Thank you for this.
I'm still getting my head around shifting bits in general so examples are
really useful; there looks to be a lot going on here! digitalWrite(DATAPin,
!!(_val & ((uint64_t)1 << (i))));
I'm making two prototypes, one with only 4 IN12 tubes and 2 INS1 neons
individually driven from an ESP32 using 4 x K155ID1 and 4 x LTV-851 plus
one MJE340 for PWM dimming. This is complete and works well but one flaw
is having had to scrimp on pins meaning tubes 1 & 3 will only go as high as
2 & 5 respectively. I intend to connect them all on V2 so will likely need
the 74HC595 or similar.
The second will have 6 IN14 tubes and 4 IN3 neons hence the 5530. Having
dropped the frequency today, a basic blink sketch is working using SPI or
shifting bits manually but only on the first driver. Adding a second breaks
everything. Both drivers work ok in isolation so I think the issue here is
with the breakout boards or breadboard joining everything together so will
be troubleshooting this next.
Thanks.
On Thursday, 27 March 2025 at 11:36:54 UTC Ian Sparkes wrote:
> My hint would be to stay away from SPI until you have done a bit banged
> version. I have drivers for everything, basically, so if you need some
> code, I'm happy to help you out. Also be careful of the implicit type
> conversions that come with bit twiddling and shifting out.
>
> This is for the ESP8266 with HV5622 or 5530 drivers:
>
> // ************************************************************
> // Perform the parallel shift out to the registers
> // ************************************************************
> IRAM_ATTR void shiftOut64(uint64_t _val) {
> uint8_t i;
>
> // Top 3 digits
> digitalWrite(LATCHPin, LOW);
> for (i = 0 ; i < 32 ; i++) {
> digitalWrite(DATAPin, !!(_val & ((uint64_t)1 << (i))));
> digitalWrite(CLOCKPin, HIGH);
> digitalWrite(CLOCKPin, LOW);
> }
>
> // Bottom 3 digits
> for (i = 0 ; i < 32 ; i++) {
> digitalWrite(DATAPin, !!(_val & ((uint64_t)1 << (i + 32))));
> digitalWrite(CLOCKPin, HIGH);
> digitalWrite(CLOCKPin, LOW);
> }
> digitalWrite(LATCHPin, HIGH);
> }
>
> // ************************************************************
> // Perform the parallel shift out to the registers
> // ************************************************************
> IRAM_ATTR void shiftOut64Off() {
> uint8_t i;
>
> digitalWrite(DATAPin, LOW);
> for (i = 0; i < 64; i++) {
> digitalWrite(CLOCKPin, HIGH);
> digitalWrite(CLOCKPin, LOW);
> }
>
> // Latch in
> digitalWrite(LATCHPin, HIGH);
> digitalWrite(LATCHPin, LOW);
> }
>
> I kind of guess you are 74HC595s if you are using K155ID1s, so here's a
> similar piece of code for using 595s:
>
> // ************************************************************
> // Perform the parallel shift out to the registers
> // ************************************************************
> void IRAM_ATTR shiftOut64(uint64_t _val1) {
> uint8_t i;
>
> #ifdef INVERT_595_OUTPUTS
> uint64_t bout = ~_val1;
> #endif
>
> #ifdef NORMAL_595_OUTPUTS
> uint64_t bout = _val1;
> #endif
> digitalWrite(LATCHPin, LOW);
> for (i = 0; i < 64; i++) {
> digitalWrite(DATAPin, !!(bout & ((uint64_t)1 << (63 - i))));
> digitalWrite(CLOCKPin, HIGH);
> digitalWrite(CLOCKPin, LOW);
> }
> digitalWrite(LATCHPin, HIGH);
> }
>
> // ************************************************************
> // Perform the parallel shift out to the registers
> // ************************************************************
> void IRAM_ATTR shiftOut64Off() {
> uint8_t i;
>
> digitalWrite(LATCHPin, LOW);
> #ifdef INVERT_595_OUTPUTS
> digitalWrite(DATAPin, HIGH);
> #endif
>
> #ifdef NORMAL_595_OUTPUTS
> digitalWrite(DATAPin, LOW);
> #endif
> digitalWrite(DATAPin, LOW);
> for (i = 0; i < 64; i++) {
> digitalWrite(CLOCKPin, HIGH);
> digitalWrite(CLOCKPin, LOW);
> }
> digitalWrite(LATCHPin, HIGH);
> }
>
>
> Of course, you'll have to adapt to your use case, but it shows the way you
> have to twiddle the clock and the latch pins.
>
> Once you have that working, you can move over to SPI if you need - I have
> never found it necessary, because I practically always work with interrupt
> driven displays (hence the IRAM_ATTR) in the signature.
>
> Hope that helps.
>
> On Wednesday, 26 March 2025 at 21:56:54 UTC+1 JBro63 wrote:
>
>> Thanks Richard.
>>
>> Spent most of the day on this with little progress. Was able to blank the
>> display using SPI but unexpected results when enabling and much flicker of
>> the LEDs evident.
>>
>> Out of curiosity I swapped out the ESP32 dev board for a C3 mini and also
>> tried a ESP82666 D1 which has much improved matters. Alas, ran out of
>> time. I'll re-visit on Friday.
>>
>> Thanks again.
>>
>> On Tuesday, 25 March 2025 at 14:24:07 UTC Richard Scales wrote:
>>
>>> Hello,
>>> Firstly, the reason (and I am NO expert) for expressing it that way was
>>> to remind me that I wanted to store data for 12 x 8 bit elements - ie. 96
>>> bits - as that was enough bits for what I wanted to control - which - in
>>> this case was a bunch of 7 segment panaplex displays with DPs. so, needing
>>> 8 bits for each character (7 x segments plus DP) I could control 12 digits.
>>>
>>> You could just as easily put:
>>>
>>> unsigned char BitArray[12];
>>>
>>> To write any one bit in that array I use:
>>>
>>> void bitArrayWrite(const unsigned int index, const boolean value)
>>> {
>>> if (index > 96)
>>> return;
>>> bitWrite(BitArray[index / 8], index % 8, value); // write the right
>>> bit of the right char
>>> }
>>>
>>> This works out which bit of which byte actually gets set. Once you have
>>> worked out your strategy for knowing how all your display elements are
>>> mapped to the outputs of the shift registers then you could set any one bit
>>> on or off as follows:
>>>
>>> bitArrayWrite(10,1); // set bit 10 on
>>> bitArrayWrite(10,0); // set bit 10 off again.
>>>
>>> Once you have got all the bits set for the display you want then call
>>> the SPI transfer function:
>>>
>>> SPI.transfer(&BitArray, sizeof(BitArray));
>>> digitalWrite(LEpin, HIGH);
>>> digitalWrite(LEpin, LOW);
>>>
>>>
>>> If you are using 2 x HV5530 then change the 96 to 64
>>>
>>> Additionally, you will want to include the SPI library and have this in
>>> void setup()
>>>
>>> SPI.begin();
>>> SPI.setFrequency(10000000L);
>>> SPI.setBitOrder(MSBFIRST);
>>> SPI.setDataMode(SPI_MODE1);
>>>
>>> - Richard
>>>
>>> On Tuesday, 25 March 2025 at 07:37:32 UTC JBro63 wrote:
>>>
>>>> @gregebert
>>>> *Are you driving the HV5530's with the correct signal levels?* I
>>>> believe so - using a CD4504BE set to CMOS.
>>>> *Secondly, are you giving enough dead-time before-and-after wiggling
>>>> the clock signal ?* I'm not including any delay in code but will
>>>> revisit the datasheet and experiment.
>>>>
>>>> @Richard
>>>> Does that help? - Yes, thank you. I won't be able to check until later
>>>> but I think I'm setting the latch low before shifting data in. I have a
>>>> couple of queries please..
>>>>
>>>>
>>>> unsigned char BitArray[96 / 8];
>>>> What is the significance of 96/8 or is this good coding practice?
>>>> (ChatGPT called it 'clarity of intent :)) What was the reason for choosing
>>>> 12 8 bit elements? Are you able to share how you populate the array with
>>>> data for a digit?
>>>>
>>>> Thanks.
>>>>
>>>>
>>>> On Tuesday, 25 March 2025 at 04:19:51 UTC Richard Scales wrote:
>>>>
>>>>> I am using SPI with multiple HV5522's (these work the same as HV5530's
>>>>> as far as this example goes) with total success.
>>>>>
>>>>> The point about the 12V logic supply to these devices is based on the
>>>>> fact that the specification clearly states that they need 12V logic and
>>>>> whilst many have run them at 5V logic with complete success - for the
>>>>> sake
>>>>> of a level shifter I have always played it safe and stuck with 12V. I see
>>>>> that you are using a CD4504BE which I guess would be fine, I use CD40109B
>>>>> with total success.
>>>>>
>>>>> Why use SPI at all? Whilst i am no expert, simply put - instead of you
>>>>> performing the bit bashing via Shiftout or some similar routine, the SPI
>>>>> process leaves the job to the processor which takes the pressure off your
>>>>> code a little - which is never a bad thing. I use Wemos Mini D1's
>>>>> (ESP8266)
>>>>> so not as beefy as ESP32 and on the D1 you are restricted to using only
>>>>> certain pins for the SPI transfer, I believe it may be different for the
>>>>> ESP32.
>>>>>
>>>>> When using SPI transfers I just point the SPI transfer command to the
>>>>> buffer that contains my data and the micro does the rest. So far I have
>>>>> driven 4 x HV55xx devices in a row transferring 128 bits in one fell
>>>>> swoop
>>>>> with total success.
>>>>>
>>>>> There is also a 'thing' about when the latch signal should be toggled.
>>>>> My understanding is that the Latch signal should be generally low and
>>>>> when
>>>>> you want to latch the data to the outputs, set it High then Low again.
>>>>>
>>>>> Here is a snip of my code for sending data out to 3 x HV55xx devices
>>>>> in a chain, note the commented out ShiftOut commands which are all
>>>>> replaced
>>>>> by the single SPI.transfer command:
>>>>>
>>>>> // send data out
>>>>> SPI.transfer(&BitArray, sizeof(BitArray));
>>>>> /*
>>>>> shiftOut(dataPin, clockPin, MSBFIRST, BitArray[11]);
>>>>> shiftOut(dataPin, clockPin, MSBFIRST, BitArray[10]);
>>>>> shiftOut(dataPin, clockPin, MSBFIRST, BitArray[9]);
>>>>> shiftOut(dataPin, clockPin, MSBFIRST, BitArray[8]);
>>>>> shiftOut(dataPin, clockPin, MSBFIRST, BitArray[7]);
>>>>> shiftOut(dataPin, clockPin, MSBFIRST, BitArray[6]);
>>>>> shiftOut(dataPin, clockPin, MSBFIRST, BitArray[5]);
>>>>> shiftOut(dataPin, clockPin, MSBFIRST, BitArray[4]);
>>>>> shiftOut(dataPin, clockPin, MSBFIRST, BitArray[3]);
>>>>> shiftOut(dataPin, clockPin, MSBFIRST, BitArray[2]);
>>>>> shiftOut(dataPin, clockPin, MSBFIRST, BitArray[1]);
>>>>> shiftOut(dataPin, clockPin, MSBFIRST, BitArray[0]);
>>>>>
>>>>> */
>>>>>
>>>>> digitalWrite(LEpin, HIGH);
>>>>> digitalWrite(LEpin, LOW);
>>>>>
>>>>>
>>>>> Then after the data has all been sent, send the latch pin High and
>>>>> then Low to latch the data to the output pins.
>>>>>
>>>>> In the above example, BitArray was defined as follows:
>>>>>
>>>>> unsigned char BitArray[96 / 8]; // space for 96 bits
>>>>>
>>>>>
>>>>> ... so it is a char array with 12 elements.
>>>>>
>>>>> All signals going to the HV55xx are at 12V logic levels (CLK, DATA,
>>>>> LATCH and POL).
>>>>>
>>>>> Does that help?
>>>>>
>>>>> - Richard
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tuesday, 25 March 2025 at 01:25:30 UTC gregebert wrote:
>>>>>
>>>>>> Are you driving the HV5530's with the correct signal levels ? Per the
>>>>>> datasheet, they should be 0 or +12V, but many have been able to run them
>>>>>> at
>>>>>> TTL-levels and that can lead to intermittent problems.
>>>>>>
>>>>>> Secondly, are you giving enough dead-time before-and-after wiggling
>>>>>> the clock signal ? If not, there could be a race condition, which can
>>>>>> get
>>>>>> worsened if not running at 12V logic levels.
>>>>>>
>>>>>> On Tuesday, March 25, 2025 at 4:52:13 AM UTC+7 JBro63 wrote:
>>>>>>
>>>>>>> Hi all.
>>>>>>>
>>>>>>> Ok so some progress. First PCBs have arrived and the K155ID1 IN12
>>>>>>> based clock is almost complete. I also knocked up a very basic breakout
>>>>>>> board for a PLCC 44 pin socket to allow me to start testing with the
>>>>>>> HV5530
>>>>>>> with a breadboard and am having mixed results.
>>>>>>>
>>>>>>> To learn how to use the HV5530 I'm using LEDs connected to the
>>>>>>> outputs, each with a 220 ohm resistor in series in place of the nixie
>>>>>>> tubes
>>>>>>> and the connections from an ESP32 go through a CD4504BE with VDD at
>>>>>>> 12v.
>>>>>>> The LEDs have a common +5V and the POL pin on the HV5530 is tied to +12v
>>>>>>>
>>>>>>> https://reboots.g-cipher.net/time/ disusses how to write data to
>>>>>>> the driver.
>>>>>>>
>>>>>>> With only a single HV5530 connected and using digitalWrite() I'm
>>>>>>> able to blank / light all outputs reliably or target a single output.
>>>>>>> There
>>>>>>> is some flicker if I 'disturb' the wires on the breadboard but
>>>>>>> otherwise
>>>>>>> seems good. Adding a second driver (shared clock & latch pin, DO on
>>>>>>> driver
>>>>>>> one connected to DIN on driver two) causes all LEDs to flicker randomly
>>>>>>> and
>>>>>>> those on the second driver are not in the correct sequence.
>>>>>>>
>>>>>>> Using a separate set of pins for each driver improves things - the
>>>>>>> LEDs on driver two light as programmed - but there is still some
>>>>>>> flickering
>>>>>>> evident on all LEDs.
>>>>>>>
>>>>>>> Is there anything obvious I can change in the above to improve
>>>>>>> matters? I've seen several references to SPI but am 1) unsure why one
>>>>>>> would
>>>>>>> choose SPI over digitalWrite() and 2) it seems more difficult to
>>>>>>> implement.
>>>>>>> If anyone has a very simple example how to use SPI with the HV5530 and
>>>>>>> ESP32 I would be grateful.
>>>>>>>
>>>>>>> Thanks
>>>>>>> On Monday, 10 March 2025 at 11:49:58 UTC JBro63 wrote:
>>>>>>>
>>>>>>>> Thanks Ian, that's really helpful.
>>>>>>>>
>>>>>>>> On Saturday, 8 March 2025 at 08:33:06 UTC Ian Sparkes wrote:
>>>>>>>>
>>>>>>>>> They work fine at 5V. Never had a problem with one at 5V.
>>>>>>>>>
>>>>>>>>> But attention: ESP uses 3V3 and you might need to use a lever
>>>>>>>>> shifter (e.g. CD40109) to make it work.
>>>>>>>>>
>>>>>>>>> On Monday, 3 March 2025 at 20:39:00 UTC+1 newxito wrote:
>>>>>>>>>
>>>>>>>>>> I use the HV5622, which goes up to 220 V, I think there is also a
>>>>>>>>>> PLCC version. The disadvantages are the price and that it should be
>>>>>>>>>> operated with 12V according to spec. However, I never had any
>>>>>>>>>> problems
>>>>>>>>>> using the chip with 5V.
>>>>>>>>>> JBro63 schrieb am Montag, 3. März 2025 um 19:02:56 UTC+1:
>>>>>>>>>>
>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>> Group noob here, about to start build on a few different types
>>>>>>>>>>> of display using Nixie tubes and ESP32.
>>>>>>>>>>>
>>>>>>>>>>> Planning to use K155ID1 initially (as I have a bunch) with some
>>>>>>>>>>> IN-12 and IN14 tubes but want to also try HV driver such as the
>>>>>>>>>>> 5812 or
>>>>>>>>>>> 5530 so would welcome any comment on which is the best one to go
>>>>>>>>>>> for or an
>>>>>>>>>>> alternative. I don't intend to multiplex. Any driver would need to
>>>>>>>>>>> be DIP
>>>>>>>>>>> or PLCC.
>>>>>>>>>>>
>>>>>>>>>>> Have spent many hours looking at the schematics and designs of
>>>>>>>>>>> others, I'm grasping the basics but one frustration and evident gap
>>>>>>>>>>> in my
>>>>>>>>>>> knowledge is how to pick / calculate the correct component and its
>>>>>>>>>>> size or
>>>>>>>>>>> rating for anything other than the most basic circuit.
>>>>>>>>>>>
>>>>>>>>>>> For example, with a 180v supply, calculating the anode resistor
>>>>>>>>>>> for a tube based on the datasheet is straight forward enough as the
>>>>>>>>>>> maintaining voltage and current are known.
>>>>>>>>>>>
>>>>>>>>>>> When looking at something like the HV5812, many seem to use a 60
>>>>>>>>>>> or 70V zener diode with a resistor to keep below the max for the
>>>>>>>>>>> chip but
>>>>>>>>>>> how do you determine the current needed for the driver, diode and
>>>>>>>>>>> load to
>>>>>>>>>>> be able to calculate the current limiting resistor? The diode
>>>>>>>>>>> datasheet is
>>>>>>>>>>> simple enough but I'm lost with the sheet for the HV5812.
>>>>>>>>>>>
>>>>>>>>>>> Thanks.
>>>>>>>>>>>
>>>>>>>>>>>
--
You received this message because you are subscribed to the Google Groups
"neonixie-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion, visit
https://groups.google.com/d/msgid/neonixie-l/35da41db-4db4-4dfc-be3f-e165dd77c707n%40googlegroups.com.
