A few months ago I started with .NET Gadeteer. .NET Gadgeteer is an open source hard- and software platform from Microsoft that was adapted by many hardware manufacturers. One of the biggest companies that embraced .NET Gadgeteer (if not the biggest) is GHI Electronics. They manufacture boards like the FEZ Spider or FEZ Raptor. These boards are delivered with all the tools you need to develop and prototype your own IoT (Internet of Things) projects like Visual Studio integration, firmware update tools and more. But the best thing about GHI is the community. Thousands of helpful people on the forums who will try to solve your issues. All these boards are running using the .NET Micro Framework, which has been open sourced by Microsoft as well. If you are a C# developer (or VB), you can re-use your existing skills to develop your first IoT prototype, or just play with Gadgeterr, which is lot’s of fun!
Gadgeteer Modules – The Hard and Software Dilemma
Unfortunately the same wording for a piece of hardware and a driver that is used to interact with the hardware are called “Module” in the Gadgeteer world. I am not sure why this was defined this way – but I assume it was because of the close relationship between the hardware and the software. Therefore I am going to use the abbreviations HM for “Hardware Module” and SM for (you guessed it) “Software Module” which represents the driver for the HM.
Here is a sample image showing the available “Builder-Templates” within Visual Studio 2013, showing the term “Module” used with project template that is used to develop a driver:
And here a sample from the Gadgeteer homepage on CodePlex, showing “Module(s)” highlighted within Google Chrome:
That should make it pretty clear why the wording “Module” can be confusing and requires additional explanation.
First Things First – The Shopping List
If you want to rebuild the HM these are the parts you need:
- 3 resistors, each 10 kΩ (10 kilo Ohm’s) (Sparkfun)
- Solder with a low melting temperature and a small diameter (starting from 0.8 mm, best 0.5mm)(Amazon)
- Single sided copper panel prototype PCB board(Amazon)
- Pin Header Strip(Amazon)
- CAT5114 32-Tap Digital Potentiometer (Mouser)
- 1x 3mm led with built-in resistor (Mouser)
- Hook-up Wire(Amazon)
- Two button HM’s from GHI
- To connect your self-made HM to your FEZ Spider board (or any other Gadgeteer compatible board), you can buy an “Extender Module” or a “Breakout Module Set” or a “Breakout TB10 Module” from GHI
- And of course a .NET Gadgeteer board. I would recommend the FEZ Spider, because of it’s small form-factor and the fact, that it is one of the best boards out there.
You might ask why you will need to buy solder that has a low melting point? The answer is simple: Some IC’s (Integrated Circuits) like the CAT5114 can resist a heat of 300 degrees Celsius for about 10 seconds. Many other IC’s only a temperature of 280 degrees Celsius or lower. This means you have to work fast to avoid damage to your chip. I recommend a solder temperature of 250-280 degrees Celsius.
Another possibility to avoid damaging your IC would be to buy IC Socket Adapters . Those allow you to solder them first to the board and then insert your IC. A good solder iron is the base for your future projects and you should not be penny-pinching. Better save some money and buy something really good.
Some of you might ask, why a 32-Tap POT and not a 128 or even a 256-Tap POT? Just because I wanted to start with something simple that does not require SPI, just a plain Up/Down protocol. And because the IC’s are cheaper. The only mistake I made, was to order a 50kΩ version of the CAT5114 which is a lot of resistance for a LED and 3.3 Volts of input voltage. But it’s good enough to demonstrate how to use a POT. And to be honest, I damaged already one during my first soldering session and another one by heating it up for a few minutes by a short circuit (used this one on the board, with about 30kΩ left to play with).
And just for the record – I am not affiliated with any of the above companies.
The Basics – How to Wire Up the CAT5114 Using a Breadboard
To demonstrate how the CAT5114 needs to be connected, I have created a very basic breadboard Fritzing! graphic (a big thank you to the Fritzing! people offering this great services and of course the open source software!). The graphics does not include the three 10kΩ resistors just to make the graphic even simpler.
The graphics is constructed in a way that will help you to understand later, how the CAT5114 is connected to the Gadgeteer-Board. The red, black and green wires (without the 10kΩ resistors) indicate the pins that will later be connected to the GPIO-Pins (General Input/Output Pins) of the Gadgeteer-Board. The yellow wires are connected later to the pin-header strip and offer the same functions an mechanical potentiometer would offer. The red led is just a 3mm led with a built-in resistor and connected in parallel to indicate that the module is powered on. As you can see in the graphics, too – I called the HM “DigiPOT”.
To understand the pin-outs of the CAT5114 it is necessary to read the data-sheet (like with any other component you want to use):
The data-sheet tells you about the pin-outs, the maximum supply-voltage, the maximum ratings for CS,INC,U/D,H,L and RWB and what’s also important, how to make the device work. Here is my summary for you:
- Min. supply voltage: 2.5V
- Max. supply voltage: 6.0V
- Max voltage on pins INC (High State),U/D (High State),CS (High State): VCC (Supply voltage) -0.5 to VCC + 0.5
- Max voltage flowing between RL and RWB,RH and RWB: VCC (Supply voltage) -0.5 to VCC + 0.5
- U/D controls the wiper direction (RWB) up or down determined on the condition. When in a HIGH-State (true) and CS is LOW, the direction is towards the high-terminal (RH). When in a LOW-State (false) and CS is LOW, it moves the wiper (RWB) towards the low-terminal (RL)
- INC moves the wiper based on the condition of the U/D input. The movement is accomplished by sending a sequence of high to low transitions to INC (HIGH (true), LOW (false)). Then the wiper is moved one TAP at a time (32 possible) towards the low-terminal (RL) or the high-terminal (RH). Always depending on the values of U/D and CS
- If CS is set to HIGH (true) activity on U/D and INC will not change the wiper position (it is considered as active LOW (false))
That’s a lot of information to handle, even with a simple IC like the CAT5114. You can find this information on page 3 of the datasheet. The section “Device Operation” describes the way it works in detail (also on page 3 of the datasheet).
With this information, we can set the rules on how to operate the device :
- CS needs to be set to LOW (false) if we want to use U/D and/or INC
- To move towards the high-terminal, we need to set U/D to HIGH (true)
- To move towards the low-terminal, we need to set U/D to LOW (false)
- To actually move the wiper we need to send a HIGH (true), LOW (false) sequence to INC
- We should not connect INC, U/D, CS, RH and RL to a higher voltage than the supply voltage
Comparing the CAT5114 to a Regular Mechanical Potentiometer
One thing that helped me to understand how the CAT5114 operates, was to compare it directly to a mechanical potentiometer. Here is a simple sketch of a mechanical potentiometer to help you compare the pin-outs with something that you might already know about:
To keep it simple, I am wiring the finished module to function as a rheostat (variable resistor). You can read more about potentiometers and how to use them as simple variable resistors here: All About Circuits – Potentiometer as a rheostat.
Pull-Up Resistors
The GPIO-Pins on the Fez-Spider board (Socket Y) are connected to +3.3V when in a HIGH state. When in a LOW state the pin is connected to 0Volts. The input pins on the CAT5114 however are in in three possible states:
- HIGH
- LOW
- FLOATING
Floating is the problem here. The IC’s cannot determine if the input value is HIGH (true) or LOW (false) when nothing is connected. It could be HIGH or LOW for a specific amount of time then LOW again and so forth. To avoid this third (unstable) state, we can use a resistor that is roughly 1/10 of the internal resistance of the IC. This internal resistance is called “Impendence“. Usually 4.7kΩ – 10kΩ resistors are used which implicates that the internal resistance of an input pin is about 100kΩ. Floating could make the CAT5114 jump up or down on it’s own. It would be out of control.
When we set the voltage of the GPIO-Pin to +3.3V no current is flowing from the resistor to ground and that will put the input-pin on the CAT5114 into a high state. On the other hand, if we put the GPIO-Pin to 0.0V the input voltage will flow with a slight voltage drop directly to ground and the input-pin on the CAT5114 will recognize a LOW state.
Final Wiring – the PCB
Showing a final circuit that could be used to produce a PCB, will make it much easier for you to understand, how I wired-up the CAT5114. I used the Fritzing! software to create something like my first PCB:
.Net Gadgeteer based hardware offers a variety of sockets that can be used to connect HM to. This sockets are usually connected to 10 Pin 2×5 2.54MM Box Header IDC male sockets, that are used with 10-pin flat ribbon-cables with female connectors:
The first image was taken from “Vetco Electronics” and the second from “GHI Electronics” on the first one you can see the IDC male-header connector labeled J1 on the PCB circuit-image. The second one shows the connector cable that connects the .NET Gadgeteer board (in my case the FEZ Spider) with the self-made HM or any other commercial HM.
Within the above circuit drawing you can see three resistors of each 10kΩ that are used as pull-up resistors:
- R1 connected to CS and pin 4 on JP1 (GPIO)
- R2 connected to INC and pin 5 on JP1 (GPIO)
- R3 connected to U/D and Pin 6 on JP1 (GPIO)
As you can see, I have put a pin-out graphics on top of JP1 to make it easier for you to determine the pin numbers.
In the upper left corner of the circuit drawing you can see that I have chosen “Socket Type Y” from the .NET Gadgeteer documentation, because this socket type offers 7 different GPIO pins. And one pin (PIN 3) is also pull-up capable (between 10kΩ and 100kΩ). Here the pin-out description:
It offers also a +5V pin, that would allow to operate devices with an input voltage of up to +5V using the CAT5114. My module is using 3.3 volts.
On the right-hand side in the circuit drawing you can see the pin-header strip that offers connections to RL,RH and RWB (the two terminals, low and high and the wiper) of the CAT5114.
TIP: How to read the pins on an IC => “Finding pin 1“.
Let’s move now to the implementation of the SM.
Writing a SM Driver Using Visual Studio 2013
To start writing the SM for the DigiPot HM the following pre-requisites need to be installed:
- Visual Studio 2013 (I recommend to start with the VS2013 community edition)
- Microsoft NET Micro Framework 4.3
- Microsoft .NET Gadgeteer Core
- The GHI NETMF and Gadgeteer Package 2014 R5
Just visit this GHI support site (you have to sign-up to be able download the Gadgeteer Package 2014 R5) and follow the five simple steps on that site to install the basic-prerequisites.
Two additional steps however are required to complete the VS-Environment to develop SM’s:
- Download and Installation of the WiX Installer Toolkit
- Download and installation of the “.NET Gadgeteer Builder Templates” for Visual Studio (direct download link)
The first download installs the WiX Installer Toolkit, that is required by the .NET Gadgeteer builder templates to create an installer for your SM. Just execute the .exe file for WiX and start the installation. The module-builder-templates come packaged within an .msi installer-package that can be executed as well. If you don’t install WiX, VS will present you a build-error that the installers cannot be built.
What You Get After the Setup is Ready
After the module was successfully assembled, it is ready to receive it’s own driver the SM. Restarting Visual Studio 2013 and creating a new project, will give you the following options within
First create a new “.NET Gadgeteer” application. Then choose your board and the Netmf-Version. I chose 4.3 and finish the process. Then right-click your solution and add a new project to your solution. This time a “.Net Gadgeteer Module“. Name it and select your options
Enter your SM name, manufacturer and a manufacturer safe name. Then choose all the NETMF versions you want to be able to run your module driver. I have chosen only NETMF 4.3. Still it generated the NETMF 4.1 and 4.2 projects for me:
Anyway. The assistant will create all the necessary files for you. One of the most important files, the “ReadMe.txt” file can be found within the resource project (the first one, not containing any version within it’s name). You will find all the necessary information in there, on how to use the GadgeteerHarware.xml file. This file is responsible for the rendering of your HW module-mage within the Gadgeteer designer. Here a sample how the designer looks like, using a standard HM from GHI and the Fez Spider Mainboard:
On the far left you can see the Fez Spider mainboard with it’s 14 sockets. On the right hand side you can see three HM: 2 Buttons and one TB10Breakout. This is why you need GadgeteerHardware.xml. Please remember that you will not be able to add your SM using the designer until you have executed the installer to actually install your SM and until you have re-started Visual Studio. You will find parts of this information’s also within the ReadMe.txt file mentioned before.
After a successful build, you will find the setup file generated using WiX within the resources-project bin/Release folder. Execute this file (close Visual Studio first) and restart Visual Studio. I have installed the DigiPOT SM and restarted VS-2013, this is what it looks now, when I edit the Program.gadgeteer (the Gadgeteer designer-file) file:
Ok. Let’s go a step further now and review the source.
The GadgeteerHardware.xml File
The Gadgeteer-Designer needs the GadgeteerHardware.xml file to be able to check the following conditions regarding your custom SM implementation:
- The unique identifier of your SM (which is a UID)
- Manufacturer Information’s
- If your HM supplies power or not
- The version of your HM
- The image that shows your HM
- The width and height of your HM
- And the minimum Gadgeteer software version (the version of the Gadgeteer package that you’ve downloaded from CodePlex)
- A help URL for user support
- The name of your assembly and the NETMF-Version that is required to run your SM
- Which socket and where to place the graphical socket-connector, that is used within the Gadgeteer-Designer
Many of the information’s are filled in automagically for you. Just don’t uncomment what you need and keep it simple. Here is my GadgeteerHardware.xml file:
<?xml version="1.0" encoding="utf-8" ?>
<GadgeteerDefinitions xmlns="http://schemas.microsoft.com/Gadgeteer/2011/Hardware">
<ModuleDefinitions>
<!-- This module definition should be filled in. Mouse over any attribute name to get more help about that attribute. -->
<!-- The Unique ID is auto-generated and does not usually need to be modified. -->
<!-- For file paths, do not use forward slash (/), use backslash (\) or it fails in Windows XP. -->
<ModuleDefinition Name="DigiPOT"
UniqueId="0b8c326d-b644-43d0-bc50-c77075d60f60"
Manufacturer="Awesomedevsigner"
Description="A DigiPOT module"
InstanceName="DigiPOT"
Type="Gadgeteer.Modules.Awesome.DigiPOT"
ModuleSuppliesPower="false"
HardwareVersion="1.0"
Image="Resources\Image.jpg"
BoardHeight="22"
BoardWidth="44"
MinimumGadgeteerCoreVersion="2.42.500"
HelpUrl=""
>
<!-- Assemblies listed here are added to the project as references by the designer whenever this module is instantiated. -->
<!-- This functionality is used to -->
<!-- (1) include the output assemblies of this template -->
<!-- (2) include other custom assemblies that the module relies on (NB you must edit msm.wxs so these are installed too) -->
<!-- (3) indicate a reliance on a Gadgeteer assembly other than Gadgeteer.dll (which is always referenced) -->
<!-- Some examples are provided inline: -->
<Assemblies>
<!-- This lists the assemblies which provides the API to this module, i.e. the output assemblies of this template. ((1) in the list above) -->
<!-- If you do not provide support for all of NETMF 4.1, 4.2 and 4.3, the relevant lines should be removed -->
<!-- NB you should use the same name for the same assembly's NETMF 4.1, NETMF 4.2 and NETMF 4.3 versions, since this will make it easier for users to change framework versions -->
<!-- <Assembly MFVersion="4.1" Name="GTM.Awesome.DigiPOT"/> -->
<!-- <Assembly MFVersion="4.2" Name="GTM.Awesome.DigiPOT"/> -->
<Assembly MFVersion="4.3" Name="GTM.Awesome.DigiPOT"/>
<!-- If your module relies on another assembly, then list it here (and see the msm.wxs file since you need to include it in the installer too), e.g.: -->
<!--
<Assembly MFVersion="4.1" Name="Awesome.CustomAssembly"/>
<Assembly MFVersion="4.2" Name="Awesome.CustomAssembly"/>
<Assembly MFVersion="4.3" Name="Awesome.CustomAssembly"/>
-->
<!-- If your module either relies upon or is often used with a .NET Gadgeteer assembly other than Gadgeteer.dll, then list it here -->
<!-- so that the designer automatically includes it when your module is included - e.g. by uncommenting the lines below -->
<!-- These .NET Gadgeteer assemblies were separated out for NETMF 4.2, so don't need to be listed for NETMF 4.1 as separate -->
<!-- Uncomment any of the below that you require for this module. -->
<!--
<Assembly MFVersion="4.2" Name="Gadgeteer.SPI" />
<Assembly MFVersion="4.2" Name="Gadgeteer.Serial" />
<Assembly MFVersion="4.2" Name="Gadgeteer.DaisyLink" />
<Assembly MFVersion="4.3" Name="Gadgeteer.SPI" />
<Assembly MFVersion="4.3" Name="Gadgeteer.Serial" />
<Assembly MFVersion="4.3" Name="Gadgeteer.DaisyLink" />
-->
<!-- If this is a networking module, then uncomment all four lines below to include Gadgeteer's web client/web server libraries -->
<!--
<Assembly MFVersion="4.1" Name="Gadgeteer.WebClient" />
<Assembly MFVersion="4.1" Name="Gadgeteer.WebServer" />
<Assembly MFVersion="4.2" Name="Gadgeteer.WebClient" />
<Assembly MFVersion="4.2" Name="Gadgeteer.WebServer" />
<Assembly MFVersion="4.3" Name="Gadgeteer.WebClient" />
<Assembly MFVersion="4.3" Name="Gadgeteer.WebServer" />
-->
</Assemblies>
<!--
This is an example socket specification with two sockets on the board.
The socket positions are specified in mm from the top left corner of the board, with the orientation 90 indicating the socket notches are pointing upwards (0=right, 180=left, 270=down)
-->
<Sockets>
<!-- This example socket is compatible with socket types XY which has electrical connections to pins 3 and 4 -->
<Socket Left="10" Top="10" Orientation="90" ConstructorOrder="1" TypesLabel="XY">
<Types>
<Type>Y</Type>
</Types>
<Pins>
<Pin Shared="false">4</Pin>
<Pin Shared="false">5</Pin>
<Pin Shared="false">6</Pin>
</Pins>
</Socket>
<!-- This example socket is compatible with socket type S, it is optional, and it has electrical connections to pins 3,4,5,7,8,9, with 7,8,9 being shareable (SPI bus) -->
<!--<Socket Left="30" Top="10" Orientation="90" ConstructorOrder="2" TypesLabel="S" Optional="true">
<Types>
<Type>S</Type>
</Types>
<Pins>
<Pin Shared="false">3</Pin>
<Pin Shared="false">4</Pin>
<Pin Shared="false">5</Pin>
<Pin Shared="true">7</Pin>
<Pin Shared="true">8</Pin>
<Pin Shared="true">9</Pin>
</Pins>
</Socket>-->
</Sockets>
<!-- Use the ExtraLibrariesRequired element if this module requires specific firmware libraries to be provided by the mainboard, and so is limited to a subset of mainboards. -->
<!--
<ExtraLibrariesRequired>
<Assembly MFVersion="4.1" Name="FooHelper" ErrorMessage="This module only works with the MainboardName1 or MainboardName2 mainboards." />
<Assembly MFVersion="4.2" Name="FooHelper" ErrorMessage="This module only works with the MainboardName1 or MainboardName2 mainboards." />
<Assembly MFVersion="4.3" Name="FooHelper" ErrorMessage="This module only works with the MainboardName1 or MainboardName2 mainboards." />
</ExtraLibrariesRequired>
-->
<!-- Also use the ExtraLibrariesRequired element if this module represents built-in functionality in a mainboard, listing the mainboard's driver as the required assembly. -->
<!--
<ExtraLibrariesRequired>
<Assembly MFVersion="4.1" Name="Awesome.Gadgeteer.MainboardName" ErrorMessage="This module is built-in to the MainboardName mainboard, so cannot be used with any other mainboard." />
<Assembly MFVersion="4.2" Name="Awesome.Gadgeteer.MainboardName" ErrorMessage="This module is built-in to the MainboardName mainboard, so cannot be used with any other mainboard." />
<Assembly MFVersion="4.3" Name="Awesome.Gadgeteer.MainboardName" ErrorMessage="This module is built-in to the MainboardName mainboard, so cannot be used with any other mainboard." />
</ExtraLibrariesRequired>
-->
<!-- Use the ProvidedSocket tag if this module provides a socket that another module can plug into -->
<!-- The example below is for DaisyLink modules which provide a socket type "*" -->
<!--
<ProvidedSockets>
<ProvidedSocket Label="*" Left="30" Top="10" Orientation="0" ConstructorParameter="DaisyLinkSocketNumber">
<Types>
<Type>*</Type>
</Types>
</ProvidedSocket>
</ProvidedSockets>
-->
<!-- Uncomment to specify power consumption data for use by the VS designer. -->
<!-- Do not partially fill this in - either fill it all in or leave it out totally. -->
<!-- Values are in Volts or Amps respectively. Use the special value Infinity, e.g. if the maximum current is unknown (such as for a motor). -->
<!--
<Power>
<PowerRequirements Voltage="3.3">
<TypicalCurrent>0.123</TypicalCurrent>
<MaximumCurrent>0.456</MaximumCurrent>
</PowerRequirements>
<PowerRequirements Voltage="5.0">
<TypicalCurrent>0.789</TypicalCurrent>
<MaximumCurrent>Infinity</MaximumCurrent>
</PowerRequirements>
</Power>
-->
</ModuleDefinition>
</ModuleDefinitions>
</GadgeteerDefinitions>
Like I said – keep it simple. You can replace the image by right-clicking the resource-project and selecting “Open Folder in File Explorer“. This will show you all the files contained within the resource-project, including the Gadgeteer-Designer image.
The Socket-Tag within the GadgeteerHardware.xml file contains the attributes:
- Left
- Top
- Orientation
You can use this attributes to define the position of the Gadgeteer connector on your image. Top and left are pixel values, simple integers. For example, if you want the connector to appear 10 pixels from the top, you just replace the value of the “Top” attribute with a 10.
Orientation is also an integer value representing the rotation of the connector in degrees. I rotated the connector 90 degrees clockwise as you can see in my GadgeteerHarware.xml file.
The Implementation of the SM – The Actual Driver for the HM
Every SM that you want to use as a driver (it is the driver for your custom HM, nothing else) needs to implement the abstract class “Module“. This class can be found within the Gadgeteer.dll assembly file. This class is quite big. To explore it, just hit F12 within Visual Studio from within your SM, placing the cursor on the class-name itself (Module). This is how I implemented the SM for my DigiPOT:
using System;
using Microsoft.SPOT;
using GTI = Gadgeteer.SocketInterfaces;
using GTM = Gadgeteer.Modules;
namespace Gadgeteer.Modules.Awesome
{
public class DigiPOT:GTM.Module
{
private GTI.DigitalOutput _cableSelect;
private GTI.DigitalOutput _upDown;
private GTI.DigitalOutput _increment;
private WiperDirection _currentWiperDirection;
public WiperDirection CurrentWiperDirection
{
get { return _currentWiperDirection; }
}
public DigiPOT(int socketNumber)
{
Socket socket = Socket.GetSocket(socketNumber,true,this,null);
socket.EnsureTypeIsSupported('Y',this);
_upDown = GTI.DigitalOutputFactory.Create(socket,Socket.Pin.Six,false,this);
_increment = GTI.DigitalOutputFactory.Create(socket,Socket.Pin.Five,false,this);
_cableSelect = GTI.DigitalOutputFactory.Create(socket,Socket.Pin.Four,false,this);
}
public void PrepareWiperMovementHigh()
{
_cableSelect.Write(false);
_upDown.Write(true);
_currentWiperDirection = WiperDirection.TowardsHighTerminal;
}
public void PrepareWiperMovementLow()
{
_cableSelect.Write(false);
_upDown.Write(false);
_currentWiperDirection = WiperDirection.TowardsLowTerminal;
}
public void MoveWiper()
{
_increment.Write(true);
_increment.Write(false);
}
}
public enum WiperDirection
{
TowardsHighTerminal,
TowardsLowTerminal
}
}
Not much code for a hardware-driver! The .NETMF-Team did a great job in terms of tooling and architecture. Thanks for that!
The code should be easy to understand and should reflect the custom HW as well. The following private fields represent the three input-pins of the CAT5114:
- _cableSelect: CS
- _upDown: U/D
- _increment: INC
All three fields are type of DigitalOutput. This class can be found within the Gadgeteer.SocketInterfaces namespace. Latter can be found within the Gadgeteer.dll assembly-file. From within the constructor you have to set the Gadgeteer socket number and you have to create first a Gadgeteer-Socket by calling Socket.GetSocket. The constructor is used by the Gadgeteer-Designer as well, to initialize a static instance of your SM. The parameters passed to this method are:
- The socket number (passed by the designer, or by yourself, if you use your SM without the designer)
- Should be an exception thrown, if the socket number is invalid, for example, there is no socket number 22 on the Fez Spider. This should be set to true, just to be sure
- The module the socket belongs to, in this case “this”
- And the label. Don’t need it, set to null
The next line ensures, that the board supports sockets of type “Y“, which is needed by the HM. The second parameter of the EnsureTypeIsSupported assigns the module the socket belongs to.
On the following three lines I initialize the GPIO-Pins. Each single pin is initialized separately, using the DigitalOutputFactory-Method, Create:
- Every single pin is assigned to the chosen socket number (this is the first parameter)
- The second parameter represents the pin itself, by choosing the pin-number using the Socket.Pin enum
- The third parameter (for all three pins: false) indicates that all pins have an initial LOW state
- The fourth and last parameter assigns again the SW, the pins belong to
Nothing too fancy so far.
There is one public property called “CurrentWiperDirection” that can be used to check, to which terminal the wiper is currently moving (RH or RL). The CAT5114 is not capable of reporting the current wiper position (TAP position) because of the simple UP/DOWN protocol implementation. Therefore I wanted at least to know, into which direction the wiper is moving.
There are three public methods defined:
- PrepareWiperMovementHigh => called if the wiper needs to be moved towards the high-terminal
- PrepareWiperMovementLow => called if the wiper needs to be moved towards the low-terminal
- MoveWiper => Executes the HIGH to LOW transition on the INC input of the CAT5114
If you take a look at this methods, you will see, that they are implemented exactly the same way like the device needs to be operated.
Putting it all together
Now that the HM and SM are ready, they can be used within a Gadgeteer application. The installation of the SM module was already successful, so that I can use the two buttons to move the wiper between the low (RL) and the high (RH) terminal of the CAT5114:
using System;
using System.Collections;
using System.Threading;
using Microsoft.SPOT;
using Microsoft.SPOT.Presentation;
using Microsoft.SPOT.Presentation.Controls;
using Microsoft.SPOT.Presentation.Media;
using Microsoft.SPOT.Presentation.Shapes;
using Microsoft.SPOT.Touch;
using Gadgeteer.Networking;
using GT = Gadgeteer;
using GTM = Gadgeteer.Modules;
using Gadgeteer.Modules.GHIElectronics;
using System.IO.Ports;
using Gadgeteer.Modules.Awesome;
namespace HelloWorld
{
public partial class Program
{
private static SerialPort UART;
byte[] rx_byte;
// This method is run when the mainboard is powered up or reset.
void ProgramStarted()
{
button2.ButtonPressed += button2_ButtonPressed;
button.ButtonPressed += button_ButtonPressed;
//Prepare UART COM
UART = new SerialPort(breakoutTB10.Socket.SerialPortName, 115200, Parity.None);
UART.Open();
UART.DataReceived += UART_DataReceived;
// Use Debug.Print to show messages in Visual Studio's "Output" window during debugging.
Debug.Print("Program Started");
}
void UART_DataReceived(object sender, SerialDataReceivedEventArgs e)
{
rx_byte = new byte[UART.BytesToRead];
UART.Read(rx_byte, 0, UART.BytesToRead);
if (rx_byte.Length > 0)
{
var data = new string(System.Text.Encoding.UTF8.GetChars(rx_byte));
if (data == "l\r\n")
{
WiperLow();
}
else
if (data == "h\r\n")
{
WiperHigh();
}
Debug.Print(data);
}
}
void button_ButtonPressed(Button sender, Button.ButtonState state)
{
WiperLow();
}
private void WiperLow()
{
digiPOT.PrepareWiperMovementLow();
digiPOT.MoveWiper();
}
void button2_ButtonPressed(Button sender, Button.ButtonState state)
{
WiperHigh();
}
private void WiperHigh()
{
digiPOT.PrepareWiperMovementHigh();
digiPOT.MoveWiper();
}
}
}
The two connected buttons both have an event “ButtonPressed”. Button2 moves the wiper towards the high terminal (RH) and button moves the wiper towards the low terminal (RL) of the CAT5114. Both call the corresponding methods digiPOT.PrepareWiperMovementHigh() or digiPOTWiperMovementLow(). Berfore this is done, the digiPOT.PrepareWiperMovementLow() or digiPOT.PrepareWiperMovementHigh() methods are called to set the direction. That’s it!
References
Useful Links
- Sparkfun-Learning
- .NET Gadgeteer Homepage on CodePlex
- NETMF source on GitHub
- GHI Community (Forum, Codeshare, Creations, Showcase)
- Duke Nukem’s YouTube Channel (All about .NET Gadgeteer)
- embedded101 (Paolo Partierno’s IoT and embedded blog)
- Pete Brown’s Blog
- Mike Dorado’s Blog
- R. Ian Lee, Sr. Blog