| ??? 07/06/06 19:42 Read: times |
#119775 - The problem with bitfields Responding to: ???'s previous message |
extends beyond the 8051. It wasn't clearly defined in the language (C). Maybe Pascal is different. The poor compiler implementation is pretty universal from my limited sampling of compilers (independent of CPU). If one could overlay a struct of bitfields on top of the 8051's bit variable space, then that might make things interesting. Terribly non-portable though. Doing it yourself with shifts, ands and ors *is* portable. I've used similar code on 8051, HC11 and x86.
What you are doing by using a struct of bitfields is drilling down from the application layer to the hardware (abstraction) layer. If you can keep those separate you can port a ton of your code... not that in many cases you can take advantage of it. I mean there aren't many embedded applications that are useful on multiple platforms, but certainly protocols are one example that can run on lots of things and one would be tempted to use bitfields for flags and such. Well, ... don't! GB |
| Topic | Author | Date |
| bit variable using struct | 01/01/70 00:00 | |
| Which compiler? | 01/01/70 00:00 | |
| Insuffiicient Info; Post formatted code | 01/01/70 00:00 | |
| Asking for help? | 01/01/70 00:00 | |
| Observation | 01/01/70 00:00 | |
| showing lack of discipline | 01/01/70 00:00 | |
| compiler | 01/01/70 00:00 | |
| Sbit and BData | 01/01/70 00:00 | |
| sbit and BData - code formatted | 01/01/70 00:00 | |
| 16 bits | 01/01/70 00:00 | |
| more hint | 01/01/70 00:00 | |
| Std C bitfields != Keil bit-addresssable | 01/01/70 00:00 | |
| What this guy said | 01/01/70 00:00 | |
| another example of two things | 01/01/70 00:00 | |
| The problem with bitfields | 01/01/70 00:00 | |
Granted | 01/01/70 00:00 |