![](templates/subSilver/images/CCSLogo.jpg) |
![CCS C Software and Maintenance Offers](templates/subSilver/images/forumAd6.jpg) |
View previous topic :: View next topic |
Author |
Message |
lifespeed
Joined: 17 Aug 2005 Posts: 19
|
Bootload code using XON/XOFF? RS232 & SPI using same lin |
Posted: Mon Oct 17, 2005 5:06 pm |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
asmallri
Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia
|
|
Posted: Mon Oct 17, 2005 7:18 pm |
|
|
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!! |
|
![](templates/subSilver/images/spacer.gif) |
lifespeed
Joined: 17 Aug 2005 Posts: 19
|
|
Posted: Tue Oct 18, 2005 10:01 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
asmallri
Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia
|
|
Posted: Tue Oct 18, 2005 6:14 pm |
|
|
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!! |
|
![](templates/subSilver/images/spacer.gif) |
f00dstamps
Joined: 28 Mar 2006 Posts: 10 Location: Kansas City, MO
|
spi to retrieve hex from MMC/SD card |
Posted: Thu Apr 20, 2006 3:01 pm |
|
|
is it possible to use the SPI of a microcontroller(pic18lf252) to retrieve data from an MMC/SD card and bootload itself? |
|
![](templates/subSilver/images/spacer.gif) |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|