Searching \ for '[PIC]: Can I read 2 Serial ports Simultaneously' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ios.htm?key=serial
Search entire site for: 'Can I read 2 Serial ports Simultaneously'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Can I read 2 Serial ports Simultaneously'
2000\07\26@163411 by Kev

picon face
Is it possibly to read 2 Serial ports (1 RS-232 & 1 RS-485) both assumed to
be at 9600 baud plus do a constant A/D conversion?

What chip is suggested?

The RS-232 port will be updated 1 per second with NMEA GPS information.

The RS-485 port will be updated periodically probably between 1 a minute to
1 time a day.

The A/D I have no idea yet but atleast 240 hz.

I simply want to take all the inputed data & then create a data stream out
to a notebook PC.  Preferable out a RS-232 port but I'm not against a
parallel port either if that is easier.

Thanks,

Kevin Klopp
HKC Inc

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2000\07\26@180438 by David VanHorn

flavicon
face
At 04:32 AM 7/26/00 -0400, Kev wrote:
>Is it possibly to read 2 Serial ports (1 RS-232 & 1 RS-485) both assumed to
>be at 9600 baud plus do a constant A/D conversion?

Sure.. The 485 ends up as TTL anyway, so you have tons of options.
Me, I'd use a chip with a real uart for the 232, and if the budget allows,
a max3100 for the 485.
One int per char, per interface. max of 38400 ints/sec for full speed full
duplex on both ports.
Or, you could bit-bang the 485, but noise on the line could drive you nuts
with TONS of ints.. (which is why uarts exist :)

Taking a few hundred A/D samples a second is nothing. What you DO with them
might get interesting..


--
http://www.SpamWhack.com  A pre-emptive strike against spam
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

My transistor sings
with unintended parasitic
the smoke escapes

By Jeff Stout

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2000\07\26@214658 by Mitchell D. Miller

picon face
> Is it possibly to read 2 Serial ports (1 RS-232 & 1 RS-485) both assumed
to
> be at 9600 baud plus do a constant A/D conversion?

Well ... Scenix has an interrupt driven "virtual peripheral" that emulates 8
UARTS via software and I believe they can all run in excess of 9600 baud
simultaneously.  Not sure if a PIC has the oomph though.  I believe Scenix
runs their SX at 50 Mhz in turbo mode (1 clock = 1 instruction cycle) in
order to accomplish this.

-- Mitch

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2000\07\27@044458 by mike

flavicon
face
On Wed, 26 Jul 2000 17:02:03 -0500, you wrote:

>At 04:32 AM 7/26/00 -0400, Kev wrote:
>>Is it possibly to read 2 Serial ports (1 RS-232 & 1 RS-485) both assumed to
>>be at 9600 baud plus do a constant A/D conversion?
>
>Sure.. The 485 ends up as TTL anyway, so you have tons of options.
>Me, I'd use a chip with a real uart for the 232, and if the budget allows,
>a max3100 for the 485.
>One int per char, per interface. max of 38400 ints/sec for full speed full
>duplex on both ports.
>Or, you could bit-bang the 485, but noise on the line could drive you nuts
>with TONS of ints.. (which is why uarts exist :)
Once you have done one 9600 uart in software (on a timer int at 2x
baudrate), adding more input and/or output ports is pretty easy

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2000\07\27@110743 by mike
flavicon
face
On Wed, 26 Jul 2000 20:45:57 -0500, you wrote:

>> Is it possibly to read 2 Serial ports (1 RS-232 & 1 RS-485) both assumed
>to
>> be at 9600 baud plus do a constant A/D conversion?
>
>Well ... Scenix has an interrupt driven "virtual peripheral" that emulates 8
>UARTS via software and I believe they can all run in excess of 9600 baud
>simultaneously.  Not sure if a PIC has the oomph though.
But I'm sure it's a lot cheaper than eight MAX3100's!

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2000\07\27@115820 by David VanHorn

flavicon
face
> >simultaneously.  Not sure if a PIC has the oomph though.
> But I'm sure it's a lot cheaper than eight MAX3100's!

It depends on how much you have to do with the data as well... The max chips
unload the cpu, and almost completely remove timing constraints.

Good luck!

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2000\07\27@121818 by Kev

picon face
Thanks for the Suggestions!

Not a programing guru myself so anything that unloads programing headaches
is appreciated (FORTH is my prefered language).

Price point won't be a big issue as I think I will only be building 1 of
these.  Time to develope is an issue, of course it is needed yesterday.

Downloading the 3100 data sheet now....

Kev


> > >simultaneously.  Not sure if a PIC has the oomph though.
> > But I'm sure it's a lot cheaper than eight MAX3100's!
>
> It depends on how much you have to do with the data as well... The max
chips
> unload the cpu, and almost completely remove timing constraints.
>
> Good luck!
>
> --
> http://www.piclist.com hint: The PICList is archived three different
> ways.  See http://www.piclist.com/#archives for details.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2000\07\27@122653 by David VanHorn

flavicon
face
> Price point won't be a big issue as I think I will only be building 1 of
> these.  Time to develope is an issue, of course it is needed yesterday.
>
> Downloading the 3100 data sheet now....

Something you won't find on the datasheet:
When using multiple devices wire-ored to a single int, you will hit a
problem, in that it appears impossible to poll the uarts without taking data
from them. This will  cause you grief if a buffer is full, and you can't
take anymore.
Here's the secret: Abort the transaction. You can read in the first byte,
which has the status, and then de-select the chip if it's not the one that
interrupted you. This way, the data stays in the chip..
Apparently, they pretty much overlooked this mode of operation. The techs
that I talked to ax max were pretty confident that there was no way to avoid
taking the data..

I have working code for this, but it's AVR.

Good luck!

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2000\07\28@110327 by Dan Michaels

flavicon
face
Mitchell D. Miller wrote:
>> Is it possibly to read 2 Serial ports (1 RS-232 & 1 RS-485) both assumed
>to>> be at 9600 baud plus do a constant A/D conversion?
>
>Well ... Scenix has an interrupt driven "virtual peripheral" that emulates 8
>UARTS via software and I believe they can all run in excess of 9600 baud
>simultaneously.  Not sure if a PIC has the oomph though.  I believe Scenix
>runs their SX at 50 Mhz in turbo mode (1 clock = 1 instruction cycle) in
>order to accomplish this.
>


Looking at the scenix virtual peripheral code [which can be downloaded
from their website] makes for an interesting educational experience.

The main program runs off a fixed-period Timer0 interrupt loop, which
occurs every few usec [much too fast for a PIC]. All VPs are serviced
in sequence, and each has a dedicated RAM area for relevant variables,
and "divider" value which dictates how many loopcounts to wait before
servicing the particular VP.

Therefore, it is easy to service 8 s.w. UARTs, with each executing at
"different" baudrates. The main Timer0 loop is not synchronized with
any of the 8 RS-232 datastreams, per se - ie, there are no external
interrupts from the serial inputs - but by virtue of oversampling,
you get correct async operation. [I forget what the oversampling
ratio is, but it would be interesting to look at this value, with
respect to data reliability].

Also, with this scheme, you handle other ops, like A/D timing, using
the same Timer0 loop, plus the appropriate divider value. As written,
however, certain VPs, like I2C, shut down the TImer0 interrupt, and
mess up the overall timing. I believe std I2C rates are too fast for
the VP timing loop [even 50 MIPS has its limitations].

This scheme probably would work ok with a fast PIC for slower
baudrates - and certain many other activities. The problem with PIC
is that you have to deal with significant interrupt overhead [~20 instr],
whereas on scenix, the cpu context is automatically saved and restored
via special shadow registers in 1 clock.

best regards,
- Dan Michaels
Oricom Technologies
http://www.sni.net/~oricom
==========================

--
http://www.piclist.com hint: To leave the PICList
spam_OUTpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu>

2000\07\28@123704 by David VanHorn

flavicon
face
>
>This scheme probably would work ok with a fast PIC for slower
>baudrates - and certain many other activities. The problem with PIC
>is that you have to deal with significant interrupt overhead [~20 instr],
>whereas on scenix, the cpu context is automatically saved and restored
>via special shadow registers in 1 clock.

Could you tell roughly, how much of the CPU time they were leaving
available to do something with the data??

I like the int handling, is it vectored?  That's been one of my big gripes
about pics, the high int latency.
In the AVR, the ints are vectored, but you still have to save and restore
one register, so it's a 2 clock penalty.


--
http://www.SpamWhack.com  A pre-emptive strike against spam
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

My transistor sings
with unintended parasitic
the smoke escapes

By Jeff Stout

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam@spam@mitvma.mit.edu>

2000\07\28@132458 by Dan Michaels

flavicon
face
David VanHorn wrote:
>>
>>This scheme probably would work ok with a fast PIC for slower
>>baudrates - and certain many other activities. The problem with PIC
>>is that you have to deal with significant interrupt overhead [~20 instr],
>>whereas on scenix, the cpu context is automatically saved and restored
>>via special shadow registers in 1 clock.
>
>Could you tell roughly, how much of the CPU time they were leaving
>available to do something with the data??
>

Yeah, essentially *none* of it. VPs are a little different from
normal programming.  program =  VP = timer interrupt code.
The whole thing is basically one big interrupt service routine.

That's how it looks - but seriously, like any other program, you
get to use whatever is left over after servicing the interrupts.
I just looked at an example of 8 UART code, and they sample the
serial channels at 8x19200, or interrupt about every 6.5 usec,
or every 325 cpu clocks [at 50 mhz]. It looks like the IRQ code
for 8 VPs takes about 220 instructions - so looks like about 66%
in ISR, 33% outside. [I didn't parse the code, but that's how
it appears].
==================


>I like the int handling, is it vectored?  That's been one of my big gripes
>about pics, the high int latency.
>In the AVR, the ints are vectored, but you still have to save and restore
>one register, so it's a 2 clock penalty.
>

With the VPs, there is no vectoring needed, since only the TImer0
interrupt is used. Any other IRQs would totally mess up the VP timing.
As I indicated last time, the serial port pins are simply sampled
asynchronously at 8x baudrate, according to the divisor used on
Timer0, rather than triggered by external interrupts. You start
counting during the timer loop when the pin changes, and divide
down according to how fast you want to sample .....

VPs are a different way of thinking. It appears to me the idea for
the s.w. VP comes from my conception of how UART h.w. works - it sits
there in its own timing loop, oblivious to the rest of the world,
and doesn't actually synchronize to the signal in, but rather starts
"counting" when the signal_in changes. If the loop is fast enough,
say 8-16-64x max input rate, then it works fairly well.

- danM

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamKILLspammitvma.mit.edu>

2000\07\29@044225 by Snail Instruments

flavicon
face
>VPs are a different way of thinking. It appears to me the idea for
>the s.w. VP comes from my conception of how UART h.w. works - it sits
>there in its own timing loop, oblivious to the rest of the world,
>and doesn't actually synchronize to the signal in, but rather starts
>"counting" when the signal_in changes. If the loop is fast enough,
>say 8-16-64x max input rate, then it works fairly well.

I have implemented several 'virtual' serial ports in a very similar way on
PIC using sample rate equal 3 times the baud rate. Works reliably.

Josef

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]: PIC only [EE]: engineering [OT]: off topic [AD]: advertisements

2000\07\29@115840 by Mitchell D. Miller

picon face
> the same Timer0 loop, plus the appropriate divider value. As written,
> however, certain VPs, like I2C, shut down the TImer0 interrupt, and
> mess up the overall timing. I believe std I2C rates are too fast for
> the VP timing loop [even 50 MIPS has its limitations].

I've successfully implemented I2C, Serial I/O (ie: RS-232), and 7219 (LED
multiplexer) on a single 50Mhz SX18/AC.  Although I did not use Scenix's VP
as written.  If you break up the I2C i/o into stages, it's quite easy to
implement using this stragegy.  However, you end up not running the I2C bus
as fast as it can go.  I believe I was using a 100kHz interrupt, and there
were about 8 steps to performing an I2C I/Os.  By implementing this as a
state machine, it was quite easy to implement polling of the device between
writes, etc.

-- Mitch

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]: PIC only [EE]: engineering [OT]: off topic [AD]: advertisements

2000\07\29@121125 by Dan Michaels

flavicon
face
Mitchell Miller wrote:
>> the same Timer0 loop, plus the appropriate divider value. As written,
>> however, certain VPs, like I2C, shut down the TImer0 interrupt, and
>> mess up the overall timing. I believe std I2C rates are too fast for
>> the VP timing loop [even 50 MIPS has its limitations].
>
>I've successfully implemented I2C, Serial I/O (ie: RS-232), and 7219 (LED
>multiplexer) on a single 50Mhz SX18/AC.  Although I did not use Scenix's VP
>as written.  If you break up the I2C i/o into stages, it's quite easy to
>implement using this stragegy.  However, you end up not running the I2C bus
>as fast as it can go.  I believe I was using a 100kHz interrupt, and there
>were about 8 steps to performing an I2C I/Os.  By implementing this as a
>state machine, it was quite easy to implement polling of the device between
>writes, etc.
>

Yes, this is the way to go. Apparently scenix was too lazy to write
their original I2C VP so it would integrate well with the rest of the
VPs. But this does illustrate the major shortcoming with the overall VP
philosophy - namely, even if you have a blazingly fast uC, it still
bogs down when you try to do too much at the same time.

By the time you implement 4 or 5 s.w. VPs, emulating RS-232, A/D,
I2C, PWM, etc/etc, your code has become so slow, and the routines
so tightly coupled and interdependent, you might as well have used a
PIC with all these features built into the h.w. in the 1st place.
SX are great for one very fast VP, but you lose the edge quickly
as more are added.

- danM

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]: PIC only [EE]: engineering [OT]: off topic [AD]: advertisements

More... (looser matching)
- Last day of these posts
- In 2000 , 2001 only
- Today
- New search...