Starting out.

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View


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.



Re: Starting out.


On Sat, 29 Oct 2005 11:21:04 GMT, "Peter Goddard"

Quoted text here. Click to load it

Possibly your best low-ish cost bet is this one from Farnell
http://uk.farnell.com/jsp/endecaSearch/partDetail.jsp?SKU86%52449&N40%1

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
http://uk.farnell.com/jsp/endecaSearch/partDetail.jsp?SKU38%84429&N40%1
It supports all AVR devices and can also be used like an AVR-ISP to do
off-board programming of another device using the ISP header. It's a bit
awkward to carry in the field, tho.

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,
http://www.imagecraft.com/software /) as well as a GPL'd compiler
(http://sourceforge.net/projects/winavr/)


[1] The AVR-ISP only handles serial, typically in-system, programming.
It is possible to set a device's configuration fuses to not respond to
serial programming. However, all AVRs can be programmed with a
"parallel" (typically not in-system) programming method. The STK500 can
do the parallel programming.

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. http://gcc.gnu.org/backends.html

--
Rich Webb   Norfolk, VA

Re: Starting out.


Quoted text here. Click to load it

Hello,

         Thanks for the information. A further surf around the AVR webring
revealed...

http://www.kanda.com

I'm beginning to get a feel for what's out there!

Cheers

Peter.



Re: Starting out.


Quoted text here. Click to load it

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.


Re: Starting out.



Quoted text here. Click to load it

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.

Quoted text here. Click to load it

True again but you only need one device that's the right size and with
the right peripherals.

Quoted text here. Click to load it

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

Re: Starting out.


Quoted text here. Click to load it


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,


Quoted text here. Click to load it

And with a wider choice, the chance of finding a device of the right
size and right peripheral is higher.

Quoted text here. Click to load it

Thank you for the info.  I guess the difference is that the PIC sucks
the control MCU into the ICD.

P.I.

Quoted text here. Click to load it


Site Timeline