Hello to everybody, I'm new here. I think that it is a good forum and I hope that you can help me. I have two devices composed as follow: ATmega328P <--SPI--> RF12B I created my own library but I have a big problem. The two devices (configurated as transmitter and receiver respectively) communicate well but the receiver miss a lot of characters. The receiver cannot receive up to 3 bytes (excluding the preamble and the synch bytes). It is very strange and makes me mad! I tryed a lot of methods to avoid this problem, but with no results. I am sure that the problem must be the underflow of tx's buffer or the early stop in receiving. other info: - I use polling RX (Read the Status, then FFIT control and finally do RX byte command for reading the FIFO) - During TX, SDO signal confirmed me the receiving of all the bytes example: TX: AA AA D2 0A 0B 0C 0D 0E AA RX: 0A 0B 0C Any suggestions? Thank you in advance! Davide
overrun of receive buffer... i'm not quite sure with spi, but most avr usarts behave this way if receive buffer isn't read fast enough, in my opinion 3 bytes is a characteristic value for AVR receive buffer overrun...
Thank you for your answer Thomas! I think that this problem is not related to SPI's buffer overrun, because every time I get the data I wait the SPIF flag and then I get the data from the buffer. It should prevent from the buffer overrun. Isn't it? I think that the problem is related to the speed of getting the data from RX's FIFO. Now I am using another method: When the reading of RF12B's status returns me FFIT flag I force the reading of 8 byte. With this bad bad method I can see this: TX(payload): 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F, 0x10, 0x11 FROM TERMINAL (RX) Start! Inizializzazione terminata! (=end of init) frame RX: 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F, 0x11, 0x0F, frame RX: 0xFF, 0xFF, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F, frame RX: 0x10, 0x07, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F, frame RX: 0x11, 0x07, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F, frame RX: 0x11, 0xC7, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F, there are a lot of mistakes but I have received more than only 3 correct bytes now :)
NEWS: TX(payload): 0x10, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19 frame RX: 0x10, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x06, frame RX: 0x10, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x06, frame RX: 0x10, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x19, 0xC6, frame RX: 0x10, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x19, 0xCF, frame RX: 0x10, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x07, frame RX: 0x10, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x3D, The problem is related to the last two bytes!
Guest
#2499989
you have to send 2 dummy bytes at the end of your payload.
LAST NEWS: my code works good! The problem was that I called the TX stop command too early!!! :) Bye :)
rfm wrote: > you have to send 2 dummy bytes at the end of your payload. No, the dummies are not mandatory.
Guest
#2500050
If your tx routine is programmed according to the datasheet, then just one dummy is enough. Obviously it wasn't done so, and the last bits got stuck in the tx buffer. Then the second dummy byte is next best solution.
rfm wrote: > If your tx routine is programmed according to the datasheet, then just > one dummy is enough. Obviously it wasn't done so, and the last bits got > stuck in the tx buffer. Then the second dummy byte is next best > solution. What you have said is true! With the 2nd dummy byte all works fine! Thank you! I have resolved the problem with a delay, but your solution is the best if we think about a wireless sensor network application. Thank you :)
Guest
#2500129
Well, I had the same issues once. Also, the delay may look as a solution at first but could cause a unwanted RGIT-IRQ if too long, because the RFM wants to transmit another byte and so get the tx buffer filled up again. Cheers.
Reply
Please log in before posting.