In my latest articles I describe some models to work with memory relocation... so here's the result of that blah blah blah!
Yablo
There's tons of bootloaders abroad. But seriously, I was tired to make LED's blinking all the time, and definitely I took this challenge. Would you dare?
Yablo is an acronym for Yet Another BootLOader...
Differently from many other bootloaders:
- It's not short (I was fighting with compiler to have it less than 1024 bytes). It has about 0x39A bytes! :)
- It's not written in Assembly (but a mix of C with assembly).
- It's written in C (not entirely, but a mix of Assembly with C :) )
- It MUST accept data coming from HyperTerminal or any other TTY consoles - yeah... copy and paste the .HEX content!
- It is written entirely in a FREE C Compiler - so by license (GPL), Yablo inherits GPL, so is free!
By now, it runs in PIC18F252... I know it's easy to port to any other PIC18F252 family. :) but the code was tested in PIC18F252. Keep your eyes in the project site, soon or later we'll get other PIC's there too!
Differently of many source codes I've seen, Yablo was written to be easy to understand the internals of a bootloader. IF you read and understood my 3 articles "SDCC: Relocação de Código - PIC", soon or later a project like this was bound to appear. Knowledge is taught/learned only if you want to transform it.
Inside the source code, there's an implementation that I love and the fundamentals of it is the implementation of a Finite Automata, you know? Just to remember, FA is the kind of processing based on inputs and states... the core of compilers, interpreters, pattern recognition engines, etc... Definitely is an elegant solution (maybe not the most notable code saver, but it is simple, data saver and fast).
From theory to practice: Yablo Memory Structure
I won't spend time justifying the "why?". Yablo was designed firstly to fit in only 512bytes (1 page), but the code started growing beyond this limit... naturally :) Then the goal was set to not pass 1024bytes (2pages).
The boot block occupies the memory from 0x000 to 0x3FF. The interrupt vectors are relocated as follows:
0x000 - jump to bootstrap() function, the bootloader function, will branch to 0x400 when it finishes!
0x008 - BRA 0x408
0x018 - BRA 0x418
0x01a..0x3FF bootloader functions
0x400 - call to user main() function
0x408 - user ISR - High vector (relocated)
0x418 - user ISR - Low vector (relocated)
0x4??... 0x7FFF - USER PROGRAM SPACE!
The rest is kept the same:
0x30xxyy - config bits
0xF0xxyy - EEPROM data
To allow, the user program to fit in this memory model, a specifik linker script (LKR) must be used. So in this LKR, this region will be protected. And to the SDCC, the new location of interrupt vectors must be informed using the flags --ivt-loc. Pretty simple! :)
Fuses... Do I need fuses?
Yes and no. Is very important to understand, when your microcontroller carries an embedded code like that, some fuses were programmed. So NO, is not a good idea to change that. For example, if your bootloader is for a crystal based clock source, there's no reason to change it to RC Osc... Avoid such things. Also, in fuses we have the pages locked or not... don't mess the things otherwise your program won't work. And maybe the bootloader can't boot!
Yablo and PIColino
One is born to another. Of course, generic hardwares deserve generic firmwares. And in general terms, its fantastic! You can adapt them easily to your needs.
PIColino (now) is a PIC18F252I/P hardware with RS232. Arduino "quasi" compatible shield connectors. The firmware is now targetted to this processor. I've heard, it runs smoothly in PIC18F2520 (the upgrade of 252). I'm waiting my 2550's to arrive in order to see how does it fit in.
