This is really convoluted, so feel free to reply to me offlist. I'm trying to model a register map for a voltage regulator chip.
Our chips used to have an extremely simple register map. There was an I2C interface, and the designers created a list of register names, defined what address they were at, how many bits wide they were, masks, etc, and we were done. It was easy because every register name was completely unique. So I just modeled it as a simple perl hash. Our latest regulator chip has multiple voltage outputs and the old register map approach fell apart. We now have the same register names occuring at multiple addresses and each version of a register might behave a little differently. i.e. the "output_voltage" register might be ten bits wide for the first voltage output core and another "output_voltage" register might be 12 bits wide for the second core. And of course, each "output_voltage" has to have a different address depending on which output its controlling. I don't even know how to model this. The best I can come up with is to start defining classes for the different types of registers. Like have an "output_voltage" class that has attributes like address and how many bits wide it is, and then give each class methods specific to what the register does, such as a "set_voltage" method which takes a floating poitn number like 1.3 representing voltage and converts it to the correct number of bits in the correct format, and then writes that data into the chip. And then I think I'd need container classes to hold instances of the registers. I might put all the "read-only" registers in one container, and the "calibration" regisers in another container. And the container would have to support iterating through all the instances it holds somehow, and have various methods to support that. So that would be a container-of-registers class. And then I'd need a third class, which would be a container-of-container class. A single voltage core would be a container of "read-only" and "calibration" and "read-write" container-of-register instances. I think. And then that class would need to deal with iterating through the container-of-register instances it holds. The idea would be that I should be able to iterate through all the cores and set the output to different voltages, and it just uses polymorphism to work. We also need to be able to iterate through all the registers, set them to somewhat-random values, read them back, and make sure they hold the values written. So, I need ot iterate through the container-of-container class whcih iterates through the container-of-regiser class, which iterates through all the register-class instances. So, (1) register_class is a base class. And then there are classes that inherit from that register_class such as output_voltage_register class which deals specifically with the output_voltage register and all its variations. Then (2), container-of-register class, which keeps track of chunks of registers that are physically related and supports iterating through those registers. And (3), a container-of-container class, which holds instances of container-of-register objects, and supports iterating through them. At which point, this seems really complicated. But at the same time, dealing with registesr maps doesn't seem like it should be a new thing, so maybe someone has already come up with a set of classes for dealing with this? But I wouldn't even know what to google for. So, anyone know of a already-existing solution (perl module or similar) for dealing with this kind of register-map problem? Maybe point me in the direction of something that's already solved this problem well so I don't reinvent the wheel, and do it poorly. Or maybe a generic container-of-instances-of-other-classes solution? Or is this the wrong approach entirely? and if so, what would be the better way to manage this? Our old approach is a kludge and needs to be recoded. And that's looking like a lot of work. So I thought before I go down that path, I'd check in with you software types and see if someone hasn't already figured this out or at the very least if someone sees a fatal flaw in the basic approach. Thanks, Greg _______________________________________________ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
