This kamikaze approach of "change this, change that", posting on several different forums, and not really knowing what you're doing with all the "help" you're getting...
Hi T,You should put everything back the way it was. Running at 32MHz, the baud rate isn't your problem.
As long as it's within a few percent you should be fine... you don't need "exact xtals" or half the nonsense spewed out in that AAC thread. You're barking up the wrong tree.
If the program was working and then "hangs up after a while", your problem is with the whole arrangement of the three different processors you have and the asynchronous communications between them. Getting this to work is not trivial, and getting it to work reliably is VERY non-trivial. Recovering from any error/missed event is hard. You have simple code for handling things like a buffer overrun byte in the uart, but resyncing things after an event like that takes some effort since your GPS is sending you multi-byte messages/packets 4 or 5 times a second. Just clearing the overrun won't help. Add to that the fact that you were probably in the middle of trying to transfer SPI data to your other uC at the time and the problems just compound.
This kamikaze approach of "change this, change that", posting on several different forums, and not really knowing what you're doing with all the "help" you're getting... good luck!
From what I've seen in all these threads, 90% of the problems are self-inflicted. You should have picked a more capable device and done it all in one processor.
Hi F,As tumbleweed has stated, when you post the same question on multiple threads, it creates a hopeless mess and wastes everyone's time. You get a jumble of responses and suggestions all working at cross-purposes because nobody can follow what you're doing....including yourself.
Hi I,As Tumbleweed said.. I'll have to drop out here as I'm not helping.
Hi F,I would humbly suggest that advice from one group of people who see the entire discussion and might be on the same page is better than advice from two or more groups who don't know that you're bouncing between approaches is probably not effective. Particularly when you can't adequately evaluate conflicting advice.
But hey, you've been working on this project for years, so I guess it's working for you.
Hi F,Perhaps cross posting should be actively discouraged. It's frustrating to write a detailed reply, and then read nearly the same thing in another forum.
Hi I,Its okay Mr Tumble... I know you weren't having a go, I agree that there are too many chefs.. I never back off anyway. Always watching, I only step in when topics take a turn.
I am starting to believe that there is more here than just serial communication error.
If I remember a couple of months back, we couldn't get the SPI sentences correct. Was that even solved?
That's a load of rubbish. A uart resyncs on the START bit of every byte so it doesn't matter how many bytes are transferred. If you're within roughly 2-3% it's very unlikely a baud rate issue.His example of a 8Mhz crystal giving 0.16% error is typical. That means at 0.16% error for a 60 character received string (10 bits each - 1 start, 8 data, 1 stop bit), you will be off by about 1 bit.
Hi T,A lot of what Ian's posted in that AAC thread is spot on. Just ignore statements like:
That's a load of rubbish. A uart resyncs on the START bit of every byte so it doesn't matter how many bytes are transferred. If you're within roughly 2-3% it's very unlikely a baud rate issue.
In your tests look for overrun errors. Your ISR must be fast enough to keep up with the GPS baud rate.
At 9600 baud that's about 1ms/byte, and at 38400 it's a quarter of that (roughly 250us).
If you have anything in the ISR that takes time (like uart or SPI output) you'll have to get rid of it because that will effect the timing in a big way.
I think the GPS is set to automatically transmit messages 4-5 times/second. With that, you can pretty much guarantee that at some point you're going to get an overrun error and have to resync your reception of the GPS data stream.
I can change the BAUD rate and the output rate of the GPS. As mentioned it runs with the GPS set to 38400 BAUD, but not at 9600
Oh vey.Hi T,
In the interests of following suggestion above, I've moved your question here:
Hi F,Oh vey.
Hi T,from AAC:
Assuming you're actually getting both the GPS and the pic set to the same baud rate, switching down to 9600 means your GPS messages now take 4 times as long to receive which is going to cut into the time your main loop has to process the message (assuming that's where you send it over via SPI), but it's hard to tell from all the bits and pieces of code fragments that keep changing.
I think your problem is syncing up with GPS messages and dealing with overruns. You could simplify the code drastically by not using interrupts to receive messages from the GPS at all... just deal with the overruns and sync up to the beginning of a GPS message in the main loop every time, send it via SPI, rinse, repeat.
That makes it a LOT easier to deal with since you're not trying to get all this done in an ISR and all the coordination that requires. For your skill level that's what I would recommend.
I don't change any CODE unless it has to change, and after advice. e,g, you are suggesting what may be the answer here, so should I adopt it? I can't tell your skill level, so I weigh it up and do what I think. what else can I do.but it's hard to tell from all the bits and pieces of code fragments that keep changing.
Hi F,I think cross-posting is rude and wastes people's time as I have previously stated.
I think sharing somebody's post from one forum to another where he may not even be a member is rude in the utmost.
But you don't understand the first point so you definitely won't understand the second.
Pardon my comments
Hi P,As I said on another thread a long time ago. You need to switch to 1 chip (and maybe C) and use that for everything. As demonstrated, controlling 8 servos, receiving uart data and buffering it (fifo) and keeping track of time uses less than 1% of actual computing power available. Knowing what else needs to be added would be programatically trivial but the communication between chips makes it very difficult (or impossible) to complete this.
Mike.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?