pi revision

The revision in /proc/cpuinfo for my board says 000f.
Therefore program leds-wp.py does not work as it looks for nos. from 0002-0006.

I believe that it is rev2. and led-rg.py says it is rev2 (I do not know how it senses it.)

Therefore I should add that to the check in the leds-wp.py program.

The question is :
IS it rev 2 and how do I definitively check?

I should have said that the program does actually work because it sets the board to 2 if it cannot find the correct revision.

It was written to identify Rev 1 boards and "if not Rev 1 treat port 21 as 27", simply because I figured it was more future-proof. At the time, the 000f hadn't come out. I believe wiringpi now has a rev check in the C version, but I don't know if that's filtered through to the Python version.

RPi.GPIO has its own rev checker, but even then the software assumes all future releases will be the same as Rev 2. And if it isn't, I'll change it. Can't really specifically cater for unknown ID numbers.

IS it rev 2 and how do I definitively check?

000f is Rev 2. But there are other hardware ways to tell as well.

Does it have 2 holes near the HDMI port labelled P6? Rev 2.
Does it have 8 holes near the main GPIO ports? Rev 2.

Yes it does. Thanks. That is a lot easier than looking at a file.
But is there a better way than used in the program to tell if it is a rev1,rev2 or any other future rev?

Yes it does. Thanks. That is a lot easier than looking at a file.
But is there a better way than used in the program to tell if it is a rev1,rev2 or any other future rev?

If I knew one, don't you think I would have used it?

Someone already commented on the messiness of the way I'd chosen back in November, so I changed it to be more explicit. The next day, someone else reported that they had a revision # 000f and it failed. So I reverted. The original way was more future-proof. It's all there in the Python software thread.

RPi.GPIO has a variable GPIO.RPI_REVISION (used in the leds-rp.py program)

But as far as I know, that's a shortcut for checking the number from /proc/cpuinfo, but it gives you back 1 or 2 instead of 0001, 0002, 0003, 000f etc.

By the way, when I first got my Rev 2 000f, I used an SD card I'd been using in a Rev 1. cat /proc/cpuinfo didn't recognise it as 000f until I update/upgraded the card. I think it was something to do with the rev numbers not being up to date in the "firmware".

As I already said, I think WiringPi, in it's C version, has a rev checking function*. But I don't know if that is accessible from Python in the WiringPi for Python incarnation. Regrettably there is precious little documentation of it, which is why I've only this week found out how to achieve pullups in wiringpi for python.

Anyway, I'm glad you've been looking at the code, as that's the idea

* I'd almost be willing to put money on it checking /proc/cpuinfo too

Thanks and sorry. I just thought it might ba a bit of old code lashed together when the rev2 came out
which had not been changed.

Thanks and sorry. I just thought it might ba a bit of old code lashed together when the rev2 came out which had not been changed.

No it was new code lashed together when the rev2 came out. There was no need for it before the Rev 2. I believe I got the basis of it from a code snippet posted by Mike Cook (Grumpy Mike) in the Python section. Of course I modified it (as you do).

The rev check is a bit 'ugly', I agree. But it works, and it only applies to one of the many Gertboard programs. None of the others use port 21/27. If you can see a way to tidy it, I'm open to suggestions (as long as they are future-proof).

Code: Select all

def PiRevCheck():               # Function to check for which Pi Board revision we have
    rev_num = ''
    revcheck = open('/proc/cpuinfo')
    cpuinfo = revcheck.readlines()
    revcheck.close()
    print cpuinfo[10][-5:-1]
    rev_num = cpuinfo[10][-5:-1]
    if rev_num == "0002" or rev_num == "0003":
        boardRev = 1
    else:
        boardRev = 2
    return boardRev

Pirev = PiRevCheck()
print Pirev



Not much better, and probably less robust as regards future changes, but have a play. I won't be changing it for this though.

Perhaps better for future Updating
[code]def PiRevCheck(): # Function to check for which Pi Board revision we have

revDict={'0002':1,'0003':2,'0004':2,'0005':2,'0006':2,'000f':2}

revcheck = open('/proc/cpuinfo')
cpuinfo = revcheck.readlines()
revcheck.close()
print cpuinfo[10][-5:-1]
rev_num = cpuinfo[10][-5:-1]
boardRev = revDict[rev_num]
return boardRev

Pirev= PiRevCheck()
print Pirev

Looks like you've messed up your code tags Alan.

Dictionary idea is a good one though. Neatly gets rid of those nasty ifs
Thanks for that. I might stick that in. (Note 0003 is Rev 1 though)
But it will spew out errors if it comes across an unknown rev number, so that needs to be worked around.

What I don't like about the slicing modification I made last night is that there's a possibility that any future system "firmware" changes in /proc/cpuinfo output might make the script dysfunctional, whereas the original would still work regardless of the position in the output. It's ugly, but it's robust.

Even better!
I am new to python but it does seem to have some nice features although I prefere strong typing of C++ or C#

Code: Select all

def PiRevCheck():               # Function to check for which Pi Board revision we have

    revDict={'0002':1,'0003':2,'0004':2,'0005':2,'0006':2,'000f':2}

    revcheck = open('/proc/cpuinfo')
    cpuinfo = revcheck.readlines()
    revcheck.close()
    rev_num = cpuinfo[10][-5:-1]
    boardRev = revDict.get(rev_num,-1)
    return boardRev

Pirev= PiRevCheck()
print Pirev


I like where you're going with this. Still needs future-proofing though (and 0003 is Rev 1).
How will it react if your dictionary call fails?

I don't know C. I've only ever done interpreted languages (apart from a few arduino sketches).
BASIC, REXX, PERL and PYTHON.

In pigpio I return the /proc/cpuinfo revision as a number (hex). The user can then work out the proper gpio assignments.

In pigpio I return the /proc/cpuinfo revision as a number (hex). The user can then work out the proper gpio assignments.

Thanks Joan

I wondered why I hadn't heard of pigpio. You only released it a few days ago

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=37&t=30489&p=265624&hilit=pigpio#p265624

Still needs future-proofing though (and 0003 is Rev 1).

Ah - just spotted the -1. OK so it will cope with "not in dictionary". I'm not overly familiar with python dictionaries. Great - we might have some upgraded code to use. Thanks David.

Think I've cracked it now Alan - unless future changes add a second entry containing "Revision" (after the one we're interested in) to the /proc/cpuinfo output. The bit I had to figure out was how to match "Revision" in a list entry without needing to import any other modules like re (list.index only seems to do complete matches).

Hopefully, by adding that line we now have something robust enough to implement. What do you think? A lot more elegant for sure. (Bit less readable for beginners though).

Code: Select all

matching = [s for s in cpuinfo if "Revision" in s]

Code: Select all

def PiRevCheck():      # Function checks which Pi Board revision we have
    revDict={'0002':1,'0003':1,'0004':2,'0005':2,'0006':2,'000f':2}
    revcheck = open('/proc/cpuinfo')
    cpuinfo = revcheck.readlines()
    revcheck.close()
    matching = [s for s in cpuinfo if "Revision" in s]
    rev_num = str(matching[-1])[-5:-1]
    boardRev = revDict.get(rev_num, -1)
    return boardRev

Pirev = PiRevCheck()
print Pirev

I have two thoughts
1 Even this could break especially if the file is created by humans! I rather think that it is the responsibility of the Raspberry Pi makers to make the different versions computer identifiable if they want the software on it to work.
2 The latest version has become opaque which is not the ethos of Python maybe the following would be more readable

Code: Select all


# Python 2.7 version by Alex Eames of http://RasPi.TV
# functionally equivalent to the Gertboard leds test by Gert Jan van Loo & Myra VanInwegen
# Use at your own risk - I'm pretty sure the code is harmless, but check it yourself.

def PiRevCheck():               # Function to check for which Pi Board revision we have

    # the various ways of identifying the Revision No are stored in a dicttionary
    revDict={'0002':1,'0003':1,'0004':2,'0005':2,'0006':2,'000f':2}

    # the information is stored ina file which is opened, read into a list, and then closed
    revcheck = open('/proc/cpuinfo')
    cpuinfo = revcheck.readlines()
    revcheck.close()
    # look for the line containing the word "Revision" and store the line in matching
    for s in cpuinfo:
        if "Revision" in s :
            matching = s
            break

    # extract the  revision reference which is the last 5 chars omitting CR/LF
    # and make sure it is treated as a string
    rev_num = str(matching[-5:-1])
   
    # try to find it in the dictionary and use -1 if not there
    boardRev = revDict.get(rev_num,-1)
    return boardRev

Pirev= PiRevCheck()
print Pirev


I have two thoughts
1 Even this could break especially if the file is created by humans! I rather think that it is the responsibility of the Raspberry Pi makers to make the different versions computer identifiable if they want the software on it to work.

But they have. That's what the /proc/cpuinfo is all about isn't it? Even wiringpi uses that for Revision ID. It is "the" way. I was just trying to come up with "better" code as what we had was somewhat scrappy.

2 The latest version has become opaque which is not the ethos of Python maybe the following would be more readable

Thanks for the enhancements Alan

I dunno. I think Python has several ethoses/ethi? - one of which is to try and write your whole program on one line.

But because this is aimed at people wanting to learn how to interface, I agree and tend to err on the side of excess commenting. I don't think there's any real harm in including lines people may not fully understand immediately though. It's always good to know there's something more and different ways of doing things.

I've also had a look at the python style guidelines and it seems that mixed case variable names and function names are frowned on. I suppose, where possible, one ought to try to reflect the official way.