From: Richard Hodges (hodges.r_at_[hidden])
Date: 2020-07-02 09:49:32
On Thu, 2 Jul 2020 at 11:02, Jupiter via Boost <boost_at_[hidden]>
> Thanks Gavin,
> Right, it is to read and to write STPM32 chipset via UART, definitely
> to use a wrapper class to define each register value, each bit field
> can be hidden inside shift functions to increase visibility of the
Why would you do this?
C and C++ already has a language mechanism for this:
int reg_a : 8;
int reg_b : 8;
int reg_c : 8;
#define my_uart (*(UART *)0xaddress)
// perform read
auto data = my_uart.reg_a;
> Thank you.
> On 7/2/20, Gavin Lambert via Boost <boost_at_[hidden]> wrote:
> > On 2/07/2020 14:43, Jupiter wrote:
> >> I am working on an embedded system where I read hardware 32-bit
> >> register values represented variables in bits. Currently I am using
> >> bit shift to extract values, it is too vague to represent variables. I
> >> have been thinking to make overhaul of using dynamic bitset, is it a
> >> good idea or bad idea?
> > If you just want a name to give to each bit shift, you can use an enum.
> > Or better yet, consolidate all of your code that deals with that
> > register into a C++ class with named methods, and only manipulate the
> > register via those methods. That keeps all the shifting away from your
> > actual business logic. (And is a better encapsulated design anyway, and
> > can be just as fast if the method calls are inlined.)
> > The point of dynamic_bitset is if you don't know at compile time how
> > many total bits you want to represent.
> > If there are a fixed number of bits you're interested in then it doesn't
> > really gain you anything over bitshifting, since you still have to
> > identify the bits by number either way. (There are ways to give names
> > for those numbers, such as the aforementioned enum, but those are
> > equally applicable to both.)
> > It also introduces a storage indirection -- you can't read or write a
> > specific bit directly out of a register any more, you'd have to copy it
> > first. This is error prone, slower, and may not even be correct, as
> > some hardware registers have write-only bits or will react differently
> > to rewriting the same bit value than plain memory does.
> > So all around, no, that seems like a very bad idea.
> > If you really want to assign names to specific bits or bit ranges and
> > bit shifting isn't doing it for you (and you don't want to write that
> > wrapper class for whatever reason), then the best alternative would be
> > to use C/C++ bitfield structures. You need to be a bit careful with
> > these (always use an unsigned integer member type unless you really want
> > each member to have a sign bit), and be aware that they are not
> > considered portable, as different compilers and/or architectures may
> > order bits differently or have different rules for padding or when
> > crossing byte boundaries. But if you're targeting a single compiler and
> > architecture then this may work well for you, since it makes the
> > compiler do the shifting for you.
> > Assuming that you get the bitfield layout correctly matching your
> > hardware register, you can use a volatile* for your bitfield directly
> > pointing to the register, and it will just work ... unless the register
> > happens to be one of the ones that requires you to write to multiple
> > bitfields simultaneously, in which case things get trickier, and you
> > have to go even further into the unportable weeds.
> > _______________________________________________
> > Unsubscribe & other changes:
> > http://lists.boost.org/mailman/listinfo.cgi/boost
> "A man can fail many times, but he isn't a failure until he begins to
> blame somebody else."
> -- John Burroughs
> Unsubscribe & other changes:
-- Richard Hodges hodges.r_at_[hidden] office: +442032898513 home: +376841522 mobile: +376380212
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk