Forums

Newbie Recommendation

Started by Fao, Sean September 28, 2005
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/ ********************************************************************