does this piece of code look ok?

[air1kdf]

Mine would look even better if the indentation could be displayed. With a little luck there will be an attachment here.

[Melanie]

You are aware that if you have multiple Serial inputs and the data is randomly arriving from all directions on all pins, whilst you are attending to one, then you will be losing data from the others. I just thought I'd burst your bubble before you get too involved in your project and discover it doesn't work as you expected.

[NavMicroSystems]

Hi Melanie,

this what I was actually trying to say here

This is yet another example of that it's hard to keep track with two different threads regarding the very same issue in two different forum categories.

[Richardco]

Thankyou air1kdf,
that does look a lot easier to understand, i didnt know you could use 'DO' and am now going to read about it in the manual, Its funny because when you look at the code you have written yourself it looks very clear but when someone such as yourself looks at it and puts a new slant on things it seems obvios, But still i have a good excuse " Im still at primary grade where all this is concerned, i do hope that you realise how thankfull people like me are to have people like you to ask.

can i just ask this question about your code: this is just a snippet,

Do
Serin2 pinin1, 188, [testbyte] ' read portc.1
If testbyte = "$" Then
Serout2 pinout, 188, [testbyte]
Do
Serin2 pinin1, 188, [testbyte]
If testbyte = "$" Then


the data is read from pin 1
the data is checked to see if it conformes
if the data conforms the program progresses

if the data does not conform then what happens??

it should keep checking the pin till the data conforms but i cant see this with your piece of code.
i have commented my code now so you can see what i wanted to achieve more easily, and here is a part to read from one pin and move on to the next pin if data is validated and if not to continue checking till it is, i am not sure if i have correctly understood the timeouts (,500,start2,) but ignore them if they are wrong please.


start1:
LOW PORTB.0 ' Reset data led to low
Serin2 pinin1,188,500,start2,[testbyte] ' Read portc.1
if testbyte = "$" then begin1 ' Test Charactor
goto start1 ' Loop till correct

begin1:
LOW PORTB.6 ' Reset data led to low
HIGH PORTB.1 ' Show data found at pin
Serout2 pinout,188,[testbyte] ' Send data out
high PORTB.0 ' Show data is sent out
goto loop1 ' Enter main loop 1

loop1:
Serin2 pinin1,188,500,start2,[testbyte] ' Read portc.1
if testbyte = "$" then start2 ' Test Charactor
Serout2 pinout,188,[testbyte] ' Send data out '
goto loop1 ' Loop till correct

Thankyou for your time once more.



Hi Melanie, ok thankyou for your observation, i am aware of the data that will be missed as im only reading one pin at a time, but i figured that in the time it takes to read the other pins, the data from the other instruments would not of changed that much anyhow, and for instance im chugging along in my little pleasure fishing boat, how far would i have moved in the time it takes to read a pin for the second time?, and the other instruments that will be attached are much the same, there will be a gps, a weather instrument , a sounder and velocity readings. So im HOPING that the missing data will be of no consequence, and untill i try it i will not know. But thankyou anyhow. By the way "I just thought I'd burst your bubble" Sorry that burst the day i realised i would have to work for a living lol

Ok now here is the question i do not know the answer to if i am mistaken about the missing data.

I can see that the idea of having a pic to recieve data from each talker and a master pic to combine the data and send it out seems logical, However if all the 4 talkers are transmitting a continuous stream of data to thair respective pics at 4800baud, how will the master ever hope to transmit at 4800baud all the data it collects, i cant see how it will do it for long before it gets overloaded. If you can see what i mean? Again if my thinking is not correct please enlighten me because i know very little and i want to learn.


And could someone please delete the other thread i started in the wrong place by mistake (and have said sorry for) as it may confuse some people.

[NavMicroSystems]

Richardco,

I guess you have already searched the forum for "NMEA" and read the matching threads.

A standard NMEA Talker sends out 1-3 sentences per second
(depending on the type of talker and length of the sentence)
The standard baudrate is 4800

To make sure you catch the "SYNC" string ($xxxxx) of a talker you have to sit there and wait (worst case) for about two seconds before your receiving routine times out.

This has to happen for every single talker.

Say you have "only" four talkers it takes (worst case) about 8 seconds before you get a full update.
(It gets even worse with an increasing number of talkers)

Especially for a sounder reading I feel this is unaccceptable.
(You will have hit the bank before your display is updated!)

On a sailracer all other readings should be more or less "realtime" as well to be of any use for trim.


Decreasing the timout value for the talkers does not really help as there is no defined timing.
Most likely you will (most of the time) have more than one talker "talking" at the same time.
So which one to listen to?

With a timeout too short you will worst case never get in sync with a particular talker.

[Richardco]

Hi NavMicroSystems

you said:-
A standard NMEA Talker sends out 1-3 sentences per second
(depending on the type of talker and length of the sentence)
The standard baudrate is 4800

if that is in a thread somwhere else i must have missed it because i was under the impresion that the data stream from a talker was continuous at 4800 baud, Again my mistake, but there has been a lot said about it,

I can see why for a sailracer nipping along at 30 knots or more why realtime would have to be the case, for trim and distance travlled and i can now see how all the data from 4 talkers would be collected, and sent out at 4800baud.

I have an 18ft hastings rye clinker with a single pot 10hp Diesel yanmar and if it goes faster than 5 knots without thrashing the engine it must have a tail wind and be running with the tide.

My equipment consists of a garmin gps 120 and a simrad EQ30 echosounder i have used the nmea output from the garmin and sent the data to the EQ30 as the display on the garmin is small and the backlight is poor, the EQ30 on the other have is Large and bright, with the vision problems sorted i discover that the EQ30 has the ability to display information from several different nmea devices however there is only one nmea input so you must just choose one external device or go down this route of buying or building some sort of multiplexor, at the moment i could probably make do with just 2 inputs to the EQ30, the garmin and a weather instrument to give wind speed and direction, which can be done on just one pic with two hardware usarts with no problems so i understand, so i came on here and looked at the threads on 'NMEA' and from what i read i saw that maybe in the future i would need more than two nmea devices connected to the system and so decided to go down that track for my boat system but to try and keep it on one chip if i could and if this meant losing data then that didnt seem to bad. Your last post above answers all my questions i do thankyou very much for that, with all that you have said maybe i will just keep to two nmea inputs to hardware usarts on one chip, that will take into consideration all the knowlege you have emparted to me and allow me to keep it all on one chip as well Assuming that the pic will be fast enough to collect all information from the two inputs Thanks again. with all that in mind i think a re-write of my code would be in order lol
Now all i have to do is remember where i saw the post on two hardware usarts on one pic (i hpoe it wasnt an atmel) so i can see what pic they were refering to.

[NavMicroSystems]

Richardco,

Even two USARTS on the same PIC will NOT solve the problem.

Why not use one PIC per talker?

A 12Fxxx would do, so it is less than $2 for every talker you want to add.