CommonSense: matrix LCR meter with a HID interface

[DMA]

Apologize DMA... boards go out Wednesday. I got pulled away last evening unexpectedly until Tuesday evening. Packed, but laying dormant

It's better actually - my home is cursed with "delivery man disappears before you react to knock".
Going back next Thursday, don't want to hit 5 working days after initial delivery and see package bouncing.

[DMA]

Playing with the idea of QFN-56 package.

qfn-pcb-full.png (35.47 KiB) Viewed 9072 times

..got carried away a bit.

The grey square is 8x8mm. So, board height is 550 mil (0.55" ~ 14mm), and width is determined by connector size (controller itself is about 1 inch wide, everything else is connector and it's traces).

J1 is USB/initial programming (cypress has a nice feature - USB pins are also SWD, so USB connector can be used for flashing the bootloader. Additional pins are there because I have a kitprog which doesn't support power-on acquisition and needs access to target's reset pin.)
J2 is xwhatsit-compatible extension header.

33 pins on the board connector is to accomodate 32 rows or columns (any order) plus ground on PCB to cover 29 pins needed for beam springs. I will correct the mistake of the leftmost pin hanging in the air - supposed to be grounded or even deleted altogether. PCB ground graces in my tests seem to be irrelevant - I'll do the "PCB ground traces removed" test to confirm this when I'll get PCBs I can dedicate to !!SCIENCE!!.

[__red__]

Since we're playing "How low can you go"... consider tag-connect for your programming header...

You can find diptrace libraries for the parts in my github repo (they sent me free cables to test with and I <3 them).

[DMA]

Since we're playing "How low can you go"... consider tag-connect for your programming header...

You can find diptrace libraries for the parts in my github repo (they sent me free cables to test with and I <3 them).

tag-connect is cool. But cypress pushed it one step further already - no additional connector is even needed.

In other news - chips are shipped already and PCB went to fab.
So I'll probably even have something working in a week.

[DMA]

While prototype PCB and chips are in transit - thought I'll show you guys some pictures.

So, I've converted the controller to a single-row two-column keyboard for laughs. While useless as a keyboard, this thing has >100kHz scan rate and so allows for more detailed observations.

So, this is how a typical VERY QUICK keypress looks like. It takes about five milliseconds for the paddle to reach the PCB, and another ten to fly back to the initial position. Those times may even be longer - sensor may just lose the sight of the paddle. Don't think that's the case though - if it wasn't so, I wouldn't see slowing down on the way back. Someone smarter than me can even calculate the paddle speed from these data (If someone volunteers, I can provide a CSV with <1us temporal resolution).

15us-slow.png (61.21 KiB) Viewed 9012 times

If you really snap it - you can get stuff moving a bit faster

15us-fast.png (60.26 KiB) Viewed 9012 times

The fluctuations of the steady state you see is our good old friend 60 HZ AC.

This is 1ms/div zoom of the keypress. The peak is when the paddle is pressed REALLY HARD to the PCB by inertia.
As you can plainly see, there's no bouncing whatsoever* (in fact, on the "fast" shot there is, but it's less than half of overshoot, nothing to speak about).

head.png (63.01 KiB) Viewed 9012 times

And this is the departure, at the same 1ms/div. The zoom is from the "slow" shot, so the actual liftoff is somewhere near the end of the second vertical mark. Thing to note is the notch at the end is not always there - it may correlate with a fact that my test keyboard doesn't have any foam so the key assembly is mobile. It's the cause of the positive slope you see before the keypress on the "slow" shot.

tail.png (61.39 KiB) Viewed 9012 times

[mik]

Will the beamspring version be compatible with the displaywriter keyboard or just with the regular beamsprings? XWhatsit's beamspring controller comes in a special version for the displaywriter because it has a slightly different matrix I believe. I wish I could loan you my displaywriter, but I'm located in The Netherlands

[Ratfink]

If Displaywriter compatibility is indeed a problem, I have one in NC, which is about half as far away from you as the Netherlands.

[DMA]

If Displaywriter compatibility is indeed a problem, I have one in NC, which is about half as far away from you as the Netherlands.

Special matrix is not expected to be a problem - in fact, I expect the same PCB to be used for all versions, beam spring and buckling spring. I think now of having a purely passive piece for an adapter - a piece of PCB with that big 30 pin connector soldered to it.

Fitting the controller so it doesn't touch anything inside is a possible problem - but that can, hopefully, be solved with no displaywriter occupying my shelf.

[DMA]

It looks like I've managed not to fuck up soldering that QFN, and the chip works.
Didn't solder 0.1uF cap - works perfectly without.

https://www.instagram.com/p/BRfPL0HB_C5/

It senses something, but figuring out how good it is will have to wait till tomorrow.
As is determining the power quality.

[Vizir]

If you need any more volunteers, I'm willing to help out. Have a displaywriter and a F122 which are ready to test. Somehow I missed this thread before and just stumbled upon it.

Sent from my Nexus 6P using Tapatalk

[DMA]

If you need any more volunteers, I'm willing to help out. Have a displaywriter and a F122 which are ready to test. Somehow I missed this thread before and just stumbled upon it.

Thanks for the offer!
lot_lizard's package is supposed to be on my porch any day now, that should cover my beamspring needs.

If you can send me ( dma@ya.ru ) some detailed photos of the displaywriter's insides around that PCB edge connector - that would be helpful. In particular I want to figure out how much space there is between card edge and {case, keyboard frame}.

As you can see, PCB can be made pretty small, but there may not be enough space still. The goal is to have a single PCB for everything with 2.54mm pitch single row connector and one passive adapter to 3.96mm pitch 30 pin connector, and handle everything else in software (Yes, all pins on that connector can be rows, columns or unconnected).

[Vizir]

If you need any more volunteers, I'm willing to help out. Have a displaywriter and a F122 which are ready to test. Somehow I missed this thread before and just stumbled upon it.

Thanks for the offer!
lot_lizard's package is supposed to be on my porch any day now, that should cover my beamspring needs.

If you can send me ( dma@ya.ru ) some detailed photos of the displaywriter's insides around that PCB edge connector - that would be helpful. In particular I want to figure out how much space there is between card edge and {case, keyboard frame}.

As you can see, PCB can be made pretty small, but there may not be enough space still. The goal is to have a single PCB for everything with 2.54mm pitch single row connector and one passive adapter to 3.96mm pitch 30 pin connector, and handle everything else in software (Yes, all pins on that connector can be rows, columns or unconnected).

I am out of town till Tuesday. I'll take some photos when I return.

Sent from my Nexus 6P using Tapatalk

[DMA]

Okay.

Over the weekend I've figured out how much I can skimp on bypass capacitors, and found out one bug in PCB.
Also learned how do solder wires to 0.4mm pitch QFNs (Thank cypress for solderable QFN pin sides!)

Details:
Left one of 2 VDDD pins hanging - that's a power rail for the digital part of the chip. Of course it was the closest one to USB pins, so powering them. Caused LOTS of noise on the power rail - like 200mV drops whenever USBIO tried to drive the bus (which is CONSTANTLY).

Figured out that I skimped on bypass capacitors a bit too much and that charge bank capacitors for the ADC ext refs are good idea even when that reference is VBUS (may be "especially when", dunno )

So, lots of very fine-pitch soldering (god bless that guy who sold 0.6mm STTC-045 with his metcal to me!) and scoping, fun weekend
Results:
1uF cap 8mm from the chip (C5 position), VDDD disconnected: noise floor 30mV, spikes up to 150mV, 20mV drops on USBIO driving impulse edge.

0.1uF cap instead: 0-150mV
0.1uF, no board connected: 0-50mV

+1uF soldered to VDDIO0 (top left on PCB): 0-15mV, 20mV drops.
+0.1uF to VDDIO0: 0-5mV, 7mV drops

VDDD resoldered to bus, 1uF @C5 only: 0-15mV, 30mV drops.
0.1@C5, 1@C6, 1@VDDIO0: 0-5mV, 4mV drops.

+board: 25-120mV, 4mV drops.

..and theeeen I discovered that I only connected chassis ground, not PCB grounds (not too long into the process, fortunately)
Final results - 15-45mV, same 4mV power drops every 1us or so due to USB.

Weakest key produces ~90mV, so there's enough SNR. Especially if you pass the readings thru IIR filter.

Also noticed that I read first column a bit early, when drive line barely reached 3V - which greatly diminished SNR. Had to code in a delay (It's actually a single-shot PWM. So delay is programmable! ) before driving the row and firing ADC sequencer.

Also various small changes
* IIR implementation with integers and no multiplication which doesn't eat precision (i.e. proper implementation),
* moved scanning to interrupts for fun and profit - scanrate is now ~5.2kHz and I can, in principle, implement noise reduction based on signal form I get (i.e. to discern between noise and incoming flipper)
* introduced rampdown delay because controller was switching on the next row too fast as a consequence of the previous. No PWM was needed there, just finding the place to get turn off signal which fires not too soon.
* made sure that _both_ ADCs complete DMA transfer before generating a "Scan complete" interrupt. Just in case.

Need this all to simmer for a day or two and then there will be a production PCB revision sent to oshpark.

[DMA]

Got a 5251 beam spring today, generously loaned by lot_lizard. Complete with xwhatsit controller Rev4.
Typed on it for about an hour. That fly plate hitting the key stem on activation is a special kind of tactile joy. Didn't notice that before.

It looks like this now:

IMG_20170318_231725.jpg (115.4 KiB) Viewed 8881 times

So, beam spring turns out to be quite a different animal.

Spoiler:

First, switches are "normally closed" - fly plate is gently pressed to the PCB. So the shortest keypress I managed to get looks like this:

DS1Z_QuickPrint40.png (39.82 KiB) Viewed 8881 times

Well, shortest complete one. Because you can get this if you're fast enough:

DS1Z_QuickPrint39.png (39.3 KiB) Viewed 8881 times

And if you manage press it even faster you can get a very shallow dip - there will be no click, but one could sense disturbance in the Force. Unfortunately there was no USB stick in the scope in that moment and I couldn't reproduce it later

Second, it's bouncy. It's bouncy on the way up - lift your finger too quickly and you'll get this:

DS1Z_QuickPrint32.png (69.7 KiB) Viewed 8881 times

If you lift it slow and steady - it will be much more smooth though:

DS1Z_QuickPrint34.png (70.12 KiB) Viewed 8881 times

Third, you can influence the slew rate - that initial dip can be made 3 to 20 milliseconds long, the more vigorously you're pressing the key the faster signal falls. The snappiest version:

DS1Z_QuickPrint26.png (70.13 KiB) Viewed 8881 times

The signal is pretty strong - ~300 mV resting, ~80mV pressed. There is some crosstalk - pressed key pulls both neighboring columns up a little. That's AWAY from "pressed" direction so it actually helps.

DS1Z_QuickPrint42.png (49.47 KiB) Viewed 8881 times

DS1Z_QuickPrint43.png (51 KiB) Viewed 8881 times

..crap, the last one supposed to have 3 keys in different columns pressed Anyway, you get the idea. Superimpose the images and you'll see what's going on around the pressed key.

Scan rate, as you can see, is healthy 7.77kHz. This long beast doesn't mind to be driven by rows - I was afraid that too much keys on a row will make it hard to sense, but turns out it's quite fine. Problems are still possible with one of those keyboards that required colskips in xwhatsit - but at this point I'm pretty sure there won't be any.

So, single unified hardware for all IBM capacitive keyboards is now a reality. Haven't tried topre, but don't see why it wouldn't work with those either.
If only someone would write software for it. Turns out building hardware is much more interesting.

I've implemented "normally closed" switches in the firmware (and FlightController) today, made the matrix 24 columns long and discovered a bunch of hardcoded values because of that

The plan is to make hardware _less_ configurable from the utility - because, in all fairness, if you're unplugging the controller from buckling spring keyboard and plugging it into a beamspring - you might as well recompile.
Changing matrix dimensions on the fly is not the brightest of ideas either - layout and noise floor data will be screwed up beyond repair and you're better off starting from tabula rasa. As a side effect it will make code smaller (and faster, not that anyone needs that on 48MHz MCU).
Just need to know to squint and see what stays. Layouts definitely stay - I do want to use KLL for layouts and macros, but I value ability to change key mapping without recompiling firmware too much (because threshold data MUST be updated in flight - how layouts are different?). May be in some future release.
Don't get me wrong, this needs to be done - I'm a strong believer in not maintaining more code than absolutely necessary, and one gets a free console with kiibohd after all - just not this time.

Also need to get rid of those bit fields in unions - what was I thinking, srsly? There were lots of warning compiler can do with field order whatever it wants. Turns out firmware and host utility interpret it differently - so fuck it, bitmasks it is.

Also to pull everything from damn binaries to text files. Actually did it for USB descriptors yesterday. Unfortunately can't just include them - one alternative would be "user-supplied descriptors", but that would make it PAINFUL to update the USB component. Also it's not ideal - it's damn XML (Cypress, of all things - why you guys love the fucking XML so much? It's ugly and unreadable. Granted, YAML is even worse, but why not JSON?), and also everything in that XML is IN DECIMAL (yeah. Binary data too. Evvvvvrything.). But it's better than .cysch blob.

Not that much left to do.

[alh84001]

It's all coming together really nicely. I wonder which will happen first - me getting a beamspring, or commonsense going into production

BTW, maybe an update of first post in this thread is in order.

[seebart]

Once again, this is great work DMA. Thanks!

[dfj]

Damn - your work is inspirational - made me mess around with my scoping and see if I couldn't replicate one of my claims - namely, that after a few tries, I can get off a double tap on F within a 16ms window.

It's been a long time - this was harder than I expected, and I'm getting some 60Hz noise I need to clean up. Bah. At least I'm haxing again. Ty DMA, yer a godsend.

dfj

[DMA]

You're welcome, dfj. It warms me to see you released from the grip of whatever held you from doing things you love. Good luck on fighting that noise. Looks like it's not 60Hz - it's something much higher frequency, badly modulated. Those huge needles betray it. Bad input filter on a PSU nearby comes to mind.

Pretty impressive, errrhm, keymanship you've got there. Couldn't ever get the buckling spring down for shorter than 10ms myself. Was pretty sure you're claiming the impossible - but evidence is solid (though noisy)

alh don't see a point in updating the top post - this needs to be cleaned up and moved to wiki. Scope shots at are of use to the guy who makes the next controller, theory and gory details - to the future firmware porters. They won't replace seeing things firsthand - but they will help. I'll do it after I have the keyboard on my hands, not a fancy capacitance gauge.

In other news, I've committed and pushed the sensing machinery which uses band-pass filtering yesterday-ish, and made a rough draft of the layer selection mechanics.

band-pass filter should provide superior noise immunity - external sources must add a very specific amount to a measured signal, to land it right into other band. +5V on the sense line will not cause a stuck key, for example. Ground short is a different story (low band touches zero, signal is pretty weak), but this only relevant to beam spring.
Tuning it is a bitch, let me tell you. You have 2x number of keys parameters to set. That's 208 for standard keyboard with winkeys. I've managed to make initial configuration simple - under 10 mouse clicks. But piano tuning comes to mind. Process involves pressing ALL the keys (relax, not at the same time ).

Encountered a problem when ISR runs for longer than the scanning cycle, which lead to breakage of scanning loop (because I was driving the next row from the "row complete" ISR and did it right at the top to increase rate - and cleared the interrupt flag at the top too. Calling ISR when that same ISR is running.. is not a good idea.).
When there were just thresholds - everything was fine, adding IIR on top wasn't that visible, but now that I've added "if value read lies within lower or upper band" per key, it started to take more than 25us@36MHz.
This was the moment I learned that function calls are expensive in Cortex M3. changing "void noise_filter" to "inline void noise_filter" almost doubled performance. About 5300 matrix scans per second now.

Moved main loop to timer ISR, using AltActive power mode (that's "active with CPU stopped") in main loop. Saved some power there - not much, like 25->22mA. Unfortunately my rigol cannot into current measurement - curious to see what happens with power consumption on microsecond scale. May be more bypass caps are in order. Or 3 is too much. You'll never know with bees^W^W.

Tried to solve "ISR takes too long" with ramping CPU clock up. Got somewhat predictable results.
@36MHz it's 25mA busy-waiting, 22mA stopping CPU outside ISRs.
@66MHz it's 45mA => 32mA.

I'm not really comfortable with keyboard which draws quarter of a watt. Sure, there's plenty of juice from PC - but still, that thing can cause Global Warming!
Also this will create problems in suspend (not that I'm applying for USB logo..) - 1 scan cycle is 200us, need 4 for noise filtering, need to do it may be 10 times a second not to get "it takes forever to wake computer up" effect - that's 10 milliseconds staying up per second, 0.4mA. And the whole power budget is 2.5mA and it looks like even in sleep states it would be hard to draw less than 2.

So, not much left for the working keyboard - basically layouts and a new way to form USB reports. If I'm not laying flat for a half a day like today, there's a chance to see the next update typed on 5251 tomorrow. I mean the next update will be typed on that 5251. The question is when it gets posted

[Ratfink]

Unfortunately my rigol cannot into current measurement - curious to see what happens with power consumption on microsecond scale.

Of course it can into current measurement, as long as you don't mind slightly changing the current it's measuring. Just pass the current through e.g. a 0.1 Ω resistor, and measure the voltage across the resistor. Then every 0.1 V on the display is 1 A.

[dfj]

DMA:

Yeah - I used a very primitive filter to deal with my noise - and I roughly know the sources as well.

The spikes are interesting - they are located at the front and back of the strobes, so I smoothed the rough edges off of them with some 10 nF I had around, but I didn't do the math nor fix the second derivatives - it still helped enough to get that shot, mind. I suspect a bit of inductance will help at strobe gen - but that more or less forces the use of analog muxes to strobe with. Topre did that, but I'm hoping for a lower cost, perhaps even home-hax-friendly controller.
Power savings during use is less of a concern to me, as it is meant to be a controller one can game with - though people will still want to sleep the poor thing occasionally. Guess I'll just reduce the refresh for that situation, if I ever get to it. Interestingly - after a bit of practice, getting a pair of taps within 20+ (including a decent gap between them so a keyboard has a chance of distinguishing them) is doable with a two-finder flick, arcade-one-frame-tap style, but when I tried on a different key it got way easier... went back and reseated that first key and it was much better. :} These are from F13, and F15 on a 122, though I was not scanning the whole board, just wanted to revive my strobe circuit to show the shape of the keypress.
Scanning at higher frequencies will bring more fun - I expect those spikes are crosstalk, and they are of different heights due to power fluctuations. This was quite a brutal experiment - I didn't even isolate gnd for the shot, nor use an analog gnd source, or really make any attempt to shield the keyboard from surrounding gear. It was just a lucky day.

Wish me luck - while I also want a fast scan - my goals are not topre and beam-spring support anytime soon; the F is the only keyboard on which I can do that trick and after that, it's all arcade button-land where I learned as a wean. I do agree that in the longer term people's new boards should be strobed row-wise, as soon as we start doing more main PCB.

Chuffed,
dfj

[DMA]

Of course it can into current measurement, as long as you don't mind slightly changing the current it's measuring. Just pass the current through e.g. a 0.1 Ω resistor, and measure the voltage across the resistor. Then every 0.1 V on the display is 1 A.

Problem is full swing is 30mA. That's 3uV.
Also that one should insert that resistor from the high side - and then has to measure 3uV difference on top of 5V.
Yes, AC coupling works. But BAM you have a relative scale now.
Floating the scope also works - but you find yourself in trouble with your usual trigger sources
Proper tools, aka differential probes/current probes make life so much easier

The spikes are interesting - they are located at the front and back of the strobes

I found that large series resistor helps a lot with that. I'm using PSoC's internal pull-up and pull-down resistors (it has this peculiar drive mode when both are enabled), which are ~5kOhm, but external 10kOhm work just fine. You need to limit pulse current, and limit it hard.

Scanning at higher frequencies will bring more fun - I expect those spikes are crosstalk

Once you kill the overshoot, crosstalk is not that bad - practically non-existent. 10% from the adjacent key, if not less.
I should post shots from the xwhatsit - the difference is profound. I didn't because it would cause "yeah that guy disparages xwhatsit but doesn't have anythin' of their own" effect.
Larger series resistor makes traces A LOT cleaner - one should watch for high-speed digital links though. USB is now the noisiest thing in commonsense. For xwhatsit's architecture though - where you have a discharge resistor which is always connected - there is a limit on series resistor value. Make it too large, and discharge resistor will drain the cap before it charges to a needed level. Make a discharge resistor larger to compensate - and it doesn't have time to discharge the cap back to empty between cycles.

But yeah, the problem is that CPU staying up, not the scan rate. Whole scanning machinery draws about 2.5mA at max speed (1Msps).

[DMA]

i am typing this on a 5251.
no modifiers yet. single layer - but up to 4 should work.
no macros, though there are plugin points marked for those.
pretty reliable sensing it seems - though that needs more testing, definitely.

enough for today.

in other news, cypress announced psoc 6 with bt and usb. datasheets in 2 weeks, prototyping kits in august somewhere, silicon in october.
i.e. not for this project.

[Techno Trousers]

Woohoo, it lives! This will get my vote for the Model MF project.

Just out of curiosity, what would the psoc 6 bring to the table? Maybe it would be worth doing another run of controllers next year, if the benefits are compelling. With the form factor wcass and lot_lizard came up with it should be easy to swap in a new one.

[DMA]

Woohoo, it lives! This will get my vote for the Model MF project.

Just out of curiosity, what would the psoc 6 bring to the table? Maybe it would be worth doing another run of controllers next year, if the benefits are compelling. With the form factor wcass and lot_lizard came up with it should be easy to swap in a new one.

Datasheet will be available in 2 weeks

But - BT and USB in one device, for example. also 15uA/MHz = 1.5mA@100MHz if I'm calculating correctly.
May be even charging controller on the same chip!

[lot_lizard]

You let us know when you are confident enough (one way or another) to have a vote over in "MF land". We have pushed things by a few weeks already for a variety of reasons. When you do feel comfortable about a decision, if you could let us know the bits that CommonSense would be missing initially as compared to the xWhatsit (no UI for mapping like the xWhatsit, how layers could be configured, etc). All of these components can be added over time for sure (others besides you could even put together if they wanted to contribute), but just want to level set everyone on what it really means so they vote clearly.

I used the term "software" over there, and shouldn't have. But we need to figure out a collection of terms that really drives home why this works with a single chip (a collection of switches that are tuned by firmware, etc). There is a reason for the simplicity, and it is not just because of the Cypress chip, it is the tuning you are putting place that is firmware based vs. the legacy xWhatsit that is more of a hybrid of firmware and additional hardware. You get what I'm driving at (highly tunable/improvable in the future, etc). This would certainly receive my vote as well if you had comfort. I realize it isn't an MF specific project, but we are tightly coupled and can speak on behalf of everyone here @ DT that you absolutely have CRUSHED something AMAZINGLY hard. Well done!!! #dta7 (best project)

[seebart]

This would certainly receive my vote as well if you had comfort. I realize it isn't an MF specific project, but we are tightly coupled and can speak on behalf of everyone here @ DT that you absolutely have CRUSHED something AMAZINGLY hard. Well done!!! #dta7 (best project)

Yes this is big, probably as big as Soarer back in the day on another level.

[DMA]

the bits that CommonSense would be missing initially as compared to the xWhatsit (no UI for mapping like the xWhatsit, how layers could be configured, etc).

UI will definitely be there. It _is_ there - missing some parts right now, but it is there and reportedly it even runs on linux.
It may crash if you press the wrong button - but
a) it's not an everyday software, and
b) there are safe trails in that minefield even now, so instructions with pictures will help avoid the pain.
Think "enterprise software which you only have walk thru once".

So, at the moment, the only huge missing part is macros.
There are no multimedia or system keyboard as of now, only keyboard proper. Those are trivial to add.
There is no USB suspend support. Not sure anyone will even notice, unless keyboard prevents PC sleep (which I don't use so can't tell) by refusing to go to sleep.
Layer conditions (decided to pull concept from xwhatsit, except layers are stacked and transparent keys are supported) are missing the UI part - supposed to be fixed this week.
Bootloader host is windows-only - but I've seen a couple win-lin-mac python scripts for cypress standard bootloader, so it's a question of using additional software for firmware upgrade.
Extension headers are not supported. I'll need to get solenoid driver board and actual solenoid for tests magically appeared at my door. I highly suspect solenoid board is a HUGE NOISE SOURCE and this can cause PCB rerouting (USB almost did that).
I am aware I sound needy - but alas. Alternative 1, "ship prototype to someone with a scope and the hardware to test, wait till he has time to get it a good whack and snap LOTS of good pictures, make one change, repeat". Alternative 2 - order driver PCB from oshpark and parts - not really an alternative, need to much luck to find a solenoid on mouser that will pass for the real thing. Also expensive, and I'm kind of in a corner right now with 3 months of runway left.

I used the term "software" over there, and shouldn't have.

It kind of started dawning on me people don't really want to know details or even truth, just that it's somehow explained to them in terms they think they know. So it may be you did a good thing there

I realize it isn't an MF specific project, but we are tightly coupled

It's not MF-specific, it's XT-specific. Originally. I saw an easy way to add more platforms and wasn't too lazy or depressed at the moment to check
Speaking of coupling. Need to actually test how CS works with MF. Better on a prototype, before concrete is solid. I have enough key assemblies and FEXT PCB, foam is optional (at least it is on F122, not much changes removing it, except rattling.). Looks like I only need plates and fasteners. Do you have a spare pair you can throw my way? (and if you have a solenoid driver + solenoid that would be miraculous)

[tentator]

would it be possible to have tmk firmware run on those cypres based commonsenses?
I would really love to be able to continue using tmk on a BS keyboard since I already am used to and have tons of useful/nice macros and layers I use on other hand wired kbds I made..
And by the way, that would solve the problem of implementing layers/macros at all from scratch maybe?

tent:wq

[DMA]

would it be possible to have tmk firmware run on those cypres based commonsenses?
I would really love to be able to continue using tmk on a BS keyboard since I already am used to and have tons of useful/nice macros and layers I use on other hand wired kbds I made..
And by the way, that would solve the problem of implementing layers/macros at all from scratch maybe?

tent:wq

:wq heh heheh

I actually started from tmk_core. Just discovered at some point there's no parts I use and removed the dependency.
I'm a strong believer in doing less work and having someone else maintain as much as possible.

Main problem is tmk_core (and kiibohd for that matter) needs configuration burned into firmware.
It's OK for mechanical switches, but for capacitive ones you have this huge thresholds field you need to edit in flight.
Sure, autoconfiguration would be great, but I can't even wrap my head around how to do it. Analog world is harsh and ruthless, separating signal from noise is not trivial.
And if you need such utility anyway - it's hard to explain even to yourself why thresholds are easily configurable but to change layout you need to reflash. And so it begins.

Also there's an assumption you scan at USB report rate - and if 2 keys are pressed within the same tick they're reported at the same time which causes undefined behavior.

The list goes on.

At this point I think it would be easier to make a macro/layer converter on the side. I can import layouts from file already, and export to file too.

But yeah, I would really like to merge all this to kiibohd at one point. Or even Kaleidoscope. tmk has a great firmware, but it doesn't have serial console, you see. And the console makes things much more Fun.

[DMA]

Multimedia keys and system keys (power/sleep/wake) support added, at least on my windows 10 desktop which is the development station. Inadvertently sent this machine to sleep 5 minutes ago.

Layer conditions editor is working, layer conditions are also working as expected.

Undefined behavior if more than 62 keys are pressed at once - but you guys only have ten fingers, this should not bother you