I’m writing a script to calibrate our boards and have things mostly working. However, I’ve noticed that the UART functions drop a lot of data. When my device boots it’ll write several hundred bytes out the UART within a second or so. The data is made broken into ~20 lines, but the Arc only receives ~2. If I step over the code in firmware so that the data is printed slower, then it receives everything. The relevant part of my script is basically:
function wait_for_boot()
otii.writeln("waiting for device to boot")
while true do
write_command("@@@")
local rx_data
repeat
rx_data = box:read_rx()
otii.writeln("data=" .. rx_data)
until string.len(rx_data) == 0
otii.msleep(200)
end
end
If I remove the write_command line (which does a box:write_tx) and the otii.msleep, I get the same behaviour.
Is UART data buffered anywhere? Why am I dropped so much data? I’m only using a 115200 baud rate and very little data is being transmitted. Also, I’ve had trouble writing new line characters with write_tx and had to switch to using ! to terminate lines, which is a little annoying, but I can live with it.
When using read_rx there’s no buffering done, lines that come in between your read_rx calls will be lost. I suggest that you instead enable the rx channel and start a recording, then you can get all the lines with get_channel_data, of if you just care about ~20 lines being received you can just check get_channel_count.
I have created an internal ticket to improve the read_rx scripting documentation.
If you are using rx data to determine when to actually start your “real” recording for power verification I suggest you stop your recording, delete it and start a new one when you got your RX lines.
I’m not sure what you mean here. Are you sending data to it’s RX pin and get it back on the TX pin? I believe I just tested that without such effect. And I’m unable to find anything in the code that would indicate such behaviour. What firmware version are you using?
Also, in the upcoming 1.0.9 version of firmware, there’s a bug fix regarding write_tx incorrectly truncating the text you want to send.
Ok, that makes more sense, thanks. I’m using UART to get device info, etc. and then to command the device to start its internal sampling. I didn’t realize I could enable rx data like you said, so that could work.
It’s a little tricky to synchronize, but because the device should be drawing a constant current it isn’t a massive issue. In an ideal world, I’d just sample the entire time and then find the relevant bits of data at the end. However, I can’t find any way to get GPIO states into a recording, so I have to poll them and then start a recording, while throwing away a bit of data at the start/end. Is there any way to record the status of the Arc’s inputs into a session? I don’t see anything in device:enable_channel(), so I would guess not?
Regarding the UART echo, yes I am sending data to the Arc’s RX and I get it back on the TX. I have hardware revision 1.1, and firmware 1.0.8 with 2.0.0 of the desktop software. I’ve just tested again by plugging in GND, TX and RX to an FTDI uart to usb coverter and plugging it into my computer. Then start a new project, enable uart and then do nothing in the script. When I open a terminal I see all characters I send back on the RX line. If I unplug Arc’s TX line (my RX), then I no longer receive the characters so the lines aren’t shorted together. Not sure what’s going on if it’s not intentional on the Arc’s behalf.
We kinda made a boo boo there. We added it in 2.0.0, but forgot to add it to the scripting documentation. You can enable GPI1 as i1 and GPI2 as i2. You can’t currently plot GPO, but as you control them yourself I assume it’s less valuable.
We’ll have to take a closer look at that UART behaviour, it’s not intended. There’s a bit of vacationing going on at Qoitech at the moment so I’m a bit unsure when we will have an answer for you.
I’ve had a closer look at this today. And I can’t reproduce it by connecting the Arc card to an FTDI cable and then sending data to Arc. I tried this on 1.0.9 firmware. If you still have problem with this, could you attach your script either here or, if it’s private, in a case so we can have a further look at it.
Hi…i am a new user here. As per my knowledge lines that come in between your read_rx calls will be lost. I suggest that you instead enable the rx channel and start a recording, then you can get all the lines with get_channel_data, of if you just care about ~20 lines being received you can just check get_channel_count.
