T
Tim Clacy
Be a hero and show me a good model of a hardware device register :-O
This might seem like an absurd challenge; after all, the C++ language has
been around for donkeys years now. It's a mature language and we have
powerful design patterns to simplify complex problems. However, I've never
seen, and have never been able to produce, a satisfactory model of a
register! It's not that I'm thick nor inexperienced; I just expect a lot
Traditionally, and still today, you'll see most device drivers using
#defines, enums, bit-fields, global constants, structs of integer types and
so on. The resultant code is inevitably difficult to follow or error prone
or
unsafe or volumous or endian-dependent... or, often, all of the above.
Surely, it must be possible to create a model of something as fundamental as
a device register that results in simple, safe, understandable and close to,
or identical to, the efficiency of these simple minded solutions...
shouldn't it?
Consider the CSR (configuration and status register) architecture, used in
numerous busses and bus devices that we all use daily (PCI, FireWire, SCI
etc.); it's all about
registers... lots and lots of registers; read-only registers, read-write
registers, registers that have one meaning if read and another meaning if
written to, registers with reserved bits, registers with read-only bits and
bit-fields etc. etc.
Most embedded compilers these days support all of the modern features of C++
(namespaces, templates...); the code generation is usually extremely good
too. Obviously, we would want to avoid features that have run-time overhead
and/or non-deterministic behaviour down at the device driver level, but the
tools I've seen and used all support leaving out these features. Some
compilers for embedded development support the very latest standards and
allow trick like template metaprogramming (in fact until Visual Studio.net,
many had better support for templates than Microsoft's desktop efforts).
So, we have the capability to use C++, templates and design patterns in
embedded/driver development; a register model would be a great starting
place to exploit these. Have you ever seen a satisfactory class for
modelling a device register?
Tim Clacy
This might seem like an absurd challenge; after all, the C++ language has
been around for donkeys years now. It's a mature language and we have
powerful design patterns to simplify complex problems. However, I've never
seen, and have never been able to produce, a satisfactory model of a
register! It's not that I'm thick nor inexperienced; I just expect a lot
Traditionally, and still today, you'll see most device drivers using
#defines, enums, bit-fields, global constants, structs of integer types and
so on. The resultant code is inevitably difficult to follow or error prone
or
unsafe or volumous or endian-dependent... or, often, all of the above.
Surely, it must be possible to create a model of something as fundamental as
a device register that results in simple, safe, understandable and close to,
or identical to, the efficiency of these simple minded solutions...
shouldn't it?
Consider the CSR (configuration and status register) architecture, used in
numerous busses and bus devices that we all use daily (PCI, FireWire, SCI
etc.); it's all about
registers... lots and lots of registers; read-only registers, read-write
registers, registers that have one meaning if read and another meaning if
written to, registers with reserved bits, registers with read-only bits and
bit-fields etc. etc.
Most embedded compilers these days support all of the modern features of C++
(namespaces, templates...); the code generation is usually extremely good
too. Obviously, we would want to avoid features that have run-time overhead
and/or non-deterministic behaviour down at the device driver level, but the
tools I've seen and used all support leaving out these features. Some
compilers for embedded development support the very latest standards and
allow trick like template metaprogramming (in fact until Visual Studio.net,
many had better support for templates than Microsoft's desktop efforts).
So, we have the capability to use C++, templates and design patterns in
embedded/driver development; a register model would be a great starting
place to exploit these. Have you ever seen a satisfactory class for
modelling a device register?
Tim Clacy