| View previous topic :: View next topic |
| Author |
Message |
itullis
Joined: 01 Jun 2016
Posts: 2
Location: UK
|
| Combining 3 .hex files into one. |
 Posted: Wed Jun 01, 2016 4:51 pm |
 |
|
I have two independent programs that work on a 18f45k50. I'm using Version 5.059
Program A clock runs quickly to support USB and sets the configuration of my system in EEPROM - about 10 bytes.
Program B clock runs very slowly and spends most of it's time in sleep mode. It depends on the settings provided by program A. Both A & B are about 1/3 the size of available ROM.
There is very little common code between program A & B.
I've written a little demo code - a dispatcher to check the USB Vbus and decide to call A or B. This collection of code produces 3 .hex files.
Is there a simple way to combine these .hex files into one so I can load it on the PIC?
dispatcher
| Code: | #include <18F45K50.h>
#device ADC=10
#ORG 0x1E00, 0x1FFF
#ORG 0x2000, 0x2FFF { }
#ORG 0x3000, 0x3FFF { }
#use delay(internal=31.25kHz)
void main(){
if(input(PIN_A0)){
goto_address(0x2000);
}else{
goto_address(0x3000);
}
} |
Program A
| Code: | #include <18F45K50.h>
#device ADC=10
#ORG 0x1E00, 0x1FFF { }
#ORG 0x2000, 0x2FFF
#ORG 0x3000, 0x3FFF { }
unsigned int8 CONFIG[]={ 0x2b, 0xc8, 0x5e, 0x3c, 0x00, 0xd3, 0xa1, 0x00, 0x0f, 0xc0, 0x0f, 0xe0}; //setup fuses (fast clock)
#use delay(internal=24MHz,USB_FULL,ACT=USB)
#define USB_CABLE_IS_ATTACHED() input(PIN_A0)
#define USB_CONFIG_BUS_POWER 500
#include <usb_cdc.h>
void main(){
char c;
write_configuration_memory(CONFIG,7);
usb_init();
while(TRUE){
if(usb_cdc_kbhit()){
c = usb_cdc_getc();
usb_cdc_putc(c + 1);
}
}
} |
Program B
| Code: | #include <18F45K50.h>
#device ADC=10
#ORG 0x1E00, 0x1FFF { }
#ORG 0x2000, 0x2FFF { }
#ORG 0x3000, 0x3FFF
#use delay(internal=31.25kHz)
unsigned int8 CONFIG[]={ <array of fuses for slow clock> };
void main(){
write_configuration_memory(CONFIG,7);
while(TRUE) {
output_high(PIN_A4);
delay_ms(500);
output_low(PIN_A4);
delay_ms(500);
}
} |
|
|
 |
stinky
Joined: 05 Mar 2012
Posts: 99
Location: Central Illinois
|
|
| Posted: Fri Jun 03, 2016 11:45 am |
|
|
Not sure you can combine HEX files.
Any reason they couldn't just be one program? |
|
|
asmboy
Joined: 20 Nov 2007
Posts: 2128
Location: albany ny
|
|
| Posted: Fri Jun 03, 2016 2:32 pm |
|
|
you are not going to get help merging hex files here.
But i don't see how that would help you.
Why can't you combine your code in one program..
will it not compile when combined for function?
I'm also troubled by the idea you are pursuing.......
REMEMBER that when you change configuration memory -
the pic will wake with those setting after an unplanned
hot or cold restart or WD reset ...
i don't see your startup verifying that the right config is loaded ...
too much info you have up our sleeve fro me to be happy about reliability.
all in all - what you are doing looks risky as all heck from a logical safe-ops startup standpoint. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19541
|
|
| Posted: Fri Jun 03, 2016 2:44 pm |
|
|
Just load them one after the other into MPLAB.
Then export the whole of memory as one file.
This is the easiest way to combine a 'runtime' program into with a bootloader to give a single file, and the same process can be used here.
However you are going to have to add the code to each section to switch the clock speeds. Honestly best to have all use the same clock settings as the fast one, and then switch the clock down for the slow ones. Use a defined macro to give the correct factor for the delay statements (this has been described here).
Seems a complex way to go though. Just write one program and change the clocks. |
|
|
itullis
Joined: 01 Jun 2016
Posts: 2
Location: UK
|
|
| Posted: Fri Jun 03, 2016 5:31 pm |
|
|
I thought that combining hex files was easy because people would want to combine a generic bootloader with their code into one hex file.
Thanks all for your help. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9244
Location: Greensville,Ontario
|
|
| Posted: Fri Jun 03, 2016 7:17 pm |
|
|
re: ...to combine a generic bootloader with their code into one hex file.
That isn't going to work if I'm reading it right...
You FIRST need to program the PIC WITH a 'bootloader' Then you can tell the 'bootloader' to load and program the PIC with the 'main' program.
The 'bootloader' always resides in 'protected' memory.
You can't, for instance, connect a 'blank ' PIC to a PC and download both bootloader and main program, as the PIC has no method of reading and storing the programs.
Jay |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19541
|
|
| Posted: Sat Jun 04, 2016 12:56 am |
|
|
| itullis wrote: | I thought that combining hex files was easy because people would want to combine a generic bootloader with their code into one hex file.
Thanks all for your help. |
In a sense, yes. However, key thing is that both the bootloader, and main program _must_ start using the same clock and fuses. The easiest way to do the combining is to load both into MPLAB, or in some cases the programming software (most have options to not erase on load, so you can load the bootloader, and then load the second program 'over the top'). Then you save the combined code. But for this to work, both programs must have the same clock/fuses. This is why many bootloaders will not change the fuses (since otherwise if you loaded a program that did this, the bootloader would no longer work).
Hence the comment that you really need to re-write the programs to all start using the same fuses. Once you have done this, it is honestly easier just to combine the routines into a single program. |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1354
|
|
| Posted: Sat Jun 04, 2016 9:12 am |
|
|
I think you can also do things like:
| Code: |
#fuses NONE
#use delay(clock=8MHz)
|
In your application to avoid changing your fuses. I *think* (this would need to be verified) by avoiding "internal", "external", "crystal", etc. in your #use delay() statement and just stick to "clock" it won't do behind the scenes fuse changes. Again, that should be verified (Easy to do in the application .LST). So far that has worked for me on mine, but I only have a small subset of chips that I use.
If you are using a different clock than the bootloader, you still have to do all the settings yourself in the code though. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19541
|
|
| Posted: Sat Jun 04, 2016 11:33 am |
|
|
Yes.
However all three code sections must be written to use the fuses they then 'inherit' from the first one loaded. |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1354
|
|
| Posted: Sat Jun 04, 2016 12:34 pm |
|
|
Yep.
I was thinking that would (or at least should be) the bootloader. Normally we base all our apps off of the bootloader fuses and change things at runtime as needed. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19541
|
|
| Posted: Sat Jun 04, 2016 1:26 pm |
|
|
Exactly.
However the point about doing the separate load with the bootloader, is that it is much more difficult to make just one program/file. This does not apply here. It'd be so much easier to just write one program. There is no need for ORG's or jumps here. A single program that selects which part is to be run depending on whatever rule is required, and then switches clock rates etc., as required.
The approach is not a 'sledgehammer nut' solution, instead it is a 'playing chess using oven gloves' solution. Making things miles more complex than needed. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
