Sorry, I may have over-simplified. You sketch might look something like this, assuming the PPS is connected to pin D2 and the rising edge makes the second:
volatile boolean PPS_ReadFlag = false; void setup () { ... attachInterrupt(digitalPinToInterrupt(2), serviceRoutine, RISING); ... } void serviceRoutine() { PPS_ReadFlag = true; } void loop () { while (!PPS_ReadFlag) { while(Serial.available()) { --parse the next character and set a flag if the time is valid-- } } if(timeValid) { -- update display or whatever -- PPS_ReadFlag = false; } } On Sun, May 21, 2017 at 2:56 PM, Jim Harman <j99har...@gmail.com> wrote: > Another way to do is to use the 1 PPS to trigger an interrupt on the > Arduino. Look at the documentation for attachInterrupt(). In the interrupt > routine, have it set a flag. The flag variable should be declared up front > as volatile. > > Then in your main loop, do all your parsing then loop waiting for the flag > to be set. When set, update the clock then clear the flag and repeat. > > > > On Sun, May 21, 2017 at 2:32 PM, Chris Albertson < > albertson.ch...@gmail.com> wrote: > >> To add to my last message. >> >> You CAN collect all the data then parse it like you are doing if you >> were to move to an interrupt driven serial port reader. Each >> character is then read by the interrupt handler anyplace in a large >> circular buffer. The parcer then reads out of the other and of this >> buffer. >> >> The phlegm with the current code is the parse ingnores serial input >> and will drop data, in also ignore the PPS and will as you found drop >> pulses. >> >> Typically in real time processors like your that must be interrupt >> driven or they must poll MANY times laster then the data arrives >> >> so as I wrote before, parsing the data stream one character at a tie >> is in effect pooling the serial port much faster then characters >> arrive. Adding a ring buffer and interrupts guarantees yo never >> miss a character and certainly you need to interrupt in the PPS to >> handle the case there three s serial data and the PPS at the same >> time. >> >> The ring buffer is like you big string except you data data onto one >> end at the same time as soured data off the other. Hopefully the ring >> buffer never has much data in it as the parser should be fathers then >> the serial line. BUT if a PPS happens then the parser in interrupted >> while the display updates so th ring buffer might get filled up a >> little. But the ISR terminals the parser clears the buffer. >> >> On Sun, May 21, 2017 at 11:20 AM, Chris Albertson >> <albertson.ch...@gmail.com> wrote: >> > The problem is that you get the ENTIRE string then parse it. This is >> > not going to work well as you found out. Your CPU spends almost the >> > entire time waiting for characters to come in slowly off the serial >> > line. You are just waiting on bits and wasting CPU cycles >> > >> > What you need to do is parse one character at a time. I bet your >> > parser reads one character at a time from the string. Have it read >> > one character at a time directly from the serial port. (Use a state >> > machine. It will work for such a simple job as this) >> > >> > Yes if your CPU was MUCH faster your plan could work. But on some >> > GPSes the data never has a break. You are trying to do ALL the work >> > in the break but actually most of the down time when you should be >> > working is between the characters. There is not a lot of work a >> > finite state machine needs to do between characters, just move state >> > based on a 'character class" table. I you ever studied this >> > formally, what you are building here is a "lexer" not a parcer. The >> > "Language" is not recursive and you never need to backtrack so it can >> > be de-coded literally one character at a time. >> > >> > You DO really want the 1PPS to drive an interrupt. Thisway you just >> > continue working on the data stream and don't wait for the PPS. When >> > the PPS happens you do something QUICK. never do anything time >> > consuming in the ISR or you will miss the next serial character. >> > increment a seconds count and write two bytes the the LCD and exit >> > >> > On Sun, May 21, 2017 at 6:45 AM, Ben Hall <kd5...@gmail.com> wrote: >> >> Good morning all, >> >> >> >> A quick update for those interested on my Arduino code development for >> the >> >> TruePosition boards. I've got Arduino code together than can read in >> the >> >> serial stream, parse it, and display time, date, number of satellites, >> and >> >> TFOM on a 2x16 LCD display. It does not do multiple screens, handle >> survey, >> >> or display lat/long yet. >> >> >> >> What I'm having issues with is handling the 1 PPS. Ideally, I want to >> use >> >> the 1PPS signal to trigger the display update. IE: >> >> >> >> void loop() >> >> { >> >> getSerialString() // uses serial.available to pull in the serial data >> >> >> >> parser() // this parses the data >> >> >> >> wait for 1PPS tick to go high >> >> >> >> if there has been a clock message, updateDispay() // update the >> display >> >> } >> >> >> >> This works great when there is a just a clock message. But when there >> is a >> >> clock message, an extstatus message, and a status message, it seems >> like it >> >> is still parsing when the 1PPS tick comes in...so it will display >> seconds as >> >> follows: 30, 31, 33, 34, 35, 36, 37, 39, etc... >> >> >> >> (If I don't wait for the 1PPS tick, it seems that my clock is one >> second >> >> fast. I say "seems" to be fast, as the time agrees with an NTP clock >> on one >> >> computer, but seems a half second slow per GPSCon's time display on the >> >> Z3801. I think I need to put up the antenna and check against WWV.) >> >> >> >> I've got one of those cheap little USB logic analyzers on order to >> figure >> >> out how much time elapses between the clock, extstatus, status, and >> 1PPS >> >> tick. I may need something faster than an Arduino Uno to do this. >> >> >> >> I'm sure there is a way to do this with an interrupt...but I couldn't >> make >> >> that work yesterday. More to follow. >> >> >> >> thanks much and 73, >> >> ben, kd5byb >> >> _______________________________________________ >> >> time-nuts mailing list -- time-nuts@febo.com >> >> To unsubscribe, go to >> >> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> >> and follow the instructions there. >> > >> > >> > >> > -- >> > >> > Chris Albertson >> > Redondo Beach, California >> >> >> >> -- >> >> Chris Albertson >> Redondo Beach, California >> _______________________________________________ >> time-nuts mailing list -- time-nuts@febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/m >> ailman/listinfo/time-nuts >> and follow the instructions there. >> > > > > -- > > --Jim Harman > > -- --Jim Harman _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.