RS232/UART Baud rate Conversion?
Ben Mok
I just wonder is there any simple method to do some RS232/Uart baud rate
conversion? Recently I need to connect a serial mouse(1200 baud) to a com
port of an embedded system, which can only be configured to 9600 baud for
slowest connection. The system is just a prototype, so the conversion can be
done at either the com or uart stage. Any hints will be much appreciated.
Mark A. Odell
news:a9jnle$o9...@imsp212.netvigator.com:
Do you mean auto-baud? If so, a search on Google should probably come up with
an example.
michael brown
Sounds like a good job for a PIC chip. If you step the 1200 up to 19200,
this will allow enough time to send the received byte during the received
bytes stop-bit time. Piece of cake. ;-)
michael
Ben Mok
rate convesion, in this case, 1200 to 9600 baud. My planned solution is also
to use a micro, a 8051 or PIC with two UART port to do it, as this is only
one of a kind demo prototype. I just wonder is there any simple circuit
tricks say a few discrete components to do the job.
Chris Pflieger
be minimal since you're going from 1200 to 9600.
--
Chris Pflieger
Design Engineer
Touchplate Technologies, Inc.
michael brown
> Ben Mok wrote:
> >
> > Thanks, guys. No, it is not auto-baud rate detection, but rather fixed
baud
> > rate convesion, in this case, 1200 to 9600 baud. My planned solution is
also
> > to use a micro, a 8051 or PIC with two UART port to do it, as this is
only
> > one of a kind demo prototype. I just wonder is there any simple circuit
> > tricks say a few discrete components to do the job.
> >
> There's no simple solution. It requires a uC and two UARTs. Lag should
> be minimal since you're going from 1200 to 9600.
I beg to differ here. This can be easily done on a PIC with no hardware
UARTS (16F84 for example).
Matthias Weißer
"Ben Mok" <be...@hotmail.com> wrote
Hi
i just opend my old Genius 3-Button-serial Mouse. There is a XTAL inside. Mybe
you can overclock ;-) the mouse by 8-times to reach the 9600Baud.
--
Matthias Weißer
matt...@matwei.de
http://www.matwei.de
Ppelectron
Yes you could come up with a hardware solution, but as in so many applications
it simply isn't worth it. It's easier, cheaper and faster to design a
microcontroller based solution. I reckon a 74 series logic based solution would
probably need between 5 and 10 chips. Personally, I wouldn't bother. Go for a
dual UART PIC or a Dallas with an 8051 core. Depends what tools you have
available and what you are used to designing with.
Norm Dresner
news:20020417162906...@mb-fs.aol.com...
Go with that advice. I remember designing a circuit back in the late '70s
to take two byte data from a uart: the first byte indexed a demultiplexer
which steered the second byte to its rightful destination. It was ugly, it
was complicated, and it was a bear to debug. Of course, once I got it
running, it could still be running for all I know. In 1978 the only things
I knew how to use were the 8080, 8085 and Z-80 CPUs. An 8051 -- or even a
PIC -- would have been a much easier solution.
Norm
Jim Granville
Before you throw silicon at this, first check to make SURE you cannot
get
the 9600 down to 1200.
The 'BIOS' may not init below that, but often you can init at 9600,
then
go direct to the BAUD divider registers, and load 1200 settings.
If you need HW, the 1200 baud is doable as SW uart, and 9600 in HW, so
any small uC with 1 UART, from a 89C1051U up, will do.
- jg
Mark A. Odell
$oj5.2...@typhoon.austin.rr.com:
From what I've seen of the TI MSP430 you could do this with no trouble, low
cost, and low power to boot.
William Meyer
says...
Try an AVR Mega128, which has the UARTs on-board. The software would be
trivial, from what you describe.
Bill
Blakely LaCroix
(Ppelectron) writes:
>Yes you could come up with a hardware solution, but as in so many
>applications
>it simply isn't worth it. It's easier, cheaper and faster to design a
>microcontroller based solution. I reckon a 74 series logic based solution
>would
>probably need between 5 and 10 chips. Personally, I wouldn't bother. Go for a
>dual UART PIC or a Dallas with an 8051 core. Depends what tools you have
>available and what you are used to designing with.
>
If it is just a one way transmission, you can use a normal 8051 with different
timers for receive and trasmit. Receive at 1200 baud on the UART and use
the transmitter to send at 9600. Use timer 1 or receiving and timer 2 for
transmit.
Blakely LaCroix
Minneapolis, Minnesota, USA.
RBP Clique member # 86.
The best adventure is yet to come.
Robert Gush
news:a9jnle$o9...@imsp212.netvigator.com...
If its only for a mouse, then it is fairly easy to do it with a PIC16F84 or
similar.
Use 8 samples per bit for the 1200 baud receive and send at 1 sample per bit
for the 9600 tx. Use the same interrupt for both the TX and RX.
I reckon about 50 lines of assembler code.
Regards - Robert
PS - a competition to see who can make the cheapest solution with the
smallest code? Maybe not...
Meindert Sprang
One uart will do. Run that on 9600. Run a software uart on 1200 baud, which
can easily be done on any micro.
Meindert
Meindert Sprang
news:20020417230316...@mb-cu.aol.com...
> In article <20020417162906...@mb-fs.aol.com>,
ppele...@aol.com
> (Ppelectron) writes:
>
> >Yes you could come up with a hardware solution, but as in so many
> >applications
> >it simply isn't worth it. It's easier, cheaper and faster to design a
> >microcontroller based solution. I reckon a 74 series logic based solution
> >would
> >probably need between 5 and 10 chips. Personally, I wouldn't bother. Go
for a
> >dual UART PIC or a Dallas with an 8051 core. Depends what tools you have
> >available and what you are used to designing with.
> >
>
> If it is just a one way transmission, you can use a normal 8051 with
different
> timers for receive and trasmit. Receive at 1200 baud on the UART and use
> the transmitter to send at 9600. Use timer 1 or receiving and timer 2
for
> transmit.
Darn! That's the best and easiest! He was talking about a mouse, that is one
way....
Meindert
Meindert Sprang
news:MPG.1727ba967...@news.earthlink.net...
Yeah, go on.... Why not use a PC with 2 serial ports :-)
He only needed to interface a mouse....
Meindert
Alf Katz
if it's only a oncer demo prototype as you say, just throw a PC in there and
say "this will be replaced by a $2 chip". Don't put in in too much NRE
until it's sold.
--
Regards,
Alf Katz,
alf...@removethis.ieee.org
"Ben Mok" <be...@hotmail.com> wrote in message
news:a9jnle$o9...@imsp212.netvigator.com...
Ben Mok
"Alf Katz" <alf...@removethis.ieee.org> 撰寫於郵件新聞
:3cbeb997$0$4304$afc3...@news.optusnet.com.au...
> if it's only a oncer demo prototype as you say, just throw a PC in there
and
> say "this will be replaced by a $2 chip". Don't put in in too much NRE
> until it's sold.
>
William Meyer
says...
>
> Yeah, go on.... Why not use a PC with 2 serial ports :-)
>
> He only needed to interface a mouse....
True enough, but if the embedded side is limited, and his choice of
mouse equally limited...
As the harder things get easier, we apply solutions to the simple things
which look like overkill. But embedded CPUs are cheap, while development
time is not.
I'm sure it could be done with some little PIC or a small AVR, and both
UARTs in software, but by the time he counted the hours in development
and debug, it would make the more expensive part seem pretty cheap. Of
course, if he needs to ship 10,000 pieces, then the dev time is worth
spending.
Bill
Rick Merrill
Used to do this without a UART at all, and for a multiplexer at that.
We sampled at 5x the maximum baud rate and located the center
point of the bits by matching the start-stop signals - it those days
it was like SETI!-)
RMM
Paul Keinanen
wrote:
>If it is just a one way transmission, you can use a normal 8051 with different
>timers for receive and trasmit. Receive at 1200 baud on the UART and use
>the transmitter to send at 9600. Use timer 1 or receiving and timer 2 for
>transmit.
Or use just a single 9600 Hz timer interrupt and sample the 1200 bit/s
stream with 8 samples/bit. If 5-8 samples are "0" then you have
received "0", if there are 5-8 "1" samples, then you have received
"1". However, if you have 4 "0" samples and 4 "1" samples, you
probably have messed up with detection of the falling edge of the
start bit.
In order to reduce the conversion delay, when you have received the
start, data and possibly parity bits and are starting to receive the
stop bit, you can already start sending the start bit on the 9600
bit/s side using the same clock interrupt. When the last sample of the
stop bit of the 1200 bit/s side has been received, you are just
sending the last data bit on the 9600 bit/s side, thus the stop bit on
the 9600 bit/s side can be sent only 1-2 ms after the end of the stop
bit on the 1200 bit/s side, compared to 12-13 ms if two separate PARTs
are used :-).
Paul
Meindert Sprang
> In article <3cbe654a$1...@news.nb.nu>, mhsp...@ANTIcustomwareSPAM.nl
> says...
> >
> > Yeah, go on.... Why not use a PC with 2 serial ports :-)
> >
> > He only needed to interface a mouse....
>
> True enough, but if the embedded side is limited, and his choice of
> mouse equally limited...
>
> As the harder things get easier, we apply solutions to the simple things
> which look like overkill. But embedded CPUs are cheap, while development
> time is not.
Come on! Use a '51, wich can use different baudrates for transmitting and
receiving. The whole initialisation code would be less than 15 assembly
instructions and the entire main loop would look like this:
wait: jnb RI,wait
clr RI
mov a,SBUF
mov SBUF,a
sjmp wait
Development time, huh? What development time....
Meindert
Ppelectron
>receiving. The whole initialisation code would be less than 15 assembly
>instructions and the entire main loop would look like this:
>
>wait: jnb RI,wait
> clr RI
> mov a,SBUF
> mov SBUF,a
> sjmp wait
>
>Development time, huh? What development time....
>
>Meindert
My thoughts exactly! We could have written the software 10 times over in the
time it has taken to discuss it!
William Meyer
says...
>
> Come on! Use a '51, wich can use different baudrates for transmitting and
> receiving. The whole initialisation code would be less than 15 assembly
> instructions and the entire main loop would look like this:
>
> wait: jnb RI,wait
> clr RI
> mov a,SBUF
> mov SBUF,a
> sjmp wait
>
> Development time, huh? What development time....
Referred to some of the other alternatives, such as hardware solutions.
I am not a '51 user, so I missed that alternative, but I agree, it's a
good one. OTOH, if the solution were for volume production, then a soft
UART on the 1200 baud side would allow even cheaper solutions.
Bill
The Happy Hippy
"michael brown" <n5...@nospam.earthlink.net> wrote ...
> > There's no simple solution. It requires a uC and two UARTs. Lag should
> > be minimal since you're going from 1200 to 9600.
>
> I beg to differ here. This can be easily done on a PIC with no hardware
> UARTS (16F84 for example).
I agree entirely, having successfully achieved 9600 to 250,000 baud rate
conversions ( PC serial to DMX-512 ) using such a PIC, just by bit banging.
At 1200 bps, you'll have 833uS to play with for each bit, which is a lot of
instructions with a 4MHz xtal.
Going up in baud rate is easy, going down adds the problem of having to
buffer data and stop the transmitter from sending as the buffer approaches
full.
jetmarc
> conversion? Recently I need to connect a serial mouse(1200 baud) to a com
> port of an embedded system, which can only be configured to 9600 baud for
> slowest connection. The system is just a prototype, so the conversion can be
> done at either the com or uart stage. Any hints will be much appreciated.
If you're willing to pay me, I'll develop you firmware for a PIC12C508(A). You
won't need external components (ie, no XTAL). You can add the PIC to your
embedded PCB right before the UART input. Small footprint SO-8 packages are
available. Check PIC12C508(A) pricing and make an offer (by email).
Marc