Detail Trackball Parts

[nethermead]

I've been playing with the trackball builds and I really like the direction it's all going. (In general, this repo is terrific, thanks for it and for the work you're doing. If you need help, I'd be happy to lend a hand.)

I did get misdirected by another trackball build guide and bought some 3mm x 18mm steel rods for bearings that I blithely assumed would fit, but they're much too long for this model. After poking around, I found a RollerBearingDowel.stl on the Ploopy Classic Trackball github and printed out three vertically and they seem to work nicely. Note that all the STLs there seem to be scaled 10X larger, in cm instead of mm.

https://github.com/ploopyco/classic-trackball/tree/master/hardware/Mechanicals/STLs

I've attached a scaled STL.
trackball_bearing_pin.zip

But would be good, when the trackball stuff is ready for primetime, to specify the bits and pieces needed to make it go: bearings, rods, 34mm ball, sensor, controller wiring, QMK funkiness, etc. I'll be tackling a lot of this in the next week and I'll keep a log of gotchas and solutions.

[joshreve]

Still working on the build, but based on the interest may update the readme early to clarify for people. All the hardware needed matches the Ploopy build. The bearings are on amazon and the posts and post/bearing press fixtures are actually just simple 3d prints available in the Ploopy repo. I should pull them into my repo and add attributions as needed.

The QMK side I am looking at right now. I got a promicro with the PMW 3360 firmware running to confirm my hardware build, but will likely need to create a new QMK keyboard to support it all. I currently have most of the pieces to start a full test build and will update the docs based on my learnings.

I am also investigating KMK and implementing a Pi Pico version to get the OLED, trackball, and per key LED running. It doesn't look like any controller that is compatible with QMK is currently capable of this. This is obviously a longer term objective.

[joshreve]

I've been spending some time reading up and I think QMK is going to be a quagmire of high and low level integration issues. I am going to investigate moving to Circuit Python. I'm going to look at KMK, but first may just make a hack functional FW to check it out.

[joshreve]

Well, circuit python is not the way to go. It lacks any low level capabilities. No timing control sub milliseconds which is needed for some of the HW control. I didn't realize it was really meant for people just starting to learn to do micro controller work. I'm looking at what possibilities exist with Arduino. It looks like the only readily available framework with hardware abstraction for a wide range of controllers and low level control. I looked at creating an Arduino driven QMK, but QMK has low level references showing up all over the place with no clear abstraction or driver layer.

Honestly a little disheartened. I am astounded how awesome the functionality is with QMK with such an entangled architecture. It does explain why they don't have more of the new MCUs running. I'll have to consider if I'm going to go down this path or just roll with whatever I can do with default QMK and slightly more obscure controllers.

[itised]

That's too bad. I was hoping it would be a viable option.

I wonder how much work it would be to port just the matrix scanning code from QMK to Arduino.

I imagine it's all you'd need, since all the other hardware should be supported by Arduino.

[joshreve]

That is what I'm going to look at, but the code is pretty tangled. It looks like I may be able to extract the TMK and possibly Quantum portions of the code and reconnect them to arduino functions, but the interface boundary is not very clear. I am debating if that is easier or hard than rewriting a simplified version. It should be a LOT less code when building off existing arduino libraries.

There is also Kaleidescope from keyboardio which may be a better base as it is already build on top of Arduino, it just lacks some of the extra features for OLED, trackball, etc. I'm going to read through the libraries a bit and try to find the best path. I should still be able to pull some pieces out of QMK to add some features, but right now, I think it is almost easier to reimplement than try to find all the boundary interfaces to extract the QMK core.

[itised]

There's also an existing Arduino library for the matrix scanning:

https://www.arduino.cc/reference/en/libraries/keypad/

I'm not sure how robust or extensible it is, but it might be another good starting point

[joshreve]

I think I'm going to start from that or Kaleidescope. I'm just going to make it what I want. I do this for fun, so even if it takes a while I'll enjoy it. I think I'm going to do something almost unheard of for small projects and actually create the architecture diagrams or at least a strongly documented API at each layer so people know how to work with it. To really shine, I want to create it so people can add stuff without needing to understand the whole stack. I think that often gets lost as one project evolves into another and intent and vision shifts. I also want to try out Papyrus as one of the few open source architecture tools.

I have a little more to wrap up to get my build running and this and a flex PCB are queued up to be next. I'll have to decide which makes more sense to do first. Probably the firmware so I know what controllers to focus on for the PCB.