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

  • Hi Inderpreet,

     

    In telecoms there's lots of protocols documented, but there's no (publicly available) source code often, so it's up to the software developer to code it. The way the protocol is documented can vary, but one method looks like flow charts, known as SDL.

    It can be used to describe pretty complex protocols. SDL allows you to describe message sequences, error states, timeouts, timers etc. So if a designer wished to design and document a protocol that would be one way, and it's accepted by telecoms software engineers, they can take it and run with it, and churn out a protocol stack in software.

     

    In a more rapid world, people would write an RFC* (Request for Comment).. it would be public and people would scrutinize it : ) pick holes in it and write updates.

     

    I think (for new situations) there's nothing wrong with lifting a protocol and inserting it into a different lower-layer, or tunneling a protocol in another, or using a protocol for a different or newer purpose, or (sometimes) adding extensions. All of these are very common in the networking world.

    Writing a totally custom protocol (even if it is on top of some well-known lower layers) while achievable, you have to ask, why would they do it.. sometimes it is to deliberately try to obscure. There was a time (about a decade ago) when company lawyers would frown on that, because interfaces were subject to the 'Software Directive'. It literally gave free permission to anyone to reverse-engineer your product, if they couldn't obtain a copy of the spec. That legislation is superseded now. Reverse-engineering was (to some, not to me!) undesirable because you always ran the risk that the person who was doing the reverse-engineering may discover more tips and tricks and proprietary stuff that go beyond what was required to understand the interfacing protocol..

     

    * Example.. this one documents information transfer with layer 1 being carrier pigeon : )

    https://tools.ietf.org/html/rfc1149

Reply

  • Hi Inderpreet,

     

    In telecoms there's lots of protocols documented, but there's no (publicly available) source code often, so it's up to the software developer to code it. The way the protocol is documented can vary, but one method looks like flow charts, known as SDL.

    It can be used to describe pretty complex protocols. SDL allows you to describe message sequences, error states, timeouts, timers etc. So if a designer wished to design and document a protocol that would be one way, and it's accepted by telecoms software engineers, they can take it and run with it, and churn out a protocol stack in software.

     

    In a more rapid world, people would write an RFC* (Request for Comment).. it would be public and people would scrutinize it : ) pick holes in it and write updates.

     

    I think (for new situations) there's nothing wrong with lifting a protocol and inserting it into a different lower-layer, or tunneling a protocol in another, or using a protocol for a different or newer purpose, or (sometimes) adding extensions. All of these are very common in the networking world.

    Writing a totally custom protocol (even if it is on top of some well-known lower layers) while achievable, you have to ask, why would they do it.. sometimes it is to deliberately try to obscure. There was a time (about a decade ago) when company lawyers would frown on that, because interfaces were subject to the 'Software Directive'. It literally gave free permission to anyone to reverse-engineer your product, if they couldn't obtain a copy of the spec. That legislation is superseded now. Reverse-engineering was (to some, not to me!) undesirable because you always ran the risk that the person who was doing the reverse-engineering may discover more tips and tricks and proprietary stuff that go beyond what was required to understand the interfacing protocol..

     

    * Example.. this one documents information transfer with layer 1 being carrier pigeon : )

    https://tools.ietf.org/html/rfc1149

Children
  • in reply to shabaz

      wrote:

     

    Hi Inderpreet,

     

    In telecoms there's lots of protocols documented, but there's no (publicly available) source code often, so it's up to the software developer to code it. The way the protocol is documented can vary, but one method looks like flow charts, known as SDL.

    It can be used to describe pretty complex protocols. SDL allows you to describe message sequences, error states, timeouts, timers etc. So if a designer wished to design and document a protocol that would be one way, and it's accepted by telecoms software engineers, they can take it and run with it, and churn out a protocol stack in software.

     

    In a more rapid world, people would write an RFC (Request for Comment).. it would be public and people would scrutinize it : ) pick holes in it and write updates.

     

    I think (for new situations) there's nothing wrong with lifting a protocol and inserting it into a different lower-layer, or tunneling a protocol in another, or using a protocol for a different or newer purpose, or (sometimes) adding extensions. All of these are very common in the networking world.

    Writing a totally custom protocol (even if it is on top of some well-known lower layers) while achievable, you have to ask, why would they do it.. sometimes it is to deliberately try to obscure. There was a time (about a decade ago) when company lawyers would frown on that, because interfaces were subject to the 'Software Directive'. It literally gave free permission to anyone to reverse-engineer your product, if they couldn't obtain a copy of the spec. That legislation is superseded now. Reverse-engineering was (to some, not to me!) undesirable because you always ran the risk that the person who was doing the reverse-engineering may discover more tips and tricks and proprietary stuff that go beyond what was required to understand the interfacing protocol..

    If your design is worth the money you earn for it, it's going to be reverse engineered in the 2020s.

    I think that if you invented a new/better protocol, and no-one bothered to hack it - you wasted money and resources because no-one cares. And you have to maintain your legacy.

    A cost that you'll have to carry along forever without a competitive gain. Yes, you may tie some existing customers to your bespoke solution. But who wants to join your customer base?

  • in reply to Jan Cumps

    I understand that.. but to some (again not me!) lawyers it was super-undesirable to legitimise it.

    The reason is, even if you don't have fancy tips/tricks/proprietary secrets, you run the risk that the person discovers _that_... and then uses it against you, by (say) finding the weaknesses and demonstrating them, and coming out with literature which then legally and rightly trash your product by pointing out these flaws.

    Using a standard protocol, and the problem went away from legitimate (operating within the law) competitors to some partial extent..

  • in reply to shabaz

    Have they ever measured the lawsuit costs versus developing-and-maintaining-proprietary costs?

    They have to sue people that steal their idea (secret or hidden behind closed source) in court - and that's expensive. Blaming and pointing doesn't do the job.

    That goes for ideas based on open and closed protocols. So the proprietary protocol may slow down competitors --- only if your idea isn't worth stealing ...

  • in reply to Jan Cumps

    I'm saying the opposite..

    i.e. that the smart lawyers understood to use standards-based protocols. Using standards-based protocols bought you more time, because you've then eliminated the legitimately operating firms from being able to legally reverse-engineer to find out the interface.

    The law was that if you _didn't_ publish the interface (i.e. it was a proprietary interface) then you've given legitimate firms free permission to knock themselves out and go ahead with their software reverse-engineering, to create products to connect with yours... and in the process, run the risk they discover everything else, tips, tricks, skeletons, warts and all, about your product.

     

    Firms that didn't think that step, may well have not cared what their engineers used, and let them code proprietary stuff and usually that's silly - as I think you're saying too.