Bootload code using XON/XOFF? RS232 & SPI using same lin

[lifespeed]

I want to start by thanking all those who have helped me with the finer points of PICs and the CCS compiler. I'm a hardware guy by training, so this is somewhat new to me.

It is desireable to have the ability to upgrade firmware in a product that is already "in the field". Not that there would be any bugs hidden in the first rev of firmware

The customer interface is SPI, so the product looks like just another SPI device to the user. However, it would be desireable to have the ability to accept communications over RS232 because it is commonly available outside microcontroller systems via PC, and because it makes the product easily controllable for customer evaluation purposes. Most importantly, it is useable for bootloading code for firmware upgrades by the customer.

I have been reading about RS232, and am concerned that with the minimal RS232 connections to the PIC (TX1, RX1 and ground) I will be limited to XON/XOFF flow control, which are controlled by ASCII chars 17 and 19. Is this incompatible with downloading a hex firmware file via bootloader? It would seem that a hex file for download would inevitably contain these characters in it somewhere. Wouldn't this make it impossible to download code without hardware flow control? I do not have the pins available to the outside world (DB9 connector) to implement hardware flow control to the PIC. I had planned on using a MAX232 transceiver chip or similar to accomplish the level shifting through an external adapter board.

Currently, the "data" input line is connected via jumper to either RC6/TX1 or RD5/SDI2. The "clock" line is connected via jumper to either RC7/RX1 or RD6/SCK2. I would like to short these connections together to remove the necessity of opening up the unit and switching jumpers to configure RS232 or SPI comms. The firmware can decide what com protocol it should be using. With the unused ports set as inputs to avoid corrupting the bus, will this work?


I am using the PIC18F8722 with CCS ver 3.234 . I am considering using a bootloader written by http://www.thebytefactory.com/
_________________
Lifespeed

[asmallri]

First off there is nothig to stop you implementing a SPI bootloader.

Bootloaders come in all sizes, colours and flavours. The type I use transmits a intel hex format file line by line. The intel hex format contains the program bytes in ASCII representation. The hex value 0x11 would be represented as the two ASCII characters 11. Note that 0x11 is the equivalent of the XON character. What this means is that XON/XOFF or any binary value can be represented in the file and will be transparent to the bootloader as the only characters the bootloader will see are ASCII cannarcters 0..9, A..F, a..f, and the three record delimiter characters : <CR> <LF>

The bootloader you are looking at looks fine - you could also use the free CCS bootloader. One of my bootloaders runs at 10Mbps, most of my serial bootloaders run at 115Kbps and my slowest at 56Kbps, so 19.2K bootloader seems a bit slow to me :-)
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!

[lifespeed]

Thanks for the info on ASCII-encoded hex files. I will look at the CCS bootloader.

Unless there is something I don't know about, which is entirely possible, SPI bootloaders are relatively inaccessible to an end user with nothing more than a PC at their disposal, PC's don't speak SPI, and parallel port bit-banging is operating system specific. There are quite a few reasons to have RS232 available, the bootloader is only one reason.
_________________
Lifespeed

[asmallri]

The SPI bootloader only makes sense if you can get to it from whatever user interface is available to you. In a multi-pic environment I used an RS232 bootloader to access the "Master PIC" and used SPI from the master to the slave devices to bootload the slaves. In this case the SPI was the only interface to the slaves that was accessable.

If you are looking at new designs you might also want to consider USB as the interface and implement a USB bootloader - this is easy if you are using an FTDI type controller as it hides the complexity of USB, in fact I found it easier to implement that a serial bootloader. If you want to use a PIC with embedded USB then its significantly more complex. USB is really only viable for current generation of Windows XP and Linux environments on the PC otherwise you get into the "New Hardware Found Insert Disk now" problem where of course your customers does not have the disk, lost the disk, or swaer it worked before without any disk. USB is so "play and break" that if you do not have the disk available and select cancel, Windows will most likely trash the USB bus and you cannot access and USB device on the PC without rebooting the operating system.

USB, from a controller interface perspect, is still not ready for prime time however, in the case of new notebooks, you really don't have much choice. I am currently working on a remote data logging system using Ethernet as the interface even though the only device it will plug into is a notebook once a month for downloading data. This is the cleanest way I have found to deal with the problem where you do not know what notebook the client will use and do not want to inherit the USB drive problem.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!

[f00dstamps]

is it possible to use the SPI of a microcontroller(pic18lf252) to retrieve data from an MMC/SD card and bootload itself?