gnupic: Re: [gnupic] [ANN] Pikme PIC Bootloader (for 16F819 etc)
Subject:
Re: [gnupic] [ANN] Pikme PIC Bootloader (for 16F819 etc)
From:
Byron A Jeff ####@####.####
Date:
27 Jul 2006 02:35:57 +0100
Message-Id: <20060727013504.GA29250@cleon.cc.gatech.edu>
On Tue, Jul 25, 2006 at 11:30:23PM +0100, Robert Pearce wrote:
> On Tue, 25 Jul 2006, Byron A Jeff ####@####.#### wrote :
> >On Tue, Jul 25, 2006 at 03:44:36PM +0000, mengjin su wrote:
> >>There is an even smaller bootloader, tiny bootloader, at
> >>
> >> http://www.etc.ugal.ro/cchiculita/software/picbootloader.htm
> >>
> >>It's less than 100 words!
> >>
> >>Yes, it uses serial port as the interface for downloading.
> >
> >Size really isn't the issue. I have an issue with Tiny precisely because
> >it does use the USART, which is a valuable resource, for programming.
> >
> Why is that a problem? If you're using the USART as a serial port in
> normal operation then the circuitry is already there.
Because I may not be using the serial port to communicate with the PC.
In addition even if I'm using the serial port to communicate with the PC
I'll have two different applications needing to share that serial port
and the complexity of having to switch between the two.
> If you're not then it's not a "valuable resource" to you.
But then it's a resource that I have to manage within the guidelines
of the USART hardware specified by Mchip. RX/TX are RB2 and RB5 on the 16F88
, which are two very odd pins in the middle of only 8 bit I/O port on the chip.
Frank has the right idea. Put a bit banged serial interface on RA5, which
is a half pin input normally used for MCLR. You get a completely clear 8 bit
port to use.
I find that using the onboard serial port impacts your design in unintended
ways. By bit banging, any digital port (possibly an only input one too) can
be utilized.
Another advantage is that with a bit banged interface you can create a half
duplex protocol using the same I/O pin fo both input and output. This is what
Wouter did in developing his WLoader bootloader.
> On the 16F871 board I have in
> front of me, I'm using the USART to communicate with a PC in the end
> application, and during development the same PC does "calibration"
> monitoring via the same USART, so having it plugged in and available
> lets me use the same USART for the boot loader when I build new code.
All true. But you can't run your bootloader software and your end application
at the same time on the PC because they share the same port. By isolating
them you have the advantage of running them together giving rise to a
secondary debugging port via the bootloader interface. This is how I did
my development using linwload and Wouter's WLoader bootloader using the
same half duplex interface on the pin of my choosing (RE2 on a 16F877
in this case).
> Similarly with the first 16F871 project I did, where the USART was used
> to drive a MIDI interface. When I wanted to update the firmware I did so
> by sending it over MIDI.
Bingo. That's the problem. You're now obligated to use the application
interface of the USART for the bootloader instead of having the bootloader
as a standalong. Fortunately with MIDI it's pretty easy to do with a
SYSEX interface. But other protocols (DMX512 for example) may be a
tougher job.
To recap the advantages of bit banged interfaces:
1) Use the I/O pin of choice.
2) Can develop single pin half duplex interfaces.
3) Adds an additional debugging channel.
4) Doesn't require bootloading through an application specific interface.
5) Bootloader and application can run at the same time on the PC.
6) Works with chips that don't have a USART. Frank did the 16F819 bit banged
because he didn't have a choice.
A bit banged interface gives a lot of flexibility.
BAJ
