'16C84@4Mhz, 9600 bauds'
Julio Cesar de Almeida Maia
|>From G.J. Flanagan <NEWCASTLE.AC.UK> G.J.Flanagan
>If the processor you used is anything like the 16c54 for serial
>communications you have two problems. First, the 5volt RS232 expects an
>RS232 converter to raise the signal to 12 volts AND to INVERT it.
Sure. I'm using max232.
>However, not only are the 5volt signals upsidedown, but I also needed to
>alter the clock constants by more than I would have expected by the
>change I made in clock frequencies. I would recomend a quick look with
>an oscilloscope is called for here.
That's the point. AN510 from Microchip describes a simple algorithm for
half duplex async communications for the 15c5x family, without using
rtcc for timing. But I just don't get it works with 16c84, 4Mhz,
9600 bauds. AN555 describes an interrupt driven communications utility
for 16c6x family. It works reasonably well just at 1200 bauds. In my
application, an algorithm like that of AN510 would be fine. Since it's
time constants be tuned. My great problem is that I don't own an
oscilloscope. Debug this kind of thing is something painful in this
situation. If someone here did 16c84, 4Mhz, works at 9600 bauds, please
let me know how.
>My great problem is that I don't own an
>oscilloscope. Debug this kind of thing is something painful in this
I have a scope and it was still painfull! What helped me figure my problem
out was using the RC oscillator mode with a variable resistor. Then,
observing the frequency at clock/4 at osc2/pin 15, vary the frequency up and
down until I saw legible characters on my computer terminal. This told me if
I was high or low with time constants. For receive, my application sets
output port bits at the same time it receives them, echoing back data to my
terminal. Lately, for other reasons I've used MPSIM; it led to more grief.
|> From MITVMA.MIT.EDU Wed Nov 15 05:46:35 1995 owner-piclist
> Date: Wed, 15 Nov 1995 05:43:37 -0600
> From: Scott Stephens <PYROTECHNICS.COM> stephnss
> Subject: Re: 16C84@4Mhz, 9600 bauds
> >My great problem is that I don't own an
> >oscilloscope. Debug this kind of thing is something painful in this
> I have a scope and it was still painfull! What helped me figure my problem
> terminal. Lately, for other reasons I've used MPSIM; it led to more grief.
> Good luck.
Use MPSim. It will tell you exact cycle counts for your transmit loops,
and exact cycle counts for your receive loops, too. Unless you're running
interrupts, you should have no problems finding out exactly (and I mean
within a microsecond) how long your bit timing is.
Timing one bit at 9600 baud, 4 MHz crystal will take you 104 instruction cycles.
That won't hurt.
Okay, maybe you'll have problems if you insist on full symbolic debugging
and are afraid of hexadecimal. But you should be able strip out the core of
your RS-232 transmit routines and verify their timing very accurately.
Alright, I will admit I borrowed a 'scope and verified my timings. So now I can
assure you that MPSim is accurate :) (More accurate than the 1-3% error
often involved in measuring a timing signal with a 'scope).
Tim Braun | Voice: 204-942-2992 ext 228
Continental Healthcare Systems Canada | FAX: 204-942-3001
1900-155 Carlton St | Email: chs.mb.catim
Winnipeg, Manitoba, Canada R3C 3H8 | www: http://www.chs.mb.ca/~tim/home.html
> Alright, I will admit I borrowed a 'scope and verified my timings. So now I
> assure you that MPSim is accurate :) (More accurate than the 1-3% error
> often involved in measuring a timing signal with a 'scope).
Though if you have a calibrated function generator and you want to time
your program's loop execution to ensure that it's correct, put a periodic
signal from your program on one scope trace and your function generator
output on the other. Then see if they drift. Easy way to get VERY accurate
More... (looser matching)
- Last day of these posts
- In 1995
, 1996 only
- New search...