Question to usage of tinyproto

[nmaas87]

Dear Aleksei,

I have multiple question regarding the usage of tinyproto (and probably some thinking errors on my side :)), which I wanted to clarify.

I plan on building the here pictured system:

Basically a Command PC with a Python Frontend, delivering data to an tinyproto instance to be sent over an serial link via radio. The commands shall be received via the main serial port of an AT SAM D21E18. Due to the fact that I need to have acknowledgments of the sucessful recveie of the command as well as error correction, I think I will need to use the TinyProtocol Half Duplex version. The received commands contain the number of the target subsystem, which will be then be evaluated by the AT SAM, switching the MUX to the correct subystem and passing on the received and "unpacked" command to one of several, serial-linked subsystems via the second serial interface. In answer to this command, the subystem can then create a new message, which will be passed via MUX and Serial2 to the AT SAM, then in the ideal case be packaged by tinyproto and sent back via Serial1 to the Command PC.

Questions: 1.) Is the TinyProtocol HD the correct choice for what I want to do? I bascially would need to both send and receive tinyproto frames via the same Serial Interface - or is it only possible to i.e. sent from the Command PC to the Embedded System as a secured tinyproto message and then do the answer out-of-scope of tinyproto?

2.) I tried to use the current master branch of tinyproto (directly checked out from Github) and could successfully test the sketch_sender and sketch_listener on Arduino UNOs, but not the sketch_hd_sender and sketch_hd_listener. Compilation works, but the UNOs do not seem to do anything.

3.) Trying to compile the sketch_hd_sender sketch for ESP32 with the latest ESP32 for Arduino package (1.0.2) gives the error call of overloaded 'millis()' is ambiguous

In file included from X:\sketchbook\libraries\tinyproto\src/proto/hal/tiny_types.h:36:0,

                 from X:\sketchbook\libraries\tinyproto\src/proto/hdlc/tiny_hdlc.h:3,

                 from X:\sketchbook\libraries\tinyproto\src/proto/half_duplex/tiny_hd.h:35,

                 from X:\sketchbook\libraries\tinyproto\src/TinyProtocolHd.h:32,

                 from X:\sketchbook\libraries\tinyproto\examples\sketch_hd_sender\sketch_hd_sender.ino:5:

X:\sketchbook\libraries\tinyproto\src/proto/hal/esp32/tiny_defines.h: In function 'uint32_t millis()':

X:\sketchbook\libraries\tinyproto\src/proto/hal/esp32/tiny_defines.h:59:31: error: conflicting declaration of C function 'uint32_t millis()'

 static inline uint32_t millis() {   return (uint32_t)(esp_timer_get_time()/1000); }

                               ^

In file included from X:\arduino\portable\packages\esp32\hardware\esp32\1.0.2\cores\esp32/Arduino.h:35:0,

                 from X:\arduino\build\sketch\sketch_hd_sender.ino.cpp:1:

X:\arduino\portable\packages\esp32\hardware\esp32\1.0.2\cores\esp32/esp32-hal.h:92:15: note: previous declaration 'long unsigned int millis()'

 unsigned long millis();

               ^

X:\sketchbook\libraries\tinyproto\examples\sketch_hd_sender\sketch_hd_sender.ino: In function 'void loop()':

sketch_hd_sender:39:34: error: call of overloaded 'millis()' is ambiguous

     unsigned long start = millis();

                                  ^

In file included from X:\arduino\portable\packages\esp32\hardware\esp32\1.0.2\cores\esp32/Arduino.h:35:0,

                 from X:\arduino\build\sketch\sketch_hd_sender.ino.cpp:1:

X:\arduino\portable\packages\esp32\hardware\esp32\1.0.2\cores\esp32/esp32-hal.h:92:15: note: candidate: long unsigned int millis()

 unsigned long millis();

               ^

In file included from X:\sketchbook\libraries\tinyproto\src/proto/hal/tiny_types.h:36:0,

                 from X:\sketchbook\libraries\tinyproto\src/proto/hdlc/tiny_hdlc.h:3,

                 from X:\sketchbook\libraries\tinyproto\src/proto/half_duplex/tiny_hd.h:35,

                 from X:\sketchbook\libraries\tinyproto\src/TinyProtocolHd.h:32,

                 from X:\sketchbook\libraries\tinyproto\examples\sketch_hd_sender\sketch_hd_sender.ino:5:

X:\sketchbook\libraries\tinyproto\src/proto/hal/esp32/tiny_defines.h:59:24: note: candidate: uint32_t millis()

 static inline uint32_t millis() {   return (uint32_t)(esp_timer_get_time()/1000); }

                        ^

sketch_hd_sender:40:19: error: call of overloaded 'millis()' is ambiguous

     while (millis() - start < 1000)

                   ^

In file included from X:\arduino\portable\packages\esp32\hardware\esp32\1.0.2\cores\esp32/Arduino.h:35:0,

                 from X:\arduino\build\sketch\sketch_hd_sender.ino.cpp:1:

X:\arduino\portable\packages\esp32\hardware\esp32\1.0.2\cores\esp32/esp32-hal.h:92:15: note: candidate: long unsigned int millis()

 unsigned long millis();

               ^

In file included from X:\sketchbook\libraries\tinyproto\src/proto/hal/tiny_types.h:36:0,

                 from X:\sketchbook\libraries\tinyproto\src/proto/hdlc/tiny_hdlc.h:3,

                 from X:\sketchbook\libraries\tinyproto\src/proto/half_duplex/tiny_hd.h:35,

                 from X:\sketchbook\libraries\tinyproto\src/TinyProtocolHd.h:32,

                 from X:\sketchbook\libraries\tinyproto\examples\sketch_hd_sender\sketch_hd_sender.ino:5:

X:\sketchbook\libraries\tinyproto\src/proto/hal/esp32/tiny_defines.h:59:24: note: candidate: uint32_t millis()

 static inline uint32_t millis() {   return (uint32_t)(esp_timer_get_time()/1000); }

                        ^

Bibliothek tinyproto in Version 0.7.0 im Ordner: X:\sketchbook\libraries\tinyproto  wird verwendet
exit status 1
call of overloaded 'millis()' is ambiguous

Thank you very much for your help and have an awesome weekend :)

Nico

[lexus2k]

Thank you for the kind words. You've so carefully described the problem, that I could find annd fix many issues in the protocol. It would be very nice if you check my latest commit. But Let me know, how would you like to work with the code. Is it ok for you to work with the sources from github. If not, I will release new version to Arduino library manager.

Answering to your questions 1) Yes, Half duplex is what you need. However, can you tell me, how fast do you need communication in your project? Mostly UART hardware implementation is robust enough to work at the speed 1Mbps, or even higher. I had experience to work with UART at 3Mbps without any data corruption. But at high UART speeds there can be problems with frequency drift for different computers, participating in communication. 115200 should be OK in many conditions.

2) I found bugs and checked once again on my Atmega328p

3) The issues with esp32 are fixed. Can you test them?

Also, I added hd_loopback tool on PC side. If you type make command in tinyproto root folder, it will build bld/hd_loopback for you (I use Linux). And using it, you will be able to check sketch_hd_sender. Let me know, if I can do anything else for you.

[nmaas87]

Hey,

thank you very much for your awesome support! Glad to hear that my input could help you a bit :)! I am completly fine with directly working from Github / sources. I think its way better to reserve the release of a new package to a "know good" version, so that it does not confuse users directly working from the library manager.

Just a short question, which version do you want me to test? I presume the master branch?

To the questions: 1.) That depends on the mode of operation. In the normal / sensor-mode, it will be used with 38400 baud - which should be unproblematic, even when pairing i.e. ESP32s and the AT SAM. However, I will also need to dump some data from the ESP32s and RPi Zero which will be in the mix as the "Subsystems" - and that needs to be done faster, i.e. 921600 baud or higher. But that is something I will test as soon as the system is assembled and I can see if all systems in the signalchain will be working on a level good enough for this kind of usage, The AT SAM will be kind of a "communication end-point" and will be only used for transfering the needed data to the needed subsystems. Those themselves will only "speak" normal RS232 TTL with some own binary format.

2.) Thank you, I will recheck and report back :)

3.) Will do :)

4.) hd_loopback: Perfect, I will have a look.

Thank you very much already, I was really looking for a possibilty to include some kind of "transport security" to the serial link and your project - in contrast to others - is really focusing on this sole aspect, giving a lot of freedom in regard of the needed usecase and "features" - while still retaining a light-weight library. Really love this, thanks for putting this library out in the world and maintaining it :)!

Nico

[nmaas87]

Update:

2.) I tested it with the 328p and it worked out flawlessly

3.) It does compile now, I tried to pair it with a Due for a little test (sender ESP32 and receiver Due like on 2.)) - but that does not work. looks like the ESP32 does not send anything :(

4.) Tested with the 328p, Due and Mega working fine. However, the M0 and ESP32 did not work. Also checking the tiny_loopback with sperf did not work with the Mega, Due and ESP32 (did not test M0).

[lexus2k]

Hi Nico,

Thank you for the report. I started long-time tests on ESP32 and yes, there are issues. I don't have M0, but I need to add hal layer for ARM cpu. As for now, I committed debug version to 0.7_dev_rework. Please, use this branch for testing. I will let you know, when I solve the issue (already working on it).

[lexus2k]

Hi. Can you check 0.7_dev_rework branch for your Cortex M0? I added some support.

[nmaas87]

Yes, I will do so tomorrow, sorry I am currently a bit in a pinch but I got it on my timeline, so I'll call back as soon as this is done, thanks :)!

[nmaas87]

Got some testing done:

Regarding 4: ESP32

• sketch_hd_sender with hd_loopback worked
• tinylight_loopback with sperf worked

M0

• Can compile and upload, but hd_loopback and sperf do not work sadly

I am still working on my DUE (which should be an M0 in the future) and ESP32 combination, however, I am a bit unsuccessful, but it seems I'll have to think this through in more detail :)

[lexus2k]

Hi.

Can you enable DEBUG_SERIAL here tinyproto/tools/serial/serial_linux.c and send me logs from hd_loopback, communicating with M0? I need to buy M0 since I don't have it by hand.

[lexus2k]

Could you please clarify, which ARCH support you need to have? You mentioned, that target CPU ARCH for Cortex is M0. However DUE Arduino board is actually Cortex M3, and I need to add such support.

[nmaas87]

Hey Aleksei, seems like I was having an episode of being really ... dumb. Sorry about that. You're absolutly right, the DUE is an M3, while the M0 is an M0 (probably M0+, even). I was using an Arduino DUE for prototyping, as I got someAT SAM D21E18 (bascially the Arduino M0 with less pins and SERCOMs but otherwise the same) - but could not get them to work on a breadboard. Reason besides that - I wanted to have something with 3V3 TTL Level and multiple HW Serials. Some days ago I finally got an M0 Clone (AT SAM D21G18, the G is the 48 pin version, the "real" one used for Arduino M0, not the 32 pin E version). Currently I focus on getting the D21E18 working, but should the pins not suffice for the job, I might switch to the D21G18 version - so the M0 ARCH would be the one to use.

Now to the DEBUG_SERIAL problem - which ain't a serial problem - but me being the problem. This cheap RobotDyn SAMD21 Mini board (Arduino M0 Clone) does not come with an Debug and one CPU Serial Interface, but just the "CPU" port: With the DUE and M0, you normally have "two" "Serial" Interfaces: The CPU one is a direct connection to the Mx CPU, emulating a Serial Connection, while the Debug/Programming Port is normally a connection to some USB2Serial Interface, connected to the HW Serial Port of the Mx CPU. The cheap clone only got the CPU connection, which emulates Serial. So, if you want to program the Arduino, it just works with the Arduino M0 (not M0 Pro, which got both ports!) boards selection. But if you then connect the M0 to your computer and use it with i.e. the sperf or loopback, it won't work. Why? Because tinyproto will use the Hardware Serial interface, which is absolutly correct. But that cannot communicate with the computer directly over the USB connection you established, because its connected to the emulated Serial Port / CPU port.

In terms of usage: tinyproto correctly uses "Serial.begin()" and "Serial.write()" for the real Serial Hardware on the AT chip, which should be on the port D0/D1. The one which is connected to the PC via the USB port is the CPU port, which is used with the "SerialUSB.begin()" and "SerialUSB.write()" commands....

I compiled, uploaded the code to the M0 for the sketch_hd_sender and afterwards opened the Serial interface - I could not observe anything being send. I tried a normal Serial.println() - nothing got send, I tried a SerialUSB.println() - and I got my Serial data.

So most probably you have implemented everything correctly, but I was just using the wrong serial port. Sorry about that. I will try to solder my USB / TTL converter to the real hardware serial ports of the M0 and try the loopback with DEBUG_SERIAL enabled and post the logs here. But I presume everything will be working correctly... Sorry again for the confusion.

Best regards

Nico

[lexus2k]

Hi Nico, Let me know how it will work. BTW, I added Cortex-M3/M4 hal support via built-in gcc ATOMIC functions. I hope that I didn't break anything.

[nmaas87]

Hi Aleksei,

this thing is getting quite funny. OK, I got this Arduino Zero Clone: https://robotdyn.com/samd21-m0-mini.html

Turns out this was the worst idea ever. The "real" serial ("Serial") (connected to PB22, PB23) in Arduino, is not connected on this board. The "second" serial ("Serial1") (PA10,PA11) is connected on this board using the D0 and D1 pins: https://robotdyn.com/pub/media/0G-00005516==SAMD21-MINI/DOCS/Schematic==0G-00005516==SAMD21-MINI.pdf

And, as already told, the USB is connected to the emulated Serial Port of the MCU. So with that in mind, I cannot easily check tinyproto with this board. The interesting question now: If I where to temporarily want to use Serial1 instead of Serial as the default Serial for tinyproto (just for the tests sake ;)) - where do I would need to change that in tinyprotos code? (In the example I obvisiouly need to open Serial1 instead of serial, etc - but I guess I also need to declare which Serial to use within tinyproto). That could be quite interesting, and I would want to try it to see if I can then make an successful test :). From my side, everything compiled and uploaded successfully, but I just cannot access the pin where the serial is now residing, so I want to move that for a test ;)

Best regards

Nico

Update: Some nice infos about this clone in particular: https://github.com/BLavery/SAMD21-M0-Mini

[lexus2k]

Hi Nico,

Try to use beginToSerial1() methods instead of beginToSerial(), and don't forget to initialize Serial1. And define HAVE_HWSERIAL1 before including proto headers like this:

#define HAVE_HWSERIAL1
#include <TinyProtocolHd.h>

Aleksei

[nmaas87]

Hi Aleksei,

this worked perfectly. Using Serial1 and an external USB/TTL converter I can receive working data in the hd_loopback. loopbacktest_m0.txt

sperf cannot be tried as the tinylight_loopback cannot be compiled this way (class Tiny::ProtoLight has no member named beginToSerial1). So it seems like the M0 should be up and running!

I retested the DUE/M3 and its still working with the hd_loopback, which is awesome news, but the test with tinylight_loopback / sperf does not work:

Syncing
Test is in progress

And then thats the end of it, no lights indicating Serial Transfer and also nothing happening anymore. Got the log attached: sperf_due.txt

Best regards,

Nico

[lexus2k]

Hi Nico,

I'm sorry for the late reply. According to dumped sperf_due.txt logs, they look ok: synchronization passes successfully, 2 packets went to Arduino due boards, but second was not received completely back for some reason. I need to debug this issue.

I added beginToSerial1 for light version of protocol

Aleksei

[nmaas87]

Hi Aleksei,

don't worry about it :). I am currently waiting on delivery of an SWD programmer I ordered, so that I can finally get the raw chip M0 (ATSAMD21) programmed and start building a real prototype for testing. But it seems like that will take some time, as I have only got news that this thing is on backorder - and nothing new since then :(.

I try to give the test of the light protocol a try :)

Best regards,

Nico

[lexus2k]

Hi Nico,

Thank you. I appreciate your help.

[nmaas87]

You're most welcome :)!

The light protocol worked on the M0, if used with the beginToSerial1 and sperf, however, it was a bit odd:

(Test with 115200 baud) Syncing Test is in progress Registered speed: 63052 baud

(Test with 38400 baud) Syncing Test is in progress Registered speed: 31436 baud

For some reason, it lacks a bit on the speed area. I don't really know why, the external USB UART interface is quite capabale and has been tested successfully with other plaintext UART transmissions with higher speed (960000 BAUDish for the ESP32 interface) - so maybe something is wrong with the M0, but I would wait for the programmer to arrive and to create my own breadboard M0. Still no signs of delievery, they told me could take 2-3 weeks but as soon as it arrives and I got something, you get to know it first :)

[lexus2k]

Did you have a chance to check on new hardware? Since last discussion I did a lot of changes, updates and fixes to protocol. And also, rich official HDLC implementation is available now. It allows to establish P2P communication with frame ACK, retransmission's, keep alive check and many other features. (But I didn't test it on real hardware)

[nmaas87]

Hello @lexus2k - I got the hardware soldered on sunday and finally got the programmer, now working on an ATSAMD21G18. I would see if I can try to test the latest version in the next days and will report back here :)! Thanks a lot!

[nmaas87]

Hi Aleksei,

sorry for the late answer, but I finally got to testing your latest release :)! All done on a ATSAMD21G18 with Arduino Zero 1.8.3 firmware and Serial1 on pins PA10/PA11

Test: tiny_loopback with sketch_hd_sender and Serial1

<<< Frame received UID=05E0, payload len=6
>>> Frame sent UID=0AF1, payload len=16
>>> Frame sent UID=0AF2, payload len=16
>>> Frame sent UID=0AF3, payload len=16
>>> Frame sent UID=0AF4, payload len=16
>>> Frame sent UID=0AF5, payload len=16
>>> Frame sent UID=0AF6, payload len=16
>>> Frame sent UID=0AF7, payload len=16
>>> Frame sent UID=0AF8, payload len=16
>>> Frame sent UID=0AF9, payload len=16
>>> Frame sent UID=0AFA, payload len=16
<<< Frame received UID=05E1, payload len=6
>>> Frame sent UID=0AFB, payload len=16
>>> Frame sent UID=0AFC, payload len=16
>>> Frame sent UID=0AFD, payload len=16
>>> Frame sent UID=0AFE, payload len=16
>>> Frame sent UID=0AFF, payload len=16
>>> Frame sent UID=0B00, payload len=16
>>> Frame sent UID=0B01, payload len=16
>>> Frame sent UID=0B02, payload len=16
>>> Frame sent UID=0B03, payload len=16
>>> Frame sent UID=0B04, payload len=16
<<< Frame received UID=05E2, payload len=6
>>> Frame sent UID=0B05, payload len=16
>>> Frame sent UID=0B06, payload len=16
>>> Frame sent UID=0B07, payload len=16
>>> Frame sent UID=0B08, payload len=16
>>> Frame sent UID=0B09, payload len=16
>>> Frame sent UID=0B0A, payload len=16
>>> Frame sent UID=0B0B, payload len=16
>>> Frame sent UID=0B0C, payload len=16
>>> Frame sent UID=0B0D, payload len=16
>>> Frame sent UID=0B0E, payload len=16
<<< Frame received UID=05E3, payload len=6
>>> Frame sent UID=0B0F, payload len=16
>>> Frame sent UID=0B10, payload len=16

Test with: sudo ./tiny_loopback -p /dev/ttyAMA0 -c 8 -g

Code:

/*
 * This example sends <Hello> packet every second.
 * This is demontraction of Half Duplex protocol.
 */
#define HAVE_HWSERIAL1
#include <TinyProtocol.h>

/* Function to receive incoming messages from remote side */
void onFrameIn(uint8_t *buf, int len)
{
    /* Do what you need with receive data here */
}

/* Half Duplex protocol requires some buffer to store incoming data */
uint8_t buffer[64];

/* Creating Half Duplex protocol object is simple           */
/* Just pass buffer info and callback for incoming messages */
Tiny::ProtoHd  proto(buffer, sizeof(buffer), onFrameIn);

void setup() {
    /* No timeout, since we want non-blocking UART operations */
    Serial1.setTimeout(0);
    /* Initialize serial protocol for test purposes */
    Serial1.begin(115200);
    //Serial1.begin(38400);
    /* We do want to use simple checkSum */
    proto.enableCheckSum();
    /* Redirect all protocol communication to Serial0 UART */
    proto.beginToSerial1();
}

void loop()
{
    /* Prepare data you want to send here */
    Tiny::Packet<6> packet;
    packet.put( "HELLO" );

    /* Send packet over UART to other side */
    proto.write(packet);

    /* We send HELLO packet every 1 second */
    unsigned long start = millis();
    while (millis() - start < 1000)
    {
        proto.run();
    }
}

Test: tiny_loopback with tinyfd_loopback and Serial1

sudo ./tiny_loopback -p /dev/ttyAMA0 -t fd -g
<<< Frame received payload len=34
Failed to send packet
Failed to send packet
Failed to send packet
Failed to send packet
Failed to send packet
Failed to send packet
Failed to send packet
Failed to send packet
Failed to send packet
Failed to send packet
Failed to send packet
Failed to send packet

Test with: sudo ./tiny_loopback -p /dev/ttyAMA0 -t fd -g

Code:

/*
 * This example sends back every buffer received over UART.
 *
 * !README!
 * The sketch is developed to perform UART tests between Arduino
 * and PC.
 * 1. Burn this program to Arduino
 * 2. Compile sperf tool (see tools folder) for your system
 * 3. Connect Arduino TX and RX lines to your PC com port
 * 4. Run sperf on the PC (use correct port name on your system):
 *      sperf /dev/ttyUSB0
 *      sperf COM1
 * 5. sperf will print the test speed results
 *
 * Also, this example demonstrates how to pass data between 2 systems
 * By default the sketch and sperf works as 115200 speed.
 */
#define HAVE_HWSERIAL1
#include <TinyProtocol.h>
// We need this hack for very small controllers.
#include <proto/fd/tiny_fd_int.h>

/* Creating protocol object is simple. Lets define 64 bytes as maximum. *
 * size for the packet and use 4 packets in outgoing queue.             */
Tiny::ProtoFd<FD_MIN_BUF_SIZE(64,4)>  proto;

void onReceive(Tiny::IPacket &pkt)
{
    if ( proto.write(pkt) == TINY_ERR_TIMEOUT )
    {
        // Do what you need to do if there is no place to put new frame to.
        // But never use blocking operations inside callback
    }
}

void setup()
{
    /* No timeout, since we want non-blocking UART operations. */
    Serial1.setTimeout(10);
    /* Initialize serial protocol for test purposes */
    Serial1.begin(115200);
    //Serial1.begin(38400);    
    /* Lets process all incoming frames */
    proto.setReceiveCallback( onReceive );
    /* Redirect all protocol communication to Serial0 UART */
    proto.beginToSerial1();
}

void loop()
{
    if (Serial1.available())
    {
        proto.run_rx();
    }
    proto.run_tx();
}

Test sperf with tinylight_loopback with Serial1 patch

pi@raspberrypi:~/tinyproto/bld $ sudo ./sperf /dev/ttyAMA0
Syncing
Test is in progress
ERROR: -1 bytes received. expected 38
Registered speed: 6023 baud
pi@raspberrypi:~/tinyproto/bld $ sudo ./sperf /dev/ttyAMA0
Syncing
Test is in progress
ERROR: -1 bytes received. expected 38
Registered speed: 9333 baud
pi@raspberrypi:~/tinyproto/bld $ sudo ./sperf /dev/ttyAMA0
Syncing
Test is in progress
ERROR: -1 bytes received. expected 38
Registered speed: 7576 baud
pi@raspberrypi:~/tinyproto/bld $ sudo ./sperf /dev/ttyAMA0
Syncing
Test is in progress
ERROR: -1 bytes received. expected 39
Registered speed: 20065 baud
pi@raspberrypi:~/tinyproto/bld $

sudo ./sperf /dev/ttyAMA0

Code:

/*
 * This example sends back every buffer received over UART.
 *
 * !README!
 * The sketch is developed to perform UART tests between Arduino
 * and PC.
 * 1. Burn this program to Arduino
 * 2. Compile sperf tool (see tools folder) for your system
 * 3. Connect Arduino TX and RX lines to your PC com port
 * 4. Run sperf on the PC (use correct port name on your system):
 *      sperf /dev/ttyUSB0
 *      sperf COM1
 * 5. sperf will print the test speed results
 *
 * Also, this example demonstrates how to pass data between 2 systems
 * By default the sketch and sperf works as 115200 speed.
 */

#define HAVE_HWSERIAL1
#include <TinyProtocol.h>

/* Creating protocol object is simple */
Tiny::ProtoLight  proto;

void setup()
{
    /* No timeout, since we want non-blocking UART operations. */
    Serial1.setTimeout(10);
    /* Initialize serial protocol for test purposes */
    Serial1.begin(115200);
    //Serial1.begin(38400);
    /* Redirect all protocol communication to Serial0 UART */
    proto.beginToSerial1();
}

/* Specify buffer for packets to send and receive */
Tiny::Packet<256> packet;

void loop()
{
    if (Serial1.available())
    {
        int len = proto.read( packet );
        if (len > 0)
        {
            /* Send message back */
            proto.write( packet );
        }
    }
}

Attachments: DEBUG_SERIAL enabled for the tests of sperf ( testoutsperf.txt) and tiny_loopbackfd ( testouttinyloopbackfd.txt )

testoutsperf.txt

testouttinyloopbackfd.txt

Best,

Nico

[lexus2k]

Thank you very much for such full report. I reproduced issue without any hardware, debugging now.

[lexus2k]

I fixed several bugs in FD and HDLC. And maybe this will solve the problems. I will be able to do some tests on real hardware next week. Thank you.

[nmaas87]

Hey, thank you very much, thats awesome! I will try to test and report tonight your latest additions :)!

[nmaas87]

• Test: loopback hd Test: tiny_loopback with sketch_hd_sender and Serial1 worked again :)

• Test: sperf Test: tinylight_loopback with Serial1 patch sperf.txt

• Test: loopback fd Test: tiny_loopback with tinyfd_loopback and Serial1 tiny.txt .. and afterwards Failed to send packet Failed to send packet Failed to send packet

[lexus2k]

Hi Nico,

Next week I will debug on real hardware (I'm still far away from home). Thank you for all your support. Also, after your report I've set serial timeout for FD arduino project to 0 milliseconds (it was 10 milliseconds): bc5e6c3, - and maybe non-zero timeout values caused communication errors. Loopback tools also supports different communication speeds, may 115200 is too much for complex full duplex protocol. Anyway, thanks for your help.

Alexey

[nmaas87]

Thank you very much, I'll wait for your findings :)

Nico

Aleksei notifications@github.com schrieb am Do., 24. Okt. 2019, 01:17:

Hi Nico,

Next week I will debug on real hardware (I'm still far away from home). Thank you for all your support. Also, after your report I've set serial timeout for FD arduino project to 0 milliseconds (it was 10 milliseconds): bc5e6c3 https://github.com/lexus2k/tinyproto/commit/bc5e6c3341b91ebd02175a84794a55e0528e5cda,

• and maybe non-zero timeout values caused communication errors. Loopback tools also supports different communication speeds, may 115200 is too much for complex full duplex protocol. Anyway, thanks for your help.

Alexey

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/lexus2k/tinyproto/issues/9?email_source=notifications&email_token=AAKFCALP5AEQXZXJWAUQGOTQQDLQ7A5CNFSM4IKRLCO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECDFQZY#issuecomment-545675367, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKFCAOUEZSZGUJKB77UOS3QQDLQ7ANCNFSM4IKRLCOQ .

[lexus2k]

Finally I've tested on my Arduino Nano. And it worked. But before I had made some changes to tiny_loopback. Now there are 3 sketches in example folder:

• tinylight_loopback
• tinyhd_loopback
• tinyfd_loopback

and those can be used with tiny_loopback:

• ./bld/tiny_loopback -p /dev/ttyUSB0 -c 8 t light -g -r
• ./bld/tiny_loopback -p /dev/ttyUSB0 -c 8 -t hd -g -r
• ./bld/tiny_loopback -p /dev/ttyUSB0 -c 8 -t fd -w 3 -g -r

[nmaas87]

Hi, I did test it. Short info: The first test misses a - at the t light ;) ( ./bld/tiny_loopback -p /dev/ttyUSB0 -c 8 -t light -g -r )

The light version did work a bit slowly at 115200 baud, but worked. fd does not work and hd does not compile.

* Test: loopback light
- tinylight_loopback with Serial1 patch
cd ~/tinyproto/bld/
sudo ./tiny_loopback -p /dev/ttyAMA0 -c 8 -t light -g -r
...............
Registered TX speed: 6401 bps
Registered RX speed: 6129 bps

* Test: loopback fd
Test: tiny_loopback with tinyfd_loopback and Serial1
- tinyfd_loopback with Serial1 patch
cd ~/tinyproto/bld/
sudo ./tiny_loopback -p /dev/ttyAMA0 -c 8 -t fd -w 3 -g -r
Failed to send packet
.Failed to send packet
.Failed to send packet
.Failed to send packet
.Failed to send packet
.Failed to send packet
.Failed to send packet
.Failed to send packet
.Failed to send packet
.Failed to send packet
.Failed to send packet
.Failed to send packet
.Failed to send packet
.Failed to send packet
.Failed to send packet
.
Registered TX speed: 0 bps
Registered RX speed: 0 bps

* Test: loopback hd
Test: tiny_loopback with sketch_hd_sender and Serial1
- sketch_hd_sender with Serial1 patch
cd ~/tinyproto/bld/
sudo ./tiny_loopback -p /dev/ttyUSB0 -c 8 -t hd -g -r

[lexus2k]

Finally, I ordered Arduino M0 on aliexpress. And today I will try on Raspberry + ESP32. I will let you know the results

[nmaas87]

Awesome, thanks a lot :)!

[lexus2k]

Hi Nico,

I found some bugs in tiny_loopback tool in serial port support implementation (the same code was used for sperf before). So, I fixed issues. And finally I've got the following results. I verified several setups:

1. PC Linux <-> ESP32 Dev board (PASS for light, fd, hd)
2. Raspberry Pi 2 <-> Arduino nano (PASS for light, fd, hd)
3. Raspberry Pi 2 <-> ESP32 Dev board (PASS for light, fd, hd)

Also, I'm waiting for Arduino M0 (hope to get it soon), to do tests similar to yours. I will send more updates later.

[nmaas87]

I tried it today with another cheap clone ( https://github.com/BLavery/SAMD21-M0-Mini ) - as I do not want to report something bad to you which could be done by me doing something wrong with the hardware. I used it with Serial1, as usual, compiled it on Windows 10 / latest Arduino version and checked on an RPi3B+ with a connected, external USB Serial Adapter (ESP-PROG) connected to the correct pins for Serial1 on the clone.

# with correct serial connection to the Arduino
sudo ./tiny_loopback -p /dev/ttyUSB1 -c 8 -t light -g -r
..............
Registered TX speed: 89161 bps
Registered RX speed: 87094 bps

# without any serial connection to the Arduino
sudo ./tiny_loopback -p /dev/ttyUSB1 -c 8 -t light -g -r
..............
Registered TX speed: 89070 bps
Registered RX speed: 0 bps

# tinylight_fd
sudo ./tiny_loopback -p /dev/ttyUSB1 -c 8 -t fd -w 3 -g -r
# with correct serial connection to the Arduino
Failed to send packet
.Failed to send packet
.Failed to send packet
.^C

# tinylight_hd
# could not test, does not compile sketch tinylight_hd on Windows 10 with 1.8.10 Arduino, due to error
# sudo ./tiny_loopback -p /dev/ttyUSB1 -c 8 -t hd -g -r

Arduino: 1.8.10 (Windows 10), Board: "Arduino M0"
X:\sketchbook\libraries\tinyproto\examples\tinyhd_loopback\tinyhd_loopback.ino: In function 'void onFrameIn(uint8_t*, int)':

tinyhd_loopback:21:33: error: invalid conversion from 'uint8_t* {aka unsigned char*}' to 'char*' [-fpermissive]

     proto.write( tx_buffer, len );

                                 ^

In file included from X:\sketchbook\libraries\tinyproto\src/TinyProtocol.h:32:0,

                 from X:\sketchbook\libraries\tinyproto\examples\tinyhd_loopback\tinyhd_loopback.ino:5:

X:\sketchbook\libraries\tinyproto\src/TinyProtocolHd.h:154:10: note:   initializing argument 1 of 'int Tiny::ProtoHd::write(char*, int)'

     int  write          (char* buf, int size);

          ^~~~~

Multiple Libs found for "TinyProtocol.h"
 Use: X:\sketchbook\libraries\tinyproto
Version 0.9.0: X:\sketchbook\libraries\tinyproto
exit status 1
invalid conversion from 'uint8_t* {aka unsigned char*}' to 'char*' [-fpermissive]

Thanks a lot for your work, just tried to get something new done :). However, I get this error for the tinyhd_loopback also by trying to compile it for ESP32. Strange, there is maybe something off on my end, as I cannot get it compiled. Mh.

[lexus2k]

The compilation problem is very simple to fix. I committed the fix.

As for the result, you provided. They are strange, since light version works, but hd and fd doesn't. Anyway, you can get more debug information from tiny_loopback tool if you recompile it using command below: make ENABLE_LOGS=y LOG_LEVEL=5

Remember that light protocol requires tinylight_loopback demo flashed, hd - tinyhd_loopback and fd - tinyfd_loopback flashed.

[lexus2k]

Hi Nico,

I found one interesting side of Arduino boards. If to use serial commincation via USB to serial interface, many Arduino boards stop loading if something is sent to UART in first 2 seconds. I believe, that Arduino boot loader does that. So, I added additional parameter to tiny_loopback tool -a or --arduino-tty, so, tiny_loopback tool make delay before transmission data to Arduino board.

[nmaas87]

Hi Alexey,

I tried it again today. The -a idea is great, however, it is a bit different on different platforms. I.e. if you try to upload your code on an Arduino Zero which has no debug bridge (i.e. the Arduino Zero (Native Port) Board in the Arduino IDE), it will trigger the bootloader by trying to open the Virtual Serial Port over USB with 1200 bps - which will reset the board. However, in my usecase I use the Serial1 for tinyproto, as this will be the configuration it will be used in later :). So I actually only use the USB Interface to upload the code and as long as the attached external usb uart would not try to open the port to the Arduino via 1200 bps, everything will be fine (the same behavior can be found on Serial1 port, however, you can burn the bootloader in a way that it will ignore Serial1 completly and only really use it for the main software. That said, I don't think it is interfering in my usecase :).

Light

pi@raspberrypi:~/tinyproto/bld $ sudo ./tiny_loopback -p /dev/ttyUSB1 -c 8 -t light -g -r
Registered TX speed: 86278 bps
Registered RX speed: 0 bps

light.txt

/*
 * This example sends back every buffer received over UART.
 *
 * !README!
 * The sketch is developed to perform UART tests between Arduino
 * and PC.
 * 1. Burn this program to Arduino
 * 2. Compile tiny_loopback tool (see tools folder) for your system
 * 3. Connect Arduino TX and RX lines to your PC com port
 * 4. Run tiny_loopback on the PC (use correct port name on your system)
 * 5. tiny_loopback will print the test speed results
 *
 * Also, this example demonstrates how to pass data between 2 systems
 * By default the sketch and tiny_loopback works as 115200 speed.
 */
#define HAVE_HWSERIAL1
#include <TinyProtocol.h>

/* Creating protocol object is simple */
Tiny::ProtoLight  proto;

void setup()
{
    /* No timeout, since we want non-blocking UART operations. */
    Serial1.setTimeout(10);
    /* Initialize serial protocol for test purposes */
    Serial1.begin(115200);
    /* Redirect all protocol communication to Serial0 UART */
    proto.beginToSerial1();
    /* Lets use 8-bit checksum, available on all platforms */
    proto.enableCheckSum();
}

/* Specify buffer for packets to send and receive */
Tiny::Packet<256> packet;

void loop()
{
    if (Serial1.available())
    {
        int len = proto.read( packet );
        if (len > 0)
        {
            /* Send message back */
            proto.write( packet );
        }
    }
}

HD

pi@raspberrypi:~/tinyproto/bld $ sudo ./tiny_loopback -p /dev/ttyUSB1 -c 8 -t hd -g -r
..............
Registered TX speed: 7987 bps
Registered RX speed: 7987 bps
pi@raspberrypi:~/tinyproto/bld $ sudo ./tiny_loopback -p /dev/ttyUSB1 -c 8 -t hd -g -r
..............
Registered TX speed: 8004 bps
Registered RX speed: 8004 bps
pi@raspberrypi:~/tinyproto/bld $ sudo ./tiny_loopback -p /dev/ttyUSB1 -c 8 -t hd -g -r
..............
Registered TX speed: 8004 bps
Registered RX speed: 8004 bps
pi@raspberrypi:~/tinyproto/bld $

hd.txt

/*
 * This simple example listens for commands from UART.
 * This is demonstration of Half Duplex protocol.
 */
 #define HAVE_HWSERIAL1
#include <TinyProtocol.h>

void onFrameIn(uint8_t *buf, int len);

/* Half Duplex protocol requires some buffer to store incoming data */
uint8_t buffer[64];

/* Creating Half Duplex protocol object is simple           */
/* Just pass buffer info and callback for incoming messages */
Tiny::ProtoHd  proto(buffer, sizeof(buffer), onFrameIn);

/* Function to receive incoming messages from remote side */
void onFrameIn(uint8_t *buf, int len)
{
    uint8_t tx_buffer[64];
    memcpy( tx_buffer, buf, len );
    proto.write( (char *)tx_buffer, len );
}

void setup() {
    /* No timeout, since we want non-blocking UART operations */
    Serial1.setTimeout(0);
    /* Initialize serial protocol for test purposes */
    Serial1.begin(115200);
    /* We do want to use simple checkSum */
    proto.enableCheckSum();
    /* Redirect all protocol communication to Serial0 UART */
    proto.beginToSerial1();
}

void loop()
{
    proto.run();
}

FD

pi@raspberrypi:~/tinyproto/bld $ sudo ./tiny_loopback -p /dev/ttyUSB1 -c 8 -t fd -w 3 -g -r
Failed to send packet
.Failed to send packet
.Failed to send packet
.Failed to send packet
.Failed to send packet
.Failed to send packet
.Failed to send packet
.Failed to send packet
.Failed to send packet
.Failed to send packet
.Failed to send packet
.Failed to send packet
.Failed to send packet
.Failed to send packet
.Failed to send packet
.
Registered TX speed: 72 bps
Registered RX speed: 18 bps

fd.txt

/*
 * This example sends back every buffer received over UART.
 *
 * !README!
 * The sketch is developed to perform UART tests between Arduino
 * and PC.
 * 1. Burn this program to Arduino
 * 2. Compile tiny_loopback tool (see tools folder) for your system
 * 3. Connect Arduino TX and RX lines to your PC com port
 * 4. Run tiny_loopback on the PC (use correct port name on your system)
 * 5. tiny_loopback will print the test speed results
 *
 * Also, this example demonstrates how to pass data between 2 systems
 * By default the sketch and tiny_loopback works as 115200 speed.
 */
#define HAVE_HWSERIAL1
#include <TinyProtocol.h>
// We need this hack for very small controllers.
#include <proto/fd/tiny_fd_int.h>

/* Creating protocol object is simple. Lets define 64 bytes as maximum. *
 * size for the packet and use 4 packets in outgoing queue.             */
Tiny::ProtoFd<FD_MIN_BUF_SIZE(64,4)>  proto;

void onReceive(Tiny::IPacket &pkt)
{
    if ( proto.write(pkt) == TINY_ERR_TIMEOUT )
    {
        // Do what you need to do if there is no place to put new frame to.
        // But never use blocking operations inside callback
    }
}

void setup()
{
    /* No timeout, since we want non-blocking UART operations. */
    Serial1.setTimeout(0);
    /* Initialize serial protocol for test purposes */
    Serial1.begin(115200);
    /* Lets use 8-bit checksum, available on all platforms */
    proto.enableCheckSum();
    /* Lets process all incoming frames */
    proto.setReceiveCallback( onReceive );
    /* Redirect all protocol communication to Serial0 UART */
    proto.beginToSerial1();
}

void loop()
{
    if (Serial1.available())
    {
        proto.run_rx();
    }
    proto.run_tx();
}

[lexus2k]

Hi Nico,

Thank you for such detailed logs. I reviewed them, and I am trying to figure out the reason, why for light and fd versions nothing is coming from the board (RX line is silent), but fd version works (a bit slow). I have no idea for now. Waiting for Arduino M0 from aliexpress to debug this issue locally.

Best regards

[lexus2k]

Hi Nico

Finally I've got protocol fixed for Arduino Zero (Cortex M0). I found bugs in memory allocation, and on low hdlc level. Everything is committed right now to master branch. Let me know if something is still wrong. I tested communication on my Arduino Zero (WeMoS) board

Aleksei

[nmaas87]

Hi there,

this is great news :)! I tested it and Light and FD seems to be working, while HD seems to be acting up a bit (still stuck at 8004 bps and I somehow don't think thats really calculated, as I have not seen it change at all).

As I wanted to use FD probably for the final version, I tried it with higher interface speeds as I got some changes in the system and will be needing to use higher serial speeds. (added both baud rates to serial_api.h and switched speed at tools/loopback/tiny_loopback.cpp, then made an make clean and make all in the root directory :))

460800 BAUD Registered TX speed: 50990 bps Registered RX speed: 50972 bps

921600 BAUD Registered TX speed: 50990 bps Registered RX speed: 50972 bps

as these values are also spot on after multiple tests with these BAUD rates + 115200. I pressume the cpu speed maxes out at about ~50990 bps. The Zero is however capable out running 921600 BAUD at ease, tried that already :).

BTW: are the gmon.out files the one you need for debug or terminal output or both? I apply them both here for FD and HD :)

debug.zip

Light

pi@raspberrypi:~/tinyproto/bld $ sudo ./tiny_loopback -p /dev/ttyUSB1 -c 8 -t light -g -r
..............
Registered TX speed: 86622 bps
Registered RX speed: 84646 bps

Code

/*
 * This example sends back every buffer received over UART.
 *
 * !README!
 * The sketch is developed to perform UART tests between Arduino
 * and PC.
 * 1. Burn this program to Arduino
 * 2. Compile tiny_loopback tool (see tools folder) for your system
 * 3. Connect Arduino TX and RX lines to your PC com port
 * 4. Run tiny_loopback on the PC (use correct port name on your system)
 * 5. tiny_loopback will print the test speed results
 *
 * Also, this example demonstrates how to pass data between 2 systems
 * By default the sketch and tiny_loopback works as 115200 speed.
 */

/* !!! WARNING !!! THIS SKETCH ONLY FOR ARDUINO ZERO/M0 !!! */

#define HAVE_HWSERIAL1
#include <TinyProtocol.h>

/* Creating protocol object is simple */
Tiny::ProtoLight  proto;

void setup()
{
    /* No timeout, since we want non-blocking UART operations. */
    Serial1.setTimeout(10);
    /* Initialize serial protocol for test purposes */
    Serial1.begin(115200);
    /* Lets use 8-bit checksum, available on all platforms */
    proto.enableCheckSum();
    /* Redirect all protocol communication to SerialUSB UART */
    proto.beginToSerial1();
}

/* Specify buffer for packets to send and receive */
Tiny::Packet<256> packet;

void loop()
{
    if (Serial1.available())
    {
        int len = proto.read( packet );
        if (len > 0)
        {
            /* Send message back */
            proto.write( packet );
        }
    }
}

HD

pi@raspberrypi:~/tinyproto/bld $ sudo ./tiny_loopback -p /dev/ttyUSB1 -c 8 -t hd -g -r
..............
Registered TX speed: 8004 bps
Registered RX speed: 8004 bps

Code

/*
 * This simple example listens for commands from UART.
 * This is demonstration of Half Duplex protocol.
 */

/* !!! WARNING !!! THIS SKETCH ONLY FOR ARDUINO ZERO/M0 !!! */

#define HAVE_HWSERIAL1
#include <TinyProtocol.h>

void onFrameIn(uint8_t *buf, int len);

/* Half Duplex protocol requires some buffer to store incoming data */
uint8_t buffer[64];

/* Creating Half Duplex protocol object is simple           */
/* Just pass buffer info and callback for incoming messages */
Tiny::ProtoHd  proto(buffer, sizeof(buffer), onFrameIn);

/* Function to receive incoming messages from remote side */
void onFrameIn(uint8_t *buf, int len)
{
    uint8_t tx_buffer[64];
    memcpy( tx_buffer, buf, len );
    proto.write( (char *)tx_buffer, len );
}

void setup() {
    /* No timeout, since we want non-blocking UART operations */
    Serial1.setTimeout(0);
    /* Initialize serial protocol for test purposes */
    Serial1.begin(115200);
    /* We do want to use simple checkSum */
    proto.enableCheckSum();
    /* Redirect all protocol communication to SerialUSB UART */
    proto.beginToSerial1();
}

void loop()
{
    proto.run();
}

FD

pi@raspberrypi:~/tinyproto/bld $ sudo ./tiny_loopback -p /dev/ttyUSB1 -c 8 -t fd -w 3 -g -r
..............
Registered TX speed: 50120 bps
Registered RX speed: 50102 bps

Code

/*
 * This example sends back every buffer received over UART.
 *
 * !README!
 * The sketch is developed to perform UART tests between Arduino
 * and PC.
 * 1. Burn this program to Arduino
 * 2. Compile tiny_loopback tool (see tools folder) for your system
 * 3. Connect Arduino TX and RX lines to your PC com port
 * 4. Run tiny_loopback on the PC (use correct port name on your system)
 * 5. tiny_loopback will print the test speed results
 *
 * Also, this example demonstrates how to pass data between 2 systems
 * By default the sketch and tiny_loopback works as 115200 speed.
 */

/* !!! WARNING !!! THIS SKETCH ONLY FOR ARDUINO ZERO/M0 !!! */

#define HAVE_HWSERIAL1
#include <TinyProtocol.h>
// We need this hack for very small controllers.
#include <proto/fd/tiny_fd_int.h>

/* Creating protocol object is simple. Lets define 64 bytes as maximum. *
 * size for the packet and use 4 packets in outgoing queue.             */
Tiny::ProtoFd<FD_MIN_BUF_SIZE(64,4)>  proto;

void onReceive(Tiny::IPacket &pkt)
{
    if ( proto.write(pkt) == TINY_ERR_TIMEOUT )
    {
        // Do what you need to do if there is no place to put new frame to.
        // But never use blocking operations inside callback
    }
}

void setup()
{
    /* No timeout, since we want non-blocking UART operations. */
    Serial1.setTimeout(0);
    /* Initialize serial protocol for test purposes */
    Serial1.begin(115200);
    /* Lets use 8-bit checksum, available on all platforms */
    proto.enableCheckSum();
    /* Lets process all incoming frames */
    proto.setReceiveCallback( onReceive );
    /* Redirect all protocol communication to SerialUSB UART */
    proto.beginToSerial1();
}

void loop()
{
    if (Serial1.available())
    {
        proto.run_rx();
    }
    proto.run_tx();
}

Best regards :)

[lexus2k]

Hi Nico,

I don't think that speed setup does anything for usbtty on Zero. You observe slow speed for fd protocol, because frame sending happens on both sides in loopback example, and fd protocol always requires confirmation from remote side until it considers that frame is received by remote side. when channel is busy with sending user payload, it takes more time to receive confirmation from remote side. If you send much data from single side only, it will be faster.

This is, what I mean. For example:

#define HAVE_SERIALUSB
#include <TinyProtocol.h>
// We need this hack for very small controllers.
#include <proto/fd/tiny_fd_int.h>

/* Creating protocol object is simple. Lets define 64 bytes as maximum. *
 * size for the packet and use 4 packets in outgoing queue.             */
Tiny::ProtoFd<FD_MIN_BUF_SIZE(64,4)>  proto;

void onReceive(Tiny::IPacket &pkt)
{
// Commented out loopback code
//    if ( proto.write(pkt) == TINY_ERR_TIMEOUT )
    {
        // Do what you need to do if there is no place to put new frame to.
        // But never use blocking operations inside callback
    }
}

void setup()
{
    /* No timeout, since we want non-blocking UART operations. */
    SerialUSB.setTimeout(0);
    /* Initialize serial protocol for test purposes */
   // Works similar for any speed I set here
    SerialUSB.begin(115200);
    /* Lets use 8-bit checksum, available on all platforms */
    proto.enableCheckSum();
    /* Lets process all incoming frames */
    proto.setReceiveCallback( onReceive );
    /* Redirect all protocol communication to SerialUSB UART */
    proto.beginToSerialUSB();
}

void loop()
{
    if (SerialUSB.available())
    {
        proto.run_rx();
    }
    proto.run_tx();
}

./bld/tiny_loopback -p /dev/ttyS8 -t fd -c 8 -g -r

.............. Registered TX speed: 217436 bps Registered RX speed: 0 bps

I will look check your logs in details, and let you know my findings

[nmaas87]

Hi Aleksei,

oh yes you're right, the speed setting for the USB does not change anything on the Arduino Zero, I have read this somewhere as well, but could not point to the source. However, I am using the Serial1 with an external UART USB converter (actually the ESP-Prog, which I can really recommend :)) as this is the way I will use it in the final system. Probably you know this, but the ATSAMD21G18 and ATSAMD21E18 (G with 48 pins, E with 32 pins) - or actually all SAM ARM processors have "Serial Communications Interfaces" called SerCom. These SERCOM Interfaces can be programmed in the bootloader and software for i.e. Arduino to be an UART, I2C or SPI Interface - or generic pins (G has 6 SERCOM, E has 4 SERCOM). If you decide to add an UART i.e., it can be a bit problematic as you have to keep an eye out for adding the relevant IRQ handlers so that i.e. RX traffic is also worked upon by the SAM. In this special case its very easy, as the default configuration of the Arduino Zero is that Serial1 (as one configured SERCOM) is configured by default and no changes is needed by the user, to get it to work out of the box :) - but just wanted to give you some context why i especially test this case, as its more prone to having difficulties as it will probably be less used than i.e. the serial on an ATMEGA or similiar chip. BTW: An awesome read is this tutorial: https://learn.adafruit.com/using-atsamd21-sercom-to-add-more-spi-i2c-serial-ports

Also, you are completly right, I forgot that you will be probably sending a very small payload and hence this is where I was so wrong, as the computational overhead was something I was leaving completly out of the focus. Thanks for pointing it out, I will probably be testing this as well :)

Thanks for your awesome work, its really a pleasure seeing how much the code and testcases have improved over the time, I really hope that many more people will join and use your library, as its really useful maturing really fast 👍

Best regards

Nico

[nmaas87]

Oh and I forgot this website, if this is your WeMos, than Serial1 should be on D0 and D1 :) https://startingelectronics.org/articles/arduino/wemos-arduino-m0/

[lexus2k]

Hi Nico,

thank you very much for the king words, and tons of information, I've got from you. I will continue to improve this library. Of course, it is possible with the help of all users, who give me feedback. For now, the library seems for me too complicated at hdlc level (src/proto/hdlc), I have an idea to remove event groups and mutexes from the lowest level to make it more efficient and usable in interrupt handlers. Maybe, I will move multithread operation to src/proto/light, hd, and fd. Any ideas are welcome. Thank you.

Alexey