Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

Forums:

im guessing this is a very bad thing to do,
all im trying to do is find out the length of a char*
and i know that it will be null terminated.

int StringLength = 0;
while(string[StringLength] != '\0')
{
StringLength++;
}

what other approach should be taken, since i realise if this doesnt complete before whatchdog comes about the phone will die....

i have seen the ISHELL_busy function, but am not quite sure how to implement something with a lot of processing needed

Quote:Originally posted by chop
im guessing this is a very bad thing to do,
all im trying to do is find out the length of a char*
and i know that it will be null terminated.
int StringLength = 0;
while(string[StringLength] != '\0')
{
StringLength++;
}
In the case of the above, one simple thing to do is to have a
MAX_STRING size that string[] should never exceed.
In that case if you exceed that length in your search,
then pop out of the loop and DBGPRINTF an error.
For other long processing, the best thing to do is to break it up
into discreet chunks that take only a small amount of processing time. There are several threads on this.

Quote:Originally posted by chop
im guessing this is a very bad thing to do,
all im trying to do is find out the length of a char*
and i know that it will be null terminated.
int StringLength = 0;
while(string[StringLength] != '\0')
{
StringLength++;
}
In the case of the above, one simple thing to do is to have a
MAX_STRING size that string[] should never exceed.
In that case if you exceed that length in your search,
then pop out of the loop and DBGPRINTF an error.
For other long processing, the best thing to do is to break it up
into discreet chunks that take only a small amount of processing time. There are several threads on this.

thats the problem, i havent found any useful threads on this,
i was told about radub's writings on developer.com/brew
but still could not get my head around breaking up a funciton into smaller tasks
does this mean i will have 100+ callback functions??
where are these articles?
how do u use the busy functions and ones like it,
and in what order??

thats the problem, i havent found any useful threads on this,
i was told about radub's writings on developer.com/brew
but still could not get my head around breaking up a funciton into smaller tasks
does this mean i will have 100+ callback functions??
where are these articles?
how do u use the busy functions and ones like it,
and in what order??

not too complicated. something like the following psuedocode should work:
stringlen(pApp * app)
{
int i, found=0;
for (i = app->startFrom; i < app->startFrom+100; i++)
{
if (app->string[i] == '\0')
{
found = 1;
break;
}
}
if (found)
{
// finished.. call other code
// or send/post yourself an event
return;
}
else
{
// didnt find it, so call loop again.
app->startFrom = i;
ishell_settimer(pShell, 1, stringlen, app);
}

-Tyndal

not too complicated. something like the following psuedocode should work:
stringlen(pApp * app)
{
int i, found=0;
for (i = app->startFrom; i < app->startFrom+100; i++)
{
if (app->string[i] == '\0')
{
found = 1;
break;
}
}
if (found)
{
// finished.. call other code
// or send/post yourself an event
return;
}
else
{
// didnt find it, so call loop again.
app->startFrom = i;
ishell_settimer(pShell, 1, stringlen, app);
}

-Tyndal

ok thanks,
but what is a good guess at knowing what fucntions might take to olong and i should break it up
also im guessing some phones will be able to process more before the whatchdog kicks in ,
and breaking the functions up into too many pieces will waste time.....
is there any information anywhere on how much processing can be done before the whatchdog kicks in for a variety of phones???
just a note......
i heard it would
for (i = app->startFrom;!found && i < app->startFrom+100; i++)
probably be better to do
to get rid of the break statement;

ok thanks,
but what is a good guess at knowing what fucntions might take to olong and i should break it up
also im guessing some phones will be able to process more before the whatchdog kicks in ,
and breaking the functions up into too many pieces will waste time.....
is there any information anywhere on how much processing can be done before the whatchdog kicks in for a variety of phones???
just a note......
i heard it would
for (i = app->startFrom;!found && i < app->startFrom+100; i++)
probably be better to do
to get rid of the break statement;

i notice that youve done this with a timer
where/why/how would you use
ISHELL_resume
and ISHELL_busy
??

i notice that youve done this with a timer
where/why/how would you use
ISHELL_resume
and ISHELL_busy
??

i dont think you need ishell_busy....
there is example code in the api doc for ishell_resume()
-Tyndal

i dont think you need ishell_busy....
there is example code in the api doc for ishell_resume()
-Tyndal

so the timer is used to make sure its stopping every 50ms or something, but what is there to say that it wouldnt be running when the whatchdog comes aout?

so the timer is used to make sure its stopping every 50ms or something, but what is there to say that it wouldnt be running when the whatchdog comes aout?

about

about

?????
the watchdog just makes sure that your process isnt stuck in a loop.. so if you function is looping for over.. say 2 seconds.. the watchdog will notice this and stop the app.. in order to avoid the watchdog, you need to return from your function within 2 seconds.. (im not sure what the watchdog time is, so im using 2 sec as an example)..
in other words.. the watchdog starts watching when your function starts, and stops watching when you return.
if you call "child" functions, they will still be counted as part of the main fxn. for ex:
myfxn()
{
doStuff()
doMoreStuff()
return;

doStuff()
{
// something
return;

doMoreStuff()
{
// something else
return;

the watchdog wont reset until the return of myfxn()

?????
the watchdog just makes sure that your process isnt stuck in a loop.. so if you function is looping for over.. say 2 seconds.. the watchdog will notice this and stop the app.. in order to avoid the watchdog, you need to return from your function within 2 seconds.. (im not sure what the watchdog time is, so im using 2 sec as an example)..
in other words.. the watchdog starts watching when your function starts, and stops watching when you return.
if you call "child" functions, they will still be counted as part of the main fxn. for ex:
myfxn()
{
doStuff()
doMoreStuff()
return;

doStuff()
{
// something
return;

doMoreStuff()
{
// something else
return;

the watchdog wont reset until the return of myfxn()

ok, thats a bit more explanitory,
does this apply for handle_event....im guessing it does.
and as before, is there no place to find out on how much can be done on specific handsets?
and if not is there no example of what would be too much and what wouldnt be too much to do before giving back control??
e.g ive got a function that initializes variables for say 50 lines
am i going to have to break this up into
function()
{
//initilize 15(for example)
call timer1(blah,1,blah,blah)l

timer1()
{
//initialze another 15
call timer2(blah....etc)
{
timer2
{
//intiialzie another 15
etc
etc
and so forth??????

ok, thats a bit more explanitory,
does this apply for handle_event....im guessing it does.
and as before, is there no place to find out on how much can be done on specific handsets?
and if not is there no example of what would be too much and what wouldnt be too much to do before giving back control??
e.g ive got a function that initializes variables for say 50 lines
am i going to have to break this up into
function()
{
//initilize 15(for example)
call timer1(blah,1,blah,blah)l

timer1()
{
//initialze another 15
call timer2(blah....etc)
{
timer2
{
//intiialzie another 15
etc
etc
and so forth??????

also sorry about not having the code seperator line's
how do u make em?
-------------------------------------------------------------------------
//code
-------------------------------------------------------------------------

also sorry about not having the code seperator line's
how do u make em?
-------------------------------------------------------------------------
//code
-------------------------------------------------------------------------

i think it is a couple of seconds.. but you should give some visual feeback to the user to show that your app hasnt hung.. so id suggest a making your loops last < 1sec, and do some visual update to let the user know its still working (like an hourglass)..
to show code use tags like this:
[mycode]
func(x)
[/mycode]
when posting.. but replace the word "mycode" with the word "code" ..

i think it is a couple of seconds.. but you should give some visual feeback to the user to show that your app hasnt hung.. so id suggest a making your loops last < 1sec, and do some visual update to let the user know its still working (like an hourglass)..
to show code use tags like this:
[mycode]
func(x)
[/mycode]
when posting.. but replace the word "mycode" with the word "code" ..

yeah, this applys to the event handler too.
your initializers shouldnt be taking up that much cpu..
what you most need to look out for is file i/o routines, and lots of heavy calculation.

yeah, this applys to the event handler too.
your initializers shouldnt be taking up that much cpu..
what you most need to look out for is file i/o routines, and lots of heavy calculation.