@Mike - many thanks - I think I'm getting it.
- Richard
On Friday, 3 November 2023 at 11:15:27 UTC Mike Mitchell wrote:
> That's basically what I'm doing for my simple case. The upkeep work is
> done after tubes are energized, where I have significantly more time before
> the next event. The off time is only 200us so I don't do anything during
> the off time. With the fast processors of today you could do "quick"
> things in the off time, but any complex computation I'd put in the longer
> on time. I'm using the FastLED module to drive a short string of LEDs
> during my "DISP_EVEN" time, but calculate what to put into the LEDs in the
> "DISP_ODD" time.
>
> On Friday, November 3, 2023 at 12:43:40 AM UTC-4 Richard Scales wrote:
>
>> @Mike
>> So, I have been getting my head around the whole state-machine concept. I
>> have one I did before - curiously also running on a Teensy but that was
>> because I was worried about speed (I had no idea!).
>> Regardless.
>>
>> Here is what I think my state-machine might look like:
>>
>> Set State to 'Turn Off Displays'
>>
>> :Main program loop
>> If state = 'Turn off Displays' then turn off all the anodes and change
>> state to 'Delay before turn on'
>>
>> //This state exists to allow the injection of any required delay between
>> display of each digit / group of digits
>> if state = 'Delay before turn on' then if there there has been sufficient
>> delay, change state to 'Turn on desired display'
>>
>> //This state works out which cathodes and anodes to set and turns them on
>> if state = 'Turn on desired display' then set the required cathodes and
>> anodes and turn them on and change state to 'Display is on'
>>
>> //This state works out whether the display has been on long enough
>> if state = 'Display is on' then has it been on long enough? If so, change
>> state to 'Turn off Displays'
>>
>>
>> Rest of clock code goes here - and by that I mean the business of working
>> out what to display be it time, date, temp, pressure etc.
>> Obviously everything must be non-blocking so if I want to do fancy things
>> like scrolling messages then I assume that I will need to introduce more
>> 'states' to control all that
>>
>> :End of main program loop
>>
>> I think this differs from yours in as much as I have lumped all the 'rest
>> of clock code' into one place on the basis that it should not be blocking
>> anything and execute quickly.
>>
>> Is this at all wise?
>>
>> - Richard
>>
>>
>> On Thursday, 2 November 2023 at 13:32:57 UTC Richard Scales wrote:
>>
>>> @Mike, many thanks.
>>>
>>> I'll work through that.
>>>
>>> - Richard
>>>
>>>
>>> On Thursday, 2 November 2023 at 12:20:53 UTC Mike Mitchell wrote:
>>>
>>>> My most recent Nixie project uses ZM1032 tubes. They are a 9-pin tube,
>>>> with five cathode pins and two anodes. I'm using direct-drive on all the
>>>> cathodes, but skimp on the tens-of-hours digit where I only drive three
>>>> cathodes instead of all five. I'm using four SN75468 darlington arrays to
>>>> drive the cathodes and two opto-isolators to drive the anodes,
>>>> multiplexing
>>>> the anodes as all evens and all odds.
>>>> I'm using a Teensy 4.1 processor to control everything, though I could
>>>> have used an ESP32. I just wanted something with a lot of pins to handle
>>>> driving the 28 cathodes. I'm not using a timing interrupt at all. In the
>>>> main loop I use the built-in arduino "micros()" call to keep track of the
>>>> time and compare it to the time of the next event. I use a state variable
>>>> to keep track of what to do next. Here's some pseudo code:
>>>>
>>>> if (long)(micros() - timeNextDisp) >= 0 {
>>>> switch(dispstate) {
>>>> case DISP_DELAY_EVEN:
>>>> timeNextDisp = micros() + 200
>>>> turn off all anodes, turn on all cathodes
>>>> dispstate = DISP_EVEN
>>>> break;
>>>> case DISP_EVEN:
>>>> timeNextDisp = micros() + disp_even_time
>>>> turn off all cathodes
>>>> turn on appropriate cathodes
>>>> turn on even anode
>>>> dispstate = DISP_DELAY_ODD
>>>> /* split work between even/odd anodes */
>>>> read PIR
>>>> read GPS
>>>> break;
>>>> case DISP_DELAY_ODD:
>>>> timeNextDisp = micros() + 200
>>>> turn off all anodes, turn on all cathodes
>>>> dispstate = DISP_EVEN
>>>> break;
>>>> case DISP_ODD:
>>>> timeNextDisp = micros() + disp_odd_time
>>>> turn off all cathodes
>>>> turn on appropriate cathodes
>>>> turn on odd anode
>>>> dispstate = DISP_DELAY_EVEN
>>>> /* split work between even/odd anodes */
>>>> read RTC
>>>> read ADC
>>>> calculate time display values
>>>> break;
>>>> }
>>>>
>>>> In my case the even digits are behind a screen electrode which blocks
>>>> their light. I keep the even digits on for about twice as long as the odd
>>>> digits to even out the brightness. I could have increased the even
>>>> digit's
>>>> current by reducing the even's anode resistor, but I decided to keep the
>>>> current the same for even/odd and just increase the "on" time. My timings
>>>> are roughly 10.1ms on for even, 0.2 ms for dead time, 5.1ms on for odd,
>>>> 0.2
>>>> ms dead time, for 15.625 ms per cycle (64 times a second).
>>>> A more typical multiplexing scheme could have two state variables, one
>>>> selects either displaying a digit or discharging the tube, the other
>>>> selects what tube to display.
>>>> On Thursday, November 2, 2023 at 12:56:33 AM UTC-4 gregebert wrote:
>>>>
>>>>> Where it all leads to, I think, is that you no longer need to do
>>>>> custom logic design, and you can skip the need for certain ICs such as
>>>>> realtime clocks, by switching to a software-based design, whether it's
>>>>> RasPi, Arduino, or any other embedded controller.
>>>>>
>>>>> It's gotten so "bad" that I rarely need to use a scope or logic
>>>>> analyzer to hunt down a bug. Several years ago I literally logged-in
>>>>> remotely to the RasPi controlling my NIMO clock and did quite a bit of
>>>>> software development and debug from thousands of miles away.
>>>>>
>>>>> Even now, I'm too lazy to get out of my chair, and go out into the
>>>>> chilly garage to work on my Pi+FPGA board. Instead, I will write a new
>>>>> test
>>>>> and run/debug logic simulations rather than push new (untested) code onto
>>>>> the FPGA to see if it works.
>>>>>
>>>>> On Wednesday, November 1, 2023 at 9:23:25 PM UTC-7 Richard Scales
>>>>> wrote:
>>>>>
>>>>>> Dual Core Processors - now my head really hurts - I mean - I love the
>>>>>> idea but don't think my programming skills are ever going to stretch
>>>>>> that
>>>>>> far!
>>>>>> Just woke early (03.13) - still full of Covid and had a wrestles
>>>>>> thinking session on this during which I reminded myself of all the
>>>>>> success
>>>>>> that I have had with B-7971/ZM1350 Smart sockets - can you see where
>>>>>> this
>>>>>> might be going?
>>>>>> - Richard
>>>>>>
>>>>>>
>>>>>> On Wednesday, 1 November 2023 at 16:29:32 UTC Craig Garnett wrote:
>>>>>>
>>>>>>> I'm using a Pico in my project, I run the tube driving routine on
>>>>>>> one core and everything else on the rest so it doesn't suffer from
>>>>>>> slowdowns.
>>>>>>> I've had to introduce a delay to slow it down to a 1ms refresh!
>>>>>>>
>>>>>>> Craig
>>>>>>> On Wednesday, 1 November 2023 at 15:47:33 UTC gregebert wrote:
>>>>>>>
>>>>>>>> Multiplexing might not be possible in certain software
>>>>>>>> environments. Several years ago I switched to Linux-based Raspberry Pi
>>>>>>>> systems in my projects, and with the unpredictable overhead of Linux I
>>>>>>>> cant
>>>>>>>> rely on the CPU being available every millisecond to update the
>>>>>>>> display.
>>>>>>>> Instead of using Arduino or a custom OS, I add an FPGA or CPLD to
>>>>>>>> handle
>>>>>>>> the time- critical tasks.
>>>>>>>>
>>>>>>>> Just by coincidence, I'm putting the final touches on the software
>>>>>>>> and RTL code for a board I recently had fabbed to do this. I know it's
>>>>>>>> blasphemy, but the first project using this is LED-based...I got a
>>>>>>>> bunch of
>>>>>>>> large 8x8 red/green LED arrays for just under 1 USD apiece and the
>>>>>>>> need a
>>>>>>>> multiplexed driver. Dont worry, there are several nixie and nixie-ish
>>>>>>>> projects in the pipeline that will use this board.
>>>>>>>>
>>>>>>>>
>>>>>>>> [image: raspi_fpga.JPG]
>>>>>>>>
>>>>>>>> On Wednesday, November 1, 2023 at 8:19:48 AM UTC-7 Richard Scales
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> @Paul - I have no idea of the sense of scale and the relative
>>>>>>>>> times taken. If I were to hang another HV driver on the chain with
>>>>>>>>> associated electronics to switch the HV, is there going to be enough
>>>>>>>>> time
>>>>>>>>> to do the following:
>>>>>>>>>
>>>>>>>>> Set the bits for the segments required- I add this step just in
>>>>>>>>> case any settling time might be be required
>>>>>>>>> Set the bits for the segments required and the anode(s) on
>>>>>>>>> Wait for 400us (typical on time for the panaplex segments I have
>>>>>>>>> in mind
>>>>>>>>> Set the digits and anode(s) off again
>>>>>>>>> Loop to the next set of digits
>>>>>>>>>
>>>>>>>>> With 12 individual anodes - there would be 12 passes - one for
>>>>>>>>> each anode that needed to be switched on
>>>>>>>>> If I used 2 drivers (using 3 x 16 bits for cathodes, I could use
>>>>>>>>> bits from the remaining 16 to control the anodes. Thus there would be
>>>>>>>>> only
>>>>>>>>> 3 passes.
>>>>>>>>>
>>>>>>>>> Please stop me when I've gone off the scent (still mid-covid) :-(
>>>>>>>>>
>>>>>>>>> In Summary:
>>>>>>>>> Using the HV55xx for cathodes AND anodes
>>>>>>>>> Given i want 12 characters:
>>>>>>>>> with 1 driver I have 16 segments and 16 spare for the 12 anodes -
>>>>>>>>> easy but slowest
>>>>>>>>> with 2 drivers I have 3 lots of 16 segments and then group the
>>>>>>>>> displays into lumps of 4 (12 characters/3) and still have 16 bits to
>>>>>>>>> control the anodes, of which there will now only be 3)
>>>>>>>>>
>>>>>>>>> Am I anywhere near close with the driver split and the pseudocode
>>>>>>>>> for the ISR?
>>>>>>>>> I was thinking that there should be some uS delays either before
>>>>>>>>> and/or after lighting the segments
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> - Richard
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wednesday, 1 November 2023 at 15:01:20 UTC Richard Scales wrote:
>>>>>>>>>
>>>>>>>>>> @David - many thanks for that caution though there will not be
>>>>>>>>>> (nor ever will there be!) any LEDS for this project!
>>>>>>>>>> @Pauld - thank you - I had thought of that but I was endeavouring
>>>>>>>>>> to keep the code inside the ISR to an absolute minimum so thought
>>>>>>>>>> that it
>>>>>>>>>> would be best handled outside of it and hence separate from the HV
>>>>>>>>>> chain.
>>>>>>>>>> Using SPI.Transfer to send 32, 64 or 96 bits - I guess it all
>>>>>>>>>> happens
>>>>>>>>>> fairly quickly!
>>>>>>>>>> @Benoit - I will look at that - ESP32 - another bridge thus far
>>>>>>>>>> uncrossed!
>>>>>>>>>> - Richard
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wednesday, 1 November 2023 at 14:54:53 UTC Benoit Tourret
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> if an ESP8266 is not enough powerful, the ESP32 will do the job.
>>>>>>>>>>> the ESP_WROVER can be a good platfom.
>>>>>>>>>>> you should have a look to Mose's work on
>>>>>>>>>>> https://neonixie.com/Z57XM6DV2/
>>>>>>>>>>> the code is a bit "strong" as it can be used both on an 6 IV-9
>>>>>>>>>>> clock and a more traditional 6 digits Z57, superb clocks, all they
>>>>>>>>>>> need is
>>>>>>>>>>> addressable LEDs for a more colorful background. and deactivable.
>>>>>>>>>>> the BH1750 luxmeter does a great job and is more sensible than a
>>>>>>>>>>> standard photoresistor.
>>>>>>>>>>>
>>>>>>>>>>> Le mercredi 1 novembre 2023 à 14:38:44 UTC+1, David Pye a écrit :
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> I offer you one caution with the ESP8266 boards - almost
>>>>>>>>>>>> everything is implemented in the libraries in software rather than
>>>>>>>>>>>> onchip
>>>>>>>>>>>> hw.
>>>>>>>>>>>>
>>>>>>>>>>>> That means doing things like updating addressable LEDs can
>>>>>>>>>>>> cause the multiplexing to glitch slightly because of the need to
>>>>>>>>>>>> send LED
>>>>>>>>>>>> data at strict timings. (Or, if you sacrifice led timings to run
>>>>>>>>>>>> your
>>>>>>>>>>>> multiplex interrupt routine, it can glitch the LEDs. ). Chips
>>>>>>>>>>>> which have
>>>>>>>>>>>> DMA/more complex peripherals might avoid this.
>>>>>>>>>>>>
>>>>>>>>>>>> You might get away with it with certain combinations of things
>>>>>>>>>>>> but it was a bit of a pain for me.
>>>>>>>>>>>>
>>>>>>>>>>>> David
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, 1 Nov 2023, 11:54 Richard Scales, <
>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Many thanks Nick.
>>>>>>>>>>>>> Unless anything else comes to light I think I will forge ahead
>>>>>>>>>>>>> on that basis. I want to drive 15 segment panaplex displays (16
>>>>>>>>>>>>> including
>>>>>>>>>>>>> the DP) so plan to use HV5530 or similar driver for the segments,
>>>>>>>>>>>>> probably
>>>>>>>>>>>>> two of them. Then the same MPSA42/MPSA92 driver arrangement for
>>>>>>>>>>>>> the HV
>>>>>>>>>>>>> though there are going to be 5 of those - I might be running low
>>>>>>>>>>>>> on pins it
>>>>>>>>>>>>> using a Wemos - I might consider a port expander for the extra
>>>>>>>>>>>>> pins needed
>>>>>>>>>>>>> - I need to check pins required - I think 4 for the HV register
>>>>>>>>>>>>> chain, 6
>>>>>>>>>>>>> for the Anode switching (two drivers driving a 12 digit device -
>>>>>>>>>>>>> perhaps 5
>>>>>>>>>>>>> for a 10 digit device) plus I want to read a PIR and talk to a
>>>>>>>>>>>>> BMP-280
>>>>>>>>>>>>> sensor. Certainly a Wemos + port expander would do it - might get
>>>>>>>>>>>>> away with
>>>>>>>>>>>>> a Node MCU or similar.
>>>>>>>>>>>>> OK, I just realised that I can use a single 32 bit driver
>>>>>>>>>>>>> with two sets of 16 bits, one going to each bank of displays.
>>>>>>>>>>>>> It still has the same pin requirements of the processor I
>>>>>>>>>>>>> think. That will be a juggling excersise!
>>>>>>>>>>>>> - Richard
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wednesday, 1 November 2023 at 11:10:02 UTC Nick Sargeant
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It’s not difficult. My fumbling attempts at a Nixie clock
>>>>>>>>>>>>>> some time ago used a 4:1 multiplex ratio, using four digits and
>>>>>>>>>>>>>> only one
>>>>>>>>>>>>>> decoder. I used the same MPSA42/MPSA92 driver as your example.
>>>>>>>>>>>>>> My multiplex
>>>>>>>>>>>>>> function was called at 100Hz, so each digit was refreshing at
>>>>>>>>>>>>>> 25Hz. It
>>>>>>>>>>>>>> doesn’t flicker, and (whoa!) it is working 15 years later.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The only mod I had was when switching between digits, I
>>>>>>>>>>>>>> turned the cathode drive off for a period of 20 microseconds,
>>>>>>>>>>>>>> before
>>>>>>>>>>>>>> selecting the correct anode and turning on the next digit. This
>>>>>>>>>>>>>> helped
>>>>>>>>>>>>>> prevent ghosting.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wednesday, 1 November 2023 at 10:14:25 UTC Richard Scales
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Actually - I just looked through an example over at:
>>>>>>>>>>>>>>> https://www.hackster.io/doug-domke/multiplexed-nixie-tube-clock-759ff5
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ... and it all seems fairly understandable, have I
>>>>>>>>>>>>>>> overthought this?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - Richard
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Wednesday, 1 November 2023 at 09:22:03 UTC Richard Scales
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The time has come when I need to get a handle the dark and
>>>>>>>>>>>>>>>> mysterious art of multiplexing.
>>>>>>>>>>>>>>>> I have an understanding of what needs to happen though am
>>>>>>>>>>>>>>>> mostly at a loss of how to implement it.
>>>>>>>>>>>>>>>> I am broadly assuming that I should be using some kind of
>>>>>>>>>>>>>>>> interrupt routine to make the actual display work whilst the
>>>>>>>>>>>>>>>> rest of the
>>>>>>>>>>>>>>>> code gets on with the job of working out what to display and
>>>>>>>>>>>>>>>> when to
>>>>>>>>>>>>>>>> display it.
>>>>>>>>>>>>>>>> Is it even going to be feasible to have some kind of
>>>>>>>>>>>>>>>> interrupt routine that decides what digits to light - set all
>>>>>>>>>>>>>>>> the bits and
>>>>>>>>>>>>>>>> then sets the right anode(s) on and then off again giving
>>>>>>>>>>>>>>>> enough time for
>>>>>>>>>>>>>>>> the persistence of vision to produce a non flickering display
>>>>>>>>>>>>>>>> when using
>>>>>>>>>>>>>>>> something like a wemos D1?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I am thinking that the interrupt routine needs to increment
>>>>>>>>>>>>>>>> which digit(s) is/are being illuminated - set up the right bit
>>>>>>>>>>>>>>>> pattern for
>>>>>>>>>>>>>>>> the cathodes and turn on the relevant anode(s) - wait a little
>>>>>>>>>>>>>>>> and then
>>>>>>>>>>>>>>>> turn them off again.
>>>>>>>>>>>>>>>> My worry is that the amount of time that the displays
>>>>>>>>>>>>>>>> should be left on might be a little too long for the ISR as my
>>>>>>>>>>>>>>>> understanding is that these should be kept as lean as possible.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Do I even need multiple interrupts (my covid addled brain
>>>>>>>>>>>>>>>> is struggling to type let alone contemplate multiple ISR's!)?
>>>>>>>>>>>>>>>> Can the rest of my code run in a non time critical manner
>>>>>>>>>>>>>>>> as it works out what it wants to display where whilst the
>>>>>>>>>>>>>>>> interrupt routine
>>>>>>>>>>>>>>>> merryly illuminates digits based on values which I store in a
>>>>>>>>>>>>>>>> buffer
>>>>>>>>>>>>>>>> somewhere?
>>>>>>>>>>>>>>>> ... or does the rest of my code have to work in come kind
>>>>>>>>>>>>>>>> of state-machine fashion?
>>>>>>>>>>>>>>>> I would expect (hope) to handle display brightness via PWM
>>>>>>>>>>>>>>>> signals to HV Drivers.
>>>>>>>>>>>>>>>> I have no need for cross fade effects either - just basic
>>>>>>>>>>>>>>>> multiplexing of say 10 different multi segment displays. I am
>>>>>>>>>>>>>>>> more than
>>>>>>>>>>>>>>>> happy to break up the displays into say 2 (or more) groups in
>>>>>>>>>>>>>>>> order to
>>>>>>>>>>>>>>>> makes things a little easier.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Can anyone point me in the right direction - ideally with
>>>>>>>>>>>>>>>> some code snippets that I can use as a foundation?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Just to confirm, it is only the general implementation to
>>>>>>>>>>>>>>>> drive the displays that eludes me - the rest of the clock code
>>>>>>>>>>>>>>>> is well
>>>>>>>>>>>>>>>> defined and working well in a direct drive capacity.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The desire to move to multiplexed operation is born out the
>>>>>>>>>>>>>>>> the desire to drive a greater number of displays with a
>>>>>>>>>>>>>>>> greater number of
>>>>>>>>>>>>>>>> segments which could be done via direct drive but I foresee
>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>> multiplexing the displays will simplify the electronics
>>>>>>>>>>>>>>>> required.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So many questions I know. I would be grateful for any
>>>>>>>>>>>>>>>> pointers, thank you.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> - Richard
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>> 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 on the web, visit
>>>>>>>>>>>>> https://groups.google.com/d/msgid/neonixie-l/e576bff1-8d65-4d53-b0cc-2ba5ba574232n%40googlegroups.com
>>>>>>>>>>>>>
>>>>>>>>>>>>> <https://groups.google.com/d/msgid/neonixie-l/e576bff1-8d65-4d53-b0cc-2ba5ba574232n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>>>>>>>>> .
>>>>>>>>>>>>>
>>>>>>>>>>>>
--
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 on the web, visit
https://groups.google.com/d/msgid/neonixie-l/81af8ec0-5f1f-49d5-a486-18d248566e2bn%40googlegroups.com.
