BTW, I just reread the docs and found this
The documentation is generally very good, however there is a huge amount to process, esp. if (like me) you have just recently joined the ecosystem. That’s why this forum is invaluable as you can lean on the experience of folks like @rickkas7 and @ScruffR (and many others) to bootstrap your knowledge.
I use a static char array in my Serial1 reading function and return asap to loop() - my use case is convenient in that I have a known inter message gap of 2 seconds, so once i get my end of message flag, I have 2s to do the rest… Serial does require careful planning (unless you use the hardware handshaking which makes it much easier - but this is not available if using an Ethernet wing as well - although you can use another IO to create a simple “Ready to receive” indicator)
That's a good basis and considerations like that were also the reason for asking the OP these questions
If you know your data is coming in "slow" with definitve boundaries (time-sliced or marked) things become easier.
However, depending on your code running during the pause, time-slice bounds may wash away if something unexpected happens (e.g. sensor libraries "silentry" retrying their tasks, communication outages, ...).
1 Like
My use case is mostly gathering environmental information on a Photon and sending it to the cloud if there is Wi-Fi, with an occasional instruction from the web to close or open one of the four relays on the relay shield. The problem is that some of these Photons might lose Wi-Fi due to circumstances beyond our control or actually be installed where there is no Wi-Fi
My idea was to tunnel messages through a Boron to the web and permit relay control in the other direction if there is no available Wi-Fi or if the Photon loses it for some reason. It may end up being not necessary to use Wi-Fi at all as we are not really sending or receiving much data.
I just recoded my library to handle 54 byte messages in either direction—they don’t need to be large—with control flow markers and a checksum and not using the String class and it seems to be working well with the use of SYSTEM_THREAD(ENABLED) and int len = Serial1.readBytesUntil( EOT, receivedBuffer, BUFFER_LEN ), so I appreciate all the help here. I also bumped the baud rate up quite a bit to get those 62 bytes (with all the things) transferred in the blink of an eye.
Regarding the documentation, the simple addition of class hierarchy, something as simple as “inherits from X” would be greatly helpful, as is standard with most frameworks. Then you know you can go check out X and see what else this current class is capable of doing without you having to study the entire framework as a whole to figure out the relationships the hard way.
Regarding the SerialEvent documentation, I understood that I could be blocked for a time, but it’s written in a way that makes it seem that it will eventually be called (in a few hundreds or thousands of milliseconds later), with the data sitting there waiting to be processed. Folks here were talking as if I am going to be losing data right and left, but that might be because the assumption is that I am sending a lot of data from device to device. My use case is much less and I don’t mind being made to wait a few seconds as I am not spamming the serial comms with a steady stream of info.