Olin Lathrop escreveu:
> That seems silly for a production bootloader.  You're not trying to teach
> students about how a bare PIC works, and you are in a environment where s=
ome
> restrictions on the app code should be fine.
>   =

I don't think it is very hard to teach how a boot-loader works, but if
the teacher wants to save his students from this at first, it is his option.
And yes, I think it is not a problem to put some restrictions on the
structure of the program for production applications.
But Microchip's approach is good, because you may use any firmware that
don't invade the boot-loader area, even if it is years old, even without
rebuilding.
> My TCP bootloader for the PIC 18 just specifies that execution of the app
> starts at 4.  That leaves two instruction words before the first interrupt
> vector.  That is enough for a GOTO instruction, which can jump to any
> location in memory without being dependent on current state (unlike a PIC=
 16
> GOTO which depends on PCLATH).  The bootloader owns locations 0-3 and a
> chunk at the end of memory.  The bootloader only needs to ignore data sent
> to it outside the app range.
>   =

My boot-loader signals an error and refuses the application if it
receives data outside the proper area.
What happens when the program try to call a routine or use data that was
discarded?
> This still makes it easy to test the app by itself.  The app code has two
> NOP instructions at 0, followed by the GOTO.  When the app is loaded
> directly with a programmer or the ICE, the PIC executes the two NOPs on
> startup instead of the bootloader.  The same HEX file can either be
> programmed directly or passed to the upload program to send to the
> bootloader just like in the other case, but the bootloader itself is less
> complex.
__________________________________________________
Fa=E7a liga=E7=F5es para outros computadores com o novo Yahoo! Messenger =

http://br.beta.messenger.yahoo.com/ =


-- =

http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist