Okay. Just to start off the list of candidate processors for
educational purposes and writing up various considerations
for them, let me offer this because then folks will say "you
missed this.." and "what about that?", but also because I
probably don't have my details right anyway and need
corrections where they apply.

In the 8-bit world, it's probably better to stay with well
worn hobbyist families (while avoiding the 8051, do you
think?) such as:
-- The Microchip PIC (up through PICF18?) I've been informed
about an extended variety of these, as well.
-- Atmel AVR (AT90) and ATmega and ATtiny.

Any other "well worn" paths you'd consider important to
include in the list before winnowing it back down?

I'm avoiding Renesas R8 (not well worn, in my mind.)

In the 16-bit world, I think I'm pretty much stuck with Texas
Instruments' MSP430. Cheap to get starter kits, widely
available, decent part, etc.

In the 32-bit world, I'm considering the (huge) ARM family of
parts (ARM7, ARM7TDMI, Cortex M0, Cortex M4, even ARM9 [okay,
some of them actually have a trace buffer in them and cripes
I can't beat that for "nice to have."]) In this area,
Freescale and Texas Instruments have certainly been
mentioned. Keep in mind I'm looking for starter kits that
exist, are generally available, and representative enough to
be worth considering. I'm also considering the MIPS M4k
(Microchip's incarnation, anyway... and I wonder if now that
Microchip bought rights to the M14k if something there will
be showing up soon at Microchip .. need to spy on their
Gresham fab, I think.)

It's fun to read about the MIPS vs ARM wars. Here's one link:

http://ww1.microchip.com/downloads/en/DeviceDoc/MD00795-2B-MCU-WHP-01%2001.pdf

For ARM, GNU is the tool of choice, I suspect. It's decent,
updated often, is definitely a "well worn path", and can be
had for free from CodeSourcery as a free compiler, updated
twice a year, without any code or data limitations. I would
most definitely also like to consider IAR's kickstart, as the
IDE is decent and I have experience with it. It's limited to
32k, but that's enough for a lot to get done. But I'd
consider anything else, as well; but please list out some of
the reasons you like it, if you can.

There seem to be reasonably priced starter boards for various
ARM and PIC32, some of these come with BASIC installed. I'm
still thinking about that option (BASIC), as it is a good
access level for many people (depends upon their goals and
interests and skills and available time, of course.)

Jon

> It's fun to read about the MIPS vs ARM wars. Here's one link:
> 
> 
> 
> http://ww1.microchip.com/downloads/en/DeviceDoc/MD00795-2B-MCU-WHP-01%2001.pdf
> 
>

and more here, as well as some at S.E.D.

I was thinking about a new thread or highjacking yours.  Well, here it goes:

I know there are many anti-PIC-er here,
but we need to learn more what and why not to PICk PIC.
The world would be too boring to be all ARMs.

Yes, I plan to control the HVAC with PIC.
However, i need to get the temperature logger working first.
Running at 80MHz heat up the CPU and the thermosistor,
not to mension shortening the battery life.

So, instead of running 7 million Nop() per second,

	for(i=0; i<7000000; i++)
		Nop();

I need to use timer and interrupt.  How do i set direction (up or down)
and overflow interrupt?  Timer 1 can run in idle mode.

	OpenTimer1( T1_ON | T1_IDLE_CON | T1_PS_1_256 | T1_SOURCE_INT, 0xFFFF);
	ConfigIntTimer1(T1_INT_ON | T1_INT_PRIOR_7);
	WriteTimer1(100);
	mT1IntEnable(1);
	INTEnableInterrupts();
	PowerSaveIdle();		// get out of here
	INTDisableInterrupts();
	mT1IntEnable(0);

Not working yet, what's wrong with my code?

Project source code at:

http://173.224.223.62/pic32

----------------------------------------------------------------

Top ten reasons not to use PIC32.

10. Don't have Microchip stocks.
9. Don't work for Microchip.
8. Microchip doesn't pay me for writing reviews.
7. Microchip is too close to home, no trips.
6. Can't charge too much for designing PIC stuffs.

5. Can't use more than 2 of the 6 serial ports.
4. Can't reprogram the chip runing at 150MHz.
3. Takes forever (minutes) to program 512K flash.
2. Can't get client to switch processor.
1. Can't think of any other reason.

On 2012-10-05, Jon Kirwan <j...@infinitefactors.org> wrote:
> Okay. Just to start off the list of candidate processors for
> educational purposes and writing up various considerations
> for them, let me offer this because then folks will say "you
> missed this.." and "what about that?", but also because I
> probably don't have my details right anyway and need
> corrections where they apply.
>

You also have a stated goal of trying to get people to build their
own circuits. With that in mind, I think you should discuss PDIP
based MCUs much more heavily than you might otherwise would.

If you are trying to get someone interested enough to build circuits,
you are much more likely to succeed if they can assemble something
quickly and easily on a breadboard or veroboard and watch it work.

After those initial experiences, you stand a better chance of getting
them interested in the extra work involved in PCB based circuits
(assuming they actually need to move to creating their own PCBs).

> In the 8-bit world, it's probably better to stay with well
> worn hobbyist families (while avoiding the 8051, do you
> think?) such as:
> -- The Microchip PIC (up through PICF18?) I've been informed
> about an extended variety of these, as well.
> -- Atmel AVR (AT90) and ATmega and ATtiny.
>

You do not want the 8-bit PICs to be the first MCU a person new to
this world uses.

In addition to the lousy instruction set (which I admit does not
matter nearly as much when programming in a HLL) there are other
issues such as it's very limited interrupt support.

In the 8-bit PICs, you have to funnel everything down one of two
interrupts (for the high end MCUs) or just one (for everything else)
which means you have to check all interrupt sources in the one handler.

The AVR however has a much cleaner interrupt architecture and allows
you to easily write standalone device libraries whose various components
do not have to interact with each other.

To achieve this on the 8-bit PICs, I had to write a little interrupt
handler library which my device handlers could register themselves
with and the interrupt handler in this library would call the appropriate
device handler when required.

In other words, I had to implement in software what you get for free in
the MCU hardware on the AVR.

You want to pick as clean a architecture as possible for a first MCU,
and the AVR is far cleaner than the 8-bit PICs.

As for why I have used 8-bit PICs if I feel this way ? Answer: It has
USB device in PDIP and the AVR does not. (Either :-) or :-( depending
on your frame of mind. :-))

> Any other "well worn" paths you'd consider important to
> include in the list before winnowing it back down?
>

Those are the only ones which come to mind for me. I did start out with
the HC08 MCUs, but I outgrew those at least 5-6 years ago.

>
> In the 32-bit world, I'm considering the (huge) ARM family of
> parts (ARM7, ARM7TDMI, Cortex M0, Cortex M4, even ARM9 [okay,
> some of them actually have a trace buffer in them and cripes
> I can't beat that for "nice to have."]) In this area,
> Freescale and Texas Instruments have certainly been
> mentioned. Keep in mind I'm looking for starter kits that
> exist, are generally available, and representative enough to
> be worth considering. I'm also considering the MIPS M4k
> (Microchip's incarnation, anyway... and I wonder if now that
> Microchip bought rights to the M14k if something there will
> be showing up soon at Microchip .. need to spy on their
> Gresham fab, I think.)
>

The PIC32MX is a seriously interesting part if you want people to build
their own circuits and want something more powerful than a 8-bit device.

> It's fun to read about the MIPS vs ARM wars. Here's one link:
>
> http://ww1.microchip.com/downloads/en/DeviceDoc/MD00795-2B-MCU-WHP-01%2001.pdf
>

I've only had a quick look at the first part of that document, but some
of the disadvantages for ARM can be relabeled as advantages with the
right mind set. :-)

For example, it says that MIPS can get higher clock speeds more easily
because of simpler instructions. You could turn that around and say you
can do more in one ARM instruction than you can in a MIPS instruction
and hence ARM could be considered quicker that way. :-)

(Note: that was a good natured comment. I have not actually written
any MIPS code yet, but the instruction set looks reasonably clean and
I will reserve forming opinions until I have experience in both
architectures.)

> For ARM, GNU is the tool of choice, I suspect. It's decent,
> updated often, is definitely a "well worn path", and can be
> had for free from CodeSourcery as a free compiler, updated
> twice a year, without any code or data limitations. I would
> most definitely also like to consider IAR's kickstart, as the
> IDE is decent and I have experience with it. It's limited to
> 32k, but that's enough for a lot to get done. But I'd
> consider anything else, as well; but please list out some of
> the reasons you like it, if you can.
>

Does CodeSourcery offer a front end to gdb ? I build my own tool chains
from source and I am currently using ddd as a gdb front end.

Simon.

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

On Fri, 5 Oct 2012 17:51:43 +0000 (UTC), Simon Clubley
<c...@remove_me.eisner.decus.org-Earth.UFP> wrote:

>On 2012-10-05, Jon Kirwan <j...@infinitefactors.org> wrote:
>> Okay. Just to start off the list of candidate processors for
>> educational purposes and writing up various considerations
>> for them, let me offer this because then folks will say "you
>> missed this.." and "what about that?", but also because I
>> probably don't have my details right anyway and need
>> corrections where they apply.
>
>You also have a stated goal of trying to get people to build their
>own circuits. With that in mind, I think you should discuss PDIP
>based MCUs much more heavily than you might otherwise would.

I do have that goal.... for some. Many will never do that. I
want this to be accessible and useful to both groups.

>If you are trying to get someone interested enough to build circuits,
>you are much more likely to succeed if they can assemble something
>quickly and easily on a breadboard or veroboard and watch it work.

The quandary there is that while I really would like to
interest them in doing that, I also can't expect that
everyone wants to or ever will want to.

But that said, I agree with the way you said your comment
(for those you are talking about.)

>After those initial experiences, you stand a better chance of getting
>them interested in the extra work involved in PCB based circuits
>(assuming they actually need to move to creating their own PCBs).

Yup.

>> In the 8-bit world, it's probably better to stay with well
>> worn hobbyist families (while avoiding the 8051, do you
>> think?) such as:
>> -- The Microchip PIC (up through PICF18?) I've been informed
>> about an extended variety of these, as well.
>> -- Atmel AVR (AT90) and ATmega and ATtiny.
>>
>
>You do not want the 8-bit PICs to be the first MCU a person new to
>this world uses.

I've not decided that, yet.

>In addition to the lousy instruction set (which I admit does not
>matter nearly as much when programming in a HLL) there are other
>issues such as it's very limited interrupt support.

Especially on the smaller parts. That "extended" beast though
has quite a lot more in the hardware stack than before.
(Yeah, that thing is annoying.)

But actually the whole idea of using 8-bit parts is, in my
mind, something that you don't want "to be the first MCU a
person new to this world uses" as you say. There are other
reasons, even using C, why I think so.

This is why I'm considering seriously the idea that the
MSP430 be their FIRST introduction. It's well supported, well
worn path, cheap readily available starter boards direct from
the company, and operates at the sweet spot. There are
downsides to it -- it's clocking system is sophisticated and
varies from part to part, for example. But I can finesses
that. I can't finesse (not easily) some of what they'd be
forced into facing with 8-bit parts using C (or have them use
BASIC, I suppose.) The MSP430 relieves some of that pressure.

>In the 8-bit PICs, you have to funnel everything down one of two
>interrupts (for the high end MCUs) or just one (for everything else)
>which means you have to check all interrupt sources in the one handler.

Yeah. High level vs low level in the midrange and PIC18 parts
memory serving and just the one level for many others. But
the flip side of that problem is explaining multiple
interrupt vectors. There is good and bad in either approach
when trying to explain it enough to use it to someone new.

>The AVR however has a much cleaner interrupt architecture and allows
>you to easily write standalone device libraries whose various components
>do not have to interact with each other.

It's been a awhile since I've used the AT90 in any thing
professional. I do still have my old STK500 system and I've
used them for hobby purposes once or twice, since. I have a
lot of AT90S2313 parts sitting in a tube, too. But my
recollection (I used assembly for the professional project)
that while it was nice in some ways, it was not so nice in
others. But it did the job, no question, and I really felt as
though the development went pretty smoothly, too. So I grant
that bottom-line.

>To achieve this on the 8-bit PICs, I had to write a little interrupt
>handler library which my device handlers could register themselves
>with and the interrupt handler in this library would call the appropriate
>device handler when required.

Yeah, but this isn't what I'd be talking about... to a newby.
The whole idea of standalone device library design is "down
the pike" a bit, whether easy or harder, and I'm not yet sure
where I think they will be by the time I do consider writing
about that (or if I do.)

>In other words, I had to implement in software what you get for free in
>the MCU hardware on the AVR.

Okay.

>You want to pick as clean a architecture as possible for a first MCU,
>and the AVR is far cleaner than the 8-bit PICs.

And the MSP430, I think, is even better at that stage.

>As for why I have used 8-bit PICs if I feel this way ? Answer: It has
>USB device in PDIP and the AVR does not. (Either :-) or :-( depending
>on your frame of mind. :-))

Hehe. Yeah. Lots of differentiating niches all over the
place. Boggles the mind. Which of course serves them, well.

>> Any other "well worn" paths you'd consider important to
>> include in the list before winnowing it back down?
>
>Those are the only ones which come to mind for me. I did start out with
>the HC08 MCUs, but I outgrew those at least 5-6 years ago.

I still have some of those laying about. Never used one for
any project, though. Just curious at the time, but they never
were the right match for anything I did. There is an HC908
thing too I seem to recall (I think I have some of those.)

>> In the 32-bit world, I'm considering the (huge) ARM family of
>> parts (ARM7, ARM7TDMI, Cortex M0, Cortex M4, even ARM9 [okay,
>> some of them actually have a trace buffer in them and cripes
>> I can't beat that for "nice to have."]) In this area,
>> Freescale and Texas Instruments have certainly been
>> mentioned. Keep in mind I'm looking for starter kits that
>> exist, are generally available, and representative enough to
>> be worth considering. I'm also considering the MIPS M4k
>> (Microchip's incarnation, anyway... and I wonder if now that
>> Microchip bought rights to the M14k if something there will
>> be showing up soon at Microchip .. need to spy on their
>> Gresham fab, I think.)
>
>The PIC32MX is a seriously interesting part if you want people to build
>their own circuits and want something more powerful than a 8-bit device.

To me it is MORE interesting because I have a LOT of
experience with the R2000 core, going back to my days in the
1980's and when I spent a couple of days talking with Dr.
Hennessey at MIPS (new start up, back then.) I learned a
great deal, then, about designing cpu architectures -- two
days in his presence as a 1:1 is enough to learn quite a lot.

I happen to consider the M4k (and M14k) to be "home ground"
where I am very comfortable and ... feel an element of joy an
love, to be honest about it. The ARM, by comparison, is
foreign in some ways. It makes CISC-like decisions that I
can't anticipate entirely because I've been trained to think
like RISC designers would. I'll mention more of this in a
moment.

>> It's fun to read about the MIPS vs ARM wars. Here's one link:
>>
>> http://ww1.microchip.com/downloads/en/DeviceDoc/MD00795-2B-MCU-WHP-01%2001.pdf
>
>I've only had a quick look at the first part of that document, but some
>of the disadvantages for ARM can be relabeled as advantages with the
>right mind set. :-)
>
>For example, it says that MIPS can get higher clock speeds more easily
>because of simpler instructions. You could turn that around and say you
>can do more in one ARM instruction than you can in a MIPS instruction
>and hence ARM could be considered quicker that way. :-)
>
>(Note: that was a good natured comment. I have not actually written
>any MIPS code yet, but the instruction set looks reasonably clean and
>I will reserve forming opinions until I have experience in both
>architectures.)

What they are saying is the same thing I personally heard
from Dr. Hennessey "way back when." There is a price in
inserting register interlock flags (though the M4k uses a
pipeline stage bypass pathway instead), for example.

That paper says, "The MIPS architecture has less predicated
execution, which minimizes logic complexity and enablesMIPS
cores to achieve higher frequencies." This is just that kind
of thing -- anytime you insert logic in the main path you
also insert delays. The longest delay path sets your max
clock rate, since you MUST allow that combinatorial pathway
to settle down. Inserting anything has a delay cost, if it is
in a longer or longest path. Predication means including such
logic to detect and act upon the predicates. And that means
longer paths, and therefore slower clock rates.

This has always been the MIPS driving philosophy. The Alpha
processor, by the way, took these ideas to a limit I never
imagined. (And therefore saw as too hard to deal with, I
admit.) The Alpha would incur exceptions, but you might be
dozens of clock cycles down the road before you could get to
a routine to deal with them. And there could be several and
they just kept information, but let the handler deal with all
of the hard job of UNWINDING things. It was daunting to
consider. But fast. The basic idea was that exceptions are
the exception. Make it FAST when there are no exceptions and
let the pieces lay where they may when they happen. Most
designers go to some trouble about pipeline stalls and so on.
Not the Alpha. It didn't care. It just kept screaming on for
a bit. I thought they went just a little too far. The Alpha
went so far as to disallow any byte references. It had a
64-bit data path but they WOULD NOT insert any "lane
changing" mux in that path. A designer often inserts a lane
change switch so that bytes can be fetched over 16-bit or
32-bit or 64-bit data paths, picking out the 8-bits needed
from the wider path. But inserting that means delays. Delays
mean slower clock rate. Alpha said "no" to that. If you want
bytes, mask them out and shift around, it said. That was your
problem, not its, it said. Clock rate was the goal.

Dr. Hennessey (and founders like Dr. Patterson) also realized
this would greatly pressure the memory system (at the time.)
So they went to great trouble to include special cache parts,
for data and instructions, as part of their R2000 core set.

By the way, Dr. Hennessey was very generous with his time
with me. I was only a small time possibility for his
business, but he took all the time I cared to accept in
studying taped out cpu designs he had available at the time
(like the 68020, which he kept a large version of on his
office wall.)

>> For ARM, GNU is the tool of choice, I suspect. It's decent,
>> updated often, is definitely a "well worn path", and can be
>> had for free from CodeSourcery as a free compiler, updated
>> twice a year, without any code or data limitations. I would
>> most definitely also like to consider IAR's kickstart, as the
>> IDE is decent and I have experience with it. It's limited to
>> 32k, but that's enough for a lot to get done. But I'd
>> consider anything else, as well; but please list out some of
>> the reasons you like it, if you can.
>
>Does CodeSourcery offer a front end to gdb ? I build my own tool chains
>from source and I am currently using ddd as a gdb front end.

It's a complete toolset. Or, for what I used of it, seemed to
be. I used the tools to do some small verification, is all.
So I can't say I've used them enough to answer your question.

I'll have to get better educated about this, though.

Jon

On 05.10.2012 13:06, Jon Kirwan wrote:
> In the 8-bit world, it's probably better to stay with well
> worn hobbyist families (while avoiding the 8051, do you
> think?) such as:
> -- The Microchip PIC (up through PICF18?) I've been informed
> about an extended variety of these, as well.

As I see it, there's absolutely no excuse for still considering PICs 
after having flat-out abolished the 8051.  If there's any architecture 
still in active existence that's actually worse than the 8051, PIC must 
be it.

> -- Atmel AVR (AT90) and ATmega and ATtiny.

Looks like the most preferred choice among 8/16-bitters out there today. 
  And a good deal less antagonistic to being programmed in anything else 
than assembler than both the PIC and 8051.

> For ARM, GNU is the tool of choice, I suspect.

For the hobbyist market: absolutely.  Professional developers would have 
to consider other options, too.  E.g. ARM's own compiler bundled with 
Keil, or the considerably wide selection of third-party compiler vendors 
like GreenHills, IAR, etc.  ARMs well may have the widest selection of 
different compilers of all currently active architectures in the 
embedded market.  Some of those might be viable for "serious" hobby use, 
but the low-price end of that market appears to be owned by GNU.

On Sat, 06 Oct 2012 00:29:06 +0200, Hans-Bernhard Bröker
<H...@t-online.de> wrote:

>On 05.10.2012 13:06, Jon Kirwan wrote:
>> In the 8-bit world, it's probably better to stay with well
>> worn hobbyist families (while avoiding the 8051, do you
>> think?) such as:
>> -- The Microchip PIC (up through PICF18?) I've been informed
>> about an extended variety of these, as well.
>
>As I see it, there's absolutely no excuse for still considering PICs 
>after having flat-out abolished the 8051.  If there's any architecture 
>still in active existence that's actually worse than the 8051, PIC must 
>be it.

I can't agree here. But unless you want to engage a debate on
the subject, we can just leave it as a disagreement and I'm
happy with that. Either way is fine, though.

>> -- Atmel AVR (AT90) and ATmega and ATtiny.
>
>Looks like the most preferred choice among 8/16-bitters out there today. 

Not 16-bit. I'd go MSP430 there. No question.

>  And a good deal less antagonistic to being programmed in anything else 
>than assembler than both the PIC and 8051.

Assembly is part of an architecture discussion. That happens
somewhat later on, and only if that's a path they want to
pursue. If so, then it becomes a matter of how you want to
approach teaching computer architecture. And on that point,
the 8051 and PIC have their place.

>> For ARM, GNU is the tool of choice, I suspect.
>
>For the hobbyist market: absolutely.  Professional developers would have 
>to consider other options, too.  E.g. ARM's own compiler bundled with 
>Keil, or the considerably wide selection of third-party compiler vendors 
>like GreenHills, IAR, etc.  ARMs well may have the widest selection of 
>different compilers of all currently active architectures in the 
>embedded market.  Some of those might be viable for "serious" hobby use, 
>but the low-price end of that market appears to be owned by GNU.

The GNU toolset pathway has been well-worn in ARM. In fact,
that is the place that gets the most use -- probably accounts
for almost all its use, if I had to guess about it. It just
works well. Even commercial vendors use it. It's just plain
good medicine for ARM. That doesn't mean someone else can't
point out an advantage in some commercial product -- but I
doubt there is much regarding code quality to show. Mostly in
the periphery, I suspect. But I'm ignorant about a lot of
things, too.

CodeSourcery appears to me to have the most lenient policy
for hobbyists -- explicit on their web site and not hard to
find, simply free in all the meanings of it, and updated
twice a year. No one else offering commercial support and
libraries does as much, I think.

I'm still considering M4k and M14k -- if I choose to consider
talking about Cortex M4F or M4.

Jon

Jon Kirwan wrote:


> In the 16-bit world, I think I'm pretty much stuck with Texas
> Instruments' MSP430. Cheap to get starter kits, widely
> available, decent part, etc.

Hi John,

<http://www.4e4th.eu/>

Couldn't remember if I gave the link for the 4e4th software. This gives a 
fully functional Forth for the MSP430 Launchpad board which can then be 
communicated with by a simple terminal programme. This makes it a whole lot 
easier to programme.

-- 
********************************************************************
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 Sun, 07 Oct 2012 10:40:42 +0100, "Paul E. Bennett"
<P...@topmail.co.uk> wrote:

>Jon Kirwan wrote:
>
>> In the 16-bit world, I think I'm pretty much stuck with Texas
>> Instruments' MSP430. Cheap to get starter kits, widely
>> available, decent part, etc.
>
>Hi John,
>
><http://www.4e4th.eu/>
>
>Couldn't remember if I gave the link for the 4e4th software. This gives a 
>fully functional Forth for the MSP430 Launchpad board which can then be 
>communicated with by a simple terminal programme. This makes it a whole lot 
>easier to programme.

Thanks, Paul. I would like to avoid writing about Forth,
though. One reason is that I'm not an expert at it. (It's
been so many years now and I never did write anything
professional using it [since no one inquired and my lack of
expertise with it wouldn't allow me to suggest it, myself.])
There are some other reasons having to do with my personal
opinions (current, and subject to change) about the slant.

But I'm going to check the link anyway. I think I saw it
earlier on the yahoo group and took note then. Might have
been a different link, though. Anyway, I was interested to
try it out.

So thanks,
Jon

On Friday, October 5, 2012 11:06:57 PM UTC+12, Jon Kirwan wrote:
> Okay. Just to start off the list of candidate processors for
> educational purposes and writing up various considerations
> for them, 
> 
> 
> In the 8-bit world, it's probably better to stay with well
> worn hobbyist families (while avoiding the 8051, do you
> think?) such as:

? Why avoid the 8051, but include PIC ?

There are good simulators for the 8051, and companies like SiLabs have good, low cost Toolstick Emulation offerings.


> 
> -- The Microchip PIC (up through PICF18?) I've been informed
> about an extended variety of these, as well.

PIC is not that low cost to get into In Circuit Debug with ..
 
> -- Atmel AVR (AT90) and ATmega and ATtiny.

and ATXMega, which seems to have the price-point on 'USB controllers with reasonable uC' 
 
> 
> Any other "well worn" paths you'd consider important to
> include in the list before winnowing it back down?

Not well worn, but Wide Vcc is seeing a resurgance.
Parts from Freescale and STM8S are other 8 bit cores....

> 
> I'm avoiding Renesas R8 (not well worn, in my mind.)
> 
> 
> 
> In the 16-bit world, I think I'm pretty much stuck with Texas
> Instruments' MSP430. Cheap to get starter kits, widely
> available, decent part, etc.
> 

Yes the 'cheap to get going' wins here.
 
> 
> In the 32-bit world, I'm considering the (huge) ARM family of
> parts (ARM7, ARM7TDMI, Cortex M0, Cortex M4, even ARM9 [okay,
> some of them actually have a trace buffer in them and cripes
> I can't beat that for "nice to have."]) In this area,
> 
> Freescale and Texas Instruments have certainly been
> mentioned. Keep in mind I'm looking for starter kits that
> exist, are generally available, and representative enough to
> be worth considering. I'm also considering the MIPS M4k

If you want ARM _and_ WideVcc, _and_ low cost, (ie the Student sweet spot) 
and Debug and Tools and PCB from one link, then look at this :

http://coocox.org/Cookie.html

There are also DSC from TI and Freescale.
- and the RX200 series from Reneas ....


My pet peeve with 32 bit controllers : 
 WHY does anyone put 16 bit timers, with a 32 bit core ?!

-jg

On Tue, 9 Oct 2012 17:41:38 -0700 (PDT),
j...@gmail.com wrote:

>On Friday, October 5, 2012 11:06:57 PM UTC+12, Jon Kirwan wrote:
>> Okay. Just to start off the list of candidate processors for
>> educational purposes and writing up various considerations
>> for them, 
>> 
>> 
>> In the 8-bit world, it's probably better to stay with well
>> worn hobbyist families (while avoiding the 8051, do you
>> think?) such as:
>
>? Why avoid the 8051, but include PIC ?

Even though it is NOT so easy to explain an 8-bit PIC, it is
EVEN HARDER to explain the 8051. That is, to kids these days.
If this were the next thing AFTER teaching a computer
architecture class, either one would be equal in my mind --
they are both good at exposing interesting details like a
"transparent man" exposes internals to view. But the 8051 is
more complex to explain. Register banks that can be quickly
switched in an interrupt routine is GREAT for speed, but I'm
not sure how to write about it. Bit manipulation applying
only to certain parts of the internal ram, but not other
parts. And discussing when the direct ram, indirect ram,
external memory... I think the PIC is easier to write about,
without the architecture background leading into it first.
And I don't think that's the path, right now.

I mentioned the AVR, by the way, here. Others seem to imagine
that is the best way to go, not the PIC. I think BOTH are
well worn paths. But the AVR has compiler tools in its
advantage over PIC (in terms of cheap, available, well worn
-- in my current opinion subject to change.) The 8051 has
SDCC, I suppose, which give it an advantage over PIC in terms
of cost of tools.

Like I said, I'm thinking out loud here and just seeing what
shakes out. I want my ass kicked when my view isn't even
close to comprehensive. So kick away.

> There are good simulators for the 8051, and companies like
> SiLabs have good, low cost Toolstick Emulation offerings.

One of the problems I have with SiLabs is from personal
experience. I needed information on the DMA. The datasheet
was "incomplete" and NO ONE there could answer my question.
So they finally got back to me, two months later, after they
tracked down the designer of the DMA unit (who was 8 years
off doing something else and hard to find) in order to find
out how it actually works. Seriously. That really happened. I
have all the emails to prove it and to show the elementary
nature of my question, too.

But I like the part. It worked as I wanted it to. And the
ONLY problem I had was with the DMA. (Try running 1MHz 16-bit
ADC data into the 8051 memory with anything else on that
darned 8051.) Still, I had to write a number of specialized
assembly routines to get the performance needed -- because of
the bottleneck of the external memory DPTR register.

I guess that's not a reason to say no. But my instincts tell
me that when I start to write, on THIS PROCESSOR, I will find
myself WRITING TOO MUCH, TOO LONG, TOO HARD. Maybe I'm wrong.

>> -- The Microchip PIC (up through PICF18?) I've been informed
>> about an extended variety of these, as well.
>
> PIC is not that low cost to get into In Circuit Debug with ..

Yeah, I admit that!! I will look around for options there.

>> -- Atmel AVR (AT90) and ATmega and ATtiny.
>
> and ATXMega, which seems to have the price-point on 'USB
> controllers with reasonable uC'

Hmm. Need to update myself on that one. Thanks. That's why
I'm asking here. To get a broader view I lack.

>> Any other "well worn" paths you'd consider important to
>> include in the list before winnowing it back down?
>
>Not well worn, but Wide Vcc is seeing a resurgance.
>Parts from Freescale and STM8S are other 8 bit cores....

Wide Vcc is both simple and complex. There isn't a complete
toolset of surrounding parts that match up, yet. People
always asking questions about level conversion, "tolerant"
I/O, etc. I am not so sure that is near the top of my list of
things I care about going into this, though I recognize it's
happening a lot more. But I'd like to cover it simply. So
it's not a make/break issue for me, I think.

>> I'm avoiding Renesas R8 (not well worn, in my mind.)
>> 
>> 
>> In the 16-bit world, I think I'm pretty much stuck with Texas
>> Instruments' MSP430. Cheap to get starter kits, widely
>> available, decent part, etc.
>
>Yes the 'cheap to get going' wins here.

Hehe.

>> In the 32-bit world, I'm considering the (huge) ARM family of
>> parts (ARM7, ARM7TDMI, Cortex M0, Cortex M4, even ARM9 [okay,
>> some of them actually have a trace buffer in them and cripes
>> I can't beat that for "nice to have."]) In this area,
>> 
>> Freescale and Texas Instruments have certainly been
>> mentioned. Keep in mind I'm looking for starter kits that
>> exist, are generally available, and representative enough to
>> be worth considering. I'm also considering the MIPS M4k
>
>If you want ARM _and_ WideVcc, _and_ low cost, (ie the Student sweet spot) 
>and Debug and Tools and PCB from one link, then look at this :
>
>http://coocox.org/Cookie.html
>
>There are also DSC from TI and Freescale.
>- and the RX200 series from Reneas ....

Well worn paths?

>My pet peeve with 32 bit controllers : 
> WHY does anyone put 16 bit timers, with a 32 bit core ?!

Some have 64-bit, I gather. Like the TI Stellaris Launchpad
LM4F120H5QR's concatenated 64-bit GPTM register. I admit I've
NOT done anything more than skim over the datasheet to see
the number. So I may be all wet here, too. Lots of work
ahead.

Point taken, though.

Jon