Dave,
To clarify a few points
1) I make no OS calls in my code while I am receiving the serial data. So
the processing is occurring when the modem HotSync line is triggered.
Presumably the Palm OS kernel is monitoring these lines, and they generate
an IRQ when they arrive.
2) Because the data is not RS232 the UART buffers are not been used. This
is unfortunate because as you mentioned the UART can run asynchronously to
the rest of the processor. But in this case there is no data going into
the UART.
Oliver
At 09:51 AM 8/24/99 -0400, you wrote:
>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
>>
>>
>>
>
