Looking for simple way to interface BCD to serial (RS232)

Started by RFI-EMI-GUY December 27, 2009
MooseFET wrote:
> On Dec 29, 8:25 am, Don Lancaster <d...@tinaja.com> wrote: >> 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. >> -- >> 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 athttp://www.tinaja.com >
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. -- Joe Leikhim K4SAT "The RFI-EMI-GUY"&#2013266089; "Use only Genuine Interocitor Parts" Tom Servo ;-P
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? 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.
On Dec 29, 8:07=A0pm, RFI-EMI-GUY <Rhyol...@NETTALLY.COM> wrote:
> MooseFET wrote: > > On Dec 29, 8:25 am, Don Lancaster <d...@tinaja.com> wrote: > >> 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. =A0You
just want = a
> >>>>> signal that looks like the RS-232. =A0You don't really
need a RS-23= 2
> >>>>> 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 se= nd
> >>>> the appropriate bits, although the RX could be used to program
the P= IC I
> >>>> guess. > >>> Yes you need to be compatible with software that expects RS-232.
=A0T= his
> >>> means that you do not need a UART chip. =A0All a UART chip does is
ma= ke
> >>> a signal wiggle up and down with a certain pattern. =A0It is
often
> >>> easier to just make the signal you want rather than adapt to some > >>> chip. > >>> Example: =A0A simple counter driving a 4051 MUX or two or three
can m= ake
> >>> 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. =A0Without a > > program they are fairly useless. > > > The 8051 is better anyway. =A0You can get a nice version from Silabs. > >> -- > >> Many thanks, > > >> Don Lancaster =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
=A0voice= phone: (928)428-4073
> >> Synergetics =A0 3860 West First Street =A0 Box 809 Thatcher, AZ 85552 > >> rss:http://www.tinaja.com/whtnu.xml=A0email: d...@tinaja.com > > >> Please visit my GURU's LAIR web site athttp://www.tinaja.com > > 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.
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.
> > -- > Joe Leikhim K4SAT > "The RFI-EMI-GUY" > > "Use only Genuine Interocitor Parts" Tom Servo =A0;-P
On Dec 30, 6:38=A0am, MooseFET <kensm...@rahul.net> wrote:
Ooops See below
> On Dec 29, 8:07=A0pm, RFI-EMI-GUY <Rhyol...@NETTALLY.COM> wrote: > > > > > MooseFET wrote: > > > On Dec 29, 8:25 am, Don Lancaster <d...@tinaja.com> wrote: > > >> 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.
=A0You just wan= t a
> > >>>>> signal that looks like the RS-232. =A0You 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. = =A0This
> > >>> means that you do not need a UART chip. =A0All a UART chip
does is = make
> > >>> a signal wiggle up and down with a certain pattern. =A0It is
often
> > >>> easier to just make the signal you want rather than adapt to
some
> > >>> chip. > > >>> Example: =A0A 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. =A0Without a > > > program they are fairly useless. > > > > The 8051 is better anyway. =A0You can get a nice version from
Silabs.
> > >> -- > > >> Many thanks, > > > >> Don Lancaster =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
=A0voi= ce phone: (928)428-4073
> > >> Synergetics =A0 3860 West First Street =A0 Box 809 Thatcher, AZ
8555= 2
> > >> rss:http://www.tinaja.com/whtnu.xml=A0email: d...@tinaja.com > > > >> Please visit my GURU's LAIR web site athttp://www.tinaja.com > > > 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. > > 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: > =A0 =A0 =A0 =A0 JNB =A0 =A0 MSBStrobe,$ =A0 =A0 =A0 =A0; Wait for MSB str=
obe
> =A0 =A0 =A0 =A0 MOV =A0 =A0 A,DigitPort =A0 =A0 =A0 =A0; Do MSB digit > =A0 =A0 =A0 =A0 ORL =A0 =A0 A,#30H =A0 =A0 =A0 =A0 =A0 =A0 ; =A0 -- Make =
BCD into digit
> =A0 =A0 =A0 =A0 MOV =A0 =A0 SBUF,A =A0 =A0 =A0 =A0 =A0 =A0 ; =A0 -- Send =
it
> =A0 =A0 =A0 =A0 JNB =A0 =A0 TwoSBStrobe,$ =A0 =A0 =A0; Wait for 2SB strob=
e
> =A0 =A0 =A0 =A0 MOV =A0 =A0 A,DigitPort =A0 =A0 =A0 =A0; Do 2SB digit > =A0 =A0 =A0 =A0 ORL =A0 =A0 A,#30H =A0 =A0 =A0 =A0 =A0 =A0 ; =A0 -- Make =
BCD into digit
> =A0 =A0 =A0 =A0 MOV =A0 =A0 SBUF,A =A0 =A0 =A0 =A0 =A0 =A0 ; =A0 -- Send =
it
> =A0 =A0 =A0 =A0 JNB =A0 =A0 LSBStrobe,$ =A0 =A0 =A0 =A0; Wait for LSB str=
obe
> =A0 =A0 =A0 =A0 MOV =A0 =A0 A,DigitPort =A0 =A0 =A0 =A0; Do LSB digit > =A0 =A0 =A0 =A0 ORL =A0 =A0 A,#30H =A0 =A0 =A0 =A0 =A0 =A0 ; =A0 -- Make =
BCD into digit
> =A0 =A0 =A0 =A0 MOV =A0 =A0 SBUF,A =A0 =A0 =A0 =A0 =A0 =A0 ; =A0 -- Send =
it CLR TI ; Don't forget this!
> > =A0 =A0 =A0 =A0 JNB =A0 =A0 TI,$ =A0 =A0 =A0 =A0 =A0 =A0 =A0 ; Wait for d=
igit done CLR TI ; Don't forget this!
> =A0 =A0 =A0 =A0 MOV =A0 =A0 SBUF,#0DH =A0 =A0 =A0 =A0 =A0; Do CR > =A0 =A0 =A0 =A0 JNB =A0 =A0 TI,$ =A0 =A0 =A0 =A0 =A0 =A0 =A0 ; Wait for C=
R done CLR TI ; Don't forget this!
> =A0 =A0 =A0 =A0 MOV =A0 =A0 SBUF,#0AH =A0 =A0 =A0 =A0 =A0; Do LF > =A0 =A0 =A0 =A0 JNB =A0 =A0 TI,$ =A0 =A0 =A0 =A0 =A0 =A0 =A0 ; Wait for L=
F done
> =A0 =A0 =A0 =A0 SJMP =A0 =A0LOOP =A0 =A0 =A0 =A0 =A0 =A0 =A0 ; Repeat for=
ever
> > It assumes that the digits come much slower than the strobes so that > they are done before > the next strobe. > > > > > -- > > Joe Leikhim K4SAT > > "The RFI-EMI-GUY" > > > "Use only Genuine Interocitor Parts" Tom Servo =A0;-P > >
On Tue, 29 Dec 2009 22:37:23 -0800, mike <spamme0@go.com> 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. >> >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&#2013266101;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&#2013266101;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&#2013266101;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&#2013266101;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 &#2013266101;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
On Tue, 29 Dec 2009 22:56:12 -0500, RFI-EMI-GUY <Rhyolite@NETTALLY.COM>
wrote:


>I have a hardcopy of the complete manual, theory, schematics, parts >lists. Unfortunately no board layouts.
--- Can you post the schematics, please? JF
mike 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. >> > 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? > > 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.
(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. -- Joe Leikhim K4SAT "The RFI-EMI-GUY"&#2013266089; "Use only Genuine Interocitor Parts" Tom Servo ;-P
"RFI-EMI-GUY" <Rhyolite@NETTALLY.COM> schreef in bericht 
news:4b3c0090$0$4962$9a6e19ea@unlimited.newshosting.com...
> mike 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. >>> >> 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? >> >> 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. > > (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. > > -- > Joe Leikhim K4SAT > "The RFI-EMI-GUY"&#2013266089; > > "Use only Genuine Interocitor Parts" Tom Servo ;-P
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
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!! -- Paul Hovnanian mailto:Paul@Hovnanian.com ------------------------------------------------------------------ There are only 10 kinds of people in this world, those who understand binary and those who don't.
On Dec 31, 5:21=A0pm, "Paul Hovnanian P.E." <P...@Hovnanian.com>
wrote:
> 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 =A0 =A0 mailto:P...@Hovnanian.com > ------------------------------------------------------------------ > There are only 10 kinds of people in this world, > those who understand binary and those who don't.
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. -- 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: don@tinaja.com Please visit my GURU's LAIR web site at http://www.tinaja.com
"RFI-EMI-GUY" <Rhyolite@NETTALLY.COM> schreef in bericht 
news:4b397197$0$4964$9a6e19ea@unlimited.newshosting.com...
> petrus bitbyter wrote: >> "RFI-EMI-GUY" <Rhyolite@NETTALLY.COM> schreef in bericht >> news:4b3815d7$0$4949$9a6e19ea@unlimited.newshosting.com... >>> John Fields wrote: >>>> On Sun, 27 Dec 2009 16:52:22 -0500, RFI-EMI-GUY
<Rhyolite@NETTALLY.COM>
>>>> 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&#2013266101;s/3.3kHz. >>>> >>>> Duck soup, maybe. ;) >>>> >>>> What's the chip that's driving the display? >>>> >>>> JF >>> 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). >>> >>> -- >>> Joe Leikhim K4SAT >>> "The RFI-EMI-GUY"&#2013266089; >>> >>> "Use only Genuine Interocitor Parts" Tom Servo ;-P >> >> >> 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 > > 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. > > -- > Joe Leikhim K4SAT > "The RFI-EMI-GUY"&#2013266089; > > "Use only Genuine Interocitor Parts" Tom Servo ;-P
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
whit3rd wrote:
> On Dec 27, 1:52 pm, RFI-EMI-GUY <Rhyol...@NETTALLY.COM> 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... > >> 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.
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. -- Joe Leikhim K4SAT "The RFI-EMI-GUY"&#2013266089; "Use only Genuine Interocitor Parts" Tom Servo ;-P
petrus bitbyter wrote:
> "RFI-EMI-GUY" <Rhyolite@NETTALLY.COM> schreef in bericht > news:4b3815d7$0$4949$9a6e19ea@unlimited.newshosting.com... >> John Fields wrote: >>> On Sun, 27 Dec 2009 16:52:22 -0500, RFI-EMI-GUY
<Rhyolite@NETTALLY.COM>
>>> 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&#2013266101;s/3.3kHz. >>> >>> Duck soup, maybe. ;) >>> >>> What's the chip that's driving the display? >>> >>> JF >> 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). >> >> -- >> Joe Leikhim K4SAT >> "The RFI-EMI-GUY"&#2013266089; >> >> "Use only Genuine Interocitor Parts" Tom Servo ;-P > > > 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 > >
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. -- Joe Leikhim K4SAT "The RFI-EMI-GUY"&#2013266089; "Use only Genuine Interocitor Parts" Tom Servo ;-P
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. -- Joe Leikhim K4SAT "The RFI-EMI-GUY"&#2013266089; "Use only Genuine Interocitor Parts" Tom Servo ;-P
On Dec 27, 1:52=A0pm, RFI-EMI-GUY <Rhyol...@NETTALLY.COM> 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...
> 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" <Rhyolite@NETTALLY.COM> schreef in bericht 
news:4b3815d7$0$4949$9a6e19ea@unlimited.newshosting.com...
> John Fields wrote: >> On Sun, 27 Dec 2009 16:52:22 -0500, RFI-EMI-GUY
<Rhyolite@NETTALLY.COM>
>> 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&#2013266101;s/3.3kHz. >> >> Duck soup, maybe. ;) >> >> What's the chip that's driving the display? >> >> JF > > 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). > > -- > Joe Leikhim K4SAT > "The RFI-EMI-GUY"&#2013266089; > > "Use only Genuine Interocitor Parts" Tom Servo ;-P
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
On Mon, 28 Dec 2009 12:46:15 -0600, John Fields
<jfields@austininstruments.com> wrote:


> 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 >. | | +------+ | | | | +------+ >. | +--|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
On Sun, 27 Dec 2009 21:20:10 -0500, RFI-EMI-GUY <Rhyolite@NETTALLY.COM>
wrote:

>John Fields wrote: >> On Sun, 27 Dec 2009 16:52:22 -0500, RFI-EMI-GUY
<Rhyolite@NETTALLY.COM>
>> 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&#2013266101;s/3.3kHz. >> >> Duck soup, maybe. ;) >> >> What's the chip that's driving the display? >> >> JF > >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).
--- 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