Finally... I've got a locked-in Tetent solution that also tries to borrow from TyMist (because a handheld input device is near useless without an output device that is just as portable) and I've started thinking of the detailed, full implementation of the solution. I also heard an interesting quote from someone commenting on a Facebook post about some engineering fail:

There's never enough time to do it right but 
there's always enough time to do it twice. ― Facebook Guy

I find this hilarious, partially because I'm in a rush yet I've actively been trying to avoid this thought process before seeing it written for the first time.  

This project... is going to take a while, mainly because the stuff I need doesn't exist yet. Something along the lines of:

If you wish to make an apple pie from scratch, 
you must first invent the universe. ― Carl Sagan

 The workload I've envisioned I need to do makes me wish I had a Tetent to create the Tetent.

For the Tetrinsic specific stuff, some of the things I'm thinking of using / implementing are:

• TinyUSB and FreeRTOS on the software side
• Not using Creative Commons for the hardware licence since they actually don't recommend it for such a purpose (which is news to me)
• Using a jig to cut 1*0.7*250mm stainless steel tube to 40mm lengths. It might even be part of the same jig that will be needed to splice the stainless steel ball chain.

  • My mental simulations that relied on chain tension and a tempered glass screen protector sliding surface kept coming back with warnings, namely that the chains will still want to bend away from their proper position since infinite tension cannot be acheived.
  • @RunnerPack mentioned that he wasn't enthusiastic with sliding chains across the screens and I couldn't shake that thought.
  • I still fondly remember when I was sliding the chain through a metal trench/channel, having a similar appreciation as that one tungsten cube review:

    • [I] bought this cube to become fully accustomed to the 
      intensity of its density, to make its weight bearable 
      and in fact normal to me, so that all the world around 
      me may fade into [...] gravitational inconsequence.
           ― Amazon Reviewer

    • It felt great that my fingers were able to frictionlessly move in their dominant axis but was solidly prevented from movement in their secondary axis. I can imagine this being extremely useful for walking and typing.
  • Thankfully, the actual height increase is only 0.5mm and LCD light should still be able to pass though mostly non-eclipsed. The weight also shouldn't increase that much, especially since the tube is hollow. The hollowness should also allow for easy cutting, and I can't imagine the tubes deflecting too much from 500g of force.
  • I should mention though, that I've just measured the chain I actually have and the balls are 2.4mm in diameter. Hopefully, 2mm balls feel almost indistinguishable, but this further increases my suspicion that 2.4mm is a more common size.
• Support for the TC358870XBG, which is a HDMI to MIPI chip that requires a microcontroller that communicates by I2C. Why not save some money, PCB space and programming time by letting a Tetrinsic handle it?
• Trying Fusion360 Electronics for the design of the PCB. 
  • Like TinkerCAD, EasyEDA is easy... if you don't need to make many adjustments/revisions (ie you know exactly what you're modelling and can create the thing first time round). 
  • I'm tired of spending 60++ seconds every time I want to slightly reroute a trace, when such a task should've been a 3 second click+drag.
  • I'd probably have to create footprints for every chip I use now, but I'm learning about the program and there's a full wizard thing that creates the PCB and the 3D model too.
  • The native 3D model generation is another reason, as well as the expectation that I'd need 5 custom PCB's to fully create Tetent.
• I might see if I can program the firmware in Rust.
  • Why? Is C not good enough?
  • It is... it's just that I'd like something that syntaxically looked like F#, and Rust does... marginally, if you squint.
    • I'm really just in it for the "let" keywords.
  • Fornjot is written in Rust and so it might be a decent idea to try and learn the language for #enSweepen [gd0096].
  • Basically, I'm going to be staring at this code and maintaining it for tens of hours, so I'd like to at least spend an hour or two weighing in my options.
  • [ok I've stopped writing to actually do some research into this]
    • Ok it turns out that there's an entire thing called the ESP-IDF which is based on FreeRTOS, according to MicroPython documentation. That sounds like 3rd-party language support can live alongside C libraries perhaps? 
    • My main concern is TinyUSB, and there seems to be bindings for it.
    • There's also the UF2 Bootloader, which is based on TinyUSB, allowing a user to drag/drop files to update the firmware. That does highlight another point, which is how to update all Tetrinsics when only one of them is connected via USB?
      • Hopefully there's some simple way to do that over I2C. There's also a way to update over BLE.
    • Oh, it turns out that espressif has a fork for TinyUSB.
    • Hmmm there's display performance issues, and the syntax of the posters code looks a lot more like c++ than F#, but with even more '::' ! Ok... pass on Rust then.
  • It also looks like C++ is absolute multitudes faster than MicroPython, and since each Tetrinsic has a lot of stuff to do simultaneously, it does seem like a simple yet inescapable choice.
• Or is it? Are there any frameworks that let me code in something else and it ports it to C?
  • Yes. There's a fat list.
  • Did a quick skim scroll and I thought I'd at least look at the ones that converted into multiple languages (so that I could say hypotheticals like "What if there's a python script in this otherwise C++ section of firmware? Dijobu, Igotchu.") and saw Haxe (cool and edgy name btw) and Wax.
  • Not that much of a fan of Haxe syntax, but I'm liking the look of wax already:

    • Yeah... might have something to do with the dark blue background and "let" keywords. You can also use (, [ or { brackets anywhere and mix/match too, wich is very nice.
    • It does seem like wax acts like a nicer looking C, reading its limitations. Hopefully, I don't need C++ stuff. Both ESP-IDF and TinyUSB are written in C, so it doesn't seem like that much of an issue.
  • Obvioulsly, the real question is if any of this would actually work for embedded systems or if they're intended for desktop programs only.
  • Additionally, it does seem that the features present in C++ would be less tedious to maintain than a C or C-like language, though it's recommended by some redditors to use C if started out and C++ for maintainability.
• Sigh... if only .NET could run on microcontrollers.

  • Me: [dances like that one kid in a club]
  • Reality: [slap]
  • Turns out ESP32-S3 support... does not yet exist. I'd give it a go (because I suspect F# isn't a first-class citizen either), but I'm not all that fond of being landlocked and typing on QWERTY (or, at the very least, my current keyboard) to get that job done. This makes me think of:

  • You can’t solve today’s problems with yesterday’s 
    solutions. ― Albert Einstein

  • By thinking of coding Tetent in C++ --> contribute to nanoFramework --> recode the thing in F#, I then come back to the first and second quotes! 
  • I'm mainly thinking of maintainability, in that I might code the firmware in 10 weeks, but I could need to maintain the codebase for 10 years. And remember, I've got more software projects to do after this, not including the hardware projects that need custom software to function. I say this, but I still haven't written a single line in F# yet. At the same time, F# and nanoFramework will likely stay in the sidelines if a relatively large percentage of the userbase only use it for side projects.
• Moving on, I'm thinking of using a small bearing or 3 instead of friction on the loop-around U shape I've got currently:

  • This part mainly depends on achievable FDM print quality, but is also a longevity concern.

I'm trying to avoid time bankrupcy here, but this overall Tetent project sounds mighty time draining right now. 

"Do it from scratch. Spare no expense! And never cut corners."
And we are almost bankrupt. ― Cave Johnson, quoting his father

 It all sounds within my capabilities, but loooooooooong.

I wondering if I'll ever get all the way to the end,
but it's a risk I gotta take. ― STRAY KIDS, TOP (english version)

 At the same time though, I'm wondering if I should just pack up this hobbyist innovation biz and reclaim my time, seeing as most my other projects all the same or larger in time-cost without Tetent, and that the 4x speed boost and quality-of-life improvement via Tetent will make it all too easy for Me In The Future to take on 8x the current workload, similar to adding more lanes to a highway only incentivises more people to drive.