@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/db6428b6-0051-42e4-aa98-880b7b53fc5bn%40googlegroups.com.
