
An embeddable dumb heartbeat daemon in 260 bytes of RAM and 350 bytes of code - luu
https://github.com/kragen/dumpulse
======
pantalaimon
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…

[1]
[https://en.wikipedia.org/wiki/Adler-32#Weakness](https://en.wikipedia.org/wiki/Adler-32#Weakness)

------
leggomylibro
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.

~~~
microcolonel
I found that comparison pretty funny too.

To me it was more amusing to see open source from... presumably the automobile
recovery and monitoring industry. A first for me, to be sure. :- )

~~~
abecedarius
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.

~~~
jfoutz
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.

~~~
NateyJay
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.

------
tptacek
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.

I only looked for a moment and might be wrong.

~~~
PinguTS
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.

------
1_2__4
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.

------
andrenotgiant
Why is there no user associated with the github commits? I've never seen that
before.

~~~
Figs
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.

------
pvdebbe
Which 350 bytes of code is the title referring to? All files are larger than
that. The resulting binary code maybe?

~~~
tbodt
Yes

------
oftenwrong
>but Kragen Javier Sitaker wrote Dumpulse, so the deficiencies of the design
and implementation are all his.

------
emilfihlman
What does the author mean with mHz?

~~~
juliangoldsmith
Probably milliHertz. 100 mHz would be 1 pulse every 10 seconds.

