Microchip PICs don't come pre-installed with a bootloader firmware??

The point you miss is that some don't want a bootloader because it eats memory. Also when Microchip installs a bootloader, does it meet your requirements? Maybe you want a simple bootloader to load your programs, but I would want a more secure bootloader with encryption so that people who get my images to load, cannot disassemble those images and "steal" my design. So in short: the requirements for a bootloader can be very different for anyone and it would be therefore pointless to preload a bootloader.

Meindert

It's fair to say that most of the PIC business is either factory programmed or in-circuit programmed in high quantities. There is no reason to instal a bootloader for either of these situations. These guys sell a billion PICs a year, folks...

I know of companies who program their own bootloaders into PICs but they are for specific communications or security requirements.

-Andrew M

Thanks for insight. I wasn't aware that the bootloader was using the same memory space that my app would use. Too bad that Microchip doesn't just include a built-in bootloader separate from the memory space used for applications. This could just be a basic bootloader to download/upload code or data. They could even allow you to set a password to avoid the problem that you mentioned.

As I now see it, the point of the bootloader really is meant for after production purposes. It doesn't appear to be possible to avoid using a hardware programmer at this stage.

Thanks again Johann

They can't program it in the factory because everybody's application is different. Different IO setup requirements, different comms interfaces, speeds & protocols.

It would be a waste to spend money putting code in the chip that is only usefult to a small proportion of users.

I consider the JTAG download support a bootstrap loader. A lot of companies provide simple programmers based on this.

The MSP430 has both a JTAG programming interface and a asynchronous serial bootloader. The async version resides in user space. I have used it because it requires few pins, but I believe it is a little slower.

--
Thad

better to use a decent micro like the 8052 variants from Philips. All come with a built in bootloader in ROM that does not eat into your program space.

IAn

All? The 87C52 I use doesn't have one....

Meindert

I wish more microcontrollers would offer built-in ROM bootloaders.

How many products have you ever used or owned that offered flash updating to the end user (motherboards, modems, satellite/freeview tv decoders, etc.) that said somewhere in the flash upgrade procedure instructions something to the effect of "interrupting this process may permanently damage the product".

I interpret this to mean "we cost-cut the product so much that there is no ROM bootloader and if you get a power-cut, any form of serious glitch, crash, or any other type of failure, you might end up with a dead product that needs to be returned to the factory", which is often too expensive a repair option. It may only be a small risk, but I don't want to tell my customer 9000 miles away that the hex file I just sent him will work but that there is a small chance he'll have to send the equipment here instead. Protecting a bootloader in a flash boot block would help, but still isn't guaranteed. Adding an EPROM for this purpose alone is too expensive.

By contrast, the last two major product developments I have done used microcontrollers with primitive ROM bootloaders. These allow me to absolutely guarantee a means by which the end user can recover from a faulty flash upgrade attempt regardless of what state the contents of flash are. If I require security or other features I can use the primitive bootloader to download a complex bootloader and continue from there to download the full firmware image.

I may only end up using the primitive bootloader as a fail-safe if the regular upgrade process fails, but at least the option is there, and effectively "hard-wired" into the chip. The ROM only needs to be typically a few hundred bytes for a primitive bootloader and typically an I/O pin to activate it on bootup.

There are several ways to communicate with a processor. Just that it has a UART doesn't mean this is the to be used communication channel. SPI, external UART, Ethernet come to my mind. Then when you already communicate with a processor, then you'd wish the bootloader to have the same protocol such that it fits into your application.

Rene

--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net

snipped-for-privacy@yahoo.com wrote On 12/22/05 00:01,:

Why don't you order it burned with a bootloader ? Most distributors have automated part programmers, and can deliver the chip with your bootloader on the part for little, or no price increase over the raw part.

Please read more carefully. I said all the Philips VARIANTS

Ian

Nah Ian, you'll have to do better than that :-) The 8052 originates from Intel, so if you say "....8052 variants from Philips. All come.....", you don't say "some 8052 variants from Philips". This is standard math basics as taught on high-school. The way you said it, you implied that all variants from Philips have a bootloader. Damn, this is bad for my headache.....

Meindert

Think again - I did not say all Philips 8052 devices have a boot ROM loader I said all Philips 8052 VARIANTS i.e. variants on the original 8052 from Intel and not the straight copies.

Ian

loader

Ah, now I know what you mean. And I am still not convinced. The Philips

80C451 has no bootloader and is not a direc copy of an existing Intel type..... :-)=)

Meindert

That part is discontinued. Try again.

Ian