Searching \ for 'USARTs' 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/io/serials.htm?key=usart
Search entire site for: 'USARTs'.

No exact or substring matches. trying for part
PICList Thread
'[EE] Microcontroller with 4 USARTs and 40 pins'
2000\05\26@130144 by Edson Brusque

face
flavicon
face
Hello,

   someone knows if there's a microcontroller with 4 USARTs capable of
working at 31250bps? I need extra 24 I/Os minimum. One USB port would be a
plus. Also, I would need an A/D converter, but I could use an external one.

   Maybe a SCENIX can do 4 USARTs as virtual peripherals???

   Best regards,

   Brusque

2000\05\26@134517 by Chris Eddy

flavicon
face
Edson, I think that you want to check out the Rabbit 2000.  I have seen it
advertised in the likes of Circuit Cellar.

Chris Eddy

Edson Brusque wrote:

{Quote hidden}

2000\05\26@141039 by M. Adam Davis

flavicon
face
Perhaps if you give us a little more information we can help you out more.  If
you take an atmel or scenix micro you could fairly easily develop 4 software
UARTs if they are all running at the same speed.  The PIC probably wouldn't run
fast enough unless you are doing very little or no processing of the data.  (I
just mashed a 4800bps full-duplex software UART into a 16c54 running at 4MHz
with a small bit of data processing...  It took a /lot/ of planning...)

It is unlikely that you will find an 8-bit micro with 4 hardware UARTs (as a
hobbyist), so you probably should plan on finding one with one or two UARTs and
build the rest in software.  If I were in your shoes, I would build them all in
software.  If you run a scenix or atmel at 24 MIPs, you'll have exactly 768
instructions (scenix, varies for atmel) per bit time to run the UARTs and your
user process (at the specified 31.25Kbps).  Divide it by four (bit slicing) and
you end up with 192 instructions to read the state of four RX lines, change the
state of four TX lines, and then do some data processing.  It really would not
be too difficult.

-Adam

Edson Brusque wrote:
{Quote hidden}

2000\05\26@142939 by Dan Michaels

flavicon
face
Edson Brusque wrote:
.....
>>     someone knows if there's a microcontroller with 4 USARTs capable of
>> working at 31250bps? I need extra 24 I/Os minimum. One USB port would be a
>> plus. Also, I would need an A/D converter, but I could use an external one.
>>
>>     Maybe a SCENIX can do 4 USARTs as virtual peripherals???
>>

Scenix can easily do this, **BUT** you will have to go to 48 or
52-pin PQFP part - with tiny smt pads - to get 24 additional I/O lines.
No PLCC available. [or possibly do a multiprocessor with 18 & 28
pin parts - not all that hard to build off a single RS-232 host line].

And I suspect with the scenix, you actually could get the weird
31250 rate you indicate here - or any other weird baudrate imaginable.
But whatcha gonna talk to at that speed?
================

Adam Davis wrote:
>Perhaps if you give us a little more information we can help you out more.  If
>you take an atmel or scenix micro you could fairly easily develop 4 software
>UARTs if they are all running at the same speed.  The PIC probably wouldn't run
..........

I believe with the scenix VP route, the separate UARTs do *not* have
to be running at the same bps. The VPs all run off the same basic
timer interrupt, but each uses a different divider to index its
update rate.

cheers,
- Dan Michaels
Oricom Technologies
===================

2000\05\26@151309 by Andrew Seddon

picon face
There is a VP on the scenix site with I think 8 USART`s running not sure of
the speed but I know it is on a 50mhz SX28. If you were to get a new 100mhz
SX52/48 I am sure you could do pretty much everything in software, not sure
about the USB.

> Hello,
>
>     someone knows if there's a microcontroller with 4 USARTs capable of
> working at 31250bps? I need extra 24 I/Os minimum. One USB port would be a
> plus. Also, I would need an A/D converter, but I could use an external
one.
>
>     Maybe a SCENIX can do 4 USARTs as virtual peripherals???
>
>     Best regards,
>
>     Brusque
>

2000\05\26@161428 by Harold M Hallikainen

picon face
       Another approach is to use Maxim external uarts hung on a serial bus out
of the PIC.

Harold


FCC Rules Online at http://hallikainen.com/FccRules
Lighting control for theatre and television at http://www.dovesystems.com

________________________________________________________________
YOU'RE PAYING TOO MUCH FOR THE INTERNET!
Juno now offers FREE Internet Access!
Try it today - there's no risk!  For your FREE software, visit:
dl.http://www.juno.com/get/tagj.

2000\05\26@182255 by Edson Brusque

face
flavicon
face
> Perhaps if you give us a little more information we can help you out more.

   As I'm a musician, and my (piano) keyboard controller doesn't makes all
the tricks I would like it to do, I'm thinking in developing a MIDI
black-box that could do everything I want. Maybe I can sell hundreds of
units and make some money :)

> It is unlikely that you will find an 8-bit micro with 4 hardware UARTs (as
a
> hobbyist), so you probably should plan on finding one with one or two
UARTs and
> build the rest in software.  If I were in your shoes, I would build them
all in
> software.  If you run a scenix or atmel at 24 MIPs, you'll have exactly
768
> instructions (scenix, varies for atmel) per bit time to run the UARTs and
your
> user process (at the specified 31.25Kbps).  Divide it by four (bit
slicing) and
> you end up with 192 instructions to read the state of four RX lines,
change the
> state of four TX lines, and then do some data processing.  It really would
not
> be too difficult.

   I think I'll want to put 16 keys on the thing (8 I/Os for that), an LCD
(6 I/Os for that), four MIDI Ins plus four midi Outs (8 I/Os), and I would
like it to communicate with the PC with Paralell or USB. Even Serial at
115.200bps would do the job nicely. Well, this puts 22 I/Os plus PC
communication. A 48 or 52 pin Scenix at 50MHz seens to be a very good option
(I've took a look at SX documentation and it says it can run eight 19.2Kbps
UARTs using 13% of 50MHz). The hard thing will be to make an adaptor to use
it on a proto-board.

   I would also like to put 16 pots on it to control various things (like
volume, pan, reverb, modulation, etc).

   I would preffer to make it with PICs, but I don't think it's possible. I
don't want to expend money on another C compiler, debugger, etc...

   Atmel would also be a good option. What Atmel micros can do 24MIPS?

   Best regards,

   Brusque

2000\05\26@190523 by Andrew Seddon

picon face
>     I would preffer to make it with PICs, but I don't think it's possible.
I
> don't want to expend money on another C compiler, debugger, etc...

Try http://www.geocities.com/SiliconValley/Network/3656/c2c/c.html for a C
and Pascal compiler that will work with the 52/48. Also if you talk to Mr
Newton I am sure he will sort you out with a demo board and socket, I would
send you the layout for mine but it is pretty crappy in comparison.

2000\05\26@191144 by Edson Brusque

face
flavicon
face
Hello Dan,

> Scenix can easily do this, **BUT** you will have to go to 48 or
> 52-pin PQFP part - with tiny smt pads - to get 24 additional I/O lines.
> No PLCC available. [or possibly do a multiprocessor with 18 & 28
> pin parts - not all that hard to build off a single RS-232 host line].
>
> And I suspect with the scenix, you actually could get the weird
> 31250 rate you indicate here - or any other weird baudrate imaginable.
> But whatcha gonna talk to at that speed?

   31250bps isn't weird: 1,000,000 (instructions for second) / 31250 (bps)
= 32 (instructions for serial bit).

   I'm looking at an Atmel datasheet. It says the AT89C55 can do 33MHz, but
how much clocks does it takes to execute one instruction? Why few
manufacturers put this information on the datasheets??? 33Mhz equals to
33MIPS? Or 8,25MPIS? Or 2,75 MIPS???

   Regards,

   Brusque

'[PIC]: [EE]: Microcontroller with 4 USARTs and 40 '
2000\05\26@232352 by Bob Ammerman

picon face
Does the application require 4  _bi_directional UARTs? Or can some of your
MIDI ports be unidirectional (ie: how many MIDI ins and MIDI outs do you
need).  Bit banging the transmit side is _much_ easier than the receive
side. You could set up an interrupt source at the bit rate (31250) and
easily have time to blast out the bits. I would suggest, perhaps, the 18C
series chips, running at a 10MHz crystal, with the PLL x4 to get 10MIPS.
This would give you 320 instructions per bit time, which is nearly
'forever'.

Unfortunately, to receive you need to run your interrupt handler somewhat
faster than the bit time.  I have successfully built a software UART using a
interrupt 6x of the bit rate. I expect 5x would work pretty well.

So, you would have to take 1 interrupt every 64 instruction times. I'm
guessing about a 8 instruction time overhead in the interrupt handler (the
18C can be quite efficient at this) and perhaps 15 instructions per
interrupt per receiver. You could handle 5 transmitters by processing them
round-robin, one per interrupt (say another 10 instructions).

Thus, our interrupt budget would be about 8 (overhead) + 15*Number of
receivers + 10 instructions.

Assuming 2 receivers, this would take about 48 instructions, leaving you
with about 2.5 MIPS for 'task-level' code.

I really think this could be done on the 18C chips!

BTW: I have developed an 18C application that directly generates (no
hardware other than the PIC and 3 resistors) a full-screen animated NTSC
(monochrome) image -- this chip can really make things happen!

Bob Ammerman
RAm Systems
(high function, high performance, low-level software)

'[EE] Microcontroller with 4 USARTs and 40 pins'
2000\05\27@115818 by Dan Michaels

flavicon
face
Edson wrote:
.........
>> And I suspect with the scenix, you actually could get the weird
>> 31250 rate you indicate here - or any other weird baudrate imaginable.
>> But whatcha gonna talk to at that speed?
>
>    31250bps isn't weird: 1,000,000 (instructions for second) / 31250 (bps)
>= 32 (instructions for serial bit).
>

Only weird viz-a-viz the "usual" baudrates, like 19200, 38400, 57600,
etc. For local networks, anything is a go. But I'm not sure whether
a PC, if used as a host, could accommodate anything like 31250. Depends
upon the internal clocks and USART h.w.

The scenix s.w. VP could probably be massaged to accommodate both 31250
and 38400, for example, if you try hard enough. 50Mhz/38400 = 1302 and
50Mhz/31250 = 1600.

- Dan

2000\05\27@163855 by Sebastian Garcia

flavicon
face
Edson wrote:

| I'm looking at an Atmel datasheet. It says the AT89C55 can do 33MHz,but
|how much clocks does it takes to execute one instruction? Why few
|manufacturers put this information on the datasheets??? 33Mhz equals to
|33MIPS? Or 8,25MPIS? Or 2,75 MIPS???


If it don't say anything more, it may be the classic 8051's: one machine
cycle is formed by twuelve clock cycles, and the instruction cycle
depends on the particular instruction.


If You want more speed enhacement look at Dallas MCS-51 compatible, hi-speed
micros.

Regards,

S.-

2000\05\27@180739 by David VanHorn

flavicon
face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>If it don't say anything more, it may be the classic 8051's: one machine
>cycle is formed by twuelve clock cycles, and the instruction cycle
>depends on the particular instruction.
>
>
>If You want more speed enhacement look at Dallas MCS-51 compatible, hi-speed
>micros.


Or the AVR, at one xtal clock per instruction (a few take two). 8 mhz, but
that's 96 to an 8051 apparently.

- --
Are you an ISP?  Tired of spam?
http://www.spamwhack.com  A pre-emptive strike against spam!

Where's Dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.2 for non-commercial use <http://www.pgp.com>

iQA/AwUBOTBgoIFlGDz1l6VWEQJuNgCeIx9yDfY/6l0dtP5C7kDbPO2o5RsAmwVi
ZPWtc4N49sDH1YL4AotBu6qG
=Osxj
-----END PGP SIGNATURE-----

'[PIC]: [EE]: Microcontroller with 4 USARTs'
2000\05\28@070501 by Alan B Pearce

face picon face
>Unfortunately, to receive you need to run your interrupt handler somewhat
>faster than the bit time.  I have successfully built a software UART using a
>interrupt 6x of the bit rate. I expect 5x would work pretty well.

You get away with 4 samples per bit time if you are not doing it synchronous to
the bit edges. Many years ago before high speed async modems were commonly
available we used to send async data through synchronous modems, and could do it
with no errors if the async baud rate was a quarter of the sync modem rate.

2000\05\28@082711 by Bob Ammerman

picon face
Of course this depends on the quality of your signal.

This thread has got me to thinking, and coding, and I am pretty sure I've
come up with a way to get 4 in and 4 out at 31250buad on a PIC18CXX2 at 10
MIPS. The trick involves accumulating input samples on each channel and
processing them 5 at a time instead of one-by-one. This idea was inspired by
byte-at-a-time CRC algorithms. Basically you end up with a monster state
machine, about 70 states, with 32 (ie: 2^5) possible inputs for each state.
The state machine is then stored as one whopping big (about 8K) table. But
hey, what's 8K when you've got 32K on chip? :-)

Bob Ammerman
RAm Systems
(high function, high performance, low level software).

{Original Message removed}

'[EE] Microcontroller with 4 USARTs and 40 pins'
2000\05\28@171749 by Edson Brusque

face
flavicon
face
> >If it don't say anything more, it may be the classic 8051's: one machine
> >cycle is formed by twuelve clock cycles, and the instruction cycle
> >depends on the particular instruction.
> >If You want more speed enhacement look at Dallas MCS-51 compatible,
hi-speed
> >micros.
> Or the AVR, at one xtal clock per instruction (a few take two). 8 mhz, but
> that's 96 to an 8051 apparently.

   Ok, but beside the Scenix, there's no 8-bit microcontroller capable of
doing more than 20 MIPS???

   And what about the 16-bit micros? Can it be a good option for my
project? A US$10-20 microcontroller isn't very expensive to me if it can do
all I need on this project.

   Best regards,

   Brusque

2000\05\28@202332 by Byron A Jeff

face picon face
On Sun, May 28, 2000 at 06:21:24PM -0300, Edson Brusque wrote:
> > >If it don't say anything more, it may be the classic 8051's: one machine
> > >cycle is formed by twuelve clock cycles, and the instruction cycle
> > >depends on the particular instruction.
> > >If You want more speed enhacement look at Dallas MCS-51 compatible,
> hi-speed
> > >micros.
> > Or the AVR, at one xtal clock per instruction (a few take two). 8 mhz, but
> > that's 96 to an 8051 apparently.
>
>     Ok, but beside the Scenix, there's no 8-bit microcontroller capable of
> doing more than 20 MIPS???
>
>     And what about the 16-bit micros? Can it be a good option for my
> project? A US$10-20 microcontroller isn't very expensive to me if it can do
> all I need on this project.

A piece of advise. Stick to environments you know instead of striking out.
Especially when your striking out for more MIPS because you want them for
something that's easily done in hardware.

I'd advise sticking with PICs. Let me throw out a couple of suggestions.

1) I'm planning on using a Cirrus Logic CL-CD180 octart. Unfortunately Cirrus
Logic has obsoleted the part. In fact they've spun off their communcations line
into Basis Communications. I have a couple of samples and an incomplete
data sheet. If anyone has the pinout I'd really appreciate it. I liked the
part because of the number of serial ports and the fact that it came in a
84 pin PLCC package making it easy to use to hobby work. Basis Comm does have
an updated version the CL-CD1865. But it comes in a 100 pin PQFP. Not real
easy to prototype with.

2) My second choice was to build an intelligent UART out of a PIC. Specifically
for MIDI conversion of the stream into events with timestamps would be
very useful. Also having buffering so that the main processor can dump
events ahead of time and have the intelligent MIDI UART deliver them to the
channel at the appropriate time. Also doing MIDI channel mapping, splits and
volume control in the UART seems interesting. It's also interesting to consider
direct transmission of events from one UART to another bypassing the main
processor.

A single software channel can easily be handled by a 12C509 with a software
UART. Of course developing the UART code, the interface to the main processor,
(probably something I2Clike) would take some effort. But once it's done
any number of channels could be added to the system and the main system
wouldn't have to be uberpowered.


Maxim has an interesting discussion in their MAX3100 intro describing the
issues of software UARTs. You can find it here.

http://dbserv.maxim-ic.com/tarticle/view_article.cfm?article_id=53

The bottom line IMHO is that the traditional approach is better than the
Winmodem approach because you end up having a highly overpowered processor
just so that you can have the MIPS to bit bang UARTS. Just remember that
8 12C509's will give you 8 MIPS just for the UARTS. Think about the
distributed processing solution.

BAJ

2000\05\28@221341 by Bob Ammerman

picon face
There are some good ideas here, but you have moved the data movement problem
from SERIAL<->PIC to be PIC<->PIC. You're still going to need some hefty
horsepower to do the PIC<->PIC transfers. Remember, the main processor has
to handle all channels at once. MIDI waits for no man (nor PIC) :-)

Bob Ammerman
RAm Systems
(high function, high performance, low level software)

{Original Message removed}

'[PIC]: [EE]: Microcontroller with 4 USARTs and 40 '
2000\05\28@221344 by Bob Ammerman

picon face
This thread has fascinated me from the beginning. I was sure that it was
possible to do this on a PIC.

What I have come up with so far:

I have designed, and written the critical code for, a scheme permitting 5
full-duplex software UARTs. This code requires a timer-driven interrupt at 5
times the baud rate. Code path in the interrupt handler, counting all
overhead, with all 5 channels going full blast in both directions, is 55
instruction times max, 51 instruction times average. This drops down
somewhat if the channels are running at less than full speed.

The simulated UARTS sample the input at 5x the baud rate, and determine bits
using the majority vote of the center 3 samples for each bit.

They detect framing errors, and can handle receive data streams slightly
faster than the nominal rate (ie: the stop bit can be less than 5 samples
long, so the UART can slip properly to handle a  slightly overspeed input).

Both receive and transmit are double-buffered so that task level has an
entire byte time to handle a received character or prepare the next
character for transmission.

Relating this to the problem at hand:

On a 10MIP 18CXX2 chip (10MHz clock, PLL'd to 40MHz on chip), with a baud
rate of 31250, the interrupt rate would be every 64 instruction times. This
will leave at least 9 and on average 13 instructions between interrupts.

Thus, 'task level' code will get about 13/64 = 20% or so of the 10MIPs.  You
can get quite a bit done with the remaining 2 MIPS!

For anyone who is interested, the basic structure of the interrupt handler
is something like this (expressed in a combination of pseudocode and "C" to
make it easier to follow, but the real code is of course assembly):

send values computed by last interrupt for output bits to the hardware

fetch current values input bits from the hardware into 5 5-bit shift
registers, one per channel.

switch (phase)
{
case 0:
   phase = 1;
   compute next output bit for channel 0
   process last 5 input bits received by channel 0
   break;

case 1:
   phase = 2;
   compute next output bit for channel 1
   process last 5 input bits received by channel 1
   break;

case 2:
   phase = 3;
   compute next output bit for channel 2
   process last 5 input bits received by channel 2
   break;

case 3:
   phase = 4;
   compute next output bit for channel 3
   process last 5 input bits received by channel 3
   break;

case 4:
   phase = 0;
   compute next output bit for channel 4
   process last 5 input bits received by channel 4
   break;
}

The phrase 'compute next output bit for channel N' simply figures out what
start, data, or stop bit is to be sent.

The phrase 'process last 5 input bits received by channel N' involves using
the 5 input bits, treated as a 5 bit number, as an input to a large state
machine stored as a table in program memory. This will determine a new
state, and possibly an action to be performed (setting a bit in the receiver
register, or marking a byte received (correctly or with a framing error)).

Bob Ammerman
RAm Systems
(high function, high performance, low-level software)

'[EE] Microcontroller with 4 USARTs and 40 pins'
2000\05\29@102422 by Byron A Jeff

face picon face
On Sun, May 28, 2000 at 09:38:33PM -0400, Bob Ammerman wrote:
> There are some good ideas here, but you have moved the data movement problem
> from SERIAL<->PIC to be PIC<->PIC. You're still going to need some hefty
> horsepower to do the PIC<->PIC transfers. Remember, the main processor has
> to handle all channels at once. MIDI waits for no man (nor PIC) :-)

This is true to a point but you can gain a few advantages:

1) Many of the mid level PICs have hardware support for such transfers. A
16F87X could use its hardware USART or I2C module to do the transfers thus
eliminating the high powered need for software bit banging from the main
PIC. And while the auxillary PICs are stuck with the software bit banging
problem, their function is limited to a single channel. Thus you gain an
advantage because the aux processors are not trying to do everything in the
system for all channels, just limited functionality for a single channel.

2) Intelligent buffering can mitigate quite a few of the tight timing
contraints in the PIC to PIC transfers. In short the main processor can dump
events that it knows is going out to the intelligent UART before the actual
moment the event needs to be played. This happens often in a multichannel
MIDI situation because the primary usage is as a multitrack MIDI recorded
where the sequencer plays some or all of the prerecorded MIDI tracks while
the musician adds the next track to the sequence. The timing sequences of
the prerecorded tracks are known apriori and can be scheduled accordingly.

3) Compression can be utilized in the PIC to PIC transfer whereas with a
straight UART the exact data stream that's required for the end unit must
be sent to the UART. For example each event in the MIDI stream encodes a 4
bit channel number. However if an intelligent UART knows that it's only
going to output 1 channel, or possibly two because of a a keyboard split,
then the channel information isn't required at all in the PIC to PIC
transfer, potentially saving a ton of bits. Another example is that typically
in MIDI streams a NOTE OFF events is generated by sending a NOTE ON event
with a volume of 0, requiring 2 to 3 bytes in the actual MIDI data stream.
However we could easily compress a note off event into a single BIT in the
PIC to PIC stream, having the Intelligent MIDI UART (IMU) do the proper
expansion on output.

4) The potential of direct IMU to IMU communication can potentially alleviate
the latency caused on the real time streams that are being recorded. See
typically the controller generating the real time stream and the one playing
that realtime stream are not on the same IMU. For example I generate my
MIDI events using my Yamaha digital piano, but those events are played on
my Alesis Nanosynth or my old Roland MT32. So the transfer sequence is
Input IMU -> main processor -> Output IMU. This would require a low latency
main processor to turn the events around quickly. However if instead the
transfer can be Input IMU -> main processor and Output IMU, then the Output
IMU would get the event with lower latency and the main processor could
take more time recording the event because it's not obligated to turn the
event around to the IMU.

MIDI streams have structure. This structure can be exploited by an IMU
type system. But it requires something more than a dumb UART. This would be
the exact reason I'd look to a software periperal.

BAJ
>
> Bob Ammerman
> RAm Systems
> (high function, high performance, low level software)
>
> {Original Message removed}

2000\05\29@132333 by andy howard

flavicon
face
> From: "Dan Michaels" <spam_OUToricomTakeThisOuTspamLYNX.SNI.NET>
> Edson Brusque wrote:
> .....
> >>     someone knows if there's a microcontroller with 4 USARTs
capable of
> >> working at 31250bps? I need extra 24 I/Os minimum. One USB port
would be a
> >> plus. Also, I would need an A/D converter, but I could use an
external one.
> >>     Maybe a SCENIX can do 4 USARTs as virtual peripherals???
> Scenix can easily do this, **BUT** you will have to go to 48 or
> 52-pin PQFP part - with tiny smt pads - to get 24 additional I/O
lines.
> No PLCC available. [or possibly do a multiprocessor with 18 & 28
> pin parts - not all that hard to build off a single RS-232 host line].


> And I suspect with the scenix, you actually could get the weird
> 31250 rate you indicate here - or any other weird baudrate imaginable.
> But whatcha gonna talk to at that speed?

I'm guessing here, how about the world's second most common serial port,
MIDI?

'[PIC]: [EE]: Microcontroller with 4 USARTs and 40 '
2000\05\29@140350 by Bob Ammerman

picon face
Oops, I left out one more point.

The original requirement was for 4 channels, not 5. The interrupt rate
doesn't change as channels are deleted, but both maximum and average
interrupt handler times will go down.

For 5 channels: max is 55, average is 51 (2.0 MIPs available for task-level)
For 4 channels: max is 53, average is about 44 (3.1 MIPs available for
task-level)
For 3 channels: max is 51, average is about 38 (4.1 MIPs available for
task-level)
For 2 channels: max is 49, average is about 31 (5.2 MIPs available for
task-level)
For 1 channel: max is 44, average is about 22 (6.6 MIPs available for
task-level)

Bob Ammerman
RAm Systems
(high function, high performance, low-level software)

2000\05\29@140353 by Bob Ammerman

picon face
Points very well taken here. It is very good to take advantage of apriori
knowledge of the data stream.

Bob Ammerman
RAm Sytems
(high function, high performance, low level software)

{Original Message removed}

'[EE] Microcontroller with 4 USARTs and 40 pins'
2000\05\30@180234 by Erik Reikes

flavicon
face
Something else to check out is the I2C UART chips from Maxim.  They have a
family of chips that has either 232, 485, or logic level serial on one side
and SPI or I2C on the other.  Very cool part.  I also believe they have a
couple byte buffer to avoid overloading your micro.

You should be able to find them on their site by searching for 'uart'...




At 07:25 PM 5/26/00 -0300, Edson Brusque wrote:
{Quote hidden}

Erik Reikes
Senior Software Engineer
Xsilogy, Inc.

.....ereikesKILLspamspam@spam@xsilogy.com
ph : (858) 535-5113
fax : (858) 535-5163
cell : (858) 663-1206

2000\05\30@180241 by Erik Reikes

flavicon
face
Something else to check out is the I2C UART chips from Maxim.  They have a
family of chips that has either 232, 485, or logic level serial on one side
and SPI or I2C on the other.  Very cool part.  I also believe they have a
couple byte buffer to avoid overloading your micro.

You should be able to find them on their site by searching for 'uart'...




At 07:25 PM 5/26/00 -0300, Edson Brusque wrote:
{Quote hidden}

Erik Reikes
Senior Software Engineer
Xsilogy, Inc.

ereikesspamKILLspamxsilogy.com
ph : (858) 535-5113
fax : (858) 535-5163
cell : (858) 663-1206

2000\05\30@181727 by David VanHorn

flavicon
face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

At 02:59 PM 5/30/00 -0700, Erik Reikes wrote:
>Something else to check out is the I2C UART chips from Maxim.  They have a
>family of chips that has either 232, 485, or logic level serial on one side
>and SPI or I2C on the other.  Very cool part.  I also believe they have a
>couple byte buffer to avoid overloading your micro.

Max 3100A with internal 232 buffers?
I'm using four of them, along with the on-chip uart, in an AVR project.
The SPI is a little tricky in that it's 16 bit words, and I can't afford to
hang around and bit-bang, but I worked out a way to do the whole mess
interrupt driven.

The hardest thing to do is to poll them and see which one interrupted you
(without having to receive data), but all you have to do is abort the
transaction, and you can have the uart hold the data while you figure the
rest out.

My four have the ints wire-or, so I have to go look at all four's status
before I know who to start pumping data from.

Why am I so busy? 7200 calculations/sec involving polar-rectangular
conversions, a little DSP, and then rect-polar again. (in addition to
parsing the stat-mux protocol that gives me four external full speed full
duplex 4800 baud ports, plus an internal virtual port, and a control
channel, with the on-chip uart talking to a PC at 115200)

I'm almost 50% busy!

- --
Are you an ISP?  Tired of spam?
http://www.spamwhack.com  A pre-emptive strike against spam!

Where's Dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.2 for non-commercial use <http://www.pgp.com>

iQA/AwUBOTRWbYFlGDz1l6VWEQKhQACdFISm1LLbCpIEHbsmfFpWHzo/HAgAoO7s
m5Bsfxy9cAu0saUvjGyFtRFl
=tRIC
-----END PGP SIGNATURE-----


'[EE] Microcontroller with 4 USARTs and 40 pins'
2000\06\01@153955 by Keith Causey
flavicon
face
I like that part too (MAX3100 family) and have used it and its cousins on
several projects. The buffer is advertised to hold 8 bytes but I have never
been able to use it sucesfully. I don't think that a normal read is clearing
the buffer. It seems to assert it's contents to me twice.

> Something else to check out is the I2C UART chips from Maxim.  They have a
> family of chips that has either 232, 485, or logic level serial on one
side
> and SPI or I2C on the other.  Very cool part.  I also believe they have a
> couple byte buffer to avoid overloading your micro.
>
> You should be able to find them on their site by searching for 'uart'...
>
>
>
>
> At 07:25 PM 5/26/00 -0300, Edson Brusque wrote:
> >> Perhaps if you give us a little more information we can help you out
more.
> >
> >    As I'm a musician, and my (piano) keyboard controller doesn't makes
all
> >the tricks I would like it to do, I'm thinking in developing a MIDI
> >black-box that could do everything I want. Maybe I can sell hundreds of
> >units and make some money :)
> >
> >> It is unlikely that you will find an 8-bit micro with 4 hardware UARTs
(as
> >a
> >> hobbyist), so you probably should plan on finding one with one or two
> >UARTs and
> >> build the rest in software.  If I were in your shoes, I would build
them
> >all in
> >> software.  If you run a scenix or atmel at 24 MIPs, you'll have exactly
> >768
> >> instructions (scenix, varies for atmel) per bit time to run the UARTs
and
> >your
> >> user process (at the specified 31.25Kbps).  Divide it by four (bit
> >slicing) and
> >> you end up with 192 instructions to read the state of four RX lines,
> >change the
> >> state of four TX lines, and then do some data processing.  It really
would
> >not
> >> be too difficult.
> >
> >    I think I'll want to put 16 keys on the thing (8 I/Os for that), an
LCD
> >(6 I/Os for that), four MIDI Ins plus four midi Outs (8 I/Os), and I
would
> >like it to communicate with the PC with Paralell or USB. Even Serial at
> >115.200bps would do the job nicely. Well, this puts 22 I/Os plus PC
> >communication. A 48 or 52 pin Scenix at 50MHz seens to be a very good
option
> >(I've took a look at SX documentation and it says it can run eight
19.2Kbps
> >UARTs using 13% of 50MHz). The hard thing will be to make an adaptor to
use
> >it on a proto-board.
> >
> >    I would also like to put 16 pots on it to control various things
(like
> >volume, pan, reverb, modulation, etc).
> >
> >    I would preffer to make it with PICs, but I don't think it's
possible. I
{Quote hidden}


'[PIC]: different pics, different USARTs'
2003\01\05@232806 by nick stedman
flavicon
face
Why do different PICs have different max baud rates in asynchronous serial
mode? I've been using only the 16f877 up till now, but I just found out that
others are capable of faster speeds. Maybe the 877 is an older chip? but the
877a is the same.

Also Id like to attach many PICs to the same serial port on my computer and
individually address them. Are there any problems with this approach? For
example, I've read that if many servos are fed off the same signal then an
amplifier is needed. Could I use the same crystal to feed all of them?

Thanks
Nick Stedman

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

2003\01\05@235535 by Robert Rolf

picon face
The number of PICs you could address would depend on the drive current
of your PC serial port and the loading each PIC presents. Laptops generally
have lower than standard drive currents (in some cases so low they are
unable to drive a full length cable). Max spec'd drive is 30mA. Different
RS232 receive chips presents differing loads. For maximum possible
drive, I'd suggest using a 74HC14 with input clamp diodes and series
20k resistor. It's a lot cheaper than MAX232 or MC1489 and works just
as well in the sort of environment you'll likely use it.

nick stedman wrote:
{Quote hidden}

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

2003\01\06@090154 by Olin Lathrop

face picon face
> Why do different PICs have different max baud rates in asynchronous
serial
> mode?

Which PICs are you referring to?  Some of the older PICs like the 17
series don't have the "high speed" baud rate generator mode, but I thought
all the 16 and 18 series had the same baud rate generator architecture,
and therefore the same max baud rate as a function of the instruction
clock.

> I've been using only the 16f877 up till now, but I just found out that
> others are capable of faster speeds.

All the 16 and 18 family USARTs have Fosc/16 as their highest baud rate.
The 18 family can be run at 40MHz oscillator (using the internal 4x PLL),
whereas the 16 family generally goes to 20MHz.  The maximum baud rate of
course scales accordingly.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

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

2003\01\06@091605 by Spehro Pefhany

picon face
At 09:01 AM 1/6/03 -0500, you wrote:
> > Why do different PICs have different max baud rates in asynchronous
>serial
> > mode?
>
>Which PICs are you referring to?  Some of the older PICs like the 17
>series don't have the "high speed" baud rate generator mode, but I thought
>all the 16 and 18 series had the same baud rate generator architecture,
>and therefore the same max baud rate as a function of the instruction
>clock.

I was recently reminded that some of the older PICs (eg. PIC16C73) have
the "high speed mode" (BRGH = 1) but it doesn't work properly.

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
KILLspamspeffKILLspamspaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

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

2003\01\06@093328 by Olin Lathrop

face picon face
> I was recently reminded that some of the older PICs (eg. PIC16C73) have
> the "high speed mode" (BRGH = 1) but it doesn't work properly.

Really?!  I hadn't heard that before.  I used a 16C77 in several project a
few years ago and the high speed mode worked fine with a 20MHz oscillator
and 115.2Kbaud.  I would think that the 73 and 77 would have the same
USART silicon.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

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

2003\01\06@100611 by Spehro Pefhany

picon face
At 09:31 AM 1/6/03 -0500, you wrote:
> > I was recently reminded that some of the older PICs (eg. PIC16C73) have
> > the "high speed mode" (BRGH = 1) but it doesn't work properly.
>
>Really?!  I hadn't heard that before.  I used a 16C77 in several project a
>few years ago and the high speed mode worked fine with a 20MHz oscillator
>and 115.2Kbaud.  I would think that the 73 and 77 would have the same
>USART silicon.

Doesn't appear so. Here's the errata for the C73 Rev. A and the C77
Reva. A., no mention of the problem in the latter. Note that the C73
is obsolete, replaced by the C73B (which fixes the problem), but
lots of us have them still kicking around (two JW's for me).

http://www.microchip.com/download/lit/suppdoc/errata/er16c73.pdf

"When the USART (SCI) is configured in asynchronous
mode with the BRGH bit set, a high number of
receive errors may be experienced. For asynchronous
receive operations, it is recommended that the
USART be configured with the BRGH bit cleared."

http://www.microchip.com/download/lit/suppdoc/errata/80091a.pdf



Spehro Pefhany --"it's the network..."            "The Journey is the reward"
TakeThisOuTspeffEraseMEspamspam_OUTinterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

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

2003\01\06@121748 by nick stedman

flavicon
face
I made an mistake!

In the data sheet for the 16f877. The fastest listed speed is 57.6k which is
different than other data sheets which list higher baud rates. I thought
these listed speeds were all that was available. Now I see that much faster
speeds can be acheived by lowering the SPBRG value...sorry for the
confusion.
Nick


on 1/6/03 9:01 AM, Olin Lathrop at olin_piclistEraseMEspam.....EMBEDINC.COM wrote:

{Quote hidden}

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

2003\01\06@144436 by Dwayne Reid

flavicon
face
At 09:14 AM 1/6/03 -0500, Spehro Pefhany wrote:

>I was recently reminded that some of the older PICs (eg. PIC16C73) have
>the "high speed mode" (BRGH = 1) but it doesn't work properly.

Later revisions to those part numbers fixed that problem.  For example,
both the 16c73 and 16c73a have the BRGH=1 problem but it was fixed in the
16c73B.  I am not aware of any PICs later than the 16c6x / 16c7x family
that had that particular problem.

dwayne

--
Dwayne Reid   <RemoveMEdwaynerspam_OUTspamKILLspamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 18 years of Engineering Innovation (1984 - 2002)
 .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-
    `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.

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

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