Hello, Are there any low cost development (~£40) boards for the AVR microprocessors? Which ones are most commonly used? It seems that the AVR processors are preferred to the PIC ones. Is this true or is it just personal preference?
Cheers
Peter.
Possibly your best low-ish cost bet is this one from Farnell
A big advantage is that it includes Atmel's AVR-ISP programmer, so you're able to program *any* AVR device [1].
A big disadvantage is that the dev board itself only supports 20- and
40-pin AVR devices, not the 8- and 28-pin chips. You can still program 28-pin (and 8-pin) devices with the AVR-ISP but you'd need to set them up on something like a breadboard along with power, clock, etc.On the other hand, the 40-pin devices that the board does support have a lot of program space, I/O pins, and internal peripherals and you would have lots of "room" to learn.
An alternative is the STK500 which is just a bit more expensive
The STK500 does not include the C compiler that comes with the first item. However, it's not clear whether or not that compiler is a code-space or time limited demo version. Besides, there are several inexpensive commercial compilers (for example,
Also please note that, for any AVR device, the serial programming clock should be less than or equal to 1/4 of the device's operating clock. This isn't really an issue if you know that many (all?) of the AVRs that have built-in RC clock oscillators are delivered to run from the internal clock, which is typically around 1 MHz. It's a simple matter to "burn the fuse" to set the chip's configuration to use an external oscillator or crystal. BUT if your AVR-ISP is running its programming clock at 900 KHz, you won't be able to communicate with a 1 MHz chip to do this and you might even think that the chip or programmer are defective. The (easy) solution is to set the ISP to less than 250 KHz to talk to a brand-new chip. Not that *I've* ever forgotten to do that. Not me, nope, never, well maybe once...
Regarding the two chip families, I've developed commercial code on both PICs and AVRs and find the layout of the AVRs registers and memory spaces to be more comfortable. A possible gauge of the relative "programmer-friendliness" of the two chips is to note that the AVR family has an active and well-supported GCC port, while there is not a port for the PIC family.
-- Rich Webb Norfolk, VA
Hello,
Thanks for the information. A further surf around the AVR webring revealed...
I'm beginning to get a feel for what's out there!
Cheers
Peter.
Nowadays, as people are programming mostly in C, should that be something unimportant? I see the Microchip having the advantage of available devices in a wide range of IO, package and memory size.
For the STK500, I am still confused. Is the control MCU straightly for controlling the MCU in the target socket (through the AVR studio running on the PC) or it is also the target? For example, when you write the "Hello world" or blinking LED program and download the code, does it run on the control MCU or target MCU?
Thank you for the attentions.
P. I.
Point taken but eventually the code, whether hand written assembler or the compiler's code generator, has to deal with the bits and bytes and registers.
True again but you only need one device that's the right size and with the right peripherals.
It runs on the target. The uC that's in the third or the board (more or less) next to the DB-9 connectors handles the programming algorithms and other housekeeping like setting Vcc, Vref, clock speed, etc. The "control MCU" doesn't really control the target, it just acts as an SPI master while running the in-system programming algorithm (or equivalent for parallel programming). Unless in-system programming is asserted, the target uC is unaware of the presence of the other chip.
-- Rich Webb Norfolk, VA
Coming from the Intel 8086 camp, I surely appreciate the Atmel's instruction set. However, more often then a lot of time. instead of reading the disassembly code, I tend to use printf to examine intermediate results,
And with a wider choice, the chance of finding a device of the right size and right peripheral is higher.
Thank you for the info. I guess the difference is that the PIC sucks the control MCU into the ICD.
P.I.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.