Code efficiencies on #Arduino

Let's talk a minute about code efficiency. I’ve written code before for devices that had small memory models and Arduino is no exception. Every spare byte of memory used can be the difference between success or failure. This isn’t a problem with your PC because it employs a virtual memory model. When you open the 20th tab on your web browser and your PC runs out of memory, your PC simply takes some programs that it is not currently working on and the data that they have in memory and writes them to a swap file on your hard disk. When those programs are needed again, something else is removed from memory and they are swapped back in. The user doesn’t, usually, even notice this happens except that their pc will get slower the more that this has to happen, because reading from the hard disk is much slower than reading from memory. So, yes, if you have enough going on that your PC is swapping things in and out constantly, your PC will keep slowing down. That advertisement that has the dollar bills flying from a piggy bank is still running, being swapped in and out, even though you haven’t looked at that web page in 20 minutes. Just close it. 

Anyway, this is handled by your computer’s operating system (OS). This can be Window’s, iOS, Lynix, etc. Your Arduino doesn’t have an OS. It has very little beyond the boot loader and your last uploaded sketch. Even if an OS was written for it, without a hard disk, there’s no where to write a swap file. That’s not to say it couldn’t be done. Some clever person, or group, may write a simple OS that will implement virtual memory using an SD card or something. But, today, as far as I know, that doesn’t exist.

That is why I have to worry about code efficiency. Having said all of that, our “Shooting Star” game is really in danger of running out of memory on my Arduino mega compatible microcontroller which boasts 256KB of flash memory. Only 8KB is used by the bootloader. In times when PCs are talking about gigabytes of memory ¼ of a megabyte seems terribly small, but these sketches are tiny. Since this game is going to be our first complete project, not including experimentation, I would like to build a permanent version with a nice case that my kids can play with and, more importantly, as a keepsake of this milestone of our journey. I have no intention of using the power, and size, of this microcontroller board for this little keepsake. My plan is to spend $3.00 on an ATtiny84 which has 512 Bytes of memory. Yes, Bytes, roughly ½ KB and the bootloader will steal some of that! It’s like comparing a drop of rain to a lake.  Add a 9 volt battery adapter, a little pcb board, power regulator, a bit more resilient push-button, power switch, and a case. Without actually pricing out everything, I suspect that we can put it together for under $25 and a ton of new experiences (flashing bootloaders, pcb layout, soldering, etc.)
ed: I apparently mis-read the specs for the ATtiny84, it can actually have up to 8k of Flash memory.  It has a 512 byte eprom and 512 byte sram.    

So where am I going to find these inefficiencies in my program? Everywhere, you’d be surprised. Let’s start with my displayLed() function. I thought I was being pretty efficient by assuming that only 1 LED would be lit at a time. What I had though was a lot of code:

void displayLed(unsigned long iVal){
  digitalWrite(latchPin, LOW);            //Pull latch LOW to start sending data
  if (iVal > 255){
    shiftOut(dataPin,clockPin,MSBFIRST,0);
    shiftOut(dataPin,clockPin,MSBFIRST,iVal/256);
  }
  else
  {
    shiftOut(dataPin,clockPin,MSBFIRST,iVal);
    shiftOut(dataPin,clockPin,MSBFIRST,0);
  }  
  digitalWrite(latchPin, HIGH);           //Pull latch HIGH to stop sending data
}

As with most discoveries, this was not a Eureka moment. I was thinking, after the “caught” LED blinked, wouldn’t it be nice to have it split and fly off in both directions? By my displayLed() function can’t handle 2 LEDs. Technically, it can, but only in the right 8 LEDs. So I turned to Excel, as I often do, to figure out the math. I had already figured out that the left 8 leds can be calculated by “int(a1/256)” and realized that the right bits are actually the remainder of that calculation “mod(a1,256).” I came up with this using those 2 formulas:

1	0	1	00000000	00000001
2	0	2	00000000	00000010
4	0	4	00000000	00000100
8	0	8	00000000	00001000
16	0	16	00000000	00010000
32	0	32	00000000	00100000
64	0	64	00000000	01000000
128	0	128	00000000	10000000
256	1	0	00000001	00000000
512	2	0	00000010	00000000
1024	4	0	00000100	00000000
2048	8	0	00001000	00000000
4096	16	0	00010000	00000000
8192	32	0	00100000	00000000
16384	64	0	01000000	00000000
32768	128	0	10000000	00000000

If I want the 3^rd LED from each end lit, I would add 8192 + 4 getting 01000000 00000010 in binary, but more importantly, I’d get 32 for the left register and 4 for the right register. Now back to the displayLed() function. With the math worked out, I can get rid of 2 lines of code and the entire “if” structure:

void displayLed(unsigned long iVal){
//This will work for 16 leds only and light any value between 0 and 65535
  digitalWrite(latchPin, LOW);         //Pull latch LOW to start sending data
  shiftOut(dataPin,clockPin,MSBFIRST,iVal%256);//Right 8 Leds
  shiftOut(dataPin,clockPin,MSBFIRST,int(iVal/256));//Left 8 Leds
  digitalWrite(latchPin, HIGH);        //Pull latch HIGH to stop sending data
}

I admit, I had to look up modulo, which isn’t a function, but an operator “%”)

Final design for our #arduino project

Now that we figured out how to make all of the components work, it was time to sit down and hash out the final design for our project. My son, age 7, started out by writing out the rules of the "catch the light" game:

For those of you that can't read 7 year old, they are:

1. Delay 100 ms between blinks

2. 10 points for blue and 5 points for white.

3. If you get 3 red you're out.

4. If you don't get 3 red and it slows down, you win - Translate when the delay rolls over, game over, you win.

This is the design document. We sat down, debated, and agreed on these. I'm not gonna re-write as I held the pencil and it's, more or less, legible. One important note, we decided to name the game "Shooting Star."

Finally got the #LCD panel working on my #arduino project

In my last post I showed the pin outs for the LCD as provided by the seller. One pin #3, I didn't connect it to anything because the diagram showed a value of "--" and I took this to mean it wasn't required. When I couldn't get even a flicker, I started to play around eventually connecting it to ground and, amazingly, the screen lit up. It was all black though, so I figured that I need to reduce the current. I tried several different resisters and settled on a 20 k which gave me a tolerable contrast. In the end, I guess that I need a variable resister to get it exactly right. Now, I can start coding the rest of the game logic. This is gonna be fun.

Trouble with the 16x2 #LCD on my #arduino project

Using the wiring diagram that was included on the eBay listing for the LCD panel, I proceeded to wire it up. It appeared that I simply needed the following:

Pin	Connection	Description
1	+5 Volts	+5 Volts
2	GND	Ground
3	--	vadj - Adjust (contrast?)
4	C/D	Command/Data (RS?)
5	R/W	Re/Write
6	E	Chip Enable
7	D0	Data
8	D1	Data
9	D2	Data
10	D3	Data
11	D4	Data
12	D5	Data
13	D6	Data
14	D7	Data

The red wire, despite the color, appears to be a ground. The red color, to me, made me think it was +5 volts, but when I looked where it was soldered, which was to the metal housing around the display, I concluded it must be ground. I decided that, for now, I need not connect this since I am providing ground to pin 2. The code, too, looks pretty straight forward. I had to include the "LiquidCrystal" library:
     #include <LiquidCrystal.h>

I created an object for the LCD:
     LiquidCrystal lcd(11,7,5,4,3,2);

This created my lcd object telling the library that pin 11 was rs, 7 was enable, and 5-2 were data 4-7. In the setup() function, I specified the display size of 16x2:
     lcd.begin(16,2);

Then I merely wanted to display "Welcome." Again, in the setup() function, I added:
     lcd.print("Welcome");

Compile, upload, nothing. The LCD didn't flicker, nothing. The rest of the project still functioned, the LEDs began their march back and forth and the interrupt worked when I pressed the button.

As usual, I'm left with a mystery. Did I wire it wrong? Did I code it wrong? Is the part defective? Unlike when I started working with the shift register, I don't have a spare and a replacement is a LONG boat ride away unless I want to pay a premium price.

The thing is, yes, for this game I need a display, but my longer term goals don't really require it. But it will be incredibly helpful when working with other shields to be able to display values returned.

One of those longer term goals is going to quickly become more immediate. A few weeks back I joined the Western PA Robotics Competition, WestPARC, group. Last night was the first meeting. Unfortunately, we were unable to attend because last night was also my son's last baseball game of the season and my daughter's last softball game, neither of which we could really miss. I did see a brief update of the meeting though and it described the first competition. It is a simple one, but will require that I fast-forward my work if I want to participate. The description:

For those who couldn't make it: we've settled on a 
straight-forward first contest: your bot will be placed 
some semi-random distance from a wall, and will be 
given a maximum time limit to approach the wall as 
close as possible without touching it.  How hard can it 
be, right?  :)

I'm sure Eric will have a rule-filled write-up soon, 
and we can start talking specifics about the first 
contest.  As for me, it's down to the basement to heat 
up the soldering iron.

Considering that I've not made anything move beyond rotating a servo, I need to get going. Need to figure out how to use that Ultrasonic Module HC-SR04 Distance Measuring Transducer Sensor that I bought.

I got the #arduino project to work, but I don't understand why

First, I modified the displayLed() routine to take an argument and modified all of the code to call it that way. But, that didn't work. So, I modified the the interrupt handler to to set a flag that it occurred, and modified the main loop to blink the "caught" LED. This worked, but I don't know why. Is it because interrupt handlers can't call a routine from the main code? This doesn't make sense to me since the, now functioning, version calls other functions. Do I need to declare the displayLed() function differently? Maybe someone can leave a comment or tweet a reason. Here's the code:

int dataPin = 10;        //Define which pins will be used for the Shift Register control
int latchPin = 9;
int clockPin = 8;

long i = 1;
int pauseTime = 100;      // byte #2 value
bool left = true;
bool buttonPushed=false;
volatile int state=LOW;
unsigned long time;
unsigned long lasttime;
void setup()
{
    attachInterrupt(0,pushit,LOW);
    pinMode(dataPin, OUTPUT);       //Configure each IO Pin
    pinMode(latchPin, OUTPUT);
    pinMode(clockPin, OUTPUT);
    pinMode(12,OUTPUT);
    digitalWrite(12,state);
    lasttime==millis();
}
void loop()
{
  displayLed(i);
  if(buttonPushed){
    for(int loopVar=0;loopVar<10;loopVar++){
      displayLed(0);
      delay(150);
      displayLed(i);
      delay(150);
    }
    buttonPushed=false;
  }

  if (left ){
    i = i << 1;
  }
  else
  {
    i = i >> 1;
  }
  if (i == 32768 || i == 1){
    left = !left;
  }
  delay(pauseTime);
  if (pauseTime <= 0){
    pauseTime = 100;
  }
}
void pushit(){
  time=millis();
  if (time-lasttime>50){
    digitalWrite(12,!state);
    state=!state;
    lasttime = time;
    pauseTime = pauseTime - 2;
    buttonPushed=true;
  }
}
void displayLed(unsigned long iVal){
  digitalWrite(latchPin, LOW);            //Pull latch LOW to start sending data
  if (iVal > 255){
    shiftOut(dataPin,clockPin,MSBFIRST,0);
    shiftOut(dataPin,clockPin,MSBFIRST,iVal/256);
  }
  else
  {
    shiftOut(dataPin,clockPin,MSBFIRST,iVal);
    shiftOut(dataPin,clockPin,MSBFIRST,0);
  }  
  digitalWrite(latchPin, HIGH);           //Pull latch HIGH to stop sending data
}

My next challenge is the LCD panel. I looked up code samples on the Arduino web site shows a different version of the LCD. Mine has a 14 pine header mounted on the bottom and a red wire soldered to the bottom. No idea what this is for.

I guess I have to do some tinkering.

I could use some help on my #arduino project

I intended for my son and I to spend some quality time last night getting the LCD display working that I bought on eBay. But, my lack of knowledge and experience got in the way. I mentioned that the code that I used, I found online. It had 2 arrays that stored decimal values for one led to start at the left and scan to the right 7 positions in one shit register and the other did the opposite in the other shift register. The final result was 2 LEDs appeared to start from both ends of the line and move toward the center, cross and continue to the opposite end. When, in fact, neither crossed the center, each register was simply panning back and forth.

For my "catch the light" game idea, I needed to have a single LED scanning back and forth. I've been a programmer in the medical industry for more than 20 years, but never had to deal much with binary data and never hardware beyond RS232 communications.

This is where my in-experience showed through.

I didn't want to use the arrays. Maybe that was a mistake. I knew easily enough that to count in binary I simply needed to start at one and multiply by 2:

     1 = 1

     2 = 10

     4 = 100

     8 = 1000

     16 = 10000

     32 = 100000

and so on. I thought that I understood that the binary data flowing to the shift registers would cascade pushing (shifting) the bits to the next shift register. I thought that I could simply keep shifting to the left until I got to 32768, then start shifting to the right until I got back to 1. The program that I started with had 2 shift outs to work with the 2 arrays:

        shiftOut(dataPin, clockPin, MSBFIRST, seq1[x]);         //Send the data byte 1

        shiftOut(dataPin, clockPin, MSBFIRST, seq2[x]);         //Send the data byte 2

I thought that I would only need 1 shift out and could, in effect, send out 16 bits at one time. So this is what I ended up with:

     digitalWrite(latchPin, LOW);      //Pull latch LOW to start sending data
     shiftOut(dataPin,clockPin,MSBFIRST,i);
     digitalWrite(latchPin, HIGH);    //Pull latch HIGH to stop sending data
     if (left ){
        i = i << 1;             //shift bit to the left while left=true
     }
     else
     {
        i = i >> 1;             //otherwise, shift right
     }
     if (i == 32768 || i == 1){
     left = !left;                    //If we are at either end of the line toggle left
     }

Needless to say this failed. My new theory was that I could only write out 1 (8 bit) byte at a time. Now, how do I do this without going back to an array? Believe it or not, I turned to Open Office Calc, sorry I can't afford Microsoft's version of Office which, according to Amazon is $139 right now and that is for 1 user on 3 PCs, however that works. We have 2 aging PCs (one of which is homemade and the other a cheap eMachine) and a laptop. Sorry, off on a tangent. The dec2bin() function failed after 9 bits:

1	1
2	10
4	100
8	1000
16	10000
32	100000
64	1000000
128	10000000
256	100000000
512	#NUM!
1024	#NUM!
2048	#NUM!
4096	#NUM!
8192	#NUM!
16384	#NUM!
32768	#NUM!

So, I figured that if I'm under 255, I can send a zero in one shiftOut() and the value of "i" in the other. I tested this in my spreadsheet in the next column with a simple if() statement:

    =if(a1>255;a1/256;a1)
This resulted in the new column counting to 128 twice. So, while 255 or less I shiftOut() my value for "i" then a zero and when greater than 255, I shift out a zero then the value of "i/256." This is what I ended up with:

void displayLed(){
  digitalWrite(latchPin, LOW);            //Pull latch LOW to start sending data
  if (i > 255){
    shiftOut(dataPin,clockPin,MSBFIRST,0);
    shiftOut(dataPin,clockPin,MSBFIRST,i/256);
  }
  else
  {
    shiftOut(dataPin,clockPin,MSBFIRST,i);
    shiftOut(dataPin,clockPin,MSBFIRST,0);
  }  
  digitalWrite(latchPin, HIGH);           //Pull latch HIGH to stop sending data
}

Next, I replaced the 9th digit (i=256) with a blue LED, which will be our target. Then decided to replace the ones on either side (LEDs 8 and 10) with yellow LEDs as warning, thinking that in game play the blue one would be worth the max score and the yellow ones half that. I modified my code to make the delay() a variable, initially set to 100. Then modified the interrupt handler to reduce the delay by 2 milliseconds every time the button was pushed. Testing this was entertaining, especially, when the scanning speed got to the point that it appeared that all of the LEDs were on at the same time. My son kept doing this over and over giggling.

Now I wanted to see which LED was lit when the button was pushed. I thought I would simply blink the "caught" led 10 times before resuming scanning. I put this code in my interrupt handler:

void pushit(){
  long holdIt=0;
  time=millis();
  if (time-lasttime>50){
    digitalWrite(12,!state);
    state=!state;
    lasttime = time;
    pauseTime = pauseTime - 2;
    holdIt = i;
    for(int loopVar=0;loopVar<10;loopVar++){
      i=0;
      displayLed();
      delay(500);
      i=holdIt;
      displayLed();
      delay(500);
    }
  }
}

I hold the current value of "i" in "holdIt," then in a loop I set "i" to zero, display it, set "i" back to "holdIt" and display that, 10 times. I tried a 50 ms delay() between the on and off, but couldn't see it blink, even 500 ms wasn't noticable.

It got late, and my boy needed sleep, even though school is finished for the summer. So we stopped there. It was amazing how he caught on the shifting left and right, and even offered intelligent suggestions when something wouldn't compile.

This is where I'm stuck

• Why isn't it blinking? 
• Is it because "i" isn't declared as volatile? 
• Is it because the interrupt handler doesn't keep running long enough? 
• Maybe, I should pass "i" into the displayLed() function? 
• Is it because the interrupt is tripping again and starting the handler again before it finishes? 
• Should I detachInterrupt() when I get into the handler?

Any suggestions would be helpful!

Here's the whole program:

int dataPin = 10;        //Define which pins will be used for the Shift Register control
int latchPin = 9;
int clockPin = 8;

long i = 1;
int pauseTime = 100;      // byte #2 value
bool left = true;
volatile int state=LOW;
unsigned long time;
unsigned long lasttime;
void setup()
{
    attachInterrupt(0,pushit,LOW);
    pinMode(dataPin, OUTPUT);       //Configure each IO Pin
    pinMode(latchPin, OUTPUT);
    pinMode(clockPin, OUTPUT);
    pinMode(12,OUTPUT);
    digitalWrite(12,state);
    lasttime==millis();
}
void loop()
{
  displayLed();
  if (left ){
    i = i << 1;
  }
  else
  {
    i = i >> 1;
  }
  if (i == 32768 || i == 1){
    left = !left;
  }
  delay(pauseTime);
  if (pauseTime <= 0){
    pauseTime = 100;
  }
}
void pushit(){
  long holdIt=0;
  time=millis();
  if (time-lasttime>50){
    digitalWrite(12,!state);
    state=!state;
    lasttime = time;
    pauseTime = pauseTime - 2;
    holdIt = i;
    for(int loopVar=1;loopVar<10;loopVar++){
      i=0;
      displayLed();
      delay(500);
      i=holdIt;
      displayLed();
      delay(500);
    }
  }
}
void displayLed(){
  digitalWrite(latchPin, LOW);            //Pull latch LOW to start sending data
  if (i > 255){
    shiftOut(dataPin,clockPin,MSBFIRST,0);
    shiftOut(dataPin,clockPin,MSBFIRST,i/256);
  }
  else
  {
    shiftOut(dataPin,clockPin,MSBFIRST,i);
    shiftOut(dataPin,clockPin,MSBFIRST,0);
  }  
  digitalWrite(latchPin, HIGH);           //Pull latch HIGH to stop sending data
}

Leave a comment below or Tweet to @kidbotz.

Adding a #hardware #interrupt to my #arduino project

Moving toward my goal of making a "catch the light" game, I needed to master hardware interrupts. To that end, I added a single blue led and a button. The button was connected to interrupt 0 which is pin 2 on the Arduino board and ground. The LED was wired to pin 12 and ground. I used the scanning code that basically started lighting LEDs, one at a time, from both ends moving to the center and back out. The goal being to light the blue LED when I push the button without interrupting the scanning. I took the basic code, and added an attachInterrupt() function on interrupt 0, setting it to trip when the value was LOW. When this pin is pulled LOW by grounding it, the "pushit" handler is called:

    attachInterrupt(0,pushit,LOW);

I also added variables to hold the time in milliseconds and the lasttime in milliseconds.  These are needed to "debounce" the button. 

unsigned long time;

unsigned long lasttime;

Debounce, what am I talking about?

The problem is, when you push a button, as the contacts come together, the Arduino moving so fast, may think the button was pushed multiple times which would turn off the LED possibly before you even noticed it was on. To debounce it, you keep track of when the last time the button was pressed, so that when the interrupt is tripped, it compares the current time against the previous time and if it has been longer than 50 milliseconds, it will consider it to be a new button press:

  if (time-lasttime>50){

Putting it all together

Now when the sketch runs, the LED is set to LOW with a digitalWrite(), the interrupt is set, and the main loop begins the scanning sequence. I press the button, the LED turns on instantly and the scanning continues. When I press the button again, the LED turns off and the scanning continues.

You may notice from the picture that I have also added a battery. The positive (red) lead goes to VIN (Voltage Input) and the black goes to ground.  Here's the code:

int dataPin = 10;        //Define which pins will be used for the Shift Register control
int latchPin = 9;
int clockPin = 8;

int seq1[14] = {1,2,4,8,16,32,64,128,64,32,16,8,4,2};  //The array for storing the 
      // byte #1 value
int seq2[14] = {128,64,32,16,8,4,2,1,2,4,8,16,32,64};  //The array for storing the 
      // byte #2 value
volatile int state=LOW;
unsigned long time;
unsigned long lasttime;
void setup()
{
    attachInterrupt(0,pushit,LOW);
    pinMode(dataPin, OUTPUT);       //Configure each IO Pin
    pinMode(latchPin, OUTPUT);
    pinMode(clockPin, OUTPUT);
    pinMode(12,OUTPUT);
    digitalWrite(12,state);
    lasttime==millis();
}
void loop()
{
    for (int x = 0; x < 14; x++)         //Array Index
    {
        digitalWrite(latchPin, LOW);            //Pull latch LOW to start sending data
        shiftOut(dataPin, clockPin, MSBFIRST, seq1[x]);         //Send the data byte 1
        shiftOut(dataPin, clockPin, MSBFIRST, seq2[x]);         //Send the data byte 2
        digitalWrite(latchPin, HIGH);           //Pull latch HIGH to stop sending data
        delay(75);
    }
}
void pushit()
{
  time=millis();
  if (time-lasttime>50){
    digitalWrite(12,!state);
    state=!state;
    lasttime = time;
  }
}

The next step, I'm going to try using the the 2 line LCD.

2 Shift Registers on #Arduino

Shot a nice, blurry, bigfoot style video of my Arduino project using 2 shift registers. it isn't pretty, but you can see how it works, counting in binary.


I'll go through the actual build, as soon as I take the time to document it. Here's a picture of the build, that, I think, I've posted before.

Here's the Artwork
I finally took the time with Fritzing to do the artwork. Here is the circuit drawing and schematic.

int dataPin = 10;        //Define which pins will be used for the Shift Register control
int latchPin = 9;
int clockPin = 8;

int byte1 = 0;         //The counter for storing the byte #1 value
int byte2 = 0;         //The counter for storing the byte #2 value

void setup()
{
    pinMode(dataPin, OUTPUT);       //Configure each IO Pin
    pinMode(latchPin, OUTPUT);
    pinMode(clockPin, OUTPUT);
}

void loop()
{
    for (byte2 = 0; byte2 < 256; byte2++)               //Outer Loop
    {
        for (byte1 = 0; byte1 < 256; byte1++)            //Inner Loop
        {
            digitalWrite(latchPin, LOW);           //Pull latch LOW to start sending data
            shiftOut(dataPin, clockPin, MSBFIRST, byte1); //Send the data byte 1
            shiftOut(dataPin, clockPin, MSBFIRST, byte2); //Send the data byte 2
            digitalWrite(latchPin, HIGH);          //Pull latch HIGH to stop sending data
            delay(100);
        }
    }
}

Next Step
I;m going to add an interrupt connected to a pushbutton. I'm going to replace an LED in the center with a white one and place blue ones on either side. With this, I'll code a scan pattern that will work kinda like the game you see in arcades where you have to capture the light. When the button is pressed, the handler will stop the tracking and blink the captured LED for a set interval showing the LED that has been captured. Then we'll see where it goes from there.

Success, finally!

I ripped apart my last build. I'm assuming that the HC595 from that build is fried, so I set that aside. Another bread board board arrived so now I have the real-estate to make my builds a little prettier. A string of Christmas LEDs gave their lives to the project so that I can use 8 LEDs. I know what you're thinking 8? You couldn't even get 4 working. Well, the build for 8 isn't really much different than the build for 4. So, I went for it.

I know that the last code I uploaded to the arduino was the binary counter. In fact, the last version that I uploaded was the counter going from 1 through 255. I, bravely, plugged my Arduino into a power supply and grinned wildly as the LEDs began to count.

Now, do I add another shift register or two, and another 8, 16, 32 LEDs? The way I have the board laid out, I can fit 32 LEDs total. Why not?