There's a mostly functionally complete bb_gpio driver in the bb-hal-gpio branch:
http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=shortlog;h=refs/heads/bb-hal-gpio It doesn't solve all pin-conflict issues yet, but the good news is it seems to fail in pinmuxing if a pin isn't available. The crash is not very pretty or helpful, but it seems safe enough :) Here's a simple little hal test: ############ loadrt threads name1=test-thread period1=1000000 loadrt hal_bb_gpio user_leds=0,1,2,3 input_pins=212 output_pins=214 loadrt siggen num_chan=1 addf bb_gpio.write test-thread addf bb_gpio.read test-thread addf siggen.0.update test-thread setp siggen.0.frequency 1 net pulse0 bb_gpio.p9.out-14 <= siggen.0.clock net led0 bb_gpio.p9.in-12 => bb_gpio.userled0 ############ This links a 1hz siggen to an output pin, and links an input pin to a userled. If you connect a wire between the output pin and the input pin, the userled will flash with the siggen. Ian On May 5, 2013, at 9:47 PM, Charles Steinkuehler <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 5/5/2013 8:30 PM, Ian McMahon wrote: >> What Michael and I had discussed was using the sysfs mechanism to >> request the pins at driver load, and only "claim" the pins that >> succeed, or fail if a user has asked for pins that we can't claim, >> or something along those lines. It's not going to stop code from >> going behind our back and manipulating registers directly, but we >> just have to assume that we're all playing in the same sandbox. > > This seems like a good approach. > >> What I'm as-yet unsure of is whether we will have a reliable way >> to find out whether the onboard peripherals (emmc, hdmi) are >> driving the pins they're attached to. > > - From what I have read, if a "proper" kernel driver is accessing > specific SoC pins for something (ie: eMMC or HDMI), attempting to map > those ports properly via the kernel (via sysfs or gpio_request() ) > will fail, which is the desired behavior. For instance, there is some > detail in the BBB manual on disabling the HDMI and MMC drivers if you > need access to those I/O pins. > > Of course, this assumes everyone is "playing by the rules". When I > modified the pinmux registers (as root writing directly to the pinmux > physical memory locations) to output all PRU I/O to the physical pins, > my BB instantly hung, as I broke the SD-card interface. But we should > do what we can to "play nice" to avoid such problems, and as a bonus > accessing GPIO via the kernel is essentially identical across most ARM > SoCs, so the allocation and (slow) access routines can be shared among > the BB, Pi, and hopefully whatever else comes along next. > > - -- > Charles Steinkuehler > [email protected] > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (MingW32) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlGHC8QACgkQLywbqEHdNFxRLwCfSn75SEWbRgr3d9ef8sWTSRzC > Q/gAoKkzo+kFiWDjD3GmbQWnz7WnZwcw > =xMl9 > -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
