Using all 17 available GPIO pins (to build a binary clock)

By the way, I was thinking about the following test: when it's finished, power on the clock from a non-Pi power source and simulate the signals from the Pi. Could this be done with the multimeter? I mean is there some mode on the multimeter (say, the diode test mode?) in which I could connect the negative lead of the multimeter to the pin where the PI's 0V pin is supposed to be and touch the pins which are supposed to be connected to the programmable GPIO pins with the multimeter's positive lead. Would this open the transistors in the ULN2003 ICs and would I see it working just like the signal was coming from the Pi? Perhaps I should use some other mode on the multimeter? Is this possible at all?

If your multimeter has a current range then yes.

A meter generally measures volts, but for current measurement it puts a small resistance in parrallel with the probes and measures the voltage across it that the current causes.
On a high (~2A) range the resistance is going to be quite low. Lower ranges will use progressively higher resistances, so that the same voltage will be produced.

It's instructive to connect two meters together. Put one on a current range, and the other on ohms. See what they each read.
A third set to voltage gives you something else to think about - though most people don't have three

OK, the soldering is done Here are a few images with the result:

The front side looks really neat, with 5 blue LEDs on the top left to show the hours, 6 orange LEDs in the middle right position to show minutes and 6 white LEDs on the bottom left to show seconds The blue and the white LEDs are connected through 390R resistors and the orange ones are connected through 680R resistors, which allow a current of 5mA if the variable resistors are turned to 0. The variable resistors are 10K, so the current can be turned down to less than 0.5 mA. Right now they are turned to 5K for testing. On the very bottom of the board sits the 26-pin IDC connector which will connect to the ribbon cable.









I'm proud of how the front side turned out. It looks really nice. Unfortunately that's not the case with the back side, which is really ugly, but I'll just cover that up, so it won't be visible. The numerous connections had to be made somehow. A custom printed circuit would have looked magnitudes better.



So now I'll test it with a multimeter, as much as I can, to ensure I don't put the Pi in any danger. After that I'll have to come up with a solution for connecting it to the Pi, at least one pin at a time. Too bad I couldn't find a 26-pin ribbon cable or some female-to-female jumper wires in the stores. I'll have to make a few somehow, because waiting for weeks until the real ones arrive from eBay is not a good option.

I could not find a way to make the published images larger or to allow you to click on them to view them at full resolution. Is it possible to do that somehow?

If your multimeter has a current range then yes.

A meter generally measures volts, but for current measurement it puts a small resistance in parrallel with the probes and measures the voltage across it that the current causes.
On a high (~2A) range the resistance is going to be quite low. Lower ranges will use progressively higher resistances, so that the same voltage will be produced.

It's instructive to connect two meters together. Put one on a current range, and the other on ohms. See what they each read.
A third set to voltage gives you something else to think about - though most people don't have three

Thanks Any way to handle it with a single multimeter?

I could not find a way to make the published images larger or to allow you to click on them to view them at full resolution. Is it possible to do that somehow?

Right-click, "View image"

Wow, you are right the board looks great, I even think the back looks pretty good.

OK, the soldering is done Here are a few images with the result:
.......
So now I'll test it with a multimeter, as much as I can, to ensure I don't put the Pi in any danger.

Pre plug in tests with meter
1/ Impedence between 5V and 3V3 and 0V (no shorts)
2/ All 5V pins connected together on GPIO connector
3/ All 3v3 pins connected together on GPIO connector
4/ All 0V pins connected together on GPIO connector
5/ No shorts between other pins on GPIO connector
6/ 5V on GPO connector only connected to 5V points in your circuit
7/ 3V3 on GPO connector only connected to 3V3 points in your circuit
8/ Likewise for 0V

That should be sufficient pre Pi connection testing.

After that I'll have to come up with a solution for connecting it to the Pi, at least one pin at a time. Too bad I couldn't find a 26-pin ribbon cable or some female-to-female jumper wires in the stores. I'll have to make a few somehow, because waiting for weeks until the real ones arrive from eBay is not a good option.

If you have access to old PC cables the old internal printer cables 26Way ribbon to 25 Way D type connectors could be a good source or reusing old rubbish, sorry reusing old cables...

I could not find a way to make the published images larger or to allow you to click on them to view them at full resolution. Is it possible to do that somehow?

Right-click, "View image"

Depends on browser and browser version.

Pre plug in tests with meter
1/ Impedence between 5V and 3V3 and 0V (no shorts)
2/ All 5V pins connected together on GPIO connector
3/ All 3v3 pins connected together on GPIO connector
4/ All 0V pins connected together on GPIO connector
5/ No shorts between other pins on GPIO connector
6/ 5V on GPO connector only connected to 5V points in your circuit
7/ 3V3 on GPO connector only connected to 3V3 points in your circuit
8/ Likewise for 0V

That should be sufficient pre Pi connection testing.

1 - Checked, OK
2,3,4 - I thought there's a single pin for 5V, 3.3V and 0V on the P1 GPIO header of the Pi
5 - Checked, OK
6 - Checked, OK
7 - Checked, OK
8 - Checked, OK

I also checked the following:
9. In diode test mode, with the multimeter's positive needle touching the GPIO 5V pin (on the clock board), if I touch the ULN2003s outpit pins with the multimeter's negative needle, one-by-one, the correct LED lights up and no other LED lights up.
10. If I touch the unused output pins of the ULN2003s, no LED lights up
11. The resistance between the GPIO pins and the corresponding input pins of the ULN2003s is 0.

Seems ready to go Except I don't understand what you meant by 2,3,4.

Thanks!

Seems ready to go Except I don't understand what you meant by 2,3,4.

Thanks!

Plug it in and run this:

Code: Select all

for i in `seq 0 17`; do gpio mode $i out ; done
for i in `seq 0 17`; do gpio write $i 1; done

at this point they should all be on. If they are, then:

Code: Select all

for i in `seq 0 17`; do gpio write $i 0; done

will turn them all off again.

and you're done. (apart from your binary clock code

-Gordon

Hmm, what language is this code written in? I'm planning to use the Java library that can be found at [url]pi4j.com[/url]

Pre plug in tests with meter
..
2/ All 5V pins connected together on GPIO connector
3/ All 3v3 pins connected together on GPIO connector
4/ All 0V pins connected together on GPIO connector
...That should be sufficient pre Pi connection testing.

1 - Checked, OK
2,3,4 - I thought there's a single pin for 5V, 3.3V and 0V on the P1 GPIO header of the Pi
...
Seems ready to go Except I don't understand what you meant by 2,3,4.

Thanks!

If you check the Wiki on GPIO connector
+5V pins 2 and 4
GND pins 6, 9, 14, 20 and 25
3V3 pins 1 and 17

Connecting more than one pin ensures good current flow and grounding, with less possibility of voltage drop in your wiring

Hmm, what language is this code written in? I'm planning to use the Java library that can be found at [url]pi4j.com[/url]

But for the short-term testing I was thinking of a python script. The only problem with that is I did not figure out yet what numbers are used to refer to the GPIO pins internally. Seem not to be the same as the numbers presented here http://pi4j.com/usage.html#Pin_Numbering, which is the same numbering that can be found on Gordon's site too. God only knows why they had to complicate things and use different numbers internally to refer to the pins

If you check the Wiki on GPIO connector
+5V pins 2 and 4
GND pins 6, 9, 14, 20 and 25
3V3 pins 1 and 17

Connecting more than one pin ensures good current flow and grounding, with less possibility of voltage drop in your wiring

Hmm, I did not know that. The pin layout peresnted here http://pi4j.com/usage.html#Pin_Numbering and here https://projects.drogon.net/raspberry-pi/wiringpi/pins/ mentions a lot of those pins as DNC (do not connect!)

Hmm, what language is this code written in? I'm planning to use the Java library that can be found at [url]pi4j.com[/url]

That's just common or garden bash script. ie. the stuff you type at the command-line.The gpio program is part of wiringPi. It lets you do GPIO stuff from the command-line.

https://projects.drogon.net/raspberry-pi/wiringpi/download-and-install/

-Gordon

Hmm, what language is this code written in? I'm planning to use the Java library that can be found at [url]pi4j.com[/url]

But for the short-term testing I was thinking of a python script. The only problem with that is I did not figure out yet what numbers are used to refer to the GPIO pins internally. Seem not to be the same as the numbers presented here http://pi4j.com/usage.html#Pin_Numbering, which is the same numbering that can be found on Gordon's site too. God only knows why they had to complicate things and use different numbers internally to refer to the pins

It's a long story. Trust me on that one. Stick to wiringPi pin numbering and it'll take care of the pin changes between board revisions. (and work in your Java stuff)

And why write a program when you can use the gpio command from the command-line. Bash scripting is goog enough - you can even write games in it...

-Gordon

Yeah, I just found on your page the part about WiringPi I did not know it existed, until now. I'm now looking for some example code and/or documentation to see what it's capable of.

Yeah, I just found on your page the part about WiringPi I did not know it existed, until now. I'm now looking for some example code and/or documentation to see what it's capable of.

And I have found all that I was looking for on your site, Gordon The more I explore your site, the more useful things I find on it. When it comes to the RPI's GPIO, your site and your support in the forum are really valuable and I'm truly grateful for that
And I'm also grateful for the help of the other members. I know I've said this already, but for somebody like me, who's getting started in this area, this help really means a lot (regardless if it's a good article, an answer in the forum or a good "tool" like the WiringPi and the gpio program). Your shared knowledge is truly appreciated. I hope one day I'll too be able to contribute

And I'm also grateful for the help of the other members. I know I've said this already, but for somebody like me, who's getting started in this area, this help really means a lot (regardless if it's a good article, an answer in the forum or a good "tool" like the WiringPi and the gpio program). Your shared knowledge is truly appreciated. I hope one day I'll too be able to contribute

Start a blog. Easy to do. I started as a way to try to avoid keeping a log-book - which hasn't quite worked - I still keep a big pad of squared paper on my desk - something I've done for years and years! But maybe one day, someone will search for a subject and hit your page - which in a tiny way will be your way of giving a little bit back. It all adds up.

I don't really want to keep a 'forum' sort of thing though - the more forums/chats/etc. there are the more "diluted" the knowledge base is (IMO). So I want this forum to keep going to find the main bits, then google, etc. can find the rest!

-Gordon

I actually have thought of starting a blog about my adventures with the RPI, not just with this binary LED clock But there are many other things in my life I'd like to blog about (and usually no time for any of it ), so I'm still thinking whether to create a dedicated RPI blog or to put everything on a general blog. Either way, eventually the binary led clock project will be online in the form of a blog

So, I'm still waiting for the jumper wires to arrive, but in the meantime I've written the code to drive the clock. Taking Gordon's advice, the code is written as a bash script that uses the gpio utility. If it has weird things in it, bear with me, I've learned bash script in the last 24 hours

Code: Select all

#! /bin/bash

echo "Binary Clock v1.0 (2012.11.05.) by Bazso-Dombi Andras"

#Binary buffer consisting of 17 elements
#(5 for hours, 6 for minutes, 6 for seconds)
declare -a binbuf=( 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 )

#Refresh rate constant (in seconds)
declare -r refresh_rate=0.2

#Options
opt_noseconds=false

function parseOptions {
   if [ "$#" -ge 1 ]; then
      for i in "$@"; do
         if [ $i == "-noseconds" ]; then
            opt_noseconds=true
         fi
      done
   fi
}

function initGPIOPins {
   #Initialize all the GPIO ports to output mode
   for i in `seq 0 16`; do gpio mode $i out; done
}

function fillBufferWithCurrentTime {
   #Hours
   hr=`date +%H`
   bitmask=16
   for i in `seq 0 4`; do
      binbuf[$i]=`expr $hr / $bitmask`
      hr=`expr $hr % $bitmask`
      bitmask=`expr $bitmask / 2`
   done

   #Minutes
   min=`date +%M`
   bitmask=32
        for i in `seq 5 10`; do
                binbuf[$i]=`expr $min / $bitmask`
                min=`expr $min % $bitmask`
                bitmask=`expr $bitmask / 2`
        done

   #Seconds
   if [ $opt_noseconds == false ]; then
      sec=`date +%S`
      bitmask=32
           for i in `seq 11 16`; do
                   binbuf[$i]=`expr $sec / $bitmask`
                   sec=`expr $sec % $bitmask`
                   bitmask=`expr $bitmask / 2`
           done
   else
      for i in `seq 11 16`; do binbuf[$i]=0 ; done
   fi
}

function outputBufferToStdOut {
   echo -ne `date +%H:%M:%S`" "

   for i in `seq 0 4`; do echo -ne ${binbuf[$i]} ; done
   echo -ne " "

   for i in `seq 5 10`; do echo -ne ${binbuf[$i]} ; done
        echo -ne " "

   for i in `seq 11 16`; do echo -ne ${binbuf[$i]} ; done
        echo -ne " "

   echo
}

function ouputBufferToGPIO {
        for i in `seq 0 16`; do gpio write $i ${binbuf[$i]} ; done
}


#main starts here
parseOptions "$@"
initGPIOPins

while true; do
   fillBufferWithCurrentTime
   outputBufferToStdOut
        ouputBufferToGPIO
   sleep $refresh_rate
done

Seems to work well, the only problem is that it is kind of slow. As you can see, currently it writes the binary buffer both to the GPIO port and to the standard output. Viewing it over SSH with putty, it outputs a sequence about once per second, which is much below my expectations. I hope that this is only because of the writing to the standard output and as soon as I comment that out and check the results on the LEDs themselves, I'll be able to achieve the targeted refresh rate of 0.2 seconds. I want to refresh the LEDs 5 times per second because if it misses a cycle (because of its own computing time or because of the OS switching processes), the time for a combination being lit up would only decrease from 1 sec to 0.8 sec, which is acceptable.

Plug it in and run this:

Code: Select all

for i in `seq 0 17`; do gpio mode $i out ; done
for i in `seq 0 17`; do gpio write $i 1; done

I just noticed this now... didn't you mean to write 0 to 16? Or, if 0 to 17 is correct, why is it correct?

Plug it in and run this:

Code: Select all

for i in `seq 0 17`; do gpio mode $i out ; done
for i in `seq 0 17`; do gpio write $i 1; done

I just noticed this now... didn't you mean to write 0 to 16? Or, if 0 to 17 is correct, why is it correct?

Just testing to make sure you're awake...

It's a schoolboy error on my part - seq 0 17 returns 0 1 2 ... 17. Too used to programming in C where i'd typically write for (i = 0 ; i < 17 ; ++0) {...}

-Gordon

Just testing to make sure you're awake...

It's a schoolboy error on my part - seq 0 17 returns 0 1 2 ... 17. Too used to programming in C where i'd typically write for (i = 0 ; i < 17 ; ++0) {...}

-Gordon

OK, then 0..16 is correct. My only doubt was whether to use 0..16 or 1..17, but I see in your WiringPi examples too that you always start form 0, which ultimately makes sense since the pins are numbered from 0 up. Thanks!

Just testing to make sure you're awake...

It's a schoolboy error on my part - seq 0 17 returns 0 1 2 ... 17. Too used to programming in C where i'd typically write for (i = 0 ; i < 17 ; ++0) {...}

-Gordon

OK, then 0..16 is correct. My only doubt was whether to use 0..16 or 1..17, but I see in your WiringPi examples too that you always start form 0, which ultimately makes sense since the pins are numbered from 0 up. Thanks!

Since you're learning bash, and finding it slow... You're probably aware that by now almost everything in a separate command executed by the shell, so you can (e.g.) just type in:

seq 0 16

at the prompt and see what it does.

Bash is great for simple scripts - as you've seen, but can be a bit "clunky" at times. I've not looked at your code in-detail though. Personally I'd code your binary clock in C, but you need to use whatever you're most familiar with...

-Gordon

Yes, it has crossed my mind that the slowness could come from the fact that each command is executed separately, but still I find it hard to believe that it's so slow on a 700 MHz processor. I really hope that the writing to the standard output is slowing it down and not the internal workings of it. I'll try redirecting to file, see if that speeds it up.

Luckily for me, C/C++ is what I'm most familiar with I've spent the last 7 years working in C++ 8 hours a day or more I've never compiled C/C++ code under Linux until now, but it can't be that hard So if the bash script can't live up to my performance expectations, C is the next one to try.