Writing protocols for bare-metal C

All good points. I think the SDL thing is useful and I can see myself using that. Like you pointed out, there is rarely any implementation or code for protocols so any pointers to relevant info would be useful.

Hi Inderpreet,

Regarding:

there is rarely any implementation or code for protocols

It requires several things usually, and so there's some mix-and-match that can occur, and using features as needed. Ordinarily the bare minimum is the need for a state machine, but also some code that can determine what message is arrived, and in the other direction how to encode for an outgoing message. Also, at a minimum, a function per state to map from what arrived to what needs to occur next. You'll also need (perhaps) a way to handle more than one message or event, and one way is to have a list capability and for your engine to go through each item in the list. And, to stop going insane : ) some logging/troubleshooting capability. You mention bare-metal, but tasks could help (doesn't have to be preemptive), so some OS and middleware is needed, whether you use existing stuff or create bits of your own. There's no single pattern for protocols, but you can get a good idea by looking at similar-complexity protocol open source to see what they used.

I can point you toward an example open source complex system, you're unlikely to want to use it unless it's a major project, but it will give you ideas of the palette of things you'd want to be able to deal with protocols - not all will apply. Also, the example is for C++, and many of the features there won't work the same if you're trying to implement something more cut-down in C. The complex example is Adaptive Communications Environment and it was designed for implementing real-time stuff including protocols, and it's good enough for satellites apparently. I've used it for one project. But, it's large enough that it needs (say) Linux. Looking at that example, you'll get an idea of the types of 'helper' things (for want of a better way to describe it) your embedded code might need to implement protocols. If it's a trivially simple protocol it might not need as much helper stuff.

I understand your inputs are quite useful. I think I have quite a bit of the answer I was looking for and have another question moving forward.

So my take on this has been state machines but with the constraint that most if not all of the code will be non-blocking calls. This means that signals are replaced by Interrupts and there are more than one. I have done projects with more than a dozen tasks running on a controller without the need for a scheduler as state machine calls would be running the main loop and there would be serial, adc, timer and counter interrupts doing things to change states and affect buffers. This makes sure that I can get away with controllers with limited resources as well as have total control over the system. Logging via a space uart is always a good option and the challenge boils down to writing the layers necessary for most of the FSMs to talk to each other. That having been said, my question now is...

What is the standard way of writing code for these projects? Does a good practice even exist and if not then am I over engineering things?

I understand your inputs are quite useful. I think I have quite a bit of the answer I was looking for and have another question moving forward.

So my take on this has been state machines but with the constraint that most if not all of the code will be non-blocking calls. This means that signals are replaced by Interrupts and there are more than one. I have done projects with more than a dozen tasks running on a controller without the need for a scheduler as state machine calls would be running the main loop and there would be serial, adc, timer and counter interrupts doing things to change states and affect buffers. This makes sure that I can get away with controllers with limited resources as well as have total control over the system. Logging via a space uart is always a good option and the challenge boils down to writing the layers necessary for most of the FSMs to talk to each other. That having been said, my question now is...

What is the standard way of writing code for these projects? Does a good practice even exist and if not then am I over engineering things?

Hi Inderpreet,

From what I've seen (could be very different to what others have seen), that is a standard way of writing code, i.e. a big loop in main() in a microcontroller, consisting of all the tasks (say each one being a function call in that loop).

Nothing must take too long, and adding more code in the future will slow the loop rate for all tasks. And use interrupts for things which most override the loop, for example the most time-critical tasks.

This is a very traditional way, but I've seen it deployed for fairly complex products.

But, once you've got more resources and perhaps more complexity in code too, then it can be advantageous to take advantage of an OS. In the past it had to be a co-operative OS pretty much, due to lack of too many resources. For example the original uC/OS was co-operative, I don't know what the later ones are. And, fairly large massively feature-rich network hardware was running on co-operative OS until around 10 years ago. Incidentally, there are maybe a dozen (at least) different flavors of co-operative and pre-emptive, it isn't a binary choice: there are different scheduling algorithms, each with benefits/disadvantages.

Nowadays given the choice some teams will pick an OS and most likely pre-emptive, but that doesn't mean the old methods always have to be thrown out. However moving to a modern OS allows you to not have to reinvent the wheel for things like passing messages, reducing risk of error and crashes. And if the OS comes with features like upgrades then your code can take advantage of them. Usually there's a long list of features, and the things that commonly cause issues in C can be reduced by using the OS features. Plus, anything that reduces lines of code has a chance of reducing bugs. But, on the flip side, the old-school big main () loop is even successfully present in some military gear.. and that has to be reliable too.

There's a lot to be said for the "Superloop plus interrupts" architecture - but like everything it has its place and gets used in the wrong places.

For simple systems it has lots of advantages - not the least is that ALL the code in the project can be known and accessible - which is almost never the case as soon as an RTOS or OS gets used.

It's important no to do too much in interrupts, ideally use them to look after buffering but do as little processing as possible.

MK