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, <[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/1c460717-078e-49e1-a076-9c9fffde311cn%40googlegroups.com.
