Hello, On Tue, 18 Feb 2014 14:25:22 -0500 Trevor Woerner <trevor.woer...@linaro.org> wrote:
> Hi Paul, > > Thanks for your input. You obviously have a great deal of experience > with ST. Not really. I specifically taking care to watch wider MCU space, not sticking with a single vendor. And then after watching them for some time, good old saying comes that "the differences only emphasize the similarity". > 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 :-) Let me guess - it was some earth-shuttering subject like how to name GPIOs? And while *any* datasheet out there talks of GPIOs in terms of ports and within-port pin numbers, some people still suggested that they should use arbitrarily assigned scalar numbers for GPIOs, just like Arduino does? Oh, that's so fresh idea. Indeed, let's ignore datasheets and how actual hardware organized, and let's follow simple-minded idea to express whole world in a single number. Then indeed, it's possible to spend years in discussions which numbering is best - left-to-right, right-to-left, or zig-zag. > 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). Sorry to spoil "exciting new" news, but releasing yet another "Arduino-connectored" board is a boring event in the industry. Before ST, Intel did it (*that* was fun, yeah), before that Freescale did it with FDRM boards, before that, NXP, before that, Cypress with PSOC4 Pioneer kit, before that... Heck, almost everyone did that, only few are brave or stupid enough to roll their own connectors. > > 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? Sorry, the association is as straight as thinking that every Intel box must be running MS-DOS and have enough-for-everyone 640KB of RAM. Actually, that's one of "criticism" all these boards receive, you can read nice rant from hard-soled bearded hardware hackers here: http://olimex.wordpress.com/2013/09/10/what-happens-when-the-engineers-listen-to-the-marketing-managers-or-why-arduino-cant-be-killed-by-all-these-new-arduino-killer-boards/ Note that I personally don't relate to such complaints in any way - I used to be young and stupid myself and wasted bunch of hard-earned icecream money on those "shields". So, now I can only enjoy ability to reuse them with bunch of other boards. *Hardware reuse*, nowhere would I expect to be dumbed with "Arduino libraries" - after all, the reason I get other boards is to get above the Arduino level. > 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 :-) Yeah, but my comment was regarding your proposal to take libopencm3 API and turn it into Arduino API. Why? Why can't you use libopencm3, or mbed, or some other API directly? There's nothing magic in Arduino API, and most other APIs are "better". > > > 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. Footprint is boon. "Library" - depends, per above. > > Best regards, > Trevor -- Best regards, Paul mailto:pmis...@gmail.com ------------------------------------------------------------------------------ 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
