Bootloader for 16f87/88 that doesn't use UART

I have a board with a 16f87 that has a two way PC connection that is bit banged, with the HW UART used to transmit a high speed one way signal to some other equipment.

What I would like to do is add a bootloader to simlify reloading or updating firmware.

I've done a quick search and it seems all the usual suspects need to use the HW UART for bootloader activity. I saw a thread a while back about the SparkFun bloader being able to use any pin, but it seems its not so.

So has anyone seen a bl for a 16f87 that allows the use of a software uart ?? What would be great is one written in pbp, as it would be easy to maintain and make changes to led flashing when in boot mode etc.

with thanks,

bill

Sure it exist or at least it could be done... as long as you're aware and you agree that the bootloader firmware will be way bigger and you're not code limited...

But... why you don't want to use the hw USART?

I saw once a 1 pin bootloader, and didn't used the HW USART, Wloader if my memory serves me well.

There's also that one using MCLR pin... omg, what was it's name... ZPBL or ZPL.

what i suggest is to look at TinyBootloader page, there's few suggestions over there.

Hi Steve,

Code space is not an issue. I cannot use the hw uart as I need it to generate rs485 at 250Kbaud ! On the PCBs it is wired as TX only, but even so I have not seen a half-duplex bootloader (please correct me, anyone..)

I looked at TinyBootloader earlier, but again it is tied to HW UART pins.

I'll keep looking. I found a mention on the Spark Fun site that bloader 1.6 could handle the 16f819, which doesn't have a uart. Maybe a bit iof creative code work is required...

bill

Scroll to the bottom of the TinyBootloader main page and there's a list, with links, of other bootloaders, including ZPL and WLoader, which do not use the UART.

Very early on, Tony Nixon used to have just such a bootloader, RomZap. Not only could it use any pin, it also had an option to invert (or not) the signal, making it ideal for direct connection to the serial port. To my knowledge, development on this stopped a while ago, so I'm not sure about the support for 16F87. In case you are interested, I could mail you a copy, since Tony had kept it free.

Regards,

Anand

Melabs had their meloader no longer sold perhaps if you call them they'll sell you one.(it's a great piece of software)
also basicmicro sells their programmer you can build a loader within their programming software
for any pin.( at least it use to be this way but you may want to take a peek)

Victor

Found a couple of options:
WLOADER - http://www.voti.nl/wloader/index_1.html
this allows any pin to be used and can work with a single pin. SRC code is in ASM with a command line Windows option (with Source in Delphi) or a Wiindows based app in Python.

PIC_E - http://www.ehl.cz/pic/pic_e.htm
Uses hardware UART, but has nice Delphi front end for PC and source code for PIC in ASM.

I am now looking at re-writing the PIC_E firmware using PBP to make it work with out the UART for my specific PIC.

These two don't have 16F87/88 definitions, but looking at the source it shouldn't be too hard to add the required info.

I might also look into RomZap - I remember reading about it a few years ago when I first toyed with the idea. Anand, if you have a copy could you email it or PM me.

If I get it going I'll upload it here.

Bill

ROMzap - http://piclist.com/images/com/bubble...mo/ROMzap.html

Looks pretty advanced for what I need - it seems to use UART, although it does support the 16F872 which doesn't have a UART.

I am downloading it now and will dig in to the Source files (if they are in the ZIP) to see how customisable it will be.

So has anyone ever written a bootloader in PBP??

bill.

Take a look at this code maybe it will help.
http://www.oshonsoft.com/picbootloader.html
victor

Hi Victor,

Fantastic ! That gives me a good starting point. The PC applicatin looks a lot like the PIC_E one.

Looks like I am going to spend Sunday in the shed learning how to bootload !!

With Thanks,
Bill.

Quote:

---

Originally Posted by bcd

ROMzap - http://piclist.com/images/com/bubble...mo/ROMzap.html

Looks pretty advanced for what I need - it seems to use UART, although it does support the 16F872 which doesn't have a UART.

I am downloading it now and will dig in to the Source files (if they are in the ZIP) to see how customisable it will be.

bill.

---

Yes, the interface does look a bit complex first, but thats because its so configurable. Once you figure out the things you need, its a breeze to use. No it doesnt use the UART; you could use any pin for the bit banging.

Pity it only supports the 16F8XX chips, though; if you are able to adapt it for others, I would love to hear about it too... it was my preferred bootloader for a long time, till I had to switch over to the one from Mecanique. I still miss the flexibility and the option of not having to use a level shifter.

Regards,

Anand

Quote:

---

Originally Posted by bcd

So has anyone ever written a bootloader in PBP??

---

See http://www.picbasic.co.uk/forum/showthread.php?t=4498

bcd,

If you're going to start with that bootloader for the 16F877?
There are some significant differences when writing to flash memory on the 16F87/88's.

The 877 allows you to write 1 word at a time. And when you write it, the chip automatically erases the word before writing the new data. This is the main reason why 99% of the free bootloaders use the 16F877. (it's easy)

The 16F87/88's require that you erase memory in blocks of 32-words first, then write the new data in blocks of 4-words. (more difficult)

It's still very doable.
Just thought it might help get you on the right track.
<br>

Quote:

---

Originally Posted by bcd

If I get it going I'll upload it here.

---

That would be great. I have several applications where I'd like to use a 16F88 with a bootloader well enough documented for me to write Windows/Linux/Mac interfaces (using PureBasic) but the bootloader, itself, is beyond my skill level.

After a weekend in the shed I have learned more about the memory layout and programming requirements of the 16f87/88 then I think I ever wanted to know.

Darrel Taylor - Excellent piece of advice re the ERASE / Write cycle. I am investigating the best way to do this, as well as making sure we don't overwrite the bootloader at the high end.

dhouston - Thank you for the link to the thread on the 18F bootloader. There is some great info on reorganising the libary to get round some jumps to 0 that I had been seeing in some hex code I created.

There is so much to learn and so much more playing to do. Stand by everyone - its coming ! We are at 650 words, but I am trying some tricks to squish that down as there are other things I would like to add.

bill.

Quote:

---

Originally Posted by bcd

There is so much to learn and so much more playing to do. Stand by everyone - its coming ! We are at 650 words, but I am trying some tricks to squish that down as there are other things I would like to add.

---

Once you post what you have, Darrel Taylor and Bruce Reynolds likely to suggest further improvements.

Clarification ....

You make it WORK.
We can All add to the "squish" part. :)

Useful project, I promise to do my share.
<br>

Quote:

---

Originally Posted by Darrel Taylor

We can All add to the "squish" part. :)

---

Shooting for a 12 byte bootloader are ya? :D

i know 35words is doable... but 12 :eek:

Quote:

---

Originally Posted by Darrel Taylor

You make it WORK.
We can All add to the "squish" part. :)

Useful project, I promise to do my share.
<br>

---

I'd offer to help squish but fear I'd squash. Once squished, I'll provide PureBasic source for Windows/Linux/Mac interfaces. I can test Windows & Linux but don't have a Mac. PB code is fairly easy to convert to VB.

Quote:

---

Originally Posted by dhouston

I'd offer to help squish but fear I'd squash. Once squished, I'll provide PureBasic source for Windows/Linux/Mac interfaces. I can test Windows & Linux but don't have a Mac. PB code is fairly easy to convert to VB.

---

Generic question about bootloaders...since I haven't had the need to use them.
Do the bulk of the bootloaders out there do HEX files or straight binary data (assuming you're not ever changing the config registers, IDLOCs, etc.)...

I think most, if not all, handle hex files.

i'll second the .HEX. Anyways.. what's the point of .BIN file while none of the assembler i know generate it anyway :D

Wow ! What have I started !

dhouston - i was aiming to take the freeware delphi source from the PIC_E project, as I hate the way VB projects seem to bloat. But looking into the source it has a checksum and some other funky stuff I don't think we need. It has also been a long time since I did any delphi stuff and I might be out of my depth. Is PureBasic a good coding app - I have never heard of it before.

mister_e - agreed .hex is the way to go. F10 in MCS to the unit. Hmmm - there is a thought - can we pass command line options to it for the name of the hex file ??

i have been thinking about other thinks that would be good and I am looking into the ability to also write the internal EEPROM. I have disected the INTEL HEX format and worked out which data points to which locations and it looks like it should be quite easy (famous last words...)

bill.

Quote:

---

Originally Posted by bcd

Is PureBasic a good coding app - I have never heard of it before.

---

It's excellent. It's inexpensive. It's cross-platform. It compiles to teensy-weensy standalone executables. It's been a well kept secret. Here's the homepage - http://www.purebasic.com/

If you can supply easy to understand documentation, I'm willing to code the interface apps.

Hi Guys,

based on what I found in http://www.picbasic.co.uk/forum/showthread.php?t=4498 I set about modifying the PBPPIC14.LIB to move the library functions out of the low memory so we don't overwrite them when we upload a new programme. I was getting compilation errors about not being able to move the librarys off page 0, but commented out the warning section to see what happened.

Well the answer was - nothing. The programme appeared to not start (I have some LEDs to give me status). I set the library to start at 800 using a custom Make_Loader define that I had in my BL program and it works again.

Custom Define definition from PBPPIC14.LIB
<code>
ifdef MAKE_LOADER ; Added by Bill Coghill 08.01.08
LIST
ORG 800 ; Keep the library code out the way
NOLIST ; was 3584, but would then not work
endif
</code>

So it looks like we can't move the PBP libary files out of page 0 which means that we either need to see if we can jump over them with an ORG 128 (or similar - remember we can only erase blocks of 64 words).

What I need to do is see how big the PBP libraries are when I use an ORG to move the actual program code to high memory.

I wonder if only the Librarys that are used are compiled in ? That would mean if I was to use the bootloader with a skip over the libraries to upload a file that didn't use a library that the Bootloader needed that the next time you tried to go to bootloader mode it would hang the chip.

Just did a quick test and it seems that 153 words are needed for the library functions. But more testing reveals that PBP compiles in the Libs it needs, meaning that the value for the libs may change according to the commands used.

Oh dear and it was all going so well. I need to think about where we can go now.

We might end up loosing a lot of space as a skip at the beginning for the Libraries and 400 words for the BL at the end !!

bill.

Well,

http://www.picbasic.co.uk/forum/showthread.php?t=4498 works.. but the hack you tried doesnt. The only way I have gotten this to work is to (as stated later in the thread)

ifdef LOADER_USED
LIST
ORG 60160 ; Own loader address depending how big loader you write
NOLIST
endif

And if you first write your bootloader and then you can change the address from where it starts to allocate just as much memory as it needs. By putting the bootloader last in the program space you also get less trouble with interupt vectors if you are using a 18-pic with high and low priority interupts. This is an ugly hack and dont forget to change back these things when you plan to compile your normal software.

/me

Jumper,

It seems the 16 series pics are different in how the libraries are assigned in memory space. I am going to look further in to it, but will try to mod the LOADER_USED jump as suggested.

stay tuned..

bill.

Well I did a bit more digging and talked to Jeff at MELabs.

This is what he told me :
<quote>
Jeff Schmoyer wrote:
Hello,

The problem is that you really can't do that. For the 14-bit
core parts, the library must be at the bottom of memory. The
bootloader has to be a completely separate program, including
its own library. This really isn't practical for a 14-bit
core part.

We did make a change for the PIC18 parts to allow the reset
location to be changed. This allows you to move the library
and the entire program up to higher memory. When you
boot load in a new program, it fills in at the bottom as
usual, with the bootloader and its library still up high.

For the 14-bit core parts, you will need to create an
assembler boot loader that does what you want, or modify
one of the many that are already out there.

To write one in PBP, you will need to move to a PIC18 part.

Thank you,
Jeff Schmoyer
microEngineering Labs, Inc.
</quote>

So it looks like it is back to reverse engineering other peoples ASM code to make it run in the 16F87. I am now going to look at the WLoader ASM and see how 'portable' it is to the 16F8x series.

Stay tuned...

bill.

This might be a silly question, but why not move to 18F parts and solve the problem that way?

Hi Charles,

I looked into using something like the 18F1320, but the HW UART pins have moved, which means a redesign of the PCB.

Wehn the product comes up for a design refresh I will look at moving to a new processor, but for now looks like I am stuck with the 16f87.

All is not lost as I think I can re-engineer the WLoader to work.

bill.

Quote:

---

Originally Posted by Charles Linquis

This might be a silly question, but why not move to 18F parts and solve the problem that way?

---

In my case, I want to use the internal comparators as inverters for the UART and I haven't found an 18F PIC in the same size range as the 16F88 that will let me do that.

Still looking in to this and I think I have found a way. Using the SparkFun BLoader code and a quick tutorial on bit-banged serial ports in C I am aiming to do a bit of testing this weekend.

Not as nice as a pbp based one, but if it works - woohoo !

bill.

Quote:

---

Originally Posted by bcd

I looked into using something like the 18F1320, but the HW UART pins have moved, which means a redesign of the PCB.

---

You using DIP or SOIC?
If DIP, put one in a socket, pop out some pins and run some jumpers.
Not the best fix in the world, but works for me.
If SOIC, maybe cut some traces and run some jumpers.
Same thing, not the best, but it works.