Microcontroller reccomendations?

[MillenniumFalsehood]

Here's what I'm looking for:

Cheap(like less than $8-10 per chip)

Easy programming language

Comes in a kit that includes software to program it and a way to hook it up to the computer

Fast processing

Instructions on how to hook it up to components like LEDs and motors.

[tetsujin]

Here's what I'm looking for:

Cheap(like less than $8-10 per chip)

Easy programming language

Define "easy"... I think PIC assembly is pretty easy... I'm guessing you're maybe thinking C or Basic?

[macfrank]

For assembly language, the Atmel AVR series is far easier to understand than the arcane PIC architecture and assembly language. For higher level languages, it doesn't matter as much.

You can get an Atmel AVR Butterfly for $19. It has several A/D channels, an alphanumeric LCD display, speakers a light sensor, a temperature sensor and several unused I/O ports. You can program it in assembly language, or use a free C compiler called WinAVR. There are some Butterfly specific ports here.

I made a solar powered data logger using a Butterfly and it spent 3 months in the desert collecting data. The temperature inside the box reached over 150F on some days, but the unit remained unscathed.

You can also get the Atmel STK-500 development board with assembler (it has sockets for almost all the AVRs made) for $80-. It'll work with the WinAVR C compiler as well.

Frank

[jwrjr]

I use PIC ASM exclusively. Naturally I think that it is easy. There is a logic to it once you get used to it. The programming suite (download the latest version from Microchip) comes with a limited C compiler. For free.
Cheap? I just finished a project using one of the low end controllers where the controller costs about $1 each in single quantities. Less if you buy more at a time.
The PIC controllers will usually source 25ma on each output. This is enough to max out one of most regular leds.

[tetsujin]

For assembly language, the Atmel AVR series is far easier to understand than the arcane PIC architecture and assembly language. For higher level languages, it doesn't matter as much.

<shrug> The PIC architecture isn't so weird, though it does have its limits (at least in the older PICs like the 16F series) - mainly the fact that there's no direct support for indirect addressing (If you want to say "read the data at memory address XXXX", you either need XXXX hard-coded into one of your program instructions, or you need to stick that address into a specific register in memory and then read another register to perform the "read at address"...), there's no opcodes for multiply/divide, and all your registers and such are 8-bit...

The existence of a GCC port that targets AVR is a definite plus, though. The older PIC architectures aren't really well-suited for use as a GCC target (there's other options, like SDCC and probably some commercial options...) - I don't know if the newer PIC architectures (16 and 32 bit) are better suited as C targets, but I expect so...

But for what I usually use PICs for (mostly model stuff) these limitations aren't a big deal. The reason I find the assembly language easy would apply to just about any microcontroller - it's a small machine with a small instruction set.... So it's relatively easy to understand what's going on in a program.

What kind of interface do you use to program an AVR anyway? I mean, I'm sure there's a parallel port solution (there always is - but they rarely work in my experience), but what are the good options for a hobbyist who wants a reliable hardware interface for writing program code to their controller?

In my work with PICs I've used PIC programmers from a company called "KitsRUs" - specifically kit 182 mostly (it's a bus-powered USB device, in-circuit programming only, and so very small... It emulates an RS-232 port and communicates using a published protocol... The script I use to upload code to my PICs, I wrote myself...)

[jwrjr]

Actually you can do indirect addressing in a PIC. You load the address into the FSR register, then do a memory access (read/write) to location 00h. The biggest shortcoming that I've found in the PIC architecture is that the RAM accesses always use 8-bit addresses. You can't put a big lookup table in RAM. This isn't usually a problem, but sometimes ... I really wish that they would put an 18F cpu in an 8 pin package. But that hasn't happened.

[tetsujin]

Actually you can do indirect addressing in a PIC. You load the address into the FSR register, then do a memory access (read/write) to location 00h.

Yeah, I actually mentioned this, just didn't remember the name of the FSR register off hand. :D

What about the PIC24F line?

[jwrjr]

I can only tell you that the Pic24 is a 16 bit machine and that it comes mostly in surface-mount packages. There are a few DIPs, though. Somewhat overkill for models and the like.

[MillenniumFalsehood]

This is a robotics project, and for what I'm trying to do, it wouldn't be overkill.

[macfrank]

What kind of interface do you use to program an AVR anyway? I mean, I'm sure there's a parallel port solution (there always is - but they rarely work in my experience), but what are the good options for a hobbyist who wants a reliable hardware interface for writing program code to their controller?

Both the Butterfly and the STK500 use serial I/O for programming. I haven't used a parallel port for anything 9even printing) in years. A generic USB-serial adapter works well.

Another good AVR option is the Arduino which gets used in a lot of robotics projects.

The main reason I recommend AVRs over PICs for assembly language is that there is a needlessly steep slope to learning assembly on the PIC. It's just easier to use a fast, cheap CPU with lots of registers and a pretty modern instruction set.

[tetsujin]

What kind of interface do you use to program an AVR anyway? I mean, I'm sure there's a parallel port solution (there always is - but they rarely work in my experience), but what are the good options for a hobbyist who wants a reliable hardware interface for writing program code to their controller?

Both the Butterfly and the STK500 use serial I/O for programming.

As in you connect an RS-232 port to it and program? Does that mean it uses the serial transmit/receive lines and you just send commands and data to it, or are you using the other lines (flow control, etc.) and bit-banging it?

How does this work in-circuit? Can those pins be used for other things besides the programming interface?

[macfrank]

As in you connect an RS-232 port to it and program? Does that mean it uses the serial transmit/receive lines and you just send commands and data to it, or are you using the other lines (flow control, etc.) and bit-banging it?

Just regular RS-232 data in and out and ground on the STK500. The other lines are not used.

It programs the parts via the SPI interface built into the parts. After programming, the SPI interface can be used as an SPI interface or regular I/O pins.


The Butterfly connects directly to the RS232 lines for its programming data.

[tetsujin]

After programming, the SPI interface can be used as an SPI interface or regular I/O pins.

How do you switch between the two uses for those pins?