Multiplex serial data

[Squibcakes]

Has anybody used a pic to multiplex input serial data?

Cheers

[Dwayne]

Hello Squibcakes,

Squibcakes>>Has anybody used a pic to multiplex input serial data?<<

Could you give a example?


I am working (right now), on the software for Serial communication to a LCD. With using only 1 pin, the ability to control a LCD. I have most everything working now, I am busy figuring the best way to have a "timeout" timer, so that if the data does not come through the whole way, the program will return to "Beginning Receive" mode. (like receive 7 bits, instead of 8).

I dont' want to "RESET" the chip, I only want to go to a certain part of my program (Like a beginning Loop).

Though I doubt if I need the "Beginning Receive mode", I sure like to "safeguard" for it.

By checking the first Byte you receive, you can tell your processor to do different things. (if it is equal to 255, tell the processor to turn on the "Command" pin to a LCD, instead of the pin being a data pin".

I maybe be misunderstanding what you are saying. If I am, I am sorry.

Dwayne

[Squibcakes]

Hmm Dwane,

What I meant was, Is it possible to receive two sets of serial data into a pic, then combining that data and then transmit the combined data?

Ideally all data will be received and transmitted at 4800 bd.

Cheers

[Melanie]

Not if everything's at the same baud rate... think about it... for evry two bytes you're receiving, you'll transmit only one, therefore you're going to be building up a backlog of data at a rate of one byte every two milliseconds (based on your 4800 baud) and pretty soon you'll run out of buffer RAM. On top of that you'll need Hardware USART for each receive channel because you won't be able to have multiple software (SERIN, SERIN2) inputs because as the PIC is grabbing data from one, you'll be losing bits from the other.

[Dwayne]

hello Squibcakes

Squibcakes>>What I meant was, Is it possible to receive two sets of serial data into a pic, then combining that data and then transmit the combined data?<<


Ouch...Both pins working at the same time...I know these chips are powerful, but....

Not that I know of. the Chip will be working with one pin, and forgetting the other. etc. I was thinking you were trying to receive two different packets on the same pin, combining these packets (or instructing the Chip to do different operations based upon that packet). Sorry for my incorrect assumption.


SquibCakes>>Ideally all data will be received and transmitted at 4800 bd.<<

If you make each pin work separately (NO two pins receiving data at the same time), you can receive on separate pins. This also means your transmit will also have to be done when Neither of the two receive pins are busy.... Maybe a rotation type pattern could be done... Receive one pin, Receive second pin, then transmit. Loop back.

Dwayne

[Squibcakes]

Hi,

Thankyou both for your replies. I see your points that the PIC has it's limits.

I have seen commercial products out there that use ATMEL chips for this kind of purpose. They receive data from up to four different sources and then combing the data strings into one.

I was hoping to build an el-cheapo version using a pic to do the same thing as I have no experience with ATMEL.

Cheers

[NavMicroSystems]

@ Squibcakes

what you are after looks a bit like a Multiplexer for NMEA-Data.
I have solved that problem the following way:

As there is no defined timing between the different Talkers
and I didn't want to miss sentences (i.e. two devices are talking at the same time)
I used one 12F629 per serial input line.
As the 12F doesn't have enough memory to store the full seetence I isolate the information bytes I need and skip all the rest.

An aditional PIC (12F or 16F) polls the "receivers", assembles the "combined" sentence and sends it out on one single serial line.

This solution offers high flexibility at about $2 per Talker.

rgds

[Squibcakes]

Hi Nav.

Your right, this is for NMEA data.

Using your design below, did you find that the "receivers" missed data while they were communicating with the talker?

Cheers

[NavMicroSystems]

Originally posted by Squibcakes
Hi Nav.

Your right, this is for NMEA data.

Using your design below, did you find that the "receivers" missed data while they were communicating with the talker?

Cheers

Hi Squib,

I will post details within the next days, I'm a bit busy at the moment.

rgds.

[NavMicroSystems]

Hello Squib,

My experience is the Talkers send out about 1 sentence per second.
If there are two Talkers with similar "timing"
the transmissions will overlap almost all the time,
this is why I used one receiver per talker.
The receiver waits for the "$" skips all unneeded bytes
and stores the wanted bytes.
(The variable will always be overwritten with latest received data)

So far you can be sure to "catch" all transmitted data from the Talker.


When I said the Multiplexer polls the Receivers that was not
correct, it actually waits for data from the Receiver.

The Receivers send data right after reception

Let's assume a Talker transmits 80 bytes every second.
This will take 150ms per Talker and sentence

assuming you have two talkers and the full blown combined sentence consists of 160 bytes
it will take about 300ms to send that data out.

I'm using a two wire connection Receiver to Multiplexer
(a Data line and a Handshake (BUSY) line)
As soon as a Receiver has data ready to be send to the Multiplexer
it checks the BUSY status. If CLEAR
it sets BUSY and sends it's data (including a RECEIVER ID)
and clears BUSY
if BUSY is not CLEAR it waits max 150ms for BUSY to become clear
and does the job as described above.

Given the "Sentence-Size" and "Timing" described,
you have plenty of time to deal with the data without loosing any single byte.

I have stripped all unneeded Bytes from the sentences so that the "combined-sentence"
is even less than 80 bytes per talker (Even GPS-Data).

[NavMicroSystems]

@SQUIBCAKES


check PM