Which uController to learn?

Tim Wescott wrote:


I heard that. That is truly the ugliest archetecture.

But but but an 8052 has a stack and an available stack pointer. Don't you like it?

The Keil compiler generates nice dense code on the 8052, but it costs a fortune too. At the other end of the spectrum you have SDCC, ha ha ha. I'd rather have a sharp stick in the eye. ;-)
Have you looked at the 18F pics? They added some things that make it much more friendly to C compilers. Tripple data pointers (FSRs), auto increment/decrement, bigger stack, W is a real SFR, LAT registers to eliminate RMW issues for people too lazy to use a shadow register, etc. Nice chip, I'll have to try one sometime. ;-)
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

...Insert multiple "negative 8051" comments here..."
Look, if you're going to program in Assembler, the 8051 (and it's many, many cousins) are fine. All this talk about architectures and C-coding probably won't mean that much to a beginner.
Except perhaps the drive levels discussions. Here, generically, I think there is something worth discussing. Ideally, you'd like 20mA sink on every pin. Some 8051's with Quasi- bidirectional ports can handle that. But I've seen some that can barely manage 4mA, or less..
8051's are very well supported having been around for decades. And they're not going away anytime soon. I don't think you can go "wrong" here.
-mpm
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

32 bit ARM's are nice, you can get them in small 4x5 mm packages up to huge floating point versions with 256K of RAM, the small ones are a few bucks. They work very well with high level languages and the assembly is easy, you spend more time doing stuff rather then fighting with the limitations of smaller PIC's, AVR's and 8051's (bank switching, multi word math, accessing 16 bit hardware with double reads that have to be done in a certain order, etc,etc,etc all that weird goofy stuff goes away).
About C, you have to realize that the majority of example code out there is in C, I hate the language myself, but I use it because it is so easy to pick up someone's elses C code and start working with that. I bought an ARM development kit recently and was up and running in a few hours (blinking LEDS, reading A/D's, and sending the data to the PC via the UART), cause they had C examples of everything, converting the A/D inputs, UART utilities, start up files etc.
You have to remember the actual number of C features actually needed in a small embedded processor is very little... learn a couple while/ for loops, if statement, how to set/clear a bit and how to call a routine and what else is there? not much
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
wrote:

OK -- I'm a late entry on this one -- but WinAVR makes everything similarly transparent for the 8 bit Atmel chips, and there is plenty of code out there written in C for the AVRs, including math libs and such (used one to do a software PID for servo motors -- worked well !!) -- best of all for me -- the compiler is free :) And like the ARM, you can ramp up to 32 bit chips with on-chip DSP and may other specialty features
I personally dont care WHICH chip I use as long as I have good development tools :) I started on the 8047/8051/Z8 MANY moons ago, and I've done plenty of PIC and AVR -- I prefer the AVR chips because the development tools and community support I got were better than what I ran into for the PIC when I was getting started. (and the only FREE dev tools I could find for the the PIC were BASIC, which I put aside a coupla hundred years ago !!)
They are all good chips -- make sure you got good dev tools !!
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

There really is no upgrade path for the AVR, the AVR 32 is only the same in name only, it's nothing like a 32 bit version of the AVR8, and currently there is only one device in that family.
the AVR series hasen't increased in performance in years (speed, a/d resolution, DMA, fifo buffers, divide instructions etc). Microchip has been very good in this respect, even though I don't use any of their PICS. I ended up using the Atmel SAM7's and Analog devices ARM chips, although AVR's are still superior in battery power devices.
All the development tools are excellent now, in my opinion, but I'm pretty easy to please....
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Many of them are doing 20 MIPS now, that wasn't available two years ago, built-in full speed USB is new too,
It's an 8-bit microcontroller it doesn't need that extra stuff ...
Bye. Jasen
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
jasen wrote:

20 MIPS, on a MEGA. Those aren't backwards compatible with the tradition AVRs are they?

Speak for yourself. Since when is A/D resolution not important for an 8 bitter?
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

AVR32 based 32-bit MCU/DSP Vectored multiplier co-processor, 32 KB on-chip SRAM, 16 KB instruction and 16 KB data caches, MMU, DMA controller. Peripherals include a 16-bit stereo audio DAC, 2048x2048 pixel TFT/STN LCD controllers, 480 Mbps USB 2.0 with on chip transceivers (PHY) and, two 10/100 Ethernet MACs. Serial interfaces include RS232, USART, I2S, AC97, TWI/I2C, SPI, PS/2 and several synchronous serial modules (SSC) supporting most serial communication protocols.
sounds like a bit more than an 8-bitter to me !!
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
John Barrett wrote:

Slightly. ;-) Sounds allot like an ARM knockoff. I wonder what the power dissipation is on that, I'm guessing it's a bit more than my slow, cumbersome PIC. I bet it costs more than a $1 too. ;-)
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

There's not much difference between them. The most significant is probably that the mega series has a hardware 8-bit MUL instruction which takes two clock cycles. I would not say that going from one series to the other necessitates any more modifications than going between parts in the same series.
Maybe you were thinking of the AVR32?
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

20 on a ATTiny2313 last year, megas to0 this year, up from 16.
I've only compared the ATTiny2313 and the AT90S2313
Those two certainly appear to be binary compatible in that the newer Tiny will run the older 90S programs and perform the same.

how often is 10 bits too few ?
Bye. Jasen
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Quite often. Photography & audio work, just for two popular examples.
--
W "Some people are alive only because it is illegal to kill them."
. | ,. w ,
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Agreed. SOme tasks like laser scanning might call for a small dedicated controller, and you'd certainly want 16 bits there, especially if colour mixing was needed.
Even a small task like lin/log conversion, which many on Usenet advise me was best solved by code, needs to use 16 bits for accuracy over a decent range. Unless more tiny micros are made with 16 bit ADC and DAC on board, people will always be agonising over expensive analog computation IC's. Far better that we have a small number of cheap standard parts we can learn to code for. If I knew I could have this, I'd put more effort into learning it. I don't want to do it with a 40 pin device that needs a diploma to learn either, I want to do it with a 4 pin IC and some very simple high level language.
The way things are now, even real experts have argued and floundered over what best to advise. If more small micros had 16 bit analog I/O built in, people like me wouldn't even have to ask.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

you want to do serious audio *1 or imaging *2 on a 20MIPS 8-bitter ?
*1 for toys, or telephony, 8 bits are enough
*2 I can't see 10 bits needed for an exposure meter, at low speeds switched gain is an option.
--

Bye.
Jasen
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Hell no! I was speaking generally. ;^)

Well, light meters for photographics work on a Log2 scale, so it requires more ADC resolution than you might expect at first glance. That said, a good sample & hold in front of a dual-slope converter would be perfectly suitable for most such purposes.
--
W "Some people are alive only because it is illegal to kill them."
. | ,. w ,
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
"bungalow snipped-for-privacy@yahoo.com" wrote:

PL/M51 handles all that goofy stuff for me.
I've only once ever come across a situation with an 8051 where I'd have liked a long word btw and I use even words quite rarely.
Graham
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

32 bit ARM's are nice, you can get them in small 4x5 mm packages up to huge floating point versions with 256K of RAM, the small ones are a few bucks. They work very well with high level languages and the assembly is easy, you spend more time doing stuff rather then fighting with the limitations of smaller PIC's, AVR's and 8051's (bank switching, multi word math, accessing 16 bit hardware with double reads that have to be done in a certain order, etc,etc,etc all that weird goofy stuff goes away).
About C, you have to realize that the majority of example code out there is in C, I hate the language myself, but I use it because it is so easy to pick up someone's elses C code and start working with that. I bought an ARM development kit recently and was up and running in a few hours (blinking LEDS, reading A/D's, and sending the data to the PC via the UART), cause they had C examples of everything, converting the A/D inputs, UART utilities, start up files etc.
You have to remember the actual number of C features actually needed in a small embedded processor is very little... learn a couple while/ for loops, if statement, how to set/clear a bit and how to call a routine and what else is there? not much
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.