pmscientist
commented
11 years ago Did some more testing on a different machine. I've now verified the same behavior using Arduino 1.0.3 w/Teensyduino 1.12 on WinXP (32 bit). Was thinking maybe it was a compiler issue of some sort. Testing on two platforms doesn't totally rule that out, just another data point.
In terms of minimum delay, down to a 1us delay in rf12_xfer() seems to work in practice. In theory, that could be a bit slim of a margin, but no issues so far.
I also noticed that geNodetId() in RF12_T3.h looks misspelled. Looks like it was probably meant to be getNodeId(). Didn't want to open a second issue just for that, but can if it's desired.
I didn't mention it before, but I'm using 433MHz RFM12B modules, in case that might make a difference.
The CS line goes high too quickly during an SPI transfer on my Teensy 3. This prevents the RFM12B from operating normally. Here's a screenshot of logic analyzer output from an OLS. (Ignore channels 5-7, any 'signals' on those are crosstalk because I left them disconnected)
This is the second SPI transfer (the 0xB800 data was a debug attempt, based on what the RFM driver in Jeelib does). The first transfer (0x0000) to get the status is fine, but the other transfers exhibit essentially the same timing. As you can see, the CS line goes high before the transfer is complete. This occurs 660ns after CS goes low and 200ns after the first bit is started. The T3 is running at 24MHz for this sample.
It would appear that, for some reason, the SPI0_TCR register is incrementing before the SPI transfer is complete. I've verified as best I can (print statement) that the CTCNT bit is getting set in the SPI0_PUSHR register, which should prevent this. I wonder if the TCR register is incrementing after transfer to the buffer for some reason?
For now, I've added 'delayMicroseconds(50)' right after while '(! SPI0_TCR)' in the rf12_xfer function. This resolves the timing issue and permits the RFM12B to operate normally, at least with the provided demo sketch. From the OLS output, 50us is probably a bit long, it's just what I started with. It looks like a delay of 5us, or maybe less, should work.
The only other thing I've done with this T3 is use the FastSPI library. Not sure if that could result in a setting that causes the issue. Since the EEPROM is erased each time the T3 is programmed, this doesn't seem that likely, but you never know.
Just so it's documented, I'm using Arduino 1.0.3 w/Teensyduino 1.12 on Ubuntu 12.04 (64 bit) as my dev environment.
I have OLS client files with and without the added 50us delay. I'd upload them here, but github didn't like that, let me know if you'd like copies. If I can help debug this further, I'm glad to do so.