View previous topic :: View next topic |
Author |
Message |
bennyboos
Joined: 17 Nov 2005 Posts: 30 Location: Chester UK
|
Start Up code - can it be customised (if so how?) |
Posted: Wed Oct 21, 2009 9:31 am |
|
|
Is it possible to disable or customise the inclusion of automatically generated start-up / initialisation code as is possible under HiTech?
Whilst I appreciate it is useful for getting up & running quickly, I would like to have more control over what is/isn't performed as I am finding that some of the default behaviours are counter to what I want. (It seems wasteful to have the compiler set the chip to a "default" condition only for my code to then modify it again?). |
|
|
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Wed Oct 21, 2009 2:42 pm |
|
|
The CCS compilers don't provide this option. The startup code is however pretty small, and part of it can be defined by preprocessor commands. But basically, the CCS philosophy is to hide hardware details from the user. |
|
|
bennyboos
Joined: 17 Nov 2005 Posts: 30 Location: Chester UK
|
|
Posted: Wed Oct 21, 2009 3:45 pm |
|
|
Thanks for this. I agree that CCS is fantastic for getting things working quickly (which HiTech is not), however I do miss the ability to fine tune pretty much everything.
Could you enlighten me as to what preprocessor commands are available to tweak the start up code (or direct me to it on the web/manual).
Thanks |
|
|
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Wed Oct 21, 2009 4:35 pm |
|
|
I suggest to check what's actually done in the short startup code listed between main() and the first user instructions. Configurable are e.g. features as RAM zeroing, RS232 setup, with PIC24 also stack size and location and additional peripheral initialisation.
I'm not saying, the startup must be hidden as a price of convenience, I'm just stating the fact. However, anything that can be edited by the user will be mixed up by special experts some time and is causing support effort at CCS. |
|
|
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Thu Oct 22, 2009 2:45 am |
|
|
The start up code as I know it is small. Things that make it larger are RAM zeroing (off by default) and initialization of RS232 and USB-ports, but only when you have configured these ports.
Another thing the startup code does is initializing your RAM variables, no C-compiler will allow you to tweak or skip this.
Can you be a little bit more specific on processor type and compiler version number for which you think the startup code is running non-required settings? |
|
|
bennyboos
Joined: 17 Nov 2005 Posts: 30 Location: Chester UK
|
|
Posted: Thu Oct 22, 2009 3:23 am |
|
|
This all came about because I discovered some undesirable behaviour in what turns out to be the automatically generated interrupt handler.
I have been porting some code from HiTech back to CCS and found that shortly after run-time something was corrupting selected areas of RAM which contained my variables.
At the time I had not (yet) defined any interrupts, and therefore assumed that the compiler would either disable all interrupts OR that it would generate a basic handler that would just clear any flags and then return.
As it turns out, the compiler opted to generate a basic handler, but in doing so, something in the handler was overwriting various bytes in my RAM - this being how I discovered the problem in the first place.
CCS are currently investigating this to see whether it is my fault (quite possibly ) or a bug in the compiler.
For the record, this particular device was an 18F8723 & compiler version 4.099.
To be concise then I suppose my question is more related to the automatically generated ISR handler rather than the start up code.
(Also I'm pretty confident that under HiTech you can deliberately break the ANSI standard and omit the initialisation of any variables which are not auto objects - not that I want to do this mind you). |
|
|
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Thu Oct 22, 2009 8:58 am |
|
|
After a hardware reset, interrupts are globally disabled (respective INTCON bits are intialized to zero). The problem can only occur after a "soft reset" (jump to start address), e.g. from a bootloader, or with a unsuitable initialization order, I think. |
|
|
|