Skip to main content ↑ ↓
Topic: Main too big: fixing the translation file (Read 2849 times) previous topic - next topic

Main too big: fixing the translation file

The PIC addition to the translation file is also included in main. This makes main too big. I think normally nobody would notice, but the guys playing with MPLABX are running into this issue. Should we make a main and add-on translation file? I don;t know a good way to deal with this.
Got a question? Please ask in the forum for the fastest answers.

Re: Main too big: fixing the translation file

Reply #1 –
Most of the textes are 'local' to the protocol in which they are used, the next thing would be to have a text per protocol.

The textfile is kinda diveded per protocol (stress on kinda ;))

Re: Main too big: fixing the translation file

Reply #2 –
Hi Ian, Sjaak,

Actually now that we use the "optimize for space" gcc flag, we can compile the MAIN too.
See r554
Enabling all modules of MAIN & ADDONS even fit in a single firmware... (except I2C_HW which fails compiling, which is why it's commented out both in MAIN & ADDONS I guess)

Re: Main too big: fixing the translation file

Reply #3 –
have you tried running the firmware? The last time i tried to use any optimizing flag, the firmware didn't  work (it did compile ok)

The reason that i2c hw is commented out is because of a series of pic with broken i2c hardware

Edit: typo

Re: Main too big: fixing the translation file

Reply #4 –
Yes I tried, selftest & UART sniffing work fine, for the rest I cannot tell.

HiZ>i
Bus Pirate v3b
Firmware v5.9RC2 (r542)  Bootloader v4.3
DEVID:0x0447 REVID:0x3043 (24FJ64GA002 B5)
http://dangerousprototypes.com
HiZ>m
1. HiZ
2. 1-WIRE
3. UART
4. I2C
5. SPI
6. 2WIRE
7. 3WIRE
8. KEYB
9. LCD
10. PIC
11. DIO
x. exit(without change)

(1)>no mode change

It might be that some timing critical code is affected but in that case it would be better to spot it and protect it with pragma rather than banning optimization over the whole firmware.
Current fw r554 with all but I2C_HW: 181416 bytes
You can test it if you want: http://www.yobi.be/files/BPv3-Firmware-r544.hex

Re: Main too big: fixing the translation file

Reply #5 –
It would be fantastic if we could optimize it a bit. Maybe it is a compiler difference?

Feel free to upload compiles to the nightly folder. It might be good to note which are MPLABX until we all make the switch.
Got a question? Please ask in the forum for the fastest answers.

Re: Main too big: fixing the translation file

Reply #7 –
[quote author="doegox"]
It might be that some timing critical code is affected but in that case it would be better to spot it and protect it with pragma rather than banning optimization over the whole firmware.
[/quote]

Not only timecritical things are affected with optimizing. Access to global vars and hardware registers are also a pain in the arse. When I redesigned the buspirate backbone I encountered lots of things that were broken with optimize on. Most of it was regarding variable that were cached, but changed from 'outside'

[quote author="Sjaak"]
have you tried running the firmware? The last time i tried to use any optimizing flag, the firmware did work (it did compile ok)

The reason that i2c hw is commented out is because of a series of pic with broken i2c hardware
[/quote]

It should be the firmware didn´t work. It could be a matter of the wrong platform includes (hardware registers not decalred as volatile for example), but accessing the hardware did not work as exected. Perhaps the MPLABX has a different set..

Will try it.

Edit: isn't optimizing disabled after the MPLAB trial is over? With the regular MPLAB it is disabled after the trial is over. I'm not near my development PC atm so I can't check.

Re: Main too big: fixing the translation file

Reply #8 –
Just the highest level of optimization.
Got a question? Please ask in the forum for the fastest answers.