> See Message #85437 in this forum that I posted.

you mean this one?

http://www.escribe.com/computing/pcpqa/m71474.html
 
> 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? 

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?

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

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.

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.

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*

---
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/

Reply via email to