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] <javascript:>>
> 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] <javascript:>
>
>
>
>
>
>
>
>
--
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/79791722-2212-4aee-bf99-379e22462ccc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
