 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
 Posted: Sun Jun 12, 2016 12:53 am |
 |
|
Yes.
Things like #pin select, are specific to the program, not 'inherited'. Same applies to clock rates, serial port setup etc...
The 'application program' has to be complete 'in itself'.
I actually use a combination of Temtronic's fuse approach when writing for a bootloader.
I put all my fuses into a separate file. 'applicationname_fuses.h', for whatever the 'applicationname' is. This is #included by both the bootloader, and the application.
Then this contains:
| Code: |
#ifdef _bootloader
#fuses //and whatever the fuses you want are
#else
#fuses NONE
#endif
#clock(//etc).
|
I always do the #define _bootloader, right at the top of my bootloader code, then include the processor file, and the fuses file.
This way I 'know' what fuses apply to both programs, but they are automatically not included in the actual application. I include the clock, since this is fuse 'dependant', and again it ensures both the application, and it's bootloader are 'singing from the same hymn sheet'.
Glad you have moved forwards a lot.  |
|
 |
soonc
Joined: 03 Dec 2013
Posts: 215
|
| Great tip |
| Posted: Sun Jun 12, 2016 8:42 pm |
|
|
| Ttelmah wrote: | Yes.
Things like #pin select, are specific to the program, not 'inherited'. Same applies to clock rates, serial port setup etc...
The 'application program' has to be complete 'in itself'.
I actually use a combination of Temtronic's fuse approach when writing for a bootloader.
I put all my fuses into a separate file. 'applicationname_fuses.h', for whatever the 'applicationname' is. This is #included by both the bootloader, and the application.
Then this contains:
| Code: |
#ifdef _bootloader
#fuses //and whatever the fuses you want are
#else
#fuses NONE
#endif
#clock(//etc).
|
I always do the #define _bootloader, right at the top of my bootloader code, then include the processor file, and the fuses file.
This way I 'know' what fuses apply to both programs, but they are automatically not included in the actual application. I include the clock, since this is fuse 'dependant', and again it ensures both the application, and it's bootloader are 'singing from the same hymn sheet'.
Glad you have moved forwards a lot. |
While in the frustration of fighting "stuff" these finer details tend to get put off... but of course they could prevent the frustration !
Now that this product is nearing its end, I think I would not use the PIC24 as the serial seems to be sluggish and I really can't run this at 230400 Baud like I can the PIC18F67K22.
No doubt there are "ways around" this issue, but 115,200 Baud will be plenty fast enough for the first release.
Thanks for your support and all the helpful people on this forum. It has been most helpful. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Mon Jun 13, 2016 12:40 am |
|
|
The PIC24/30 serials, can go faster than the PIC18.
However a huge amount depends on the 'nature' of your serial data, and the handler.
What you should do, is if (for instance), you are using code similar to ex_sisr, then modify the serial receive data routine like:
| Code: |
//assuming UART1 stream is named 'SERIAL1'
#int_rda
void serial_isr(void)
{
int t;
do
{
buffer[next_in]=fgetc(SERIAL1);
t=next_in;
if (++next_in==BUFFER_SIZE)
next_in=0;
if(next_in==next_out)
next_in=t; // Buffer full !!
} while (kbhit(SERIAL1));
}
|
The point is that because there is a much larger hardware buffer, this allows more than one character to be transferred 'at a time' if they are available.
If your serial data is 'block based', rather than character based, you can get even more sneaky, and use the DMA, to transfer four or even eight characters at a time. Downside of this is it doesn't give immediate response for a single character. |
|
|
soonc
Joined: 03 Dec 2013
Posts: 215
|
|
| Posted: Mon Jun 13, 2016 9:55 pm |
|
|
| Ttelmah wrote: | The PIC24/30 serials, can go faster than the PIC18.
However a huge amount depends on the 'nature' of your serial data, and the handler.
What you should do, is if (for instance), you are using code similar to ex_sisr, then modify the serial receive data routine like:
| Code: |
//assuming UART1 stream is named 'SERIAL1'
#int_rda
void serial_isr(void)
{
int t;
do
{
buffer[next_in]=fgetc(SERIAL1);
t=next_in;
if (++next_in==BUFFER_SIZE)
next_in=0;
if(next_in==next_out)
next_in=t; // Buffer full !!
} while (kbhit(SERIAL1));
}
|
The point is that because there is a much larger hardware buffer, this allows more than one character to be transferred 'at a time' if they are available.
If your serial data is 'block based', rather than character based, you can get even more sneaky, and use the DMA, to transfer four or even eight characters at a time. Downside of this is it doesn't give immediate response for a single character. |
Yes I noticed the UART has a larger FIFO, but never really understood how to use it.
This looks like something I may be able to use.
The DMA looks too fiffy for me, and I do have a few transactions that only respond with 1 char.
The other code looks like something may try for my next release.
I'll copy/past it into my tips file.
Thanks again. |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1315
|
|
| Posted: Tue Jun 14, 2016 5:10 am |
|
|
Just keep in mind that if the PIC24 code seems sluggish, then it is usually something in a persons code causing it. As Ttelmah pointed out, they have different hardware, so it isn't always a 1:1 code copy between chips.
I've been using PIC24's for a long time and their UARTS are spot on in timing (barring any particular chip errata, but PIC18's also have this risk) and code execution time is great. They run twice as fast as a PIC18 on the same crystal (in terms of code instruction time) and they can use higher baud rates than the PIC18 on the same crystal.
Not that PIC18's are bad by any stretch. Each has their uses. |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 537
Location: Des Moines, Iowa, USA
|
|
| Posted: Mon Jan 06, 2020 1:23 pm |
|
|
Should the .hex file contain anything at the FUSES location (end of flash) when you use #FUSES none?
I'm trying to track down where these settings are coming from. If it's only possible to set the using #FUSES, I will focus there.
:020000040005F5
:1057F0000000FF00FFFFFF00FB87FF005F77FF0057
:00000001FF
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ? |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1315
|
|
| Posted: Mon Jan 06, 2020 3:40 pm |
|
|
| allenhuffman wrote: | Should the .hex file contain anything at the FUSES location (end of flash) when you use #FUSES none?
I'm trying to track down where these settings are coming from. If it's only possible to set the using #FUSES, I will focus there.
:020000040005F5
:1057F0000000FF00FFFFFF00FB87FF005F77FF0057
:00000001FF |
Most of the time your clock statement is the culprit. When you use
| Code: |
#use delay(clock=8000000)
|
the compiler doesn't change any fuses. If you use internal, crystal, external, or other options, it can change the fuses.
I have also seen setup_oscillator() changes fuses, but not when NONE has been specified. |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 537
Location: Des Moines, Iowa, USA
|
|
| Posted: Mon Jan 06, 2020 3:43 pm |
|
|
| jeremiah wrote: | Most of the time your clock statement is the culprit. when you use
| Code: |
#use delay(clock=8000000)
|
the compiler doesn't change any fuses. If you use internal, crystal, external, or other options, it can change the fuses.
I have also seen setup_oscillator() changes fuses, but not when NONE has been specified. |
Ah, that would make sense. I need to neuter out anything else that sets those flags. I just need to find a list of what all does it. Thanks!
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ? |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 537
Location: Des Moines, Iowa, USA
|
|
| Posted: Tue Jan 07, 2020 9:33 am |
|
|
I conditionalized all my #use/#fuse statements so they only get included by the bootloader. I hit a snag when I wanted to use printf() in the application.
Does anyone know if there is a trick that will allow me to create printf-compatible code but not put the fuse/use settings in the .hex file? Those will be set by my bootloader code. For production, it will be disabled in both bootloader and app, but for testing I'll have it enabled.
I'm hoping I can have this set in the bootloader code, and just have some way to let the app code compile to use it (obviously, not working if I turned it off in bootloader and still had that app code in).
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ? |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 537
Location: Des Moines, Iowa, USA
|
|
| Posted: Tue Jan 07, 2020 10:27 am |
|
|
Actually, even with my printf disabled, I still end up with things at that end memory range. What are they called? I need to poke around in the manual and see what else adds stuff there in my C code.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ? |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1630
Location: Perth, Australia
|
|
| Posted: Tue Jan 07, 2020 11:51 am |
|
|
| allenhuffman wrote: | | Actually, even with my printf disabled, I still end up with things at that end memory range. What are they called? I need to poke around in the manual and see what else adds stuff there in my C code. |
Hi Allen,
Some bootloader remap interrupt vectors. I do not like this approach. It adds unnecessary latency to the interrupt processing and binds the application to the bootloader. If you are using this type of bootloader then ignore the rest of this post.
I think you are making this much harder than it needs to be. Personally I believe bootloaders and applications should be ships in the night. The application should never need to know about the bootloader with the exception of reserving the memory space consumed by the bootloader. The bootlader however does need to know the config fuse settings which are hardware platform specific.
With the application and bootloader fully decoupled, you don't care the what tool-chain is used to build the bootloader nor do you care if the bootloader is a binary file, a hex file, or whatever.
The steps I would recommend for producing a golden image are:
1. develop your initial application reserving space for the bootloader.
2. Fully test and debug your initial application application
3. Copy the config fuses from the resultant hex file to notepad. These config fuse settings are located at the very end of the hex file. (we use this later)
4. Disable any code protection bits in the applications. config fuses, recompile the application and copy the new config fuse settings from the hex file to notepad
5. Copy the application fuses from the modified application source file to the bootloader.
6. Compile and install the bootloader.
7. Bootload the modified application.
8. Read the PICs memory into MPLAB
at this point you have a combined image but with code protection disabled. You can either set the code protection bits in MPLAB to reenable code protection or wait a couple of steps
9. Use MPLAB to export the program memory to a hex file[/list]
If you modified the config settings in MPLAB at step 8 you are now finished. If not, open the resultant hex file, go to the end of the hex file and replace the config fuses hex records with the original ones your stored at step 3
You now have a golden image. It may sound like a lot of steps but the whole process takes only 10 minutes once you have done your first one.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 537
Location: Des Moines, Iowa, USA
|
|
| Posted: Tue Jan 07, 2020 11:56 am |
|
|
| asmallri wrote: |
9. Use MPLAB to export the program memory to a hex file[/list]
|
MPLAB sure comes up alot here. Is that a CCS Product too? I use the CCS tools.
In my case, all I want to do is do a build that doesn't put the fuse settings in the app, since they will be in the booter.
I can manually do this, of course, by merging and editing files, then I use a program I wrote to fix the CCS-created CRC comment line, but I'm trying to find a way to do it via the project file.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ? |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 537
Location: Des Moines, Iowa, USA
|
|
| Posted: Tue Jan 07, 2020 12:03 pm |
|
|
I also looked at trying to load both hex files into the CCS LOAD utility (useful if this can be done from command line, not if it can only be done from the GUI). I did not find an obvious way to do anything but Open, though I am told it's in there.
There's still a bug in the current version that prevents writing without erasing the entire PIC first, so I can't get them both into flash at the same time (though I did by flashing my booter, then using it to load my app, then reading that back). Works great, but time consuming and isn't easy to automate.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ? |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1630
Location: Perth, Australia
|
|
| Posted: Tue Jan 07, 2020 12:42 pm |
|
|
| allenhuffman wrote: | | asmallri wrote: |
9. Use MPLAB to export the program memory to a hex file[/list]
|
MPLAB sure comes up alot here. Is that a CCS Product too? |
No, this is a Microchip Integrated Development Environment. It is a free tool. CCS compilers can be easily integrated into the MPLAB environment and I do all my CCS code development and debugging in the MPLAB environment. For me, the advantage is I can use all the Microchip hardware debuggers, programmers and specifically MPLAB ICE.
You can use MPLAB to merge, edit hex files, disassemble, export and program the target.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9097
Location: Greensville,Ontario
|
|
| Posted: Tue Jan 07, 2020 1:17 pm |
|
|
As Andrew said, MPLAB is a free Mcrochip product. I've used it since the mid80s when PCM vas V2.534..... Currently I have MPLAB V8.92 and it's my interface between PCM and PICs via a PICKit3 programmer. When using t be sure to change the build config to RELEASE before compiling and burning a PIC. It defaults to 'DEBUG' but that can be changed to 'RELEASE'.
Since I debug in the real world, I've never use the 'debug' mode. |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
