Reliable SoftwareSerial

[eloquentarduino]

I'm using an Attiny1616 to communicate with a serial AT device at 9600 baudrate. The sketch is almost like the SerialEcho, but it sends commands automatically and awaits a few seconds for a response.

The problem is: sometimes it works, sometimes not. By "works" I mean the peripheral replies correctly to AT commands. By "not works" I mean I get no response at all.

By "sometimes" I mean:

1. I upload the sketch, open the Serial Monitor and the peripheral is responding
2. I disconnect power, re-power, open the Serial Monitor and the peripheral is not responding

Point 2. may happen after the first power disconnection or second, but once the peripheral starts not responding, there's no way I can reliably make it respond again. The day later maybe it starts responding again for 1-2 power cycles.

If I communicate with the peripheral via Hardware Serial (the Serial object) and use SoftwareSerial for debugging (via a chinese USB-to-Serial adapter), it works fine all the times (both the device responds to all commands and I get all the debug messages).

Is there anything I can do to reliably get it working?

[hmeijdam]

A sim card module? How are you powering that. They need a 2A powersupply at times.

[eloquentarduino]

A sigfox module. It only draws 10-15 mA while not transmitting. I power it with a LiPo battery or the 3.3v of the USB-to-Serial.

Il gio 25 gen 2024, 13:09 Hans @.***> ha scritto:

A sim card module? How are you powering that. They need a 2A powersupply at times.

— Reply to this email directly, view it on GitHub https://github.com/SpenceKonde/megaTinyCore/issues/1051#issuecomment-1910074989, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOA7GNOKOD6IYGJK4NT3RI3YQJDQVAVCNFSM6AAAAABCKIVNEGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJQGA3TIOJYHE . You are receiving this because you authored the thread.Message ID: @.***>

[SpenceKonde]

brief powercycles on modern chips can sometimes fail to naturally let the voltage fall enough to rearm the POR, and one or both chips may not actually receive a clean reset. This can typically be tested by hand by simply shorting the power rails after disconnecting power, and then reconnecting power normally. More sophisticated setups have the main chip controlling power or reset lines for the external peripherals and/or take more sophisticated power staging measures depending on the complexity of the system. You want to either A) ensure with BOD that that which causes a peripheral reset will also cause a chip reset, and set the SUT or use an early delay to ensure it waits long enough for the device to be ready or B) Have the chip control the reset lines of it's connected devices, so it can reset them whenever it starts up, and wait long enough that we expect there to be successful communication

For further debugging, scope trace would be useful to give and idea of what software serial is doing wrong. Software serial really isn't fit for purpose, and I consider it such an abomination I don't really want to try to replace it, with something that sucks slightly less (it will never be good, but it can be made better (though any route to acceptable behavior vis-a-vis attachInterrupt (which any implementation that isn't garbage will be forced to be incompatible with, even though it only would need to take over a single vector) is going to be a flaming bitch cause we gotta make winterrupt not take over that vector because the ISR for a runtime configured attach interrupt is still too slow after I rewrote it in asm....

[eloquentarduino]

Ok, too complicated for me, sorry. I'll go on using Hardware Serial for peripheral communication and Software Serial for debugging.

Thanks for your valuable time.

Il gio 25 gen 2024, 18:58 Spence Konde (aka Dr. Azzy) < @.***> ha scritto:

brief powercycles on modern chips can sometimes fail to naturally let the voltage fall enough to rearm the POR, and one or both chips may not actually receive a clean reset. This can typically be tested by hand by simply shorting the power rails after disconnecting power, and then reconnecting power normally. More sophisticated setups have the main chip controlling power or reset lines for the external peripherals and/or take more sophisticated power staging measures depending on the complexity of the system. You want to either A) ensure with BOD that that which causes a peripheral reset will also cause a chip reset, and set the SUT or use an early delay to ensure it waits long enough for the device to be ready or B) Have the chip control the reset lines of it's connected devices, so it can reset them whenever it starts up, and wait long enough that we expect there to be successful communication

For further debugging, scope trace would be useful to give and idea of what software serial is doing wrong. Software serial really isn't fit for purpose, and I consider it such an abomination I don't really want to try to replace it, with something that sucks slightly less (it will never be good, but it can be made better (though any route to acceptable behavior vis-a-vis attachInterrupt (which any implementation that isn't garbage will be forced to be incompatible with, even though it only would need to take over a single vector) is going to be a flaming bitch cause we gotta make winterrupt not take over that vector because the ISR for a runtime configured attach interrupt is still too slow after I rewrote it in asm....

— Reply to this email directly, view it on GitHub https://github.com/SpenceKonde/megaTinyCore/issues/1051#issuecomment-1910717668, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOA7GNJ4KHOWGDG73WLDU6DYQKMNRAVCNFSM6AAAAABCKIVNEGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJQG4YTONRWHA . You are receiving this because you authored the thread.Message ID: @.***>

[SpenceKonde]

That would be my recommendation.

I'm guessing that there's a collision of (it's sending, and then a byte arrives while a byte is being sent, mangling both, and leaving the external device in a hosed state. until power cycle.

You always want to have the least picky device, on the software serial port, especially the implementation Arduino provides (though as I said, I do not belive a 'good' implementation is possible). Things that can go comatose if bad commands are sent should never use software serial, because of this kind of crap - the fact that it has to do everything by timing everything with a stopwatch while paying undivided attention makes serial behave a lot worse than when it runs in the background on the hardware ports.

[SpenceKonde]

Closing unless/until someone can propose a plausible route to improving behavior without breaking compatibility; I do not think this issue is new, and I don't think its specific to these parts. The largest problems with SoftwareSerial are inherent to general case software serial implementations. Specific case ones limited to an arbitrary set of pins would work very well. But by the time you've generalized it to work on any pins, across any baud rate without modifying library files to make it work, performance and reliability suffer.