is using the vendor library with bitfields for mapping register a good idea?

Whether to use the default register maps from the vendor or roll out your own is pretty much project-specific. If you have high requirements of portability and general source code quality, you have to make your own register map.

Some discussion on that topic can be found here: How to access a hardware register from firmware? As discussed in that post, the vendor has several reasons for rolling out their own custom, crappy register maps:

  • Makes debugging register maps easier, particularly when using a crappy debugger with no specific part support (such as the various Eclipse-flavoured ones). High quality debuggers like Lauterbach, iSystem, Crossworks etc do have part support and you can watch registers just fine in them, no matter how those registers were declared in C source.
  • Silicon vendors have absolutely no reason to make it easier for you to port away from their silicon to some other. Quite the contrary. Register maps are of course quite non-portable to begin with. But similarly, tool vendors don’t want you to port to another compiler for the same silicon.
  • Silicon vendors are notoriously incompetent when it comes to writing firmware. This has been the case for as long as everyone can remember. I wouldn’t point at any particular vendor here, they are all hopelessly bad at this.

What you could do however, in case of Infineon specifically, is to ask: “Hey guys, you seem to like automotive electronics a lot. The automotive industry has been using MISRA-C since 1998. How come you still don’t provide MISRA-C compliant libraries in the year 2020? You don’t want automotive customers to use your products?” Lots of amusing mumbling responses to be had.

CLICK HERE to find out more related problems solutions.

Leave a Comment

Your email address will not be published.

Scroll to Top