Hi Ian,
great start, almost there! Am 05.05.2013 um 10:12 schrieb Ian McMahon <[email protected]>: > I started a repository of test code here: > > https://bitbucket.org/imcmahon/beagleboneblack-gpio_driver > > The complexity that I see in this is that, from a user's point of view, you > have pins on expansion headers, but from the system's point of view, there > are GPIO ports with pins inside them, and control module registers to > control pinmuxing, etc. > > I created a spreadsheet that maps the header/pin to the mode0 name of that > pin, and then to the control register offset: > > https://docs.google.com/spreadsheet/ccc?key=0AuCI6qJwolM-dENsdWtzZ21GakwxRXdqanZUeklOZHc&usp=sharing > > > The code I have so far defines a couple of structs: > > one is a gpio_port struct which contains pointers to the mmaped gpio > port memory for a given port (GPIO0, GPIO1, etc), and a couple of choice > register pointers within. > > the other is a gpio_pin struct, which contains a gpio_port pointer > (which gpio port does this pin live in?), a pin_num (which bit number of the > port am I?), and a control_offset (where do I go to set up my pinmuxing?) > > Then, I have a configure_pin function: > > /* > configures pin direction and pullup enable and direction > > oe_reg - address of the (mmap'd) GPIO_OE register for the port the pin > we're looking to set up is in. > > valid values for mode are: > O - output > I - input, no pullu/d > U - input, pullup enabled > D - input, pulldown enabled > */ > void configure_pin(bb_gpio_pin *pin, char mode); > > > Those are the four modes that seem like they'd be useful. > > I have a vision of user-configuring the driver with a pair of nasty 46-char > strings which represent each P8/P9 header and what you want each pin in that > header to be: > > "----OOOOUUUUUUDDDOOOOOIII".... etc > > I don't love that idea, but I have yet to think of anything better. that's going to cause a lot of character counting with likely errors what about this syntax (using completely random numbers) hal_gpio out=p8-1,p9-42 in=p8.2,p9.43 inpd=p8.3,p8.23 inpu=p9.4,p9.47 or hal_gpio p8-out=1,42 p8-in=2,43 p9-inpd=3,23 p9-inpu=4,47 maybe this driver should have an exclusion map, to default to the stepgen pin usage, with an override capability: assuming the PRU stepgen isnt used so p8.43 and p8.44 would be free for gpio; in the stepgen those would be X Step/X Dir; so disable the builtin exclusion map like so: hal_gpio exclude= out=p8.43,p8.44 (just pulling two pins used by the PRU stepgen, see http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=commitdiff;h=fde5606226ba14d0b033ba6b2310d2c58a296284) +// R3 lcd_data2 5 pru1.r30.2 P8.43 GPIO2_8 X Step +// 6 pru1.r31.2 +// R4 lcd_data3 5 pru1.r30.3 P8.44 GPIO2_9 X Dir +// 6 pru1.r31.3 - Michael > > > It's a start... onward and upward! > Ian > > > ------------------------------------------------------------------------------ > Get 100% visibility into Java/.NET code with AppDynamics Lite > It's a free troubleshooting tool designed for production > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap2 > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
