• A Web Developer's Guide to Communication Protocols (SPI, I2C, UART, GPIO)

    Thursday, January 22, 2015

    1/22/2015– Kevin Sidwar, Kelsey Breseman

    This post is also on our docs page, where it will be kept up to date.

    This guide is meant as a companion to the Tessel DIY Modules and the DIY Module Guide.

    Each of the four ports on a Tessel exposes ten pins for use in creating custom modules. Two of the pins are for power (3.3V and ground) and the other eight are digital pins that can be used to communicate with your module.

    All eight communication pins speak in terms of simple on/off states, but only three of them (the GPIO pins) are meant to be controlled manually. The rest, when grouped in pre-defined ways, are capable of encoding complex messages by having their state rapidly toggled in accordance with various protocols. It’s a lot like Morse code, but for electronics.

    In embedded electronics, there are four common protocols and Tessel supports them all in JavaScript.

    This guide will provide a brief overview of the protocols and cover some of the strengths and weaknesses of each.

    Quick Reference

    Most of the time, you will choose your protocol based on the parts you are using when designing your module. Other things to consider are the pins you have available, as well as your communication speed requirements. The following table can be used as a quick reference for the more detailed explanations of each protocol below.

    Protocol # Pins Required Supported Ports Max Speed Example Modules
    GPIO 1 (G1,G2 or G3) A,B,C,D 1kHz All Modules
    SPI 3+ (MOSI, MISO, SCK + 1 GPIO pin) A,B,C,D 25MBit/s
    I2C 2 (SCL and SDA) A,B (shared bus I2C1) C,D (shared bus I2C0) I2C0 - 1Mbit/s I2C1 - 400kbit/s
    UART 2 (TX and RX) A,B,D - hardware C - software 8Mbit/s

    A Note on Level Shifting

    All of the diagrams and discussions below regarding communication protocols assume that the hardware modules you are communicating with operate at 3.3V, just like the Tessel.

    If you have a device on your custom module that operates at 5V, 1.8V, or any other non-3.3V voltage, be careful! Directly connecting components with different operating voltages can damage the Tessel and/or your device.

    You can use devices which operate at different voltages by employing a technique called ‘level shifting’. Sparkfun has a nice writeup on voltage dividers and level shifting that can be used as a starting point.

    The easiest way to avoid this complication is by trying to find module components that natively work at 3.3V.

    GPIO

    Pros: Simple, Requires a single pin

    Cons: Not good for sending complex data

    By far the simplest form of communication is via General Purpose Input/Output (GPIO). GPIO isn’t really a 'protocol’. It is a rudimentary form of communication where you manually (in code) turn a pin on and off or read its state.

    Each port on the Tessel exposes three GPIO pins that can serve as a digital input or output and are marked as G1, G2, and G3.

    GPIO pins available on a Tessel module port: G1, G2, and G3

    By default, Tessel’s GPIO pins are configured to be inputs.

    Input

    When acting as a digital input, a pin can be queried in software and will return a value indicating the current state of the pin: high (1 or true) or low (0 or false).

    The following code snippet is an example of querying the G1 pin on port A.

    var tessel = require('tessel'); // Import tessel
    var portA = tessel.port['A']; // Select Port A
    var myInputPin = portA.pin['G1']; // Assign the G1 pin to a variable
    
    var pinState = myInputPin.read(); // Query the state of the pin
    

    This is great for connecting things like switches, buttons, and even motion detectors. Just remember that the Tessel can only handle signals that are 3.3V or lower.

    The [MicroSD Card Module][sd_module] uses a GPIO pin acting as an input to detect whether a card is inserted or not.

    Determining digital state– a note for the curious:

    It’s pretty clear that if an input pin sees 3.3V it would be interpreted as a high state and if the pin is connected to ground it would recognize that as a low state. But what if the pin senses something in between, like 2V?

    Your first thought might be that a high state is anything 1.65V (halfway between 0 and 3.3) or higher, and anything lower than that would be considered the low state. However, this is not always the case.

    The high/low threshold is always determined by the main processor. In the case of the Tessel, that’s the LPC1830. The documentation on the LPC1830 tells us that the Tessel will consider an input to be high if it is at least 70% of the Tessel’s supply voltage (VDD) which is 3.3V. It also tells us that any signal that is 30% of VDD or lower is guaranteed to be read as a low state. That means anything 2.31V (referenced as VIH) or higher would be considered high, and anything .99V (referenced as VIL) or lower is guaranteed to be interpreted as a low state.

    What about the voltages between .99V and 2.31V? The read behavior is undefined and you are not guaranteed to get an accurate result. That’s one reason why it’s important to make sure that any module you connect to a Tessel input pin provides a high voltage that is between VIH and 3.3V and a low voltage between ground and VIL.

    More GPIO example code and information

    Output

    When acting as a digital output, a pin can be set to one of two states: high (on/1/true) or low (off/0/false). High means the main Tessel board will set that pin to be 3.3V and low means it will set it to 0V.

    Digital output is useful for connected hardware that understands simple on/off states. The following code snippet shows how you can set the state of the G2 pin on port B.

    var tessel = require('tessel'); // Import tessel
    var portB = tessel.port['B']; // Select Port B
    var myOutputPin = portB.pin['G2']; // Assign the G2 pin to a variable
    
    // Set the pin state with ones and zeroes
    myOutputPin.output(1); // Set the pin high
    myOutputPin.output(0); // Set the pin low
    
    // Or use booleans
    myOutputPin.output(false);
    myOutputPin.output(true);
    

    Some examples of using a GPIO pin as an output are simple LEDs and for turning appliances on and off with a relay.

    An output pin is perfect for controlling an LED. Image is licensed under the [Creative Commons Attribution-Share Alike 2.0 Generic](http://creativecommons.org/licenses/by-sa/2.0/deed.en) license.

    More GPIO example code and information

    Tessel Modules That Use The GPIO Protocol

    Every Tessel First party module uses the GPIO protocol in some fashion. The MicroSD Card Module uses a digital input to detect state on a module. The Accelerometer Module uses a digital input to detect a data interrupt from the sensor. The Relay Module uses digital outputs to turn things on and off.

    SPI

    Pros: Fast, supports multiple devices on a single bus, allows two-way communication

    Cons: Requires at least 3 pins

    SPI stands for Serial Peripheral Interface. The SPI protocol allows data to be exchanged one byte at a time between the Tessel and a module via two communication lines. This is great for transferring data like sensor readings or sending commands to a module.

    SPI pins SCK, MISO, and MOSI on Port B of the Tessel

    The SPI protocol is known as a Master/Slave protocol, which means that there is always a single master device which controls the flow of communication with one or more slave devices. Think of the master as a traffic cop. It directs all of the connected slave devices so they know when it’s their turn to communicate.

    When you are creating modules, the Tessel will always act as the master device, and your custom module will be a slave device.

    The SPI protocol requires a minimum of three signal connections and usually has four (this is in addition to the power connections). The following diagram shows the connections (arrows indicate flow of data).

    The red lines constitute the shared bus connections used for talking to the slave devices. The green wire is the shared bus connection used by the slaves to talk to the master. The blue line is the chip select for signaling each slave individually.

    SCK

    This is the clock signal that keeps the Tessel and the module synchronized while transferring data. The two devices need to have a mutual understanding of how fast data is to be transferred between them. This is sometimes referred to as the baud or bitrate. The clock signal provides that reference signal for the devices to use when exchanging data.

    Without a clock signal to synchronize the devices, the devices would have no way to interpret the signal on the data lines.

    One bit of data is transferred with each clock cycle (see the diagram below).

    MOSI

    MOSI stands for Master Out Slave In and is the connection used by the Tessel to send data to the module. It’s on this line that the Tessel will encode its data.

    MISO

    MISO stands for Master In Slave Out and is the connection used by the module to send data to the Tessel.

    SS or CS

    This line, normally referred to as the Slave Select (SS) or Chip Select (CS) line, is used by the master device to notify a specific slave device that it is about to send data. We normally call it CS, but you may see it either way in datasheets and other references.

    When you create a Tessel module which uses the SPI protocol, the CS connection will be handled by one of the GPIO pins (G1, G2, G3) on the Tessel port.

    In the SPI protocol, the SCK, MOSI, and MISO connections are shared between all of the slave devices on a given SPI bus. For example, if you connect the MicroSD Card, Camera, and nRF24 modules to the Tessel at the same time, they will all be using the same SCK, MOSI, and MISO lines from the main Tessel chip.

    When the Tessel needs to send data to the Camera Module, the MicroSD and nRF24 will see that data but should just ignore it. To accomplish this, the Tessel will pull the CS line that is connected to the Camera Module low and leave the CS line high for the MicroSD and nRF24 modules. This lets the camera know that it is the active module and should pay attention.

    The following diagram shows how the various pins in the SPI protocol are toggled to create meaningful data. In this case, the master sends the ASCII character ’S’, and the slave responds with 'F’.

    Timing diagram of SPI data exchange. Modified [image](https://dlnmh9ip6v2uc.cloudfront.net/assets/c/7/8/7/d/52ddb2dcce395fed638b4567.png) from Sparkfun is [CC BY-NC-SA 3.0](http://creativecommons.org/licenses/by-nc-sa/3.0/)

    Remember that the master initiates all communication. When it is ready, the first thing it will do is pull the CS/SS pin low to let the slave device know that a data transmission is about to begin. The master holds this pin low for the duration of the data exchange as seen in the diagram above.

    With the CS/SS pin low, the master will start to toggle the clock pin (SCK) while simultaneously controlling the MOSI to represent the bits of information it wishes to send to the slave. The numbers in green on the diagram above delineate each bit in the byte being transferred.

    It sounds complicated, but remember that the Tessel takes care of all of this pin manipulation for you. All you have to do is write some Javascript like this code snippet, which demonstrates the use of the SPI protocol on port A.

    var portA = tessel.port['A'];
    var spi = new portA.SPI({
      clockSpeed: 4000000 // 4MHz
    });
    
    spi.transfer(new Buffer([0xde, 0xad, 0xbe, 0xef]), function (err, rx) {
      console.log('buffer returned by SPI slave:', rx);
    });
    

    More SPI example code and information

    Tessel Modules That Use The SPI Protocol

    Ambient, Audio, Camera, Micro SD, nRF24, and Infrared

    I2C

    Pros: Only requires 2 pins, multiple devices on a single bus, allows two-way communication

    Cons: Devices can have address conflicts, not as fast as SPI

    I2C stands for Inter-Integrated Circuit and is pronounced “I squared C”, “I two C” or “I-I-C”. I2C is a protocol that allows one device to exchange data with one or more connected devices through the use of a single data line and clock signal.

    I2C pins SCL and SDA on Port B of the Tessel

    I2C is a Master/Slave protocol, which means that there is always a single master device which controls the flow of communication with one or more slave devices.

    I2C only requires two communication connections:

    SCL

    This is the clock signal that keeps the Tessel and the module synchronized while transferring data. The two devices need to have a mutual understanding of how fast data is to be transferred between them. This is sometimes referred to as the baud or bitrate. The clock signal provides that reference signal for the devices to use when exchanging data. Without a clock signal to synchronize the devices, they would have no way to interpret the signal on the data lines.

    SDA

    This is the data line used for exchanging data between the master and slaves. Instead of having separate communication lines for the master and slave devices, they both share a single data connection. The master coordinates the usage of that connection so that only one device is “talking” at a time.

    Since multiple slave devices can use the same SDA line, the master needs a way to distinguish between them and talk to a single device at a time. The I2C protocol uses the concept of device addressing to coordinate traffic on the data line.

    Every single I2C device connected to the Tessel will have an internal address that cannot be the same as any other module connected to the Tessel. This address is usually determined by the device manufacturer and listed in the datasheet. Sometimes you can configure the address through device-specific tweaks defined by the manufacturer. The Tessel, as the master device, needs to know the address of each slave and will use it to notify a device when it wants to communicate with it before transferring data.

    Flow of data between Tessel and multiple I2C devices.

    The following diagram illustrates how the SDA and SCL pins are toggled when transferring data with the I2C protocol.

    To begin a data transaction, the master creates what is called a start condition by pulling the SDA pin low before the SCL pin.

    The master then broadcasts the address of the device it wishes to communicate with by sending each bit of the 7 bit address. Notice the clock signal (SCL) is toggled for each bit. This toggling is how the slaves know when to read each bit of the address so they can determine with which device the master wants to communicate.

    Right after the address, the master sends a read/write bit which signals whether it will be sending data to the slave or reading data from the slave.

    After broadcasting the address, the master either transmits data to the slave or sends the address of a register (internal storage) on the slave from which it wishes to retrieve data.

    Finally, the master will issue a stop condition on the bus by pulling SCL high, followed by SDA.

    It’s a little complicated, but the Tessel takes care of all the details for you. Using the I2C pins on port A looks like this:

    var tessel = require('tessel'); // import tessel
    var portA = tessel.port['A']; // use Port A
    var slaveAddress = 0xDE; // This is the address of the attached module/sensor
    var i2c = new portA.I2C(slaveAddress)
    
    i2c.send(new Buffer([0xde, 0xad, 0xbe, 0xef]), function (err) {
      console.log("I'm done sending the data");
      // Can also use err for error handling
    })
    

    More I2C example code and information

    Tessel Modules That Use The I2C Protocol

    Accelerometer, Climate, RFID, and Servo

    UART

    Pros: Widely supported, allows two-way communication

    Cons: Can’t share communication lines, slower than SPI and I2C

    UART stands for Universal Asynchronous Receiver/Transmitter and is really just a fancy way of referring to a serial port. It is really easy to understand as it only requires two lines: a transmission line (TX) and a receiving line (RX). The Tessel sends data to connected modules on the TX line and gets data back on the RX line.

    UART pins TX and RX on Port B of the Tessel

    TX

    Used by the Tessel to send data to the module.

    RX

    Used by the module to send data to the Tessel.

    When using a UART, it’s important to remember that the communication lines cannot be shared between modules. In fact, because of this, each Tessel port needs its own RX and TX line from the main Tessel chip (LPC1830) as seen below.

    Only ports A, B, and D have dedicated UART lines from the LPC1830.

    Since the LPC1830 doesn’t have 4 UARTs, only Ports A, B, and D have a hardware UART. A software UART can be implemented on Port C but is beyond the scope of this guide. If you need to use a UART for communication we recommend using Port A, B or D.

    A UART data transmission.

    UART transmissions begin with a start bit where the appropriate line (TX or RX) is pulled low by the sending party. Then 5 to 8 data bits are sent. The diagram above shows a scenario where 8 bits are sent.

    Following the data, an optional parity bit is sent, followed by 1 or 2 stop bits, where the sending module pulls the pin high.

    For this protocol to work, the sender and receiver have to agree on a few things.

    1. How many data bits are sent with each packet (5 to 8)?
    2. How fast should the data be sent? This is know as the baud rate.
    3. Is there a parity bit after the data, and is it high or low?
    4. How many stop bits will be sent at the end of each transmission?

    When you want to interact with a specific module via UART, the answers to these questions are found in the module’s datasheet. Using that information you can configure the UART in Javascript like this:

    var port = tessel.port['A'];
    var uart = new port.UART({
      dataBits: 8,
      baudrate: 115200,
      parity: "none",
      stopBits: 1
    });
    
    uart.write('Hello UART');
    

    More example code using a UART

    Tessel Modules That Use a UART

    BLE, Camera, GPS, and GPRS

    This post is also on our docs page, where it will be kept up to date.

    #modules #tessel #kevin sidwar #technical machine #diy #diy module #new module #prototyping

  • Creating Your Own Tessel Module

    Wednesday, January 21, 2015

    1/21/2015– Kevin Sidwar, Kelsey Breseman

    This post is also on our docs page, where it will be kept up to date.

    What Is a Module?

    Modules should be devices with clear-cut functionality. That is to say, they should have a single, well-defined purpose or a set of closely related functions, rather than an eclectic mix of capabilities onboard. This requirement is designed to reduce complexity, cost, and power consumption and maximize reusability in hardware and software.

    –Tessel hardware docs

    One of the main goals of the Tessel platform is “connected hardware as easy as npm install.” If you need an accelerometer, Bluetooth Low Energy connection, SIM card capability, or any of the other 14 first-party modules available, you can literally plug, npm install, and play.

    There is also a growing library of community-contributed third-party modules: npm libraries paired with some simple wiring instructions, built for specific pieces of hardware.

    But what if your project needs functionality that can’t be provided by one of the existing first- or third-party modules? You make your own, of course.

    This guide will walk you through the basics of creating your own Tessel module using our new DIY Modules.

    A Quick Note of Encouragement

    Making your own module might seem like an overwhelming task best left to those who know things like Ohm’s Law, how to solder, and why licking a 9V doesn’t feel very good. But while having some electronics knowledge doesn’t hurt, it’s not a hard and fast prerequisite. If you know how to program, you are smart enough to figure out the basic concepts and make awesome things happen. Just trust us and read on.

    Module Design Basics

    Before you venture into the world of custom module creation, we need to cover some basics that will help guide you along the way.

    Every module created for the Tessel involves 5 parts:

    1. Power
    2. Communication
    3. Software
    4. Documentation
    5. Sharing

    If you understand how each of these fit into the module creation process, you will be well on your way to creating your own custom module. Let’s start with power.

    Power

    When dealing with anything in electronics, whether it be sensors, displays, buttons, or servos, you have to provide power. Everything needs a power source, and Tessel modules are no exception. In its simplest form, you can think of a power source as two connections; a positive voltage and a ground connection. These connections are provided on each Tessel port as seen in the image below.

    Power connections on Tessel’s Port B

    The main Tessel board can be powered several ways, but regardless of how you provide power to the main board it ultimately turns that source into 3.3V. That’s the native “voltage language” of the Tessel. It likes to speak 3.3V to everything if possible.

    One of the nice things about the proto-module is that the 3.3V and ground connections are exposed as two rails that run along each side of the module as seen below. This allows you to easily power your module components.

    Proto-module power rails

    Special Considerations

    If all of the components on your custom module operate at 3.3V, then your power design is extremely simple. You just use the 3.3V and ground rails and connect your components accordingly (the custom screen module below is a good example). Sometimes, however, you may encounter a situation where 3.3V is not what you need, like in the case of the servo module.

    Many servos like to operate at 5V. That’s their native “voltage language” and so the 3.3V provided by the Tessel isn’t ideal and, in many cases, just won’t work. Servos can also draw a lot of current, which may overwhelm the Tessel’s power supply. To solve this problem, you’ll notice that the servo module has a DC barrel jack on it that allows you to plug in a 5V adapter to provide sufficient power to the connected servos.

    DC Barrel Jack on the Servo Module

    From the servo module schematic, we can see that communication is accomplished with the normal I2C lines, which operate at 3.3V, but servo power is provided via schematic component J2, which is the barrel jack.

    This guide isn’t meant to be a comprehensive power reference, but we just want to point out that if you have any components on your custom module that work outside of the 3.3V realm, you will need to design for it. To simplify your module design, we recommend using 3.3V components where possible.

    The Power Warnings

    Here are some items to remember when working with power in electronics.

    • ALWAYS unplug your Tessel and any external power before making or altering connections.
    • Don’t mix voltages unless you know what you’re doing. For example, if you put 5V on any of the module pins, you can ruin your Tessel.
    • Never connect the positive voltage directly to ground. This is called a short circuit and can ruin components and your day.
    • Always exercise caution and verify that you have hooked everything up correctly before plugging in your Tessel.

    Communication

    Once you have decided how you are going to power your custom module, it’s time to decide how the main Tessel board will talk to it.

    In the world of web communication, there are standards like HTTP, HTTPS, and FTP that allow different systems to talk to each other in well-defined ways. The same concept exists in the hardware world and the Tessel supports four standard communication protocols for talking to modules.

    Because the Tessel does most of the heavy lifting for all of these, you don’t need to be an expert to use them in your custom module. However, if you’d like to learn a little more, we’ve provided a simple overview of each.

    So Which Communication Protocol Should I Use?

    Knowing that there are four communication options available to you, which should you use for your custom module? The good news is that this will usually be decided for you based on the type of module you are creating. For example, most PIR sensor modules will set a pin high when motion is detected, which can be read with a simple digital input (GPIO). The same applies to sensors. For example, the Si7005 temperature and humidity sensor on the Climate Module communicates via the I2C protocol. Usually sensors will only support one protocol– so the decision is easy, you use that one.

    You will find some modules that support both SPI and I2C, and either will work just fine with the Tessel. As a general rule of thumb, we recommend you favor the SPI protocol in these scenarios as it eliminates the risk of I2C address collisions with other connected I2C modules.

    Software

    Once you have the power and communication all worked out and connected, it’s time to start writing JavaScript to talk to your module. This is where the open-source nature of the Tessel really comes in handy. We’ve already used all of the possible communication protocols in our modules and the code is free to look at and copy.

    Design an API for working with your module so that it’s easy for others to integrate into their projects. As a general rule, top priority is intuitive interaction. Second priority is exposing as many features as you can. You can find a lot of great information about organizing your project and writing an API in Making a Tessel-style Library for Third-Party Hardware.

    Documentation and Sharing

    Once you have a working module, it’s time to share the good news with everyone so other people can build amazing things with your work. We recommend doing a few things to share it with the community as outlined below. This helps create a consistent feel across all Tessel modules, whether they are official modules or submitted by the community.

    Create A Git Repo

    Having your code in a git repo and available online makes it easy for others to grab your code and start using it in their projects. To help you get started we’ve created a template repository that you can use as a starting point.

    Custom Module Git Repo Template

    Document It

    You may have just created the world’s most amazing Tessel module, but how is anybody going to know about it or use it? Once you’ve hashed out the API and everything is working, it’s important to document its use so others can easily apply your work to their projects. The best way to do this is to use the README template, which includes things like how to install the module, example usage, and API information.

    Publish Your Code on NPM

    Once your git repo is ready and you’ve documented your module, this step is really easy and makes your module fit the Tessel motto of “connected hardware as easy as npm install.” If you’ve never published code to NPM before, you can get started with just four lines of code (run in a shell window).

    npm set init.author.name "Your Name"
    npm set init.author.email "you@example.com"
    npm set init.author.url "http://yourblog.com"
    
    npm adduser
    

    This sets up your NPM author info. Now you’re ready to create your package.json file. There is one in the repo template but we suggest creating it by running npm init from within the project directory.

    npm init
    

    Edit your package.json file to include a name, version, and description. We also highly recommend adding “tessel” as a keyword so that other Tessel users can easily find your work. Most of the package.json file is self-explanatory and follows the npm package.json standard with the exception of the hardware member.

    **hardware** section of package.json

    This is a Tessel-specific item that you must add manually and is a list of files and folders in your project that you would like to exclude when code is pushed to your Tessel.

    Once your package.json file is complete you’re ready to publish your code. Run the following command from the top level directory of your project.

        npm publish ./
    

    Create a Project Page

    The Tessel Projects page is a way to share your module directly with the Tessel community. You simply provide a few pieces of information, a picture, and can even use your README.md file from your Git repo as the contents.

    Submit Your Module

    We’re always looking to add modules to our third-party module list so if you’d like your custom module to be listed at tessel.io/modules then fill out this form and we’d be happy to review it.

    Third-Party Module Submission Form

    A great example of using this module-creation pattern can be found in Making a Tessel-style Library for Third-Party Hardware.

    Your First Custom Module

    So now that we’ve described the pattern for making a custom module, let’s walk through creating a very simple module using that pattern. The Tessel has a spare button on the main board, but maybe you’d like to add one as a module. Kelsey did a great writeup on adding a button to the GPIO bank so let’s use her work to take it one step further using a proto-module.

    Power

    You might not think of a button as needing power, and you’re right, sort of. While the button itself doesn’t need power to function, we can connect our button in such a way that it uses the power connections to create high and low states on a GPIO pin.

    GPIO pins on the Tessel will always read high/truthy with nothing connected, because internally (inside the main Tessel chip), they are pulled up to the 3.3V supply. That’s our positive connection.

    The other power connection is ground, which we’ll connect to one side of our button. It doesn’t matter which side, because a button is just a momentary switch that creates and breaks a connection. You can’t hook it up backward. We’ll get to connecting the other side of the button in a minute.

    Communication

    As mentioned above, normally your communication protocol is determined by your module. In the case of a button, we use a GPIO pin because we want to read the state of the button.

    Each port on the Tessel has 3 pins that can serve this purpose, and you are free to pick any one you like because it doesn’t matter.

    GPIO pins available on a Tessel module port: G1, G2, and G3

    We’re going to choose G1, which is what we will hook up to the other side of the button. When the button is not pressed, our input pin will read high, or true. When we press it, we are making a connection between our GPIO pin and ground, which will cause a low state to be present on the input pin. This is what the design looks like.

    Schematic of button connections

    Soldered together on a proto-module board.

    Don’t let the soldering part scare you. Soldering components like this onto a proto-module is a little harder than learning to use a hot glue gun, but not a lot harder. This tutorial from Sparkfun is a great place to start learning soldering.

    Let’s go ahead and plug our module into Port A. Remember to never make connections while your Tessel is powered up. Always unplug it first.

    Software

    With everything hooked up, it’s time to write some Javascript.

    Actually, we’re going to reuse the code from Kelsey and modify it just a bit. Since she followed the style guidelines and shared her work on NPM, we actually don’t have to write the bulk of the code. She’s even provided a Quick Start guide in her documentation, so we’ll use that.

    1. Install the tessel-gpio-button package. This will allow us to reuse Kelsey’s work.

      npm install tessel-gpio-button

    2. Create a file named myButton.js and copy her Quick Start code into it. It should look like this:

        // examples/button.js
        // Count button presses
    
        var tessel = require('tessel');
        var buttonLib = require('../');
        var myButton = buttonLib.use(tessel.port['GPIO'].pin['G3']);
    
        var i = 0;
    
        myButton.on('ready', function () {
          myButton.on('press', function () {
            i++;
            console.log('Press', i);
          });
    
          myButton.on('release', function () {
            i++;
            console.log('Release', i);
          });
        });
    

    This almost works right out of the box. We just need to make two small adjustments. Do you see them?

    First, to include her module we won’t use “require(’../’).” Instead we’ll include the module directly with require(‘tessel-gpio-button’).

    Second, she hooked her button up to the G3 pin on the GPIO bank, but we’ve hooked our proto-module up to Port A and used the G1 pin. So all we have to change is the line where myButton is defined. We’ll change it to be:

    var myButton = buttonLib.use(tessel.port['A'].pin['G1']);
    

    Save your changes and test it out.

    tessel run myButton.js
    

    Every time you push your button it should log to the console.

    Congratulations! You just created your first custom module for the Tessel.

    Custom button module connected to the Tessel

    Documentation and Sharing

    We sort of cheated for our first module; Kelsey had already created an NPM package that we could reuse, so there wasn’t really anything to document or share on the software side. There is nothing wrong with that. In fact, the less code you have to write, the better. This is a great example of how taking the time to document and share your work benefits the entire community.

    What we can do though is create a project page showing how we took Kelsey’s button to the next level in the form of a plug-in module. We created the physical module. It’s a simple module, but we should document it in case someone else wants a button module like ours.

    Custom Button Module Project Page

    Custom Screen Module

    Now that you have a simple module under your belt, it’s time to level up. To date, the module that people have requested the most is a screen module. Displays are tricky because they come in so many flavors. There are simple 7-segment displays, LCD displays, OLEDs, resistive touchscreens, capacitive touchscreens, and more. This is a great use case for a custom module.

    One of the popular screen modules in embedded projects is the Nokia 5110, because of its simple interface and low cost. Let’s see how we’d create a module for it by following the same pattern as before.

    For this example we’ll use the Nokia 5110 breakout from Sparkfun, but you could also use the Adafruit version of the screen or just try to snag one on Ebay

    Nokia 5110 Graphic LCD

    Power

    The 5110 has a listed power supply range of 2.7V to 3.3V, which means any voltage in between (inclusive) is sufficient to power the screen. Since the Tessel ports have a 3.3V supply pin we don’t have to do anything special to hook it up. All we need to do is connect the screen VCC, or positive pin, to a 3.3V rail on the proto-module and the GND on the screen to a GND rail.

    Because of the screen’s size, we’ll use one of the double-wide proto-modules this time, even though we’ll only use a single port to connect everything.

    Double-Wide Proto-Module

    Communication

    Just like in the button example, the communication protocol for the screen has already been chosen for us. The Nokia 5110 uses a slightly modified version of SPI to communicate with a parent controller, namely the Tessel in our case.

    In addition to the normal SPI protocol, the 5110 has an extra pin involved (D/C) that tells the screen whether the data we are sending via SPI is a special command or actual screen data.

    The D/C pin is controlled by a simple high or low signal, which is a perfect job for one of the GPIO pins.

    The following table shows all of the communication connections available on our screen and how we’ll attach them to the Tessel port.

    Nokia 5110 Pin Proto-Module Connetion
    SCE G1
    RST Connected to 3.3V through 10K resistor
    D/C G2
    MOSI MOSI
    SCLK SCK
    LED Connected to G3 through 330 ohm resistor
    Design Note

    The Nokia 5110 has 4 connections that can utilize GPIO pins for functionality. The D/C (data/command) and SCE (chip select) pins have to be used to get data to the screen. That leaves just one GPIO pin on the port with RST and LED left unconnected. You have a few options here.

    1. Wire RST to 3.3V through a 10K resistor which prevents you from resetting the screen in code. This allows you to control the backlight with the free GPIO pin.
    2. Wire LED to 3.3V through a 330 ohm resistor (to limit current) which will permanently turn on the backlight. This leaves a GPIO free that can be used to reset the screen via Javascript.
    3. Since we’re using the double-wide, you could use a GPIO pin from the adjacent port and have use of both LED and RST
    4. Connect SCE (chip select) to ground, which frees up a GPIO so you can control both LED and RST. Holding the chip select low, however, makes it so that no other SPI device (including other Tessel modules that use SPI e.g., the Camera module) can be connected to the Tessel on any other port.

    We decided to go with option 1 because there isn’t really a need to reset the screen in most cases and it allows control of the backlight with a GPIO pin. This is another great thing about custom modules. You can design it however you want to fit your project needs.

    We hooked everything up using the Graphic LCD Hookup Guide. We recommend testing everything with a breadboard before you solder everything in place, just to make sure it works the way you expect it to.

    Here is what the module looks like soldered to the double-wide proto-module.

    Nokia 5110 soldered to a large proto-module board

    Software

    With the screen hooked up, it’s time to start writing code. We’ll follow the pattern found in the Git Repo Template and start by creating a directory called tessel-nokia5110 and cd into that directory. Next, we’ll create index.js which is where we’ll write our API using the example index.js template as a guide.

    Because this screen is so popular, there are lots of code examples and libraries online for interacting with it. We don’t need to reinvent the wheel; we just want to control the screen with JavaScript.

    We took a simple Arduino library for this screen and ported it to JavaScript. Our API is very simple and exposes just one event and a few methods.

    Event

    Nokia5110.on('ready’, callback(err, screen)) - Emitted when the screen object is first initialized

    Methods

    Nokia5110.gotoXY(x,y,[callback(err)]) - Sets the active cursor location to (x,y)

    Nokia5110.character(char, [callback(err)]) - Writes a single character to the display

    Nokia5110.string(data, [callback(err)]) - Writes a string to the display

    Nokia5110.bitmap(bitmapData, [callback(err)]) - Draws a monochrome bitmap from bitmapData

    Nokia5110.clear([callback(err)]) - Clears the display

    Nokia5110.setBacklight(state) - Turns the backlight on if state is truthy, off otherwise

    Documentation

    Now that the module is connected up and the software is working, it’s time to document its use.

    We can’t stress enough how important this is, and it really only takes a few minutes once you’ve defined everything. Just think of all the times you’ve needed a piece of code and found a beautifully documented example that had you up and running in minutes. Share that love with others when you create your own modules, no matter how trivial you think they are.

    In our case, we’ll take the template README.md file and add some notes for getting started as well as document our API.

    We’ll also create an examples folder to show how the module can be used.

    Sharing

    Now it’s time to share our new creation with the world by:

    Finished screen module

    Resource List

    To help you get started creating your own custom modules, here is a list of the resources we used to put this tutorial together.

    Power
    Communication
    Software
    Documentation
    Sharing

    This post is also on our docs page, where it will be kept up to date.

    #modules #tessel #technical machine #kevin sidwar #diy #diy module #new module #prototyping #kelsey breseman

  • Community-Contributed and DIY Modules

    Tuesday, January 20, 2015

    1/20/2015– Updates

    We have a couple of small announcements for you:

    We now have international resellers in Japan, China, Australia, and the UK/EU. Check them out here!

    We’re also announcing a new module in our store: the DIY Module. It comes in single-wide, double-wide, and a kit including both sizes and a few electronic components.

    Community-contributed modules

    Complementing the fourteen plug-and-play first-party modules we built, there are currently nine third-party modules on our site. These are community-contributed projects, whereby someone publishes an npm abstraction for a piece of hardware and shows how to hook it up. Here are a few examples:

    OLED Display

    Proximity Sensor

    Matrix Keypad

    These aren’t quite as plug-and-play as first-party modules, but they’re well-documented, nicely abstracted into npm libraries, and often pretty cheap. Definitely check them out.

    (If you’ve made an npm module for using new hardware on Tessel, please submit your module to be listed as well!)

    DIY Modules

    We’re also announcing a new module in our store: the DIY Module. It comes in Single-wide DIY Module, Double-wide DIY Module, and a the DIY Module Kit. including both sizes and a few electronic components.

    Now, for those of you who want to take this a bit further, we’ve just added the Single-wide DIY Module, the Double-wide DIY Module, and the DIY Module Kit to our store. It has (unsoldered) 10-pin headers, labeled pins, and power and ground rails, and comes in regular-sized, double-wide (in case you’re making something big, like our RFID module), and a pack of both with some capacitors and buttons.

    (Above: DIY module original prototypes. Below: DIY Module Kit in store)

    If you’d like to get a bit more hands-on with electronics, we’ve written a Beginner Guide for module creation and a Companion Guide for understanding how different pieces of hardware talk to each other.

    We’ve tried to assume no electrical engineering experience, so please file issues on the guide repos if anything is confusing.

    Button Module

    EMIC 2 (Speech) Module

    Nokia Screen Module

    We hope you like it– this is a by-request module.

    We also have something bigger in the works, but we’re not quite ready to talk about it yet… stay tuned!

    Best,
    Kelsey, Jia, Tim, Jon, Kwyn, Eric, Kevin, and Ken

    #update #updates #diy #module #new module #diy module #proto-module #community #community contributed #open source

  • An Interview with Pirumpi: Webservers on Microcontrollers

    Friday, January 9, 2015

    1/9/2015– Kelsey Breseman

    Carlos’s face lights up as he says the names of his microcontrollers, holding them up to the screen so I can see each one: “Espruino, Netduino, EZ Robots, Tessel, of course.” Carlos Martin, or pirumpi on the Tessel forums, is thankful that he gets to write code, and states simply that programming the physical world is what everyone wants to do.

    Originally a math major in his native Venezuela, Carlos came to the United States in the early 2000s for a change of political climate. He didn’t go back to school right away, and spent some time working away from computers– but over the last several years, he’s been working his way back towards the work he loves– programming and building things.

    Currently, he’s a software engineer at a network security company in Colorado, as well as a couple of other jobs and the full-time role of being a father to two daughters and one boy. But at night, when the kids are asleep, he takes a few hours to make robotics projects on every kind of microcontroller he can get his hands on.

    Kelsey: Can you tell me a bit about your background?

    Carlos: I’ve been working as a software engineer for four years, at this security company. We do surveillance & video analytics for many chain companies in the US, Canada and the UK.

    I’m originally from Venezuela, born and raised. Around 2000, I went to Central University of Venezuela, majoring in mathematics. Then this crazy government came in– you know, Chavez, and started messing with my family’s business and bank accounts. My mom got all freaked out, so we came to the United States around 2000, 2001.

    When we first moved to the United States, I didn’t do much. I spent four or five years working at Disney World. But after about six years out of college, I decided to go to Westwood College, here in Colorado. They’ve got a great Associate’s degree, so I became a network engineer.

    Because of that, I got a job working in IT, for a forensic accounting company in Denver. But my true passion was in math and coding, so I got really excited when I got to start this job.

    I’m almost finished with my Bachelor’s degree in information security, through Colorado Technical University. I’ve only got three more classes left.

    Kelsey: Why did you decide to get a Tessel?

    Carlos: I’m kind of a microcontroller freak. I go on Kickstarter, or any other crowdsourcing site, anywhere people are trying to make microcontrollers. I really like them, I get so excited about it, and I want to have them all.

    And then I saw Tessel. Of all of the microcontrollers, I like Tessel the most, because it’s so easy to use. You plug things together and it just works.

    Kelsey: What sparked your interest in microcontrollers?

    Carlos: I was always into it as a hobby. When I was around 12, I got my first computer. It was a Pentium 1, on Windows 3.1. My favorite thing to do was to take it apart. But I constantly burned the motherboard. My mom got really mad. So she decided I needed to learn to fix computers.

    I was in middle school, and I worked through this certificate on computer repair. I learned how to take computers apart and fix them when I was pretty young. So from there, I started going into software and electronics. But I spent most of my time in middle school doing crazy math stuff.

    I didn’t get into microcontrollers until I got to the United States, not until around 2005. I got so excited– programming electronics is the dream, for any software developer. You write code but you want to control things, physical things.

    I like to combine electronics with web technologies. When Node.JS came out, I got so excited– JavaScript on the server side. Lots of people use it to create their own command line interfaces. You started seeing these web technologies being used for other things.

    Kelsey: What’s the first thing you made on Tessel?

    Carlos: The first thing that I do when I get a new microcontroller is make a webserver. I want a webpage running on every microcontroller. So the first thing that I did was this really simple webpage running on the Tessel, called tiny-router.

    I wanted something like Express, but made to run on any microcontroller. I want it to be easy, and simple, and not a lot of code. I want it to run on Edison, and Espruino, everywhere. So that’s what I made.

    I like to follow the technology trend, see where software is going, and microcontrollers are big right now.

    Every company that I know of is trying to come out with their own version of the Internet of Things, and companies like Intel, and like you guys [Technical Machine], are making tools to let people create their own Internet of Things.

    That’s why I like microcontrollers so much, they empower people who don’t have the time to make a circuit from scratch, but who have the passion and the desire to create.

    I’m a busy guy, but this is what I like to do. I go to my office at home, after the kids go to sleep, close the door, and just play with electronics.

    #kelsey breseman #pirumpi #microcontrollers #webservers #user interview

  • An Interview with io2work: Industrial Automation

    Tuesday, December 23, 2014

    12/23/2014– Kelsey Breseman

    I first became intrigued by Josh Dudley when he mentioned a Tessel project that involved controlling a welder. Josh (io2work on our forums) is a welding engineer by training, an industrial researcher and IT tech by trade, and a self-taught computer and electronics engineer by choice. He’s been picking up JavaScript, Node, and more recently Tessel in pursuit of his vision for modern web interfaces on industrial machines.

    Kelsey: What’s your background in engineering?

    Josh: My actual engineering degree is in something relatively unrelated– I’m a welding engineer from Ohio State. But I’ve started doing the computer stuff out of personal interest over the last five years or so– it’s something that’s grown out of interest, but there are also needs here at work for automating some different processes.

    I’ve been exploring different avenues. Back in late 2011, I read about Node.JS. I’d been learning some JavaScript and wanted to continue down that path.

    When I saw that I could communicate with serial devices through Node.JS, I set up a Node server on a Raspberry Pi and started figuring out how to communicate with these precision power supplies that we use for one of our manufacturing processes.

    Kelsey: What’s the first thing you made on a Tessel?

    Josh: The first thing I made with it was an automated welding process that controls rotation with some limit switches and turns the welder on and off with a Tessel relay module.

    It’s relatively simple; it has three buttons on it, and one plunger-style limit switch on the turntable so I know when it’s made a 360 degree revolution. One button tells it to activate and start turning and welding. When it hits the limit switch, after it rotates around, it turns everything back off. It automates welding around the drum for us.

    Kelsey: How do you control a welder with a Tessel?

    Josh: In this case, it’s just a simple relay. I’m using a standard MIG welder. It has a trigger that you pull, which is nothing more than opening and closing a contact. So all I did was the same thing, programmatically, with one of the Tessel relays.

    Editor’s note: the code for this project can be found here.

    Kelsey: Did that make you nervous, hooking up something as critical as a welder to your own wiring?

    Josh: Not really. I grew up in a machine shop environment, so I’m used to tinkering with things.

    My skill set tends more naturally towards the mechanical side of things, and the electrical and computer stuff has become a personal interest– I learn it as I go.

    Kelsey: Where do you envision this sort of automation going in the future?

    Josh: When I started working on the Raspberry Pi, I came up with this vision. I’ve worked on a lot of homemade automation stuff, one-off stuff that’s relatively simple. But it’s aging– it’s written on stuff that was made fifteen years ago, applications that are in Visual BASIC, dependent upon Windows 95 or Windows 98 in order to run. I want to start moving some of these simpler things to the browser.

    I’m creating a vision for that here, where I work, moving more and more of our custom automation stuff directly into the browser so we don’t have to deal with client-installed software. That’s the driver for all of this. And the Tessel just made it even easier to do, because it’s a microcontroller, with inputs and outputs on it, and the webserver’s built right in, so all that stuff fit perfectly with what I was already trying to do.

    For most stuff in the manufacturing environment, it doesn’t matter if it happens in one millisecond or 100 milliseconds, so it isn’t often necessary to deal with compiled, client-installed code that is dependent on complex IDEs. Plus technology keeps closing this performance gap to the point where it simply isn’t an issue any more.

    Therefore, the simplicity and the ability to use one language, whether I’m writing my frontend in the browser, or talking to the device that’s controlling the IO, makes my workflow easier, and it’s easier to maintain. Plus, I get to grow my skills quickly, because I’m concentrating on one thing.

    A combination of laziness and necessity is the “mother of invention” here; as I become responsible for more of these machines, I want them to be easier to work on. I want to be able to open up a modern web browser and do what I need to do.

    Kelsey: What would make it easier to develop these sorts of automations for the industrial sphere?

    Josh: An industrial hardened version of the Tessel, similar to what they are doing with Arduino at controllino.cc, would be absolutely awesome. The event-driven nature of Node.JS just makes a ton of sense for controls-based stuff, and being able to use the same language for the entire stack makes things simple and easy to upgrade and maintain.

    Everything in the industrial environment gets mounted into a cabinet on a DIN rail, so a case that’s mountable would be one thing. And then of course things like electrostatic discharge protection. It would also need to be coupled with a relatively robust power supply.

    A lot of things in the industrial world depends on 24V logic or 12V logic. I’ve been able to get around that with Tessel by using some digital relays that will take the 3.3V output that Tessel provides, and then I have a 24V secondary power supply. I’m opening and closing the relay with the Tessel and that’s my 24V logic.

    Kelsey: What are some projects you’re working on right now?

    Josh: I’m working on a project right now, where I have an HTML5-based web application, using websockets for talking to a machine that I’m controlling– making ramps go up and down. I’m also using UART (along with a SparkFun RS232 Shifter), reading the serial port, in order to get the information back from a digital level, and then I’ve got some proximity switches I’m reading and doing different stuff on.

    I’ve got another project I’m working on, helping one of our other engineers prototype something for a new process – rotating a part and dipping it down in a masking material, so I’ve got to control a pneumatic raising and lowering device, and talking to a DC motor to rotate the part.

    But now that I’ve got a little bit of experience with it, something like that takes just a few hours.

    Kelsey: What do you see as the future of industrial automation?

    Josh: I would hope that more and more of it will be moving to the web browser. The whole platform-independent aspect of the web is what’s so desirable. It doesn’t matter whether I bring my Macbook Air in, or my iPad, or my PC, I can pop open a webpage in a modern browser, and do whatever I want to do.

    Creating web interfaces makes it easier to go back and update one codebase. Devices change over time, and the web progresses. On the web, you just update your codebase accordingly, and you still have it available on a larger number of devices.

    I hope that the manufacturing industries get with the times and start taking advantage of these open platforms.

    #kelsey breseman #interview #josh dudley #io2work #industrial #industrial automation #tessel #technical machine

August 2018

January 2018

July 2017

February 2017

November 2016

October 2016

September 2016

August 2016

July 2016

June 2016

April 2016

March 2016

February 2016

November 2015

September 2015

August 2015

July 2015

June 2015

May 2015

March 2015

February 2015

January 2015

December 2014

November 2014

October 2014

September 2014

August 2014

July 2014

June 2014

May 2014

April 2014

March 2014

February 2014

January 2014

December 2013

November 2013

October 2013

September 2013

August 2013

July 2013