Hi Paul,
Thanks for your input. You obviously have a great deal of experience
with ST. Since I don't have this same amount of experience, it isn't
obvious to me how ST will have this project unfold.
On 02/18/14 13:42, Paul Sokolovsky wrote:
> On Tue, 18 Feb 2014 12:49:38 -0500
> Trevor Woerner <trevor.woer...@linaro.org> wrote:
>
>> How ironic that, just the other day on IRC,
>> we were talking about higher-layer hardware abstractions and it was
>> mentioned that, if anything, it would be a good idea to consider a new
>> fake machine (like arduino did) instead of trying to make it too much
>> like any existing hardware.
> That's rather cryptic - isn't Arduino is like any existing hardware,
> except that API implementation is stupidly inefficient?
If I recall the IRC conversation correctly (and perhaps I don't) there
is a discrepancy in the functionality and naming of "standard"
interfaces (e.g. GPIO) between different manufacturers. So the question
was asked as to whether libopencm3 should follow the data sheet naming
for each SoC, or whether a generic naming should be used across the
entire library (regardless of a particular SoC's naming in their
datasheet). But, in essence, the suggested generic naming was based on
one specific chip. So if this opinion was adopted, libopencm3's API
would match that one chip, and all others would have to fit within that
one chip's conventions.
It was suggested in the IRC chat that if one chip was to be used as the
basis, then that basis shouldn't exactly follow any one chip
specifically, but rather a "fake chip" should be defined and everything
named to that. The arduino was used as an example, but nobody was
suggesting it should be taken as the golden standard :-)
My original email was merely pointing out how ironic it is that in the
IRC conversation just a couple days ago the arduino was used as a silly
example, but now ST has actually come out with an arduino-ized product
(i.e. by using its footprint and naming conventions).
> Well, even links you quote clearly state that the boards will be
> supported by mbed. Besides that, ST will do what they always do -
> provide CMSIS and peripheral library. Besides that, they will do
> nothing, in particular, why would they bother with "ports of the
> existing arduino libraries"?
These boards are clearly meant to take existing Arduino shields. If a
customer is using generic shields, and this product is clearly trying to
take advantage of the existing ecosystem of existing arduino shields,
then I would assume there would be some effort to allow the libraries
associated with these shields to also be used?
You've stated several times that the arduino appeals to a particular
demographic. If a company targets a board at this demographic it
wouldn't be too far fetched to think it would be crazy of them to assume
these people are going to suddenly understand how to code PWM registers
directly :-)
> What for? Is any particularly bright software written with '"arduino"
> library'? Maybe Contiki, Wiselib, L4 exist only thanks to arduino
> enablement? Nope, it's a library of choice for people who don't know
> how to blink LEDs. When it gets to do something real, arduino spirit
> quickly dies off
And yet arduinos are quite popular, and many board manufacturers have
put out products targeting the arduino footprint and library.
Best regards,
Trevor
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
_______________________________________________
libopencm3-devel mailing list
libopencm3-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libopencm3-devel
