Project Logs

Collapse

• A full re-write of the framework

  Jeremy Gilbert • 07/21/2017 at 17:32 • 0 comments

  In the last month since my previous post, I've been busy reworking the entire Makernet software framework. Nearly every line of code has been rewritten and posted now to github here: https://github.com/jgilbert20/Makernet. The major advantages of the rewrite is pluggable support now for datalink layers other than I2C.

  The initial version of the Makernet code was long overdue for an overhaul. I had originally cobbled it together when I was still learning about I2C internals, and many of the concepts were based on EKT's code from the Modulo project. This was good for proof of concept, but I rapidly realized that the architecture would be impossible to maintain unless I created a proper networking stack.

  The new version of Makernet now is a fully OSI-relatable network stack with several layers. The first layer is the datalink, which provides medium access control, and forms input and output into frames. In the case of I2C, these frames are I2C transactions, but the code is generalized now to support nearly any way that a packet of information can get from A to B. 

  One nice advantage: my datalink layer handles all hardware concerns, making the upper layers of the stack fully hardware neutral. In fact, I implemented a second Datalink layer based on UNIX domain sockets which allows Makernet to run over MacOSX and Linux interprocess signalling!

  Once frames leave the Datalink layer, they move up to the Network layer where they are interpreted as packets and dispatched to various registered handlers called Services. Because the packet format is constant across different datalinks, every part of the software code can interchange with new transport protocols like RFM69HW radios or RS485.

  The code is now about 20% more compact than it was before, and all of the packet routing is now 100% object oriented, making it very clear to understand how packets and information flow between layers and also assisting in expanding the framework in the future.

  The next innovation was the removal of command syntax entirely from the makernet specification. In the early version, there was the idea of a command that got sent from a master device to a slave device that caused something to happen. This imperative syntax is very easy to implement but causes a number of problems. First, it does not handle irregular communications very well. Say your command from A to B is lost in the network. Do you just sit there polling for an ACK, while the rest of your code grinds to a halt? 

  Furthermore, commands make it entirely too easy to forget about state, which can be very pernicious in a truly asynchronous programing model. Consider the example of a neopixel strip N and a controller/master C. The code on C fires off a bunch of commands to draw some pixels. What happens if strip N disconnects and reconnects? Or experiences a software reset? Suddenly, the code no longer functions as you intend, because each "command" to the strip was actually updating state on the remote node and now all that state is lost. 

  To remove the imperative command syntax, I created a built-in mechanism called mailboxes. In this model, both a master and slave device share a set of connected, automatically synchronized small buffers. When one buffer is updated, the buffer on the remote end is synchronized automatically by the networking services. Now, all of the state assumptions are clearly defined. The mailboxes are defined as clean C++ object types that can be subclassed and adapted to nearly any type of communication need including streams. 

  You might think a heavy OO framework would be too much for a small embedded framework. I certainly was worried about this, especially virtual functions which implement a hidden jump table on each object type. However, my extensive testing has shown that in fact this new architecture is faster for most operations. The gain comes from the fact that the new framework never generates packets it doesn't intend to send because...

  Read more »

• Polyphonic sound using I2C!

  Jeremy Gilbert • 06/20/2017 at 17:11 • 0 comments

  I'm a big fan of devices that make sounds as a way of interacting with the user. Pretty much every app, game and operating system uses sound in some way and it feels very natural.

  Sadly, adding high quality sound into a hobby-grade EE project is kind of a pain in the bottom. The Arduin supports a Tone library, but this is quite limited. You only get one sound playing at a time, and its basically a square wave. Adafruit and others have come up with WAV shields that fill in the gaps. With these neat devices, you can actually take sound files from your PC and set them up to be triggered by your project. The best winner in this category has to be the prop shield and audio library from PJRC.

  Even with these new devices, there is still a lot of complexity. And you don't really get everything you'd want.

  For instance:

  • Polyphonic sound- Most of these devices will play exactly one sound at a time. This doesn't correspond to how we normally expect interactive noises to work where multiple can be playing at the same time
  • Open source: Sadly most of the Adafruit and Sparkfun devices appear to be closed source firmware
  • Esoteric chips: I always feel cautious about integrating strange chips into my design. There is no reason why a $1 ARM chip can't stream I2S signals, so why have a dedicated player unless you actually need MP3?
  • Programing interface: Ideally you want to just send a single quick command and have the rest taken care of. I'd rather not consume a UART and work out how to send my device signals at 9600 baud.

  Based on these experiences, I was determined to integrate a true polyphonic sound player into the Makernet arsenal. Behold, the result of my efforts:

  As you can see, this little baby is still being prototyped (note the dangling USB cable and programing jig). It has a MicroSD card reader, a SAMD21G18 MCU and plays sound out of a MAX98357A I2S audio chip. Of course it also has the regular 6 pin makernet header that provides it with network, 3.3V and VIN (usually 5V).

  Using this device inside Makernet code is really easy.

  First you declare an SoundPeripheral object like this:

  SoundPeripheral soundPeripheral;

  The Makernet framework will connect your sound peripheral hardware to this object. Now when you want to play sounds, you can simply call:

  soundPeripheral.triggerSound(1)
  

  By way of a demo, I made a very simple setup with a Makernet mainboard (a SAMD21G/M0), a DPad button and the Sound Board.

  The following code snippet is all you need to have a sound play on a keypress. The Makernet framework handles all of the network discovery, message passing, error handling, etc.

  #include <Makernet.h>
  #include <Wire.h>
  
  SoundPeripheral soundPeripheral;
  DPadPeripheral dPadPeripheral;
  
  void setup() {
    Serial.begin(57600);
    Makernet.begin();
    dPadPeripheral.onButtonPress( buttonHandlerPress );
  }
  
  void buttonHandlerPress( DPadPeripheral *p, uint8_t channel )
  {
    soundPeripheral.triggerSound(55);
  }
  
  void loop() {
   Makernet.loop();
  }

  You can see a quick demo here:

  Writing the code for the Sound Peripheral involved a lot of learning. For the uninitiated, real time sound programming is a bit of an adventure.

  First I had to get the I2S library working properly. The library supports DMA, and you hand it a buffer of things to play periodically.

  Next, I needed to add double buffering, so that sound can be generated in batches and then handed off to the DMA. Otherwise, new sound data generated by the audio sources would trample over old sound data.

  Next, I needed a full audio framework. I started with the PJRC/Teensy libraries that I admire so much. They are brilliantly written, but assume Cortex-M4 DSP instructions which I don't have on the Cortex-M0. Secondly, Paul makes liberal use of a very sophisticated hand-tuned memory library presumably so that each audio source can avoid unnecessary memcopy() calls.

  I ultimately decided it would simply be easiest to implemeny my own library using some of the design patterns I like from the PJRC stuff. In my design, there are a set...

  Read more »

• Making products is hard - the story of the Rotary Encoder "Problem"

  Jeremy Gilbert • 06/15/2017 at 21:25 • 0 comments

  The last 2 weeks have been a big of a slog for Makernet. I'm in that obnoxious phase where a ton of stuff has to get done but there isn't a whole lot of new wiz-bang stuff to show for it.

  It kind of reminds me of this picture:

  Anyway, last weekend I accomplished a major but somewhat unfulfilling task: I successfully stabilized the rotary encoder board's logic.

  The rotary encoder board looks like this:

  I had noticed for a long time that my rotary encoder was not nearly as stable as it is on the Teensy or in other projects I built. I had been treating the Arduino Encoder library as a bit of a black box, but this was coming back to bite me. I was seeing skipped steps and other unexplained repeating pattern glitches. Initially this didn't bother me much because as a proof of concept, it still worked.

  But I'm rapidly getting out of proof of concept mode and quality starts to matter. Over the weekend someone reached out to me on Twitter asking if they could try out some of my boards for a project they are working on. So I now needed to get the rotary encoder far more stable since it would be leaving my workshop and going out into the world.
  

  I have to admit that I basically never really "grokked" how the rotary encoder works. Yes, I understand the principal, but knowing the theory is quite a bit different than actually intimately understanding the various state transitions. I had been trying to get away with not knowing them and treating them like a black box. But this challenge finally tipped me over the edge since no one on the Teensy forums seemed to have any idea what might be going on.
  

  So if I wanted a high quality rotary encoder circuit board, basically no one was going to do this for me. I had to do it myself.

  People sometimes say "why do we need Makernet"? For instance, they point out that there is a lot of example code out there for a rotary encoder. Why would a person want to buy (or make from source) a single component that connects a rotary encoder onto a shared network bus? Even if it was less than $10 in parts? Well, one of the reasons is that rotary encoders are harder than they look. They get glitchy!

  In fact, all bits of hardware actually are harder than they look. And if I'm some random interaction designer working on a project where I think it might be nice to experiment with adding a rotary encoder to my device, I don't want to spend a weekend learning the gross details of this esoteric device. Its the same reason why the ArduinoCore is so useful at getting people out of the weeds. Sure, digitalWrite() can be replaced with PORT register calls. But doing that forces you to worry about implementation that you'd rather not have to deal with. It takes your head out of the game and slows down your innovation and your idea generation/iteration.
  

  Anyway...

  I digress.

  So, the Makernet rotary encoder design needed to be stabilized and de-jittered. After a painful process struggling with my oscilloscope, I decided to try my Saleae Logic 8. This little tool is super useful and frankly probably the most useful diagnostic device I own. After setting up a test rig, I started looking at traces especially under high speed.

  What you see below is both an analog interpretation of the pins as well as the controller echoing back when its interrupt were firing and what the MCU thought the rotary encoders A and B signals were.

  I quickly discovered that there were bizzare corner cases that most rotary encoder code-bases or tutorials don't handle or even bother to tell you about. For instance, the "recommended" way to read an encoder is with an pin change interrupt. But say your encoder is noisy and it bounces around a lot. Its possible that a LOW->HIGH bounce will trigger the interrupt several times, and that by the time the interrupt code reads the pin state it will have temporarily bounced back LOW. That means that for the next few microseconds, maybe longer, the code's state machine thinks that the pin is LOW when its really high.

  This "gap" may...

  Read more »

• SAMD21 with Makernet - Keypads!

  Jeremy Gilbert • 06/02/2017 at 20:26 • 0 comments

  Lots of great stuff going on this weekend, and I'm still cruising off of the huge dose of encouragement I received in the last week!

  First of all, a bunch of new boards came back from OSH Park. The first is a breakout of everything on the ATSAMD21 plus some Makernet headers. This is by far the smallest ATSAMD21 board I have and I'm a bit proud of how compact it is. It reminds me a lot of the Teensy 3.0 boards.

  I plan to use this board to prototype keypad interfaces. The idea is to make an adapter board you can connect to any keypad and get it onto Makernet easily. Keypads are annoying to wire into a project because they need a lot of GPIO pins and thus a lot of messy wires in your project.

  I have a bunch of keypads in my collection:

  
  

  While most of these keyboards are polite, only needing ~8 pins, some others are not so elegant and have a pin per key.

  And then there are some boards like this one I ripped out of a graphics test pattern generator I bought at MIT swapfest:

  This board, while very cool, needs 20 pins for reasons I haven't fully investigated.

• Communication, communication, communication

  Jeremy Gilbert • 04/25/2017 at 12:48 • 0 comments

  I spent the weekend shooting some video with my daughter to try to better illustrate my Makernet idea.My daughter wanted a timer for her toy rocket that would give a countdown. She wanted colors that would go green when it was time to launch.

  What a perfect opportunity!

  Here is the rough sketch:

  Next, I built a full implementation with a breadboard. Lots of messy wires, and the project isn't very shareable. Even with plenty of rehearsal, I still managed to screw up the wiring three times on the video.

  Finally, I built the same project using the prototype Makernet modules I had made so far:
  

• More devices

  Jeremy Gilbert • 04/25/2017 at 12:13 • 0 comments

  GM1201 - Metal ball tactile DPad

  The second I saw these cool metal buttons on Adafruit, I knew they had to be part of my Makernet user interface. This DPad is a four way controller featuring four directional buttons. Cute, eh? They are super clicky when pressed - extremely satisfying.

  Unfortunately, this DPad module presented a lot of unexpected challenges. Unlike the other modules I had built, this one had some unexpected clock issues that exposed some serious gaps in my understanding.

  I first realized something was wrong when the serial port on the board was garbled. By way of explanation, my standard test jig involves GND, VCC, SWD, SWC and a TX UART pin. When I loaded the test firmware initially, the status messages printed to the UART at 115200 baud were garbled. At first, I suspected that I had somehow screwed up the SERCOM UART configuration, but loading identical firmware onto the rotary encoder board (GM1200) didn't show this problem. So it was a problem with the board, not the code.
  

  I suspected that there was a short or some wiring issue, but i couldn't find any obvious reflection or inductance probing around with a scope. Granted, I am fairly witless when it comes to analog signal debugging so I may not have even been using the scope properly to do this. Next, I inferred that a slower baud rate would be more impervious to noise, but even running at 1200 baud still showed the problem.

  After wracking my brain, I finally concluded that perhaps the clock on this particular copy of the chip might not be as stable as the other board. ARM clocks are notoriously complex and arcane. The SAMD architecture has 7 different clock generators that can be routed to nearly any purpose. For instance, you can clock your chip UART one way, and you peripheral bus another way, and your actual processor a third way. You can even use one clock to drive another clock in a phase locked loop.

  What is supposed to happen on the SAMD11 architecture is that your code starts running at a very slow, baseline 1MHrz speed using a very unstable boot-up clock. It has all sorts of jitter but its supposed to be enough to get you going. The first thing your program code is supposed to do is set up a proper clock configuration. Typically you configure two pins to be XTAL inputs, and connect those to a 32Khz crystal. 32Khz is really slow, right? So something called a digital phased-locked loop is used to "step up" the speed to 48Mhrz. Not being a signal expert, I am a bit at a loss to explain how it works but my basic guess is that the DPLL is a much less stable but faster oscillator that is more sensitive to noise and the environment. The 32Khz signal is used as a reference heartbeat, and the circuitry must alter the speed of the DPLL to match the heartbeat, thus guaranteeing a consistent clock.

  In my architecture, I don't want an external clock or crystal. Fortunately, the Atmel chip designers included a high precision 32K internal clock, presumably one based on a RC oscillator. This clock is factory calibrated. I had hoped this would be sufficient for all of my Makernet peripherals.

  Given that the serial port didn't work with the internal clock, I was tempted to assume my factory calibration was off. I seriously considered just pulling the chip off and substituting for another copy. But my experience so far on this project has taught me the value of double checking my assumptions. I've noticed that if I force myself to learn how to debug something with the right tools and instruments, I'll gain much more insight and avoid more mistakes and frustration later.

  The first tool I reached for was a Bitscope Micro. This little baby is supposed to work as a logic probe and an oscilloscope. However, over the past year, I have rapidly came to loathe it as an oscilloscope. On the other hand, the Bitscope supports a logic probe. I was eager to try it out and redeem my $129 purchase. But I rapidly discovered how sucky the software is. Slow and sluggish. I needed to calculate...

  Read more »

• First Makernet Boards: An RGB Rotary Encoder

  Jeremy Gilbert • 04/20/2017 at 21:20 • 2 comments

  Hot off the press are two new Makernet boards. This post will talk about GM1200, a rotary encoder module.

  Firmware for my boards is still in a very early state but a lot is working. Each module participates on the Makernet bus and performs some input or output function for the user's project. Each peripheral runs controlling firmware on a 48Mhrz ARM processor that supports network arbitration, addressing, broadcasting, event polling, and imperative commands. The event architecture reduces the need for polling - only devices with new information to share to the MCU raise their hand to send events. The ARM is internally clocked and doesn't need an external crystal.

  I've decided to give each module a product number to help me look them up quickly in my notes and identify hardware versions.

  GM1200 - Rotary Encoder 1.0

  Every project needs a rotary encoder - not only are they fun to twiddle, but they are great for menu navigation, setting values and all sorts of other useful things. This module drives a single rotary encoder which includes a pushbutton switch and a RGB LED. It also sports a small activity LED on the side to tell you if the module is working. Attractive, don't you think?

  The backside supports two Makernet ports, so the knob can be daisy chained with other peripherals. Everything is controlled with a 48Mhrz Atmel SAMD11 ARM chip running at 48Mhrz. The LEDs can be PWM'ed to any desired brightness. The chip uses interrupts to process grey code from the rotary encoder to reduce the chance that steps are missed.
  

  The initial batch of these worked nearly out of the box, however, there are a few planned improvements. First, I want to standardize on a 0804 LED indicator. Secondly, I neglected to put in I2C pull-ups, which I think are probably essential. There is an empty space for a clock and capacitors that ended up not being required once I got the clock-less configuration working. Finally, I haven't made a firm decision if the rotary encoder actually needs debouncing capacitors so those spots are un

• March Update (late)

  Jeremy Gilbert • 04/19/2017 at 21:37 • 0 comments

  For the May deadline, my current aim is a demonstration project - a vivid illustration of how someone could create a variety of different cool looking, functional projects, using the Makernet architecture. I am hoping to do this with a combination of videos and code examples.

  Why something demo-able? I think it will make the idea of Makernet come alive much better.

  This means I'll need a few different things:

  • Some kind of controller board (e.g. where the user puts their code). Has to be Arduino IDE compatible and have the Makernet hardware support on the PCB.
  • A common design for each Makernet peripheral, each ideally reprogrammable using the Arduino IDE, with as much consistency as possible in design.
  • A variety of actual Makernet peripherals built on the common design standard. I am aiming for a rotary encoder, a D-pad, a 128x64 B/W OLED, 8x8 mini LED matrix, 8x8 large matrix, and a sound generating board.
  • A good way to photograph and create videos of my work

  Over the last few months I've been putting together all of the fundamentals needed for the demonstration project. Some key accomplishments between Jan-March:

  - Interviews with a number of makers around the boston area to help learn what niches Makernet might address

  - Leveling up my soldering skills to repeatably solder the 24-QFN and 1mm fine-pitch connectors needed in the project

  - Creating a miniature SWD programming header (G/V/D/C) so that the ascetics of my boards will be as clean as possible
  

  - Creating a simple programming jig with tiny pogo pins (1.27mm pitch, for the win!)

  - Building out an Eagle library for the key parts I'll need so I can have standard looking resistors, capacitors, PTH connectors, logos, etc.

  - Settling on JST-SH as the board-to-board connector standard and working out a temporary source for the cables I'll need. Digikey offers these cables, but they are 1-to-N not 1-to-1. (Booo!) I will have to manually reverse them. For those not aware, JST-SH is a 1mm pitch connector -- reversing these cables will require work using a SMT inspection scope.

  - Building some test boards using the Atmel SAMD11 MCU to see if I can get the platform working on my build environment, and to evaluate the state of the Arduino Core for this platform. Turns out Justin Mattair has spent time porting the Arduino code to the SAMD11. These tests went very well, and I was able to get all of the basic things I need - analog, digital, PWM, in a fairly portable format. This allows me to feel confident in standardizing all of my Makernet peripherals around the ATSAMD11.

  - Taking a deep tour through the ATSAMD11 Arduino Code to figure out how remap pins the way I want them. This will let me cut down on BOM and layout complexity for the peripherals.

  - A massive adventure with the black magic of ARM clock configuration code to load factory calibration into the various internal oscillators. This will get me standalone ARM processor with very little external logic that will use a high accuracy internal clock.

  - Creating a Makernet clone of the Adafruit Feather M0 (ATSAMD21G18-based MCU) which is one of the candidates for my controller boards.

  - Creating a working Teensy 3.2 clone which is another candidate for the the central controller board design. The Kenisis MCU is much more featured than the SAMD21, with better instructions. Also, I'd argue that Paul supports it much better than any Arduino, and it has a clearly thriving community. I'd love the Teensy to be the central architecture given its excellent libraries and my admiration for the team that supports it.

• Concept origins

  Jeremy Gilbert • 04/13/2017 at 20:40 • 0 comments

  In this post, I want to share a bit of the origins of the Makernet idea. In the next post I'll talk more about where I am today.

  By way of background, I've been a "maker" since 2012, when my daughter was born. Prior to that, I was a software engineer turned management consultant. I guess I was destined to re-enter the making world. On one fall day in 2012, I walked in a Radio Shack and on a whim, bought my first Arduino. That afternoon, I blew the dust off of 15 years of unused EE training and got hello world up and running.

  The idea of Makernet started a few years later in my re-entry to "maker" hood. My daughter was about one year old, and I built her an electronics toy. I made it out of crudely glued plexiglass with a AT328P and a simple program that made light and sound when she pressed a knob. I wanted her to have something she could play with where the internals and electronic guts were visible. (The transparent case was critical - I wanted her to feel her electronics toys were understandable not mysterious.)

  Picture below: My first standalone project (since 1998).

  The project required a rotary encoder, and I had limited experience with this type of device. I hacked the module onto a slab of blank perf-board just above the MCU. Too late, I discovered that the pins I had used did not support the right kind of interrupts for grey code. More rework. Uhhg.

  Rotary encoder knobs are cool. They are so fun to twiddle, especially if your project does cool things with lights and sounds. Every project should have one. But what a pain to integrate! You have to deal with interrupts, with a state change and a ton of other things.

  There and then, I resolved to someday just create a simple I2C rotary encoder module. Then adding a rotary encoder to any new project would be as simple as adding an I2C device to the bus.

  Fast forward a few years, and I was building the box of clicky awesomeness. It has at least 6 I2C devices inside: an accelerometer, gyro, magnetometer, hepatic driver, capacitive touch sensor, etc. Two devices had to have I2C addresses reassigned. The wiring was a complete mess. The project barely fits in its case due to all of the obnoxious bits of glue logic. But the project was a success - on Cambridge Hackspace open houses, people love sitting down and playing with it.

  This is what it looks like:

  How to make things more modular? At this point, I had been building quadcopter using the DJI Naza platform and I was familiar with the elegance of CANBUS. The DJI autopilot platforms communicates with everything over CAN - the GPS, bluetooth, gimbal control, etc. Its dead simple to rearrange your drone because you don't have a ton of point to point wiring.

  I became determined to make the same level of flexibility and interchangeability available to Makers. I built an early pitch deck and researched I2C and CAN to try to decide what technology to standardize on. I2C is limited - it doesn't support flexible addressing and its not clear how long the bus can really be. It doesn't seem ideal. And CAN is obnoxious - it needs relatively expensive 5V logic transceivers and the protocol is complex. In most cases, you need to select a specialty MCU that has a hardware implementation for the CAN protocol.

  Then I discovered RS-485. The transceivers are relatively inexpensive. Combining RS485 with a $1.00 ARM MCU, you'd have the foundation of a network bus for maker projects. And you get the resilience of

  At this point, I started sharing the idea around my local hackspace. Someone quickly pointed me towards a platform called Modulo. I reached out to Erin Tomas, the inventor of Modulo. She had a very similar idea and created a whole line of modular units that she now sells online. The idea is that each module is a simple sled that fits into a docking station. One of the modules is the main controller, and the rest act as I2C slaves. She has a library of about 10 different modules that can fit into the docking station.

  Her vision is to enable plug-and-play...

  Read more »

• First post

  Jeremy Gilbert • 04/13/2017 at 13:36 • 0 comments

  Wow, OK, here it is, my first post about Makernet. The last four months have been a busy blur with my day job plus my Makernet hacking work crammed in between. I am remiss in keeping this journal up to date and even explaining to anyone out there what the idea is about.

  The goal of Makernet is simple: Democratize the creation of projects where the increase in hardware complexity creates sub-linear increases in complexity. Or in laymen terms, adding more stuff to your project should be easy, transparent and modular. The result will be faster learning for new makers, because it makes hardware look and act more like the software paradigms they are already used to in their daily life.

  Wow. OK. So what do I mean by that?
  

  I want hardware projects to act more like software projects where there are libraries of interchangeable parts with clean abstraction barriers, substitutability, and clean APIs.
  

  You want to swap out your rotary encoder scrolling interface for a touch-based one? That should be a snap. A 10 minute job.

  You want to refactor your project case to sit on your desk rather than your shelf? That should be easy. 30 minutes or less.

  Here's the challenge -- for many reasons, hardware engineers don't typically think about clean lines of abstraction and modularity. They often cant - a OLED display needs extra control lines and and SPI interface. A rotary encoder needs to be on interrupt generating pins. There are tons of wired dependencies that take hours to understand and grapple with. So the typical project has multiple design layers: the physical layout of the project, the PCB layout, the circuit design and finally the code design. All of these different things become hopelessly tangled together. You want to experiment with a different user interface for your project? Or add a new peripheral? In many cases, you end up re-designing half of your project! So you end up with cascading complexity when you start adding new things.

  This is not how pure software works. In pure software, you pick really good abstraction layers that keep one part of your project from touching other parts. CSS keeps your styling separate from your rendering code. React keeps your UI logic separate from your back-end. I'm not saying web technology isn't complex, but we've done so much to iron it out and smooth it down to clean borders.

  I want to help do this for hardware makers. Especially young, up-and-coming makers.

  I want to meaningfully make it easier for the average hardware builder to benefit from modularity of the components they use, and the software they use to talk to their hardware.

  So why is this good for the world?

  In short, I think it will transform the way people learn about and understand electronics. Young makers are exposed to computers and software early in life. They use Minecraft. They tinker with legos. The use USB to plug in new webcams. They expect their world to be rearrangeable using software-like principals. Hardware in its current form will seem archaic, like a weird throwback. Things like I2C address conflicts, and the hardware internals of PWM are great to understand eventually, but should not be a major consideration for new makers.

  In my view, early makers should be exposed to simple combinations of hardware and software that they can tinker with and earn fast results. They should be able to start building things that resemble the world around them quickly. And they should be insulated from complexity until they are ready to dive into it. They should stay frustrated enough that they have to learn and it doesn't come too easy, but not so frustrated that they half to walk away from projects they think and known ought to be simple.

  I also fundamentally believe that projects should be shareable. If my daughter builds a cool little project that glows different colors based on the temperature, she should be able to take it with her. She should be able to show it to her class, or take it on a play date. It should fit into her pocket. Sharability...

  Read more »

View all 10 project logs