Downsides of software serial libraries
Closed this issue · 11 comments
The default Arduino SoftwareSerial library proved to be non-tolerant with simple libraries when used for BLE communication, even more so with fairly complex libraries on top of that.
We switched to Paul Stoffregen's AltSoftSerial library and things have been great... till now. From the documentation:
Interrupt Latency Requirements
AltSoftSerial can withstand approximately 1 bit time of interrupt latency from other libraries or functions. Most libraries, HardwareSerial, and the millis() timekeeping interrupt are designed to minimize CPU time spend executing interrupts or accessing data with interrupts disabled.
However, some libraries may disable interrupts for longer than 1 bit time. If they do, AltSoftSerial will not work properly. If you discover erroneous results from AltSoftSerial, please try testing without other libraries.
SoftwareSerial would break with relatively low complexity I2C communication using Arduino's Wire library, it proved impossible to use with the AD5933 library for similar reasons.
AltSoftSerial works very well in this regard, but as we begin to write multiple sampling rates and frequency sweeps that request timer interrupts and reset commands to the AD5933 more frequently, the time window for interrupts to be handled shrink considerably.
With the sketch BLE_Debug_Timer that just carries a psuedo sine signal, setting a sampling rate of 90 Hz is no issue. Z_BLE_3 however that has to measure and send impedance values, breaks at sampling rates over 80 Hz and completely garbles serial communication with AltSoftSerial library, you only need to look at Arduino's serial monitor to see the gibberish it spouts and functions it calls that it really shouldn't.
We therefore probably need to move to the Arduino Mega for development and use the multiple hardware serial port it provides for BLE communication.
All this of course is a working hypothesis, I will be testing my claims tomorrow in lab, but I'm fairly certain they're right from past experience with SoftwareSerial and AltSoftSerial.
On we go again.
Can you please clarify the following:
- Is the maximum we can get while changing impedances 80 Hz under the best of circumstances (and only getting worse with increasing interval changes)? For instance, if we just went with 50-60Hz continuously, would this be stable? What about 'lower' values like 30Hz?
- Is it gibberish regardless or does it become gibberish at higher sampling rates?
- Are there other serial libraries we could potentially use? Is there anyway we could debug the currently library to suit our needs? We can always fork their work.
Let me know.
Sure.
- At 30 Hz, things run okay but once in a while you'll notice erroneous values come through. For example a variable that has the same value written to it all the time (zero), will once in a while have 15, 23 or some random number written to it. At 50 - 80 Hz it becomes more common, the value set to zero will spike in value every 5 seconds or so, and above 80 Hz, the connection will break and data will cease to be sent to the phone.
- The gibberish in the serial monitor only happens when the connection never initialized, or after it breaks. So at 1 - 80 Hz, the serial monitor is accurate, but there will be random inaccuracies in the data transmitted.
- AltSoftSerial is the current choice as it uses the high resolution 16 bit timer. There's another one out there, but it isn't packaged as a library, but as a sketch and it uses an 8 bit timer. It will have the same issues AltSoftSerial will have with no clear advantages.
@ 75 Hz. The gold spike to the left is at the value that 0 is supposed to be written to all the time.
@ 50 Hz. Random spikes.
FYI: Arduino Uno board (TinyDuino) has 1 hardware UART. (It make things little bothering if we use it because we need to detach the wires on Pin 0-1 to program the MCU (microcontroller.)
I realized, that's why I decided to test on the Mega tomorrow.
To reply @tunjid
- I mean we can use UART of Arduino Uno. Did you mean that one hardware UART is not enough?
- This bug partly from not adjusted cycles value of AD5933. I am working on fixing it.
@itkwon
Oh I understood that's what you meant, what I mean is that having to rewire pins 0 and 1 for software uploads and bluetooth communication would be tiring. We also won't be able to debug through the serial monitor that way.
It's easier to just try with the mega and see if it is indeed the serial library again.
Okay.
Just tested a minute ago and the hypothesis is confirmed. When the hardware serial of the Arduino Mega is used, there are no more random spikes and everything works as it should even at 90 Hz.
The final hardware can still be based on the ATmega328 as there will be no need for debugging to the serial monitor in final hardware. The custom PCB will just have to be designed to let us short the connection to pins 0 and 1 to let us upload sketches when we need to.
Good.
Hypothesis confirmed, hardware serial does not have any random spikes and is generally more robust. Custom build should still be based on the Uno, but with workarounds to short pins 0 and 1 for BLE communication and sketch uploading. depending on circumstance