Actions
Forum Thread Details
  • Replies 18 replies
  • Subscribers 470 subscribers
  • Views 3233 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

  • My take on this would be that if you find someone presenting you with a ‘need’ for a new protocol, or you find yourself trying to create a new protocol, you should go back into the design process and ask where it went wrong.  That’s not to say a new protocol won’t be required, but given what is established in industry already you need to stick with what’s there.  Really, the only time I can see a need to create a new protocol is if you’ve invented a new industry!  An existing protocol may not be perfect, may be too heavyweight etc etc but there it is already and in use.  If I created something new in an existing marketplace it would end up so niche that it would likely fail to gain any traction.  At the least, you’d have customers coming back demanding it talked nicely to their other equipment!

     

    And to the point on interrupt driven processing, I’d say it has its place but drives development, testing and support complexity so appropriateness must be considered - it’s not a standardised design pattern.  Timing, blocking, synchronisation, reproducibility all become issues to resolve and the more your software is interrupt driven the greater the complexity level.  Personally, I’d only ever drive ‘imperatives’ as interrupts (I.e. this thing MUST be done at the time of interrupt and can’t wait) and not conflate the concepts of events and interrupts.

     

    EDIT: When I wrote that paragraph above, it hadn't crossed my mind to think 'real-time' - it's nothing I have any experience with - so I would have to caveat that paragraph accordingly. 

Reply

  • My take on this would be that if you find someone presenting you with a ‘need’ for a new protocol, or you find yourself trying to create a new protocol, you should go back into the design process and ask where it went wrong.  That’s not to say a new protocol won’t be required, but given what is established in industry already you need to stick with what’s there.  Really, the only time I can see a need to create a new protocol is if you’ve invented a new industry!  An existing protocol may not be perfect, may be too heavyweight etc etc but there it is already and in use.  If I created something new in an existing marketplace it would end up so niche that it would likely fail to gain any traction.  At the least, you’d have customers coming back demanding it talked nicely to their other equipment!

     

    And to the point on interrupt driven processing, I’d say it has its place but drives development, testing and support complexity so appropriateness must be considered - it’s not a standardised design pattern.  Timing, blocking, synchronisation, reproducibility all become issues to resolve and the more your software is interrupt driven the greater the complexity level.  Personally, I’d only ever drive ‘imperatives’ as interrupts (I.e. this thing MUST be done at the time of interrupt and can’t wait) and not conflate the concepts of events and interrupts.

     

    EDIT: When I wrote that paragraph above, it hadn't crossed my mind to think 'real-time' - it's nothing I have any experience with - so I would have to caveat that paragraph accordingly. 

Children
No Data