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/ac7db76a-d5ef-4ee8-aaf5-f17ee4e640aen%40googlegroups.com.
