|
This work is impressive and I'd like to see it continue. I do see some issues though. The problem of connector reliability has already been mentioned. Let's say I add two LED modules and two sliders and I want each slider to control one LED, or I want both sliders to control both LED's or I want both sliders to control both LED's but one slider's action is reversed. That decision is in my mind and can not be automatically guessed, there has to be some way to decide which modules are linked to other modules and what action is expected. Do I want motion detected by a PIR sensor to turn a light on via a relay module or turn a light off (when I'm walking up stairs out of a basement)? Again, a need to configure. To go deeper, say I connect an I2C temperature and humidity sensor and I want the temperature to control a heating pad and the humidity to control a humidifier, plus I want a readout of both on an LCD module and I want both to feed into another LCD module that displays an air quality index while another LCD module shows CPU temperature. Configuration is needed. If I add 5 camera modules, do I run out of high speed buses? So far I see a few specialized use cases demonstrated, but not a general method of interface and routing configuration. Modules may need to be configured also (does the temperature module report Fahrenheit or Celsius? Is the conversion handled in the sensor or the app?) As soon as you start to build anything complex the default behavior is not likely to be what you want (try building an audio mixing board out of modules), so I see a limit on complexity. The capabilities of the editor mentioned in the video will be interesting (to be shown in a future video it says). Connections to external devices that are not wireless also seem like an issue, a pull on the HDMI cable is going to pull the HDMI module off the board. If I plug in a slider, a button and an HDMI module what are the slider and button automatically configured to do to the HDMI module? There is an attempt here to encode common functionality and routing. That only allows you to do common things, not uncommon ones. Still, until you try you don't know what is possible or how far this could go. I would encourage using optical and wireless interfaces instead of wired interfaces since those are much less sensitive to the quality of the contact. Power supply could be inductively coupled. If you make it all RF wireless you don't need the baseboard, the modules could be anywhere, powered by anything. The modules, especially the inputs, should be able to dynamically alter the routing of all the other modules (for example, routing audio from five input modules to either or both of two audio output modules controlled by a 3-state switch.) In some ways I see this as building a configurator for an MCU. MCU's have all kinds of I/O, timers, interrupts, some have RF interfaces and sensors, etc. Imagine all the modules (or at least RF/optical interfaces to them) already built into a chip and you just want to configure them for a specific application. Instead of copying the example code for a SPI interface and modifying it, you instead just configure it in a configurator. The configurator could automatically recognize multiple chips and let you route RF/optical connections between them (with a selection of protocols) and configure their I/O. No need for a baseboard or modules, everything is just general purpose chips with tons of stuff already built into it (sensors, RF, I/O, protocols), and you just turn on and off and route whatever parts you need. Sounds somewhat wasteful, but if you make a trillion chips like this it may actually be more efficient, particularly in terms of human effort, for building a wide range of systems. Security would be a problem, if a flaw is found in the basic design everything built using it would be vulnerable. Reliability might be increased since anything that fails would be trivial to replace. |