Combining AC & CCL. Loving it.

[grandaspanna]

Many thanks again for this core - I'm super pleased with progress on this little project. In hindsight, much simpler than I originally thought, but isn't hindsight always so clear? :-)

I needed a way to measure the relatively small time difference between two signals (~5us). I had a hunch that I could put the peripherals to use, and first started playing with ways to synchronise two B timers (it's possible), but then found out one of the signals is not as clean as it would like, so needed to fix that.

For example:

You can see channel two tends to hover in the mid-range (not surprising really, since it's the output of a h-bridge driver). I needed to measure the difference between signal one dropping and signal two going max.

So, ran that through the analog comparator (AC) and now got a clean signal to work with.

Finally, married up these two with a state signal from another pin and low and behold the output from LUT0:

The code is super simple too (notwithstanding a current issue with mixing logic & comparator libraries, which I worked around by going directly to registers for CCL).

Plan from here is to feed that into a pulse width capture on TCB0...

[SpenceKonde]

The CCL and EVSYS are miraculous.

They operate insanely fast (setting and even LUT to invert it's output oscillates at like 80MHz or so. Around half that on an odd LUT because you have to use an event channel, Highly temperature dependant and inconsistent between parts, but gives an idea of how fast these things are. And incredibly complex behavior is possible (I think i can make it output WS2811 signals without assembly, and allowing up to 16 bits to be sent at a time without CPU action - it involves a TCD, a TCB or twp, and several CCL modules, and an SPI interface in slave mode with the SCK signal generated on chip and physically connected to SCK, then with one of several methods to latch the 0/1 from MISO to select between the TCD0 WOA and TCD0 WOB which will respectively output 0's and 1s). The main advantage of course being that you can be calculating the next frame while sending the current one. And the higher the CPU clock , the more you gain from this: at 16 MHZ there are 160 clocks per byte In interrupt-driven mode, with 6 (entering interrrupt) + prologue (push r1, push r0 in r0,SREG push r0, push r26, push r27) 6+ 6 (then 2x lds to load the pointer to the next pixel) +2 to load that pixel with postincrement of pointer +2 to output, +4 to write the pointer back, epilogue of 5 pops and an out for 11. and 4 to RET) So 48 clocks per byte, so 5/16ths of our clocks would be occupied with that. Better than nothing but.... say we run at 40 MHz (exteneded temp range parts will generally do this at room temp with ext. crystal). The number of clocks per 10us byte transmit stays constant, but now you're using only 1/8th of the clocks to periodically throw in the next byte, and you have 1050 clocks to generate each pixel. This in turn means that it becomes practical to have nearly the theoretical maximum frame rate possible with an 800 khz signal. My goal is 1000 LEDS at 30 FPS, while calculating the next frame and listening for an RF signal.and responding to user input.