Can Moteino SPI speed be set to 1MHz without causing a problem?

[TomWS]

I am attaching a SPI slave whose highest supported speed is 1MHz.  This can obviously be set with SPI.setClockDivider(SPI_CLOCK_DIV16) change in RFM69.cpp, but will this break anything?  The comment says you slowed the clock down to 4MHz due to problems, but do you see any reason it couldn't be slowed to 1MHz?

Tom

[Felix]

The best way to know is to try. I don't think it will be an issue. If it is interfering with other SPI devices then you can just set it to 1mhz only when you talk to that particular device, then switch back to whatever it was (ie save the current speed, set to 1mhz, talk to your device, then set speed back to saved value).

[TomWS]

The best way to know is to try. I don't think it will be an issue. If it is interfering with other SPI devices then you can just set it to 1mhz only when you talk to that particular device, then switch back to whatever it was (ie save the current speed, set to 1mhz, talk to your device, then set speed back to saved value).

Ok, I'll let you know what I find.  I guess the simplest 'reasonable' test would be to do several wireless updates to a device that has been set to 1MHz SPI speed.  This will give both the radio and the flash an acceptable workout.

I don't expect it to be an issue, but, if it is, I'll try keeping shadow copies of some of the RFM69 registers (the ones in which 'readreg' is used on registers that are only set from the processor) to reduce some unnecessary overhead.

[TomWS]

The best way to know is to try. I don't think it will be an issue. If it is interfering with other SPI devices then you can just set it to 1mhz only when you talk to that particular device, then switch back to whatever it was (ie save the current speed, set to 1mhz, talk to your device, then set speed back to saved value).

I just noticed that this is exactly what you do in the SPIFlash and RFM69.select() methods.  Makes sense to use this model on my new device and set the speed appropriate to the device.

Thanks!
Tom

[Felix]

Yes, I think a lot of libraries are crappy because settings are set in a init() function somewhere and never touched again. Then people get frustrated that their device doesn't work when they hook up another SPI device, perhaps with the same poor settings setup. The only way to ensure reliability is to use "transactional" SPI, ie make sure the settings are right on every access. The new Arduino release contains transactional SPI, but from what I've seen it's an overengineered piece of software that nobody will understand. I prefer a few lines that I can read and just get it 1 year after I wrote it.

[TomWS]

Yes, I think a lot of libraries are crappy because settings are set in a init() function somewhere and never touched again. Then people get frustrated that their device doesn't work when they hook up another SPI device, perhaps with the same poor settings setup. The only way to ensure reliability is to use "transactional" SPI, ie make sure the settings are right on every access. The new Arduino release contains transactional SPI, but from what I've seen it's an overengineered piece of software that nobody will understand. I prefer a few lines that I can read and just get it 1 year after I wrote it.

I agree with your assessment of the assumption that, in anything other than a very simple device, you could set 'global resource' settings once and then forget it. 

I'd like to have some kind of atomic mutex, so having to disable interrupts isn't necessary every time you want to use SPI, but I was glad to see that you did disable interrupts in the select method to prevent contention.  I just hope that, with the slower transfer rate and the fact that I could be transferring up to 32 byte blocks between Moteino and my device, that I don't exceed some critical timing in the RFM69...

[Felix]

No, I think you should be fine.