Fix for deadlock in UARTSerialDeviceReceive and UARTSerialDeviceTransmit

Releases, updates and announcements from the Ultibo team.
User avatar
Ultibo
Site Admin
Posts: 1978
Joined: Sat Dec 19, 2015 3:49 am
Location: Australia

Re: Fix for deadlock in UARTSerialDeviceReceive and UARTSerialDeviceTransmit

Postby Ultibo » Wed Apr 04, 2018 12:20 am

develone wrote:Let me if this makes sense, that the long write time was hanging it up?.

Maybe, looking at the code in checksum_ultibo.c it does fopen() and then fputc() for every character so it certainly won't be fast.

It still shouldn't stop it from working, it would just be quite slow. You might be better to use something like fputs() to write the complete string at once.

We can do some tests with your project and a large gps.dat see what results we get.
Ultibo.org | Make something amazing
https://ultibo.org
Gavinmc42
Posts: 1387
Joined: Sun Jun 05, 2016 12:38 pm
Location: Brisbane, Australia

Re: Fix for deadlock in UARTSerialDeviceReceive and UARTSerialDeviceTransmit

Postby Gavinmc42 » Wed Apr 04, 2018 2:49 am

GPS data every second, depends on the baud rate and the amount of data sent.
GPS modules usually default to 4800 baud.
I have found if I need more than standard data I need to increases the baud rate.
Previously I had to debug this with the help of a CRO, now I am working on a built in logic analyser unit.

This will read the level of the GPIO pins.

Code: Select all

data:=GPIORead(BCM2835_GPLEV0);

Saving a second of data should get you the state of the uart pins to check if all the data has been sent in the time allowed.
If set up to get data bu DMA then is should be independent of the Arm core code.
I still need to figure that bit out.

Return to “Ultibo”

Who is online

Users browsing this forum: Google [Bot] and 1 guest