UART/CODE problem Oshonsoft

[camerart]

Hi,
When setting the BAUD rate on a PIC, one of the settings is BRGH, the H stans for High.
what I want to know is, what is high and what is low?
In other words when is BRGH used?
Camerart

 

[For The Popcorn]

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...

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.

 

[tumbleweed]

... and my comment wasn't directed at Ian, not at all.

In order for this one thread to make any real sense you would have to have been following the last 10 years of posts about this from the OP (and all the other related threads) on multiple forums. It keeps reguritating the same stuff over and over since the root of the problem is never really addressed.

There's no way anyone's going to be of real help here.

 

[camerart]

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 T,
I'm afraid that my Kamikaxe approach, is due to lack of programming skills, and my progress, is with the fantastic help from the forums mentioned, which is much appreciated.

I have set up a mini program, as you suggest.

Thanks, I'll keep trying.
C

 

[camerart]

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 F,
Initially, I started on this forum many years ago, and sometimes pop back for a second opinion.
I also update the thread, that I've had for years.
C

 

[camerart]

As Tumbleweed said.. I'll have to drop out here as I'm not helping.

Hi I,
Please don't, you are and have been a great help.

I'll try to post fewer questions!
C.

 

[For The Popcorn]

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. [Yes, this sentence doesn't make great sense, but it makes more sense than this thread.]

But hey, you've been working on this project for years, so I guess it's working for you.

 

[camerart]

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,
It has been said that this thread is years long, but I only asked a short particular question away from AAC, for a quick answer.
It's true that the project is years old, but if you saw the project set-up, it has lots of elements, that I never would have thought it was possible for me to learn, so really this is brilliant, even though it looks a mess to onlookers, who are perhaps much tidier programmers, than me.

I wanted to stop lots of time, as it is hard work, but because so many people had spent their time with this, I told myself keep going till it all works. folly, or what.
C

 

[Ian Rogers]

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?

 

[For The Popcorn]

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.

 

[camerart]

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 F,
Looking from my perspective: The thread on this topic at AAC is explaining alots of different opinions, that may lead to finding this error.

I swapped over to this forum, to ask a particular question, which was answered by #3, so I should have closed the thread, but was asked questions, so it has got longer. Not really my fault, and inseresting.

C

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?

Hi I,
I looked up Mr Tumble, and not far off

The SPI is working fine. In fact the BASE CODES with 2x PICs and all of the peripherals is all working except for this mystery problem. There are a couple of hints explained, to work through.

I have a mate whos helping me, and we've now gone back a bit 'as suggested' I'm working on a cut down vesrion looking for the BAUD error, and he's shortening the INTERRUPTs, then hpefully we' put them back together, and all will be fine. See you in a day or two (Months more like)
C

 

[tumbleweed]

A lot of what Ian's posted in that AAC thread is spot on. Just ignore statements like:

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.

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.

 

[camerart]

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.

Hi T,
In the interests of following suggestion above, I've moved your question here:

UART/CODE problem Oshonsoft

Hi, I have an intermittent error, on an 18F4431. There is a GPS connetected to PIN 1, where the GPS read at the pin, shows it correctly at 38400 Baud. The 4431 sends it via SPI to an 18F46K20, which shows it on a computer terminal. Sometimes the 46K20 stops outputting, even though the 4431 still...

forum.allaboutcircuits.com

C.

 

[tumbleweed]

from AAC:

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

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.

 

[For The Popcorn]

Hi T,
In the interests of following suggestion above, I've moved your question here:

Oh vey.

 

[camerart]

Oh vey.

Hi F,
I don't know what I'm supposed to think after your exclamation?
C.

 

[For The Popcorn]

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

 

[camerart]

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.

Hi T,
Ok, we'll stay on this thread.

With the existing program 4431 SLAVE, set to 9600, and after reading the GPS set to 38400 BAUD, then after SPI to MASTER which output the DATA, it works. when the SLAVE is set to match the GPS at 9600, then it doesn't work properly.

but it's hard to tell from all the bits and pieces of code fragments that keep changing.

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.

I think INTERRUPTs were adopted years back, after a problem with the method used to read the GPS at the time.

I'll pass on your advide to my mate who is a good programmer (with limited time) and see what he comes up with.

My thoughts are: This has been running fine until recently, and one suggestion was to find out when this error occured. I think one change is the SS/CS PIN being the same as the EUSART TX. There may be others.
Thanks.
C

 

[camerart]

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 F,
I didn't know it was rude, but now I do!

The reason I tried, was that the real question [ UART/CODE problem Oshonsoft ] is on AAC, and this question [BAUD rate High rate or low? ] was asked here so as not to confuse AAC, and was answered in #2, so it should have finalised there. It told me what I wanted to know.

I'm afraid this is the nature of Forums, it's difficult to navigate them without offence, while making the point as clear as possible.
C.

 

[Pommie]

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.

 

[camerart]

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.

Hi P,
When I started this project, I used 16F648A PICS, such was my knowledge. Over the years I have changed PICs quite a few time, and as I use the Oshonsoft SIM, it must be supported, and I have chosen the best choice that I could.

The PCBs are another thing I've had to keep changing, and at the moment it's all working apart from this.

To me it has been a learning process, albeit slow, but that's my limitations.

I have had to learn the whole system (which is very complicated and has many differing parts to it) as I go. I can't really 'rock the boat' where most of you can, and seem to find it incomprehesible that I am unable to..

Use a different PIC, use Arduino, why don't you learn C++, you'll never finish it, doing it that way. What to do?

Thanks,
C.