Hi guys,
I tried to modifiy PDFUSB bootloader, mostly written in Jal (few asm
statements) by Guru Albert Faber. The idea was to integrate a LED status,
which would blink while bootloader is active (to fully exploit the marvelous
onboard LED on Jaluino v2.0...).
The "problem" is bootloader's size must be < 2048, leaving very few words to
add this. Here's what I could explore, including comparison with jalv24o and
jalv24n. Sample used is 18f4550_usb_bootloader_autostart.jal
$ jallib compile 18f4550_usb_bootloader_autostart.jal
jal 2.4n (compiled Jun 2 2010)
generating p-code
0 errors, 0 warnings
2587 tokens, 179941 chars; 4709 lines; 6 files
generating PIC code pass 1
generating PIC code pass 2
writing result
Code area: 2032 of 32768 used (bytes)
Data area: 37 of 928 used
Software stack available: 891 bytes
Hardware stack depth 3 of 31
OK, 2032 bytes.
Now with jalv24o-beta:
jal 2.4o (compiled Nov 28 2010)
generating p-code
2587 tokens, 179941 chars; 4709 lines; 6 files
generating PIC code pass 1
generating PIC code pass 2
writing result
Code area: 2066 of 32768 used (bytes)
Data area: 39 of 928 used
Software stack available: 889 bytes
Hardware stack depth 3 of 31
0 errors, 0 warnings
No! 2066 > 2048, we can't compile a usable PDFUSB bootloader anymore !
Now, modifying the code, to include LED logic... I added the line, just
after 18f4550 inclusion:
pin_E2 = !pin_E2
and this eats 28 bytes. Do you know another way to do this with lower memory
usage when it's about bit ? asm ? I was using "!!" but that just doesn't do
what I want :)
Trying to save some space (back to original sample source, the following
"case" is found:
case boot_cmd_cmd of:
READ_VERSION:
...
UPDATE_LED:
block
end block
RESET:
block
disable_boot()
-- asm reset
asm goto 0x800
end block
end case
that is, UPDATE_LED is empty. So, when matching UPDATE_LED, execution just
continue *after* "end case", and not inside RESET block, the following
choice (according to the documentation). So, this empty case could be
optimized away, coudn't it ? Because deleting it save 10 bytes !
In the end, for my original purpose, I've removed cases in Jal code that
weren't implemented on hostapp's PC side and code size felt down under 2000
bytes.
Still, how could we track code size objectively ? I mean we have to consider
added features and fixes in metrics. For instance, code may be bigger but
would have less bug or would be more secure...
Cheers,
Seb
--
You received this message because you are subscribed to the Google Groups
"jallib" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/jallib?hl=en.
