Image made with Fritzing
Hardware interfaces for the MinnowBoard Max are exposed through the 26-pin header JP1 on the board. Functionality includes:
Note that the MinnowBoard Max uses 3.3V logic levels on all IO pins. In addition all the pins are buffered by TXS0104E level shifters, with the exception of power and ground pins. These level shifters appear as open collector outputs with a 10KΩ resistive pull-up, and the pull-up is present regardless of whether the IO is set to input or output. The open-collector nature of the level shifters means is that the pins can output a ‘0’ strongly, but only weakly output a ‘1’. This is important to keep in mind when attaching devices which draw current from the pins (such as an LED). See the Blinky Sample for the correct way to interface an LED to the MinnowBoard Max.
The following GPIO pins are accessible through APIs:
Note: GPIO 4 and GPIO 5 are used by the MinnowBoard Max as bootstrap configuration pins for the BIOS. Make sure that attached devices do not drive these GPIO low during boot, as this could prevent the MBM from booting. After the MBM has booted past the BIOS, these GPIO can be used normally.
As an example, the following code opens GPIO 5 as an output and writes a digital ‘1’ out on the pin:
There are two Serial UARTS available on the MBM: UART1 and UART2
UART1 has the standard UART1 TX and UART1 RX lines, along with flow control signals UART1 CTS and UART1 RTS.
UART1 is not working as of build 10240. Please use UART2 or a USB-Serial converter.
UART2 includes just the UART2 TX and UART2 RX lines.
UART2 does not support flow control, so accessing the following properties of SerialDevice can result in an exception being thrown:
The example below initializes UART2 and performs a write followed by a read:
Note that you must add the following capability to the Package.appxmanifest file in your UWP project to run Serial UART code:
Visual Studio 2017 has a known bug in the Manifest Designer (the visual editor for appxmanifest files) that affects the serialcommunication capability. If your appxmanifest adds the serialcommunication capability, modifying your appxmanifest with the designer will corrupt your appxmanifest (the Device xml child will be lost). You can workaround this problem by hand editting the appxmanifest by right-clicking your appxmanifest and selecting View Code from the context menu.
Let’s look at the I2C bus available on this device.
There is one I2C controller I2C5 exposed on the pin header with two lines SDA and SCL. 10KΩ internal pull-up resistors are already present on these lines.
The example below initializes I2C5 and writes data to an I2C device with address 0x40:
The MinnowBoard Max has a known issue with the I2C bus which causes communication problems with certain I2C devices. Normally, an I2C device will acknowledge its address during a bus request. However, under certain conditions this acknowledge fails to propagate back through the level shifters to the MBM, and as a result the CPU thinks the device did not respond and cancels the bus transaction. The issue seems to be related to the TXS0104E level shifters on the IO pins, which can trigger prematurely due to voltage spikes on the line. The current workaround is to insert a 100 ohm resistor in series with the I2C SCK line, which helps suppress spikes. Not all devices are affected, so this workaround is only required if you are having trouble getting a bus response. One device that is known to require this workaround is the HTU21D.
Let’s look at the SPI bus available on this device.
There is one SPI controller SPI0 available on the MBM:
An example on how to perform a SPI write on bus SPI0 is shown below: