Tasmota
Tasmota copied to clipboard
arendst
Please review: SML: FastExit for binary SML parsing
Description:
I noticed a high load (~170) and slow FPS on the connected display (240x240 ST7789)
With this PR I tried to improve the SML parsing for binary SML data, which seems to have some room for improvement.
As far as I understand the binary parsing, there is a buffer, where each byte is added at the end of the buffer and then the buffer is shifted one byte to the left. After each byte, SML_Decode is called, which parses the the descriptor each time and checks if one line matches with the buffer. (@gemu2015 is this correct?)
In my case I have 3 Logarex LK13BE606739 meters, where each transmits ~660 bytes each second. My descriptor has ~ 60 lines, which means that SML_Decode is called ~2000 times/sec. and it will parse and check each line in the descriptor.
As far as I see, all SML messages in binary mode will start with 0x77, so I thought, it could be a good idea to implement a fast exit, and start decoding only, when the buffer starts with the sync byte, which makes the decoding a lot of faster. (0x77 occurs 23 times in my test sample of 660 bytes)
To test the improvement, I bound this to flag 32, but I want to discuss, if this could be the default. (is 0x77 really a sync byte?)
This change reduces the load from 170 to 100 and gives some extra frames on the TFT
Roland
Related issue (if applicable): fixes #<Tasmota issue number goes here>
Checklist:
- [x] The pull request is done against the latest development branch
- [x] Only relevant files were touched
- [x] Only one feature/fix was added per PR and the code change compiles without warnings
- [ ] The code change is tested and works with Tasmota core ESP8266 V.2.7.6
- [ ] The code change is tested and works with Tasmota core ESP32 V.3.0.0
- [x] I accept the CLA.
NOTE: The code change must pass CI tests. Your PR cannot be merged unless tests pass
that seems to be a good improvement. i would suggest to make this the default und invert flag & 32 as i also assume that 0x77 is always present.
I've modified the PR a bit. I still have to test this and provide a PR for documentation update...