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
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.
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 ?
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 :-)
IME a modern PC with a decent terminal program doesn't choke at all. Same if it pipes into Excel (BTDT).
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.
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
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.
-- Regards, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.
-- 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.
-- 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
I guess the OP did not like your idea. :-/
don
Looks like it is still in production, just not from intersil.com .
don
I s e
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.
one: (928)428-4073
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!
I have a hardcopy of the complete manual, theory, schematics, parts lists. Unfortunately no board layouts.
-- Joe Leikhim K4SAT "The RFI-EMI-GUY"© "Use only Genuine Interocitor Parts" Tom Servo ;-P
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.
-- Joe Leikhim K4SAT "The RFI-EMI-GUY"© "Use only Genuine Interocitor Parts" Tom Servo ;-P
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"© "Use only Genuine Interocitor Parts" Tom Servo ;-P
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 a sunny day (Tue, 29 Dec 2009 18:06:22 -0600) it happened John Fields wrote in :
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
a 2
nd
IC I
his
ke
ake
phone: (928)428-4073
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.
t a
232send
PIC I
=A0This
make
make
ce phone: (928)428-4073
2obe
BCD into digit
it
eBCD into digit
it
obe
BCD into digit
it
CLR TI ; Don't forget this!
igit done CLR TI ; Don't forget this!
R done CLR TI ; Don't forget this!
F done
ever
--- 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-->| |As for implementation, a microcontroller is gonna be fewer parts,
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
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.