Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Coding Flows

Status
Not open for further replies.

StudentSA

Member
Hey Guys/Gals.

More of a discussion type question, Id like to know in sudo code terms what the best/most accepted way of writing micro controllers coding loops.

A micro will typically have inputs both digital and analog, with outputs to control displays, motors and relays.

How do we handle the main high level code loop? Is it as simple as read all inputs, process, apply all outputs. Or is it read one input, process that data and change the corresponding output; repeat?

I tend to easily get my code very messy and confusing.

Thoughts?

Thanks,
StudentSA
 
My high-level loops in my controller code often look like this:
Code:
Main  goto Main;

The inputs are handled on one set of interrupts, the outputs on another, I process the data on or the other of those. Typically there will be one interrupt that has to run fast and unencumbered - maybe an input (realtime A/D), maybe an output (bit-bang PWM) and that goes in a high-priority interrupt. I put any time consuming processing somewhere else - sometimes in the Main loop, but usually just in another interrupt.
 
Hi
In a simple application (few inputs/outputs) your first suggestion is probably most applicable. On the other side of the scale an application with many inputs/outputs (and most of them with different processing/timing requirments) you will find an operating system (RTOS) will go a long way towards helping to keep things orderly, and simpler.
 
Typically each function which changes an output, sends data to a display, sends data via a serial port, etc etc...is canned as a subroutine. Inputs are monitored in a continuous "forever loop", and each subroutine is called upon a state change occuring at an input. Once the subroutine is completed, it returns back to the main loop where it continues to poll the inputs waiting for the next state change.
 
How do we handle the main high level code loop?

You need to "handle" the low level stuff into well defined modules. In C, a module is usually a single source file (and the accompanying .h-file). I think the best design practices for modules are "single responsibility" and "dependency injection". Single responsibility is quite self explaining, but "dependency injection" is more advanced design pattern from the Object Oriented world, but it can be applied to C-programs to some extend. The goal is to separate the hardware related stuff, communications etc. from the "business logic". When you design good modules that you can use, reuse, and replace easily, your main high level code loop becomes trivial (and simple). As it should be in large programs.

If you google "dependency injection" and read some articles, it will probably be very confusing. But, the basic idea is very simple. When you initialize a module, you would have to create and pass it all the dependencies it needs. Modules should only deal with their given area of responsibility, without concerning themselves with how dependencies are created.

For example: If you initialize an UART communication module, you would first initialize a FIFO buffer (module) and pass that to the UART module as a dependency. You do not want to write an UART module that handles the FIFO initialization implicitly.. That would lead to messy and hard to maintain code. When you have all these well written modules, all you need to do is to "compose" the application at the "composition root".. which is the main() function.
 
Last edited:
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top