Re: console_getline vs 0ms char delay in UART comms
Piotr Barszczewski <piotr@...>
toggle quoted messageShow quoted text
I actually was about to check the signals out of curiosity and sending them in the attachment. All of the following were done with 8N1 @ 115200 and flashed with https://docs.zephyrproject.org/latest/samples/subsys/console/getline/README.html having different DTS for the custom board of course. Every time I’ve sent "1234\r\n” to the nrf52832-QFAA chip and connected with the probes directly to UART lines.
I’ve checked the PCBs on Linux and OSX to get rid of suspicion that the OS drivers might somehow be involved in makig things funny.
I’ve also tried changing to 8N2 but the result was the same.
From the nrf52832-pcb-UART-0ms it looks like the RX corruption happens when nrf52832 starts transmitting but then it handles every n-th byte correctly. What is even stranger is that the analyzer gets a different value than what was sent and what nRF52832 received. I don’t really understand what could be the difference as both are nrf52832 (same frequency clocks) in the end, the only thing that is different is the way USB-UART converter is made and handled on OS level. Though I can’t really say that FT232R has failed like that before. It’s just this particular firmware and the way it handles the data.
I will try to find some USB-UART converter which will enumerate as ttyACM device on my Linux, unsolder the FTDI chip and try talking through ttyACM it instead of a /dev/ttyUSB one. Maybe there is something to it.
On 17 March 2021 at 23:49:09, Lawrence King (lawrence.king@...) wrote: