Beaglebone & C

I've accessed GPIOs on a BeagleBoard using mmap().  Here's an old Google Groups thread on the topic: https://groups.google.com/forum/#!topic/beagleboard/_29qqEOv2VA

I suspect the Bone is similar, with different addresses.  You will probably have to "sudo" to be able to mmap() the GPIOs directly.  The thread has some other methods that may be easier.

Thanks.  I'll give that a try. I thought about writing direct to the registers, but the chip data sheet only gives the offsets to the registers, I'm still looking for the base address.  With the microcontrollers I'm used to working with if you want to do something to PORTB you just call it PORTB or PORTB,4 to play with bit 4. there's no need to plow through a 4700 page chip manual to find an address you can attach to a symbolic name.  It doesn't look like any of the names for ports are in the C compiler, unless they're in a header file I haven't found yet.  I'll admit I'm a bit rusty, my last serious exposure to unix was System 5 Rev. 4 on Unisys 6000-50's handling 911 call centers.  Yeah, that long ago. :-)

No, C wouldn't know about the device registers for any particular SoC.  There may be header files somewhere, but I don't know where.  A lot of GNU/Linux programmers use a device driver on SBCs like Raspberry Pi and Beagles.  Personally, I prefer mmap() and accessing the registers, but maybe I'm still stuck in the PDP-11 days :-)

Raspberry Pi GPIO is quite well developed and supported, and maybe some of this applies to Beagle: RasPi Hardware Wiki

Realize that is one of the things you give up when going from bare metal to working with an operating system. The OS becomes the gatekeeper between you and the underlying hardware. This is by design. There are concepts that the beagle bone uses where they expose the pins via device drivers. This is how bonescript works underneath. It's been a while since I have looked at it, but I know it's there and with a little research you could probably find it. The next best thing would be to write your own device driver that behaves the way you want it to. There are free documents available on writing linux device drivers, so maybe that is a direction you could go.

I'll try to take a look around this weekend and see if I can find the sources I used when I looked into this earlier.

Good luck, learn and have fun,

Mike

BTW, though, the things you gain by using an OS are incredible as well, you don't have to include your disk IO routines in every program, you don't have to worry about user IO, networking etc. But there are tradeoffs.

Mike

So basically programming a beaglebone in C isn't all that different from writing programs on the old AMD K-7 with Debian on the other side of my room, just a lot smaller.  With Linux being a lot more generic as opposed to a C compiler written for a specific architecture the chip specific stuff will suffer.

There is nothing stopping you from getting to the specific architecture of the chip as far as the compiler goes. You can still get there, that's how they wrote the OS in the first place. I'm just saying that when there is on OS involved you should look at the problem a little differently.

You may not know at any given time what the OS is doing with the underlying hardware. I don't believe you would damage anything, but you could certainly introduce instability and unexpected system lockups.

Take a look at this blog post from shabaz ,a very knowledgeable element14 contributor. It might get you started on your way. This isn't the documentation I mentioned I had found before, it's better.

http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/10/10/bbb--beaglebone-black-io-library-for-c

Hope this is helpful,

Mike

Another good resource

http://derekmolloy.ie/beaglebone/beaglebone-gpio-programming-on-arm-embedded-linux/

Mike

Thanks, it looks like that will save me a year or two of work.  It looks like what I was planning to try to write.

Michael Conners wrote:

 

Realize that is one of the things you give up when going from bare metal to working with an operating system. The OS becomes the gatekeeper between you and the underlying hardware. This is by design. There are concepts that the beagle bone uses where they expose the pins via device drivers.

GPIOs in Linux typically get exposed by the driver under /sys/class/gpio and you can do a lot of things that way including interrupt driven.  There are of course trade-offs, the interface can be slow - certainly much slower than direct register manipulation.  One of the big advantages though is that code you write to use /sys/class/gpio can run on virtually any linux system that has a gpio driver, your code no longer needs to know SoC specific details.

One of the other trade-offs of using linux is that the gpio driver for your SoC will rightly assume that when it's loaded then it owns all of the registers and resources associated with the gpios it's been asked to control.

So when you go behind it's back and do some direct register manipulation you shouldn't be surprised if at some point your code doesn't behave well, it's highly likely to be due to the 'owner' of the registers you're using overwriting what you're trying to do.

Ideally you want to stop the driver touching those registers, but often that's not so easy due to the heavy use of gpios by other things on the board.