Using Adler32 over a four byte payload is a bad idea [1]
This has bitten me personally when designing an embedded protocol that sends 128 byte frames (of which not all are checksummed as those include hop count and checksum) that used Adler32 as checksum. It would not reliably detect a broken packet, so I had to switch to crc32 (for which the STM32 even provides hardware acceleration).
This also told me the lesson of including some option bits for later use to make the upgrade process less painful…
Wow, this looks really great for things like modular nodes in remote areas! It does seem like this is sort of a weird comparison to make, though:
>It needs about 3% of the RAM found in a traditional Arduino like the Duemilanove, and it processes each heartbeat message in about 256 instruction executions (about 30 nanoseconds on a 1.6GHz N3700).
The Duemilanove uses a 16MHz ATMega328, so...16 microseconds? Still pretty good for a power-efficient setting, as long as you have separate listening/caching hardware for each individual high-speed signal.
The author works for a micro-satellite company. I dunno what that implies for this particular project -- is this level of stinginess important or just nice to have? Back in college I considered joining a student satellite project where the processor had just a few hundred bytes of RAM, but that was in the 80s.
I don't know for sure, but i do know rad hardened electronics are a lot more expensive. Older gear with bigger gates, slower clocks, all that stuff is more tolerant of a stray cosmic ray. which you'll get all the time in space. in a microsatellite, not much room for shielding. so i'd bet they just have to be really stingy.
My space engineering professor says for what he does (microsatellites mostly, but some science instruments for bigger satillites) they use off the shelf non-radiation hardened parts mostly, and get their reliability though software and hardware redundancy.
Rad hardened is only for GEO or long term missions. If you're throwing cube sats, or other micro (maybe even a small) sats, you're going to use off the shelf hardware. If you're worried, throw a little polyethylene around it. First few mm are going to do the majority of shielding. But at these low altitudes you're not going to get many bit flips and semiconductor damage isn't a concern because the low lifespan of the satellite. For the little errors you get, you can always reupload software, which you check on large or small satellites.
Hey yeah, good point - I'll bet they do have a high-speed central processor for the whole engine-control/user-interface stuff, but they also probably have a lot of far-flung modules operating in very rough environments for a signal going over a long wire. And I guess the figure does say 'Car' and 'ECU' a lot...
It looks to me like this code will read off the end of short packets; the actual library interface (dumpulse_process_packet) probably needs to take a length, and sanity-check it.
Yes, there seems no length checking at all. All is assumed. Even on CAN you can't expect to receive only 8 bytes, because with a CAN FD controller it can be now 64 bytes.
That is some of the best documentation I’ve ever read. Clear, concise, and with just enough context and additional explanations to make the whole thing effortlessly readable.
The git commits are associated with "<user@debian>" rather than a valid github account. Whoever made the commits probably did not set up their git authorship information correctly on the machine where the commits were made.
This has bitten me personally when designing an embedded protocol that sends 128 byte frames (of which not all are checksummed as those include hop count and checksum) that used Adler32 as checksum. It would not reliably detect a broken packet, so I had to switch to crc32 (for which the STM32 even provides hardware acceleration).
This also told me the lesson of including some option bits for later use to make the upgrade process less painful…
[1] https://en.wikipedia.org/wiki/Adler-32#Weakness