Olin,

Re: Original Post.

The UART is being used by another part of the project. The TX and RX pins to
the com serial interface are bit-bashed.

ie. The UART controls a Radio Module via the RXD and TXD pins (RC7, RC6).
The serial com link for command reception and message routing are via RB0
and RB1 (bit bashed), these pins go to both a MAX202 and MAX485. This is
where I want to upload new operating code from.

Regards

David Huisman

-----Original Message-----
From: pic microcontroller discussion list
[mailto:PICLIST@MITVMA.MIT.EDU]On Behalf Of Olin Lathrop
Sent: Monday, July 30, 2001 11:30 PM
To: PICLIST@MITVMA.MIT.EDU
Subject: Re: [PIC]: Bootloader using Bit Bashed IO and C Source


> My project already has TXD and RXD coming out via a MAX202 for RS232 level
> conversion. These lines have a shared function. They allow control of the
> project as well as updating of firmware.
>
> What I am looking for is this.....
>
> 1) At production, project is supplied with bootloader pre-programmed into
> PIC16F876 via ICSP.
>
> 2) Project is supplied with Windows package that does 2 things...
>           A) Allows operating code (for project to perform required
> functions) to be uploaded
>             B) Allows testing of unit once operating code is loaded
> 3) When project is powered it is in either of 2 states.
>           A) No operating code has been uploaded (bootloader only is
> programmed)
>           B) Operating code is programmed and running
>
> 4) In Case A of "3", The bootloader receives commands and bytes from the
> bit-bashed serial
>    link to program the Operating code into Flash ROM.
> 5) In Case B of "3", The operating code responds to commands via the
> bit-bashed serial link
>    (eg. Switch LED ON, Read ADC etc). It will also respond to commands to
> upload new Operating
>    code. In this case it will call the bootloader programming handler.

I don't understand why the bootloader must do manual bit twiddling.  You
have the TX and RX lines already going out and turning into RS-232.  It
sounds like everything is already connected, so why not just turn on the
UART and use it?  I've done exactly this on this chip, although the GET and
PUT byte routines are modular so that they could be replaced by a different
means of getting the bytes from here to there.  The uploader always does
programmed I/O so that it doesn't need to own the interrupt vector.  In one
case it even used a different baud rate from the main firmware, which had
totally interrupt driven UART I/O with software FIFOs.  Since nothing else
is running when the uploader is running, there is no conflict in it taking
over resources that will be used by the main code differently later.  Note
that this applies to RAM locations as well.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, olin@embedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu


---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.265 / Virus Database: 137 - Release Date: 7/18/01

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.265 / Virus Database: 137 - Release Date: 7/18/01

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu