Actions
Forum Thread Details
  • Replies 18 replies
  • Subscribers 449 subscribers
  • Views 2004 views
  • Users 0 members are here
Related

Writing protocols for bare-metal C

ipv1

Over the years, I come across the need to connect sub systems together with the like of UART, I2C, CAN, LIN, RS485, MODBUS and what not. A few years ago, I also wrote about implementing custom protocols that are simple versions of the previously stated ones and recently jumped into a project that uses a custom LIN implementation. By custom, I means that it does not follow the rules or LIN in terms of communication but uses the same electrical base and some other pieces.

 

The existing code base is heavily reliant on the processor registers etc and the guy who wrote it can't/won't explain the structure of the system as a lot of it is unplanned, undocumented patches. It works but its a lot of C code mixed with "other things".

 

My question here is about a standard way of writing things like these. I am talking about implementing multi-byte exchange protocols and what should be the do's don't, correct way, though processes, etc when writing this stuff. Finite state machine code with non-blocking code is where I usually land but I want your thoughts on the process.

 

What is your way of writing protocols without an OS and how would you accomplish multiple tasks with out the scheduler?

Parents

  • I worked intensively on a multi-protocol communications device with (thank God) no operating system.  It was basically the approach described by Michael Kellett:

    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.

    Our basic data unit was a "buffer".  Input data went into a buffer using DMA and when the buffer was "complete", which meant different things for different serial protocols, an interrupt would occur and the ISR (interrupt service routine) would append the buffer to the "Action Queue" for processing by the main loop.  The main loop, which ran in foreground, would grab the next buffer from the Action Queue, perform the action indicated by a 16-bit action number, and then queue up the buffer for a different output port or return the buffer to the free buffer list.

     

    We also had a timed events.  These were handled by an "event wheel", a technique used in event-driven logic simulation.  The main loop would see if any timed events needed to be processed and did it before the Action Queue.

     

    As Michael points out, bare metal programming means you have all the source code so you can track down bugs without wearing a blindfold.

     

    You learn lots of interesting things programming at the bare metal.  One bit of fun was when we ported the software from Motorola 68020 to PowerPC.  The 68020 has an atomic memory increment instruction implemented with a non-interruptible read/modify/write.  The PowerPC does this with three instructions: Load, Increment Register, and Store.  If an interrupt occurs in the middle of this and the ISR modifies the same shared variable, you can get a nasty result.  This has a low probability of occurrence, which makes debugging nasty.  The error is happening at the machine language level, so programmers who only know high-level languages don't understand how it could be happening.

     

    Management was always trying to replace the bare-metal code with an operating system.  I always fought against it.  After I left the company they did the operating system thing.  It took a couple years to get going and required at least twice the memory.  Think about it: there's no way that adding an OS is going to make your code run faster or smaller, right?

  • in reply to johnbeetem

      wrote:

     

    ...

     

    We also had a timed events.  These were handled by an "event wheel", a technique used in event-driven logic simulation.  The main loop would see if any timed events needed to be processed and did it before the Action Queue.

     

     

    That's virtually the same as what RTosses do.

     

      wrote:

     

    ...

     

    Management was always trying to replace the bare-metal code with an operating system.  I always fought against it.  After I left the company they did the operating system thing.  It took a couple years to get going and required at least twice the memory.  Think about it: there's no way that adding an OS is going to make your code run faster or smaller, right?

    On the other hand, it's a proven working way of scheduling tasks with right timings and priorities. And have inter task communication.

    Reusable things that you need, and have to build inhouse if you roll your own. That leads to writing a toolkit that already exists by a team that could work on domain specific functionality?

Reply
  • in reply to johnbeetem

      wrote:

     

    ...

     

    We also had a timed events.  These were handled by an "event wheel", a technique used in event-driven logic simulation.  The main loop would see if any timed events needed to be processed and did it before the Action Queue.

     

     

    That's virtually the same as what RTosses do.

     

      wrote:

     

    ...

     

    Management was always trying to replace the bare-metal code with an operating system.  I always fought against it.  After I left the company they did the operating system thing.  It took a couple years to get going and required at least twice the memory.  Think about it: there's no way that adding an OS is going to make your code run faster or smaller, right?

    On the other hand, it's a proven working way of scheduling tasks with right timings and priorities. And have inter task communication.

    Reusable things that you need, and have to build inhouse if you roll your own. That leads to writing a toolkit that already exists by a team that could work on domain specific functionality?

Children
  • in reply to Jan Cumps
    Reusable things that you need, and have to build inhouse if you roll your own. That leads to writing a toolkit that already exists by a team that could work on domain specific functionality?

    My experience with RTOS has been mixed.  The product I'm talking about at one time had an optional set of protocols that we didn't want to write ourselves because nobody understood them.  So we licensed software from a vendor.  The software ran on VRTX.  Well, we didn't want to have to run VRTX on our standard product (and pay a per-unit royalty), so I engineered it so that VRTX was optional.  If installed, it ran our standard software as a task.  The 68000 version of VRTX was simple and well-documented, so doing this was straightforward.

     

    Later I had to the same thing for PowerPC.  That ended up being a nightmare.  VRTX had been bought by Mentor Graphics and the PowerPC documentation was awful.  You were supposed to use a "board support package" which was supposed to take care of everything for you, but if your hardware didn't have a "board support package" the documentation didn't tell you what you needed to know.  I ended up having to disassemble the task switch code to figure out how they saved and restored registers.

     

    So yeah, using the PowerPC VRTX didn't open up a bunch of time for "domain-specific functionality".

     

    I love embedded programming down at the bare metal and having control over everything.  I'm OK with writing application-level code for mainframes, but if I'm doing embedded I want to be down at the bare metal.  Chacun a son goût.