Quoting Alexey Bishletov <nita@...>: > 5:08:07 PM, Wednesday, March 1, 2006, Robert wrote: >> Also if you have a different read and write register at the same >> address you may >> get really odd results. > > My variant uses the same register for read and write. It is possible > for LPC. Sorry I don't understand this. This is a general issue using any sort of Read-modify-write sequence when you have hardware that maps a ready-only register and a write only register to the same address. Bit fields are almost always implemented as RMW sequences and so in that case you will not be doing what you expected to do. > There is another solution. Use C++, create class "port" and overload > operator=(int) and int(port). But some overhead will be unavoidable. There was an initiative to standardize a set of macros and library routines for ISO C for Hardware access. I havn't heard of it in a while though. >> Basically bitfields are a very bad idea for I/O. Sooner or later thay >> will bite >> you in the fundament. > > Why do you think so? Or is it so only with LPC? Nope, all processors. The issues off the top of my head are - Bitfield order is implementation defined - Bitfield write is necessarily an RMW sequence which is invalid for a lot of hardware and non-atomic on a lot of processors. - Access size is indeterminate. - Bitfields default to signed. Worse some of this may change depending on optimization conditions. And the compiler vendor is quite free to change this from version to version. Now if the compiler vendor is using this for their own defined headers there is a reasonable chance that it will remain valid (although I have seen vendors change similar details on a major upgrade). You are though locked into your particular vendor at that point. I've also found building and maintaining bifield structures to be far more painful than the alternatives. The only thing bitfields are good for is saving memory in internal data structures, where everything except the signedness is irrelevant. Robert
Message
Re: Re[4]: [lpc2000] Re: Bit addressing
2006-03-01 by Robert Adsett
Attachments
- No local attachments were found for this message.