Max size for program ?

[goule]

Hello,

What's the maximum size for .hex file to upload into the PIC ?

Thanx

Goule

[TK.]

Not the size of the .hex does matter, but the last memory address which is allocated by the program. For the PIC18f452 it's 0x7bff (because the bootstrap loader begins at 0x7c00). The easiest way to determine the last address before the upload is just to run the hex2syx script, because it shows you the used address ranges. Also MIOS Studio shows the address block addresses during the upload - once you've reached the upper boundary, MIOS will report an error acknowledge.

Best Regards, Thorsten.

[goule]

I had never tried MIOS Studio before. I have to say that this program seems to implement lot of great tools ! I particularly appreciate the external command button, to run the make.bat (well, for C lazy programmers like me  ;D (plus it happens that I like C  :D :-* ;D))

Here is what it says when uploading :

Starting upload of project.hex

Sending block 00003000-000030FF

Received acknowledgement response

Sending block 00003100-000031FF

Received acknowledgement response

Sending block 00003200-000032FF

Received acknowledgement response

(...)

Sending block 00004600-000046FF

Received acknowledgement response

Sending block 00004700-000047FF

Received acknowledgement response

Upload process complete

Will it be possible to store my program on my banksticks to allow a bigger source code ?  :o 8)

Mmm ... what else ...Thanks ?  ;)

Goule

[TK.]

No, it isn't possible to store code in a BankStick, the PIC can only execute from internal Flash.

Currently your program allocates the range from 0x3000-0x47ff, thats ca. 6k

The range from 0x4800-0x7bff is not used yet, means: 13k are free

so, just ca. 33% are allocated yet, I don't think that you will hit the border so fast... and even if this happens, there is always room for optimizations in the code ;-)

Best Regards, Thorsten.

[goule]

Thanks for that information !

Goule

[goule]

Hi,

I start this topic again to ask if anything has changed since new versions of MIOS : does the bootstrap loader still begins at the same address ? Is there other ways of increasing the available size for the program (except from optimizations of course  ;D) ?

Not that I'm already running short of memory but I was planning to eventually write a more complex application and will probably have to deal with this max size parameter ...

Thanks all,

Olivier

[TK.]

According to the ChangeLog http://www.ucapps.de/mios_changelog.html) the upper border is 0x7fff now. By using the most recent SDCC skeleton, you will get all the required changes in the setup files.

Once you hit the border, just use a PIC18F4685 - it provides 96k flash instead of 32k, and it also has more RAM - it would only cost you $10, so no need for wasting time in code optimisations (which wouldn't be possible for MIOS anyhow, only within your own code)

Best Regards, Thorsten.

[goule]

Hi Thorsten,

If my calculations are correct, raising the upper border to 0x7fff only provides one more ko for program (20 ko instead of 19 - I mean for the program only-), which is not such a big upgrade ... but the PIC18F4685 seems to be the real thing when it comes to writing complex applications !  :D

Thanks for that quick answer and for that very good news !  ;D

Olivier

[MTE]

Hi

I reached my limit of my firmware too for the 452 and I want to change to 4685.

Do I need change the mios.h like described in the Wiki for 4620 ?

I use 8 of the PCD8544, must I change some for the soldering of the CAN-Interface like on the SID V2 ?

[stryd_one]

You mean this page?

FIXME This is really outdated!!!

I wrote that before MIOS supported them, it's mostly irrelevent and outdated information now. Only reason I didn't remove it is that I think there is a small amount of helpful info in amongst it

For your C app, you will need to edit the linker script, but MIOS is precompiled for the 4685 now. There is the one catch, that the LCD is automatically configured to use 4-bit mode, but as you are using a custom LCD driver it is not relevant. Others may take note that Wilba's driver will also get around that and use 8bit mode from different pins, if you want.

TK says

Please note, that the PIC18F4685 and PIC18F4682 are not 100% binary compatible to PIC18F452. RAM from 0x60-0x7f is not directly accessible. BANKED accesses have to be used instead. Some bigger applications which allocate this area could crash.

Take note of that last part. I have worked around this by using sections in the linker and pragmas to force things around, but it's messy (I've warned against doing just that in the past). There may be a better way, I'm stuck on something else and haven't really investigated much.

You might consider a 4620 - you still get twice the codespace and over twice the RAM, without the hassles of fudging the RAM :) (and the LCD for other guys that are reading this)

[MTE]

OK Stryd, now I understand why 4685 isnt the best choice for such big firmwares :'(

So now I'll hunt to my cellar, soldering a IIC and try this with an 4620 ;)

But i have 1 more problem, or more a question :

I drive my Traktorizer with the com-port, can 4620 do this without bug ??

[TK.]

I drive my Traktorizer with the com-port, can 4620 do this without bug ??

no, therefore I recommented the PIC18F4685 - for your project, which especially needs flash, not RAM, it's the better choice.

Best Regards, Thorsten.

[stryd_one]

Just to avoid confusion, and for future reference...

TK is quite right - your application in particular does not have a requirement for a large amount of variables, so a PIC with lots of RAM (aka data RAM aka SRAM) is not so important - what you need most, is flash memory (aka code space aka Program Memory) because of the large complex functions.

Here is a table for comparison:

[table]

[tr][td][/td][td]IC[/td][td]4685 [/td][td]4620 [/td][td]452 [/td][/tr]

[tr][td][/td][td]Flash[/td][td]96k [/td][td]64k [/td][td]32k [/td][/tr]

[tr][td][/td][td]SRAM[/td][td]3392b [/td][td]3968b [/td][td]1536b [/td][/tr]

[/table]

As you can see, there is a trade-off here. I recommended the 4620 in your case because it would be more code-compatible in the short term, because the 4685 has that RAM limitation (banked IO only in that range) - But in your case, the most appropriate PIC in the long term, would be the 4685, as it does not require IIC_MIDI, and it has more codespace vs less RAM, which matches the requirements of your application.