Tutorial : writing a driver

How to write a MBN compliant driver for a module
Coding drivers for MBN is (almost) as easy as coding NETMF applications !

Since there are some constraints with pins mappings and different checks involved, you should start with one of the two drivers templates, depending on which kind of communication it’s using (I²C or any other).

In the following example, we will use the Bargraph Click board, which is by default a SPI board. Coding for an I²C driver is absolutely identical except for the template, which will of course be the I2C template.

Open Visual Studio and create a new Micro Framework -> MikroBus.Net -> “MBN SPI driver” :

ScreenShot753

At this point, you can see that the template has generated two source files : Driver.cs and DriverEvents.cs. If you don’t need to generate events in your driver, then you may safely delete the DriverEvents.cs file and remove the reference to the event at the beginning of Driver.cs.

Select the Driver.cs file. The code should look like this :

As you can see, the template also comes with XML comments ready. This will be useful for users as VS auto-completion will use this information. At the beginning of the class, we declare the DemoEventFired event that will be raised in the MethodWithEvent() method. If you don’t need events, you can delete this line and the code in the method.

In our example, since we won’t be using events, we will delete the related code and the SPIDriverEvents.cs file. Also, it’s now a good time to rename the SPIDriver.cs file to something more adapted to your driver. Here, we will call it BargraphClick.cs. This is not mandatory, of course, but using a generic name is not really useful.

Back to the driver itself…

You will notice that your driver needs to implement the IDriver interface. This interface is part of the MBN core and tells that the driver will expose some common methods and properties. The IDriver interface exposes the Reset() and PowerMode() methods as well as the DriverVersion property. Users can then check for the driver’s version to enable more advanced features, for example.

In the class constructor, the Hardware.CheckPins() method is used to see if there’s another driver that may already use the same pins as the Bargraph Click board. So it is very important to put the correct pins used, here.

The Bargraph Click board is using SPI pins by default, PWM pin to control brightness and the RST pin, so we have to modify the line accordingly :

Also, since it’s using PWM, we have to declare some (private) variables : PWM needs that a reference to Microsoft.SPOT.Hardware.PWM be added to the project. The PWMLevel variable will hold the current PWM value as we will use a property to get/set the leds brightness.

Just to show that the default constructor call can be modified, we will add a parameter for the initial brightness of the leds when the object is created (leds will have full brightness in the example). Now, let’s change the constructor to initialize SPI and PWMLevel as well :

The CS pin and the SPI module are attached to the socket passed to the constructor, so you don’t need to know the exact pin number/name on the chip and simply add “Socket.Cs” (for the CS pin).

So far, we have created the driver’s constructor, which is fine, but useless without some properties/methods to control the bargraph leds ! Let’s then add a property to control brightness :

 

Now, the method to light on/off some leds :

The parameter NbBars is the number of bar to light on. Fill will indicate if the preceding leds will also be lit or not.  

Here you are ! The driver for the Bargraph Click board is done ! At least for basic features. You can download the complete source code of this driver on the Download page of this site.

Final note :

At this point, you may want to add more methods or properties, so that you have a very complete driver. Although this is understandable, be aware that this is a driver, and as such it’s not meant to contain a full application ! Temptation is huge to code an application in a driver, but think at users that don’t need the ExtraFeature(Boolean MyNice Param) ; method. It will consume memory while being useless in most cases. So, our advice would be to keep the driver as small as possible and to allow users to access the internals of the chip if needed. This can be done for example by making public the methods used to access internal registers. Or you can create a separate assembly that contains advanced features, based on the basic driver.