I'm writing a chapter for a book targeted for self-paced
students (who may have some taken as much as a year or two of
programming at a community college, but also may have very
little experience and only enough to know they are interested
in trying to perform some small embedded tasks but have no
idea how to start out.)

The chapter is intended to help them consider different
demo/educational boards to purchase and will list out the
features, estimated cost, difficulty level, and so on. I will
buy each of these and work through them for some tasks I have
in mind and then write about the experience of each so that
there is some context for the reader to make their own
decisions about what serves them better.

It will not be comprehensive and I will probably NOT include
systems that are either very expensive (over $200 would be
certainly be "very expensive"), very difficult to find and
buy, deals with unobtanium or boutique parts, or where it is
very complex to learn the tools needed to get even the
simplest programs running on them. The microcontrollers
should be "mainstream" __hobbyist__ parts, by and large. And
nothing where only BGA packaging is available, for example.

The broader goals (beyond this chapter) are to help people
who don't even know well what questions to ask, but who
imagine they have an interest in embedded programming, in
getting past the initial hurdles of self education needed to
be successful for the first time doing something with results
they care about and are proud of achieving. To then explore
more whether or not this is a path they want to continue on.
And finally to develop some of the specific (but basic)
skills needed generally when facing some new problem that I
cannot predict. To create the skill base they need in order
to navigate the web, understand enough of what they read
there on their own that when solving new problems that are
somewhat novel they have a decent chance of pushing through
on their own to some kind of modest success in the end.. or
know how to frame questions detailed enough that the answers
they get may be helpful.

I'd appreciate any specific suggestions (and any context you
are motivated to provide.) It would help me a lot in
developing a modern list. I expect to revisit it before
finalizing things, so this is an early survey that will need
to be re-examined at the end of the process (and probably
revised over and over as time proceeds.) But I expect enough
of it will remain useful for long enough of a time, too. So
it is worth doing up front to help me inform the content of
chapters that follow, as well. And I think the value of that
will be more enduring than the specific boards may be.

Jon

Jon Kirwan wrote:

> I'm writing a chapter for a book targeted for self-paced
> students [ ... ]

 This is going to be a big chapter.  Seems to me that every week the blog at 
dangerousprototypes.com lists a new development board announcement from some 
manufacturer or other.  Development boards have come to be the flavour of 
the month with chip manufacturers.

Lattice Semiconductor: 
<http://dangerousprototypes.com/2012/09/19/latticesemi-offers-discounted-
fpga-dev-boards/>

Stellaris: <http://dangerousprototypes.com/2012/09/16/stellaris-lm4f120-
launchpad-evaluation-board-pre-orders-open/>

Somebody else: <http://dangerousprototypes.com/2012/09/12/olinuxino-micro-
arm9-linux-board-available-at-mouser/>

Digilent: <http://dangerousprototypes.com/2012/09/06/giveaway-another-
chipkit-uc-32-and-chipkit-wifi-shield-2/>

Renesas: <http://dangerousprototypes.com/2012/08/07/renesas-rx62n-demo-kit-
promotion/>

Then the old standby Arduino and the new standby Raspberry Pi.

And the cost-reduced Beagleboard, the Beaglebone: 
<http://beagleboard.org/bone>

And at least 3 STM32*DISCOVERY boards from ST.

And somehow I missed those little old MSP430 boards from TI.

 ... 

	Mel.

In article <t...@4ax.com>, 
j...@infinitefactors.org says...
> 
> I'm writing a chapter for a book targeted for self-paced
> students (who may have some taken as much as a year or two of
> programming at a community college, but also may have very
> little experience and only enough to know they are interested
> in trying to perform some small embedded tasks but have no
> idea how to start out.)
> 
> The chapter is intended to help them consider different
> demo/educational boards to purchase and will list out the
> features, estimated cost, difficulty level, and so on. I will
> buy each of these and work through them for some tasks I have
> in mind and then write about the experience of each so that
> there is some context for the reader to make their own
> decisions about what serves them better.
> 
> It will not be comprehensive and I will probably NOT include
> systems that are either very expensive (over $200 would be
> certainly be "very expensive"), very difficult to find and
> buy, deals with unobtanium or boutique parts, or where it is
> very complex to learn the tools needed to get even the
> simplest programs running on them. The microcontrollers
> should be "mainstream" __hobbyist__ parts, by and large. And
> nothing where only BGA packaging is available, for example.
> 
> The broader goals (beyond this chapter) are to help people
> who don't even know well what questions to ask, but who
> imagine they have an interest in embedded programming, in
> getting past the initial hurdles of self education needed to
> be successful for the first time doing something with results
> they care about and are proud of achieving. To then explore
> more whether or not this is a path they want to continue on.
> And finally to develop some of the specific (but basic)
> skills needed generally when facing some new problem that I
> cannot predict. To create the skill base they need in order
> to navigate the web, understand enough of what they read
> there on their own that when solving new problems that are
> somewhat novel they have a decent chance of pushing through
> on their own to some kind of modest success in the end.. or
> know how to frame questions detailed enough that the answers
> they get may be helpful.
> 
> I'd appreciate any specific suggestions (and any context you
> are motivated to provide.) It would help me a lot in
> developing a modern list. I expect to revisit it before
> finalizing things, so this is an early survey that will need
> to be re-examined at the end of the process (and probably
> revised over and over as time proceeds.) But I expect enough
> of it will remain useful for long enough of a time, too. So
> it is worth doing up front to help me inform the content of
> chapters that follow, as well. And I think the value of that
> will be more enduring than the specific boards may be.
> 
> Jon

I would vote for the STM32 Discovery boards.   The include not
only STM32 processor, but a built-in ST-Link programmer.

$8 to $15 qty 1 at Digikey. Hundreds in stock.

Free Windows tools available for up to 32K of code or with time-limited
demos if you want to save your students the trouble of setting 
up a GNU-ARM system.

Mark Borgerson

On 2012-09-26, Jon Kirwan <j...@infinitefactors.org> wrote:
> I'm writing a chapter for a book targeted for self-paced
> students (who may have some taken as much as a year or two of
> programming at a community college, but also may have very
> little experience and only enough to know they are interested
> in trying to perform some small embedded tasks but have no
> idea how to start out.)
>

I'm a commercial programmer/sys admin by day and a electronics/embedded
hobbyist by night.

> The chapter is intended to help them consider different
> demo/educational boards to purchase and will list out the
> features, estimated cost, difficulty level, and so on. I will
> buy each of these and work through them for some tasks I have
> in mind and then write about the experience of each so that
> there is some context for the reader to make their own
> decisions about what serves them better.
>
> It will not be comprehensive and I will probably NOT include
> systems that are either very expensive (over $200 would be
> certainly be "very expensive"), very difficult to find and
> buy, deals with unobtanium or boutique parts, or where it is
> very complex to learn the tools needed to get even the
> simplest programs running on them. The microcontrollers
> should be "mainstream" __hobbyist__ parts, by and large. And
> nothing where only BGA packaging is available, for example.
>

If they are buying a standard board, why does it matter if it's
a BGA package on the board ?

Are you trying to get them interested in programming existing
boards, or in building boards from scratch ?

The boards I work with fall into one of two categories. First,
(for the small/simple requirements stuff), I just use a 8-bit
microcontroller in a PDIP package and build the board myself
using through hole components placed on veroboard.

When I need a board where the MCU is not available in PDIP (such as
ARM), I just buy a standard board from someone like Olimex. I will
not be modifying these boards and will interface to them via the
existing interfaces on the board.

For me, "hobbyist friendly" just means been able to obtain all the
information about the components on the board without having to sign
some NDA and been able to easily (ie: cheaply :-)) interface with the
board for programming. If I have decided to buy a board, I don't care
what component packaging is in use on the board.

> The broader goals (beyond this chapter) are to help people
> who don't even know well what questions to ask, but who
> imagine they have an interest in embedded programming, in
> getting past the initial hurdles of self education needed to
> be successful for the first time doing something with results
> they care about and are proud of achieving. To then explore
> more whether or not this is a path they want to continue on.
> And finally to develop some of the specific (but basic)
> skills needed generally when facing some new problem that I
> cannot predict. To create the skill base they need in order
> to navigate the web, understand enough of what they read
> there on their own that when solving new problems that are
> somewhat novel they have a decent chance of pushing through
> on their own to some kind of modest success in the end.. or
> know how to frame questions detailed enough that the answers
> they get may be helpful.
>

I've mentioned this before, but different people have different
things they are comfortable with. For example, I only work with
PDIP sized components on my own boards, but OTOH, I am quite
capable of creating a BSP or protocol stack as required (and I
enjoy doing so as well :-) ).

Another person may be very comfortable with the hardware side
of things and think nothing of building custom PCBs using SMD
components, but when it comes to the software may strongly
prefer to work with already existing software libraries because
they are not comfortable writing drivers or protocol stacks.

You need to make sure what the interests of your potential
hobbyists are.

Simon.

-- 
Simon Clubley, c...@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

On Wed, 26 Sep 2012 17:49:47 -0400, Mel Wilson
<m...@the-wire.com> wrote:

>Jon Kirwan wrote:
>
>> I'm writing a chapter for a book targeted for self-paced
>> students [ ... ]
>
> This is going to be a big chapter.

They all start out big. Then the job is to winnow the damned
things down so that a human can actually look at it and
imagine they can read it.

So yeah, the chapter will start out with 1000 pages of
research and then I work it down to a few tens of pages of
concentrated information hopefully written in accessible
language to neophytes.

I know.  "Good luck."

>Seems to me that every week the blog at 
>dangerousprototypes.com lists a new development board announcement from some 
>manufacturer or other.  Development boards have come to be the flavour of 
>the month with chip manufacturers.

Yeah. Tell me about it.

>Lattice Semiconductor: 
><http://dangerousprototypes.com/2012/09/19/latticesemi-offers-discounted-
>fpga-dev-boards/>
>
>Stellaris: <http://dangerousprototypes.com/2012/09/16/stellaris-lm4f120-
>launchpad-evaluation-board-pre-orders-open/>
>
>Somebody else: <http://dangerousprototypes.com/2012/09/12/olinuxino-micro-
>arm9-linux-board-available-at-mouser/>
>
>Digilent: <http://dangerousprototypes.com/2012/09/06/giveaway-another-
>chipkit-uc-32-and-chipkit-wifi-shield-2/>
>
>Renesas: <http://dangerousprototypes.com/2012/08/07/renesas-rx62n-demo-kit-
>promotion/>
>
>Then the old standby Arduino and the new standby Raspberry Pi.

Arduino is a book (or three) by itself. It will get a
mention.

>And the cost-reduced Beagleboard, the Beaglebone: 
><http://beagleboard.org/bone>

Thanks for the above. I'll look them over.

>And at least 3 STM32*DISCOVERY boards from ST.

Yes, at least the cheapest one of those goes into the book.
(Cost me $10.)

>And somehow I missed those little old MSP430 boards from TI.

LaunchPad, for sure, of course.

Thanks,
Jon

On Wed, 26 Sep 2012 15:31:41 -0700, Mark Borgerson
<m...@comcast.net> wrote:

>I would vote for the STM32 Discovery boards.   The include not
>only STM32 processor, but a built-in ST-Link programmer.

Already have about 5 of them. And yes, they are going into
the chapter. I consider the development tools just a bit
daunting. But not overly so. So it goes in.

>$8 to $15 qty 1 at Digikey. Hundreds in stock.

Yeah. I think I paid $10.

>Free Windows tools available for up to 32K of code or with time-limited
>demos if you want to save your students the trouble of setting 
>up a GNU-ARM system.

I'm still undecided about how I'm going to handle limited
compiler tools. I absolutely dislike telling people to use
tools that will, someday after months or years of hard work
and investment of personal time, come back to bite them in
the butt when they are ready to do more.

I happen to very much appreciate IAR's C/C++ IDE. It's very
easy to learn to use, laid out nice, and just works (mostly,
except arguably not so well on 64-bit O/S where it is
possible that the reason isn't IAR but TI regarding the USB
drivers.) And it will handle all of the "value" parts from TI
without trouble and without charge (kickstart.)

But the complexity comes in several flavors. One is that TI
provides certain versions of kickstart and IAR's own web
sites provide other versions of kickstart, sometimes with
slightly different rules. Another is that if one decides to
use a larger part (non-value-line), then ponying up the HUGE
expense for the compiler is prohibitive and I would probably
be committing malpractice in suggesting that they invest all
that time in the kickstart toolset when also knowing full
well that I may also be putting them into a terrible catch-22
situation later on.

The GNU tools work well also only for a subset (not with the
8051 core, so far as I'm aware) and, as you suggest, there
are many very different approaches to setting it up well (or
at all.) So this is probably something I'm going to have to
bite off and somehow do a good job of it (which means a lot
of work and trial and error for me trying it out in many
different ways before deciding how to write about it.)

Jon

On Thu, 27 Sep 2012 00:24:16 +0000 (UTC), Simon Clubley
<c...@remove_me.eisner.decus.org-Earth.UFP> wrote:

>On 2012-09-26, Jon Kirwan <j...@infinitefactors.org> wrote:
>> I'm writing a chapter for a book targeted for self-paced
>> students (who may have some taken as much as a year or two of
>> programming at a community college, but also may have very
>> little experience and only enough to know they are interested
>> in trying to perform some small embedded tasks but have no
>> idea how to start out.)
>
>I'm a commercial programmer/sys admin by day and a electronics/embedded
>hobbyist by night.

I'm sure there are many similar situations to that.

>> The chapter is intended to help them consider different
>> demo/educational boards to purchase and will list out the
>> features, estimated cost, difficulty level, and so on. I will
>> buy each of these and work through them for some tasks I have
>> in mind and then write about the experience of each so that
>> there is some context for the reader to make their own
>> decisions about what serves them better.
>>
>> It will not be comprehensive and I will probably NOT include
>> systems that are either very expensive (over $200 would be
>> certainly be "very expensive"), very difficult to find and
>> buy, deals with unobtanium or boutique parts, or where it is
>> very complex to learn the tools needed to get even the
>> simplest programs running on them. The microcontrollers
>> should be "mainstream" __hobbyist__ parts, by and large. And
>> nothing where only BGA packaging is available, for example.
>
>If they are buying a standard board, why does it matter if it's
>a BGA package on the board ?

Because the "audience" is not solely for those who will use
standard boards. Many want to move beyond that stage. If the
part is ONLY available in BGA (often meaning 100's of pins,
which puts it outside my scope anyway) then this cuts off
many. I want to focus on parts that at least have the chance
of coming in other packaging.

>Are you trying to get them interested in programming existing
>boards, or in building boards from scratch ?

It's up to the reader. I'd like to address both groups.

>The boards I work with fall into one of two categories. First,
>(for the small/simple requirements stuff), I just use a 8-bit
>microcontroller in a PDIP package and build the board myself
>using through hole components placed on veroboard.
>
>When I need a board where the MCU is not available in PDIP (such as
>ARM), I just buy a standard board from someone like Olimex. I will
>not be modifying these boards and will interface to them via the
>existing interfaces on the board.

Yeah. Sounds like much of what I do, too.

>For me, "hobbyist friendly" just means been able to obtain all the
>information about the components on the board without having to sign
>some NDA and been able to easily (ie: cheaply :-)) interface with the
>board for programming. If I have decided to buy a board, I don't care
>what component packaging is in use on the board.

If you know of a chip that deserves consideration and is ONLY
found in BGA, let me know. I'll take a look. Maybe you are
right.

>> The broader goals (beyond this chapter) are to help people
>> who don't even know well what questions to ask, but who
>> imagine they have an interest in embedded programming, in
>> getting past the initial hurdles of self education needed to
>> be successful for the first time doing something with results
>> they care about and are proud of achieving. To then explore
>> more whether or not this is a path they want to continue on.
>> And finally to develop some of the specific (but basic)
>> skills needed generally when facing some new problem that I
>> cannot predict. To create the skill base they need in order
>> to navigate the web, understand enough of what they read
>> there on their own that when solving new problems that are
>> somewhat novel they have a decent chance of pushing through
>> on their own to some kind of modest success in the end.. or
>> know how to frame questions detailed enough that the answers
>> they get may be helpful.
>
>I've mentioned this before, but different people have different
>things they are comfortable with. For example, I only work with
>PDIP sized components on my own boards, but OTOH, I am quite
>capable of creating a BSP or protocol stack as required (and I
>enjoy doing so as well :-) ).
>
>Another person may be very comfortable with the hardware side
>of things and think nothing of building custom PCBs using SMD
>components, but when it comes to the software may strongly
>prefer to work with already existing software libraries because
>they are not comfortable writing drivers or protocol stacks.
>
>You need to make sure what the interests of your potential
>hobbyists are.

I'm trying to make this broadly useful, audience wise. I'm
intentionally NOT limiting the audience to some specific set
of interests, just yet.

There is another element to this. The business model isn't
just a book or two. There is much more to it -- including
week long, intensive classwork targeted at several different
tiers of experience, age, and backgrounds. From high school
students to professionals needing a concentrated learning
experience with professional tools available in order to
master some specialized area.

I'm still struggling to see how all this precipitates in the
end and I frankly expect to be surprised where the research
and effort takes me in the end. This chapter fits into a
larger context. But I'm not going to solve everything up
front, either. The production will be in stages, over years
of time. This small bite is the step I take today. But there
is a vision, as well.

Jon

On 27/09/2012 03:15, Jon Kirwan wrote:
> if one decides to
> use a larger part (non-value-line), then ponying up the HUGE
> expense for the compiler is prohibitive and I would probably
> be committing malpractice in suggesting that they invest all
> that time in the kickstart toolset when also knowing full
> well that I may also be putting them into a terrible catch-22
> situation later on.

Tbh I think you are exagerating a little here, Jon.  It's a fact of life for 
embedded engineering that the tools cost money and learning your way around 
different toolsets is also something that all future engineers have to get used 
to.

I'd pick a toolset that suits the material you're teaching (and imho lots of 
attention to things like execution tracing is in order here) and not worry too 
much about what your proteges will have to do once they spread their wings.  A 
polished but restricted toolset will mean fewer excursions into confusing setup 
details at at time when complexity will be not appreciated.  You could always 
put the gnu tools into an addendum or appendix if you want to offer them an 
alternative route.

Best of luck,

Boo

Jon Kirwan wrote:

> I'm writing a chapter for a book targeted for self-paced
> students (who may have some taken as much as a year or two of
> programming at a community college, but also may have very
> little experience and only enough to know they are interested
> in trying to perform some small embedded tasks but have no
> idea how to start out.)
> 
> The chapter is intended to help them consider different
> demo/educational boards to purchase and will list out the
> features, estimated cost, difficulty level, and so on. I will
> buy each of these and work through them for some tasks I have
> in mind and then write about the experience of each so that
> there is some context for the reader to make their own
> decisions about what serves them better.
> 
> It will not be comprehensive and I will probably NOT include
> systems that are either very expensive (over $200 would be
> certainly be "very expensive"), very difficult to find and
> buy, deals with unobtanium or boutique parts, or where it is
> very complex to learn the tools needed to get even the
> simplest programs running on them. The microcontrollers
> should be "mainstream" __hobbyist__ parts, by and large. And
> nothing where only BGA packaging is available, for example.
> 
> The broader goals (beyond this chapter) are to help people
> who don't even know well what questions to ask, but who
> imagine they have an interest in embedded programming, in
> getting past the initial hurdles of self education needed to
> be successful for the first time doing something with results
> they care about and are proud of achieving. To then explore
> more whether or not this is a path they want to continue on.
> And finally to develop some of the specific (but basic)
> skills needed generally when facing some new problem that I
> cannot predict. To create the skill base they need in order
> to navigate the web, understand enough of what they read
> there on their own that when solving new problems that are
> somewhat novel they have a decent chance of pushing through
> on their own to some kind of modest success in the end.. or
> know how to frame questions detailed enough that the answers
> they get may be helpful.
> 
> I'd appreciate any specific suggestions (and any context you
> are motivated to provide.) It would help me a lot in
> developing a modern list. I expect to revisit it before
> finalizing things, so this is an early survey that will need
> to be re-examined at the end of the process (and probably
> revised over and over as time proceeds.) But I expect enough
> of it will remain useful for long enough of a time, too. So
> it is worth doing up front to help me inform the content of
> chapters that follow, as well. And I think the value of that
> will be more enduring than the specific boards may be.
> 
> Jon


Hi John,

For the really beginner hobbyist the TI Launchpad with MSP430 would seem 
like a suitable starter. Once the application is developed for the MSP430 it 
can be transferred to another board custom for the hobbyists application 
with it. With the Launchpad, and loading 4E4th onto it he could be up and 
running very quickly into an application programme.

There are others like Arduino and PIC's that may also be suitable candidates 
but I would probably stick to the smaller processor set in that chapter.

-- 
********************************************************************
Paul E. Bennett...............<email://P...@topmail.co.uk>
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

On Thu, 27 Sep 2012 10:35:51 +0100, Boo
<r...@spam_me_no_spam.net> wrote:

>On 27/09/2012 03:15, Jon Kirwan wrote:
>> if one decides to
>> use a larger part (non-value-line), then ponying up the HUGE
>> expense for the compiler is prohibitive and I would probably
>> be committing malpractice in suggesting that they invest all
>> that time in the kickstart toolset when also knowing full
>> well that I may also be putting them into a terrible catch-22
>> situation later on.
>
>Tbh I think you are exagerating a little here, Jon.  It's a fact of life for 
>embedded engineering that the tools cost money and learning your way around 
>different toolsets is also something that all future engineers have to get used 
>to.

One of the prime targets is high school students and
hobbyists, not professionals. There is the hope in what I do
that it will perhaps be ALSO useful for professionals. But
that is not yet in the plan.

>I'd pick a toolset that suits the material you're teaching (and imho lots of 
>attention to things like execution tracing is in order here) and not worry too 
>much about what your proteges will have to do once they spread their wings.  A 
>polished but restricted toolset will mean fewer excursions into confusing setup 
>details at at time when complexity will be not appreciated.  You could always 
>put the gnu tools into an addendum or appendix if you want to offer them an 
>alternative route.
>
>Best of luck,

I generally take your comments above positively. There is
much in favor of getting started quicker/easier and moving
ahead without getting bogged down. But I also have to weigh
other factors and create some balance. I do NOT consider this
is an easy answer. I am going to spend some time thinking
hard about my choices. When I make them, I will be able to
justify what I've done. For now, I'm still just slogging
through.

Jon