Regular Member
Joined: 27/04/2012
Location: AustraliaPosts: 42
| Posted: 10:40pm 20 Jun 2024 |
Thanks for all the suggestions. My original four RP2040-zeros are side by side on a PCB roughly 150mm long so it's not as if I'm sending data over long distances. Though with a high baud rate & random dropped bytes I wasn't sure if it was timing or maybe the multi-drop wasn't pulling the serial line low enough (I used Schottky diodes) or whatever. I do have some queries regarding handling the ADCs but I'll post a new topic for that.
So if you re-read my original post, all tests I've now performed are using 2 raspi PICOs interconnected with 3 wires about 40mm long: +5 to +5, 0V to 0V and COM1 Tx from PICO#1 to COM1 Rx on PICO#0. I move the USB lead from one to the other to re-program each PICO but I leave it plugged into PICO#0 for the data transfer tests.
I confirmed that sending a 32 byte string + cr/lf (PRINT dat$) at 921600 baud via the USB port on each PICO to a computer running TeraTerm and Putty didn't drop any bytes when sending at 1 string per second and also 100 strings per sec. I then loaded a program into PICO#1 to send the 32 byte string via COM1 Tx at 921600 baud but once per second and looked at the signal with a CRO (oscilloscope). The packet didn't change size so confirmed 32 bytes were always sent (it would have been obvious if a byte was dropped).
Then I programmed PICO#0 to wait for a min of 32 bytes to be received from PICO#1 using LOC(), it inputs everything from the receive buffer using INPUT$(70,#5) (the 70 is there so it'll read up to 2 strings just in case) and to send everything it receives to TeraTerm at 921600 baud. So on the screen it should display 1 line of 32 characters each second.
So imagine my surprise when occasionally it skipped a second and then 1 second later printed nearly 2 strings of characters. 1 string per sec is hardly stretching any buffer or timing limits but there is was - it was dropping the occasional byte. The work-around as we now found is to either send the data with 2 stop bits or to up the speed of PICO#0. So it seems to indicate a timing problem in MMBASIC either with the INPUT$ command or thinking about it overnight, maybe there's an interaction using LOC() while serial data is being received by the serial port, I just don't know.
Another test I'll do later today is to ditch the LOC() command and use
"COMn: baud, buf, int, int-trigger, EVEN, ODD, S2, 7BIT"
With int-trigger set to 32 it'll trigger an interrupt when 32 bytes are received and I'll read the data then. That should confirm if LOC() was the problem.
Peter