On Sat, 28 Nov 2009, Philipp Klaus Krause wrote:
> Gordon Henderson schrieb:
>> I'm probably missing something obvious, but is there an easy way to find
>> out how much flash and ram my project is using? (PIC18 target).
>
> I don't know about the PIC18, but on the Z80 finding the amount of RAM
> used should be eqivalent to the halting problem and the .map file is
> quite OK at telling the amount of ROM used (though according to your
> post it seems different on the PIC18).
I think the information is there - it's just not very human readable in
4116 lines of map file! (Which doesn't get written when the linker stalls
with that error I had earlier)
so the map file starts off like:
gplink-0.13.7 beta
Map File - Created 11-28-2009 00:00:48
Section Info
Section Type Address Location Size(Bytes)
--------- --------- --------- --------- ---------
S_crt0i___entry code 00000000 program 0x000004
S_logRom__i2cAck code 0x000004 program 0x000004
S_interrupts____ivt_high_int code 0x000008 program 0x000004
.code code 0x00000c program 0x002014
S_oledWrite__oLedPutchar code 0x002020 program 0x000a08
etc.
then it changes to udata with similar stuff, then ...
Program Memory Usage
Start End
--------- ---------
0x016f54 0x016fa1
00000000 0x000003
0x015802 0x015899
0x017662 0x017679
0x011124 0x01129d
0x300000 0x30000d
0x015086 0x01512d
etc...
that's a big block - I guess I could read that in, parse it and work out
how much code is being used... At the end of that list it says:
48056 program addresses used
Now I'm pretty sure I'm using more thant that - but not double (if that
was words rather than bytes!) because the bootloader I'm using is getting
up to 95% (then again, I don't know if that's accurate as it's a bit of
Java to interact with the bootloader in the PIC!)
I'm also a bit confused by compiler comments which it places at the end of
each file - for example, I have one file which includes a set of hex
values - looks like this:
code
_font:
DB 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x07, 0xe0, 0x0f, 0xf0,
0x18, 0x18
DB 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18,
0x18, 0x18
DB 0x18, 0xd8, 0x19, 0x98, 0x1b, 0x18, 0x0f, 0xf0, 0x07, 0xe0,
0x03, 0x00
etc.
etc. in the .asm file. I know there are exactly 5120 bytes in there, but
at the end of that file is:
; Statistics:
; code size: 856 (0x0358) bytes ( 0.65%)
; 428 (0x01ac) words
; udata size: 0 (0x0000) bytes ( 0.00%)
; access size: 0 (0x0000) bytes
So someones out by a few bytes...
I'm sure the information is all there - somewhere, it's just a matter of
finding it :-)
I'm not really too concerned about it though - it would be nice to know,
but it's not going to stop anything. I just got used to using 'size' for a
very long time!
Thanks,
Gordon
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Sdcc-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sdcc-user
