@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, < >>>>>>>>>>>> ric...@scalesweb.co.uk> 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 neonixie-l+...@googlegroups.com. >>>>>>>>>>>>> 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 neonixie-l+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/neonixie-l/81af8ec0-5f1f-49d5-a486-18d248566e2bn%40googlegroups.com.