PIC programming techniques...

A

asdf

Guest
Hello everybody,

A question that has been bothering me lately is this...

What is the difference in how PICs are programmed. For example, the PICAXE
and Basic Stamps use a simple cable connection (RS-232 or USB) to a PC with
no high dollar "programmer." As opposed to PIC Micro or AVR PICs that use
expensive programmers. Is it that the former has a preprogrammed boot code,
and that the later can write said boot code to the chip. I'm just confused
as to why they all don't use the cheaper (easier?) method of programming.

Also, wouldn't most boot codes be pretty much the same. Why re-invent the
wheel each time. I would think the IC manfacturers would just program the
boot code to begin with. So, in other words, why would one want such access
to the boot code. This is all assuming that my above reasoning is correct.

Thanks,

Scott
 
On Sun, 7 Dec 2008 12:38:40 -0500, "asdf" <sadf@sdff.com> wrote:

Hello everybody,

A question that has been bothering me lately is this...

What is the difference in how PICs are programmed. For example, the PICAXE
and Basic Stamps use a simple cable connection (RS-232 or USB) to a PC with
no high dollar "programmer." As opposed to PIC Micro or AVR PICs
PIC is not a generic word for "microcontroller." Microchip makes PICs,
Atmel makes AVRs.

that use
expensive programmers.
I haven't done much with PICs, lately, but the AVRs may typically be
programmed with a simple serial in-system programming technique (similar
to an SPI link). Those programmers are relatively inexpensive. The
Atmel-branded AVRISP2 (USB on the PC side) is only about US$35 and there
are plenty of plans on the 'net for roll-yer-own versions, mostly using
RS-232 on the PC side.

There *are* more expensive options, typically based around an ICE
(in-circuit emulator), but those are not needed just to load and run
compiled code.

Is it that the former has a preprogrammed boot code,
and that the later can write said boot code to the chip. I'm just confused
as to why they all don't use the cheaper (easier?) method of programming.
Bootloaders take up space.

End-users may want a particular flavor of bootloader, e.g., one that
accepts an encrypted image file.

A serial bootloader connects to a serial port, a resource that may be
otherwise occupied so special provisions may be needed to configure it
for a bootloader.

Other methods, such as JTAG, are similarly "easy" but can be much faster
and provide additional capabilities.

Those considerations aside, some microcontrollers do come from the
factory with "built-in" serial bootloaders. Others provide boilerplate
application notes and/or have third parties who provide them.

Also, wouldn't most boot codes be pretty much the same.
Erm, no, since most microcontrollers aren't pretty much the same. Some
routines are probably re-usable (hex to bin, that sort of thing).

Why re-invent the
wheel each time.
Because the carts are different sizes. An ATtiny13 with 1 K flash and 64
bytes of RAM won't support much of a bootloader.

I would think the IC manfacturers would just program the
boot code to begin with. So, in other words, why would one want such access
to the boot code. This is all assuming that my above reasoning is correct.
QED.

--
Rich Webb Norfolk, VA
 
On Dec 7, 11:38 am, "asdf" <s...@sdff.com> wrote:
Hello everybody,

A question that has been bothering me lately is this...

What is the difference in how PICs are programmed. For example, the PICAXE
and Basic Stamps use a simple cable connection (RS-232 or USB) to a PC with
no high dollar "programmer." As opposed to PIC Micro or AVR PICs that use
expensive programmers. Is it that the former has a preprogrammed boot code,
and that the later can write said boot code to the chip. I'm just confused
as to why they all don't use the cheaper (easier?) method of programming.
There is no such thing as an "AVR PIC". PIC is a product of
Microchip, Inc. AVR products are something else entirely.

PICAXE & Basic Stamp are what one might call "middleware"
applications, on top of Microchip PIC models. Besides the bootloader,
they have interpreters for their languages. The bootloaders &
interpreters occupy code space (memory) that becomes unusable for
other purposes. Interpreted code can't run as fast as native, machine-
level assembled code. Hardware functions available to an assembler
may not be available to the interpreted code. If timing is critical,
it can be very difficult to tell how many instruction cycles are
actually being used in an interpreted instruction, but working with
assembly language one always knows that each instruction takes exactly
1 cycle, except where there's a conditional jump, which takes 2
cycles. With that knowledge, one can accurately predict execution
times, but without it you can't (if that sort of thing is important).

PICAXE & Basic Stamp are great for learning basics & some quick
prototyping. When there's a lot of work to do, they're not so
convenient. Programmers aren't expensive at all, unless you expect
everything to be free, & well worth the price. They're also not that
tough to build, if you're so inclined (& not a bad learning exercise,
if you're not).

Also, wouldn't most boot codes be pretty much the same. Why re-invent the
wheel each time. I would think the IC manfacturers would just program the
boot code to begin with. So, in other words, why would one want such access
to the boot code. This is all assuming that my above reasoning is correct..
Why would all controllers be the same? Why do you suppose there are
so many different models, if they're all the same? The whole point of
embedded programming (that others may disagree with) is to gain access
to the hardware at its most primitive level. If you have to deal with
somebody else's loader, driver, etc. you can't get that primitive
access, only what the loader/driver writer thinks you should have. In
any event, somebody has to write that code, anyway. Look at a typical
uC's machine-level instructions & see what the hardware is actually
doing. If you want to work at a higher level, where you're just
calling functions that are already written (by somebody), there's
always Windows...

JM
 
On 2008-12-07, asdf <sadf@sdff.com> wrote:
Hello everybody,

A question that has been bothering me lately is this...

What is the difference in how PICs are programmed. For example, the PICAXE
and Basic Stamps use a simple cable connection (RS-232 or USB) to a PC with
no high dollar "programmer."
no the don't, they fake it.

As opposed to PIC Micro or AVR PICs that use expensive programmers.
3 resistors is expensive?

Is it that the former has a preprogrammed boot code,
and that the later can write said boot code to the chip. I'm just confused
as to why they all don't use the cheaper (easier?) method of programming.
manufacturing cost is (sligtly) higher.

Also, wouldn't most boot codes be pretty much the same. Why re-invent the
wheel each time. I would think the IC manfacturers would just program the
boot code to begin with. So, in other words, why would one want such access
to the boot code. This is all assuming that my above reasoning is correct.
boot code wastes space in the flash rom. and requires that the
processor can write to its flash rom itself (or that it stores your
uploaded program in eeprom)...
 
On Dec 8, 3:38 am, "asdf" <s...@sdff.com> wrote:
Hello everybody,

A question that has been bothering me lately is this...

What is the difference in how PICs are programmed. For example, the PICAXE
and Basic Stamps use a simple cable connection (RS-232 or USB) to a PC with
no high dollar "programmer." As opposed to PIC Micro or AVR PICs that use
expensive programmers. Is it that the former has a preprogrammed boot code,
and that the later can write said boot code to the chip.
That is basically correct.
You need a "real" programmer to program a blank PIC or AVR chip.
A PICAXE for example is just physically a normal PIC chip, but you buy
it pre-programmed with code that lets you access it via serial cable.
This pre-programmed code (kinda like a bootloader, but it's really an
interpreter application) is designed to allow you to upload your own
programs in the spare memory space on the chip, and then it runs your
program line-by-line.

I'm just confused
as to why they all don't use the cheaper (easier?) method of programming.
Because it's really just for beginners and simple applications. PICAXE
and BASIC Stamps are very slow, have limited memory space, and you may
not be able to access all the hardware features of the PIC chip.

More experienced users prefer to write their own program from scratch
in C or assembler (or even BASIC), and use the "real" programmer.
BTW, "real" programmers are not expensive, the PICkit2 for example is
very cheap:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en023805
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail?name=PG164120-ND

Also, wouldn't most boot codes be pretty much the same. Why re-invent the
wheel each time. I would think the IC manfacturers would just program the
boot code to begin with. So, in other words, why would one want such access
to the boot code. This is all assuming that my above reasoning is correct.
It's not really "boot code", it's a BASIC interpreter application, and
it's a proprietary system.
In theory it would be possible to turn almost any microcontroller, be
it PIC, AVR, MSP430 or whatever into a "PICAXE" like device.

Dave.
 

Welcome to EDABoard.com

Sponsor

Back
Top