Openlog Artemis: Serial1.AvailableForWrite always return 0

Development Boards Artemis
1

Hi,

I suspect that my code with Serial1.write() is blocking due to having 0 tx buffer.

PaulZC pointed out the following:

https://github.com/sparkfun/OpenLog_Art … 1617442577

What should I be modifying so that the tx buffer is nonzero?

2

V1.x

The V1.x library is using a separate TX buffer to store the bytes to be sent.

In V1.x, which is interacting directly with the HAL (Hardware Abstraction Layer), it will get infomration in return about the number of bytes written in the TX-FIFO and keeps looping until ALL bytes that have been written to Serial(1) and are sent to the UART module in the Apollo3 chip.

V2.x

The Apollo3 Sparkfun V2.x library is the Apollo3 chip directly. So there is NO separate tx-buffer and as such it is always zero.

Also, the TX FIFO and RX FIFO in the Apollo3 chip are disabled in HardwareSerial.cpp :

    // disable that pesky FIFO
    AM_CRITICAL_BEGIN
    UARTn(0)->LCRH_b.FEN = 0;
    UARTn(1)->LCRH_b.FEN = 0;
    AM_CRITICAL_END

In V2.x, due to MBED being in between, it works character by character. It first checks that the UART-TX can handle a new byte. If not it will wait. After that when a previous byte has been sent, the next byte is written into TX. If the UART module has not handled that previous byte yet, it will just loop in the HAL until the new byte can be sent.

The fact that in OLA (using V2.x) the receiving/log is getting incorrect is because MBED just before starting to write all the bytes, and thus potentially waiting in between each byte in the HAL, it is setting a lock on the thread. Once completed sending all the bytes, it is unlocked. That same locking is used before and after reading. So the more you write (and even on a low baud rate) the more the change exists that incoming bytes are lost, as FIFO is NOT used and reading is potentially waiting for the lock to be removed.

Actually, this should/could have been a better implementation. Maybe in the future when I find time to update the current setup.

Way around for you

Use SoftwareSerial on V2. It is NOT part of the official V2 release, but I created one some time ago.https://github.com/paulvha/apollo3/tree … wareSerial. It has some good examples and documentation.

3

Thank you Paul,

Paul

4

Paul,

Thank you for the explanation and a solution. Quick question before I jump in. Looking at example 7, it looks like I can continue to use hardware serial while utilizing software serial. Would you recommend that I keep my current setup as is for rx using hardware and use software for just tx?

Thank you,

Hjy

5

The SoftwareSerial is working in parallel to the hardware/UART. So yes you can do what you propose.

Another, maybe easier, test you can do is to write to serial1 one byte aa time from your sketch. So do not write the complete buffer from you sketch. By doing one byte at a time, it first checks and waits that a byte can be written to the UART module. without doing a lock. The lock is happening once it starts writting.

6

Thank you, Paul. I’ll try the one byte writing.