Why getch() blocks for more than 3 characters?

[pic14]

Hello,

I wish to acquire the coordinates of a frame NMEA GPS EM-506 UART on a PIC16F88, and display on a Nokia 5110.

$ GPGGA, 064036.289,4836.5375, N, 00740.9373, E, 1,04,3.2,200.2, M,, 0000 * 0E

I use MPLAB and CCS 8 5.021d.
The test sending 3 characters on the serial port works well, but why getch() command blocks for more than 3 characters?

How else?

Partial program:

[temtronic]

It's called 'overrun'. The hardware UART has a 2-3 character buffer if you don't read the data as it comes in, the 4th data coming in causes the UART to get 'jammed'.
Add 'errors' to the use rs232(...options....). This adds a wee bit of code to clear the overrun condition.

You should though ALSO take a look at the CCS example called 'ex_sisr.c' as it allows proper operation of the UART as well as a circular buffer making it easy to receive data and parse it.


hth
jay

[ezflyr]

Hi,

Another thing. Please repeat after me, "Never, ever, ever put a printf statement, a delay, or other time consuming process inside your int_rda serial interrupt handler! Instead, stuff the character into an array and get out fast, then process the array inside your Main() routine. Keep in mind that once a character is detected by the UART, and the int_rda interrupt fires, the interrupt is then disabled until the character is read, and the interrupt returns to the Main() program. In your case, the printf statements take significantly longer to execute than the receipt of a single character, so the UART buffer overflows while the interrupt is disabled and then hangs.

John

[bkamen]

"Liking" ezflyer's comment.


ISRs should be fast and succinct.
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D

[gpsmikey]

Depends - interrupts work best for the younger crowd - us old folks tend to start to service an interrupt then get another one and another one until we are exhausted and still have not finished the first one (or found our glasses)

mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3

[Ttelmah]

No, the ones who have been around for a while, learn to delegate, and go and play golf.

However, back to the original problem, temtronic's and exflyr's comments are spot on. I'm guessing that nokia_printchar routes to a routine to drive a nokia LCD. If so, these are _slow_. The routine sends ten characters to this, for every one received. Result, overflow/deadlock....
It gets worse, since this print is being done four times, for every single character received.

The old (oft repeated) mantra, is _keep interrupt handlers _quick_.
An interrupt handler should just do the job to handle what has been signalled. Nothing else. So INT_RDA (which signals one character has arrived), should just receive that character and get out again ASAP.

Gpsmikey's comment makes the point. It is as if a person receiving calls on a switchboard, instead of just receiving the call, insisted on reciting their life story to each caller. The switchboard would quickly grind to a halt.

[pic14]

Hello,
Thank you for your advice and see my solution below.

Solution that works with GPS (EM-506)-16F88 Nokia 5110
-> Reading Time and Latitude:

Program for PIC16F88: