silentbicycle

The previous post: https://spin.atomicobject.com/2015/02/26/uniprocessor-schedu...

and discussion: https://news.ycombinator.com/item?id=9112930

Fixed, thanks.

Also, "Uniprocessor Garbage Collection Techniques" (https://ritdml.rit.edu/bitstream/handle/1850/5112/PWilsonPro...) is a great survey paper, and _The Garbage Collection Handbook_ by Jones, et. al (http://gchandbook.org/) is an excellent book covering the field as of pretty recently.

But, isn't accessibility excruciatingly important here?

This post (http://modelviewculture.com/pieces/it-s-not-you-it-s-the-sys...) mentions many ways well-intentioned projects can miss the mark, because of these kinds of issues.

There's value in knowing how it's implemented.

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

Software Defined Radios are also fascinating! That's a very different post, though. :)

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.

Excellent, thank you. Those also compile differently for me, so it probably appeared in a newer version of gcc.

Would you mind elaborating on that? I don't see this behavior with GCC 4.2.1 on OSX or OpenBSD at -O3 when I look at the disassembly.

You might want to read this, then: http://exple.tive.org/blarg/2013/10/22/citation-needed/

That did speed things up a bit further: https://github.com/atomicobject/heatshrink/commit/38b8025895...

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.

I realized yesterday that it can also be used as the basis for a linear-time sorting algorithm: https://gist.github.com/silentbicycle/8389129

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.

I think it could work like this:

    SUITE_LIST(suites) {
        suite1,
        suite2,
        // ...
    };

    GREATEST_MAIN(suites);

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.

Also, a minor nitpick: the 591 line header is the whole thing. The 133-line .c file is only an example.

Unity alone doesn't, but ceedling and CMock do. I was referring to them as a group, because I usually see them used together, but you're right.

(I work with most of the maintainers of those tools, and have some minor commits myself.)

In my experience, unit testing is more common in embedded C development, because the code is held to much higher standard of accountability.

Sloppy embedded code can kill people, or at the very least lead to incredibly expensive hardware recalls. With the exception of poorly thought-out privacy policies, it's unlikely that errors in a web app can cause that level of problems.

It's also much easier to deploy an update to a web app than a Mars rover or a car's brake controllers.

Thanks!

I use GREATEST_MAIN_BEGIN and GREATEST_MAIN_END so that people can put other things in main, around them. Also, there are often several RUN_SUITE calls, and I can't depend on vararg macros portably without also depending on C99. While there are some ways to work around that, they don't deliver enough value to justify the added complication.

I'm been thinking about ways to get around this. I'm using macros for __FILE__ and __LINE__, but it does interfere with breakpoints.

One of my open issues is to add an ASSERT_EQ_MEMCMP function that does print out the difference, probably as a hexdump. Similarly, greatest could have something like 'ASSERT_EQ_NUM' for the cases where printing the value is meaningful, and an ASSERT_EQ_STRUCT that takes cmp and print functions. I've been thinking about it for a while, because I want to get it right before I change the API.

Knowing that a change broke a specific set of tests tells you a lot more than knowing it broke the first one of them that happened to run.

If I'm using fuzzing to run thousands of tests, and all the ones whose seed led to the same specific bit pattern are failing, that's particularly useful information. I found a particularly subtle bug in heatshrink (https://github.com/atomicobject/heatshrink) that way, but a single failing test would have looked like noise.

I have not, but I'll check it out, thanks.

They've got a lot in common. tinytest looks a bit simpler, but also doesn't do any allocation and looks reasonably portable. Cool.

The single biggest difference is that greatest has more control over about which test(s) it runs. tinytest just bails at the first failure, whereas greatest can run everything and report, or individual test(s) or groups of tests whose names match a substring. That adds some to the implementation, but I've found it particularly valuable once a program has several modules and hundreds of tests.

Also, greatest supports parametric testing, which means that adding fuzzing/randomized testing is pretty straightforward (though usually project-specific).

tinytest requires C99, greatest doesn't. That shouldn't matter, but unfortunately sometimes it does. Embedded compilers for proprietary architectures can be lacking, in particular.

greatest also doesn't assume ANSI escape sequences are okay. Sometimes dumping out a bunch of [1;31m stuff is annoying. That's a matter of taste, though, and it'd be easy to make it optional.

fff looks cool, too. Thanks! I'll check it out. :)

I've tended to use CMock (https://github.com/ThrowTheSwitch/CMock) for mocking, though it depends on some Ruby-based tooling. The last time I looked into replacing CMock I wound up hip-deep in the binutils. (It was fun when I stopped getting google results from StackOverflow and started getting them from Phrack, though. ;) )

I've seen people do that before, as well as putting the tests in the .c file, guarded by "#if TEST_MODULE_NAME", and exporting a (module_name)_run_tests(void) function.

My preference is to have separate test_module_name.c files. Failing that, I would include tests in the module's .c file rather than the header, so that the header can be relatively short and focused on documenting the module's interface, rather than its implementation details.

greatest doesn't force any specific style there, by design.

Author of greatest, here.

I wrote a blog post about it a couple months ago: http://spin.atomicobject.com/2013/07/31/greatest-c-testing-e...

I (the author) have been doing a lot of embedded development lately, and in those cases you really can't assume very much beyond core ANSI C features. That's also why greatest doesn't do any dynamic allocation, at all. There's a relatively small struct for the current testing progress, and everything else can easily run out of ROM.

My primary goal with greatest is to assume as little as possible, and avoid imposing any additional constraints on projects just because people want to test them. I also want the implementation to be very transparent -- it's just a 600-ish line header file, carefully documented. It's a major pet peeve of mine when I have to work around features that try to automatically be helpful, but have edge cases that break down in opaque ways. (Build systems tend to be particularly bad in that way.)

Also, I'm beyond shocked that the name wasn't already taken. ;)

One of my upcoming tasks is making stdio optional in greatest, because printf doesn't do you a whole lot of good if you're running it on an Arduino or something, but in those contexts automated testing is especially valuable.