One idea I've been toying wit (but don't have the skills to implement) is a standard for hardware that's a bit more verbose than things like i2c or serial. I'd like one connector I can plug into a piece of hardware (a sensor, a servo, a keypad, etc) and have it just work. The protocol would have to be a bit more complicated, maybe something like PJON^1, and you'd need to deliver power at a few different voltages.
I've been calling it kitbash in my head, just throw a bunch of components together in various topologies and you're good to go. Considering you can get a very cheap microcontroller for something like 40 cents I can definitely see the appeal of adding a "kitbash port" to various pieces of hardware, even if it means adding a whole new microcontroller.
> I'd like one connector I can plug into a piece of hardware (a sensor, a servo, a keypad, etc) and have it just work.
Not knowing much about hardware stuff, I'd assume there's a few different tradeoffs when designing some kind of connection. For instance, some connections might be designed to transfer more power, some might prioritize minimizing the possibility of interference, some might prioritize data transfer speed, and some might prioritize physical size. How can one connection type serve all of these kinds of competing requirements?
I believe that this day and age we can get one connector that cover 80% of use cases. How I'd do it is have 1 4 pin barrel connector like the kind found on head phones, I'd have 1 pin be ground, another be data, another be 3.3v, and another be either 12 or 24 volts. The 3.3v would cover lower power devices, 24v would cover higher power devices like stepper motors or servos.
Technology marches on. Basically cheap powerful microcontrollers can act as a modem and do more complicated error correction, modulation, etc. I think you'd only get something like ~400 bytes per second, but that should be plenty for most hardware peripherals. You're not going to be doing hard real-time industrial control using this kind of system, but if you want to poll the air temperature, humidity, light level, and actuate a servo, once per second, you should be able to. For more complicated setups, like those where you pull a lot of amps or require hard real-time control, you may need to do things the old fashioned but you'll still be able to take advantage of other kitbash components. But it's about the abstraction, like if you need a precise motor controller (high amps, high speed sensing of current and rotation) you probably need something custom. Still, hopefully you can export a kitbash interface and all you need is a side-channel for the power.
The cost is a $0.40 microcontroller on every device, which doubles the cost of many simple components, and it's not something I see being used in "properly designed" consumer products, but I think it would be entirely doable for the hobbyist/prototyping market. Imagine a bunch of physical hardware knobs, sliders, and buttons, and you can just wire them together to make your user interface.
I'd like a better build system for JVM apps. The standard is Gradle, which is powerful but hard to use. Unfortunately most other alternatives fail on basics like easy dependency management, support for languages, IDE integration and so on. This is something that bugs me enough I'd consider paying for it, and even considered doing as a product myself, but it's hard to know if there's even a market for paid build systems. Gradle has Gradle Enterprise but it's not actually a build system, and hard to know if they really make money given that they were raising rounds for the last 10+ years.
5 comments
[ 4.2 ms ] story [ 34.2 ms ] threadI've been calling it kitbash in my head, just throw a bunch of components together in various topologies and you're good to go. Considering you can get a very cheap microcontroller for something like 40 cents I can definitely see the appeal of adding a "kitbash port" to various pieces of hardware, even if it means adding a whole new microcontroller.
1: https://github.com/gioblu/PJON
Not knowing much about hardware stuff, I'd assume there's a few different tradeoffs when designing some kind of connection. For instance, some connections might be designed to transfer more power, some might prioritize minimizing the possibility of interference, some might prioritize data transfer speed, and some might prioritize physical size. How can one connection type serve all of these kinds of competing requirements?
Technology marches on. Basically cheap powerful microcontrollers can act as a modem and do more complicated error correction, modulation, etc. I think you'd only get something like ~400 bytes per second, but that should be plenty for most hardware peripherals. You're not going to be doing hard real-time industrial control using this kind of system, but if you want to poll the air temperature, humidity, light level, and actuate a servo, once per second, you should be able to. For more complicated setups, like those where you pull a lot of amps or require hard real-time control, you may need to do things the old fashioned but you'll still be able to take advantage of other kitbash components. But it's about the abstraction, like if you need a precise motor controller (high amps, high speed sensing of current and rotation) you probably need something custom. Still, hopefully you can export a kitbash interface and all you need is a side-channel for the power.
The cost is a $0.40 microcontroller on every device, which doubles the cost of many simple components, and it's not something I see being used in "properly designed" consumer products, but I think it would be entirely doable for the hobbyist/prototyping market. Imagine a bunch of physical hardware knobs, sliders, and buttons, and you can just wire them together to make your user interface.