Good arguments. Now I'm a bit unsure. Maybe I'll make it configureable
Let the user decide.. recipe for disaster?
I guess it could make sense to secure the whole package with a proper crc even if it slows the code down by 4-8ms.
Thanks for the crc16 code!
When I use that code at 400Bytes it takes ~4ms, crc8 takes ~2.7ms. So kind of acceptable. With only 100Bytes the difference is only ~400us. Guess I could live with that. For 1KB the difference is up to 2ms but that's fine too, sending 1kb doesn't happen often.
Only problem is the use of a list because it will reside in RAM and it's a considerably long list, it taks 10kb of RAM! On an esp32 no problem, if I plan on using an esp8266 it will be a problem.
I tried transforming it into a bytes object so it can stay in flash when the module gets frozen (which the client side will likely not, but at least might be an .mpy).
However, to use it I have to change the crc16 code to correctly read the 2 bytes from the bytes object (since I can't just read 16 bits like from the table can I?), which obviously makes the code even slower and is now 2-4ms slower than the original crc16 code.. So a 400Byte message will take 6.5-9ms with this code.. that is just too long.
So crc16 original has a RAM demand of 10kb and crc16 with table as bytes is very slow..