Thanks again for the comments, Ian. #1 - Yesterday I removed the pin numbers that were passed as parameters. I'll work on removing digitalWrite() by Monday or Tuesday.
#2 - Easily done at the same time. It's probably best to remove the 'vibrate' code that is more of a kluge than good programming, and do fades correctly. #3 - Would the overhead to assemble a data buffer be worth the cycles to do it? I'm thinking about separating the data lines as Carl mentioned. Even if that's done, three bits could be located with an offset and written to all three HV5530s with one clock write. That could be done on your board with two trace cuts and four jumpers. The extra level shifters are there. What do you think about that? #4 - That's beyond my understanding. I was thinking of using a hardware interrupt to update the display, but it would require some changes to the menu function as it runs in its own loop.And that is on the list of changes to be made. Mitch On Thursday, September 3, 2015 at 5:28:14 AM UTC-4, Ian Sparkes wrote: > > Hi Carl, Mitch, > > A couple of thoughts in decreasing order of ease of implementation: > > 1) Software only: As a first step I'd bypass the digitalWrite() and > control the port directly. I agree that assembler is probably too much for > the first round of improvement. I see that your "dataPin" is a constant. > > It's best not to pass it as a parameter: it can be referenced from > directly within the "shiftItOut" code and the variable referencing can be > skipped. I'd also do away with the number of bits variable. It's a known > constant in the code which is required, and you can just call the right one > straight away, skipping another comparison. > > I'd also tend in the longer term to prepare a full static "data packet" to > be shifted out and use the "shiftItOut" routine to just dump that to the > output. This section is the innermost loop and needs the most optimisation. > > 2) Software only: I was mulling this over, and it occurred to me that out > of each 10 cathode group, only 1 cathode is lit at a time (perhaps two if > you implement a cross fade that way - but I wouldn't). This means a lot of > the time you're only twiddling the clock line without toggling the data > line. You're *nearly* doing this in "shiftItOut", but we have: > > if (val == i - 1) digitalWrite(dataPin, HIGH); > else digitalWrite(dataPin, LOW); > > and it might be better as: > > if (val == i - 1) digitalWrite(dataPin, HIGH); > else if (val == i) digitalWrite(dataPin, LOW); > > in order to save 8 writes to the data pin at the cost of 8 comparisons. I > don't have any benchmarks about the speed of a digitalWrite as opposed to a > comparison, but I'd be surprised if they were comparable. > > 3) Software only: We can do quite a bit of software optimisation in the > code, without much restructuring. For example in "displayD" there are some > variable declarations which we could do away with, and we tend to be > shifting variable values around quite a lot. I would personally prefer > something along the lines of a "display buffer" where changes are made when > required. For example we only need to change the hours when they really > need changing. This is the next most inner loop and needs the next most > attention. > > 4) Software and hardware change: The most obvious improvement I can see > would be to drive the 5530 clock from a PWM output in CTC mode, and use the > ISR to do the shifting. As a nice side effect, it would have an easily > programmable (in software) refresh rate. Unfortunately, I think you are > using pin 4 as the clock pin and this is not PWM capable (unless I am > looking at the wrong data sheet). > > Just thoughts... Happy to discuss... > > Ian > > > On Wednesday, 2 September 2015 14:33:51 UTC+2, H. Carl Ott wrote: >> >> >> On Tue, Sep 1, 2015 at 1:34 PM, Mitch <[email protected]> wrote: >> >>> >>> And I have a question - For the IN-18 version, would it be better to >>> connect all three HV5530s to the processor using separate data, latch, and >>> clock lines? The processor does have enough spare pins and the code changes >>> are trivial. >>> >>> Mitch >>> >>> >>> >> If you are using level shifters, then you will need additional hardware >> on all the lines. >> I would not bother, >> >> There is a possible advantage to just using separate data lines, while >> keeping the CLK/LE/BLANK lines paralleled. You could clock out the data in >> 1/3 the time. >> >> But, it's a trade off when you are bit-banging the serial data. >> The determining factor is how fast you can shift the data, set io ports >> and then toggle the clk line in software. >> >> I did it all in an ISR written in AVR assember. I clock out 96 bits of >> buffer data into 3 chained HV5522s. The ISR fires at 4096hz off a timer. I >> get very smooth cross fades. >> I spent a lot of time optimizing those inner loops, shaving cycles >> wherever possible . >> >> I doubt that I could actually do it much faster if the data lines were >> separate. I'd now have to de-mux the data and manipulate 3 IO lines before >> I could toggle the clock line, All those extra cycles take time. >> >> I think you'd gain more by tweaking the code a bit, using the SPI >> hardware, or just by running the AVR at a higher clock rate. >> >> >> carl >> -------------------------------------------------------- >> Henry Carl Ott N2RVQ [email protected] >> >> >> >> >> >> >> >> > -- 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 post to this group, send an email to [email protected]. To view this discussion on the web, visit https://groups.google.com/d/msgid/neonixie-l/1fc94a2a-3898-4b7d-a57f-a87e128e9fe2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
