Newbie Recommendation

Hello,

What would you all recommend for a beginner looking to get into embedded 
systems programming for somebody with Ix86 Assembly and C experience, 
but relatively no experience in electronics?

The two most popular I've heard of are the Atmel (Atmega RISC based 
processors) as well as the various PIC line of microcontrollers.

I'm looking for something capable of dealing with analog signals from 
various devices (such as an ultrasonic range finder), as well as PWM's 
to control servos.  I2C isn't really necessary, but I wouldn't turn a 
processor down just because it's there.  I also have no preferences 
between the Harvard and von Neumann architectures.  I'd really prefer to 
stay away from BASIC in general in favor of developing code in either 
Assembly, C, or a combination of the two.

What do you recommend?

Thank you,

-- 
Sean

"Fao, Sean" <enceladus311@yahoo.comI-WANT-NO-SPAM> writes:

> Hello,
> 
> What would you all recommend for a beginner looking to get into
> embedded systems programming for somebody with Ix86 Assembly and C
> experience, but relatively no experience in electronics?
> 
> The two most popular I've heard of are the Atmel (Atmega RISC based
> processors) as well as the various PIC line of microcontrollers.
> 
> I'm looking for something capable of dealing with analog signals from
> various devices (such as an ultrasonic range finder), as well as PWM's
> to control servos.  I2C isn't really necessary, but I wouldn't turn a
> processor down just because it's there.  I also have no preferences
> between the Harvard and von Neumann architectures.  I'd really prefer
> to stay away from BASIC in general in favor of developing code in
> either Assembly, C, or a combination of the two.


If you want to go 8-bit, then I would say that the AVR series is the
best choice.  It is probably the most "C friendly" 8 bit chip.  It
does have a Harvard architecture, which can make programming with lots
of string constants a bit awkward in C.

However, if I was starting out I would go directly to the 32 bit ARM
chips, e.g. the LPC2000 series. ARM looks like becoming the industry
workhorse for embedded systems, much like the 8051 is/was. Just about
every cpu manufacturer seems to make them in some variation. The price
premium for 32 bits vs 8 bits seems to be vanishing (except for high
volume manufacturing).

Both of these product lines (AVR and ARM7 / LPC2000) have a large
active user community with high quality free tools (gcc) and
inexpensive development boards.

-- 

John Devereux

I highly recommend Zilog Encore microcontrollers. They have an incredible
deal (US$40) for a development kit, including IDE with C/Assembler, lots
of great documentation and inexpensive powerful uC's.
http://www.zilog.com/products/family.asp?fam=232

On Wed, 28 Sep 2005 07:46:08 -0400, "Fao, Sean"
<enceladus311@yahoo.comI-WANT-NO-SPAM> wrote in comp.arch.embedded:

> Hello,
> 
> What would you all recommend for a beginner looking to get into embedded 
> systems programming for somebody with Ix86 Assembly and C experience, 
> but relatively no experience in electronics?
> 
> The two most popular I've heard of are the Atmel (Atmega RISC based 
> processors) as well as the various PIC line of microcontrollers.
> 
> I'm looking for something capable of dealing with analog signals from 
> various devices (such as an ultrasonic range finder), as well as PWM's 
> to control servos.  I2C isn't really necessary, but I wouldn't turn a 
> processor down just because it's there.  I also have no preferences 
> between the Harvard and von Neumann architectures.  I'd really prefer to 
> stay away from BASIC in general in favor of developing code in either 
> Assembly, C, or a combination of the two.
> 
> What do you recommend?
> 
> Thank you,

Actually, since you mention both analog signals and servo control, and
you come from a 32-bit background, take a look at TI's C28xx family of
DSPs.

http://dspvillage.ti.com/paramsearch/docs/parametricsearch.tsp?&familyId=510&totalCount=168&showAdditionalParameters=no&lc=2001216&lc=2000062&lc=2001226&lc=2001227&lc=2001215&lc=2000059&lc=2001213&lc=2001211&lc=2001212&lc=2000061&lc=2000603&lc=2000607&lc=2001218&compare=yes&download=yes&sort=yes&customize=yes&paramResults=yes&paramCriteria=yes&familyTree=yes&military=no&baSystem=yes&paramTable=no&sortOption=&sortMode=&searchPaths=1000322&searchPaths=1000326&searchPaths=1000044&pageId=44&templateId=5121&navigationId=12447&family=dsp&paramTable=no&military=no&compare=yes&download=yes&sort=yes&customize=yes&paramResults=yes&paramCriteria=yes&familyTree=yes&military=no&baSystem=yes&paramTable=no&sortOption=&sortMode=&searchPaths=1000322&searchPaths=1000326&searchPaths=1000044&pageId=44

Watch out for line wrap!

16 analog channels for ADC, quadrature encoder inputs (if needed), and
up to 12 PWM outputs, can drive six brush DC motors or two 3-phase
motors simultaneously.

Has SPI built in, not I2C, but you might be able to do I2C with the
McBSP serial peripheral.  Check the app notes.

-- 
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html

John Devereux wrote:
> If you want to go 8-bit, then I would say that the AVR series is the
> best choice.  It is probably the most "C friendly" 8 bit chip.  It
> does have a Harvard architecture, which can make programming with lots
> of string constants a bit awkward in C.

To be honest, I didn't actually even consider 8-bit versus 32-bit 
architectures.  That's probably something I should give a little 
consideration to.

> However, if I was starting out I would go directly to the 32 bit ARM
> chips, e.g. the LPC2000 series. ARM looks like becoming the industry
> workhorse for embedded systems, much like the 8051 is/was. Just about
> every cpu manufacturer seems to make them in some variation. The price
> premium for 32 bits vs 8 bits seems to be vanishing (except for high
> volume manufacturing).

I keep hearing a lot about the arm processors, but I know next to 
nothing about them (all I know is that it appears that multiple 
manufacturers have ARM-based CPU's, but I have no clue what ARM actually 
is, yet).  I'll have to do some research because I'm not even sure what 
they're primarily targeted at or how to program them (although after 
reading on in your message, it appears that gcc will work just fine).

> Both of these product lines (AVR and ARM7 / LPC2000) have a large
> active user community with high quality free tools (gcc) and
> inexpensive development boards.

One of the things that lead me to the AVR in the first place was the 
large number of free tools available (e.g. gcc).

That was great information.  Thank you much!

-- 
Sean

Larry Gagnon wrote:
> I highly recommend Zilog Encore microcontrollers. They have an incredible
> deal (US$40) for a development kit, including IDE with C/Assembler, lots
> of great documentation and inexpensive powerful uC's.
> http://www.zilog.com/products/family.asp?fam=232

I have to admit that I hadn't heard of these processors, but after 
reading what they have to offer, this might be exactly what I'm looking 
for --inexpensive and simple development boards to get me started 
quickly.  And they all appear to come standard at 20 MHz, which is more 
than enough for my current needs.

I'll definitely include these processors in my research and give them 
some serious consideration.  Thank you!

-- 
Sean

Jack Klein wrote:
> Actually, since you mention both analog signals and servo control, and
> you come from a 32-bit background, take a look at TI's C28xx family of
> DSPs.

Ever since I played with my first TI-8x calculator, I've always wanted 
to learn how to program on the TI CPU.  They were always incredibly fast 
and --as I understood it-- had great floating point capability.  The 
thing that always steered me away from these processors, however, is 
that they were always priced more than double that of other processors I 
was considering.

> 16 analog channels for ADC, quadrature encoder inputs (if needed), and
> up to 12 PWM outputs, can drive six brush DC motors or two 3-phase
> motors simultaneously.

The thing here that caught my eye is that you mention quadrature encoder 
inputs.  If I'm not mistaken, this is how a ball mouse works, right? 
The reason I ask is because at an instrument company I used to work for, 
they developed robots that had to detect both direction of movement, as 
well as provide the ability to "count" the number "steps" in any 
direction that an arm was moved (intentionally moved with software or 
unintentionally moved by a foreign object forcing the arm to move).  As 
far as I know, the engineers just simply used the analog channels 
available on the processor (I could be wrong).  Is this possible?  If so 
--and you don't mind a little explanation-- how exactly do you benefit 
from having a quadrature encoder input?  Does it simplify the processes 
or is this the only way to detect such movements?  Basically, what I'm 
wondering is whether or not it's possible to implement the same design 
using the analog channels (possibly with a little more work).

I could potentially have a project (in the distant future, of course) 
that would require quadrature encoder inputs, so this is a very 
interesting find, for me.  Naturally, all this assumes that I'm even 
talking about the right thing ;-).

> Has SPI built in, not I2C, but you might be able to do I2C with the
> McBSP serial peripheral.  Check the app notes.

As of now, I2C isn't really a big concern of mine.  I probably only 
mentioned it because it was something I recognized from editing the 
Linux kernel configuration for my system and knowing that it provided 
the ability to read temperature and fan speed for various devices in my 
PC.  I have seen some pretty cool I2C devices online, such as 
ultra-sonic range finders, and such.  For now, though, I prefer to 
implement these peripherals on the analog channels.

Thank you much for your response.

-- 
Sean

Fao, Sean <enceladus311@yahoo.comi-want-no-spam> wrote:

> Ever since I played with my first TI-8x calculator, I've always wanted 
> to learn how to program on the TI CPU.  They were always incredibly fast 
> and --as I understood it-- had great floating point capability.  The 
> thing that always steered me away from these processors, however, is 
> that they were always priced more than double that of other processors I 
> was considering.

Well the TI-8x calculators use Zilog Z8 CPUs.... not TI CPUs :)

or, at least they did when I learned to program them in assembler a few 
years back....

--buddy

In article <fSR_e.3$bI5.111@news.abs.net>,
Fao, Sean <enceladus311@yahoo.comI-WANT-NO-SPAM> wrote:
>The thing here that caught my eye is that you mention quadrature encoder 
>inputs.  If I'm not mistaken, this is how a ball mouse works, right? 
>The reason I ask is because at an instrument company I used to work for, 
>they developed robots that had to detect both direction of movement, [...]
>                                        [...] how exactly do you benefit 
>from having a quadrature encoder input?  Does it simplify the processes 
>or is this the only way to detect such movements?

You can do it in software with two digital inputs. But if the software
doesn't respond quickly enough, it can miss steps, which can of course
be bad if you need to keep track of your absolute position. The
hardware needed to handle quadrature inputs is very simple, though, and
can handle much faster rates, all else being equal.

(All that quadrature means is that you have two sensors connected
to the same wheel or shaft, but one of them is offset by ninety
degrees.  The offset lets you tell whether the shaft is rotating
clockwise or counterclockwise, according to whether sensor #1 is
giving you pulses slightly ahead of sensor #2, or behind. At that
point it's just a matter of counting pulses, and counting up or
down depending on which way the shaft is going.)

-- 
   Wim Lewis <wiml@hhhh.org>, Seattle, WA, USA. PGP keyID 27F772C1

Wim Lewis wrote:

> In article <fSR_e.3$bI5.111@news.abs.net>,
> Fao, Sean <enceladus311@yahoo.comI-WANT-NO-SPAM> wrote:
>>The thing here that caught my eye is that you mention quadrature encoder
>>inputs.  If I'm not mistaken, this is how a ball mouse works, right?
>>The reason I ask is because at an instrument company I used to work for,
>>they developed robots that had to detect both direction of movement, [...]
>>                                        [...] how exactly do you benefit
>>from having a quadrature encoder input?  Does it simplify the processes
>>or is this the only way to detect such movements?
> 
> You can do it in software with two digital inputs. But if the software
> doesn't respond quickly enough, it can miss steps, which can of course
> be bad if you need to keep track of your absolute position. The
> hardware needed to handle quadrature inputs is very simple, though, and
> can handle much faster rates, all else being equal.

You could have answered the second question as well.

The quadrature encoder is quite simple as has been indicated and is often 
quite innexpensive to implement. It can be done with optical or magnetic 
proximity sensors.

An alternative position/motion sensor is the resolver or synchro motor 
which provides an indication of absolute position of its shaft. For linear 
motion the LVDT is a similar style of position sensor.

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