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/ee8ed552-ac50-4b66-a5d5-a09984ee3bf9n%40googlegroups.com.
