I agree with that in general, however I find that systems documentation
generally refers to thing with their GPIO "pin" name, so the docs for the
Discovery board for example talk about the LED being connected to PD15.
As for the symbology, its a composition of [name][bit_number] so really the
only thing you learn is that there are up to 9 GPIO ports on the part (A -
I). As symbols go it is composable exactly like numbers are composable so
the dictionary is actually quite small (A - I) (0 - 15).
The way the current system works is it uses "GPIOD" (for example) to name
port D and then GPIO0 through GPIO15 to name the bits. So the tuple (GPIOD,
GPIO10) == PD10. My thought was they were easier to carry around together
rather than as tuples.
--Chuck
On Fri, Jan 24, 2014 at 1:56 PM, Frank Duignan <[email protected]>wrote:
> My feeling on this that there is questionable value in learning a large
> dictionary of symbols versus learning the meaning of each bit. So, why not
> use for example BIT2 for PA2 and PB2 etc.
> On Jan 24, 2014 9:49 PM, "Chuck McManis" <[email protected]> wrote:
>
>> One of the things I did to make writing ARM code simpler was to define an
>> enum called GPIO_PORT_PIN with the values PA0 .. PI15. These have the
>> values 0 .. 143.
>>
>> Because of their numerical relation, you can do some math on them, like
>> so
>>
>> GPIO_BIT_NUMBER(PB6) == (PB6 % 16)
>>
>> I exploit this in other ways too, which you can see in my library (cpa)
>> which is hosted here: https://github.com/ChuckM/libcpa
>>
>> In particular, the libopencm3 interface to toggle a bit can be written:
>>
>> gpio_toggle(gpio_base(PB5), gpio_bit(PB5))
>>
>> or as I do in my #define, you can rewrite this that simply toggle(PB5);
>>
>> Now I'm not a huge fan of massive syntactic sugar, this is part of what
>> makes the "standard peripheral library" from ST.M so distasteful. But this
>> change to being able to 'name' GPIO pins has come in handy.
>>
>> Things you can't do of course, you can't say toggle(PB5 | PB6); (or even
>> more creatively toggle(PB5 | PC2); Not sure if that is a problem or not for
>> some.
>>
>> I also found when doing my SPI work that since you may have pins all over
>> the map for an SPI port or a USART you can "safely" enable clocks or
>> alternate functions for each pin, but that is slightly slower more verbose
>> than setting groups of pins.
>>
>> I'm looking for feedback on whether or not that is a useful abstraction
>> or not.
>>
>> --Chuck
>>
>>
>>
>> ------------------------------------------------------------------------------
>> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>> Learn Why More Businesses Are Choosing CenturyLink Cloud For
>> Critical Workloads, Development Environments & Everything In Between.
>> Get a Quote or Start a Free Trial Today.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>> _______________________________________________
>> libopencm3-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/libopencm3-devel
>>
>>
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
libopencm3-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libopencm3-devel
