Proper technique needed to nest a setWatch() within a separate setWatch()

You are reading a single comment by @Robin and its replies. Click here to read the full conversation.

•

Gordon
Ok, so this is with MDBT42Q as the master? I don't believe the hardware on the MDBT42Q is capable of going below 125kHz, at least according to the datasheet.

You could try poke32(0x40003524, 0x01000000) which should be 62.5kHz (and if that works, try lower numbers in the second argument).

On the STM32 the hardware should be capable of going lower though so if you used that as a master you'd be sorted.

I'm afraid that right now software SPI doesn't implement a programmable baud rate - it's so rare that you wouldn't push SPI as fast as you can that it just wasn't worth it.

You could try:
```
var MOSI=D27;
var SCK=D25;
var CS=D28;

function send(data) {
  var p=SCK.set.bind(SCK);
  var n=SCK.reset.bind(SCK);
  var w=MOSI.write.bind(MOSI);
  CS.reset();
  data.forEach(function(d) {
w(d&128)p()n()
w(d&64)p()n()
w(d&32)p()n()
w(d&16)p()n()
w(d&8)p()n()
w(d&4)p()n()
w(d&2)p()n()
w(d&1)p()n()
  });
  CS.set();
}

send([0,1,2]);
```
Which should implement software SPI in JS in a reasonably fast way - I just tried it and I'm getting around 2kHz

... but as I'd mentioned in other threads, if you want to do device->device comms, UART is so much easier and less trouble - and it uses half as many pins.

•

Robin in reply to @Gordon

Mon 2019.08.05

'UART is so much easier and less trouble'

Project goal to push EspruinoWiFi for end users. Current board layout already has SPI for a separate slave. The other micro, short on available pins, will act as a slave initially, will need to act as a master periodically. The above proof of concept works, but at much too slow a speed. Goal to stay between 100000-800000 bits/sec.

setWatch() on WiFi as slave isn't picking up bits accurately at 100000, but does around 5000+

Thank you for promptly responding @Gordon. You have validated some additional questions I had.

'On the STM32 the hardware should be capable of going lower '

My initial testing is showing this isn't the case. I'll re-check that, but the reason to use my initial observation to use the MDBT42Q as the master.

'You could try poke32(0x40003524, 0x01000000)'

New learning there, but will look into. The real issue isn't necessarily the need to change the clock speed, but to understand why setWatch() becomes unreliable at top speed.

'software SPI doesn't implement a programmable baud rate'

No need to panic, really not needed. Just needed a method to be able to get at the setWatch() issue. Can only go so fast using Javascript, and at lowest default SPI speed too fast for setWatch() to handle.

One thought I had using software SPI, is whether the clock width is remaining stable. There is a bit of jitter using the logic analyzer, and wondered if that might be causing setWatch() to misbehave. The data stays in tact with the protocol analyzer, so I didn't originally think so. Don't have a fast enough scope to cross check.

Working on the WiFi slave code cleanup right now. Only one line inside the snippet you provided, so I don't believe setWatch() execution is the cause.

Proper technique needed to nest a setWatch() within a separate setWatch()

About

Espruino