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/c2b560f6-9242-4992-9ff3-bdd56d39968fn%40googlegroups.com.

Reply via email to