Looking for simple way to interface BCD to serial (RS232)
in [Design]
|
From: Don Lancaster on 29 Dec 2009 11:25 MooseFET wrote: > On Dec 28, 6:48 pm, RFI-EMI-GUY <Rhyol...(a)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(a)tinaja.com Please visit my GURU's LAIR web site at http://www.tinaja.com
From: Joerg on 29 Dec 2009 14:59 Martin Riddle wrote: > <don> wrote in message > news:Kq-dnfM2ZeS7taXWnZ2dnUVZ_rdi4p2d(a)forethought.net... >> Martin Riddle wrote: >>> "Joerg" <invalid(a)invalid.invalid> wrote in message >>> news:7pqjftFe4cU2(a)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 >>> >>> >> This is what I was wondering about. >> >> 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 > > 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. -- Regards, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.
From: don on 29 Dec 2009 15:47 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). 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 ?
From: Joerg on 29 Dec 2009 16:02 don wrote: > 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. -- Regards, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.
From: don on 29 Dec 2009 18:26
Joerg wrote: > don wrote: >> 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. > 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 |