Very nice work - a lot more sophisticated than I dare to dream to achieve! - Richard
On Tuesday 9 January 2024 at 08:55:39 UTC Jon wrote: > >For the hardware I was thinking that one of the 595's would connect to > low sided drivers (MPSA42 etc) to ground the required cathodes whilst the > other 595 would connect to high sided drivers (MPSA42+MPSA92 etc) to > connect the >desired anode to the HV supply > > Yes, that approach works really well. See this clock from a few years > back: https://youtu.be/4FnxWsp58EM > > Each six tube row is a 2 x 3 multiplex controlled by a pair of 595s > driving discrete transistor high-side drivers for the anodes, low side > drivers for the decimal points and a pair of Russian K155ID1 (near > equivalents of the 141) to decode and low side drive the digits. The > K155ID1 route was chosen instead of a regular logic decoder and discrete > low side drivers to save board space without getting into lots of fiddly > SMD stuff. And then each of the seven rows simply have their pairs of 595s > hooked up to make a 14 device total daisychain that controls the whole > display. There's a single PIC18 running the show which bit blasts display > refreshes down the daisychain as well as managing USB comms, talking to a > DS3232 RTC - plenty of compute time and power to do that. The nice thing is > that this approach reduces all the display composition and management to > software - multiplexing, cross-fading, all the funky display animations > shown in the video; it's all just a matter of figuring out what bits to set > when in the 144 bit output stream. Took me right back to my programming > roots writing for bit-mapped displays on 8 bit micros in the early 80s! :) > > Jon. > > > On Tuesday, January 9, 2024 at 5:03:52 AM UTC Richard Scales wrote: > >> @ David - that is an interesting idea - I did that already in another >> design where I wanted to reduce the workload on an ESP8266 so I used a >> Teensy running a state machine based piece of code to do the heavy lifting >> - the ESP8266 just fed data to the Teensy over a serial connection - I kid >> you not - it works really well - though that is all running a lot slower >> than what I need for this multiplexed display project. >> I am actually hoping to do it all on ESP8266 this time round with a >> couple of 595's driven via SPI transfers and some state-machine based code >> which manages the display. >> >> The next part of my planning is to gain the understanding of what delays >> are required and where. >> >> I am broadly assuming that I need to do things in the following order: >> >> { >> Set the cathodes for the number to be displayed >> Delay before turning on anode >> Set the desired anode on >> Wait for the desired 'anode on' time >> Set the anode off >> Wait for the desired 'anode off ' time >> Increment the current anode number (reset to 0 if we got past the max) >> } >> >> In this way, the anode on and off times can be set - thus controlling >> fading etc >> >> My next question is - do I need to wait at all after setting the cathodes >> up and before turning the required anode on? >> >> For the hardware I was thinking that one of the 595's would connect to >> low sided drivers (MPSA42 etc) to ground the required cathodes whilst the >> other 595 would connect to high sided drivers (MPSA42+MPSA92 etc) to >> connect the desired anode to the HV supply. >> >> I was then thinking that all anodes and cathodes would connect to >> something like 80V via a suitable resistance - as per the Bally schematic >> for driving multiplexed panaplex displays in pinball machines. >> >> As detailed here: bally_as2518_15_6digit.pdf (pinitech.com) >> <https://www.pinitech.com/retrofit/schematics/bally_as2518_15_6digit.pdf> >> >> Am I anywhere near the right track on any of this? >> >> - Richard >> >> >> On Friday 3 November 2023 at 12:12:03 UTC David Pye wrote: >> >>> Hi, >>> >>> Next time I do a clock, I am going to separate my hw into 2: >>> >>> A cheap ARM based MCU using SPI/DMA to do multiplexing and dimming, with >>> enough IO to drive anodes and cathodes via individual transistors, with >>> Comms to the main MCU via spi or i2c. >>> >>> An esp32 or esp8266 to provide application logic >>> >>> Using the ARM MCU and transistors solves the issues with the HV driver >>> ICs needing 9v and both the STM32 and the esp8266 can communicate with 3v3 >>> signal levels and will be cheaper albeit with higher component count. >>> >>> David >>> >>> On Fri, 3 Nov 2023, 11:15 Mike Mitchell, <mmit...@gmail.com> 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+...@googlegroups.com. >>>> >>> To view this discussion on the web, visit >>>> https://groups.google.com/d/msgid/neonixie-l/1bc508d5-1f0c-4b6e-af2f-3f9a0092ecc6n%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/neonixie-l/1bc508d5-1f0c-4b6e-af2f-3f9a0092ecc6n%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/0c018277-a937-4dd8-9ddc-db23d4bb86edn%40googlegroups.com.
