does this piece of code look ok?

[Richardco]

im using the example code and changing it around as listed below and i wondered if instead of just having portc.6 as the input pin, i could have several input pins?? as listed below



' PicBasic Pro Code that demonstrates the use of modifiers
' with the Serin2 and Serout2 commands.

testword VAR WORD ' Define word variable
testbyte VAR BYTE ' Define byte variable
test8 VAR BYTE[8] ' Define array variable with 8 locations
pinin1 VAR PORTC.1 ' Define serial pinin1 as PORTC.1
pinin2 VAR PORTC.2 ' Define serial pinin2 as PORTC.2
pinin3 VAR PORTC.3 ' Define serial pinin3 as PORTC.3
pinin4 VAR PORTC.4 ' Define serial pinin4 as PORTC.4
pinin5 VAR PORTC.5 ' Define serial pinin5 as PORTC.5
pinin6 VAR PORTC.6 ' Define serial pinin6 as PORTC.6
pinout VAR PORTC.7 ' Define serial pinout as PORTC.7

' For these examples, assume that the following string
' is being received continuously at 2400 baud on PORTC.7:
' "X-1011Y-546Z-F7ZZ-0001"

[NavMicroSystems]

does this piece of code look ok?

The answer to this question simply is:

YES it does!

[Richardco]

Thankyou very much NavMicroSystems, i assume you know what project i am working on having read many of your posts, so could you just answer me this question as well please. If i was sending data to a device (nmea) what would be the maximum interval between transmissions before the nmea device detects an error and displays the error or is this not defined in the standard?

[NavMicroSystems]

Richardco,

there is no need to start two different threads regarding the same thing.

see my reply HERE

and please see THIS

We are willing to help you help yourself, but we will certainly not provide you with a ready to run piece of code for your particular application.

[Richardco]

Im sorry for starting two threads but i began the first one in the wrong place and i saw a comment from someone regarding posting in the correct place so i changed it to here, Next the suggestion that you provide me with the completed piece of code was not a serios one as i would have thought the tone of the following statement in the post would have suggested, getting a ready built piece of code is not what i am after at all as this would teach me nothing.

Now in the post that i started in the wrong place there is a picture, this picture shows that i do not wish to use more than one chip.

so i assumed that although related to your method using more than 1 chip that there would be a new set of complexities involved in using 1 chip so i started a new thread. Again if this was not the correct thing to do i am sorry.

i would now like to know where this question has been answered
so that i can read this information and maybe get some use out of the replies

quote:
If i was sending data to a device (nmea) what would be the maximum interval between transmissions before the nmea device detects an error and displays the error or is this not defined in the standard?

i do see similarities between the above question and the one below that has been posted, However it does not answer my question,

quote:
As there is no defined timing between the different talkers

all that aside please forgive me if i have upset anyone.

Now here is my code so far, and although not completed and there are no timeouts yet , being new to this i want to iron out mistakes before the code gets to complicated for me, running before i can walk as it were. I do not mind if i miss some sentances from a pin while i read another unless the recieving device minds the break in information for that particular device, im not sure how long a device can go without update from a particular talker before it objects, which i asked about it in the question above.

If you see anything you dont think is right or you know of a more efficient way of achieving the same thing could you please let me know thanks.

the code:-

' Routine to read imea sentance from a pin and send it
' then do the same from another pin and send it.

testbyte VAR BYTE ' Define byte variable
pinin1 VAR PORTC.1 ' Define serial pinin1 as PORTC.1
pinin2 VAR PORTC.2 ' Define serial pinin2 as PORTC.2
pinout VAR PORTC.7 ' Define serial pinout as PORTC.7

' For these examples, assume that the following string
' is being received continuously at 4800 baud on PORTC.7:

start1:
Serin2 pinin1,188,[testbyte] ' read portc.1
if testbyte = "$" then begin1
goto start1

begin1:
Serout2 pinout,188,[testbyte]
goto loop1

loop1:
Serin2 pinin1,188,[testbyte]
if testbyte = "$" then start2
Serout2 pinout,188,[testbyte]
goto loop1

start2:
Serin2 pinin2,188,[testbyte] ' read portc.2
if testbyte = "$" then begin2 '
goto start2

begin2:
Serout2 pinout,188,[testbyte]
goto loop2

loop2:
Serin2 pinin2,188,[testbyte]
if testbyte = "$"then start1
Serout2 pinout,188,[testbyte]
goto loop2

[air1kdf]

Your code hurts my head and is very hard for me to follow the logic because it jumps in and out so much, so this is the same code rewritten. Is this what you were intending?

start1:
Do
Serin2 pinin1, 188, [testbyte] ' read portc.1
If testbyte = "$" Then
Serout2 pinout, 188, [testbyte]
Do
Serin2 pinin1, 188, [testbyte]
If testbyte = "$" Then
Do
Serin2 pinin2, 188, [testbyte] ' read portc.2
If testbyte = "$" Then
Serout2 pinout, 188, [testbyte]
Do
Serin2 pinin2, 188, [testbyte]
If testbyte = "$" Then start1
Serout2 pinout, 188, [testbyte]
Loop
End If
Loop
Serout2 pinout, 188, [testbyte]
Loop
End If
Loop

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

[Richardco]

Ralph
it is Because i am not cleaver enough to do it, with all the coding on the other chip, i know it comes natural to you, but me well it took me long enough to get my program working on one chip, never mind two, for the 12f chip i just wouldnt know where to satrt and polling well again over my head. i know all the information is available but it just looks like too bigger job for me to do... at my stage in the learning curve. Like one reply said it hurts the chaps head to read my code when it jumps in and out although i couldnt see that myself (it looped sent some data looped while sending more data then went on to the next pin) it must just be because i dont have that sort of brain although a HND in software engineering would suggest otherwise.

[Squibcakes]

Richardco,

I've been down this path before. Its pretty tough to multiplex NMEA data with a pic and not loose data from at least one source.

You would be better off learning the basics before tackling this project!

Trust me, I've waisted hours trying to do this


The only thing I can suggest to you is rather than use the pic to serial receive / send the data, use the pic to control a digital switch (isolated).

The switch would then cycle and pass through each talker's NMEA data. You could also use the PIC to detect the CR/LF at end of each string to trigger the digital switch to cycle to the next talker.

Cheers
J

[Richardco]

Thanks Squibcakes, i will bear that in mind, i am reading like a lunatic at the moment so i dont keep making myself look stupid and because i want to learn, this is not the last you will hear from me on this subject i am not willing to give up on it i just need to fill in a few more gaps in my knowlege. I am going to give the multiple pics a try in the mean time more as a learning tool.

[NavMicroSystems]

The only thing I can suggest to you is rather than use the pic to serial receive / send the data, use the pic to control a digital switch (isolated).

The switch would then cycle and pass through each talker's NMEA data. You could also use the PIC to detect the CR/LF at end of each string to trigger the digital switch to cycle to the next talker.

Squib,

I totally agree,
MUXing NMEA Data without loosing too much data and not adding too much delay is not one of the easiest tasks.

With the switch approach you'll need a MCU to control the switch.
And you have got to do a bit more than just triggering on "$" and "CRLF"
many talkers send out telegrams consisting of more than one sentence.
(I have actually not seen any talker sending out just a single sentence)
Every single sentence within that telegram starts with "$" and ends with "CRLF"
(Think of a GPS Unit)

By simply triggering on "$" and "CRLF" you will randomly get one sentences out of the telegram,
but this is most likely not the one you really need.

And due to undefined timing between different talkers transmissions will most likely be overlapping and you will still miss data.

So switching in a pure electrical sense does not really help.
What you need is some smart "store and forward" mechanism.

Sure,
if there aren't too many talkers to be MUXed and you can afford to miss one or the other sentence
a simple switch controlled by a simple timer (no MCU at all) would do.
But bear in mind that this solution will create some garbage on the MUXed bus (incomplete sentences).
I have seen Listeners being locked up by garbage on the bus.

[NavMicroSystems]

Having thought about the switching method...

With a limited number of talkers there is an option to avoid garbage on the bus.
(You will still miss some sentences, but if there are not too many talkers it may be acceptable if you don't need a realtime display.)

PSEUDO

MAIN:
Listen 1st talker
wait for the talker to become idle (time between two transmissions)
switch 1st talker to the bus
wait for talker to become active (or timeout if talker doesn't "talk" within a defined time)
wait for talker to become idle again
disconnect talker from bus

Listen to 2nd talker
wait for the talker to become idle (time between two transmissions)
switch 2nd talker to the bus
wait for talker to become active (or timeout if talker doesn't "talk" within a defined time)
wait for talker to become idle again
disconnect talker from bus

.
.
.
GOTO MAIN

[Richardco]

Ok im not good a wording what im thinking which may be why my coding is so bad but i will give it a go: i need a break from all this reading anyhow

would a pic be fast enough to do it like this, memory allowing:

memory locations from A01-A99 & B01- B99

read byte from pin 1 into memory location A01
is byte "crlf"
if yes move from memory location A** to tx & clear memory reset memory location to A01
if no increment memory location A01

read byte from pin 2 into memory location B01
is byte "crlf"
if yes move from memory location B** to tx & clear memory reset memory location to B01
if no increment memory location B01

start again

[Squibcakes]

Nav,

As you know, many talkers can send out different strings, and different versions of nmea... just to add to the complexity of NMEA.

My understanding was that Richard wanted to display two items on his echo sounder:

1. Windspeed/Direction ($--MWV) and
2. Position ($--GLL) or ($--GGA)

To keep things easy, he needs to turn off all other sentances coming out of both the GPS.

Instead of detecting the $ (start of string) and LF (end of string) he could just let the MCU just toggle every couple of seconds, say three.

That way, if a sentance does get chopped off, the echo sounder should just ignore the bad string.

The other thing to consider is the time it takes the echo sounder to bring up an alarm when an string input is missing.

This is how I would do it.

PS
(Thinking more about it, you could do this using a JK Flip Flop, and couple of Gates)

[NavMicroSystems]

Richardco,

A PIC is certainly fast enough to do that,
but you shouldn't start "recording" at a random point in the transmission of a talker if you don't want to record garbage.
You at least should (for each talker) to sit there and wait for a "Start of String" [$]

With a number of talkers memory may be an issue,
but you don't really need arrays of 98 bytes per talker.
Strip all unneeded bytes off the received sentence and just record a minimum of raw information from each talker.

The Transmit routine adds all bells and whistles to the raw data to make it a look like an NMEA sentence again.

i.e. for a sounder
If your display is meters, why record feet and fathoms?

[Richardco]

Hi there nav

quote:
A PIC is certainly fast enough to do that,

So the pic would be fast enough to read a byte from a pin then do some process on the byte then read the next pin and do the same and get back to the first pin in time for the second byte without missing any data?


quote:
but you shouldn't start "recording" at a random point in the transmission of a talker if you don't want to record garbage.

Well I understood that with nmea0183 1.5 that there was a checksum at the end of the sentence and the listener would just dump any information recieved with a bad checksum, but I was also thinking that i would make sure the multiplexor could be switched on before the talkers,as for stripping un-needed data i just overlooked it because i figured that the more the pic had to do then the slower it would become and that goes for any processing of the recieved data as well. Just read it in and send it out as it were

quote:
but you don't really need arrays of 98 bytes per talker.

I assumed that as a talker string could be upto 80 bytes long
i would give a little more memory but this could be changed if memory did become an issue,

[NavMicroSystems]

Richardco,

the problem simply is the "wait for sync" and "receive data" routine.

the data you will miss is the one that is being transmitted by other talkers while you are busy receiving data from the one talker.
(you can't receive from more than one talker at a time)

Letting the PIC do some work on the data once it has been received will not cause any timing issues.
You can do as much as program space and memory allows.

[Richardco]

Hmmm i think im not explaining it to you correctly lol

$WIVWT,177.2,R,3.0,N,1.5,M,5.5,K*55
$GPGLL,0010.90181,N,00010.90181,W,200253.49,A*1D

above are two sentences from a weather talker
and a gps these will be sent to pin 1 (weather)
and pin 2 (gps)

would the pic be fast enough to read

"$" from pin 1
then
"$" from pin 2
and then get back in time to read
"W" from pin 1
then
"G" from pin 2
and so on..

[NavMicroSystems]

No way!

And due to the fact there is no defined timing between the talkers it doesn't make much sense to me either.

[keithdoxey]

Hmmm i think im not explaining it to you correctly lol

$WIVWT,177.2,R,3.0,N,1.5,M,5.5,K*55
$GPGLL,0010.90181,N,00010.90181,W,200253.49,A*1D

above are two sentences from a weather talker
and a gps these will be sent to pin 1 (weather)
and pin 2 (gps)

would the pic be fast enough to read

"$" from pin 1
then
"$" from pin 2
and then get back in time to read
"W" from pin 1
then
"G" from pin 2
and so on..

I doubt it.

If both started at the same time you would get

1> $
2> G

If the second one started one character later you would get

1> $
2> $
1> I (the W would have gone whilst receiving $ from 2)
2> P ( the G would be lost when receiving I from 1)

and that is assuming that they stay in sync with start of character ocuring at the same time. If they were even slightly out then you would just receive total garbage.

Regards

[Richardco]

Ill take that as a no then shall I the pic is not fast enough to do that is more than i knew a moment ago thankyou