Sunday, October 11, 2015

Parallax Smart Card Reader - Revisited

I believe I have mentioned that at some time, I was going to implement an Arduino Library for the Parallax Smart Card Reader.   Well, that time is now.

The library has support for the 3 smart cards that are also available from Parallax.   The samples are equivalent to the stand-alone samples that have been available for quite some time now.   The big difference is that using the 3 smart cards is now very similar.   You initialize the cards with an Initialize() function, you read and write data to the cards with Read() and Write() functions.   There is an Authenticate() function available for the IS23SC4442 card.   The parameters are similar for each card (but they aren't always identical ... the IS24SC16A card requires a Page parameter, where the IS24SC02A doesn't, for example).   Update:  This library now has 3 additional functions for each card:  WriteString(), ReadString() and ClearString() ... basically you can write a string at a location on a page of the memory (note, it does NOT attempt to write past page boundaries ... very important for the IS24SC16A card!) ... so for a single page card, you could write a string starting at a specific location...WriteString(0x50, "Test");  Then if you needed to, at some time, you could read data into a string buffer ... ReadString(0x50, 4, buffer);  // buffer needs to be 1 byte larger than required in order to handle NULL terminator ... so a definition of char buffer[5]; would be fine in the previous example.  Finally if you need to clear the string you would simply call ClearString(0x50, 4); to set the 4 non-null memory locations to NULL (or 0x00).  The IS24SC16A version of the functions do have a Page # as the first parameter.  The location parameter is zero-based ... so if you wanted to clear all memory in a single-page card or all memory of a page in the IS24SC16A card, you could call ClearString(0x00, 256); ... or ClearString(5, 0x00, 256); to clear page 5 of the IS24SC16A card.  Each of the card samples have a new function showing samples of using the new String functions. Remember a page is 256 bytes in size, regardless of the card type.  So the maximum string size is going to be 256 bytes ... if you have a string that takes up an entire page, the buffer size would still need to be 257 to allow for the null terminator returned from the ReadString() functions.

Note:  Initially there wasn't an addressable Read() function for the IS23SC4442 card (i.e. the ability to pass a location to read from).  Even though the Card doesn't seem to directly support it, I worked out a way to make it possible to support it from the Library.

Also Note:  The Constructor for each Card actually accepts 5 parameters ... those parameters are int IOPin, int CLKPin, int CDPin, int RSTPin, int Delay ... but they all default to int IOPin = A4, int CLKPin = A5, int CDPin = 3, int RSTPin = 2, int Delay = 50  ... so you don't have to specify the parameters unless you want to change the values (and the samples don't use the parameters) ... but if you wanted to, you could do something like:   IS24SC02A CardReader(A4, A5, 3, 2, 50);  which would just be the defaults, but can be changed as-needed.   Also, if you are familiar with how default parameter values work, you know that you really don't have to always specify all parameters, but I'm not going to take the time to explain that here.

Final Note: The IS23SC4442 card can be locked if authentication fails, however the IS23SC4442.cpp Authenticate() function is coded to help make sure that doesn't happen (but also means that it doesn't really have the full protection that it could have).   I have put comments in the code showing what was there (when I locked a card!!!!), and you are welcome to change it back to provide full security support.   BUT, if you do, be very careful.  When you lock a card, it can't be unlocked and is no longer usable!!!

Please see the original post about the Parallax Smart Card Reader, because a lot of it is still very relevant.

The Parallax Smart Card Reader Library is now downloadable directly from the Arduino Library Manager.   Simply search for Parallax.

--- or ---

You can find the Parallax Smart Card Reader Library on Github Here.

NOTE: If you are using an older version of the Arduino IDE that does not include the more recent Arduino Library Manager, you may need to move all of the files in the libraries\SmartCardReader\src directory to the root libraries\SmartCardReader directory.   Also, the .properties file may need to be deleted.   Neither of these actions will change the ability to use the library (or samples) and should work fine after doing so.   At the time that I updated the libraries for Library Manager support, I was using version 1.6.9 of the Arduino IDE.


Updates:

10-11-2015 - First release of Library available on GitHub.

10-11-2015 - Added Addressable Read Support to IS23SC4442 Card.    Checked into GitHub.

10-12-2015- A couple minor changes (just some cleanup).  Checked into GitHub.

10-12-2015 - Improved consistency of examples (again, just some cleanup).  Checked into Github.

10-15-2015 - Fix a potentional issue with the IS23SC4442 card when swapping multiple cards in and out of the Card Reader.  Checked into Github.

10-15-2015 - Added String Functions to Library.  Checked into Github.

05-23-2016 - Now available from the Arduino Library Manager (changes required are also checked into Github).

Wednesday, March 18, 2015

1Sheeld Libraries for Netduino, revisited.

NOTE:  See the original post here for additional information (including version updates).

I have updated the 1Sheeld Libraries and Samples for Netduinos.   Things have changed a bit and those of you creating your own sketches will need to modify your code a bit if you decide to use the latest version (but, frankly, things have gotten a lot simpler and I recommend that you upgrade and take a couple minutes to update your sketches ... for no other reason than the older libraries will no longer be upgraded).

I'm going to give you a look at a simple sketch, both before and after the updates, so you can see the differences ... I'll use the SimpleLED sample for this discussion.

First a look at the before code...  Note: I've removed the using statements to simplify things (nothing has changed regardless of whether you use the old libraries or the new libraries with the using statements).

Here's the Program.cs  ... it just instantiates an Led class and calls Setup(), then Loop() endlessly.

 namespace SimpleLED  
 {  
   public class Program  
   {  
     public static void Main()  
     {  
       // write your code here  
       Led led = new Led();  
       led.Setup();  
       while (true)  
         led.Loop();  
     }  
   }  
 }  

Here's the Led.cs ... equivalent to the Arduino Blink sample.

 namespace SimpleLED  
 {  
   public class Led  
   {  
     OneSheeld sheeld = null;  
     public void Setup()  
     {  
       sheeld = new OneSheeld();  
       sheeld.begin();  
     }  
     public void Loop()  
     {  
       OneSheeld.LED.setHigh();  
       Thread.Sleep(1000);  
       OneSheeld.LED.setLow();  
       Thread.Sleep(1000);  
     }  
   }  
 }  

And here's a look at the after code (using the new way) ...

Here is Program.cs ... it still instantiates the Led(), but it is now using the Run function from the OneSheeldUser class included in the new OneSheeld library,   Note ... if I included a using OneSheeldClasses;  in Program.cs it could be called like this ... OneSheeldUser.Run(new Led());  ... just saying.   Also, if you really want to ... you can use the old way (i.e. the old Program.cs would work just fine).

 namespace SimpleLED  
 {  
   public class Program  
   {  
     public static void Main()  
     {  
       OneSheeldClasses.OneSheeldUser.Run(new Led());  
     }  
   }  
 }  

and here's the new Led.cs ...

 namespace SimpleLED  
 {  
   public class Led : OneSheeldUser, IOneSheeldSketch  
   {  
     public void Setup()  
     {  
       OneSheeld.begin();  
     }  
     public void Loop()  
     {  
       LED.setHigh();  
       Thread.Sleep(1000);  
       LED.setLow();  
       Thread.Sleep(1000);  
     }  
   }  
 }  

As you should notice, there is no instantiation of the OneSheeld class like before (and if you have one in your code ... REMOVE IT!!!!) ... and you don't have to reference the OneSheeld class to get to the Shield classes.    This makes Netduino sketches look very similar to the Arduino counterparts.

Now let's look at how things are working now.

If you will notice, the Led class is now derived from the REQUIRED OneSheeldUser class ... what this does is simplify things for us ...

For example:   When the OneSheeld.begin() function is called ... this is now where the OneSheeld class gets instantiated.

If you look at the OneSheeldUser class you will see the following code (towards the end of the class) ...

     public OneSheeldClass _OneSheeld = null;  
     public OneSheeldClass OneSheeld  
     {  
       get  
       {  
         if (_OneSheeld == null)  
         {  
           _OneSheeld = new OneSheeldClass();  
           OneSheeldMain.Init(_OneSheeld);  
         }  
         return _OneSheeld;  
       }  
       set { }  
     }  

What happens is this .... when OneSheeld (of the OneSheeld.begin()) is called, it is actually using the getter above ... and if _OneSheeld (with the underline to make it unique) is null, it will instantiate the OneSheeldClass for you. and return it.   Then when the .begin() part is called, the OneSheeld is actually pointing to an object that was just instantiated.   From this point on, every call reference to OneSheeld, will use that same Object (since _OneSheeld is not null, it will not be re-instantiated).   That really simplifies things for our sketches, we no longer have to instantiate the OneSheeld class ourselves.

The other thing that the OneSheeldUser class does for us is simplifies using Shields. For example the call to LED.setHigh() will actually start here ... again, you don't have to reference OneSheeld before referencing the Shield (in fact, it will throw an error now when compiled if you do), LED isn't actually part of the OneSheeld class anymore).

     public static LedShield LED  
     {  
       get { return OneSheeldMain._LED; }  
       set { }  
     }  

It will reference the previously created OneSheeldMain class (which is the base class of the OneSheeldClass) and passes back the _LED object (which is the live Shield object) ... but how did the _LED object get created???? ... well ... if you look back at the OneSheeld getter ... there's a call in there to OneSheeldMain.Init(_OneSheeld) ... the init function not only stores access to the _OneSheeld object for other OneSheeld classes to use, but also instantiates ALL of the Shields with a call to the IncludedShieldsDefines.cs InitShields() function ...

     public static void Init(OneSheeldClass onesheeld)  
     {  
       OneSheeld = onesheeld;  

       OneShieldMain.InitShields();
     }  

...which then creates the shield objects so we can use them (All Shields can be used similarly to the LED calls without having to reference OneSheeld first).   Our OneSheeldUser class is taking care of that behind the scenes for us.   Note:  There are #defines at the top of the IncludedShieldsDefines.cs module that allow you to specify one or more shields are not to be created (saving memory, if needed).  The #if/#end if around the shield creation (in the below sample, the _LED = new LedShield(); is an example of how that works).   If the #define LED_SHIELD was commented out, the _LED object wouldn't get created (and would remain null) ... in addition, future use of the _LED (through the LED getter, for example) would cause an error in your sketch.   Just make sure any shields that you use are being created (by making sure the #define isn't commented out).   To comment out the line, so a shield doesn't get created simply put two / in front of the #define for the shield #define ... for example // #define LED_SHIELD  would guarantee that the _LED object does not get created (and should not be used by your sketch).   To make sure it does get created, make sure the // is not in front of the #define for whatever shields you are using.   The OneSheeld library WILL need to be rebuilt for the change to take effect (so, if you do add or remove the // to or from one or more #defines, make absolutely sure you rebuild the OneSheeld library).

     static void InitShields()  
     {  
        .  
        .  
        .  
       #if LED_SHIELD  
         _LED = new LedShield();  
       #endif  
       .  
       .  
       .  
     }  

If you don't understand some of this ... that's OK ... you really don't have to ... all you need to remember to do is derive your classes (specifically the ones that call OneSheeld.begin()) from the OneSheeldUser class!!!!) ... and you may need to know how to comment out (or uncomment a #define) and rebuild the OneSheeld library, but that's really it.

You have probably already noticed that the Led class (and all of the Library Sample classes that use OneSheeld.begin() are also derived from the IOneSheeldSketch interface.   This is why we don't have to call the Setup() and Loop() ourselves ...

In the Program.cs module, where we called the OneSheeldUser.Run() function ... that Run() function is calling Setup() and Loop() endlessly for us.   See....

     public static void Run(IOneSheeldSketch sketch)  
     {  
       sketch.Setup();  
       while (true)  
         sketch.Loop();  
     }  

The Run function expects an IOneSheeldSketch object as a parameter ... the IOneSheeldSketch interface just indicates that any class that derives from it must include a Setup() and Loop() function.

   public interface IOneSheeldSketch  
   {  
     void Setup();  
     void Loop();  
   }  

Hint:  If you do use the IOneSheeldSketch interface, after you derive your class from it ... right click on it and select the implement interface option and it will create the Setup() and Loop() functions for you ... which, by default will look like this ...

     public void Setup()  
     {  
       throw new NotImplementedException();  
     }  
     public void Loop()  
     {  
       throw new NotImplementedException();  
     }  

 ... you just delete the throw new NotImplementedException(); from the functions and start coding ... of course you can just create your own public void Setup() {} and public void Loop() {} without using the implement interface option.  Just remember to capitalize both of the function names.

From this point on, all future shield additions will include support for the OneSheeldUser class and IOneSheeldSketch interface.

Updates

03-18-2015 - Another small update was put on Github ... after I wrote the above post ... this update allows for JsonKeyChains to be specified in the same fashion that the Arduino allows (i.e. response["weather"][0]["main"].query(); ... taken from the Advanced Internet Sample).

03-20-2015 - Cleaned up the post (should make more sense now) ... sorry was in a hurry when I wrote it.

03-20-2015 - Added support similar to Arduinos IncludedShieldsDefines.h file.   The file that allows #defines to be commented out for Netduino is OneSheeldMain.cs.   Updates have been checked in to Github.

03-20-2015 - Decided it would be nice to have an IncludedShieldsDefines.cs file for as much similarity to the Arduino Libraries as-possible.  So, I have made the OneSheeldMain.cs partial and made an IncludedShieldsDefines.cs (which is just another part of the OneSheeldMain class but allows the #defines (and where they are used) to be broken out from other parts of the OneSheeldMain.cs module).   Updates have been checked into Github.   You should now be able to easily cut down on the memory footprint of your sketches that use the 1Sheeld library on Netduino by commenting out unused shields in the IncludedShieldsDefines.cs module (and rebuilding the Library and sketch).  Note: This doesn't change the size of the Library, it just changes what Shields get created for Sketches to use.

Monday, March 2, 2015

1Sheeld on a Raspberry Pi using Alamode (or not)

The previous post was about using the Arduino IDE to build and run sketches for a 1Sheeld shield with the 1Sheeld plugged directly into a pcDuino.

This post describes the changes necessary to do similar ... but in this case the 1Sheeld is sitting on an AlaMode (Arduino compatible board) which, in-turn is sitting on a Raspberry Pi.   I have a Raspberry Pi 2 B ... but this should work on any version of the Raspberry Pi that the AlaMode is compatible with.   NOTE: Further investigation shows that these changes are necessary whether you use an Alamode or you simply have an Arduino plugged in to a USB Port.

First off, changes necessary are similar to pcDuino ... so, I'll go through each file that needs to be changed.   NOTE: I'm going to start with the base OneSheeld Arduino libraries, the changes made for pcDuino are NOT included.

Make sure you have the Arduino IDE and Alamode working on the Raspberry Pi before attempting this.  NOTE: Again, this is required even for Arduinos plugged into a Pi USB Port.  Also, make sure to have a copy of the OneSheeld Arduino Libraries and Examples on the Raspberry Pi ... I just copied them to the /usr/share/arduino/libraries directory (you will need to have root privileges to copy them there though) ... you can also copy them to your sketchbook location as specified in the Arduino IDE preferences (you may have to create the directory ... and you will have to create and put them in a libraries directory under the sketchbook directory ... otherwise, the IDE won't find the libraries during compilation of any sketches).

 <<< TERMIO ISSUES - ALAMODE SPECIFIC >>>  
 You may want to add this somewhere to your start-up configuration ...  
 or create an easily accessible script somewhere.  
   
 stty -onlcr -icrnl -F /dev/ttyS0  (or /dev/ttyS1, etc ... dependent on which is relevant)
   
 If you don't, using some of the 1Sheeld Shields won't work as-expected ...   
 and if you ever need to you can always do this to reset to default:   
   
 stty onlcr icrnl -F /dev/ttyS0  (or /dev/ttyS1, etc ... dependent on which is relevant) 
   
 There are a couple of shields that are affected if these changes   
 aren't in place (Terminal and Internet Shields are known to have problems).  



The only files that need to be changed are OneSheeld.h and OneSheeld.cpp.  All changes are highlighted in Red.

1. OneSheeld.h

For v1.3 libraries, after the #include "Arduino.h"
For v1.4 libraries, after the #include "ShieldParent.h"
For v1.5+ libraries, after the #include "ShieldsInstantiation.h"

add the following #defines ...

 #define ARDUINO_LINUX 1  
 #define RASPBERRYPI 1  

This will do 2 things for us ... the ARDUINO_LINUX define will allow the OneSheeld classes to compile properly (so it knows what version of string is available on the Rasberrry Pi) and the RASPBERRYPI #define will allow us to fix a couple other problems.

2. OneSheeld.cpp

Code in the begin function and where the class is instantiated both need to be changed...

 void OneSheeldClass::begin(long baudRate)  
 {  
  #if defined(__AVR_ATmega32U4__) || (defined(ARDUINO_LINUX) && !defined(RASPBERRYPI))  
  Serial1.begin(baudRate);  
  #else  
  Serial.begin(baudRate);  
  #endif  
 }  
 
 #if defined(__AVR_ATmega32U4__) || (defined(ARDUINO_LINUX) && !defined(RASPBERRYPI))  
 OneSheeldClass OneSheeld(Serial1);  
 void serialEvent1()  
 #else  
 OneSheeldClass OneSheeld(Serial);  
 void serialEvent()  
 #endif  
 {  
  OneSheeld.processInput();    
 }  

In both of cases, we want to use the Serial object NOT the Serial1 object when compiling for the Raspberry Pi.  So, even though ARDUINO_LINUX is #defined, we now can check for the RASPBERRYPI #define, and create and use the Serial object, rather than the Serial1 object.

---------

That is literally ALL you need to do.

I originally had a statement here about removing the two #defines if you were going to plug an Arduino into one of the Pi's USB ports (indicating you would have to remove the defines manually before compiling).  Further investigation has proven that these changes ARE REQUIRED for Arduino device compilation too.

A couple additional notes:   On the Raspberry Pi/Alamode combo ... you DO need to switch the UART switch when uploading to the Alamode (just as if you were communicating to an UNO)...and back when running a sketch.   Also, I just leave the power switch set to 3.3V ... it works fine.

Updates

03-04-2015 - changed text to indicate changes are required for Arduino devices connected through a USB Port as-well (not just the Alamode).

Friday, February 20, 2015

Using the Arduino IDE to run 1Sheeld sketches on a pcDuino

In a previous post, I provided a modified library and samples for using the 1Sheeld on a pcDuino (2 or 3) using the pcDuino Arduino-ish libraries (c_environment).   If, however, you want to compile sketches for the 1Sheeld on the pcDunio using the Arduino IDE, there are some additional things you need to do.   I've also taken pains to make sure that the changes I talk about here are integrated into the Arduino Libraries in such a way that you can still use them if you are connecting an Arduino to the pcDuino and using the 1Sheeld on the Arduino ... so, the exact same libraries can be used for Ardunio/1Sheeld sketches or pcDuino/1Sheeld sketches.

 <<< TERMIO ISSUES >>>  
 You may want to add this somewhere to your start-up configuration ... 
 or create an easily accessible script somewhere.  
   
 stty -onlcr -icrnl -F /dev/ttyS1   
   
 If you don't, using some of the Shields won't work as-expected ... 
 and if you ever need to you can always do this to reset to default: 

 stty onlcr icrnl -F /dev/ttyS1  
   
 If you really want to make a code change ... you will have to modify
 the Serial.cpp module to add this somewhere in the begin function 
 (I tested with it right before the tcsetattr() call ...   
   
  Opt.c_iflag &= ~(ICRNL);   
  Opt.c_oflag &= ~(ONLCR);   
   
 There are a couple of shields that are affected if these changes aren't
 in place (Terminal and Internet Shields are known to have problems).  

First, let me say that the changes to the OneSheeld library are pretty much identical to the changes made to compile with the c_environment (arduino-ish libraries).   Second, from what I can tell at this point, you won't have to change the sample sketches at all (no additional forward declarations required) and third, originally, you had to make changes to the Serial.cpp file to get this all to work ... but now, it's all OneSheeld library changes.  Every thing that needs to be changed or added is highlighted in Red below.

Note:  New v1.5 requirements ... After copying the Arduino Library and Samples to you pcDuino, delete the library.properties file from the library directory (OneSheeld) or the Arduino IDE included with pcDuinos will throw an error (and not load).

So, let's get started with the code changes.

--------------------------

OneSheeld Library changes ... 

1. OneSheeld.h - should be found in /home/ubnutu/Arduino/libraries/OneSheeld 

Add the following to just below the #define OneSheeld_h line ...

 #ifdef PCDUINO_IDE  
 #define PCDUINO 1  
 #define ARDUINO_LINUX 1  
 #endif  

The reason for these additional lines is to change things a bit for pcDuino when the OneSheeld libraries compile.   The ARDUINO_LINUX #define is already used by the OneSheeld libraries and defining it fixes a couple things so the libraries will compile for us.   The PCDUINO #define is new and we're going to make a couple changes to the OneSheeld libraries so things will compile properly.  The #ifdef PCDUINO_IDE check indicates that we only want to do the other #defines if we are compiling for the PCDUINO.  If we have an Arduino connected, we won't #define PCDUINO or ARDUINO_LINUX at all.

Also add the following  above the #include "Stream.h" line.

 #ifdef PCDUINO  
   typedef unsigned char byte;  
 #endif   

2. OneSheeld.cpp - again, should be found in /home/ubnutu/Arduino/libraries/OneSheeld 
put the following code around the #include "HardwareSerial.h" line ...


 #ifdef PCDUINO  
 #include "Serial.h"  
 #else  
 #include "HardwareSerial.h"  
 #endif  

also, add the extra checks for the PCDUINO definition in the begin method and where the OneSheeld object gets instantiated ... 


 void OneSheeldClass::begin(long baudRate)  
 {  
  #if defined(__AVR_ATmega32U4__) || (defined(ARDUINO_LINUX) && !defined(PCDUINO))  
  Serial1.begin(baudRate);  
  #else  
  Serial.begin(baudRate);  
  #endif  
 }  

 #if defined(__AVR_ATmega32U4__) || (defined(ARDUINO_LINUX) && !defined(PCDUINO))  
 OneSheeldClass OneSheeld(Serial1);  
 void serialEvent1()  
 #else  
 OneSheeldClass OneSheeld(Serial);  
 void serialEvent()  
 #endif  
 {  
 #ifdef PCDUINO  
  Serial.process_recv();  
 #endif  
  OneSheeld.processInput();     
 }

Finally, we need to add an additional parameter to the pulseIn calls in the analogRead method ...

 static unsigned long analogReadTimeout = 1000000L;  
 
 unsigned char OneSheeldClass::analogRead(int pin)  
 {  
   double period=(double)pulseIn(pin,HIGH,analogReadTimeout)+(double)pulseIn(pin,LOW,analogReadTimeout);  
   double duty=(double)pulseIn(pin,HIGH,analogReadTimeout);  
   double fraction=duty/period;  
   unsigned char pwm_out=(unsigned char)(ceil)(fraction*255);  
   return pwm_out;  
 }  

That is all that you should have to do to use the Arduino IDE when compiling OneSheeld sketches with the 1Sheeld sitting on the pcDuino.   

Also, if you already had the pcDuino OneSheeld library changes in place, make sure you revert back to the original Serial.cpp module ... remove the comment tags that commented out the serialEvent() and serialEventRun() functions and delete the newer serialEventRun() function.

  /*   
  #define serialEvent_implemented   
  void serialEvent()   
  {   
   Serial.process_recv();   
  }   
  void serialEventRun(void)   
  {   
  #ifdef serialEvent_implemented   
   serialEvent();   
  #endif   
  }   
  */   
   
  void serialEventRun(void)   
  {   
  Serial.process_recv();   
  serialEvent();   
  }   

Please remember to select the pcDuino as the Board in the Arduino IDE.   Make sure you pick the right Serial Port (if you don't have an Arduino connected, it should be the only port available).  

Also, set the power switch to 3.3V (since that's what pcDuino wants) ... and you can just leave the UART/SWITCH set to UART ... since you will be just compiling to the files system and running an executable.  That switch can just stay where it is.

These are the same changes that I made for the c_environment version. The big difference is the Arduino IDE version doesn't need the forward declarations added to the samples (which would probably have worked if needed).

Updates

02-24-2015 - removed requirement to modify the pcDuino version of Arduino.h ... now the only original pcDuino library change is to Serial.cpp (and it's the exact same change that is needed for the Arduino-ish [c_environment] version). 

03-05-2015 - no changes are required to the pcDuino library now (none, zero, zilch, zip) ... all necessary changes are part of the OneSheeld library ... and the changes made to the OneSheeld Library are done in a way (wrapped in #ifdefs)  that you can still use the library for either pcDuino compiles or Arduino compiles without any additional changes.

03-09-2015 - Updated for compatibility with Arduino v1.4 library and samples.

05-06-2015 - New requirement for v1.5 library noted above.

Monday, February 16, 2015

All post's source code downloads now point to Github

As of 02-16-2015 all source code (libraries, sample, sketches, etc) download links in the Arduino CodeDog blog posts that I've created have been changed and now point to public Github repositories.

All future source code downloads will point to Github repositories as well.

Friday, February 6, 2015

1Sheeld's GamePad and a Gameduino and you are Good-To-Go

After converting the Arduino Libraries to C# for Netduino I needed a little play time.  So, I decided to dig out my Gameduino and see what I could come up with.  It didn't take long to think "hmmm, 1Sheeld's GamePad may just work for the Frogger demo that the Gameduino folks have provided" ... and a small change to the Frogger Sketch (adding 1Sheeld Gamepad support) and voila, Frogger on an Arduino with 1Sheeld GamePad support...very, very cool!


Here's the entire Controller class using the OneSheeld library GamePad support, #include the OneSheeld.h at the top of the Frogger sketch and you will be crossing the street with a frog in tow in no time.

 class Controller {  
  public:  
   void begin() {  
    OneSheeld.begin();  
    prev = 0;  
   }  
   byte read() {  
    byte r = 0;  
    if (GamePad.isDownPressed())  
     r |= CONTROL_DOWN;  
    if (GamePad.isUpPressed())  
     r |= CONTROL_UP;  
    if (GamePad.isLeftPressed())  
     r |= CONTROL_LEFT;  
    if (GamePad.isRightPressed())  
     r |= CONTROL_RIGHT;  
    byte edge = r & ~prev;  
    prev = r;  
    return edge;  
   }  
  private:  
   byte prev;  
 };  

Put the 1Sheeld on an Arduino UNO r3 (or similar), put the Gameduino on the 1Sheeld.

For Manic Miner (updated):

Well, what I thought would work doesn't (the code I placed here earlier just doesn't seem to want to work).   What I have found is that it seems like it's best to just define pins on the 1Sheeld GamePad (rather than using the GamePad class) and then tweak the Manic Miner code like below:

 /* Setup 1Sheeld Gamepad Buttons to point to some pins... I used analog pins, but it probably doesn't matter. */  
 #define PIN_L A2  
 #define PIN_R A3  
 #define PIN_J A5  
   
 /* This was already in the code, but I just copied and pasted everything that needs some changes ... nothing here though */  
 #define CONTROL_LEFT 1  
 #define CONTROL_RIGHT 2  
 #define CONTROL_JUMP 4  
   
 /* Don't do any of the digitalWrite's in the setup_control() function ... I just commented them out... all we have to do is setup the pin modes for input. */  
 static byte setup_control()  
 {  
  pinMode(PIN_L, INPUT);  
  digitalWrite(PIN_L, HIGH);   
  pinMode(PIN_R, INPUT);  
  digitalWrite(PIN_R, HIGH);  
  pinMode(PIN_J, INPUT);  
  digitalWrite(PIN_J, HIGH);  
 }  
   
 /* Finally get rid of the ! in front of the digital read calls, we want the character to jump or move when we press the button(s) ... note, this was fine for the hardware joysticks, but for the 1Sheeld Game Pad, we need to do things a bit different! */  
 static byte control()  
 {  
  byte r = 0;  
  if (!digitalRead(PIN_J))  
   r |= CONTROL_JUMP;  
  if (!digitalRead(PIN_L))  
   r |= CONTROL_LEFT;  
  if (!digitalRead(PIN_R))  
   r |= CONTROL_RIGHT;  
  return r;  
 }  

One of the benefits of doing it this way is you don't have to load the OneSheeld libraries at all, so the code stays small enough to run on an UNO too!!!

Frogger could have been done similarly.

Updates

02-15-2015 - Updated changes for Manic Miner to work.

Saturday, January 31, 2015

MakerShield Kit, why another Prototyping Shield?

Even though I do have an Adafruit Proto Shield, which works well and I've had no problems what-so-ever with it, I decided to pick up one of the MakerShield Kits for a number of reasons.

  • Yes, It has a Potentiometer on the board ... but that wasn't the primary reason.
  • The Shield Headers allow you to attach shields ON TOP ... BIG reason #1 
  • The ICSP Headers are in the correct place for Arduino Shields ... BIG reason #2

So, why is this important if you are going to use it as a Prototyping shield, you want it to be the one on top, so you can access everything... right?   Well... yes, typically.  But here are the benefits to me...

  1. I have a pcDuino with a T Board to bridge 5V Arduino shields (the pcDuino only wants 3.3V shields used, the T Board allows 5V shields without damaging the pcDuino).  It has ICSP headers, but they aren't in the standard location for Arduino shields.  The MakerShield fixes that, I can attach this to the T Board and then attach a shield that has the ICSP connection, and I'm good-to-go.
  2. I also have an Arduino UNO clone from doflye.net (Chinese).  Bought it for about $4.00 on eBay.  After replacing the chip with the correct one for UNO (instead of the one that was included with it ,.. another $2.00 expense), I found that the ICSP headers on this board were rotated 180%!!!! (i.e not compatible with standard Arduino shields at all), and it's offset just a tad from the Standard Arduino.position too.   The MakerShield fixes that too.  I can now just attach the MakerShield to the clone, then attach a shield that has an ICSP connection, and, again, good-to-go.   I tried it with my USB Host Shield and it worked like a charm.
To me, the MakerShield is a benefit in a couple of ways ... plus it's a nice Prototyping shield too ... it works for my Arduino (including fixing a problem with a clone I purchased), pcDuino (fixing the ICSP header location on the T-Board) and my Netduino too (it doesn't even have ICSP headers ... this Shield is the recommended way to resolve that too!).

Keep in mind, that it does come as a kit, you need to dig out the tools and soldering iron to put it together.  But once you do, I think you'll find it's a nice addition.

Wednesday, January 21, 2015

Netduino Library and Samples for 1Sheeld

NOTE:  See the revisited post here for additional information and updates.

I received a Netduino Plus 2 as a gift a little while back. I have completed converting the 1Sheeld Arduino Libraries and Sample Sketches to C# so they can be used with my Netduinos (I now own a Netduino 3 Wifi as-well).

Please note: the projects / source were created with Visual Studio 2013 Professional, but are being maintained with Visual Studio 2015 Professional (Note: the free version of Visual Studio 2015 Community works fine and will load the solution, compile and run the samples without any problems).  The projects / source also expects a recent firmware on the Netduinos with the latest.NET Micro Framework, the VS 2015 Project System, and the latest Netduino SDK.

Recommendation: Since there are multiple projects that you can deploy in the OneSheeld solution, rather than setting a sample as a Startup Project, I highly recommend that you right-click on one of the sample solutions, select debug->Start new instance to upload to the Netduino and start a debugging session of whatever sample you want to play with.

All Shields and the SDK supported by the Arduino 1Sheeld v1.13 library are now supported by the Netduino library.

If  you are interested in playing with the Netduino Libraries and Samples, you can find the most recent updates here



You can also follow along with the discussions and updates on the 1Sheeld Forums here. (you will need to be a member and logged in to get the full benefit).

I just leave the 1Sheeld at 3.3v and the other switch set to UART (you do NOT need to change the switch to upload to the Netduino Plus 2 & Netduino 3 Wifi ... not sure about other Netduinos).   

Updates

01-22-2015 (1) - Added Buzzer and Camera Shields. Note: Difference with Arduino Samples ... pin 11 is used for the Button (Arduino Samples use pin 12) ... pin 12 always seems to start high on my Netduino ... not sure why really ... but pin 11 is low, so it does seem to be a Netduino hardware feature. And when using a button from the 1Sheeld, until you specify the pin for the button, it will stay high (since technically there isn't a button hooked up to the pin). Had some issues when I re-connected the the 1Sheeld app with a PushButton and Camera already defined, it would start taking pictures until I setup the pin 12 on the pushbutton ... not exactly what we want ... I guess I could have setup a hardware button rather than using the 1Sheeld PushButton ... but what's the fun in that????

01-22-2015 (2) - Added Twitter Shield. Note: Camera sample now sends picture as Tweet (like Arduino sample does). Again, used pin 11 instead of 12 for button.

01-22-2015 (3) - Added Accelerometer Sensor Shield. Note: Sample only expects 1 Axis to be > 8 (Arduino seems to want all 3 ... although just the Z-Axis > 8 might turn on the LED on the Arduino, just because of hardware performance).

01-22-2015 (4) - Added SevenSegment Shield. Note: setDot() function doesn't work, but according to the 1Sheeld docs, it's for future use.

01-23-2015 (1) - Added LCD and Magnetometer Shields.  LCD sample included and Magnetometer sample uses LCD too (Arduino sample uses hardware LCD shield ... why???).

01-23-2015 (2) - Added Facebook Shield (with sample).

01-24-2015 (1) - Added Gravity Sensor and Gyroscope Sensor Shields support, both have samples which are slightly different than the Arduino versions.  Just a single led is used to show when one of the 3 axis values go large enough to illuminate the led, Also, realized that I did have access to a Sqrt function directly from .NET so the MagnetometerShield class now calls it, rather than providing its own.

01-24-2015 (2) - Added Temperature Sensor Shield support with Sample.  Note: I have NO WAY to test this.  I think it will work. For those that can use it: if it doesn't work, please let me know.

01-25-2015 (1) - Added Light Sensor Shield support with Sample.  Note: The callback interface names have changed a bit recently ... Instead of using a Shield Name within the Interface Name (like IToggleButtonCallback), I am now using names based on data type (IByteCallback, or IBoolCallback ... these can be used across Shield implementations ... one exception is the ITwitterCallback which is pretty unique and that callback interface is still present) ... I would recommend just deleting and re-installing the whole OneSheeld Library/Sample directory structure.  If you have also started coding and you have used one of the old callback interface names, the only change you should have to make is the name of the interface that your class derives from.

01-25-2015 (2) - Added Proximity Sensor Shield support with Sample.

01-26-2015 (1) - Added Terminal Shield support with Sample.  Also fixed a problem with PushButton and ToggleButton (when I moved to a base class for these shields, I missed initializing the Shield Function Id variable in the constructor.   So, if you are having problems with either of these shields ... UPDATE, they should work again.  I do need to do some additional testing for the terminal shield.  But, the sample definitely works (a bit different from the Arduino sample ... I didn't want to hook up a fan and I have no way to use a temperature sensor shield, so the Netduino sample just sends a message to the Terminal Shield when a ToggleButton Shield button is on (it also turns on an Led connected to pin 13).

01-26-2015 (2) - Added Orientation Sensor, Pressure Sensor and SMS Shield support with Samples. Again, since I don't have a temperature sensor compatible device that I can use for testing, the SMS sample just uses a simple PUSHBUTTON to send a text.  The Pressure sample uses SMS too.  Don't forget to change the phone # for sending the message(s) in the samples.

01-27-2015 (1) - Added Slider Shield support with sample.  Also, changed ALL samples using callbacks. You should see far better performance now.  Moving the actual processing back to the Loop() and just capturing the value in the callback is a better way to handle things.  Otherwise you are reliant on the speed at which the Library has time to process the callback.  Just capturing the value(s) sent by the callback, then using it in the main process Loop will give you far better performance (and control).  When I was testing the Slider sample, it became very evident that there was a performance issue.   The Slider sample is different from the Arduino sample.  I use a Buzzer and a Slider Shield.  As the slider is moved up, the speed of the buzzer going on and off will increase (the length of the on/off times will decrease), and in-turn when the slider is moved down, the speed of the buzzer going on and off will decrease (the length of the on/off times will increase).

01-27-2015 (2) - Added Clock, TTS and VoiceRecognition Shield support with Samples.  Note:  The TTS sample is also the VoiceRecognition sample for now.  Also:  The Clock Shield on the Netduino cannot be initialized (using begin()) in Setup since the reset of the Netduino also resets the 1Sheeld (and the clock never gets initialized).  I have added a new function to the Netduino Clock Shield called isInitialized.  In the sample Loop function, I check to see if the clock hasn't been initialized, if it hasn't, I call begin() there instead ... this will initialize the clock and future reads will return data.  The Clock sample is different from the Arduino sample, I just use a Terminal Shield to send the current time to the Terminal every 2 seconds.  Finally, the main section of the posting now shows those shields NOT supported, this list will shrink as time progresses.

01-27-2015 (3) - Added DataLogger Shield support with Sample.

01-27-2015 (4) - Added Email Shield support with Sample.

01-27-2015 (5) - Added Foursquare Shield support with Sample.

01-27-2015 (6) - Added GamePad Shield support with Sample.  Again, sample is different from Arduino.  I'm more interested in things working (and being able to see things working than getting too fancy right now).  So, the sample just sends a text message to terminal when buttons are pressed.  Also, I think there is a problem with how the Arduino callback support is implemented for the GamePad shield (will be reporting  my assessment to guys at OneSheeld).

01-28-2015 (1) - All remaining Shields are now Supported (GPS, KEYBOARD, MUSICPLAYER, NOTIFICATION, PHONE, REMOTE and SKYPE) ... with samples.   I also created a VOICERECOGNITION sample.   Please NOTE:  I have no idea if Remote Shields work (I only have a single 1Sheeld ... it won't be because there's no code, it will be because I messed up).  Please let me know if you find any problems.

01-28-2015 (2) - Just uploaded a new version.  I upgraded to the Non-Beta (QFE R2) version of the .NET Micro Framework that was just released.   Just in-case something changed project wise, etc, just wanted to make sure the latest was available for download.   No other changes.

01-29-2015 - A very minor change to the Clock Shield ... it wouldn't make any difference in the actual functionality.  But it might save some clock cycles (but nothing you would probably notice) ... lol ... a change to the Clock Shield that saves clock cycles.  I crack myself up.

02-13-2015 - Moved Library and Sample Downloads from Google Drive to Github.

03-09-2015 - Added support for v1.4 app with currently supported Shields.   Updated Github.

03-10-2015 - Added support for v1.4 Pattern Shield with Sample ... Internet Shield is next.  Updated Github.

03-16-2015 - Added support for v1.4 Internet Shield with (2) Samples.  Also added instance and callback support similar to Arduino libraries.   Github has been updated.

03-18-2015 -  Upgraded Github with Usability updates.   See new post for an explanation.

05-06-2015 - Upgraded Library and Samples to v1.5.  NFC and Color Detector Shields are now supported (samples included for each).  Remote Shield support has been removed.  Clock Shield has been updated.   Everything is checked in to Github.

05-08-2015 - Made some modifications to ColorShield memory handling and also added ISelectionCallback support to the SampleCOLOR sample (both non-callback and callback versions). There is also a public setColor method that has been added to ColorClass (which is used within the ColorShield for improved memory handling).

05-09-2015 - Changed supported Netduino SDK version to v4.3.2.1.

06-25-2015 - Improved Serial Port handling (now uses multi-byte reads) ... also tweaked a couple of the Samples.   Everything is checked in to Github.

08-10-2015 - Noted support for Visual Studio 2015 Community.

08-18-2015 - Upgraded Library and Samples to v1.6.  GLCD Shield is now supported (samples included).  Everything is checked into Github.

09-20-2015 - Upgraded Library to 1.6.1.  Everything is checked into Github.

11-24-2015 - Upgraded Library to 1.7.  Everything is checked into Github.

01-26-2016 - Upgraded Library to 1.8.  Everything is checked into Github.

04-22-2016 - Upgraded Library to 1.9.  Everything is Checked into Github.

05-24-2016 - Upgraded Library to 1.9.2 (I never did a 1.9.1 upgrade).  Everything is Checked into Github

11-30-2016 - Upgraded Library to 1.10.0.  (This includes the newest Barcode Scanner Shield). Everything is Checked into Github.

01-05-2017 - Upgraded Library to 1.11.0 (This includes the new Face Detection and Fingerprint Scanner Shields).  Everything is Checked into Gibhub.

02-17-2017 - Upgraded Library to 1.12.0 (This includes the new Chart Shield).  Everything is checked into Github.

06-21-2017 - Upgraded Library to 1.13.0 (This includes the new IOT Shield).  Everything is checked into Github.

Saturday, January 17, 2015

SolidDigi Color Image Shield Revisited

As previously mentioned, the SolidDigi Color Image Shield is very similar to the (now retired) SparkFun Color LCD Shield, but does have some differences. I had converted some of the code found around the internet that was available for the SparkFun shield so it would work on the SolidDigi shield. Now, I've decided to take a lot of that same code and make it work on the pcDuino. So, if you have a pcDuino, this shield will now have some sample code that works on the pcDuino.

Below is a list of what has (and has not been converted) of those mentioned in a previous post:

  • The Color LCD Shield Library - converted and working.
  • The Arduino-O-scope - converted and working,
  • The SparkFun Sample - not converted (although I did move over the Mandelbrot and RGB Image code to the SolidDigi Sample (just run the SOLID application and press the 1st and 3rd buttons simultaneously to see the demo(s) work).
  • The SolidDigi Sample (with color tweaks) - converted and working.

You can find the code here.    Just unzip the two directories (Solid and ColorLCDShield) into the c_environment directory.  Change to the directories and run a make clean followed by a make to rebuild everything.   The samples will a end up, ready to run in the directories' sample/bin directory.  Don't forget you have to run with a ./ preceeding the sample name if the directory isn't part of the path.  So, for example, you would run the SOLID sample by typing ./SOLID and pressing enter (while being in the ~/c_enviroment/Solid/sample/bin directory).

A couple of notes:

- This isn't the fastest running code in the world (for example, the clock sample included with the Color LCD Shield library...I had to add 2 seconds to every update for the clock to keep up (and it actually does pretty well accuracy wise ... no promises on absolute accuracy though ... consider it just a sample for the shield, not necessarily an accurate clock!).

- The main problem with speed is that I haven't found a way (yet) to have direct access to the GPIO pins (I do use the file writing method ... which works, but not nearly as zippy as a memory mapped technique, etc).

If anyone knows about a faster method of setting pin modes and performing digital writes on a pcDuino, I'd love to hear about it.   Something similar to the PORTB/DDRB abilities on an Arduino.

For now, these samples do work.   I'm using the Translatiion T Board with this shield.  Not so much that I need to ... but, I'm just not 100% convinced I don't need to.   Even with 3.3V shields, they work just fine with the T Board.  I'd rather be safe than sorry.

Updates

02-16-2015 - Libraries and Sketches moved to Github.