Tuesday, December 30, 2014

More efficient coding and flashing LEDs

I got a late start playing with the Pi tonight, so I decided to not try to do too much. It turned out to be much more than I bargained for. I ran into my first real issue with the device. Here's the functional code:
import RPi.GPIO as GPIO
import time
GPIO.setmode(GPIO.BCM)

def LEDflash(channel):
#    DeactivateButtons()
    inputchannel = channel
    for i in range(1,5):
        if inputchannel == button[i]:
            GPIO.output(LED[i], GPIO.HIGH)
            time.sleep(0.5)
            GPIO.output(LED[i], GPIO.LOW)
#    ActivateButtons()

def ActivateButtons():
    for i in range (1,5):
        GPIO.add_event_detect(button[i], GPIO.FALLING, callback=LEDflash, bouncetime=200)

def DeactivateButtons():
    for i in range (1,5):
        GPIO.remove_event_detect(button[i])

# Label buttons and pins
button = [4, 12, 16, 20, 21]
LED = [22, 5, 6, 13, 19]

# Set GPIO pins
for i in range (0,5):
    GPIO.setup(button[i], GPIO.IN, pull_up_down=GPIO.PUD_UP)
    GPIO.setup(LED[i], GPIO.OUT)

ActivateButtons()

GPIO.output(LED[0], GPIO.HIGH)
GPIO.wait_for_edge(button[0], GPIO.FALLING)
GPIO.output(LED[0], GPIO.LOW)
GPIO.cleanup()

This code flashes the LEDs on for a half second when the button is pressed. You will notice that there are two commented commands in the LEDflash function. The program behaves erratically when that code is included. And really, it seems to be trying to call the ActivateButton() command that is causing problems because if I just run the DeactivateButtons() command, it seems to run just fine. For the first two buttons, there are no issues. But when I try to press the other two buttons, the program behaves strangely.
If I press button 3, it will maybe repeat the loop a couple times and then exit the program abruptly. If I press button 4, it runs the loop exactly once and then exist abruptly. It does not proceed to the line that turns off the primary LED. I have no reasonable explanation for this behavior. I even tried switching the physical buttons to see if there was some sort of sticking that was happening. I toyed around with this for about an hour with no successful resolution.
So I went over to the Raspberry Pi forums and signed up. Maybe I'll get an answer from the community.

Monday, December 29, 2014

A new breadboard, some buttons, and a game plan for Simon

I bought a new breadboard from Fry's. It's a TW-E40-1020 and seems to be a pretty standard breadboard. It cost $6.99. But upon returning home, I discovered a problem. The distribution strips down the side of the board do not match the breakout connectors from the Raspberry Pi. On that breadboard, the distribution strips are offset by a half pin, but everything on the new breadboard is lined up. It's a good thing I noticed this before I tried to force the pins into the holes. So this means I'm going to have a slightly clumsier setup, but it's nothing I can't deal with. I also bought a bag of 25 cheap buttons for $5.99. These buttons are smaller than the one that came in the kit, but they're basically the same thing.
After tax, the total was $14.03, which brings my total cost for this experiment to $137.41.
But now that (I think) I have enough pieces to put together my Simon game, I need to decide on how exactly it's going to work.
  • There will be 5 buttons. One button will be the start/reset button and the other four will be the input buttons. The reset button will be connected to pin 4, and the four input buttons will be connected in the following manner: A-12, B-16, C-20, D-21. All buttons will connect to ground when pressed and will be set as pull-up buttons.
  • There will be 5 LEDs. I happened to have four different colors from the kit, so I will use a repeat color for the mode indicator on pin 22. The others will be connected to pins in the following manner: Red-5, Yellow-6, Green-13, Blue-19. (Note: Remember that the short leg connects to ground.)

It kind of looks like a mess because of all the wires, but I don't care. This isn't about making a pretty device; it's about making a functional one.
I needed to write a short program to test all of my connections and the basic code concepts, so I decided to simply make the buttons into toggle switches for the corresponding LEDs and have the reset button act as the kill button. This was not too difficult to do using the ideas from the code that I had already learned previously.
import RPi.GPIO as GPIO
GPIO.setmode(GPIO.BCM)

def LEDtoggle(channel):
    if channel == A:
        GPIO.output(Red, not GPIO.input(Red))
    if channel == B:
        GPIO.output(Yel, not GPIO.input(Yel))
    if channel == C:
        GPIO.output(Gre, not GPIO.input(Gre))
    if channel == D:
        GPIO.output(Blu, not GPIO.input(Blu))

# Label buttons and pins
kill_switch = 4
A = 12
B = 16
C = 20
D = 21
ModeInd = 22
Red = 5
Yel = 6
Gre = 13
Blu = 19

# Set GPIO pins
GPIO.setup(kill_switch, GPIO.IN, pull_up_down=GPIO.PUD_UP)
GPIO.setup(A, GPIO.IN, pull_up_down=GPIO.PUD_UP)
GPIO.setup(B, GPIO.IN, pull_up_down=GPIO.PUD_UP)
GPIO.setup(C, GPIO.IN, pull_up_down=GPIO.PUD_UP)
GPIO.setup(D, GPIO.IN, pull_up_down=GPIO.PUD_UP)
GPIO.setup(ModeInd, GPIO.OUT)
GPIO.setup(Red, GPIO.OUT)
GPIO.setup(Yel, GPIO.OUT)
GPIO.setup(Gre, GPIO.OUT)
GPIO.setup(Blu, GPIO.OUT)

# Set GPIO Interrupts

GPIO.add_event_detect(A, GPIO.FALLING, callback=LEDtoggle, bouncetime=200)
GPIO.add_event_detect(B, GPIO.FALLING, callback=LEDtoggle, bouncetime=200)
GPIO.add_event_detect(C, GPIO.FALLING, callback=LEDtoggle, bouncetime=200)
GPIO.add_event_detect(D, GPIO.FALLING, callback=LEDtoggle, bouncetime=200)

try:
    GPIO.output(ModeInd, GPIO.HIGH)
    GPIO.wait_for_edge(kill_switch, GPIO.FALLING)
    GPIO.output(ModeInd, GPIO.LOW)
except KeyboardInterrupt:
    GPIO.cleanup()
GPIO.cleanup()
I'm not going to make a video of this because it's quite boring. All that happens is that the correct lights turn on and off as I press the buttons. But it's good enough to consider this to be a successful test of the connections.
The construction of the code itself is going to end up being a bit haphazard. I first want to work on the simple things like recording the input when I press buttons and flashing the right LEDs when I do that. I think I'm going to need to set up a number of functions that activate and deactivate the interrupts at different points during the program so that I don't have code being interrupted by other code when I don't want it to happen. I will also need to learn a thing or two about lists to store the randomly generated sequence and the user input sequence. I may also want to think about using lists to do something with the labeling scheme to simplify it a bit. And I still need to learn how to use pygame to make a nice graphical interface for the game. But these are all projects for another night.

Friday, December 19, 2014

Playing around with Python interrupts

I wanted to spend a little time playing around with the interrupt code a bit to find out what types of boundaries there are. I guess I probably could have read the documentation carefully, but it seemed more interesting to skim it over briefly and just try things to see what would happen.
The first thing I wanted to play with is to work with the channel parameter that was passed in the interrupt sample code. It does turn out that it's passing the number of the pin along, which means that a single callback function can be used to identify multiple pins. This allowed me to simplify the last example.
import RPi.GPIO as GPIO
GPIO.setmode(GPIO.BCM)

GPIO.setup(23, GPIO.IN, pull_up_down=GPIO.PUD_UP)
GPIO.setup(17, GPIO.IN, pull_up_down=GPIO.PUD_UP)

GPIO.setup(24, GPIO.IN, pull_up_down=GPIO.PUD_DOWN)

def my_callback(channel):
    print "falling edge detected on", channel

GPIO.add_event_detect(17, GPIO.FALLING, callback=my_callback, bouncetime=300)
GPIO.add_event_detect(23, GPIO.FALLING, callback=my_callback, bouncetime=300)

try:
    GPIO.wait_for_edge(24, GPIO.RISING)
except KeyboardInterrupt:
    GPIO.cleanup()
GPIO.cleanup()
As I was skimming the documentation, I noticed that there was also a GPIO.BOTH to detect both rising and falling voltage. So of course I was going to try it. The issue I quickly discovered is that there was no parameter being passed to indicate whether it was a rising edge or a falling edge. However, a quick internet search came up with another tutorial for dealing with GPIO.BOTH.
I decided that things were getting a bit confusing with having a mixture of pull-up and pull-down resistors, so I decided I'd just start from scratch and build things in a way that makes sense to me. In my mind, pressing a button down should correspond to a falling edge. This meant I needed to have the pins set as a pull-up, and that the buttons should connect to ground when pressed. I also made it so that connecting the loose wires would lead to the end of the program.
import RPi.GPIO as GPIO
GPIO.setmode(GPIO.BCM)

# Two buttons connected to ground when pressed
GPIO.setup(23, GPIO.IN, pull_up_down=GPIO.PUD_UP)
GPIO.setup(24, GPIO.IN, pull_up_down=GPIO.PUD_UP)

# Loose wires connected to ground when touched
GPIO.setup(22, GPIO.IN, pull_up_down=GPIO.PUD_UP)

def button_change(channel):
    if GPIO.input(channel) == 1:
        print "Button on pin", channel, "was released"
    else:
        print "Button on pin", channel, "was pressed"

GPIO.add_event_detect(23, GPIO.BOTH, callback=button_change)
GPIO.add_event_detect(24, GPIO.BOTH, callback=button_change)

try:
    GPIO.wait_for_edge(22, GPIO.FALLING)
except KeyboardInterrupt:
    GPIO.cleanup()
GPIO.cleanup()
By swapping GPIO.BOTH for either GPIO.RISING or GPIO.FALLING I was able to confirm that I had everything set up the way I wanted. However, in the process I discovered more artifacts about the physical nature of the project. Sometimes, even if the event was set to trigger on GPIO.FALLING I would get some "button released" feedback and sometimes I would get multiple presses registered.
The multiple presses was a result of the bounce effect, and was resolved by adding in a bounce time delay. I set it to 200ms because I like the idea of two tenths of a second more than I like the idea of three tenths of a second. (That's probably an even divisibility thing. I would probably need to get some more sophisticated meters to determine the actual bounce times.) But I'm not entirely sure how to resolve the other issue. It might require a physical solution, like shoving a capacitor across the pins of the button like in the tutorial. But since I don't have any capacitors, I wasn't able to try that out.
I've reached a point where I think I've somewhat maxed out what I can do with these buttons in isolation. I can read button presses and turn LEDs on and off. So I think it's time for me to engage in slightly larger projects. The Dummies book has some instructions for making a Simon-like game (memory game), which seems like an interesting project. But I'm going to try to do it without using the book. I think it would be better for me to go through the practice of thinking through the logic and learning to code in Python on my own and not just copy code that already exists. And maybe I'll learn some PyGame (a graphics engine for Python) in the process.
I'll have to spend some time thinking about how exactly I would want to put that project together. I'm going to be traveling again soon, so I'll probably start with the programming portion and work my way back to the buttons and LEDs later.

Wednesday, December 17, 2014

Python Interrupts

I went through the RasPi tutorial on Python interrupts tonight. In the process, I learned that the wget command can be used to download stuff from a website, but that's a moderately uninteresting side bar.
The whole point of interrupts is to not waste CPU cycles polling the buttons (that is, checking on their status). This creates a much more efficient program in the end, and that's a good thing.
Interestingly, this setup does not require the pull-up or pull-down resistors. My guess is that since it's not looking for an actual high/low state but rather a rising/falling state, the fluctuations are too small to be picked up. It could also be that the program is able to internally mimic the pull-up and pull-down resistors, making the physical resistors obsolete.
The important thing for me to remember is that if I use GPIO.setup(Pin#, GPIO.IN, pull_up_down=GPIO.PUD_UP) then I'm setting the default state to high so that the button needs to connect to ground in order to work.

Since I used wget to download the code, I didn't type it in. I'm going to copy a stripped-down version of the code here so that I at least have a record of it in case the tutorial ever disappears.

import RPi.GPIO as GPIO
GPIO.setmode(GPIO.BCM)

GPIO.setup(23, GPIO.IN, pull_up_down=GPIO.PUD_UP)

print "Waiting for falling edge on port 23"
try:
    GPIO.wait_for_edge(23, GPIO.FALLING)
except KeyboardInterrupt:
    GPIO.cleanup()
GPIO.cleanup()

The important new pieces of code are the GPIO.setup which has the extra command to set it as a pull-up or pull-down pin, GPIO.wait_for_edge which puts Python in a passive waiting mode, and GPIO.cleanup() which is probably the command I was missing in an earlier post when it complained about certain pins already being in use.

The try: command is also new. I tried to read some stuff online, but I'm still not completely sure what this does. I think it just tries to execute something and has an error catcher at the end in case there are problems. Since I don't really know the types of exceptions Python can accept and I don't think it's worth spending a lot of time learning them right now, I'm just going to pick things up as I go. The KeyboardInterrupt catches the control-C command, which I think means if I do things right I can make it impossible to quit by hitting control-C.

The first tutorial is pretty straightforward, so I went on to the second one. The purpose of this one was to create a threaded interrupt. This means to use the interrupt to interrupt something else. The buttons are set differently this time, just for demonstration purposes. Here's the basic code:

import RPi.GPIO as GPIO
GPIO.setmode(GPIO.BCM)

GPIO.setup(23, GPIO.IN, pull_up_down=GPIO.PUD_UP)
GPIO.setup(24, GPIO.IN, pull_up_down=GPIO.PUD_DOWN)

def my_callback(channel):
    print "Rising edge detected on port 24 - even though, in the main thread,"

GPIO.add_event_detect(24, GPIO.RISING, callback=my_callback)

try:
    GPIO.wait_for_edge(23, GPIO.FALLING)
except KeyboardInterrupt:
    GPIO.cleanup()       # clean up GPIO on CTRL+C exit
GPIO.cleanup()           # clean up GPIO on normal exit

This one has the command GPIO.add_event_detect() command. All it seems to say is that it's going to look for pin 24 to rise and when it happens it will call the function my_callback.

The function my_callback is the first user-defined function that I've bumped into so far. I'm not sure why it's set up as my_callback(channel). The "channel" might be the pin number. I'll try to remember to look into that next time I play with this.

The basic idea of this code is that it's waiting for the Pin 23 button to be pressed, but pressing the Pin 24 button will cause the program to jump out of that waiting and do something else.

There's another page to the tutorial where another interrupt event is added. My breadboard ran out of room, so I had to improvise a button out of two loose wires. This is just a reminder that I need to get myself a bigger breadboard soon.

import RPi.GPIO as GPIO
GPIO.setmode(GPIO.BCM)

GPIO.setup(23, GPIO.IN, pull_up_down=GPIO.PUD_UP)
GPIO.setup(17, GPIO.IN, pull_up_down=GPIO.PUD_UP)

GPIO.setup(24, GPIO.IN, pull_up_down=GPIO.PUD_DOWN)

def my_callback(channel):
    print "falling edge detected on 17"

def my_callback2(channel):
    print "falling edge detected on 23"

GPIO.add_event_detect(17, GPIO.FALLING, callback=my_callback, bouncetime=300)
GPIO.add_event_detect(23, GPIO.FALLING, callback=my_callback2, bouncetime=300)

try:
    GPIO.wait_for_edge(24, GPIO.RISING)

except KeyboardInterrupt:
    GPIO.cleanup()       # clean up GPIO on CTRL+C exit
GPIO.cleanup()           # clean up GPIO on normal exit

There's a bouncetime command that was added to the GPIO.add_event_detect() function. It looks like this feature was added between the time that the second and third pages were written. There's a physical "bounce" when the button is pressed due to the flexing of the metal, and this can cause fluctuations in the voltage that could potentially be picked up as other button pushes. The bouncetime command tells Python to ignore all fluctuations for a certain period of time after the initial detection, and this avoids that bouncing.

What's interesting to me about the code is that there are two different functions that are defined. Next time, I'm going to play around to see if I can get that callback to happen in a single function by using an if-then or something like that. But for now, this is all I've got for the night.

Monday, December 15, 2014

Button input with Python

My project for the evening was rather simple. I just wanted to get the button input to work in a useful way using Python. The button wiring was the same as before. Just a 10k resistor and connecting to the voltage supply and the GPIO pin. This time, I used pin 24 instead of pin 23. Here's the basic code:

import RPi.GPIO as GPIO
import time

GPIO.setmode(GPIO.BCM)
GPIO.setup(24,GPIO.IN)

count = 0

while True:
    inputValue = GPIO.input(24)
    if(inputValue == True):
        count = count + 1
        print("Button pressed " + str(count) + " times.")
    time.sleep(.01)

The basic issue with this code is that it doesn't count very accurately. If you hold the button down, it keeps counting it every time it loops. The Getting Started book suggests using a .3 second pause to avoid that, but I don't like that solution. I want to make sure that the button knows when it's being held down and when it has been released. This was simple enough:

import RPi.GPIO as GPIO
import time

GPIO.setmode(GPIO.BCM)
GPIO.setup(24,GPIO.IN)

count = 0

while True:
    inputValue = GPIO.input(24)
    if(inputValue == True):
        count = count + 1
        print("Button pressed " + str(count) + " times.")
        ReinputValue = GPIO.input(24)
        while(ReinputValue == True):
            print("Button is still down.")
            time.sleep(.01)
            ReinputValue = GPIO.input(24)
        print("Button released. Total button pushes: " + str(count))
    time.sleep(.01)

Browsing around a bit aimlessly, I stumbled on an article about using interrupts: How to use interrupts with Python. This scheme basically takes the looping code out of the program and makes it more efficient because it won't be asking whether the button is up or down all the time. The idea of the interrupt is that it isn't going to think about the button until the button is pressed. I'm thinking of it like a doorbell. You only respond to the doorbell when it has been pushed, not when it's not being pushed. I'm going to have to read up on it before I try to run it.

And that's all I'm going to do tonight.

Saturday, December 13, 2014

Python and the 2-bit counter

After a brief hiatus, I'm back to tinkering. I want to interact with the pins using Python.
The Getting Started book gives a brief set of commands to test whether all the modules are installed properly:
  • sudo python: This runs Python in the command line.
  • import RPi.GPIO as GPIO: This tells Python to import the module that runs the pins. An error means something is wrong.

Since everything was working so far, I was able to proceed directly to trying out the commands to turn the LED on.

  • GPIO.setmode(GPIO.BCM): There are different ways to refer to the pins using Python. There's a numbering based on the physical layout (GPIO.BOARD) and then there's the numbering based on the labels that have been designated and the same ones that were used earlier (GPIO.BOARD).
  • GPIO.setup(25,GPIO.OUT): Set pin 25 as an out.
  • GPIO.output(25,GPIO.HIGH): LED on. (It worked!)
  • GPIO.output(25,GPIO.LOW): LED off. (It also worked!)

So everything was ready to go, and I could start into programming. The Getting Started book uses VNC to get access to the graphical interface to create the files, but I wanted to use terminal method just because I feel that I should be able to make text documents through the terminal. I decided to use the Nano editor.

The code was pretty straightforward. It used the time module in Python to allow a sleep function to be called (which just pauses the program for a set period of time -- time.sleep(# of seconds)), and then flipped back and forth between the two settings using the commands above.

import RPi.GPIO as GPIO
import time

GPIO.setmode(GPIO.BCM)
GPIO.setup(25,GPIO.OUT)

while True:
    GPIO.output(25, GPIO.HIGH)
    time.sleep(1)
    GPIO.output(25, GPIO.LOW)
    time.sleep(1)

This is all simple enough. I did get an error, but it looks like it's a pretty innocuous one:

blink.py:5: RuntimeWarning: This channel is already in use, continuing anyway.  Use GPIO.setwarnings(False) to disable warnings.
  GPIO.setup(25,GPIO.OUT)
I think this just means that I had already run GPIO.setup(25,GPIO.OUT) before. It probably means that I'll need to learn how to un-set the pins at some point.

I decided I would plug in another LED and make a binary counter that could count up to 3. One thing I discovered is that the amount of space on the breadboard is not enough to do anything too complex, so I'm probably going to need to make a run to Fry's and pick up a bigger breadboard. But this was big enough for a two bit counter. Here is the code:

import RPi.GPIO as GPIO
import time

GPIO.setmode(GPIO.BCM)
GPIO.setup(25,GPIO.OUT)
GPIO.setup(24,GPIO.OUT)

while True:
    GPIO.output(24, GPIO.LOW)
    GPIO.output(25, GPIO.LOW)
    time.sleep(1)
    GPIO.output(24, GPIO.HIGH)
    time.sleep(1)
    GPIO.output(24, GPIO.LOW)
    GPIO.output(25, GPIO.HIGH)
    time.sleep(1)
    GPIO.output(24, GPIO.HIGH)
    time.sleep(1)

This felt like a good stopping place. Next time I'm going to try to read a button as an input using Python.

Saturday, December 6, 2014

I made the pins dance

First of all, my problems last time were because the ribbon was backwards. With the ribbon in the correct position, everything worked properly and the LED lit up when I wanted it to.
The second half of this exercise is to read values of the pins. The kit came with a button, and I did my best to connect the button properly. There are four leads which stick out of the left and right sides, and when arranged in this way it straddles the middle of the breadboard perfectly. The two leads on the top are always connected, the two leads on the bottom are always connected, and pushing the button connects them all together.
The top left lead was connected to the ground pin using a 10k resistor that also came with the kit. I actually pulled out a different resistor at first, and it took a quick Google search to understand the colored band system for labeling them. (The other one was only a 220 resistor.) The top right was connected to GPIO23. The bottom left was connected to the 3.3V pin.
Setting up the pin to read input followed a similar form as making the pin an output.
  • echo 23 > /sys/class/gpio/export
  • cd /sys/class/gpio/gpio23
  • echo in > direction: This is what sets the pin to an input
  • cat value: This gives the value of the pin. It will either be 1 (high) or 0 (low).

Unfortunately, I was getting erratic results. Sometimes it was a 0, sometimes it was a 1, and it didn't really seem to matter whether the button was pressed or not. Both books warned that this could happen. It has to do with the pin being a "floating pin" when it's not connected properly. I'm still not quite sure about the physics behind this, but it looks like it has to do with small random currents creating a large enough voltage difference because of high resistance. Since V = IR, large R causes large voltages even for small currents. The resolution to the problem is to stick the 10k resistor between the GPIO and the ground, which sets the "normal" voltage to zero.

But everything was already connected, and I tried double checking the connections with no luck. So I went out and bought a multimeter so that I could test the connections directly. The multimeter is a Southwire 10030S and cost exactly $27 from Lowes after tax. This brings the total cost of this experiment to $123.38.

After getting back home and poking around a while, I found that the button wasn't making good contact, so I pulled it out and put it back in. I don't know why this didn't work before, but this time it did. Now the reading was 0 when the button was up and 1 when the button was down.

My next task will be to use Python to read the pins. It's probably not going to happen for at least a week, as next week is very busy.

Wednesday, December 3, 2014

All I want is to make that LED turn on!

I pulled out the ribbon cable and other pieces today to start playing with the GPIO pins. One would think that connecting a few wires isn't complicated. And it isn't. But I still somehow managed to get things wrong.
The first thing I've got wrong is that I don't have a multimeter. I started playing with this at around 8:45 PM, so I didn't have time to go out and buy one. I'll have to do that sometime in the next couple days.
But I went ahead and started connecting things anyway. My first task was to seat the ribbon cable connector (that came with the kit) into the breadboard. This took about 5 minutes to do even though it seems like it should take about 5 seconds. I spent a lot of time pushing on parts of it and thinking that I was going to break it. On the one hand, I've seen how some people have handled circuit boards and such, and so I know that they're at least somewhat robust. On the other hand, I'm not one of those people. I haven't handled these very much, so I don't really know what types of stresses they can take. Another issue I had was that it seemed to rock back and forth where the pins would go down on one side while coming up on the other side.
My next issue came with trying to connect the connector to the Pi with the ribbon cable. The connector has a notch on it to tell me which way the ribbon cable should go. But on the Pi side, it's just pins. That meant that I didn't really know which way to connect it. What's worse is that I can't see any of the internal circuitry to trace back and forth between the labeling and the physical locations of everything. I looked around on the internet for something that would help, but failed (even though I feel like I should have been able to succeed at that). So after a while, I just picked an orientation and connected it. (I've got a 50% chance, right?)
Someone who knows what's going on will instantly know whether this is right or wrong. But I'm not such a person. So I just kept going forward.
The next step was to wire up the LED. The instructions in both the Getting Started book and the Dummies book assume that you're connecting directly to the pins on the Pi (or that you've built your own ribbon connector). It was at this time that I discovered that there is a significant change in the configuration. The books were written for a Pi that has a 26 pin GPIO. The B+ has a 40 pin GPIO. I had no idea what this meant for the labeling of the pins. But after a bit of internet browsing, it seems that the first 26 pins are still pretty much the same, so that if I just stuck to that side for now I probably won't get myself into any trouble. It took a little bit of reasoning, but I eventually wired up an LED to GPIO25.
And yes, I'm aware that there's a pointless connection there. I fixed it later, but didn't bother taking another picture.
From here, it was time to boot up the Pi. I logged in and went through the various commands:
  • sudo su: This logs me in as the root so I have the access I need.
  • echo 25 > /sys/class/gpio/export: This is what creates the virtual files that controls the pin.
  • cd /sys/class/gpio/gpio25/: Change directories to the one that controls the pin.
  • echo out > direction: This tells the Pi I want to use the pin as an output.
  • echo 1 > value: This turns the pin on.

Unfortunately, the LED did not come on. I turned the LED around in case I had it backwards (LEDs are polarized, which means that they only work in one direction). And nothing happened.

The next thing I needed to do was turn the ribbon cable around on the Pi side and see if that's the problem. It was at that time that I discovered I had just spent an hour trying to get an LED to turn on, and decided to stop playing around with it and just type up my entry for the night. Just as a note to myself, after I typed this up, I turned the ribbon cable around so that next time I can just power it up and go from there. And upon staring at it for a moment, it seems like they probably would not have designed it so that the ribbon cable stretches across the entire motherboard. At least, that seems like it would have been a reasonable way to look at it.

Monday, December 1, 2014

A successful headless Pi

Tonight's project was simple. I wanted to connect remotely to the Pi from my laptop, just to ensure that I'm able to set it up correctly. I turned on the Pi and waited a couple minutes, then used Putty to SSH into the computer. That worked without any issues.
The next step was to get the VNC server running. The command for this was vncserver :0 -geometry 1920x1080 -depth 24. I also ran it using vncserver :0 -geometry 1280x720 -depth 24. I don't know what resolution I prefer better. Logging in from the laptop using VNC also had no issues, so that's that. I'm able to run both the command line and X11 remotely. This was much easier than I thought it would be.
Since that was so quick, I decided I would play around a little bit. I looked for a game to play using sudo apt-cache search game and downloaded a game called "Pathological" using sudo apt-get install pathological. I played for about 15 minutes and stopped. It's not that the game was boring or that difficult (at least in the first several levels), I just wanted to get on to do something else. Now that I know this works, I'm going to move the Pi over to my office and connect up the ribbon cable to the bread board and play with some LEDs. But I'll do that another night.