--- In [EMAIL PROTECTED], "Aaron Ardiri" <[EMAIL PROTECTED]>
wrote:
> > See Message #85437 in this forum that I posted.
>
> you mean this one?
> http://www.escribe.com/computing/pcpqa/m71474.html
That looks like it.
> > SrmReceive() doesn't return until at least 8 bytes are in the
buffer
> > in OS 5. The app I'm working on needs to respond to single byte
> > polls and the same exact code worked fine in the preOS 5 world,
so
> > I'm thinking that there must be a bug in their stuff.
>
> as you identified, this is most likely a problem with implementation
> (either be it hardware limitation or software). its not that common
> people use the serial manage and send a single byte over it *g* or,
> begad.. it could be a bug in your code :)
>
> have you tried isolating the code slightly?
Yes. See below.
error = SerReceiveCheck(m_serRefNum, &serNumBytes);
if(serNumBytes >= 1)
{
char serNumBytesChar1 = serNumBytes + 0x30;
FrmCustomAlert(DebugAlert, &serNumBytesChar1, NULL, NULL);
}
This Alert message will ALWAYS display 8 in OS 5. OS 4 displays 1.
>
> see if SrmReceive is actually thread blocking - that is, doing
nothing
> until 8 bytes of data is actually put into the buffer. are you sure
> that no errors are occuring with those calls?
>
Yes, I check for errors on SrmReceiveCheck() and SrmReceive(). I
don't call SrmRecieve() if SrmReceiveCheck() returned an error.
> looking over the code, i see some potential issues.
>
> 1. serNumBytes <-- set to zero by SrmRecieveCheck
>
> - should you reall go in and try to receive bytes if this value
> is zero? your if (!error) should probably include a check that
> there are bytes to recieve. i dont know what calling SrmReceive
> with 0 bytes actually does - could do some funky stuff.
>
> you might want to also set it manually to zero before that call
> to be on the save side, your optimizer might be doing some funky
> register tweaking which is known to make fun bugs at times as
well
I have turned all optimizations on the compiler off. I will try only
calling SrmRecieve() if SrmReceiveCheck() returns a non-zero value,
but that still doesn't explain why SrmReceiveCheck() will only return
when I have 8 bytes in the buffer.
>
> 2. SrmReceive call, are you sure you want to pass -1 as the timeout?
> -1 means wait forever. maybe serNumBytes is being set to 8
magically
> and, SrmReceive sits and waits forever for these 8 bytes? try
> setting it to 10 or so (100ms) - at least, give it enough time
to
> get X bytes.
I've tried -1, 0, 1, 2, 3, 4, 5, 6, 7, and 8 as the timeout values.
SrmReceiveCheck() will always wait until I have at least 8 bytes in
the buffer.
>
> while this wont be part of your problem, it is a little nitpick :)
>
> char serNumBytesChar = serNumBytes + 0x30; // convert to ASCII
> FrmCustomAlert(DebugAlert, &serNumBytesChar, NULL, NULL);
>
> isn't the best way to do this :) your passing the address of a char
> variable onto your CustomAlert - but, you cannot guarentee that the
> byte directly following is actually a \0 character.
You are correct, you are nitpicking. This is just debug code. The
end user doen't care how many bytes are in the buffer. It's a quick
and dirty way to convert a single digit to ASCII without allocating
more memory. The alert does display some garbage after the text, but
I know what I'm looking for. For all other Custom Alerts I do
allocate more memory.
>
> since it also works on OS4, it could potentially spell out a bug
> with PACE - but, lets not count your chickens before they hatch.
> it could just be programmer error *g*
>
Dude, I have worked for a week on this crap. I have sat down with
multiple engineers that have worked on the Palm OS and embedded
software before. We have spend well over $500 worth of time into
this problem and no one can explain what is going wrong. My company
is willing to fork over the $500. I appreciate your attempt at
helping. I'll let you know what the experts say.
> ---
> Aaron Ardiri [EMAIL PROTECTED]
> CEO - CTO +46 70 656
1143
> Mobile Wizardry
http://www.mobilewizardry.com/
>
> --
> For information on using the Palm Developer Forums, or to
unsubscribe, please see http://www.palmos.com/dev/support/forums/
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
