[TriEmbed] Learning Curve

Charles West crwest at ncsu.edu
Thu Apr 23 11:10:47 CDT 2015


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.triembed.org/pipermail/triembed_triembed.org/attachments/20150423/cbae1e1c/attachment.htm>


More information about the TriEmbed mailing list