[beagleboard] Re: Memory Mapped GPIO, has the addressing changed?

[Saleem Ahmad]

Try using
#define GPIO *((volatile unsigned long *)0x44e...)

On Sunday, May 5, 2013 4:47:00 AM UTC+5:30, ky...@cranehome.info wrote:
>
> If been able to find a couple of libraries that deal with GPIO on the 
> BeagleBone.  I have tried to compile and execute them on the BeagleBone 
> Black but have had no success thus far. One library is a C library and 
> tries to set the MUX via the now missing omap_mux file and fails at that 
> point.  It's mimicking the Arduino style DigitalWrite syntax.  The other 
> one is a C++ library that appears to try to access the MUX settings through 
> memory as well. 
>
> Both Libraries seem to have a base address for the GPIO pins as*:*
>
> *#define GPIO0   (0x44E07000)#define GPIO1   (0x4804C000)#define GPIO2   
> (0x481AC000)#define GPIO3   (0x481AE000)* 
>
> The control register base seems to be set as this:
> const unsigned long Beagle_GPIO::GPIO_Control_Module_Registers = 
> 0x44E1;
>
>
> This is the C++ library I found.
> https://github.com/majestik666/Beagle_GPIO/blob/master/Beagle_GPIO.cc
>
> and was able to compile it but had to add: 
> #include 
> to the Beagle_GPIO.hh to cover the use of usleep in several places before 
> it succeeds in building.  Running the test executable however results in:
>
> root@beaglebone:~/downloads/Beagle_GPIO-master# ./Beagle_GPIO_test 
> [GPIO] : Beagle_GPIO::Beagle_GPIO()
> [GPIO] : Opening /dev/mem
> [GPIO] : Beagle GPIO Initialized
> [GPIO] : 
> [GPIO] : BeagleBone GPIO Test
> [GPIO] : 
> [GPIO] : Configuring Pin P8_46 as Output
> Bus error
>
> So the error suggests that something about the addressing is not right. 
>  Has the BBB new processor changed the memory map locations around?
>
> I'm just searching for a way that allows me to use the GPIO pins in a 
> straight-forward way.  I have several C/C++ programs I have been using on 
> the RaspberryPi and wanted to port over to the BeagleBone Black but they 
> need to have access to the GPIO pins.  At present I have no option it seems 
> to move forward with this since file operations on exported pins is not 
> going to cut it for my needs.  
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [beagleboard] Re: Memory Mapped GPIO, has the addressing changed?

[Bo Gao]

Thank you,

I tried and it worked. 

I ran the 
bbb_enable_gpio.sh
  
from 
https://github.com/piranha32/IOoo/blob/master/examples/bbb_enable_gpio.sh
 first.
Then, I  ran the Beagle_GPIO_test compiled from 
https://github.com/majestik666/Beagle_GPIO/blob/master/Beagle_GPIO.cc. 
I could see the Pin P8-46 is changed from 3.3v to 0v.
Hope this will help others who are using or trying to use the mmap to 
configure the pin using C/C++.

Thank you,

Bo


On Wednesday, July 17, 2013 12:19:19 PM UTC-4, Jacek Radzikowski wrote:
>
> Unfortunately enabling setting pinmuxing for GPIOs does not turn on 
> the GPIO modules. The easiest way to enable them is to export one pin 
> from each of the problematic GPIO blocks. You can use the following 
> script: 
> https://github.com/piranha32/IOoo/blob/master/examples/bbb_enable_gpio.sh 
>
> j. 
>
>
> On Wed, Jul 17, 2013 at 5:53 AM,  > 
> wrote: 
> > All 
> > 
> > Has anyone found a solution to this? 
> > 
> > I am mapping /dev/mem and setting the GPIO input / output in a similar 
> > fashion to the referenced example by the OP. 
> > 
> > From dmesg I see 
> > [267773.389824] Unhandled fault: external abort on non-linefetch 
> (0x1018) at 
> > 0xb6f71134 
> > 
> > In a TI forum I came across 
> > http://e2e.ti.com/support/embedded/linux/f/354/t/49197.aspx 
> > 
> > "You need to make sure that the appropriate McSPI functional 
> > (CM_FCLKEN1_CORE)  and interface (CM_ICLKEN1_CORE) clocks are enabled 
> before 
> > reading the McSPI registers." 
> > 
> > Is this solution - especially since I am not using SPI?  What exactly 
> does 
> > it mean? 
> > 
> > Thanks 
> > 
> > Stuart 
> > 
> > 
> > 
> > On Sunday, 5 May 2013 09:17:00 UTC+10, ky...@cranehome.info wrote: 
> >> 
> >> If been able to find a couple of libraries that deal with GPIO on the 
> >> BeagleBone.  I have tried to compile and execute them on the BeagleBone 
> >> Black but have had no success thus far. One library is a C library and 
> tries 
> >> to set the MUX via the now missing omap_mux file and fails at that 
> point. 
> >> It's mimicking the Arduino style DigitalWrite syntax.  The other one is 
> a 
> >> C++ library that appears to try to access the MUX settings through 
> memory as 
> >> well. 
> >> 
> >> Both Libraries seem to have a base address for the GPIO pins as: 
> >> 
> >> #define GPIO0   (0x44E07000) 
> >> #define GPIO1   (0x4804C000) 
> >> #define GPIO2   (0x481AC000) 
> >> #define GPIO3   (0x481AE000) 
> >> 
> >> 
> >> 
> >> The control register base seems to be set as this: 
> >> const unsigned long Beagle_GPIO::GPIO_Control_Module_Registers = 
> >> 0x44E1; 
> >> 
> >> 
> >> This is the C++ library I found. 
> >> https://github.com/majestik666/Beagle_GPIO/blob/master/Beagle_GPIO.cc 
> >> 
> >> and was able to compile it but had to add: 
> >> #include  
> >> to the Beagle_GPIO.hh to cover the use of usleep in several places 
> before 
> >> it succeeds in building.  Running the test executable however results 
> in: 
> >> 
> >> root@beaglebone:~/downloads/Beagle_GPIO-master# ./Beagle_GPIO_test 
> >> [GPIO] : Beagle_GPIO::Beagle_GPIO() 
> >> [GPIO] : Opening /dev/mem 
> >> [GPIO] : Beagle GPIO Initialized 
> >> [GPIO] :  
> >> [GPIO] : BeagleBone GPIO Test 
> >> [GPIO] :  
> >> [GPIO] : Configuring Pin P8_46 as Output 
> >> Bus error 
> >> 
> >> So the error suggests that something about the addressing is not right. 
> >> Has the BBB new processor changed the memory map locations around? 
> >> 
> >> I'm just searching for a way that allows me to use the GPIO pins in a 
> >> straight-forward way.  I have several C/C++ programs I have been using 
> on 
> >> the RaspberryPi and wanted to port over to the BeagleBone Black but 
> they 
> >> need to have access to the GPIO pins.  At present I have no option it 
> seems 
> >> to move forward with this since file operations on exported pins is not 
> >> going to cut it for my needs. 
> > 
> > -- 
> > For more options, visit http://beagleboard.org/discuss 
> > --- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "BeagleBoard" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to beagleboard...@googlegroups.com . 
> > For more options, visit https://groups.google.com/groups/opt_out. 
> > 
> > 
>
>
>
> -- 
> Given a choice between two theories, take the one which is funnier 
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.