multiple serial comms

[Ricardoco]

Hi All
ok here goes i have a device that takes input (sentances) from several different peripherals using serial but only has one socket. the device is a marine gps/plotter/fish finder/weather indicator depending on what type of peripheral is conected to it. the data provided is in a format called IMEA 0183 an explanation of which is here :- https://www.windmill.co.uk/monitor52.html
My question is could a microcontroller take in serial data from several peripherals at once and send the collected data all together down one serial line to the device, the device is capable of understanding data from several devices at the same time but with only one serial line in, i would have to use a multiplexor which is available but the price is very prohibitive.

 

[upand_at_them]

First off, do the serial devices that are sending data...do they follow the serial/RS232 standard by having RequestToSend/ClearToSend and DataSetReady/DataTerminalReady lines?

And how many devices do you have?

If you can hold off all but one device from transmitting, you could create serial receive lines for every pin on the PIC through software.

Mike

 

[Ricardoco]

hmmm I have as many as 8 or as few as 1 devices. On examining the standard it often states RS232 but the peripherals have a data out line and a data ground and sometimes even a data in line and a ground, as for RTS, CTS, DSR, DTR. I dont think it uses them,each device can be a 'listener' to one device or a 'talker' to several devices.
Each sentence begins with the dollar character, $, and ends with
a carriage return and a line feed (as with printers i believe).
The maximum sentence length is 80 characters. Between the beginning and the end are identifier and data fields, separated by commas.
The first two characters following the $ comprise the "talker" identifier, describing the type of instrument
sending the data. For example $GP for GPS receiver or $ZA for atomic clock. Following the talker ID is a three letter code identifying the type of sentence. For example: DBT Depth below transducer.
An example of the type of data is: $GPGLL,5330.25,N,00215.31,W,134531,A*2D

The NMEA signal or output line needs to be
connected to the RS232 receiver or input line (line
2 on a 9-pin plug). The NMEA ground or earth needs
to be connected to the RS232 ground or earth (5 on
a 9-pin plug). The NMEA 0183 Interface Standard specifies the
communication settings as
Baud Rate: 4800
Data Bits: 8
Parity: None
Stop Bits: 1

By the way as the data stream is contant from each device (talker) it dosnt matter if while collecting data from one device (talker) the others are ignored as long as the data being collected and sent on to the listener has no gap greater than 5 seconds max

I wonder if that helps.

 

[eblc1388]

Eight 8-pin 12F683 PICs each monitoring and archiving the message from one particular device into its RAM.

A master PIC polls and retreives the message from each 12F683 and sends it out via its serial port.

 

[Ricardoco]

Eight 8-pin 12F683 PICs each monitoring and archiving the message from one particular device into its RAM.
A master PIC polls and retreives the message from each 12F683 and sends it out via its serial port.

well that sounds like just the job
and my usual reply tell me more please or a bit of psuedo would be nice :lol:

 

[eblc1388]

and my usual reply tell me more please or a bit of psuedo would be nice :lol:

No crystal needed for each 12F683 as they have a 1% accuracy internal OSC.

Software USART for each 12F683 reading message from device using one port pin and stores them into RAM.

For messaging between master and individual PICs one can use I2C protocol with a twist. Instead of sending a I2C address to call for individual PIC to response, I would simply use a hardwire enable from master PIC to each individual PIC. So common bus for all nine(8+1) PICs and individual enable line to each PIC from master.

I2C routines freely available on the internet.

So each PIC just monitor the enable port pin, if its enabled, sends the data. In other times, it just floats its SDA and SCL port pins. Sounds easy?

 

[Ricardoco]

As the data is headed by a $ sign would it not be possible to use one pic and move from port to port listening triggered by the $ sign and then forwarding the data to a port out of the pic to the device?

 

[eblc1388]

As the data is headed by a $ sign would it not be possible to use one pic and move from port to port listening triggered by the $ sign

Of course you can do it in software to read asynchronous messages on eight port pins. Infact it is really an interesting project indeed if one can pull it off.

I would not myself as it will cost me too much headache in terms of code reliability and error handling and eight 12F683s only costs me around £10. My arrangement is straight forward and easy to debug.

Just ask yourself, how much you would charge for producing an error free, well tested eight port software USART, which works correctly even if eight channels all have the "$" sign occur at the same time, not to mention each channel can each has slightly baudrate timing difference.

 

[Nigel Goodwin]

As the data is headed by a $ sign would it not be possible to use one pic and move from port to port listening triggered by the $ sign and then forwarding the data to a port out of the pic to the device?

The problem there is missing data on the other ports while you're reading one of them - particularly with a software UART!. You would need to use interrupt driven routines, and I'm still rather dubious about it's reliability?.

 

[Ricardoco]

Hmmmm so the program could not listen on a port for a pre determined time or untill it hears a $ and if it hears a $ store the data after the dollar untill it hears another dollar and then move on to listening to the next port
all the time reformating the data (adding the $ and the carriage return and line feed) and sending it out of another port?

The problem there is missing data on the other ports while you're reading one of them - particularly with a software UART!. You would need to use interrupt driven routines, and I'm still rather dubious about it's reliability?.

Thanks Nigel As for missing data that is not so bad. as each device has only to give data once every 5 seconds to the recieving device, so unless i am missing something? as long as all ports however many, are read and the data forwarded within 5 seconds, there may not be a problem..

If that makes any sence lol

here is an example of the data from one peripheral (weather instrument):

$WIMWD,90.0,T,90.0,M,5.0,N,2.6,M*5B
$WIMWV,90.0,T,5.0,N,A*19
$WIVWR,135.0,R,5.0,N,2.6,M,9.3,K*5B
$WIMTW,30.0,C*0E


here is an example of the data from two peripherals (weather instrument & GPS):

$GPRMC,110552.72,A,0000.10095,N,00000.10095,W,5.0,315.0,231105,0.0,W*59
$WIMWD,90.0,T,90.0,M,5.0,N,2.6,M*5B
$WIMWV,90.0,T,5.0,N,A*19
$WIVWR,135.0,R,5.0,N,2.6,M,9.3,K*5B
$WIMTW,30.0,C*0E


the data being sent can also contain a checksum for error correction or rejection at the recieving device end.

 

[eblc1388]

If each individual device is sending out the message repeatedly, then it is simple to just listen to one channel, wait until a $ is received and forwards the message to the listener.

Then one moves on to the next channel down the line. In actual fact, the PIC can even send the "$" to the listening device before it detects a valid "$" from one of the 8 individual devices.

If this is what you wants, then it is easily implemented because you are using one software USART instead of many. It is just the input pin has changed.

 

[Ricardoco]

If each individual device is sending out the message repeatedly, then it is simple to just listen to one channel, wait until a $ is received and forwards the message to the listener.

Then one moves on to the next channel down the line. In actual fact, the PIC can even send the "$" to the listening device before it detects a valid "$" from one of the 8 individual devices.

i think that is it.
so can you jot me down a bit of pseudo code?
or is that being cheeky.... :roll:

 

[eblc1388]

so can you jot me down a bit of pseudo code?
or is that being cheeky.... :roll:

OK. Sending to the listening device is easy once you have setup the correct baudrate on the PIC hardware USART. You just dump any 8-bit value into the Tx buffer and it will be sent. Initially send a "$".

Get hold of a software USART code routine from the internet and either:

1. modify the code to have it operates on a different input pin as per a variable value OR

2. repeat the code eight times using different port pin as input.

3. after the character is "capatured" via the routine, check for "$". Loop until found.

4. capture another character, check that it is not a "$" and then dump it into the hardware transmit buffer. Loop until "$" found.

5. wait a short while and send a "$". Moves on to next channel.

Is that OK?

 

[Ricardoco]

ok sounds good

Get hold of a software USART code routine from the internet

well ive been having a look around the web but i cant find an example in basic that i can go through so i can fully understand what is going on does anyone have any ideas or examples i may have a look at please.

 

[Nigel Goodwin]

ok sounds good

Get hold of a software USART code routine from the internet

well ive been having a look around the web but i cant find an example in basic that i can go through so i can fully understand what is going on does anyone have any ideas or examples i may have a look at please.

There are assembler routines in my tutorials.

 

[Ricardoco]

thanks nigel but i would like to keep away from assembler if i can until i am more confident.

i have jotted some pseudo code (of a sort) down to see if the structure is right before i start on the proper code. any input would be great.

input_pin = 0
output_pin = 1

start:
clear read_data
if input_pin = > 7 
then input_pin = 0

move data at input_pin to read_data

if read_data ="$" 
goto send_read

else
goto start

send_read:

move read_data to output_pin
clear read_data
read input_pin
move data at input_pin to read_data
if read_data = "lf"
then send read_data to output_pin 
increment input_pin
goto start

else
goto send_read

below is an image that may make things more clear.