Oliver
Have you tried masking out the hotsync char while you are processing the
first. If the problem is the second hotsync char is being generated before
the OS gets to process it, you can use the same technique as if you were
masking out one of the hardware buttons (short-stop the OS and handle the
key yourself, or ignore it). If the problem is the hardware stopping to
service the interrupt generated by the key being press and placing the char
on the even queue, I don't know what can be done
>2) When the HotSync signal is triggered, the Palm OS kernel spends so much
>time processing the signal, I miss a large chunk of the data coming in.
I found I typically don't loose data to interrupts since the UART buffers
incoming chars even if the processor is busy. Are you using a control line
to read data?
-----Original Message-----
From: Oliver King-Smith <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Tuesday, August 24, 1999 3:33 AM
Subject: HotSync signal
>My application uses the HotSync Signal to initiate a read from an external
>device. This works fine in most cases, but one particular device sends a
>second HotSync signal after the read has begun.
>
>This has two unfortunate side effects.
>1) The program attempts to read a second value from the external device
>after it has completed the first read (This is solvable with a UI switch,
>although I would prefer to keep it hidden from the user).
>2) When the HotSync signal is triggered, the Palm OS kernel spends so much
>time processing the signal, I miss a large chunk of the data coming in.
>
>These problems all go away by turning off interrupts, but "everyone" says
>don't turn off interrupts otherwise your cat will go blind, etc. So does
>anyone have a suggestion on how to prevent the aforementioned problems.
>
>Other relevant facts to consider when proposing solutions
>a) The external hardware is designed by other companies, so redesigning it
>is not an option.
>b) I can not use the UART, since the data is not RS232 compatible (i.e. no
>start or stop bits, and no frame information).
>
>Thanks in advance
>
>Oliver King-Smith
>
>
>
