The nw2s::b is extensible through a few means. This post will outline them and how you can use them.
Note that each of the listed pin headers is providing raw access to the Arduino pins. Arduino pins are notoriously non-robust as even they are simply giving you raw access to the microprocessor. If you build an extension or attach anything to one of the exposed pins, you will need to take all of the same precautions as you would any other microprocessor interface. You will need something. Probably more than one thing. Buffer driver, comparator, zener diode, protection resistor, optoisolator, FET, whatever is called for. If you don’t, you will almost certainly destroy that pin or the entire microcontroller.
ALSO: The Ardiuino Due is a 3.3V device. Most other other Arduinos (Due, Leonardo, Mega, etc) are 5V devices, and some breakout boards are designed for one or the other. If you use a 5V logic device to interface with, you will damage the Due.
Now that that’s out of the way, let’s walk through the options:
There are two USB ports on the Arduino. You can find lots of information about them on the Arduino Due pages, but the general breakdown is this:
The native USB port is connected directly to the SAMX3A. If you would like to connect any USB devices to the Arduino like mice, keyboards, etc, then this is the port you should use. You will need to write your own device driver for whichever device you use, but you can find some examples here (use a keyboard or mouse) and here (turn your Arduino into a USB MIDI device!) – just pay attention, some examples set up the arduino as a USB host and others a USB client.
On the Due, the programming port is connected to a tiny microcontroller (ATmega16U2) that is programmed to be a USB to serial converter. This 16U2 will appear to be a serial port when connected to your computer and is what the Arduino IDE uses to communicate and to upload programs.
The 16U2 also provides one important piece of functionality. When the IDE sends a specific signal, the 16U2 triggers the hardware erase and reset sequence. This erases the SAM3X’s program memory and resets it to the boot loader which allows the IDE to program the SAM3X.
Because the programming USB provided such specific functionality, it should only be used for programming.
You’ll read below that the bluetooth connection provides a similar programmability connectivity. It’s important to note, however, that the erase and reset functionality provided by the bluetooth connection is a software routine rather than a hardware function. This means that if you completely crash your Due or do not use the nw2s::b framework, then you will not be able to program the Arduino over bluetooth. Because of this, I typically keep a USB cable connected to the Due at all times, but leave it behind the panel until I need it. (Another useful addition will be a panel mount USB cable on a blank panel, but that will come a little later)
Due to the positioning of the Arduino, if you want to use the USB ports, then you will need a little bit of room above the module and a reasonably flexible USB cable. I’m using a Doepfer A-100 and even in the top row, there’s plenty of space. Something with less room may require you to move to a second row or find a 90 degree micro USB cable
GPIO stands for General Purpose Input/Output, if you don’t know. Most of the pins on the Arduino can be used as GPIO pins. Some of them, however have hardware acceleration for their intended purpose, so it’s generally best to leave those pins to be used for their intended purpose and to use the GPIO pins for theirs.
The nw2s::b uses GPIO pins for a few purposes. You can follow these usages or find new ones.
- digital inputs
- digital outputs
- SPI chip select
- beat display via demux
There are three unused GPIO pins. Due pins 38, 39, and 40 are exposed on the GPIO pin header next to the Arduino headers. The image below illustrates their location.
The UART ports provide old-school serial protocols. There are four UARTs available on the Due. The first UART is connected to the programming interface. The three remaining UARTs are exposed on the serial pin headers. The most obvious use for one of these pin headers would be as a MIDI interface, but there are likely others that come to mind as well.
The three UARTs are on Due pins 14 through 19.
Please remember that these are 3.3V UARTs. A lot of TTL logic serial interfaces are 5V, so be sure to build in a buffer using either a bi-directional level converter or a simple 74LVC family driver.
There is a bluetooth-to-serial breakout board that, along with the usb-to-serial converter, is attached to UART 1. This means that you may use a bluetooth connection to communicate from your host computer to the nw2s::b. There are more details on the Bluetooth Pairing page.
I have built into the nw2s::b framework, a serial command interpreter which allows you to send text-based commands to the nw2s::b to do things like trigger events, configure IO, or even reset the device to accept an incoming program. This framework deserves its own writeup, so I won’t go into any further details here.
The Due provides two TWI interfaces. There is one that is used to interface to the LED driver. As it is already wired, and the LED driver breakout board provides a convenient second set of headers, it is possible to simply chain onto the existing TWI bus.
It may be more reliable, however, to use your own TWI bus since it is available. The second SPI interface uses pins 20 and 21 and is also exposed on the serial pinheaders as shown below.
SPI is faster than TWI, but also takes more pins to operate. Besides the clock, master-in-slave-out, and master-out-slave-in pins, it requires a chip-select pin (or pins). This pin allows you to connect multiple devices to the same bus and allows you to indicate which device is being communicated with.
There is only a single SPI interface available on the ‘b, and it is dedicated to the SD Card reader and the CV DACs. While it is technically possible to use SPI for your projects to also leverage this bus, you should seriously consider using TWI/I2C instead.
The SAM3X provides a hardware CAN interface, but the Arduino firmware as yet does not support it. Technically, you could use them for GPIO pins if you like, but if they ever provide a CAN API, then you may want to migrate your code to use one of the dedicated GPIO pins.
The following diageam illustrates the placement of the pins. Note that the diagram shows the PCB from above, but when you are looking at the pins, you’ll most likely have flipped the ‘b over on it’s back. In that case, the orientation will be a mirror of what you’re seeing.