Embedded Programming – Getting Started With the Netduino - Part 2

In my previous post, I covered the basics of getting started with the Netduino development platform. The post covered getting the environment setup and our first program was created, blinking the on board LED. All of the code in the first example was inserted into the Main method. In this second part, the code is refactored to leverage some object oriented features in C# and improve readability.

Although all the code in the first example was in the Main method, there were two distinct tasks that were being accomplished. The first was to setup the environment; the second was to perform the task we wanted to accomplish (blinking the LED). Therefore, we will add two methods to isolate the code for these two tasks. If you have worked with the Arduino, you are already familiar with this concept. Arduino programs are called sketches and they contain two methods, setup and loop. The modifications are nothing drastic, all the code is the same as in our original program but we have moved lines to their respective methods. Figure 1 contains the modified code.

1. Line 13 is a static field declared to store the OutputPort object that controls the power to the LED. Since two methods are created, the LED variable needs to be accessible from both methods. Therefore, a class level variable is created that is accessible to both methods. The variable is static because everything is run from the static context of Main method.
2. Lines 15 to 17 contain the Main method. The Main method contains calls to the Setup and Loop methods.
3. Lines 20 and 21 contain the declaration to the Setup method. The Setup method is where all the code related to initializing the environment is placed. In this case, an output port is initialized to the on board LED pin and the initial state is false (or off).
4. Lines 24 to 29 contain the declaration to the Loop method. The code that turns the LED on and off has been moved to this method.

Since C# is an object oriented language, classes can be created to represent the real world objects being worked with. For the LED example, we will create two classes. One will be an abstract base class to represent an LED. The other will be our particular implementation for the LED. Figure 2 is the code listing for an abstract representation of an LED.

1. Line 8 is the declaration of the abstract class that will act as the base class for the LED implementations.
2. Lines 11 and 12 include two protected fields. The pin variable will store what Cpu.Pin or port the LED will be connected to. The isOn variable will store a Boolean value for the current state of the LED.
3. Lines 15 and 16 have two properties to get the values of the fields. In this case, no set methods have been created as the fields will be set through other means.
4. Lines 19 and 20 declare the abstract methods that will do the work for turning the LED on or off.

Now that an abstract class has been created, the implementation can be written. Our first implementation will allow for a simple on or off state of the LED; therefore, we can call this first implantation LedBinary. Figure 3 is the code listing for the Ledbinary.

1. Line 5 is the declaration of the class which extends from the Led abstract class.
2. Line 7, a private read only field, is declared for the OutputPort which is the Microsoft.Spot.Hardware namespace. The output port is the class that controls the pin to power the LED and can be abstracted away from the Program class.
3. Lines 14 to 16 is our initial constructor which requires the Pin to which the LED is connected and the initial on or off state of the LED.
4. Line 23 is a convenience constructor which requires the Pin to which the LED is connected and sets the initial state of the LED to off. Constructor chaining (overloading) can be used and the parameters can be passed to the initial constructor on line 14 to do the work.
5. Line28 is another convenience constructor that will initialize the onboard LED. Again, chaining is used to pass the required parameters to the initial constructor on line 14. It is important to note that by creating this constructor, we are binding this class to the Netduino Plus since a reference has been added to use the enumeration that provides the keyword to the onboard LED.
6. Lines 30 and 31 contain the code for the SetOn method. The method contains a simple if statement that checks to see if the LED is already on, if not, true is written to the port to apply power and the isOn state of the LED is set to true.
7. Lines 34 and 35 contain the code for the SetOff method. The method contains a simple if statement that checks if the LED is on, if so, false is written to the port to remove power and the isOn state of the LED is set to false.

Now that the LED classes have been created, the Program file can be modified to use the new classes. As can be seen in figure 4, there has not been any reduction in the number of lines of code to complete the work (technically, the total line have increased if you take into account the created classes), but the code could arguably be considered more readable.

1. Line 13 contains a private static field for the Led class.
2. Lines 15 to 17 contain the main method that calls the Setup and Loop methods.
3. Lines 20 and 21 contain the declaration for the Setup method which instantiates a new LedBinary for the Led class to be used in the program. Since LedBinary is a subclass of Led, no casting is required and we don’t need to have our field as a LedBinary since all the methods we need to access are in the Led class.
4. Lines 24 to 29 contain the declaration for the Loop method that turns the LED on and off. In this case, we no longer have to provide a Boolean value in the method and simply call the SetOn and SetOff methods in the Led class.

There is a price to be paid for the redesigning of the code, not necessarily by adding our Setup and Loop methods, but creating classes adds some overhead to our deployment package size. Figure 5 shows the deployment size for version 1 of the code that contained all the work in the main method. The deployment size totaled 1204 bytes. Figure 6 shows the deployment size for version 2 of the code that separated the work out into the Setup and Loop methods. The deployment size for version 2 was the same as version 1 at 1204 bytes. Figure 7 shows the deployment size for version 3 of the code that added the LED classes. The deployment size for version 3 is 2156 bytes and almost adds an additional 1000 bytes over version 1 and 2 due to the additional code for the LED classes (technically, I have a third LED class in there for Pulse Width Modulation which will be discussed in the next post).

The changes made to the code don’t add any additional functionality; however, the modifications made can add improved readability and with the additional classes for the LEDs, we have added some code that can be leveraged in other projects. The price paid for the benefits is a slight increase in the codebase deployment size, but this is not significant as there is a total of 128 kb of code storage available on the Netduino.

CodeProject