element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • About Us
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Embedded and Microcontrollers
  • Technologies
  • More
Embedded and Microcontrollers
Embedded Forum Writing protocols for bare-metal C
  • Blog
  • Forum
  • Documents
  • Quiz
  • Polls
  • Files
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join Embedded and Microcontrollers to participate - click to join for free!
Actions
  • Share
  • More
  • Cancel
Forum Thread Details
  • Replies 18 replies
  • Subscribers 464 subscribers
  • Views 3039 views
  • Users 0 members are here
  • firmware
  • ip_iot
  • embedded
Related

Writing protocols for bare-metal C

ipv1
ipv1 over 5 years ago

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?

  • Sign in to reply
  • Cancel

Top Replies

  • Jan Cumps
    Jan Cumps over 5 years ago in reply to Jan Cumps +5
    While I'm at it: never consult hardware/firmware forums when thinking about version control. They are inventing issues that have been solved in 1985 .... and say that firmware development is unique. And…
  • michaelkellett
    michaelkellett over 5 years ago in reply to ipv1 +5
    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…
  • shabaz
    shabaz over 5 years ago +4
    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…
Parents
  • Jan Cumps
    Jan Cumps over 5 years ago

    I always use a standard protocol. Even if I don't like it or can see shortcomings.

     

    It helps myself and my colleagues in the long run.

    All in your list are fair game as a protocol I'd use. The decision would be based on topology (on-board- wired, long-distance wired, industrial,  ...)  and what's already used in a design.

     

    The same for OSes. I will always use an existing OS protocol  In RTOS, that's typically tasks, queues, messaging and metaphors.

    In Linux/Windows/... any of the existing protocols, from sockets up to MQTT, web services, RPCs, ..., domain specific APIs).

    Any protocol my colleagues or myself invented "because they were better" turned into an unsupported pile  of trash. One of the reasons why I'm sticking to SCPI (and love it).

    • Cancel
    • Vote Up +3 Vote Down
    • Sign in to reply
    • Cancel
  • ipv1
    ipv1 over 5 years ago in reply to Jan Cumps

    I understand and agree. My problem starts with the fact that most hardware guys are not trained to thing in software. In many cases I don't really have a choice hence the question.

    • Cancel
    • Vote Up +3 Vote Down
    • Sign in to reply
    • Cancel
  • Jan Cumps
    Jan Cumps over 5 years ago in reply to ipv1

    ipv1  wrote:

     

    I understand and agree. My problem starts with the fact that most hardware guys are not trained to thing in software. In many cases I don't really have a choice hence the question.

    That's one of the arguments why I think that hardware guys should shy away from inventing "better" protocols.

    • Cancel
    • Vote Up +3 Vote Down
    • Sign in to reply
    • Cancel
  • Jan Cumps
    Jan Cumps over 5 years ago in reply to Jan Cumps

    While I'm at it: never consult hardware/firmware forums when thinking about version control.

     

    They are inventing issues that have been solved in 1985 .... and say that firmware development is unique. And advice zip files. Copies. Dropbox. More copies, directories that have a version as their name...

    Then they make the errors peoples in 1984 made ...

    • Cancel
    • Vote Up +5 Vote Down
    • Sign in to reply
    • Cancel
Reply
  • Jan Cumps
    Jan Cumps over 5 years ago in reply to Jan Cumps

    While I'm at it: never consult hardware/firmware forums when thinking about version control.

     

    They are inventing issues that have been solved in 1985 .... and say that firmware development is unique. And advice zip files. Copies. Dropbox. More copies, directories that have a version as their name...

    Then they make the errors peoples in 1984 made ...

    • Cancel
    • Vote Up +5 Vote Down
    • Sign in to reply
    • Cancel
Children
No Data
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2025 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube