-
well as i said it was a consideration another more sensible way would be to use a hv buck boost assuming of course that its a voltage hog, matter of fact i dont even know why i brought a cockroft walton into this conversation now
-
with the 595 which pins are the, mosi, /cs, and sck the TI datasheet wasnt clear
-
The path you are following is for sure the worst possible to make a VFD clock, why not use the chips designed for this purpose ?
-
which path are you talking about? the shift registers are a training exercise, the 7407 i might end up using i might not but it too is a training exercise a stepping stone on the path to me learning how to program a display driver chip. I cannot speak for how you learn but i find it far easier with stepping stones.
-
Based on the learning idea, it's OK go ahead
But for real world have better ways
I would suggest based on the learning ,that you try Proteus, they have a nice simulator than can help you on the learning process
https://www.labcenter.com/ -
Proteus VSM pricing is a bit on the steep side for hobbyists.
Yes, it doesn't make any sense commercially to build a VFD driver from SSI chips and discretes, and hasn't made sense since the beginning of the '80s, but I've currently got 4 chips + 36 discretes assembled on my breadboard doing a pretty good job of emulating a MAX6920 (I'd have to invert Din and use higher voltage drivers if I wanted it to be more exact), and I didn't have to wait 3 days or pay shipping to get a boutique part. OTOH there are 36 extra wires hooking it all up . . . . .
@neo,
Working from the NXP (Philips) 74HC595 datasheet, and the Arduino SPI reference page, pins are as follows:
Arduino Uno 74HC595
MOSI (11) => DS (14) - first chip only
SCK (13) => SH_CP (11)
SS (10) => ST_CP (12) - SPI /CS
Other '595 connections
+5V => /MR (10) - reset disabled
Gnd => /OE (13) - outputs on
Q7' (9) => DS (14) of next chip
+5V => Vcc (16)
Gnd => Gnd (8 )
Please double check against the datasheet - I'm not immune to typos. -
It's for fun... Make it
-
Just in case if you plan do use Arduino, They can do everything except the high voltage driver, you don't need logic Ic's
-
@ebclr: Unfortunately one rapidly runs out of pins that way.
I've done some documentation of it. Here's a schematic.
Not shown: Arduino Uno
I've also attached a photo as built, and my first cut at a sketch for driving it. Very crude - just multiplexing it in the main loop and counting up in hex from 0000 to FFFF
The display was photographed under normal room lighting with the PWM set for 1/4 brightness. Its showing some flare on the segments, not visible in real life, due to the brightness and the camera's auto aperture & exposure settings.
Photo Notes
The 74HC595 chips U1,2 are top right, with pin 1 to the left.
The ULN2803A chips U3,4 are center right with pin 1 to the right
Q1-12 are on the right top half of the lower board, with Q1 that handled the LSB from U1,U3 on the left. Pinout is B.C.E with E at the rounded end.
+HT is the top bus of the lower breadboad, from AM1S-0524SZ 1W DC-DC converter (bottom right) Pinout is SIL: Vin-, Vin+, Vout-, Vout+. All other busses are +5V at top edge , 0V/Gnd at lower edge of each board.
Decoupling: 2x 0.1uF ceramic disk across U1,U2, 10uF 50V on +HT rail (by DC-DC converter), 47uF 25V, (on right between U2 & U4).
There is some wiring under the VFD so that the four symbols appear in order as the eighth bit of each digit. As VFD anodes and grids are fairly interchangeable from a driver point of view, this is achieved by connecting Grid 3 (centre symbols) to the 'A' anode (which is already under Grid 1), then connecting one of the centre symbol anodes to each remaining grid.
Edit: updated schematic, and zipped code for working clock
-
i wired up the 595 on breadboard, it didnt blow up though the led did light up is it meant to?
-
All the pins you need are available
Analog pins can also be digital pins -
except for the fact im trying to learn how to it with (relatively) high voltages that idea is ok, but as it says in the title this is for a vfd, specifically it has become me learning spi for a display driver chip, not simple logic level, i might be missing something from your post but i dont see how i would learn spi that way
-
The quick answer is: you woudn't. You'd be taking someone else's code and just hoping it worked.
Normally I'm a big proponent of using a MCU with enough pins rather than external I/O expanders and other logic, but sometime elegance or convenience wins over costs savings.
The 74HC595 circuit gives you far far more access with a logic probe, and if you 'bodge' it by wiring ST_CK to SCK instead of SS, you can get the previous shift register contents to appear on the outputs after each SCK rising edge, ideal for watching a bit pattern shift across a string of LEDs while you clock it sloooooooowly. Stick a single chip integrated shift register, latch and HV driver in there and not only are there voltages you don't want to stick your logic probe into, but there is also absolutely no update until the rising edge of SS so if the data is getting corrupted, its the devil's own to debug without putting it on a reasonably good 4 channel DSO. (You need to monitor three lines of the SPI interface + at least one output bit, and the output level will blow the s--t out of a logic analyser unless you add a circuit to convert it back down to logic levels.)
Ebclr does have a point if you want to learn about driving multiplexed displays without the SPI stuff getting in the way and I suggested something similar to you in the early pages of this topic, but you'd have to rip it up to replace it with the SPI stuff, whereas if you learn the SPI first, simply displaying one static digit, you can then extend that to multiplexing without moving single wire, just by adding code to loop through all the digits repeatedly. Unless you've got the resources to keep two versions fully assembled, that's a major benefit when you start doubting yourself and need to go back to simpler code that you've already proved to work.
I hope you found my VFD breadboard interesting, and at least the schematic should help you with some of the hookup details even though you intend to use different buffers for the level shifter.
Edit: Meanwhile I've got interrupt driven background multiplexing working. I'll hold off on posting code to avoid confusing you before you've got the basics going. Also it needs some cleanup before its fit to be out in public. -
@Neo: Its five days later and no followup on your progress with your VFD project. Are you still working on it? If so, I'll wait till you have cracked controlling a '595 chip before posting my current code, but if you've got sidetracked or would like to see my code before you work on your own, or don't follow up, I'll wrap this up by posting it.
Its currently loosing about 2 minutes per day (approx 700ppm) which is more than an order of magnitude worse than a really bad crystal. The Uno I am using is genuine 'Made in Italy' with a crystal, not a resonator. I suspect the Arduino millis() count is FUBARed by design - its supposed to compensate for the Timer 0 interrupt rate not being exactly 1000Hz by adjusting the count periodically and my running second count allows for any adjustments to millis():Code: [Select]if((millis()-ms)>ONE_SEC){by keeping a running count of 'milliseconds' and adding 1000 to it whenever it lags by more than 1000. There seem to be a lot of reports of problems with millis() accuracy. . . .
ms+=ONE_SEC;
BCDtime++;
fixHMS();
} -
thank you ian, i have gotten a bit side tracked, all but one part for my simple iv-6 clock showed up and ive been building it, pics of it will go up when im done. As for the 595 i plugged it in but the led lit up, is it meant to? no code or nothing i just grounded the chip and it acted like id grounded the leds
-
Thanks for following up. Your IV-6 clock build sounds interesting, why not start another topic to document it as you build it? (I'm impatient to see it
)
Yes, the '595 can do that. Its got 16 flipflops storing state, eight as the shift register itself and eight as the output latch and at powerup their states are effectively random* until you either shift in valid data or pulse the reset pin. Without logic or a MCU set up to feed in data while pulsing SH_CP with a clean pulse, and then pulse ST_CP, the '595 will *NOT* do anything useful. If you have two SPDT pushbuttons and either a quad NAND or quad NOR gate chip (either will do) + a toggle switch, I can draw you a schematic for a '595 test jig that will let you manually shift data through it and latch it to its outputs, but its probably better to dive right in and try to bit-bang it using an Arduino.
* They actually depend on manufacturing tolerances + noise on the supply during powerup, so although random from chip to chip, one specific chip in a particular circuit often tends to have 'favourite' powerup states. -
ok, the threads started https://www.eevblog.com/forum/projects/daves-clock-from-russia-with-glow-version/
-
I was wrong.
AARGH!!! Italian Arduino Designers!
You already have a 16MHz crystal for the ATmega16U2 running the USB interface, so why not tap into that accurate clock for the main ATmega328P MCU instead of fitting a s--tty resonator?
No wonder Arduinos have such a rep for crappy timekeeping.
-
You already have a 16MHz crystal for the ATmega16U2 running the USB interface, so why not tap into that accurate clock for the main ATmega328P MCU instead of fitting a s--tty resonator?
No wonder Arduinos have such a rep for crappy timekeeping.
Indeed. An AT-cut crystal is more stable than a 32k watch crystal and runs way more accurate if properly trimmed. Such a thing is also a good one to learn a bit of assembler if you like. A hundred lines or so will do including alarm and bells and whistles
An ATmega48 will do easily.
-
Well, I'm now gilding and polishing the turd.Code: [Select]
#define ONE_SEC 997784UL // micros() in one second trimmed for resonator.which was calculated based on the time lost during a 15 hour run, and:Code: [Select]int main() {which is how I'm keeping time in my main() function (I've got a dummy .ino file so I can program it in real GCC C++ without the IDE mangling it before compilation).
uint32_t t; // temp for digit extraction
uint8_t d; // extracted digit, then its font
uint32_t ms; // tick counter to sync to system micros count.
setup(); // initialisation
ms=micros();
while(1){ // Superloop
flags.bMode=!digitalRead(BTNMODE);
flags.bSet=!digitalRead(BTNSET);
if((micros()-ms)>ONE_SEC){
ms+=ONE_SEC;
BCDtime++;
fixHMS();
}
switch(flags.bSet<<1|flags.bMode){
case 0b00: //Normal
display(BCDtime>>8);
VFDsymbWrite(VFD_SYMB_DOT,(BCDtime&1)); //Flashing dot
break;
case 0b01: //Mode pressed
display(BCDtime&0xFFFFUL);
VFDsymbWrite(VFD_SYMB_DOT,0); //No dot
break;
case 0b10: //Set pressed
BCDtime+=0x000100UL; //Increment only minutes
if((BCDtime&0x00FF00UL)==0x005A00UL) BCDtime&=0xFF00FFUL; //Wrap 60 to 00
goto doSet;
case 0b11: //Set + Mode pressed
BCDtime+=0x010000UL; //Increment hours
doSet:
BCDtime&=0xFFFF00UL; //Clear seconds
ms=micros();
fixHMS();
display(BCDtime>>8);
VFDsymbWrite(VFD_SYMB_DOT,1); //Fixed dot
delay(80);
break;
}
delay(20);
} //endWhile(1)
}//endFn main
We'll see this time tomorrow, how closely I've trimmed it for the crappy resonator.
I also found a fencepost error in my multiplexing function - it was scanning one extra non-existent digit, and the variable after the display buffer array was the flags structure, which resulted in the top segment of the third digit getting lit, (or brightened if already lit) whenever the [Secs] button was pressed. Fortunately I had the display well dimmed so it was obvious that segment was getting extra time in each frame, and that it wasn't display buffer corruption.
-
I'd overcorrected. It now usingCode: [Select]
#define ONE_SEC 999187UL // micros() in one second trimmed for resonator.and is tracking a NNTP corrected PC clock to better than 2 seconds a day. To do any better, I'd have to either write a sketch to automate the clock setting and error measurement, or use a *good* frequency meter.
The resonator currently has a frequency error of about -800PPM, However its a s--ty resonator so I'm expecting the turd gilding to fail as it drifts due to temperature change, mechanical stress and ageing. -
this is getting way ahead of the 595 stage but when i go to build it will at at89c2051-24pi chip work? i just happened to find one
-
Theoretically yes, but that's an 8051 family MCU with only 1/16 the RAM and program memory of the ATmega328P on an Arduino, my fairly simple VFD clock is already using more program memory on the Arduino than its got, its not supported by GCC, and it needs a HV programmer you don't have.
Put it aside for now - there are some options to use it (see https://www.pjrc.com/tech/8051/) but the learning curve would be a lot steeper than Arduino and its not something a novice should tackle until they've thrown away the training wheels of the Arduino IDE, libraries, boards and preloaded bootloader.
On the subject of the gilded turd, the gilding is definitely flaking off. The clock is currently running 6 seconds fast since I posted about it yesterday. It looks like an order of magnitude improvement in accuracy over an uncalibrated resonator is practical in a shirt-sleeve environment, but its still an order of magnitude worse than an uncalibrated crystal. -
-puts the arduino chip in his collection next to the pic that he will probably not use anytime soon- ok back to the 595, i got the 595 on the breadboard what now?
-
So what do you have hooked up to the '595?
I would suggest a LED on each output pin with a series resistor of between 330R and 1K for each one. Either individual LEDs or a single 7 segment + DP one.
How do you want to stuff data into the '595? Do you want to use push buttons and toggle switches till you have a feel for it, or go straight to Arduino?