http://forums.leaflabs.com/topic.php?id=9685 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:18:44 +0000 http://bbpress.org/?v=1.0.2 q http://forums.leaflabs.com/search.php http://forums.leaflabs.com/topic.php?id=9685&page=2#post-21367 Fri, 30 Nov 2012 13:26:35 +0000 gbulmer 21367@http://forums.leaflabs.com/ <p>StephenFromNYC - You are always welcome; I'm pleased to be of help.</p> <p>BYOB is much more interesting than Scratch! I think the OU might have started with BYOB instead of extending Scratch to make Sense, it BYOB had been around.<br /> IMHO Snap! is more interesting than proprietary and Flash-based (i.e proprietary platform) Scratch-like systems that run within the browser, for obvious reasons. If folks haven't tried Snap!, I strongly encourage them to have a look, even though it is 'Alpha' quality. </p> http://forums.leaflabs.com/topic.php?id=9685&page=2#post-21363 Fri, 30 Nov 2012 08:35:48 +0000 StephenFromNYC 21363@http://forums.leaflabs.com/ <p>Thanks!</p> <p>I am glad I asked, because the Build Your Own Blocks (BYOB) project was not one of the Snap! sites I found using Google.</p> <p>Now I understand why you find BYOB-Snap so appealing. Thanks for sharing the resource.</p> <p>Stephen from NYC </p> http://forums.leaflabs.com/topic.php?id=9685&page=2#post-21347 Thu, 29 Nov 2012 19:08:15 +0000 gbulmer 21347@http://forums.leaflabs.com/ <p>StephenFromNYC - <a href="http://byob.berkeley.edu/#snap4.0" rel="nofollow">http://byob.berkeley.edu/#snap4.0</a> </p> http://forums.leaflabs.com/topic.php?id=9685&page=2#post-21345 Thu, 29 Nov 2012 18:59:58 +0000 StephenFromNYC 21345@http://forums.leaflabs.com/ <p>@gbulmer,</p> <p>In an <a href="http://forums.leaflabs.com/topic.php?id=9685&amp;replies=16#post-21292">earlier post in this thread</a> you mentioned "Snap!" I found a few open source projects with Snap in their names, but it was not clear which one you were describing.</p> <p>I could post all my "Snap!" links here here, but I am afraid doing this (listing both the correct and incorrect links) could confuse the conversation.</p> <p>Can you give us the URL for the Snap! project you like?</p> <p>Thanks! </p> http://forums.leaflabs.com/topic.php?id=9685#post-21343 Thu, 29 Nov 2012 18:25:59 +0000 gbulmer 21343@http://forums.leaflabs.com/ <p>modkit -<br /> <blockquote>The larger discussion is "Pins as objects" towards a Wiring API 2.0 implementation/proposal. I agree this should be discussed in public. I was asking for your email as a way to "loop you in to the larger discussion" which would probably happen elsewhere as this is a larger discussion than the STM32 implementation mainly supported and discussed here.</p></blockquote> <p>So where is the "larger discussion" happening? </p> http://forums.leaflabs.com/topic.php?id=9685#post-21339 Thu, 29 Nov 2012 11:48:23 +0000 modkit 21339@http://forums.leaflabs.com/ <blockquote><p> I disagree with said direction (I also believe IOS is about the last thing I would like to see come out of this discussion). </p></blockquote> <p>I referred to IOS being built on top of a POSIX OS to say that we don't need to make decisions about a well formed API vs. easy implementation that can simply live on top of it. Let's not be polarized by IOS' restrictions or proprietary nature when discussing "easy" as IOS' ease of use is probably exactly where Android wants to end up.</p> <blockquote><p> "what is the best way to expose common microcontroller functionality (GPIO, USB, I2C, etc) at the lowest possible cross-device level "?</p> <p>Is the meat of it. I believe the obsession with oop is part of the problem (zb look at the arduino EEPROM library / reduced functionality increased overhead on top of a library that wasn't broken). I would like to see more stdlib like, c based work exposed (then when the foundations are built oop it up all you want) </p></blockquote> <p>You'll see we're looking at this the other way. We have a harder requirement (than anyone here has explained) for a C API (see first post) but are still advocating for C++ at the core. Why is that? We certainly don't have an obsession with OOP or even want to expose it to our Modkit Micro users. We're advocating for this because we think objects are the right way to organize pins at the low level.</p> <p>Wikipedia describes Objects as "data structures combined with the associated processing routines". Why do we need objects then? Because our C API (based on Wiring) abstracts the physical pins so that a single identifier (int/uint_8 - our "data") can be used to call the various peripheral functionality exposed on that pin (our "processing routines"). This would be fine as is except that the actual processing routines don't accept a single identifier when referencing the same physical pin for different uses. So you need to store this mapping somewhere. We think the "best" way to do this is directly from a pin object which keeps references to the various identifiers for the given pin's functionality. </p> <p>The original post we referred to starts to explore some of the reasons this could be more efficient than any non-class-based approach to pin mapping. If you're not interested in understanding why this can be the case, that's fine, but I believe the space and runtime efficiency of one approach vs. the other is provable so this is not a question of style or preference. </p> http://forums.leaflabs.com/topic.php?id=9685#post-21338 Thu, 29 Nov 2012 11:18:41 +0000 modkit 21338@http://forums.leaflabs.com/ <blockquote cite="gbulmer"><p> Please clarify the aims, goals, and terms of that 'larger discussion'.<br /> I don' understand why my experience and ideas might go to waste by discussing them here, in the open. Would you please clarify your rationale for saying that?<br /> I'd rather discuss this stuff in public so we can all benefit, or have some clear, up-front, explanation. </p></blockquote> <p>The larger discussion is "Pins as objects" towards a Wiring API 2.0 implementation/proposal. I agree this should be discussed in public. I was asking for your email as a way to "loop you in to the larger discussion" which would probably happen elsewhere as this is a larger discussion than the STM32 implementation mainly supported and discussed here.</p> <blockquote cite="gbulmer"><p> modkit - IMHO Snap! is a far better basis for my interests than Modkit because:<br /> 1. Snap! is Open Source. AFAICT modkit is proprietary, not Open Source.<br /> 2. Snap! is freely available at no cost, significantly less than $50 for 1 year for modkit. So anyone can use Snap!, now.<br /> 3. AFAIK Modkit has been in development since, at least, March, 2009; Snap! appears to have started mid 2011, so its 'velocity' is impressively high by comparison.</p> <p>There is already a prototype to connect Snap! to Arduino (not by the Snap! authors).<br /> Because Snap! is Open Source, making it work on different microcontrollers is not restricted to the authors; anyone can access the source and explore it. </p></blockquote> <p>Sorry, I think you have mistaken our background (why we care about Wiring etc) as promotion of our solutions. Our interest here is as the title states: Pins as objects - Wiring API 2.0. </p> <blockquote cite="gbulmer"><p> feurig - I wrote: I am okay with class-based solutions for low-level peripheral interfaces.</p> <p>But I should add that doing stuff in C is easier. There is a problem which I didn't mention, and which folks need to understand before assuming it is as easy to use C++ as C for low-level code.</p> <p>The problem is: all the Cortex-M3 interrupt vectors call a C function. There is no way to directly call a class method on a C++ object. There are quite a lot of implications from this for C++ development. </p></blockquote> <p>Right there are all of these implications that we'd like your input on. Modkit's own user API is C based so we're only really concerned about a better way to keep the low level "pin" to peripheral mapping for our own use case. But I think exploring a complementary C++ API would bring an even broader user base so I think it is worth identifying the issues and possible solutions.</p> <p>In any case, thanks again for all your comments. Of course discussing this in public is how we found your initial thoughts. </p> http://forums.leaflabs.com/topic.php?id=9685#post-21319 Wed, 28 Nov 2012 13:13:40 +0000 gbulmer 21319@http://forums.leaflabs.com/ <p>feurig - I wrote: <em>I am okay with class-based solutions for low-level peripheral interfaces.</em></p> <p>But I should add that doing stuff in C is easier. There is a problem which I didn't mention, and which folks need to understand before assuming it is as easy to use C++ as C for low-level code.</p> <p>The problem is: all the Cortex-M3 interrupt vectors call a C function. There is no way to <em>directly</em> call a class method on a C++ object. There are quite a lot of implications from this for C++ development.</p> <p>For C developers, it means that any C function can be called as an interrupt service routine on Cortex-M (there is no need to identify it as a <code>SIGNAL(...)</code> or <code>ISR(...)</code> handler in the code either). 'Simples' :-)</p> <p>For C++ developers it means that either an extra layer of code (e.g. something like an 'attach interrupt' mechanism), executed at run-time is needed, or some of the benefits of having multiple instances of a class object (to represent multiple instances of a peripheral device) can't be used because a signal handler would need to be 'static'. C++ has costs which IMHO are subtle. </p> <p>Fuerig, I am confident that you understand these issues. I am just raising them for anyone else reading this thread. </p> http://forums.leaflabs.com/topic.php?id=9685#post-21311 Tue, 27 Nov 2012 12:25:16 +0000 gbulmer 21311@http://forums.leaflabs.com/ <p>modkit<br /> <blockquote>Also could anyone interested in this direction (especially @siy and @gbulmer) please send me an email to ed [at] modk [dot] it, so we can loop you in to the larger discussion? We'd hate to see your experience and ideas go to waste! </p></blockquote> <p>Please clarify the aims, goals, and terms of that 'larger discussion'.<br /> I don' understand why my experience and ideas might go to waste by discussing them here, in the open. Would you please clarify your rationale for saying that?<br /> I'd rather discuss this stuff in public so we can all benefit, or have some clear, up-front, explanation. </p> http://forums.leaflabs.com/topic.php?id=9685#post-21294 Mon, 26 Nov 2012 20:45:31 +0000 gbulmer 21294@http://forums.leaflabs.com/ <p>feurig - <em>"I believe the obsession with oop is part of the problem"</em></p> <p>I might agree (about 70+%-), however, aside from the EEPROM example, have their been any other egregious uses of OOP?</p> <p>I think it is confusing to new users to have more than one syntax, <code>object.foo()</code> or <code>foo(pin, ...)</code>.<br /> As I've written before, one of my major concerns is the error messages from the compiler when code contains errors. These tend to become harder to understand when classes are used.</p> <p>I think the <code>foo(pin, ...)</code> syntax works very well with simple things like digital and analogue I/O where the pins get treated as pretty much independent; most of the documentation is on the board's silkscreen.</p> <p>It starts to get messier when trying to deal with peripheral resources shared by pins, or pins shared by peripherals. For example if you want to manipulate one of three ADC's that can sample a shared pin, or change which ADC is sampling the pin. It gets even worse when there are several peripheral on different pins, and alternative peripherals are only on specific pins. That is when some sort of abstraction other than an integer becomes useful. This isn't automatically inefficient, though (my) simple solutions tend to become pointers :-) </p> <p>I find it takes time and care to do a good job of an API no matter which approach is used. I need to write programs that use the API to get a feel for how it is working out. Those programs become the 'use cases' and 'integration tests' for the API.</p> <p>IMHO a problem is C++ class mechanisms are 'brittle' and create work if the class relationships aren't just right. But, I don't feel we should blame OOP for weaknesses in C++ or lack of care in design and implementation. OOP is a much bigger hammer than simple functions, so KISS applies even more so. </p> <p>Summary: I am okay with class-based solutions for low-level peripheral interfaces. However OOP is hard to do well, easy to mess up, hard to improve without breaking code, easy to over complicate, and only significantly help for complex peripheral hardware, or for flexibility, which often doesn't matter :-) </p> http://forums.leaflabs.com/topic.php?id=9685#post-21293 Mon, 26 Nov 2012 15:49:42 +0000 feurig 21293@http://forums.leaflabs.com/ <p>Modkit,</p> <p>I disagree with said direction (I also believe IOS is about the last thing I would like to see come out of this discussion). </p> <p>That said,</p> <p>"what is the best way to expose common microcontroller functionality (GPIO, USB, I2C, etc) at the lowest possible cross-device level "?</p> <p>Is the meat of it. I believe the obsession with oop is part of the problem (zb look at the arduino EEPROM library / reduced functionality increased overhead on top of a library that wasn't broken). I would like to see more stdlib like, c based work exposed (then when the foundations are built oop it up all you want) </p> <p>That is where I am headed. </p> http://forums.leaflabs.com/topic.php?id=9685#post-21292 Mon, 26 Nov 2012 12:44:16 +0000 gbulmer 21292@http://forums.leaflabs.com/ <p>modkit - IMHO Snap! is a far better basis for my interests than Modkit because:<br /> 1. Snap! is Open Source. AFAICT modkit is <em>proprietary</em>, <em>not</em> Open Source.<br /> 2. Snap! is freely available at no cost, significantly less than $50 for 1 year for modkit. So anyone can use Snap!, now.<br /> 3. AFAIK Modkit has been in development since, at least, March, 2009; Snap! appears to have started mid 2011, so its 'velocity' is impressively high by comparison.</p> <p>There is already a prototype to connect Snap! to Arduino (not by the Snap! authors).<br /> Because Snap! is Open Source, making it work on different microcontrollers is not restricted to the authors; anyone can access the source and explore it. </p> http://forums.leaflabs.com/topic.php?id=9685#post-21278 Sun, 25 Nov 2012 22:30:42 +0000 modkit 21278@http://forums.leaflabs.com/ <p>@feurig and @gbulmer - Thanks for your comments. I don't know the state of Maple/Arduino/Wiring on STM32 but there seemed to be some good ideas here for how to evolve the Wiring API so we thought we'd say hi. </p> <p>@feurig -We don't believe we need to choose between well formed and easy. We'd like to see the underlying Wiring APIs tightened up and to make use of the full power of C++ which is why we linked to the original post and the ideas of @gblumer and @siy which seem like the right direction. The main question here is what is the best way to expose common microcontroller functionality (GPIO, USB, I2C, etc) at the lowest possible cross-device level and then let all the other languages/platforms make use of those APIs. This is like the POSIX of the microcontroller world and we think Wiring can get there with a little help. Then in terms of well formed vs. easy we only need o remember that IOS is built on a POSIX OS. </p> <p>@gbulmer - We second the need for a threading/event system. As we're all about cross-device portability for 8, 16 and 32 bit micros, we were convinced that a low-overhead, non-stack-based, cooperative multithreading system like proto-threads would serve all common needs while being feasible on even the most constrained micros. Here's an implementation by our friend Daniel Ozick also has scratch-like events <a href="http://code.google.com/p/threadkit/" rel="nofollow">http://code.google.com/p/threadkit/</a> Also, snap looks cool but where's the microcontroller implementation? </p> http://forums.leaflabs.com/topic.php?id=9685#post-21274 Sat, 24 Nov 2012 20:57:40 +0000 feurig 21274@http://forums.leaflabs.com/ <p>Also agree about 2b. My experience with freertos on the maple was nightmarish and cost me about a man month. </p> http://forums.leaflabs.com/topic.php?id=9685#post-21273 Sat, 24 Nov 2012 20:48:57 +0000 feurig 21273@http://forums.leaflabs.com/ <p>At present I am looking at CMSIS v2 or 3 and better new lib integration, c based, BSD/MIT licsensed (I am tired of rewriting code that is vendor closed or gpl3 open -- and therefore useless ), thinking about taking the wiring-s, stm32f[0-1], and the lpc1114 as base platforms and seeing if I can come up with a coherent way of doing i/o, a couple of tasks, and error handling for my own projects. </p> <p>The maple is a pretty good case study for porting the arduino to the arm and frankly I am not as pleased with it as I should be. The team is bright the design is conservative but I think the arduino/wiring and object orientation are at the core of the issues.</p> <p>So yeah as someone who has been teaching on this platform for 5 years now and doing professional projects with it for another 3, I am finding myself thinking its time for something a little less easy to but a little better formed. </p> <p>On the arduino side we were backed up by Weddington and Wuenches avrlibc combined with gcc on all major platforms so I could get away with writing hybrids where you prototype with the arduino stuff and rewrite it (most of the arduino stuff works but thats about it) until it is something stable if it needed to be more than a prototype.</p> <p>On the arm side there is no open source equivalent (newlib is close but mostly a retrofit), every vendor has their own way of doing things, and a lot of venders code isn't portable between families of their own arm derivatives (look at nxp for ample examples). This weekend I just got my stellaris launchpad programmed on osx and I looked at the deep pile of work that it would take to make it usefull without just using ti's codebase and I put it back in the box. </p>