RPi.GPIO python module for Pine A64/A64+
#41
Sorry...  

... you will need to either code for an internal pull-up,  or use an external pull-up resistor.

How are you providing '1' or '0' to the pin(3)  GPIO02 ?

Here is the code I use for my test push_button() :

I'm using BCM numbering  pin(35)   GPIO19



Code:
import RPi.GPIO as GPIO
GPIO.setmode(GPIO.BCM)
p_switch = 19
GPIO.setup(p_switch, GPIO.IN, pull_up_down=GPIO.PUD_UP)


def push_button():
   if GPIO.input(p_switch):
       return False
   else:
       return True


This code works and is tested using debian image, and RPi.GPIO-Pine64 from github

With the pin open (internal pull-up as coded) push_button() returns False... else if the pin is grounded, push_button() returns True.


PS, you'll notice the push_button() is coded back-wards... because I want the push_button() to be a positive thing if pressed, but, if pressed its actually grounding the pin with the pull-up on it... Smile
marcushh777    Cool

please join us for a chat @  irc.pine64.xyz:6667   or ssl  irc.pine64.xyz:6697

( I regret that I am not able to respond to personal messages;  let's meet on irc! )
  Reply
#42
Beware that GPIO2/GPIO3 are by default the I2C-1 bus, so it needs to be disabled in DTS to get it back as GPIOs.
  Reply
#43
(08-10-2016, 09:56 AM)martinayotte Wrote: Beware that GPIO2/GPIO3 are by default the I2C-1 bus, so it needs to be disabled in DTS to get it back as GPIOs.

martinayotte's point is well stated,  I try to stay away from the 'special use' pins if possible. The pins on the GPIO layout that are marked in green are safe, as are the pins in this case, marked in blue.  I believe as long as the SPI (blue) and i2c (pink) are not being used they can be utilized as GPIO.  

Please take a look at this layout of the PI bus.
marcushh777    Cool

please join us for a chat @  irc.pine64.xyz:6667   or ssl  irc.pine64.xyz:6697

( I regret that I am not able to respond to personal messages;  let's meet on irc! )
  Reply
#44
I haven't spent a ton of time with RPi.GPIO on the Pine (still holding out for a working port of WiringPi or similar), but is it supporting all I/O pins?

Based on some very minimal use in he midst of working on another project, it seemed like it had the issue that was similar to the one listed in the change log for versions 0.5.11 https://pypi.python.org/pypi/RPi.GPIO. I was using Board mode, and use of Board pins greater than 26 gave me errors. Switching to BCM mode got me where I needed to be. I need to get back to it and do a little more testing, but seems to be similar to the bug noted in the link.

Anyone else experience similar?
  Reply
#45
All GPIO pins are available; BOARD and BCM numbering schemes have been tested, and work.

... that said, I use BCM (Broadcom numbering scheme) because in my development lab I also use the Sparkfun cobbler breakout board (the T board) which lists the GPIO pins by BCM number; in other words, there is no way on the cobbler to know which 'board' number it is.

I have done full projects with BOTH BOARD and BCM numbering, and I have used the PineA64 connection naming scheme to map to GP numbers PL7-->359

Keep in mind, the RPi.GPIO-PineA64 from github is a work in progress; should you find something that does not work correctly (we can help you debug here or on irc) then submit an issue to github and let the author know.
marcushh777    Cool

please join us for a chat @  irc.pine64.xyz:6667   or ssl  irc.pine64.xyz:6697

( I regret that I am not able to respond to personal messages;  let's meet on irc! )
  Reply
#46
The issue I describe is specifically using RPi.GPIO in Board mode. I too use the sparkfun T, and so typically go with BCM, but at the time I was doing ihis with what I was doing, board numbering was much easier.

I just tested again, few lines of python to simply set up some pins via RPi.GPIO, and anything assigning a valid GPIO mode with a (board) pin number greater than 26 tells me "channel sent is invalid". Switch to BCM mode, same physical pins, works fine.

Need to do a bit more digging into it and either find the error of my ways, or confirm as a bug.
  Reply
#47
(08-09-2016, 03:52 PM)MarkHaysHarris777 Wrote:
Code:
import RPi.GPIO as GPIO
GPIO.setmode(GPIO.BCM)
p_switch = 19
GPIO.setup(p_switch, GPIO.IN, pull_up_down=GPIO.PUD_UP)


def push_button():
   if GPIO.input(p_switch):
       return False
   else:
       return True

That worked for GPIO19, 2 and 3 but not GPIO4. That is what I tested so far.
  Reply
#48
(08-10-2016, 03:25 PM)DonFL Wrote: The issue I describe is specifically using RPi.GPIO in Board mode. I too use the sparkfun T, and so typically go with BCM, but at the time I was doing ihis with what I was doing, board numbering was much easier.

I just tested again, few lines of python to simply set up some pins via RPi.GPIO, and anything assigning a valid GPIO mode with a (board) pin number greater than 26 tells me "channel sent is invalid". Switch to BCM mode, same physical pins, works fine.

Need to do a bit more digging into it and either find the error of my ways, or confirm as a bug.

hi DonFL,  I can easily check this again too;  I'll get right back to you...

(08-10-2016, 03:37 PM)Wolfenstein Wrote:
(08-09-2016, 03:52 PM)MarkHaysHarris777 Wrote:
Code:
import RPi.GPIO as GPIO
GPIO.setmode(GPIO.BCM)
p_switch = 19
GPIO.setup(p_switch, GPIO.IN, pull_up_down=GPIO.PUD_UP)


def push_button():
   if GPIO.input(p_switch):
       return False
   else:
       return True

That worked for GPIO19, 2 and 3 but not GPIO4. That is what I tested so far.

Confirmed: GPIO04 does not work as input, nor does it work as output. Time to dive into the code... to find out; and or the datasheet.pdf to see if the GPIO04 (BCM) board pin(7) has a special purpose on the PineA64... which to be compatible with the Raspberry PI it must not have ! GPIO04 is not a dual function pin.

Let's look at the code, and maybe we open an issue on github.
marcushh777    Cool

please join us for a chat @  irc.pine64.xyz:6667   or ssl  irc.pine64.xyz:6697

( I regret that I am not able to respond to personal messages;  let's meet on irc! )
  Reply
#49
@DonFL, confirmed:  

GPIO.setmode(GPIO.BOARD)
GPIO.setup(40, GPIO.OUT)

... will get an error channel not valid on a Raspberry PI.  Either the RPi.GPIO-PineA64 codes were ported from the 26 pin GPIO stuff... or else, this is an over-sight (a bug, for sure).

The work-around (as DonFL has noted) is to code  GPIO.setmode(GPIO.BCM).  then all of the channels may be setup, with the exception that some of the channels (GPIO04) apparently do not work.  Need to dive into the code to find out, because that doesn't make any sense.

Thanks for reporting these issues guys,  and we'll proceed.  Again, the RPi.GPIO-PineA64 codes are a work in progress, and the author notes that they are not complete.  I personally do not use BCM numbers below 12, and I always code for BCM, so my projects so far have run happy as a clam...  

... I can confirm that for output the channels GPIO 20-27 work fine !

PS,  so... tis also probably the time to go through the pin block one by one and get a status check...  what on the pinblock works ?

@Wolfenstein, if you like,  set your GPIO04 to output, and see if it stays ON all the time regardless of setting it OFF.

Update:  never mind.

The GPIO04 pin(7) is not a compatible Raspberry PI bus configuration.  

On the PineA64 pin(7) PL10 is GPIO04,  AND  S_PWM,  GPCLK0   hence, the reason a test LED is lit all the time;  the S_PWM function on this pin will have to be disabled in dts to use this pin as GPIO04 (compatible with the Raspberry PI).

Refer to the Pine_A64_Pin_Assignment_160119.pdf document page 1 for the dual functions of all PineA64 channels; the PI bus is not exactly compatible with the Raspberry PI bus.
marcushh777    Cool

please join us for a chat @  irc.pine64.xyz:6667   or ssl  irc.pine64.xyz:6697

( I regret that I am not able to respond to personal messages;  let's meet on irc! )
  Reply
#50
Quote:On the PineA64 pin(7) PL10 is GPIO04,  AND  S_PWM,  GPCLK0   hence, the reason a test LED is lit all the time


Yes, I've figured that out too... That's mean the the "green" color on pins mapping should be changed ...
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  fm transmitter with gpio weasel18 2 4,752 09-10-2019, 04:28 AM
Last Post: desai_amogh
  How to use dts or other setup to declare gpio pin Interrupt (e.g. a button)? dkebler 1 3,546 06-12-2019, 10:37 AM
Last Post: dkebler
Lightbulb Sample GPIO codes highlighting RPi.GPIO-PineA64 and the PI bus MarkHaysHarris777 6 10,956 06-07-2019, 12:37 AM
Last Post: tllim
Star GPIO, SPI and I2C C++ Lib databit 7 11,043 02-04-2019, 05:45 AM
Last Post: Jeff R
Information Howto: Controlling Pine64 GPIO via the filesystem (sysfs) on linux pfeerick 4 11,755 01-24-2019, 03:36 AM
Last Post: Fifth
  GPIO and SPI SamR1 20 31,160 03-15-2018, 10:32 AM
Last Post: jomoengineer
Question GPIO shockr 7 14,586 03-11-2018, 01:52 AM
Last Post: jomoengineer
  Read GPIO problem shworker 14 20,932 08-17-2017, 01:21 PM
Last Post: martinayotte
  Cross-wired Uart Ports between two Pine Boards via Cat5 Cable MarkHaysHarris777 10 15,728 11-20-2016, 04:17 AM
Last Post: pfeerick
  GPIO fiq capability joseph 3 6,010 11-10-2016, 06:07 PM
Last Post: joseph

Forum Jump:


Users browsing this thread: 2 Guest(s)