Dirt Simple I/O Board for Elementary LUT Demo

[mosqu-ito]

//               DIRT-SIMPLE I/O BOARD
//                       for
//                ELEMENTARY LUT DEMO
//     suitable for elementary minds such as mine

// I admire people who can code for multiple chips simultaneously, I'm just not one of them...
#include "MyAliases3226.h"
#include "MyGeneral3226.h" 
#include "MyPins3226.h"
#include "MyChannels3226.h"
#include "MyLuts3226.h"
// ...where I hide my sins.

// Please try to forgive my annoying aliases, I do realise that I'm not playing well with others.
// Here, for instance, "defU8" means "constexpr byte"...
defU8 truthAnd   = 0b10000000;
defU8 truthOr    = 0b11111110;
defU8 truthXor   = 0b10010110;
defU8 truthAndOr = 0b11100000;

// ...and here, "ChipPin03" means "PIN_PA5" etc...
defU8 LED3 = ChipPin03;    // Native Alternate
defU8 LED2 = ChipPin08;    // Native Default
defU8 LED1 = ChipPin05;    // Native Default
defU8 LED0 = ChipPin02;    // Native Default

defU8    J32  = ChipPin14;   // Native
   defU8 J31  = ChipPin13;   // Native
   defU8 J30  = ChipPin12;   // Native
defU8    J22  = ChipPin09;   // Native
   defU8 J21  = ChipPin10;   // Native
   defU8 J20  = ChipPin11;   // Native
defU8    J12  = ChipPin19;   // via Ch.2
   defU8 J11  = ChipPin06;   // via Ch.1
   defU8 J10  = ChipPin15;   // Native
defU8    J02  = ChipPin18;   // Native
   defU8 J01  = ChipPin17;   // Native
   defU8 J00  = ChipPin04;   // via Ch.0

void setup() {

   pinMode(LED3,OUTPUT); pinMode(LED2,OUTPUT); pinMode(LED1,OUTPUT); pinMode(LED0,OUTPUT);

   pinMode(J32,INPUT_PULLUP); pinMode(J31,INPUT_PULLUP); pinMode(J30,INPUT_PULLUP);
   pinMode(J22,INPUT_PULLUP); pinMode(J21,INPUT_PULLUP); pinMode(J20,INPUT_PULLUP);
   pinMode(J12,INPUT_PULLUP); pinMode(J11,INPUT_PULLUP); pinMode(J10,INPUT_PULLUP);
   pinMode(J02,INPUT_PULLUP); pinMode(J01,INPUT_PULLUP); pinMode(J00,INPUT_PULLUP);

   // I confess, I have perverted a few of the facilities afforded to us by the Great One; may my soul find mercy...
   EnableLutPin(LED3); EnableLutPin(LED2); EnableLutPin(LED1); EnableLutPin(LED0);
   
   EnableLutPin(       J32);
      EnableLutPin(    J31);
      EnableLutPin(    J30);
   EnableLutPin(       J22);
      EnableLutPin(    J21);
      EnableLutPin(    J20);
   ChannelFromPin(2,   J12); LutFromChannel(1,2, 2);
      ChannelFromPin(1,J11); LutFromChannel(1,1, 1,true);   // LUT#,Input#, Channel#,NeedsRouteB (default is false)
      EnableLutPin(    J10);
   EnableLutPin(       J02);
      EnableLutPin(    J01);
      ChannelFromPin(0,J00); LutFromChannel(0,0, 0);
   
   StartLuts(truthAndOr,truthXor,truthOr,truthAnd);         // Lut3,Lut2,Lut1,Lut0

   }


void loop() {}

[SpenceKonde]

IMHO: The Microchip docs people lack any sort of creativty with regards to the CCL. Using the CCL as logic glue is like tying a helicopter to the ground on a hot day and using it as a fan.

The point of the CCL is that it can use internal inputs that aren't otherwise accessible, and need not be clocked, ie, it can be completely asynchronous. Both of those are imcredibly powerful. That's why I feel that the EVSYS and CCL are the most powerful peripherals on modern AVRs without even a doubt. You can remap PWM. Switch between PWM channels, and if you're willing to jumper pins, it's even morepowerful.

[mosqu-ito]

OMG, I'm in the presence of the Great One himself!
Yes, I was careful to say "elementary" because here I'm just twiddling the inputs.
My pea-sized brain felt that would be the place to start. But even getting that far
immersed me in the datasheet and IO header files enough that I can see the great
possibilities. And seeing that the input twiddling does work correctly may well
give me the confidence to go further. Thank you!

[SpenceKonde]

https://github.com/SpenceKonde/megaTinyCore/blob/master/megaavr/libraries/Logic/Tricks_and_Tips.md might be an interesting read for you.

[mosqu-ito]

Ahhh... yes indeed. I have just recently learned to work both ends of the six channels, and with those, the internal connection possibilities do seem pretty awesome, as per the read just now, getting feedback from an odd numbered LUT. That one I was able to wrap my head around, the rest I'm still digesting. :D

[mosqu-ito]

It's beginning to sink in (the interesting read). First time through, I failed to twig to the fact that the lookup table is first cousin to an 8:1 multiplexor, and I'm old enough to remember implementing functions with multiplexors. For sequential functions my first instinct would have been to bring the feedback in through the broad-side inputs (which aren't really inputs in the case of a table) but I can now see how it works well via the select inputs too. Suddenly the lut-only latches make perfect sense. Looking at the RS I can see that your example has active-high inputs like a pair of cross-coupled Nors, and that it would be easy enough to change the truth byte to make it active-low like cross-coupled Nands. In the early days it was common to debounce SPDT switches with an RS latch, and active low is better suited to how one typically wires a signal switch. So now I see my first practical application: Hardware debouncing with no (external) hardware, and with your odd-Lut feedback trick, that's a lot of debouncing. Thanks for getting me started down this path!

[SpenceKonde]

Here's a quick thought to get your mind wrapped around just how crazy the CCL and event can be.

Take SPI1 on a 48 or 64 pin DX chip and make it slave, buffered mode, and turn off that stupid dummy bit thing.

jumper a
LUT input pin to MISO, Make that LUT switch between two channels of TCD. Override the output of TCD so that it is either 0110 or 0100.
Use those events, between the second and third section, that event triggers a pin jumpered to SCK to rise, and between the third and fourth to fall, with a a few added timers... you have a WS2812 output generator, that doesn't tie up the CPU except to toss a byte into the buffer every 8 bits. You can now use the time that the chip it outputting the signal to do the calculations of what colors to output.

Previously, if your spec is 30 FPS, 1k pixels, that means 33kpixel per second, meaning only 9% of the time could be used to generate the pattern of data to send. suddenly that increases to 80-90% of the time, allowing more complex patterns (I am thinking of this in particular because I have an application that would, even clocked at 40 MHz, struggle to do 15 fps at 500 pixels, not even counting the user interface.

You can do CRAZY things with the CCL and event systems yo.

[mosqu-ito]

It's gonna take a while for THAT to sink in.
But you're a good teacher and I do have a thing for colorful blinky lights, so, there's hope.