Multiple Array and pointer issue

[Ron Blancarte]

I was looking through the newsgroup FAQ for an answer to my question,
but it doesn't appear to have one.

I am working with a system that has VERY limited memory. I was
defining two buffers to pass in and out data:

unsigned char inputBuffer[100];
unsigned char outputBuffer[100];

But now it turns out I need the output buffer to be larger under
certain cases. What I wanted to do was make the output buffer double
size:

unsigned char outputBuffer[200];

And then use the input buffer as a portion of outputBuffer:

unsigned char *inputBuffer = outputBuffer + 100;

When necessary, the outputBuffer could then use the large array and
inputBuffer would have it's space as well, without having to allocate
the extra 100 bytes for the outputBuffer.
So I made this change, however, now input is not working. I would
have thought subscripting that was existing in code would still work.
My code all uses inputBuffer[location] as means of accessing the
inputBuffer.

So my question is, what am I doing wrong?

RonB

[Eric Sosman]

Ron Blancarte wrote On 06/07/07 13:08,:

I was looking through the newsgroup FAQ for an answer to my question,
but it doesn't appear to have one.

I am working with a system that has VERY limited memory. I was
defining two buffers to pass in and out data:

unsigned char inputBuffer[100];
unsigned char outputBuffer[100];

But now it turns out I need the output buffer to be larger under
certain cases. What I wanted to do was make the output buffer double
size:

unsigned char outputBuffer[200];

And then use the input buffer as a portion of outputBuffer:

unsigned char *inputBuffer = outputBuffer + 100;

When necessary, the outputBuffer could then use the large array and
inputBuffer would have it's space as well, without having to allocate
the extra 100 bytes for the outputBuffer.
So I made this change, however, now input is not working. I would
have thought subscripting that was existing in code would still work.
My code all uses inputBuffer[location] as means of accessing the
inputBuffer.

So my question is, what am I doing wrong?

There's nothing inherently wrong with your pointer
arithmetic, if that's what's worrying you. Note, though,
that this doesn't magically create 100 extra bytes out
of thin air. What you're actually doing is sharing the
latter half of the 200-char buffer, using those locations
for input and for the tail end of long outputs. Are your
output characters stomping all over your inputs before
you've processed them? Are you, say, reading data into
inputBuffer, then filling outputBuffer with blanks, then
trying to process the suddenly all-blank inputBuffer?

Without having seen any code, that's about all the
guessing I can manage.

--
Er*********@sun .com

[Ron Blancarte]

On Thu, 07 Jun 2007 13:25:19 -0400 (while OU was sucking), Eric Sosman
wrote:

>Ron Blancarte wrote On 06/07/07 13:08,:

>I was looking through the newsgroup FAQ for an answer to my question,
but it doesn't appear to have one.

I am working with a system that has VERY limited memory. I was
defining two buffers to pass in and out data:

unsigned char inputBuffer[100];
unsigned char outputBuffer[100];

But now it turns out I need the output buffer to be larger under
certain cases. What I wanted to do was make the output buffer double
size:

unsigned char outputBuffer[200];

And then use the input buffer as a portion of outputBuffer:

unsigned char *inputBuffer = outputBuffer + 100;

When necessary, the outputBuffer could then use the large array and
inputBuffer would have it's space as well, without having to allocate
the extra 100 bytes for the outputBuffer.
So I made this change, however, now input is not working. I would
have thought subscripting that was existing in code would still work.
My code all uses inputBuffer[location] as means of accessing the
inputBuffer.

So my question is, what am I doing wrong?

There's nothing inherently wrong with your pointer
arithmetic, if that's what's worrying you. Note, though,
that this doesn't magically create 100 extra bytes out
of thin air. What you're actually doing is sharing the
latter half of the 200-char buffer, using those locations
for input and for the tail end of long outputs. Are your
output characters stomping all over your inputs before
you've processed them? Are you, say, reading data into
inputBuffer, then filling outputBuffer with blanks, then
trying to process the suddenly all-blank inputBuffer?

Without having seen any code, that's about all the
guessing I can manage.

Damn, I did leave out a paragraph on this.

So yea, I didn't magically create 100 bytes, I am just sharing that
back 100 under the special circumstances (which I won't mind if I
clobber the information in the input Buffer). Normal cases should not
be a problem

What problem that I am having is that it seems my functions which
worked with:

unsigned char inputBuffer[100];
unsigned char outputBuffer[100];

don't appear to be working with:

unsigned char inputBuffer[100];
unsigned char *inputBuffer = outputBuffer + 100;

These are functions which don't produce enough data to actually hit
the 100 byte limit.

For example:

void SPI_receive()
{
systat_7 = 0;
SPICON = 0x31;
SPI_COMM_SS = 0;
SPIDAT = 0;
while (ISPI == 0);
inputBuffer[spi_in] = SPIDAT;
++spi_in;
if(!(--spiSize)){
systat_3 = 1;
systat_1 = 0;
}
SPI_COMM_SS = 1;
}

void spi_getSize()
{
*((char*)&spiSi ze ) = inputBuffer[1];
*((char*)&spiSi ze+1) = inputBuffer[2];
}

void SPI_send()
{
systat_7 = 0;
SPICON = 0x31;
if(!systat_5){
SPI_COMM_SS = 0;
SPIDAT = outputBuffer[OB_out];
while (ISPI == 0);
if(!(--spiSize))
systat_5 = 1;
++OB_out;
ISPI = 0;
SPI_COMM_SS = 1;
}
else{
systat_1 = systat_3 = systat_5 = systat_6 = 0;
systat_4 = 1;
}
}

These appear to be my problem functions right now. What happens is
that you xfer 3 bytes of data over the SPI bus initially. Then you
call spi_getSize(), so you know how many characters are being sent.
Then you start to use SPI_receive() to pull data off the bus 1
character at a time and place it into the buffer. After some
processing is done, and then the response is sent back out across the
SPI bus via SPI_send.

spi_in and OB_out are just indices which allow me to traverse
character by character through the buffers. There is an out and in
indice for each buffer (spi_in/spi_out and OB_in/OB_out)

RonB

[Ron Blancarte]

On Thu, 07 Jun 2007 13:39:39 -0500 (while OU was sucking), Ron
Blancarte wrote:

>On Thu, 07 Jun 2007 13:25:19 -0400 (while OU was sucking), Eric Sosman
wrote:

>>Ron Blancarte wrote On 06/07/07 13:08,:

>>I was looking through the newsgroup FAQ for an answer to my question,
but it doesn't appear to have one.

I am working with a system that has VERY limited memory. I was
defining two buffers to pass in and out data:

unsigned char inputBuffer[100];
unsigned char outputBuffer[100];

But now it turns out I need the output buffer to be larger under
certain cases. What I wanted to do was make the output buffer double
size:

unsigned char outputBuffer[200];

And then use the input buffer as a portion of outputBuffer:

unsigned char *inputBuffer = outputBuffer + 100;

When necessary, the outputBuffer could then use the large array and
inputBuffer would have it's space as well, without having to allocate
the extra 100 bytes for the outputBuffer.
So I made this change, however, now input is not working. I would
have thought subscripting that was existing in code would still work.
My code all uses inputBuffer[location] as means of accessing the
inputBuffer .

So my question is, what am I doing wrong?

There's nothing inherently wrong with your pointer
arithmetic, if that's what's worrying you. Note, though,
that this doesn't magically create 100 extra bytes out
of thin air. What you're actually doing is sharing the
latter half of the 200-char buffer, using those locations
for input and for the tail end of long outputs. Are your
output characters stomping all over your inputs before
you've processed them? Are you, say, reading data into
inputBuffer , then filling outputBuffer with blanks, then
trying to process the suddenly all-blank inputBuffer?

Without having seen any code, that's about all the
guessing I can manage.

Damn, I did leave out a paragraph on this.

So yea, I didn't magically create 100 bytes, I am just sharing that
back 100 under the special circumstances (which I won't mind if I
clobber the information in the input Buffer). Normal cases should not
be a problem

What problem that I am having is that it seems my functions which
worked with:

unsigned char inputBuffer[100];
unsigned char outputBuffer[100];

don't appear to be working with:

ONE THING!!
I don't know if this makes a difference or not, BUT...
I forgot to mention, inputBuffer and outputBuffer are both global.
They are being accessed via extern in the SPI routines. Will this
make any sort of differnce?

>unsigned char inputBuffer[100];
unsigned char *inputBuffer = outputBuffer + 100;

These are functions which don't produce enough data to actually hit
the 100 byte limit.

For example:

void SPI_receive()
{
systat_7 = 0;
SPICON = 0x31;
SPI_COMM_SS = 0;
SPIDAT = 0;
while (ISPI == 0);
inputBuffer[spi_in] = SPIDAT;
++spi_in;
if(!(--spiSize)){
systat_3 = 1;
systat_1 = 0;
}
SPI_COMM_SS = 1;
}

void spi_getSize()
{
*((char*)&spiSi ze ) = inputBuffer[1];
*((char*)&spiSi ze+1) = inputBuffer[2];
}

void SPI_send()
{
systat_7 = 0;
SPICON = 0x31;
if(!systat_5){
SPI_COMM_SS = 0;
SPIDAT = outputBuffer[OB_out];
while (ISPI == 0);
if(!(--spiSize))
systat_5 = 1;
++OB_out;
ISPI = 0;
SPI_COMM_SS = 1;
}
else{
systat_1 = systat_3 = systat_5 = systat_6 = 0;
systat_4 = 1;
}
}

These appear to be my problem functions right now. What happens is
that you xfer 3 bytes of data over the SPI bus initially. Then you
call spi_getSize(), so you know how many characters are being sent.
Then you start to use SPI_receive() to pull data off the bus 1
character at a time and place it into the buffer. After some
processing is done, and then the response is sent back out across the
SPI bus via SPI_send.

spi_in and OB_out are just indices which allow me to traverse
character by character through the buffers. There is an out and in
indice for each buffer (spi_in/spi_out and OB_in/OB_out)

RonB

[Eric Sosman]

Ron Blancarte wrote On 06/07/07 14:39,:

[...]
What problem that I am having is that it seems my functions which
worked with:

unsigned char inputBuffer[100];
unsigned char outputBuffer[100];

don't appear to be working with:

unsigned char inputBuffer[100];
unsigned char *inputBuffer = outputBuffer + 100;

Of course this won't "work:" It won't even compile.
And if the first `inputBuffer' is really `outputBuffer',
then the buffer isn't big enough. We can sit here all
day trying to guess how to change what you've shown to
get to what your code is actually like, but in the end
that just means we're debugging our guesses and not
debugging your code.

If you feel ill, do you send your doctor a crayon
drawing of your body with an arrow saying "This is where
it hurts?"

If your car won't start, do you call the garage and
tell the mechanic "It's a sort of off-blue color, more
toward aqua. What's wrong with it?"

I'm not asking for you to post all umpty-bazillion
lines of your code (and I wouldn't read it if you did).
Whittle the code down to the smallest complete and
compilable program that demonstrates the problem, and
post that exact code: No paraphrases, no abbreviations,
no fill-in-the-blanks, but something another person can
run through his compiler unmodified. That way, we'll
be debugging your code instead of debugging a sort of
cloud of more and less likely possibilities centered
around your code.

Oh, and one more thing: "input is not working" is
not a sufficiently precise description of your problem.
In what way is it "not working?" What actually happens,
and how does that differ from what you hoped would happen?
Some people on this group seem to be able to read minds
on occasion, but it's not a reliable talent.

People *will* try to help you, but you've got to
cooperate more actively.

--
Er*********@sun .com

[Karl Malbrain]

"Ron Blancarte" <[e-mail] rote in message
news:0v******** *************** *********@4ax.c om...

On Thu, 07 Jun 2007 13:39:39 -0500 (while OU was sucking), Ron
Blancarte wrote:

>>On Thu, 07 Jun 2007 13:25:19 -0400 (while OU was sucking), Eric Sosman
wrote:

>>>Ron Blancarte wrote On 06/07/07 13:08,:
I was looking through the newsgroup FAQ for an answer to my question,
but it doesn't appear to have one.

I am working with a system that has VERY limited memory. I was
defining two buffers to pass in and out data:

unsigned char inputBuffer[100];
unsigned char outputBuffer[100];

But now it turns out I need the output buffer to be larger under
certain cases. What I wanted to do was make the output buffer double
size:

unsigned char outputBuffer[200];

And then use the input buffer as a portion of outputBuffer:

unsigned char *inputBuffer = outputBuffer + 100;

When necessary, the outputBuffer could then use the large array and
inputBuffe r would have it's space as well, without having to allocate
the extra 100 bytes for the outputBuffer.

How do you tell the buffer's clients how large it is???? If you use
sizeof(outputBu ffer) you're going to have trouble.

karl m

[Ron Blancarte]

On Thu, 07 Jun 2007 20:58:53 GMT (while OU was sucking), Karl Malbrain
wrote:

>"Ron Blancarte" <[e-mail] rote in message
news:0v******* *************** **********@4ax. com...

>On Thu, 07 Jun 2007 13:39:39 -0500 (while OU was sucking), Ron
Blancarte wrote:

>>>On Thu, 07 Jun 2007 13:25:19 -0400 (while OU was sucking), Eric Sosman
wrote:
Ron Blancarte wrote On 06/07/07 13:08,:
I was looking through the newsgroup FAQ for an answer to my question,
but it doesn't appear to have one.
>
I am working with a system that has VERY limited memory. I was
defining two buffers to pass in and out data:
>
unsigned char inputBuffer[100];
unsigned char outputBuffer[100];
>
But now it turns out I need the output buffer to be larger under
certain cases. What I wanted to do was make the output buffer double
size:
>
unsigned char outputBuffer[200];
>
And then use the input buffer as a portion of outputBuffer:
>
unsigned char *inputBuffer = outputBuffer + 100;
>
When necessary, the outputBuffer could then use the large array and
inputBuff er would have it's space as well, without having to allocate
the extra 100 bytes for the outputBuffer.

How do you tell the buffer's clients how large it is???? If you use
sizeof(outputB uffer) you're going to have trouble.

Yea, that I know. when defining the buffers, instead of using "100"
etc, they are constant defines. If the size needs to be checked, then
I will just check it against these define statesments.

RonB

[Ron Blancarte]

On Thu, 07 Jun 2007 16:26:16 -0400 (while OU was sucking), Eric Sosman
wrote:

>Ron Blancarte wrote On 06/07/07 14:39,:

>[...]
What problem that I am having is that it seems my functions which
worked with:

unsigned char inputBuffer[100];
unsigned char outputBuffer[100];

don't appear to be working with:

unsigned char inputBuffer[100];
unsigned char *inputBuffer = outputBuffer + 100;

Of course this won't "work:" It won't even compile.
And if the first `inputBuffer' is really `outputBuffer',
then the buffer isn't big enough. We can sit here all
day trying to guess how to change what you've shown to
get to what your code is actually like, but in the end
that just means we're debugging our guesses and not
debugging your code.

That would be a typo as you pointed out.
unsigned char outputBuffer[200];
unsigned char *inputBuffer = outputBuffer + 100;

I'm not asking for you to post all umpty-bazillion
lines of your code (and I wouldn't read it if you did).
Whittle the code down to the smallest complete and
compilable program that demonstrates the problem, and
post that exact code: No paraphrases, no abbreviations,
no fill-in-the-blanks, but something another person can
run through his compiler unmodified. That way, we'll
be debugging your code instead of debugging a sort of
cloud of more and less likely possibilities centered
around your code.

If possible I would do this. Unfortunately what I am looking at here
is a 10000 line program that I need to change the memory footprint of
to add a new feature. The code runs in an in-house developed hardware
environment w/ two 8051 processors, to "Whittle the code down" would
still result in a large program.

I posted some function which utilize this code, mainly asking if,
syntactically they are correct. Clearly, I agree, my typo in the
above code was wrong, but in the thread of whittling down the code,
here it goes:

Given these declarations:

unsigned char inputBuffer[100];
unsigned char outputBuffer[100];
int spiSize;

And this function:

void spi_getSize()
{
*((char*)&spiSi ze ) = inputBuffer[1];
*((char*)&spiSi ze+1) = inputBuffer[2];
}

if I changed my declarations to this:

unsigned char outputBuffer[200];
unsigned char *inputBuffer = outputBuffer + 100;
int spiSize;

Ignoring reading in data (which again was done via the SPI_receive
routine I posted earlier), should the spi_getSize function continue to
work as expected? (Which is reading in the 2nd and 3rd characters of
inputBuffer into an int).

RonB

[CBFalconer]

Ron Blancarte wrote:

>

.... snip ...

>
ONE THING!!
I don't know if this makes a difference or not, BUT...
I forgot to mention, inputBuffer and outputBuffer are both global.
They are being accessed via extern in the SPI routines. Will this
make any sort of differnce?

Please snip immaterial quoted material.

The answer is quite likely yes. They will affect anything such as
"sizeof buffer".

--
<http://www.cs.auckland .ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfoc us.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

Ron Blancarte wrote:

>

.... snip ...

>
And then use the input buffer as a portion of outputBuffer:

unsigned char *inputBuffer = outputBuffer + 100;

When necessary, the outputBuffer could then use the large array
and inputBuffer would have it's space as well, without having to
allocate the extra 100 bytes for the outputBuffer.

So I made this change, however, now input is not working. I
would have thought subscripting that was existing in code would
still work. My code all uses inputBuffer[location] as means of
accessing the inputBuffer.

So my question is, what am I doing wrong?

Who knows. You omitted the code. Cut your system down to
something compilable and executable that exhibits the problems
(about 100 lines or so) and post that. By then you probably have
solved it yourself.

--
<http://www.cs.auckland .ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfoc us.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com