Subject:
Re: [gnupic] [ANN] Pikme PIC Bootloader (for 16F819 etc)
From:
"Frank Sergeant" ####@####.####
Date:
25 Jul 2006 22:27:43 +0100
Message-Id: <11493.1153862884@bed.utoh.org>
(I hope I am not posting this a second time. I think my first try
failed due to using the wrong From: address.)
Byron A Jeff ####@####.#### wrote:
Thank you for your detailed and thoughtful comments.
Let me say first, that I find various bootloaders and also software
minimization and particularly hardware minimization *interesting*. I am
not suggesting a single approach (even mine!) is the best in every
case. I may well spend more time fooling around with a bootloader than
it is actually worth.
> > It uses only half of an I/O pin on the PIC (that is, it can use an
> > input-only pin) and even that pin can be used for other purposes by the
> > application, providing it doesn't wiggle at boot time.
> Interesting choice. That's getting close to Wouter van Ooijen's ZPL
> which used wiggling on MCLR to reset the PIC after specific time delays.
> The length of time that the PIC ran determined the bit transmitted.
> ZPL = Zero Pin Loader.
Thanks for reminding me of that. I've seen his page but haven't taken
the time to study it in detail. I felt the initial mention of the code
taking about 1K disqualified it from consideration for a 16F818/819 (with
only 1 or 2 K of instruction words). Of course, that doesn't mean than
some aspects wouldn't be useful.
> > It uses a one-way serial interface from the PC to the PIC (so, 2 wires:
> > the PC's TX pin and ground). It is bit-banged to do inverted TTL serial
> > (fake RS232) so that no MAX232 or similar is needed.
> Depending on the serial port, this may be a problematic choice. Unfortunately
> some serial ports don't even come close to generating the 4V required to
> register as a 1 on the PIC.
That's a good point. The first thing I would try if I ran into this
would be a pull-up between the PIC's 5 V and the PIC's serial input
pin. (And, if using the RA5/Vpp/MCLR* pin for the serial input, that
pin should be pulled up or down anyway if the serial port is not
connected.) So, this would be an even simpler circuit than the one I'm
using with my desktop machine.)
> Also I read your pinouts.txt file. Using a pot to tune the voltage is
> a bit time consuming.
I guess that depends on how many host PCs you would use. It is a
one-time action per host machine. I wire the (miniature) pot, connect
the PC serial side (but not the PIC side), measure the output as I turn
the pot until the output voltage is approximately -5 V and viola (as we
in the string section like to say), it's done. Yes, there is no
guarantee the negative and positive excursions of the PC's serial port
are symmetrical, in that case some further adjustment would be necessary
-- again one-time per host PC. Another choice would be to measure the
voltage and calculate the 2 resistors for a non-adjustable voltage
divider. I might even guess at it (assuming, perhaps 11 volts and scale
it to 5 volts, download an LED flashing program (I usually download a
serial output program that says "Hello") and see what happens. The pot
seems like a nice compromise.
>A better choice may be to refer back to Wouter's El-Cheapo
> serial bootloader interface. The schematic is located here:
Yes, I appreciate that but I'm of 2 or 3 minds about it. If I get
burned bad enough some day, I might lean more toward it.
> Note that Wouter voices some concerns with trusting the PIC protection
> diodes to clamp and keep the part working properly.
Thanks for the caution. I'll keep that in mind.
> I keep debating to myself how important is robustness and verification
> in the bootloading process.
I admit I was a little nervous when I first started on this bootloader.
I was prepared to use an extra pin on the PIC for transmitting back to
the PIC (Tx) (yes, I realize we could use a single pin as Wouter does and as
Dallas 1-wire does) if absolutely necessary. For feedback while
developing the bootloader, I did use Tx, bit-banged as with Rx. The
code for that is still present, but commented out, in boot.asm.
So far, I have been tickled to find the bootloader reliable. My purpose
for this bootloader is to use it for quick turn around while developing,
rather than for using it in the field in finished products for software
upgrade. Because of that, I think I can work without a net, since I
don't have far to fall. The Python downloader does take various steps
to verify each line of the hex file (but, really, if we can't trust our
assembler, who can we trust). Can we trust the serial port to get the
data across a 3 foot cable?
Also, extensive verification can be built into the application that is
downloaded via the bootloader. It does not necessarily need to be
present in the bootloader itself.
I might well argue the other side, about the cost of lost, expensive
(human) programmer time, upset customers, etc. just to save a little
hardware cost and complexity, if we were talking about a production
quality field upgrader. So, I am not necessarily disagreeing.
> - I was thinking of locating the entire bootloader in low memory. It seems
> to me once the application cannot be transparent and must account for low
> memory that the bootloader can occupy low memory.
That's very interesting. I had been thinking of moving *parts* of the
bootloader (as much as would fit) from high-memory down to the first
32-word block, since most of that 32-block is now wasted. Your idea,
though, would eliminate the need of adjusting where the high-memory part
of the bootloader is ord'd for different processors. I like it.
Some approaches let the user application sit in that first 32-word block
and the bootloader overlays the 'goto loader' etc so that gets
reprogrammed every time. That makes me even more nervous (unaccountably, I
guess) than the blind downloading.
> - Finally I'm trying to figure out how to build a Trivial programmer that
> runs from the serial port. Something along the lines of Tony Nixon's
> ASCII programmer here:
>
> http://www.piclist.com/techref/com/picnpoke/www/http/projects/prog.html
Thanks for the link. I hadn't seen that before. I hope to find the
time to take a careful look.
> Frank, this is a fine effort and very much apprciated. I have an intern
> working on PIC bootloader stuff. I'm going to forward your stuff to him
> and get him to test it out and adapt it for the 16F88, which is our chip
> of choice. I'll let you know of any results that come from it.
Thank you again. I will look forward to how he gets on with it. I
think the 16F87 and 16F88 are my (14-bit) chips of choice also, I just
haven't switched over yet due to inertia. However, I am wondering
whether I should switch directly to an 18F chip.
--
Frank
