I decided against software USB because the receiver is already spending much of its time trying to meet the real-time limits from the radio decoding, and the USB would be its own big undertaking.
As I stressed in the preceding post (http://spin.atomicobject.com/2014/05/16/radio-system-from-sc...), I'm intentionally doing these things the hard way, so I can learn how more of these things work at a deeper level than "use built-in functionality, configure to run at this baud rate, done". Otherwise, yeah, I'd use a 32-bit ARM chip and a better SMD transceiver. :)
Hello, author here. As I said, mostly stressed in the first post, I'm doing things the hard way as a learning exercise, building a bunch of infrastructure myself. I would use a better radio transceiver and a chip with actual USB and UARTs, etc. if it wasn't a self-study project. :)
There's no way to know that the payload has been received - they're transmitters, not transceivers. The messages are idempotent anyway, so just retransmitting makes the whole system simpler.
Thanks for letting me know. I made sure the ATtiny84s could be re-flashed in circuit in case something like this came up. (I also have 315MHz modules, and will prefer those in the future. Swapping out the transmitters and receivers will only take a bit of resoldering.)
Short names also make sense if the same conventions appear over and over throughout the code base. While they can be quite opaque at first, they're very consistent, and people with experience in other APLs will recognize many of them.
Good idea! I'll try it out later, thanks. Kind of a variant of Boyer-Moore. I had thought about BM, but ruled it out because the search string length isn't fixed.
Thanks! There are much better indexing algorithms if you don't have such tight resource constraints, but it may be a useful trick to speed up inner loops in some other algorithms.
Benchmarking indicates that it's probably not competitive speed-wise compared to counting sort (of which it is a variant), but the implementation should be pretty easy to understand. It may be good for pedagogical purposes.
but, again, I don't know if that's necessarily an improvement. RUN_SUITE is encapsulating saving the suite's name, optionally only running suites with names that match a certain pattern, and some other features that become tricky to implement with just a statically allocated function pointer array. I'm also trying to avoid doing anything "clever" with macros.
and discussion: https://news.ycombinator.com/item?id=9112930