The fast, intuitive and modular way to make awesome portable projects that maximize creativity and sharing

Similar projects worth following
Challenge: Cool interactive electronic projects are hard to build, require a lot of esoteric knowledge and aren't modular and abstracted like software. The effort to scale up your idea to a something _shareable_ is even harder - so many cool ideas never make it past breadboards.

Solution: Modular, interoperable components on a common field-bus that can be wired in any order and work with clean software interfaces. Now cool projects are more like Legos!

Aspiration: Young makers will be able to share their projects with each other, creating a virtuous cycle of inspiration. The barrier to create cool things will become lower.

License: Open-source hardware + software.

Status: Concept in testing

Makernet simplifies electronics projects and makes low-level hardware act more modular and abstracted like software. I want to enable makers -- especially young makers -- to build cool projects with minimal effort.

See the concept video below:

Everyone loves the thrill of building cool one-of-a-kind hardware. But lets be honest: hardware is pretty esoteric, much more so than software. Imagine someone raised on Minecraft and smartphones. How do we get new makers excited about building things? And how can experienced makers make projects more repeatable and less one-off and hard-coded?

Makernet addresses this challenge by creating a common robust bus network for all of the peripherals of a project. Everything is wrapped in a clean OO like paradigm. All you have to do is literally plug and play and forget about addresses, level shifting, battery charging, etc. Now electronics can be more like legos!

All of this is empowered by some clever hacking of the I2C bus and the availability of $1.00 SAMD11 ARM processors. A common event-based architecture sits on the inside passing messages back and forth.

Makernet is at the light concept stage. I have prototypes and I'm submitting this to the concept contest. I'd like to see if this idea resonates with other people.

Some of the intended features:

Pre-made modules: A small library of cool modules such as a rotary encoder, 8x8 matrix, capacitive slider, MCU board, neopixel driver, LCD/OLED screen, 4-way control pad, sensors, etc. All of them will be compatible and interoperable

Bus Architecture: MakerNet will be built on a bus architecture (initially I2C, later RS485) that allows true "plug and play" for most projects

No Soldering: Everything is connected with JST-SH 6 pins and can be daisy chained

Case plans: Every component has a clear mounting strategy, eliminating guesswork on how to put it into a case. Mix and match modules to create the control panels of your dreams! Everything flush mounts with countersunk M2 hex flat-head screws.

Low Power: All modules can be shut down into a low-power state consuming only a few microamps, meaning your projects won't need on/off switches

Battery management: The base MCU board will support LiPo charging and charge monitoring

USB programable with Arduino: The core MCU will be either the SAMD21 or possibly the Teensy 3.2. The core module will expose a USB port to the outside of your case.

Common libraries: Programming is largely event-driven

MakerNet i2c GM1200 rotary thin v02.sch

Rotary encoder schematics (still early version)

sch - 234.43 kB - 04/28/2017 at 20:51

See BOM Download

Makernet i2c GM1400 SSD1306 v01d.sch

Schematic for a Makernet device that sports a 1" OLED screen. (Still early version)

sch - 246.59 kB - 04/28/2017 at 20:45

See BOM Download

Makernet i2c GM1400 SSD1306 v01d.brd

Board design for a Makernet device that sports a 1" OLED screen. (Still early version)

brd - 135.72 kB - 04/28/2017 at 20:45


MakerNet v006b.pdf

Original pitch deck, dated ~1/1/2017.

Adobe Portable Document Format - 37.00 MB - 03/21/2017 at 01:46

Preview Download

View all 4 files

  • 1 × AT91SAMD11D Processor for peripherals
  • 1 × AT91SAMD21G18 Processor for mainboards

  • Communication, communication, communication

    Jeremy Gilbert5 days ago 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 Gilbert5 days ago 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....

    Read more »

  • First Makernet Boards: An RGB Rotary Encoder

    Jeremy Gilbert04/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 Gilbert04/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 Gilbert04/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...

    Read more »

  • First post

    Jeremy Gilbert04/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...

    Read more »

View all 6 project logs

Enjoy this project?



Morning.Star wrote 18 hours ago point

Hi I'm sorry we didnt get a chance to speak in HackChat. When it gets busy, the interface is too slow to type in... I may have appeared a little terse in my choice of words.

My point was that although MakerNet is a good idea (I've also noticed how modular the architecture has become) it means purchasing lots of little boards. This makes it proprietary in nature and also locks the students into a knowledge path. There isn't anything wrong with I2C, or indeed a protocol you've written yourself (I applaud your use of a wide standard here), but it doesnt teach how an MCU addresses the various hardware, for example, it simply replaces it with a layer.

Abstraction is all very well, but it created Microsoft and the problems monolithic systems are causing in education now. This is why I have utilised cardboard as a substrate in my work - it becomes a framework for knowledge rather than a series of modules replacing it.

Your approach is very different to mine, but I wish you the best of luck all the same :-)

  Are you sure? yes | no

davedarko wrote a day ago point

isn't it just ATSAMD21G18 instead of AT91SAMD21G18?

  Are you sure? yes | no

Jeremy Gilbert wrote a day ago point

Thanks for the comment and sorry I didn't see it earlier. I started with I2C because my aim right now is to test the idea and see if it resonates with other people. I defined minimal viable product the minimum that would show the excitement of the concept to others and validate my putting more effort against it. I2C is a hack that lets me mix makernet and non-makernet enabled devices for the proof of concept. In the end, I will probably either switch to RS485 or make some sort of repeater since I2C is working remarkably well.

The six wires are: GND, 3.3V, VIN (4-5V), SIG (reserved for future), SDA, and SCL. It could easily be pared to 4 wires as you suggest.

"Asynchronous" signaling is handled by a clever hack of the i2C bus I learned from Erin Tomson at Modulo. In my twist on her design, all of the devices sit on a common I2C bus address (address 0x09.) The master sends out broadcasts allowing each device to raise their hand with a message. I2C arbitration is used to avoid bus contention.

I2C is a clocked protocol so variation in the processor speed of each module isn't relevant. My experience so far is that 115kBaud is stable without the crystal, so there should be a way to get RS485 working there too. The internal RC oscillator is calibrated at the factory.

The protocol will obviously get documented if I proceed with the project. Right now, its all documented in header files. :)

  Are you sure? yes | no

Morning.Star wrote 18 hours ago point

I would myself stick with I2C as the standard, the point of being able to mix non-MakerNet devices is really a feature I'd not wish to lose. There are a lot of I2C devices out there already... Now if you could do this wirelessly over very short range instead of a wired protocol you would have a killer.

Cardware is hollow and has room for Special Weapons and other modifications, but wiring is a pain. We've discussed this in team chat and come to the conclusion that smart modules with wired power and a common wireless bus would be the answer. If you ever do something like this, we'd be very interested in it.

  Are you sure? yes | no

Frank Buss wrote 04/22/2017 at 22:56 point

Looks interesting. But why first I2C and later RS485 and not starting right away with RS485? And do you have a description of the 6 wires for your connection and the protocol? How do you do asynchronous signalling and how does it work with RS485 with ARM microcontrollers without a crystal?

I thought of such a bus, too, but it would need only 4 wires, and no crystal required, because the first byte (or few bytes) of each package would be the sync byte for the auto-baud calibration of a PIC chip.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates