Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
@Fast-Nop: I know. These headers are only going to be used with one compiler, though.
-
@7400 and that's awful legacy code - tied to a single compiler and even compiler version without any good reason.
-
@Fast-Nop: Yes, I like to live dangerously. Bit ordering in bitfield is not that likely to change between compiler versions, though (especially since the architecture is fixed and it's a single byte every time), and it would undeniably have been nice to use in code. Microchip even uses bitfields in the “official” headers for PICs, I think.
But, yeah, it still was a nice exercise in writing C macros. -
@7400 ST's code sucks anyway; I only use it for getting a quick overview how something should work and then implement it myself.
But if you are into macros, why don't you drop the bitfields and make set/reset bit macros using bitmasks? -
@Fast-Nop: I never liked the aesthetics of bit set/reset/check macros. Otherwise I wouldn't go through all the trouble with bitfields.
Related Rants
She runs C shells by the seashore.
I felt like being the cause for “that dreaded legacy code“ and wrote 250 lines of C preprocessor macros for generating bitfields in a large header file automatically, with the goal of simplifying and clarifying register access for all peripherals in the end. Then, I found out that SDCC's optimisation for bitfields is absolutely awful (if existent at all), and I don't really want to use these abstractions if they have a performance impact.
Did I deserve that?
rant
🔌
sdcc
c
embedded