First off, I thank you all for the help.
It is true that b was returning 0. Tied quite a few variation and wound up in the end scanning for both chars.
It was actually not that bad or time consuming because this was a video stream, so after i got a chunk of data from the net i just read through that short buffer length of 1024 bytes to find them.
Once i finally got my image data from the IP cam, i then converted the .jpeg data to RGB. It was this that killed it. Even though i got the image in a fraction of a second from the camera over the net, it took the like 2-3 minutes to convert a 320x240 image. Had no idea it would have taken that long ;(
Having Issue with strstr, need some help.
- Chris Ruff
- Posts: 222
- Joined: Thu Apr 24, 2008 4:09 pm
- Location: topsail island, nc
- Contact:
Re: Having Issue with strstr, need some help.
Ah yes...
I remember back when I was with Telephoto in San Diego
We had a copressor board with a DSP onboard that did the .JPG processing....
Believe me, conversion from JPG to RGB is MUCH faster than going the other way. And you have found how computationally intensive unpacking an image is.
Chris
I remember back when I was with Telephoto in San Diego
We had a copressor board with a DSP onboard that did the .JPG processing....
Believe me, conversion from JPG to RGB is MUCH faster than going the other way. And you have found how computationally intensive unpacking an image is.
Chris
Real Programmers don't comment their code. If it was hard to write, it should be hard to understand
Re: Having Issue with strstr, need some help.
I sure did, had no idea how much uP speed it takes to some seeming simple on such a small image.
Re: Having Issue with strstr, need some help.
I didn't check my code by compiling it.
it should be
or
this is how to define char arrays without null-termination.
You don't really need to use TOKEN_SIZE when you declare your startdata and enddata arrays, I just put that there to let you know what TOKEN_SIZE was intended to mean. It specifies the length of the token that is being searched for.
Also, no-one spotted the deliberate mistake.
should be
or
quicker version
this code has no concerns with the difference in size between pointers and integers, because it doesn't do any pointer maths.
this code also makes no assumptions about the contents of the startdata and enddata arrays.
given that each of these starts with 0xFF, there is a more efficient way of doing this using memchr, by finding the 0xFF and then looking at the next char to see if it is 0xD8 or 0xD9.
it should be
Code: Select all
char startdata[TOKEN_SIZE] = {'\xff','\xd8'};
char enddata[TOKEN_SIZE] = {'\xff','\xd9'};
Code: Select all
char startdata[TOKEN_SIZE] = {0xFF,0xD8};
char enddata[TOKEN_SIZE] = {0xFF,0xD9};
You don't really need to use TOKEN_SIZE when you declare your startdata and enddata arrays, I just put that there to let you know what TOKEN_SIZE was intended to mean. It specifies the length of the token that is being searched for.
Also, no-one spotted the deliberate mistake.

Code: Select all
for ( i=0; i< (sizeof(Imagee) - TOKEN_SIZE + 1); i++ )
Code: Select all
for ( i=0; i< (sizeof(Imagee) - TOKEN_SIZE); i++ )
Code: Select all
for ( i=0; i<= (sizeof(Imagee) - TOKEN_SIZE + 1); i++ )
Code: Select all
#define TOKEN_SIZE 2
char startdata[TOKEN_SIZE] = {'\xff','\xd8'};
char enddata[TOKEN_SIZE] = {'\xff','\xd9'};
int i;
int start_idx = -1;
int end_idx = -1;
for ( i=0; i< (sizeof(Imagee) - TOKEN_SIZE); i++ )
{
if ( memcmp((void*)startdata, (void*)(&Imagee[i]), TOKEN_SIZE) == 0 )
{
start_idx = i;
break;
}
}
while( i< (sizeof(Imagee) - TOKEN_SIZE))
{
if ( memcmp((void*)enddata, (void*)(&Imagee[i]), TOKEN_SIZE) == 0 )
{
end_idx = i;
break;
}
i++;
}
if ( start_idx>=0 )
{
iprintf("Start of data = %u\r\n",start_idx );
if ( end_idx>=0 )
{
iprintf("End of data = %u\r\n",end_idx );
}
else
{
puts("End of data not found\r");
}
}
else
{
puts("Start of data not found\r");
}
this code also makes no assumptions about the contents of the startdata and enddata arrays.
given that each of these starts with 0xFF, there is a more efficient way of doing this using memchr, by finding the 0xFF and then looking at the next char to see if it is 0xD8 or 0xD9.