Looking for simple way to interface BCD to serial (RS232)
RFI-EMI-GUY
the LED also has four Binary Weighted outputs (1,2,4,8) and three
address pins for 100's, 10's and units. I want to drive a FIFO UART of
some sort to output an RS232 stream so that this device can update a
software program. Baud rate 300 to 4800 range would be nice if possible.
The updates are about 300/second
Is there a real simple hardware FIFO UART that can do this without a lot
of extra hardware. I don't want a software fix unless I can do it in
PicAxe and can find code written.
Off the shelf products OK I don't want to reinvent the wheel.
--
Joe Leikhim K4SAT
"The RFI-EMI-GUY"�
"Use only Genuine Interocitor Parts" Tom Servo ;-P
don
> I have a device that has a three digit LED display. The chip that drives
> the LED also has four Binary Weighted outputs (1,2,4,8) and three
> address pins for 100's, 10's and units. I want to drive a FIFO UART of
> some sort to output an RS232 stream so that this device can update a
> software program. Baud rate 300 to 4800 range would be nice if possible.
>
> The updates are about 300/second
>
> Is there a real simple hardware FIFO UART that can do this without a lot
> of extra hardware. I don't want a software fix unless I can do it in
> PicAxe and can find code written.
>
> Off the shelf products OK I don't want to reinvent the wheel.
>
don
John Fields
wrote:
>I have a device that has a three digit LED display. The chip that drives
>the LED also has four Binary Weighted outputs (1,2,4,8) and three
>address pins for 100's, 10's and units. I want to drive a FIFO UART of
>some sort to output an RS232 stream so that this device can update a
>software program. Baud rate 300 to 4800 range would be nice if possible.
>
>The updates are about 300/second
>
>Is there a real simple hardware FIFO UART that can do this without a lot
>of extra hardware. I don't want a software fix unless I can do it in
>PicAxe and can find code written.
>
>Off the shelf products OK I don't want to reinvent the wheel.
---
The way I'd do it would be to broadside load a 10 bit parallel-in
serial-out shift registers with the BCD data, the digit data, a stop and
a start bit, and then shift the data out serially to the RS-232 input of
whatever's updating your software program.
If the broadside data into the shifter is updating at about 300Hz,
that's about 3.33ms, so to shift it all out before the next update comes
along would require a bit clock at least 10 times faster than that, or
about 333�s/3.3kHz.
Duck soup, maybe. ;)
What's the chip that's driving the display?
JF
RFI-EMI-GUY
I think you are asking the specs of the driving chip? Its an ICM7217IJI
Common Cathode 4 LED Display/Programmable Up/Down Counter. The BCD I/O
pins and the segment drivers b, d and f (d1, d2, d3) used to select
100's. 10's and units (I may have order reversed).
RFI-EMI-GUY
Its an ICM7217IJI Common Cathode 4 LED Display/Programmable Up/Down
Counter. The BCD I/O pins and the segment drivers b, d and f (d1, d2,
d3) used to select 100's. 10's and units (I may have order reversed).
--
Joerg
That will not be so trivial because this is a chip that drives the LED
in muxed fashion.
--
Regards, Joerg
http://www.analogconsultants.com/
"gmail" domain blocked because of excessive spam.
Use another domain or send PM.
Martin Riddle
"Joerg" <inv...@invalid.invalid> wrote in message
news:7pqjft...@mid.individual.net...
> RFI-EMI-GUY wrote:
>> don wrote:
>>> RFI-EMI-GUY wrote:
>>>> I have a device that has a three digit LED display. The chip that
>>>> drives the LED also has four Binary Weighted outputs (1,2,4,8) and
>>>> three address pins for 100's, 10's and units. I want to drive a
>>>> FIFO UART of some sort to output an RS232 stream so that this
>>>> device can update a software program. Baud rate 300 to 4800 range
>>>> would be nice if possible.
>>>>
>>>> The updates are about 300/second
>>>>
>>>> Is there a real simple hardware FIFO UART that can do this without
>>>> a lot of extra hardware. I don't want a software fix unless I can
>>>> do it in PicAxe and can find code written.
>>>>
>>>> Off the shelf products OK I don't want to reinvent the wheel.
>>>>
>>> Do you docs on the outputs ?
>>>
>>> don
>>
>>
>> I think you are asking the specs of the driving chip? Its an
>> ICM7217IJI Common Cathode 4 LED Display/Programmable Up/Down Counter.
>> The BCD I/O pins and the segment drivers b, d and f (d1, d2, d3) used
>> to select 100's. 10's and units (I may have order reversed).
>>
>
> That will not be so trivial because this is a chip that drives the LED
> in muxed fashion.
>
There are separate BCD outputs, in addition to the LED drivers abcdefg.
So he could use the muxs to latch the bcd data into shift registers.
After 16 bits are latched, clock them out with start and stop bits.
Cheers
don
So my answer is "use a PIC".
As long as there is a way to sync with the first digit, that with would
be easy.
don
Martin Riddle
<don> wrote in message
news:Kq-dnfM2ZeS7taXW...@forethought.net...
Datasheet <http://www.intersil.com/data/fn/fn3167.pdf>
Sync the digits with the Mux outputs.
Cheers
Jan Panteltje
<marti...@verizon.net> wrote in <hh98b5$c9l$1...@news.eternal-september.org>:
Replace the whole chip by a PIC with a RS232 output.
MooseFET
> I have a device that has a three digit LED display. The chip that drives
> the LED also has four Binary Weighted outputs (1,2,4,8) and three
> address pins for 100's, 10's and units. I want to drive a FIFO UART of
> some sort to output an RS232 stream so that this device can update a
> software program. Baud rate 300 to 4800 range would be nice if possible.
>
> The updates are about 300/second
>
> Is there a real simple hardware FIFO UART that can do this without a lot
> of extra hardware. I don't want a software fix unless I can do it in
> PicAxe and can find code written.
I think it would be easier without the FIFO UART. You just want a
signal that looks like the RS-232. You don't really need a RS-232
receive function at all unless you want to use it to set the Baud
rate.
John Fields
wrote:
---
According to the schematic, the segment drivers are only used to drive
segments and the digit drivers are used to select which digit is being
driven, multiplexed at 25% duty cycle.
So, if you were to do something like this:
ICL7217
. +------+
. | D1|--------------------------------------+
. | D2|-----------------------------------+ |
. | D3|--------------------------------+ | |
. | D4|-----------------------------+ | | |
. | I/O1|--------------------------+ | | | |
. | I/O2|-----------------------+ | | | | |
. | I/O4|--------------------+ | | | | | |
. | I/O8|-----------------+ | | | | | | |
. +------+ | | | | | | | |
. U1 | | | | | | | |
. +------------------------+
. | Dh Dg Df De Dd Dc Db Da|
.CLK>--+-----------------|> |
. | |____ | U2
.LOAD--|-+--------------O|LOAD 74HC165 |
| | | |
. | | +--|Sin Qh|--+
. | | | +------------------------+ |
. | +------------|----------------------------+ |
. +-|------------|--------------------------+ | |
. | | HC74 | | | | HC74
. | | +------+ | | | | +------+
. | +--|R Q|--+ | | +----|D Q|-->OUT
. +----|> | | +------|R |
.Vcc>----+--|R | +--------|> |
. +--|D | Vcc--|S |
. +------+ +------+
U3A U3B
Then, when LOAD went low, U3 would generate a start bit, U2 would hold
the segment and digit data, and U3A would generate the stop bit, all of
which would be shifted out of U3B-Q at a rate determined by CLK.
According to page 6 of the 7217 data sheet, when LOAD COUNTER goes
3-state, the 4 bit I/O port will output BCD segment data peculiar to one
of the four digits when that digit line go high, so differentiating the
low-going edge of the digit pulses to load data into U2 and the start
and stop bits into E3 would look like this:
________
DIGITn_____| |_______________
_____ ________ ______________
DATAn _____|________|______________
____ ______________ _____________
LOAD |_|
_______________ _______________
DATAl_______________|_______________
After loading the parallel data into U2 and setting up the start and
stop bits, serial data in the registers would look like this, LSB on the
left:
____ ______________ _____________
LOAD |_|
______________ __ __ __ __ __ __ __ __ __________
SD |__|__|__|__|__|__|__|__|__| \
/ Da Db Dc Dd De Df Dg Dh \
START STOP
Notice that the numerical data as well as the digit ID is embedded in
the frame, so it should be easy for your software to sort out what's
what as data comes rolling in
Next, you'll need to generate a LOAD pulse when any of the digit lines
goes low, and you can do that like this:
Vcc
|
[10K]
+-------------A |
+-----+ | +-----+ NAND Y--[<1N4148]--+
DIGIT1>------|D Q|-+-|D Q| +--B |
| _| | _| | |
CLK>-------+-|> Q| +-|> Q|O-+ |
| +-----+ | +-----+ |
+---------+ |
| |
| +-------------A |
| +-----+ | +-----+ NAND Y--[<1N4148]--+
DIGIT2>----|-|D Q|-+-|D Q| +--B |
| | _| | _| | |
+-|> Q| +-|> Q|O-+ |
| +-----+ | +-----+ |
+---------+ |
| |
| +-------------A |
| +-----+ | +-----+ NAND Y--[<1N4148]--+
DIGIT3>----|-|D Q|-+-|D Q| +--B |
| | _| | _| | |
+-|> Q| +-|> Q|O-+ |
| +-----+ | +-----+ |
+---------+ |
| |
| +-------------A | ____
| +-----+ | +-----+ NAND Y--[<1N4148]--+-->LOAD
DIGIT4>----|-|D Q|-+-|D Q| +--B
| | _| | _| |
+-|> Q| +-|> Q|O-+
| +-----+ | +-----+
+---------+
The dflops are HC174's and the nands are HC00's
JF
John Fields
>. | +--|S Q|--+ | | +----|D Q|-->OUT
>. +----|> | | +------|R |
>.Vcc>----+--|R | +--------|> |
>. +--|D | Vcc--|S |
>. +------+ +------+
> U3A U3B
---
Oops...
'R' at the top left of U3A should be S(ET), as corrected above.
JF
petrus bitbyter
"RFI-EMI-GUY" <Rhyo...@NETTALLY.COM> schreef in bericht
news:4b3815d7$0$4949$9a6e...@unlimited.newshosting.com...
Hmm... So 300 updates/s * 3 digits * 10 bits makes 9000bps. Even 4800Bd will
not be enough you will need at least 9600Bd.
Meanwhile, the scanrate is some 2500 digits/s. To send them all you would
need at least 25kbps. There is no need to send them all but you will need to
do some buffering and selection at the transmitting side.
Another complication is the updating itself. For all I can see there is no
other way to detect an update but finding some digit(s) changed. That's to
say unless you can catch the /STORE signal. But even then there seems no way
to predict at what time during the scanning of the three digits that signal
occurs. So you need to store two sets of digits and compare them. Only when
two successive sets are equal you may have a valid output. Otherwise one or
even both may be deformed.
I consider the chance to find an of the shelf solution pretty small.
Building a circuit that account for all details mentioned requires quite a
lot of hardware. Today, designers will use some programmable device like a
PLD or an FPGA. But the moment you're going to program a device you may get
a micro as well. A PIC16F628 or a PICAXE-28X2 will do the job... But yes, it
need to be programmed.
If you want me to do something like that for you, mail me at
petrusdotbitbyterathotmaildotcom.
petrus bitbyter
whit3rd
> the LED also has four Binary Weighted outputs (1,2,4,8) and three
> Is there a real simple hardware FIFO UART that can do this
The RS-232 requirement will be somewhat awkward, depending
on what power supplies are available; have you considered
USB instead? The FTDI device "FT245R" is a FIFO-input
USB slave device, with software support. I'd imagine you
can clear the FIFO and clock eight bits of address-and-BCD
data (four BCD bits and three 'digit enable' flags) as the
display is updated. Maybe the 'extra' bit could be used for
overflow or other error indicator.
RFI-EMI-GUY
snip
> I think it would be easier without the FIFO UART. You just want a
> signal that looks like the RS-232. You don't really need a RS-232
> receive function at all unless you want to use it to set the Baud
> rate.
>
I need compatibility with software that expects RS232 , I need to send
the appropriate bits, although the RX could be used to program the PIC I
guess.
RFI-EMI-GUY
The device I am talking about is a Doppler Systems DDF4002 doppler
direction finder. It is an older modele that once had a serial interface
option which is no longer available.
Your observation about the update rate is quite correct and is covered
in the manual for the DDF4002, The theory section of the manual
describes almost exactly the data rate assumptions you have stated but
qualifies it with:
"However, the message is initiated only when the display is updated.
Since this occurs at a maximum rate of 1/1.875 (0.533) seconds, ample
time exists between characters and between messages to prevent overrunning.
There is also a later hardware mod to raise the 16X clock (4800 Hz from
main board) to 38,400 Hz to provide 2400 baud.
RFI-EMI-GUY
I understand that I may need a bi-polar power supply and line driver
like a DF1488 am wary of USB beacause I don't know if any of the legacy
amateur software that this will be used for has drivers for USB. Tell me
more however.
petrus bitbyter
Found a manual of the DDF1. That's a kits description but two important
pages i.e.18 and 19 are carefully wiped out. Maybe a predecessor of the
DDF4002 (or not).
Current information at Doppler Systems Inc. starts at 6000 series. No trace
of the 4002 ever existed. Does your manual contain a schematic or print
layout?
petrus bitbyter
MooseFET
> MooseFET wrote:
>
> snip
>
> > I think it would be easier without the FIFO UART. You just want a
> > signal that looks like the RS-232. You don't really need a RS-232
> > receive function at all unless you want to use it to set the Baud
> > rate.
>
> I need compatibility with software that expects RS232 , I need to send
> the appropriate bits, although the RX could be used to program the PIC I
> guess.
Yes you need to be compatible with software that expects RS-232. This
means that you do not need a UART chip. All a UART chip does is make
a signal wiggle up and down with a certain pattern. It is often
easier to just make the signal you want rather than adapt to some
chip.
Example: A simple counter driving a 4051 MUX or two or three can make
perfectly good RS-232 data out of some small collection of logic
signals.
Don Lancaster
--
Many thanks,
Don Lancaster voice phone: (928)428-4073
Synergetics 3860 West First Street Box 809 Thatcher, AZ 85552
rss: http://www.tinaja.com/whtnu.xml email: d...@tinaja.com
Please visit my GURU's LAIR web site at http://www.tinaja.com
Joerg
But that could present a problem. Converting parallel to serial is easy
but now he'll have to work with a bit rate that's probably non-standard.
Or he could try to change the mux rate until it gets to within a percent
of a popular baud rate while keeping potential drift in mind.
don
> Martin Riddle wrote:
>> Datasheet <http://www.intersil.com/data/fn/fn3167.pdf>
>>
>> Sync the digits with the Mux outputs.
>>
>
> But that could present a problem. Converting parallel to serial is easy
> but now he'll have to work with a bit rate that's probably non-standard.
> Or he could try to change the mux rate until it gets to within a percent
> of a popular baud rate while keeping potential drift in mind.
>
It was stated in an earlier post about the update rate and baud rate.
The OP stated that the display update is 300 updates a second.
There are four BCD digits, so it take about 3 mSec to scan one set of
digits.
Looking at the diagram on page 2, the digit drivers and the BDC I/O are
all is needed to capture the numbers on the display.
A software loop checking each digit driver and assembling a ASCII string
in an output buffer.
And if the display changes, send the ascii string out the serial port (
any baud rate).
My question would be on the PC side.
How fast can a PC process data before its buffer overflows ?
Do I care, will the PC guy understand that he may drop data.
The worst case would be if the lowest digit changes every update.
don
PS: with the ICM7217 out of production, how would someone test if this
works with out the original unit ?
Joerg
> Joerg wrote:
>> Martin Riddle wrote:
>>> Datasheet <http://www.intersil.com/data/fn/fn3167.pdf>
>>>
>>> Sync the digits with the Mux outputs.
>>>
>>
>> But that could present a problem. Converting parallel to serial is
>> easy but now he'll have to work with a bit rate that's probably
>> non-standard. Or he could try to change the mux rate until it gets to
>> within a percent of a popular baud rate while keeping potential drift
>> in mind.
>>
>
> It was stated in an earlier post about the update rate and baud rate.
>
> The OP stated that the display update is 300 updates a second.
>
> There are four BCD digits, so it take about 3 mSec to scan one set of
> digits.
>
> Looking at the diagram on page 2, the digit drivers and the BDC I/O are
> all is needed to capture the numbers on the display.
>
> A software loop checking each digit driver and assembling a ASCII string
> in an output buffer.
>
> And if the display changes, send the ascii string out the serial port (
> any baud rate).
>
Ok, yeah, you could send out 19.2k or faster bursts. But I don't see how
that can be done without some uC programming up there. Which the op said
he doesn't want unless it can be had on a silver platter :-)
> My question would be on the PC side.
> How fast can a PC process data before its buffer overflows ?
>
IME a modern PC with a decent terminal program doesn't choke at all.
Same if it pipes into Excel (BTDT).
> Do I care, will the PC guy understand that he may drop data.
>
> The worst case would be if the lowest digit changes every update.
>
> don
>
> PS: with the ICM7217 out of production, how would someone test if this
> works with out the original unit ?
AFAIU the op already has the units with that chip in there.
don
Looking more at the data sheet, just using a PIC as the counter would be
the easiest.
Knowing how this ICM7217 is configured and using an interrupt on the PIC
counter.
don
Joerg
Sure, but the OP wrote, quote "I don't want a software fix unless I can
do it in PicAxe and can find code written."
So the 1st part would probably be quite feasible (but I don't know
PIC-Axe), the 2nd part is doubtful unless someone had the same task at
hand before and has posted the code.
John Fields
wrote:
---
Not necessarily, since if he uses the digit strobes to acquire the BCD
data, one digit at a time, in parallel, and generates the start and stop
bits at the same time, he'll have the time until the next digit strobe
to shift the ten bits out, serially, using a bit clock his receiver is
expecting.
---
>Or he could try to change the mux rate until it gets to within a percent
>of a popular baud rate while keeping potential drift in mind.
---
Much easier, I think, to just shift the data out using the proper bit
clock assuming, of course, the receiver is fast enough to receive ten
bits between digit strobes.
JF
John Fields
wrote:
---
So I take more than a little time out of my life to propose a 5 chip
hardware solution, and get neither a "Thanks", nor a "Kiss my ass", nor
an acknowledgement of any kind.
I don't get it...
JF
don
don
don
>
> PS: with the ICM7217 out of production, how would someone test if this
> works with out the original unit ?
Looks like it is still in production, just not from intersil.com .
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/1501
don
MooseFET
> MooseFET wrote:
> > On Dec 28, 6:48 pm, RFI-EMI-GUY <Rhyol...@NETTALLY.COM> wrote:
> >> MooseFET wrote:
>
> >> snip
>
> >>> I think it would be easier without the FIFO UART. You just want a
> >>> signal that looks like the RS-232. You don't really need a RS-232
> >>> receive function at all unless you want to use it to set the Baud
> >>> rate.
> >> I need compatibility with software that expects RS232 , I need to send
> >> the appropriate bits, although the RX could be used to program the PIC I
> >> guess.
>
> > Yes you need to be compatible with software that expects RS-232. This
> > means that you do not need a UART chip. All a UART chip does is make
> > a signal wiggle up and down with a certain pattern. It is often
> > easier to just make the signal you want rather than adapt to some
> > chip.
>
> > Example: A simple counter driving a 4051 MUX or two or three can make
> > perfectly good RS-232 data out of some small collection of logic
> > signals.
>
> Use a PIC instead of pissing around.
I don't know that RFI-EMI-GUY knows how to program one. Without a
program they are fairly useless.
The 8051 is better anyway. You can get a nice version from Silabs.
Jamie
you can use a USB-RS232 converter, the old software will work.
P.S.
Beware of Windows 7, it don't want to run 16 bit apps with out a
VM for Xp on it.
Up todate, I've only seen 64 bit versions of W7, there could be
32 bit versions, who knows!
RFI-EMI-GUY
lists. Unfortunately no board layouts.
RFI-EMI-GUY
Sorry for not replying, in fact I did print out the hardware solution as
it is educational to me for understanding how this works at a discrete
level. I am impressed at the detail you provided. The PIC interests me
because I would like to become more knowledgeable in that respect.
I am also impressed how this thread has remained on topic and productive.
RFI-EMI-GUY
I did a tiny bit of PICAXE programming with the help of my son on two
small projects. For this one I would need a head start, but could debug
at my end with the hardware I am sure.
I am impressed to hear the "Guru" weigh in, given he is the CMOS "God",
his opinion to go for PIC means a lot.
mike
> I have a device that has a three digit LED display. The chip that drives
> the LED also has four Binary Weighted outputs (1,2,4,8) and three
> address pins for 100's, 10's and units. I want to drive a FIFO UART of
> some sort to output an RS232 stream so that this device can update a
> software program. Baud rate 300 to 4800 range would be nice if possible.
>
> The updates are about 300/second
>
> Is there a real simple hardware FIFO UART that can do this without a lot
>
>
Check my math...
300 baud is 30 characters a second, give or take...
You want 3 digits updated 300 times a second.
that's 900 characters a second through a 30 character/second pipe.
4800 baud is about half of what you need for throughput.
You can almost get there if you mux two digits into one RS232 character.
What am I misunderstanding?
As for implementation, a microcontroller is gonna be fewer parts,
smaller size, easier implementation. These days, it's hard to find
a project that can be done better/faster/cheaper without one.
Jan Panteltje
<jfi...@austininstruments.com> wrote in
<a56lj59lhnjgdtggv...@4ax.com>:
>So I take more than a little time out of my life to propose a 5 chip
>hardware solution, and get neither a "Thanks", nor a "Kiss my ass", nor
>an acknowledgement of any kind.
>
>I don't get it...
>
>
>JF
Well, I dunno what he wants is for, but if it is for logging or remote indication,
I would just get a webcam, and record it as a low bitrate H264 AVI one pic a second or so.
If it has to go around the workd use a webcam in Skype :-)
And then he can upload it to youtube too :-)
LOL
MooseFET
Other that the fact that he suggested the PIC and not the 8051, if you
know micros, it is
the way to go.
If the digits are scanned slowly enough code that does something like
this will do the job:
Loop:
JNB MSBStrobe,$ ; Wait for MSB strobe
MOV A,DigitPort ; Do MSB digit
ORL A,#30H ; -- Make BCD into digit
MOV SBUF,A ; -- Send it
JNB TwoSBStrobe,$ ; Wait for 2SB strobe
MOV A,DigitPort ; Do 2SB digit
ORL A,#30H ; -- Make BCD into digit
MOV SBUF,A ; -- Send it
JNB LSBStrobe,$ ; Wait for LSB strobe
MOV A,DigitPort ; Do LSB digit
ORL A,#30H ; -- Make BCD into digit
MOV SBUF,A ; -- Send it
JNB TI,$ ; Wait for digit done
MOV SBUF,#0DH ; Do CR
JNB TI,$ ; Wait for CR done
MOV SBUF,#0AH ; Do LF
JNB TI,$ ; Wait for LF done
SJMP LOOP ; Repeat forever
It assumes that the digits come much slower than the strobes so that
they are done before
the next strobe.
MooseFET
Ooops See below
CLR TI ; Don't forget this!
>
> JNB TI,$ ; Wait for digit done
CLR TI ; Don't forget this!
> MOV SBUF,#0DH ; Do CR
> JNB TI,$ ; Wait for CR done
CLR TI ; Don't forget this!
John Fields
>RFI-EMI-GUY wrote:
>> I have a device that has a three digit LED display. The chip that drives
>> the LED also has four Binary Weighted outputs (1,2,4,8) and three
>> address pins for 100's, 10's and units. I want to drive a FIFO UART of
>> some sort to output an RS232 stream so that this device can update a
>> software program. Baud rate 300 to 4800 range would be nice if possible.
>>
>> The updates are about 300/second
>>
>> Is there a real simple hardware FIFO UART that can do this without a lot
>> of extra hardware. I don't want a software fix unless I can do it in
>> PicAxe and can find code written.
>>
>> Off the shelf products OK I don't want to reinvent the wheel.
>>
>Implementation details can be interesting, but only if the concept is sound.
>Check my math...
>300 baud is 30 characters a second, give or take...
>You want 3 digits updated 300 times a second.
>that's 900 characters a second through a 30 character/second pipe.
>4800 baud is about half of what you need for throughput.
>You can almost get there if you mux two digits into one RS232 character.
>What am I misunderstanding?
---
Dunno...
As for the 7217, I don't think the option to output only three digits is
available, so if all four digits update 300 times a second, that's 1200
characters per second; i.e. 1200 baud. If a start and stop bit are
added to each character, as must be done for asynchronous transmission,
then the signaling element rate will still be 1200 baud, but the bit
rate will be 10 times that, or 12000 bits per second if the characters
are aligned head-to-tail with no space between the end of the stop bit
of one character and the beginning of the start bit of the next.
Now, since the digits update at 300Hz per 4 digits, that's 83.3�s per
digit, so as soon as one digit is strobed into the shifter by the
negative going edge of its digit strobe, there'll be 83.3�s available to
shift 10 bits into the OP's device before the next digit strobe goes
true and loads its corresponding digit into the shifter.
Just for grins, let's say that to avoid any conflicts we use a 1/80�s =
125kHz bit clock to shift out the digits; then we'll have something that
looks like this:
__
D4 \________________________________________________________________
____
D4IO \______________________________________________________________
_ __ ______________________________________________________________
L/S |_|
____ __ __ __ __ __ __ __ __ ___________________________________
SD4 |__|__|__|__|__|__|__|__|__|
___________________________
D3 ______/ \_______________________________
_____________________________
D3IO______/ \_____________________________
_ ___________________________________ _____________________________
L/S |_|
____________________________________ __ __ __ __ __ __ __ __ __
SD3 |__|__|__|__|__|__|__|__|__|
8.3�s-->| |<--
and so on for the rest of the digits.
>As for implementation, a microcontroller is gonna be fewer parts,
>smaller size, easier implementation. These days, it's hard to find
>a project that can be done better/faster/cheaper without one.
For other than a one-off, all true except for implementation.
Since a hardware solution requires hardware and circuit design, and a �C
solution requires hardware design as well as circuit design which must
be implemented in software, I'd say it was a wash.
For a one-off, "easier implementation" ignores the learning curve and
the tooling costs required to get started in software, and could be much
more difficult than doing it in hardware.
In this case, I'm not defending either approach but, since the OP asked
for a hardware solution, that's what the preliminary circuit I posted
was.
JF
John Fields
wrote:
>I have a hardcopy of the complete manual, theory, schematics, parts
>lists. Unfortunately no board layouts.
---
Can you post the schematics, please?
JF
RFI-EMI-GUY
(I repeat)
The device I am talking about is a Doppler Systems DDF4002 doppler
direction finder. It is an older modele that once had a serial interface
option which is no longer available.
Your observation about the update rate is quite correct and is covered
in the manual for the DDF4002, The theory section of the manual
describes almost exactly the data rate assumptions you have stated but
qualifies it with:
"However, the message is initiated only when the display is updated.
Since this occurs at a maximum rate of 1/1.875 (0.533) seconds, ample
time exists between characters and between messages to prevent overrunning.
There is also a later hardware mod to raise the 16X clock (4800 Hz from
main board) to 38,400 Hz to provide 2400 baud.
--
petrus bitbyter
As you have the schematic why not use the solution provided there? Or is
this part left out? But even then you'd find some remnants of the interface
that'll make it much easier to provide a solution.
Supposing you have a signal that initiates the display update (and there
must be some) the next algorithm will due (either in hardware or in a
micro):
1. Wait for display update
2. Wait for leading edge of address pin 1
3. Load digit 1 in shift register and shift it out
4. Wait for leading edge of address pin 2
5. Load digit 2 in shift register and shift it out
6. Wait for leading edge of address pin 3
7. Load digit 3 in shift register and shift it out
8. Goto 1
If you really want a hardware only solution, the schematics of John Fields
will give you a headstart.
petrus bitbyter
Paul Hovnanian P.E.
OOps??
We already shipped 100,000 units based on your last post!!
--
Paul Hovnanian mailto:Pa...@Hovnanian.com
------------------------------------------------------------------
There are only 10 kinds of people in this world,
those who understand binary and those who don't.
MooseFET
> MooseFET wrote:
>
> > On Dec 30, 6:38 am, MooseFET <kensm...@rahul.net> wrote:
> > Ooops See below
>
> OOps??
>
> We already shipped 100,000 units based on your last post!!
They wouldn't have made them out of the test department if you were
running a good shop.
So you should have said "we just scrapped 100,000 units..."
>
> --
> Paul Hovnanian mailto:P...@Hovnanian.com
JosephKK
>RFI-EMI-GUY wrote:
>> don wrote:
>>> RFI-EMI-GUY wrote:
>>>> I have a device that has a three digit LED display. The chip that
>>>> drives the LED also has four Binary Weighted outputs (1,2,4,8) and
>>>> three address pins for 100's, 10's and units. I want to drive a FIFO
>>>> UART of some sort to output an RS232 stream so that this device can
>>>> update a software program. Baud rate 300 to 4800 range would be nice
>>>> if possible.
>>>>
>>>> The updates are about 300/second
>>>>
>>>> Is there a real simple hardware FIFO UART that can do this without a
>>>> lot of extra hardware. I don't want a software fix unless I can do it
>>>> in PicAxe and can find code written.
>>>>
>>>> Off the shelf products OK I don't want to reinvent the wheel.
>>>>
>>> Do you docs on the outputs ?
>>>
>>> don
>>
>>
>> I think you are asking the specs of the driving chip? Its an ICM7217IJI
>> Common Cathode 4 LED Display/Programmable Up/Down Counter. The BCD I/O
>> pins and the segment drivers b, d and f (d1, d2, d3) used to select
>> 100's. 10's and units (I may have order reversed).
>>
>
>That will not be so trivial because this is a chip that drives the LED
>in muxed fashion.
Which immediatly leads to the next question, what is on the other side of that chip?
JosephKK
Seeing as this your first post in this thread i have found, perhaps your
post did not appear in much of Usenet.
JosephKK
Interesting. Your previous post reached OP but not me. I already know
that my news host does not get/propagate all posts.
John Fields
wrote:
---
That's a shame...
Check Google groups; since this thread is all text they'll probably all
be there.
JF
John Fields
wrote:
---
If you're talking about the driven side of the 7217, it shouldn't make
much difference since all that's being output from the chip is four
parallel bits of BCD date along with four single-bit strobes with edges
that go low when the BCD data is valid.
The job, therefore, is to assemble the four output data bits, the strobe
bit, the start and stop bits, and to send all of them as a 10 bit serial
word formatted as RS-232 TRANSMITTED DATA to a receiver somewhere which
is expecting it to come in at a particular bit rate.
JF
Joerg
An analog input signal :-)
JosephKK
Already having the data in a convenient form reduces the design complexity.
JosephKK
And that would lead to an entirely different solution space.
John Fields
wrote:
---
"Solution space" ???
Pretentious nonsense.
Regardless of what feeds the input(s) of the 7217, the outputs we're
concerned with are the four-bit BCD I/O and the four digit strobes which
identify which BCD digit is which.
What the OP wants is a way to convert the BCD and digit strobe data into
a format which can be read by an RS-232 DTE box, and several solutions
were presented earlier on in the thread.
JF
John Fields
wrote:
---
You do seem to have a remarkable grasp of the obvious but, other than
demonstrating that, I don't understand what point you're trying to
make.
JF
krw
Certainly. A different problem space, of course, has a different
solution space. ;-)
>Pretentious nonsense.
>
>Regardless of what feeds the input(s) of the 7217, the outputs we're
>concerned with are the four-bit BCD I/O and the four digit strobes which
>identify which BCD digit is which.
>
>What the OP wants is a way to convert the BCD and digit strobe data into
>a format which can be read by an RS-232 DTE box, and several solutions
>were presented earlier on in the thread.
Your (first) solution was clearly the simplest, given that an
appropriate baud rate generator can be had easily.
JosephKK
That's odd. I was under the impression that the output of the 7217 was
7 segments of 4 digit LED display scanned.
RFI-EMI-GUY
It actually has both 7 segment drivers and BCD I/O's. The lines used to
strobe the display segments also used to address the BCD output.
JosephKK
Looked up most probable chip. Weird. But i more nearly understand now.