3 ms·
Yes I wonder what was wrong with the C code. Was it fixable, was it just a single loop code that ran or could they have used something like FreeRTOS to handle m
by sgt 2y ago
Yes I wonder what was wrong with the C code. Was it fixable, was it just a single loop code that ran or could they have used something like FreeRTOS to handle multiple tasks with less chance of bugs?
- RandomThoughts3 2y agoI would have liked to have more details because it's easy to have memory related issues when using a serial protocol in a memory constrained environment and I was wondering if somehow some feature of Rust helped them. I would guess that the more expressive type system is very nice but I don't expect memory safery features to be that useful in this context. Would like to hear from someone with real world experience on that.
- lsllc 2y agoIf you're parsing a serial protocol on an embedded system where you're only getting a byte-at-a-time (from a register), or possibly up to 8 at a time, then a parser combinator library such as nom should make it very easy to create a bulletproof parser. Definitely much easier than in C, where I've resorted to using Ragel for safely parsing serial protocols (and also in Go!) since it generates a single small dependency free source file containing the state machine and your "actions", but nom is much more expressive.
- RandomThoughts3 2y agoDeeply doubt so. Parser combinators are notoriously poor performance and memory-wise. They are somewhat nice to write if you like the style and don’t mind the tax but we are talking about ESP32 here. Unless they are inexperienced, the issue is unlikely to be the state machine anyway and more likely to be in how they manage buffering of long message to avoid running out of RAM.