CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

PIC24EP Out of rom question [CLOSED]
Goto page Previous  1, 2
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Mon Oct 25, 2021 6:00 am     Reply with quote

You don't need to worry about the extra parameters. These only apply if
you are using the RECURSIVE option to support recursive functions.
What happens then is you can then specify how scratch registers are
allocated. Unless you are setting this, don't worry about the extra options.
benoitstjean



Joined: 30 Oct 2007
Posts: 542
Location: Ottawa, Ontario, Canada

View user's profile Send private message

PostPosted: Mon Oct 25, 2021 6:06 am     Reply with quote

I guess I had a typo or something because now it appears to compile but I still have the out of rom error. Here's the original code:


.h file:

bool My_Function( param1, param2 );

.c file:

bool My_Function( param1, param2 )
{
// My code for this function
return( bool_value );
}


This is what I changed:

.h file:

#separate
bool My_Function( param1, param2 );

.c file:
#separate
bool My_Function( param1, param2 )
{
// My code for this function
return( bool_value );
}


Then in the rest of the code, where I call the actual function, I just call its name:

// some code...
retval = My_Function( param1, param 2 );
// some more code...

I still get the error...


[EDIT] Did a bit of clean-up in the code so that I could at least compile it and I hit 93%. Then I added #separate directives and it still compiles to 93%....
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Mon Oct 25, 2021 7:08 am     Reply with quote

#separate, won't change the size. What it does is allow the pieces to be split,
so when you are at a size like this, the bits can be fitted into the available
blocks.

The memory is like pages. If you have a singe entity that is larger than
a page, it can't be fitted in, even if there is space in other pages. Using
the #separate, is like using paragraphs. Split the entity into four paragraphs,
and one of them can potentially be moved into another page. Suddenly things
fit.
In your original post, there was some (not a lot) of spare space in another
page, but you had a single program lump than was larger than the biggest
available space.
benoitstjean



Joined: 30 Oct 2007
Posts: 542
Location: Ottawa, Ontario, Canada

View user's profile Send private message

PostPosted: Mon Oct 25, 2021 7:14 am     Reply with quote

Ah ok, I see. So then this means I could compile at the moment at hit 93% but since things got separated, I sort of have "more" space since the code has now been properly split... at bit like doing a defrag on a drive...?
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Mon Oct 25, 2021 7:33 am     Reply with quote

It is perhaps also worth asking if you have tried increasing the #opt level?.
Some time ago, in the readme for the compiler, CCS referred to two higher
optimisation levels being offered. At the time on some of the PIC18's
these did offer some significant savings. #OPT 10 and #OPT 11. Now
the manual still only refers to 0-9, and I haven't tried these recently,
but a large input switch is exactly the sort of thing these affected.
Might be worth seeing if these do have any effect,

It is worth saying that I'd probably be doing this by using a table rather
than a switch statement. On the PIC16/18, a large switch, provided it does
not have a default, will code as a jump table. On the PIC24/30/33, these
always code as separate tests, so quite inefficient code, and increasingly
bulky. Instead a table walking table comparison, is likely to be much more
efficient.
benoitstjean



Joined: 30 Oct 2007
Posts: 542
Location: Ottawa, Ontario, Canada

View user's profile Send private message

PostPosted: Mon Oct 25, 2021 7:53 am     Reply with quote

Haven't tried the #OPT option...

And as for the large "switch" statement, I can't really do this as the returned data from the modem is plain readable text... so unless there's a better way to do this or some programming trick I am not aware of (very possible!)... At the moment, I test each message against the real message like this:

if( strncmp( BaseMessage, "+CPING", 6 ) == 0 )
{
// do something;
// return;
}

if( strncmp( BaseMessage, "+CFTPSSTART", 11 ) == 0 )
{
// do something;
// return;
}

if( strncmp( BaseMessage, "+NETOPEN", 11 ) == 0 )
{
// do something;
// return;
}

if( strncmp( BaseMessage, "RING", 11 ) == 0 )
{
// do something;
// return;
}

if( strncmp( BaseMessage, "MISSED_CALL", 11 ) == 0 )
{
// do something;
// return;
}


I mean, this has been working for years and as soon as the proper message is found, it runs the code inside that 'if' then exits the function immediately and doesn't need to check the remaining messages.

I guess what I could do though is if the string returned is 'OK', since many AT commands return OK, I could take this portion and put it in another function.

When an AT command whose only response is 'OK', just before calling the command, a flag is set then when 'OK' is retuned, flags are checked one by one to find which one was set then the code in that 'if' statement is processed and the function is exited immediately.
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Mon Oct 25, 2021 8:13 am     Reply with quote

Imaging you took all your messages and stored them in a string array in
alphabetical order.
Then when a character or message arrives, you just walk down the first
characters of the table lines till you find a match. If you get past the letter
you have received, abort.
Now when you receive or look at the second character, you just look at the
second character in this line. If it matches wait for the next character. If not
try the next line. Again if there is a match wait for the next character.
Again if you get to a character that is higher than your new character you
abort.
For each character you only have to do as many character tests as there
are lines with the same characters to this point. Vastly more efficient than
trying every possibility. When you reach the end of string character in the
line, you have a full match. Now, since you now have a line number in the
array, you can have an array of functions, and just call the one for this line.
This can be so fast that you can do it on the fly as the characters are
received. The code itself is tiny, and all you have stored is the array of text,
and the array of functions.
Your current approach is just about the most inefficient way of actually
coding this, that it is possible to do. Both in terms of processor operations,
and size.
benoitstjean



Joined: 30 Oct 2007
Posts: 542
Location: Ottawa, Ontario, Canada

View user's profile Send private message

PostPosted: Mon Oct 25, 2021 8:30 am     Reply with quote

haha, yikes. Yes, I've always found it was not very efficient but it always worked-out for me. I guess at some point I will have to do a good analysis of the code and see how I can optimize it.

Thanks for your input, it's always very appreciated.

Cheers.

Ben
newguy



Joined: 24 Jun 2004
Posts: 1899

View user's profile Send private message

PostPosted: Mon Oct 25, 2021 9:44 am     Reply with quote

I've found that the compiler almost always "inlines" things like a printf or, I suspect in your case, strncmp() too.

To save code space, try making your own strncmp(), my_strncmp(), and within in place the strncmp() function. Every place you presently use strncmp(), switch to my_strncmp(). That will save a lot of code space.
benoitstjean



Joined: 30 Oct 2007
Posts: 542
Location: Ottawa, Ontario, Canada

View user's profile Send private message

PostPosted: Mon Oct 25, 2021 9:58 am     Reply with quote

Ok, thanks newguy (who's been around for a long time! :) )
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
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