And you said I was confusing YOU with rotary encoders... Yeah, go get your "WAVE THING", and take your sweet time.
How did you become a moderator anyway? I've always been curious.
this is clearly a rathole, but to elaborate for a second. here's the firmware model i have in my head:
we have a 2d matrix of chars, let's call it fbuf, representing the display state of the LED matrix (ie, fbuf
[j] = "brightness of the (i,j)th LED"). we get to execute one firmware loop on the micro.
foreach tick:
update fbuf;
scan the LED matrix, updating the PWM registers with the contents of fbuf
poll the keyswitch matrix
dump active keys onto usb bus
but updating fbuf could take an arbitrary amount of time, depending on how much computation we'd like to do to yield the next display frame. because we only have one flow of control on the micro, this all has to happen sequentially, and if we scan the LED matrix too slowly, we will have flicker on the LEDs, or worse, we'll miss a keystroke.
so imagine instead that the host computer can write directly into the memory at fbuf (can you do DMA over usb? who knows, but let's pretend). then, the loop becomes simpler:
foreach tick:
scan the LED matrix, updating the PWM registers with the contents of fbuf
poll the keyswitch matrix
dump active keys onto usb bus
soarer seems confident that we will have zero flicker if the firmware loop looks like this. to mutate fbuf, then, it suffices to write a simple driver on the host machine that dumps data into it.
finally, soarer is nixing my 2 micros suggestion because communication between them is needlessly complicated. coming from a high-level background, my model of multiprocessing is either a) shared memory or b) message passing. while these abstractions can be implemented at a micro level, there's a _lot_ of engineering required to build those abstractions, and there's no ready platform that does that engineering for us. basically, it's a lot of added complication for no particular reason, so his conclusion is quite sound.
