working with UART and Bytearrays

[dhylands]

Yeah - you're right.

I was trying to point out that if you do:

Code: Select all

uart.readinto(buf[3:6])

then that won't modify the underlying buffer (it will instead modify a temporary slice of the buf), but if you do:

Code: Select all

uart.readinto(mv[3:6])

then that will modify the underlying buffer.

[EasyRider]

x

[dhylands]

Do you have 2 pyboards connected together? Or are you looping back with one?

Reading waiting for the gaps should also work, but maybe not with one pyboard looped back to itself.

When you specify an rx buffer length > 0 then the chars are buffered via IRQ into the buffer and all sense of timing is lost.

With pyboard looped back on itself, the write is synchronous, so by the time the write finishes, all of the bytes will already be in the rx buffer.

I think I'd have to see the complete code for the reader and writer and know whether you've got one or 2 pyboards connected together to explain what you're seeing.

[EasyRider]

x

[dhylands]

You could send it via email to dhylands@gmail.com or pastebin it and post a link here

[EasyRider]

x

[Sokrates]

I will try to simplify this to work with 2 pyboards to make it easier to evaluate.
Will let you know.

Regards
John

I had the same issue.
In my project i have to read 25byte frames but I set the buffer read_buf_len to 250. In my understanding it is the "physical" buffer and when you call readinto(myByff, 25) the first 25 bytes are copied from that buffer to your myBuff var. Setting read_buf_len to 250 gave me some timing-related robustness.
My frame has known start/stop bytes so i know exactly when i received a valid frame.

I initially call a method sync() that read all the byte until it finds a the start byte. Then it checks if after 25 bytes there is the end bytes. If the check is true we have the sync so the application start reading 25 bytes. if it receives a frame with the first byte different from start byte and the last byte different from the end byte it mark the frame as lost. if the number of lost frame goes above a threshold it start the sync process again.

For me this works since i can afford loosing some frames.

Please anybody feel free to correct me if I'm wrong

[pythoncoder]

The problems under discussion are endemic to serial comms and warrant some thought before you start coding.

To set up a robust serial link between two devices usually involves considering the case where one end of the link is power cycled, temporarily disconnected or reset. At the very least the two ends are likely to start up asynchronously. You need a design where synchronisation can be achieved after a disruption: a disruption which may involve the receiver only getting part of a frame. @Sokrates has implemented one approach, having a fixed frame length and a unique start character. Another approach is to use a half duplex request-response protocol where the receiver sends a request character to the transmitter, which responds with a frame. This avoids the need for a unique start character and is the approach I'd recommend if it's possible.

@EasyRider, your approach lacking a start character and relying on timing, is inherently tough to get right in the presence of disruptions. If at all possible I'd use another way.

The other issue is frame length: if it can't be fixed at design time the message format needs a data value (at the start of the message) to specify the total length of data to be transmitted. The other thorny problem is flow control, but hopefully this isn't required here.

[EasyRider]

x

[dhylands]

uart.any returns if any characters are available. If it executes immediately after the write, its possible that your response may not have arrived yet.

Depending on the how the timeouts are setup the read may not return all of the bytes that you want.

If you want to read ulen bytes, then you'll need a loop.