At that level I sort of agree but when people start assigning names to
individual bits in a large address space the value is lost.
On Jan 24, 2014 10:05 PM, "Chuck McManis" <[email protected]> wrote:
> 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
