gnupic: Thread: Re: [gnupic] gplink Question

On Tue, 4 Jul 2006, M.S.Waters ####@####.#### wrote :
>
>I'm in the process of developing a PIC bootloader specifically for
>Linux based PIC development.

Been there, done that. Twice. The first one was for a "MIDI drum pad" 
project for www.livewires.org.uk so the download sequence obeyed the 
rules for a MIDI system exclusive message. The second was on RS232 so I 
made some minor adjustments to the protocol.

>
>The bootloader is made up of 4 ASM modules which are separately
>assembled and then linked with gplink. The bootloader is designed to
>be installed at the top of the PIC's memory.
>
>I would like to hard code a memory address in one module using an ORG
>or CODE directive and have the linker place the remaining modules
>after the first. At present I must address all 4 modules separately
>which kind of defeats the purpose of using the linker.
>
No, you don't use ORG with the linker. What you do is declare all the 
code to be in a suitably named code section, so each file contains

boot code        ; Put this code in the bootloader block

Then you need to create an appropriate linker file, based on the default 
one but with changes. In particular you need to define a logical code 
section called "boot" at the top of the flash.

CODEPAGE   NAME=BBLOCK    START=0x0700   END=0x07FF   PROTECTED

SECTION    NAME=boot      ROM=BBLOCK

Then set up your makefile to use that linker file and it should work. 
I've done this extensively in my current project. Code from different 
files allocated to the same section will be linked end-to-end in the 
order the files are listed on the gplink command line.
-- 
Rob Pearce                       http://www.bdt-home.demon.co.uk

The contents of this | Play Rogue, visit exotic locations, meet strange
message are purely   | creatures and kill them.
my opinion. Don't    |
believe a word.      |

Hi All,

Thanks for all the replies. I haven't had time to actually
implement them but it's given me a good starting point.

There are some really good ideas floating around out there but
I haven't found a bootloader that incorporates all of them IMHO.

I'm currently using the Tiny Bootloader until I get mine going.
I've found it to be very good and have even got the GUI running
under Linux and Wine. I think keeping the functionality and
therefore code size to a minimum is a good idea but not at all
costs. There are certain features which in my view are essential
and well worth the code space used. These include:

 * Readable / maintainable sources (assembler is not easy to
   read at the best of times).
 * Auto baud rate detection (no need to alter the bootloader code
   due to a change in crystal frequency).
 * No need to modify the user's code to accommodate the bootloader.
 * Error detection.
 * GNU Licensed.

Julian: I'd be interested in looking at your code for your client
tool. I'm using wxWidgets for a different project and have toyed
with the idea of developing a GUI for my bootloader using wxWidgets.
Would you email me a copy.

Mike Waters

Hi All,

As a follow-up to a question I asked about 10 days ago re gplink
(see below).

The solution was to hard code the start of the boot loader using
an ORG directive in the main module and using CODE directives (with
no address) in the remaining modules. If the main module is passed
to gplink first all following modules are linked as desired.

This is what I was hoping for. The actual problem was due to an
incorrect gplink command line argument.

On Tue, 2006-07-04, Mike W. wrote:
> I'm in the process of developing a PIC bootloader specifically for
> Linux based PIC development. At this stage it will be comprised of
> the bootloader and a CLI utility to talk to the bootloader. Both the
> bootloader and CLI are 70%-80% complete.
> 
> The bootloader is made up of 4 ASM modules which are separately
> assembled and then linked with gplink. The bootloader is designed to
> be installed at the top of the PIC's memory.
> 
> I would like to hard code a memory address in one module using an ORG
> or CODE directive and have the linker place the remaining modules
> after the first. At present I must address all 4 modules separately
> which kind of defeats the purpose of using the linker.

Mike W.