@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/1d8e36b4-b316-45b8-b0d4-31e8ba4cc9d1n%40googlegroups.com.
