Using or improving Collapse OS requires a certain set of skills, most of all basic knowledge in electronics. "How can I acquire those skills?", some ask. Sorry, I don't know.
One thing I know, however, is how I did it myself. 3 years ago, I knew nothing of electronics or assembly language. I was a regular web developer. 2 years later, Collapse OS was born. I don't know how you can ramp up your skills, but maybe knowing how I did will help you.
That's a lot of "talking about myself", but I don't know how else to present that information and I believe that some of that information will be useful to some, so here we go.
The first thing I did was buying myself a Arduino Uno starter kit. I think it was worth it to pay a premium for the starter kit because it comes with everything you need to tinker and a list of projects to build that will give you an idea of the power that electronics give you. Breadbording simple circuits is fun and rather easy for a run-of-the-mill developer.
I liked Arduino a lot, but I didn't like the IDE and the wrapper library. Too clunky. Also, I needed to get closer to the metal. After having gone through the example projects, I worked on re-doing them outside the IDE, so I set myself up with avr-libc and avrdude, those tools wrapped up in makefiles. The result of this is published on Github. Note that it doesn't only contain Arduino projects, but also further breadboard projects made on the ATtiny.
Once you get rid of Arduino's cruft, things get interesting because you're forced to dive directly into your micro-controller's documentation. As I read ATMega328p's datasheet, I discovered one really nice thing hardware people have that software people usually don't have: reliable and complete documentation. That's really refreshing.
Of course, it also means that you're really supposed to read that stuff and you frequently have to refer to it, but it's a habit that is actually pleasant to acquire.
As I played around, I realized something rather important about hardware programming. Software developers are used to program in a "logical paradise". A perfectly consistent code base is considered perfectly adequate. The challenge resides in keeping consistency in an increasingly complex ecosystem with increasingly complex specifications.
In hardware, the logic itself is very often trivial. It's therefore very easy to write perfectly consistent code. But the underlying cause of bugs is almost never logic, it's timing! Too fast, too slow, this is really hard to debug without specialized tools (it took me a while to buy myself a logic analyzer, I would buy it sooner if I did it again).
One thing I then discovered is that naive C code written for AVR chips and compiled with avr-libc was really, really inefficient. I tried rewriting a program I had written in C in assembly and I was surprised to see that the binary was 10 times smaller.
To be fair, my C code was written in a "software developer" mindset, so it was grossly inefficient (let go of your aestetical preferences with regards to code, if you have any. You will have to). By writing it in assembly, I was forced to think more in terms of hardware and it made me write more efficient code.
Is it possible to write efficient C code for AVR? Probably, but then you need to be intimate with both assembly and your compiler. Assembly, because you have to know in what instructions your C code translate to, and the compiler because you need to know how your compiler thinks and optimizes.
I thought it was easier to go straight to assembly, so I did. As practice, I rewrote those same breadboard projects in assembly.
Up until now, I haven't done much work in the physical world. Those little playground projects involved little breadboarding work, so I'm still learning mostly about programming.
I want to go a step further, so I buy "Make: Electronics" by Charles Platt and start going through this. I also buy myself some basic soldering equipment ( solder station, wires, protoboards, resistances, capacitors, basic logic ICs, etc.). The magazine itself has a purchase list that you can follow. I mostly followed this. It's worth investing in a good solder station and a good multimeter. You'll always be using those.
One thing you painstakingly learn there is that bad soldering is very often the cause of bugs. Your wire might initially be well connected, but after messing around with your prototype too much, you start having loose wires and everything goes awry. Not fun to debug.
I briefly tried designing circuits with KiCAD and order them for print (like many hobbyists, I used OSH park which is pretty nice). It was very fun and it saves tons of painful soldering work, but we're already almost at the point where I start working on Collapse OS, so it didn't take long for me to revert to protoboards because OSH park isn't collapse-friendly.
As you can see, I'm not even a very good hobbyist. Most of my knowledge and know-how is centered around digital logic and I know very little of analog electronics. I'm still learning. I bought myself "The art of electronics" by Horowitz and Hill, which seems to be the reference, but I haven't dug much into it yet. It's massive.
The computer you'll run Collapse OS on will likely need some makeshift soldering. The peripherals you plug in will probably involve some adapters you will have to design and solder yourself. Collapse OS' code is built around this kind of context and I think you need to be aware of what this context implies.
You need to intimately know what a shift register, a decoder, a multiplexer are so that you understand why Collapse OS' code toggles pins in this particular manner with this particular timing. You need to be able to understand a circuit schematic and how it plugs into the code.
This knowledge and know-how is acquired by practice. Good luck!