Hello Duc,
Am 29.06.22 um 13:46 schrieb Duc Doan:
Hello Christian,
I have been writing the complete API and also implementation for
STM32F4. A patch is coming soon.
On Mon, 2022-06-27 at 13:33 +0200, Christian MAUDERER wrote:
Regarding pin groups: I think it's worth to think a bit about how the
structure could be extended. You don't have to implement it right now
but you should have a plan what could be possible.
From my point of view, there are two directions how that could be
implemented: Masks or lists.
If you have a mask (like 0x00108 for pin 3 and pin 8) it has the
advantage that it works fast for most controllers. Difficult is that
it
adds a limit to the maximum pin number depending on the size of the
mask. With that it works only for a few hardware models.
The other option is to add a list of pins instead of a mask. That
makes
it inefficient because most controllers will have to collect pins
into
masks and work with that.
Hm. Difficult. Maybe someone else has a good idea for that in the
next
few days.
I am thinking of later adding separate functions that handle pin
groups. I think it's quite hard to integrate into current functions
because of using virtual pin.
I have an assumption that needs confirmation: all microcontrollers (or
most of them) have register size equal to word size, and pin masks
should be at word size. Is that assumption correct? If so, maybe we can
just use unsigned int (or uintptr_t) for pin masks?
Not sure whether some 64bit controllers don't use 32bit registers. So
it's not generally true that registers have the word size. It should
work for most controllers (at least the ones I worked with) but I
wouldn't guarantee it.
Beneath that: You most likely know my argument already: What about I2C
or SPI chips. They can use register sizes that are not the same as the
controllers register size (even if they are most likely only 8 bit most
of the time at least for I2C).
Best regards
Christian
Best,
Duc Doan
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
