27c256 | 4K81H | 68HC11A1 | 68HC11P1 | 68hc24 | 68HC711E9 | 68HC811 | 8255 | A2D | ADC | ADC12138 | Am85C30 | BRCLR | Buffalo | CMOS | EEPROM | EPROM | Ethernet | EVB | EVBU | HC11E1 | HC11E9 | HC711E9 | Horray | ImageCraft | IRQ | Keypad | LCD | MC68HC11D0FN | MC68HC11E1CFU3 | MC68HC11F1 | MC68HC711E9 | MC68HC711E9CFN2 | Microcore11 | Microstamp11 | Minikit | NVRAM | PSD | PSD8xx | PSD9xx | PT1000 | RS232 | RTS | RXD | SPI | SRAM | TXD | Watchdogs | XIRQ

I'm having problem with the sci communication with 68hc11e1. I've setup the baud = 0x30, sccr1 = 0x0 and sccr2 = 0x0c . I've connected the serial input to a gps reciever that sends the data in the same format. I have to serial inputs, I'm trying to read location data from the gps reciever and then send that data through the other serial connection to pc. But when i'm checking the SCSR if RxD is IDLE, it says it's active with out a connection to the gps receiver. Is it possible to read from the serial port (RS232) from a gps reciever that puts out data every second, and only read it every 5 seconds or do I need to read it every second? I want to know if it's possible to read from a serial connection at only certain intervals not all the time? The gps reciever is set at 9600 bps, and the baud is set at 9600. I check using hyperterminal for both connections.

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

On Sat, 2004-04-03 at 15:49, yazhi_1 wrote: > I want to know if it's possible to read from a serial connection at > only certain intervals not all the time? The problem here is one of "handshaking". Your GPS unit, as you say, sends out data every second, that is, when it wants to, and you can't control that. If you were to "listen" only every five seconds, then what you see the moment you *start* "listening" is random - it may be the start of a data packet, it may be the middle, it may be the end. I think that you will agree, that you need the whole data packet in the right order, to make any use of it. If I gather correctly, you need to gather the packet starting with a CR, or the first character after a CR, which means you have to be continuously receiving characters, looking for a CR. When you find one, then you either start loading the characters into your input routine, or you decide to ignore the whole packet, in which case you simply continue to receive characters until you get another CR. Your SCI code then, which runs continuously, either polling fast enough not to miss any characters at 9600 baud, or interrupt driven, will contain a "switch" which is set to decide whether you will use, or "drop" a whole packet. This switch is read - only - whenever a CR is received, to decide what to do with ensuing characters. You could "fudge" it using a switch which if off, ignored the SCI port entirely, then when on, waited until the next CR, then processed the following packet, and on consideration, I think this would probably work adequately. -- Cheers, Paul B. "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." - Unknown

(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

I believe if you do a search for NMEA-083 (the standard most GPS units use, You will find the packets always start with the same character a $. To synch with the next bit of information from the GPS read and skip characters until you get a $, then parse the message. The details are at http://www.NMEA.org/

(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

One other thing, Glenn Bradley has posted a nice summary at http://werple.net.au/~gnb/gps/nmea.html Hope that helps. Jim

(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Processing NMEA 0183 sentences is quite simple. This is an excerpt from the NMEA faq: --------- Under the NMEA-0183 standard, all characters used are printable ASCII text (plus carriage return and line feed). NMEA-0183 data is sent at 4800 baud. The data is transmitted in the form of "sentences". Each sentence starts with a "$", a two letter "talker ID", a three letter "sentence ID", followed by a number of data fields separated by commas, and terminated by an optional checksum, and a carriage return/line feed. A sentence may contain up to 82 characters including the "$" and CR/LF. If data for a field is not available, the field is simply omitted, but the commas that would delimit it are still sent, with no space between them. --------- I'd recommend you use interrupt-driven mode for the SCI. Inside the ISR, check for the sentence's leading $ symbol setting a flag when found. (If you know you'll be reading only from GPS units change the $ to $GP as this is fixed for all GPS generated sentences.) While the flag is set, store every following character to a buffer (77 chars max, $GP and CR/LF not saved) until a CR is detected which should also turn off the flag. Chances are you're not interested in all available sentences as many of them only repeat the same information in a different format. So, choose which one or two sentences you care to decode (usually GGA, RMB, or RMC sentences are good enough for most applications), and search and save only those in the buffer(s) to be processed by the main code. The same sentence normally repeats every second. So, if you don't have enough time to read and decode the previous sentence before the next one arrives, you'll need another flag to tell the ISR to not start saving another sentence until the previous is processed. You could use polled-mode SCI, wait for the correct sentence to appear (indicated by the corresponding $GPxxx sequence of bytes) and process the sentence as it arrives (at about 2ms per character at the standard's 4800 bps, or even 1ms @9600 bps, there is plenty of time). But, given the one-second distance between same sentences, this could cause too long a wait for your system each time it tries to update the device's location. This may be useful only if updates are a very low priority task that runs only when no other tasks are active. (The use of the term task does not imply the use of an RTOS, although one would certainly make the whole application much easier having task prepare decoded GPS data in the background for the main task to use.) To answer you other question, it is possible to read from the SCI only when you like regardless of actual data flow. Any characters received between actual reads will be lost and this will be indicated by the overrun bit (OR) in the SCI status register. Good luck. ----- Original Message ----- From: "yazhi_1" <> To: <> Sent: Saturday, April 03, 2004 8:49 AM Subject: [m68HC11] sci communication with 68hc11e1 > I'm having problem with the sci communication with 68hc11e1. > I've setup the baud = 0x30, sccr1 = 0x0 and sccr2 = 0x0c . > I've connected the serial input to a gps reciever that sends the data > in the same format. I have to serial inputs, I'm trying to read > location data from the gps reciever and then send that data through > the other serial connection to pc. But when i'm checking the SCSR if > RxD is IDLE, it says it's active with out a connection to the gps > receiver. > Is it possible to read from the serial port (RS232) from a gps > reciever that puts out data every second, and only read it every 5 > seconds or do I need to read it every second? > > I want to know if it's possible to read from a serial connection at > only certain intervals not all the time? > The gps reciever is set at 9600 bps, and the baud is set at 9600. I > check using hyperterminal for both connections.

(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )