3/10/15– Eric Kolker
Hey Tesselators, Eric here. Since we announced Tessel 2 last week, we have gotten a lot of questions about the new hardware.
Shiny new boards back from the manufacturer!
Tessel 2 at a glance
We packed a whole lot of hardware in there:
- A 580MHz WiFi router system on chip (Mediatek MT7620n) running linux (OpenWRT)
- 64 MB of DDR2 RAM
- 32 MB of flash storage
- 2 High-speed USB 2.0 ports
- a micro USB port
- A 10/100 Ethernet port (RJ-45 jack)
- A 48MHz ARM Cortex M0 microcontroller (Atmel SAMD21)
- Two module ports that are much more capable than their predecessors
- a button and a bunch of LEDs, because what’s a Tessel without blinky?
The board’s bill of materials and physical characteristics are only part of the picture. We spent a long time thinking about how we wanted to architect Tessel to push it beyond “another dev board” and clear into “this platform is exactly what I needed!” territory.
A few features under the hood (in addition to the ones current Tessel users know and love, including the expansive plug-and-play module ecosystem and high-level language support for low-level hardware features) include:
- Router-grade 802.11b/g/n WiFi, including access point mode (Tessel can be a router)
- 16 GPIO broken out as a pair of multi-purpose module ports
- Individual control over and protection for all outward-facing power buses (USB and module ports)
- A form factor designed for abstraction and flexibility in the hardware, software, and mechanical worlds as you scale from prototype to production
One of the things which makes software so powerful is a heavy emphasis on frameworks and abstraction. Although there is no shortage of “standards” (official or otherwise) in the hardware space, one thing nobody has done particularly well yet is cleanly and clearly share abstraction boundaries between the hardware and software layers. We’re looking to change that.
The high-level system diagram for Tessel 2…and most other single-board computers, too.
The diagram above is a high-level system diagram for Tessel 2. Let’s dive into where we drew the lines internally.
The board employs a processor/coprocessor architecture. The Mediatek runs your user code, hosts USB devices, handles the network connections (be they wired, wireless, or cellular over USB), and communicates with the SAMD21.
The SAM acts as a coprocessor and handles real-time, low-level IO through the module ports, USB comms through the Micro USB port, and programming the device as a whole.
The two chips are connected by a SPI bridge that also includes the onboard flash (the readme for Tessel 2’s firmware repo goes into more detail here).
The whole system is powered from the single Micro USB (device) port, and its specific functional blocks look more like this:
Functional blocks of Tessel 2
This arrangement, which also very closely mirrors where the related parts are located on the hardware itself, allows us to draw the boundaries at the both the mechanical and conceptual level as follows:
Functional groups in Tessel 2’s architecture
Or, on the board itself:
Functional groups on Tessel 2’s prototype hardware
Consciously drawing these same boundaries when creating both the software and the hardware lets us make developing on the Tessel platform simple and consistent throughout an entire product cycle, which is a huge win. I’ll talk more about this in another post, but suffice it to say that most of the optimization and integration story relies on the fact that we kept these boundaries at the top of the list when making design decisions about how to build Tessel 2.
New and improved module ports
The two module ports on the new Tessel look and behave the same as the ones on the original board, but they’re actually a lot more versatile. In fact, don’t lock yourself into thinking that they’re “just module ports”; think of them as mini GPIO banks. Each pin on the two 10-pin headers is unique and can be reconfigured to do almost anything from speaking alternate comms protocols to clock generation. For example, if you decide you don’t want SPI, feel free to give yourself another I2C or UART with minimal changes to the SAMD21’s firmware. Touching only JS, you can forgo the fancy comms in favor of just plain GPIO, which gives you access to as many as 16 of them.
Plus, a nifty new power architecture gives you individual control over the 3.3V rails on each port, so you can turn modules off when they’re not in use to save power. This essentially converts the 3.3V rails on the ports into two high-current (at least 250 mA) output pins that just so happen to power modules most of the time. …Or, put another way, this is our pass at solving hot-plugging for low-level hardware.
Last but not least, all eight pins on Port B are also inputs to a 12-bit, 350ksps ADC, with adjustable gain that can operate in differential mode, if that floats your boat. Not too shabby.
We’re pretty excited about the new hardware and what in enables, and hope you are too. It’s been in the works for a few months now, and at this point it’s time for us to start cranking out docs and answering questions, so don’t hesitate to reach out on the forums or over email.
Until next time,
This post has been translated: