TasmotaSerial: Reduce IRAM usage by 280 bytes and improve reliability at 115200 bauds (v2)

[s-hadinger]

Description:

Second try, replaces #6373, 9600 baud tested by @Jason2866 (thanks a lot)
Improvements to TasmotaSerial

• Leverage attachInterruptArg() from STAGE and pre-2.6, removes the need for multiple interrupt functions, saves 224 bytes of IRAM
• pre-compute m_bit_start_time time for first byte, instead of computing it in the interrupt handler
• removed optimistic_yield(1) from the interrupt handler, optimistic_yield is not in IRAM, I'm not sure it's safe to call it from the interrupt handler. Anyways, low baud (9600) should use the nw option.
• changed while (ESP.getCycleCount()-start < wait) to while (ESP.getCycleCount() < wait + start), the addition gets out of the loop (minor change)
• removed first digitalWrite(m_tx_pin, HIGH);, if the output is not already in HIGH mode then it's too late to change it (Am I missing something?)
• when sending, re-enable interrupts at the beginning of stop bits, instead of after stop bits. Total time won't change but it allows other interrupts to be served earlier

I did lots of tests with Zigbee and discovered that sometimes bytes were misread. What happens is that when receiving a row of bytes, interrupts are disabled for each byte, re-enabled after stop bit and disables again for next byte. This short window would allow other interrupts to fire and delay enough the Serial interrupt that the first bit would be missed.
I changed so that the interrupt handler wait for 3.5 stop bits if the next message is already there. If so it continues to read it without lifting interrupts, if not it re-enables interrupts.

Overall I saw a huge improvement in reliability when receiving at 115200.

Overall IRAM saving: 280 bytes

Theo, I didn't change the TasmotaSerial verion number.
I hope I did not change the behavior at lower baud rate, this might need some more testing.

Checklist:

• The pull request is done against the latest dev branch
• Only relevant files were touched
• Only one feature/fix was added per PR.
• The code change is tested and works on core 2.3.0, 2.4.2 and 2.5.2
• The code change pass travis tests. Your PR cannot be merged unless tests pass
• I accept the CLA.

[arendst]

Still errors with my PzemAc:

17:57:25 DMP: 01 10 84 F7 6D 00 FA 00 46 05 00 40 00 16 00 46 FA 00 00 00 00 00 00 00 F0 A7
17:57:25 DBG: PzemAc response error 8
17:57:26 DMP: 01 10 84 F7 6D 00 FA 00 46 05 00 40 1F 64 00 AD 00 00 00 00 00 00 00 00 F0 A7
17:57:26 DBG: PzemAc response error 8
17:57:27 DMP: 01 10 84 F7 6D 00 FA 00 46 05 00 40 1F 64 00 AD 00 00 00 00 00 00 00 00 F0 A7
17:57:27 DBG: PzemAc response error 8
17:57:28 DMP: 01 10 84 F7 6D 00 FA 00 46 05 00 40 1F 64 00 AD 00 00 00 00 00 00 00 00 F0 A7
17:57:28 DBG: PzemAc response error 8
17:57:29 DMP: 01 10 84 F7 6D 00 FA 00 46 05 00 40 00 16 00 46 FA 11 91 00 00 00 00 00 70 7E
17:57:29 DBG: PzemAc response error 8
17:57:30 DMP: 01 10 84 F7 6D 00 FA 00 46 05 00 40 1F 64 00 AD 77 95 95 00 00 00 00 00 58 82
17:57:30 DBG: PzemAc response error 8

For now I leave it merged and see what others experience.

[s-hadinger]

Do you know which bits are wrong? Is there any pattern?

Also are you running at 80 or 160 MHz?

What's strange is that the receive code for nw=1 didn't change at all.

[arendst]

Receive code for nw 1 was just added by gemu. Other than his smart driver it is not used

I'm in quality time now. Will continue tomorrow.