[TriEmbed] Learning Curve

Thu Apr 23 11:25:20 CDT 2015

Hey Charles,

I believe your rambling is amazingly insightful. I am betting that ARM+mbed
OR a currently unknown player will become very important.

As you mention, re-creation of middleware and IDEs by every player is
holding back the market. The fact that every hardware platform had its own
steep learning curve is also an encumbrance to mass coder adoption.

I am personally excited by the potential of embedded Linux platforms that
are paired the MCUs for particular tasks.

Which hardware will make it through this paradigm shift from traditional
disconnected embedded to IoT? Could be one of the "maker" platforms :-)
On Thu, Apr 23, 2015 at 9:10 AM Charles West via TriEmbed <
triembed at triembed.org> wrote:

> Hello,
>
> This sort of maker/engineer transition is what I thought the ChibiOS board
> might be good for.  The main differences I've seen between amateur and
> professional work (I've done both) is that professional work cares more
> about final product cost (depending on the application), tends to use more
> advance microcontrollers/software concepts and will gladly use surface
> mount parts.
>
> Broad generalizations:
> Most Arduino users are comfortable with PWM, interrupts and basic program
> control structures (for loops, while, ifs etc).  More advanced users have
> learned how to connect to modules using UART, SPI, I2C and started learning
> the basics of serial protocols.  Really advanced users have started
> designing their own shields/PCBs and soldering.
>
> Advanced Arduino users (more professional makers) have most of the basics
> down but haven't really delved down into more advanced chips/chip features,
> such as sleeping to save power.  They also probably don't have the
> soldering capabilties to solder small surface mount parts (which locks them
> away from most newer parts unless they can find someone selling it attached
> to a breakout board).   They also (unless they come from a professional
> programming background) tend not to have experience with mutexes,
> semaphores and other multiprocess programming structures that are common on
> a desktop platform which makes RTOSes seem scary.  Getting a new chip to
> blink can also be difficult (since they generally can't just be plugged in
> via USB).  These factors can make it difficult for a maker to make the
> switch to making "professional" level work.  Some of these factors are
> changing, however, and I don't think it would be that hard to make
> something that bridges the gap.
>
> The fundamental difference between embedded programming and PC programming
> has been that every microcontroller is different from the others.  There
> have always been significant differences between part families and REALLY
> big differences between microcontrollers made by different manufactures.
> Each has different peripherals and different ways to tap into them.  Some
> have different memory architectures and require you to do stuff like paging
> to get access to the memory you need.  This is starting to change though.
>
> When I was just starting to work with microcontrollers, most hobbyists
> were working with 8 bit microcontrollers (AVRs primarily).  NC State's
> graduate course on embedded development used 16 bit microcontrollers which
> didn't have that much in common with the AVR chips I had learned with
> originally.  Both of them required substantial modification of the
> programming style I used with PCs if I didn't want to suffer pretty large
> performance penalties.  This changed with the first set up 32 bit ARM chips.
>
> Since they started out, ARM-Cortex M3/4/0 chips have had 32 bit processors
> so your PC code didn't need much modification to run on them.  The fact
> that the ARM-Cortex is just a design that different manufactures can drop
> into their product has resulted in pretty much every major manufacturer
> developing one or more lines of ARM-Cortex based chips.  While the
> peripherals may be a little different between part families, the core
> functionality/programming model is exactly the same (also, they tend to
> reuse at least half of the peripherals such as PIT timers).  This has made
> it so that you can learn 1-2 similar architectures and have access to the
> full range of peripherals/capabilities across MANY different
> manufacturers.  I think this trend will continue to make it much easier to
> start making "professional" level products by making the number of things
> that have to be learned much more manageable.
>
> At the core, a lot of what makes embedded development difficult is a lack
> of portable middleware (mostly due to the historic drastic architecture
> diversity).  I spent a lot of last summer developing code that was mostly
> drivers to make accessing the UART, ADC and I2C parts of our board easier.
> Once that was sorted out, it didn't take long to write the actual
> application.  The sad fact is that this sort of code is being written again
> and again by different companies developing for these products (mine
> certainly didn't wasn't released).  This is the sort of code that really
> should only be written once.
>
> Manufacturers try to make it easier, often by making custom IDEs for their
> products.  They write some code to make accessing peripherals on their
> chips easier, but they often don't have necessary features such as
> buffering (which generally requires an RTOS).  However, this really should
> be dealt with at the OS level (like it is with PCs).
>
> People like working with the Arduino because of the great community and
> because there are a lot of drop in libraries and solutions.  It is not that
> hard to get up and running.  I don't really see why we couldn't have a
> similar environment for more advanced chips with a similar level of
> portability.  This is why I find ChibiOS interesting.  It offers a fairly
> good hardware abstraction interface for the different peripherals on the
> microcontrollers it supports (UART, I2C, USB, etc).  I think that with a
> good community, a easy to get started with board (directly programmable via
> USB, which is provided out of the box by the STM32F042C4) and a bunch of
> tutorials we could see a very easy transition into professional level
> embedded development (particularly for software developers with
> multithreading experience).
>
> Even if that never happens, I think we are headed in a convergent
> direction due to the developments with ARM in recent years.
>
> Apologies if I have rambled.  What do you think?
>
> Thanks,
> Charlie West
>
>
>
> On Mon, Apr 20, 2015 at 9:46 AM, Craig Cook <cncook001 at yahoo.com> wrote:
>
>> I am on this journey as well.  I plan to present to the June Triembed
>> meeting on what I have learned over the last few months doing an edX course.
>>
>> This sounds close to what you are describing...
>>
>>
>> https://www.edx.org/course/embedded-systems-shape-world-utaustinx-ut-6-02x#.VSA6zOSA8yo
>>
>> Here is a link to the content we are working from (the labs are missing):
>>
>> http://users.ece.utexas.edu/~valvano/Volume1/E-Book/
>>
>>
>> I am scheduled to speak on the Ebmedded Systems podcast.  It will be
>> about the edX course and also how to learn embedded systems in general. (I
>> plan to read Elecia's book to compare the two).
>>
>> This is an interesting email thread for me.  I like the observations of
>> "Maker" vs "Engineer".  The edX course is on the Engineering side, but
>> certainly can be applied to Maker as well.
>>
>>
>> Craig
>>
>>
>>
>>
>> Subject:
>> Message-ID:
>>     <755683395.115518.1429535510177.JavaMail.yahoo at mail.yahoo.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>>
>> I think what Burr wrote defines my target audience perfectly!
>> If anyone else found themselves nodding along to what Burr wrote below,
>> please email me: I'd love to get more details on what people would like to
>> get out of an "Embedded Software 101" (and maybe 102, 201, etc...) class.
>> (My current target would be someone who has at least *some* programming
>> experience, but not necessarily a seasoned professional - a bit of Ruby,
>> Python, Javascript, etc. would be good enough.)
>> Thanks!
>> -svec
>>
>> _______________________________________________
>> Triangle, NC Embedded Computing mailing list
>> TriEmbed at triembed.org
>> http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
>> TriEmbed web site: http://TriEmbed.org
>>
>
> _______________________________________________
> Triangle, NC Embedded Computing mailing list
> TriEmbed at triembed.org
> http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
> TriEmbed web site: http://TriEmbed.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.triembed.org/pipermail/triembed_triembed.org/attachments/20150423/d029ef3c/attachment.htm>