From: Gaurav C. <gau...@ns...> - 2013-12-09 10:33:36
|
Hello All, I am using Duovero board (OMAP 44xx, Cortex A-9) with Parlor expansion board. I want to use the GPIO pins as inputs and store the data on filesystem (through C program). Have been through some tutorials, but most of them are related to OMAP3xxx. What I understood is that I can open files e.g. "/sys/class/gpio/gpio122/value" as binary file and read the value. But, I am not getting a clear idea about the following: 1. Format of data to be read. 2. How to configure the pins as Input 3. How many pins I can use to get the input stream of data. 4. How will I maintain the sequence of data from multiple pins. Any quick help is highly appreciated. Thanks in advance. Cheers Gaurav |
From: Conor O'R. <con...@sc...> - 2013-12-09 14:13:31
|
Doing it this way you could bitbanging. The format of data from sysfs is ascii. Ie: it's a "1" not a 1 or even a '1'! You can configure the pins as inputs and outputs either via uboot or via debugfs. I made up a page describing some of that on the wiki (http://wiki.gumstix.org/index.php?title=Duovero_Multiplexes) which I hope will help you. You can use as many pins as you want to as long as they aren't being used already. Eg: I'm testing right now by switching MCSPI1_* on the parlor interface and toggling the lines via GPIO. For an example in C a quick google gave me this: http://stackoverflow.com/questions/11375884/reading-a-port-gpio-value-in-c-beagleboard-xm I suppose realistically you are supposed to use a driver to maintain a sequence at a particular time but you can do direct GPIO register manipulation using /dev/mem (not for faint hearted). There is an example for the Raspberry Pi here: http://elinux.org/RPi_Low-level_peripherals But bear in mind that the register base numbers are likely different. Conor. On Mon, Dec 9, 2013 at 10:33 AM, Gaurav Chaturvedi <gau...@ns...> wrote: > Hello All, > > I am using Duovero board (OMAP 44xx, Cortex A-9) with Parlor expansion > board. I want to use the GPIO pins as inputs and store the data on > filesystem (through C program). Have been through some tutorials, but > most of them are related to OMAP3xxx. > > What I understood is that I can open files e.g. > "/sys/class/gpio/gpio122/value" as binary file and read the value. But, > I am not getting a clear idea about the following: > > 1. Format of data to be read. > 2. How to configure the pins as Input > 3. How many pins I can use to get the input stream of data. > 4. How will I maintain the sequence of data from multiple pins. > > Any quick help is highly appreciated. Thanks in advance. > > Cheers > Gaurav > > > ------------------------------------------------------------------------------ > Sponsored by Intel(R) XDK > Develop, test and display web and hybrid apps with a single code base. > Download it for free now! > http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Gaurav C. <gau...@ns...> - 2013-12-09 16:32:32
|
Hello, Thanks again Conor for the quick information. Yes I already read your wiki page that was pretty useful. Through the wiki/Gumstix list, I have got a link "http://wiki.gumstix.org/index.php?title=User_GPIO_Driver", that provides some driver code to serve as GPIO library. As far as I understood, I can just include these files in my code, add bb files path to bblayers.conf and compile as loadable module and then load module using "insmod". Right? The doubts I have are: 1. "/You can use as many pins as you want to as long as they aren't being used already /" ==> does it mean that I can use all the 40 pins as GPIO pins and configure them as inputs (using the information on "http://wiki.gumstix.org/index.php?title=Duovero_Multiplexes")? 2. If yes, I am confused about maintaining the order of data from multiple pins. OR I need to program the input device to throw data in particular order over the pins (or fix the bits sent to a pin)? And I suppose I need to concatenate all these bits received on pins to make proper bytes, correct? Thanks and regards Gaurav On 09/12/2013 14:13, Conor O'Rourke wrote: > Doing it this way you could bitbanging. The format of data from sysfs > is ascii. Ie: it's a "1" not a 1 or even a '1'! You can configure the > pins as inputs and outputs either via uboot or via debugfs. I made up > a page describing some of that on the wiki > (http://wiki.gumstix.org/index.php?title=Duovero_Multiplexes) which I > hope will help you. You can use as many pins as you want to as long as > they aren't being used already. Eg: I'm testing right now by switching > MCSPI1_* on the parlor interface and toggling the lines via GPIO. For > an example in C a quick google gave me this: > > http://stackoverflow.com/questions/11375884/reading-a-port-gpio-value-in-c-beagleboard-xm > > I suppose realistically you are supposed to use a driver to maintain a > sequence at a particular time but you can do direct GPIO register > manipulation using /dev/mem (not for faint hearted). There is an > example for the Raspberry Pi here: > http://elinux.org/RPi_Low-level_peripherals > > But bear in mind that the register base numbers are likely different. > > Conor. > > On Mon, Dec 9, 2013 at 10:33 AM, Gaurav Chaturvedi > <gau...@ns...> wrote: >> Hello All, >> >> I am using Duovero board (OMAP 44xx, Cortex A-9) with Parlor expansion >> board. I want to use the GPIO pins as inputs and store the data on >> filesystem (through C program). Have been through some tutorials, but >> most of them are related to OMAP3xxx. >> >> What I understood is that I can open files e.g. >> "/sys/class/gpio/gpio122/value" as binary file and read the value. But, >> I am not getting a clear idea about the following: >> >> 1. Format of data to be read. >> 2. How to configure the pins as Input >> 3. How many pins I can use to get the input stream of data. >> 4. How will I maintain the sequence of data from multiple pins. >> >> Any quick help is highly appreciated. Thanks in advance. >> >> Cheers >> Gaurav >> >> >> ------------------------------------------------------------------------------ >> Sponsored by Intel(R) XDK >> Develop, test and display web and hybrid apps with a single code base. >> Download it for free now! >> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > ------------------------------------------------------------------------------ > Sponsored by Intel(R) XDK > Develop, test and display web and hybrid apps with a single code base. > Download it for free now! > http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Scott E. <sc...@ju...> - 2013-12-09 16:45:35
|
Hi Guarav, You cannot use all 40 pins. Some of them like the ADC pins are not attached directly to the OMAP chip and are not available to be remuxed. The power and ground pins cannot be used as GPIO. I doubt you can repurpose SYSEN or PWERON. I haven't looked at what REGEN1 is used for. It might be more useful if you shared more about what you are trying to do and what kind of hardware you are accessing. There might be an another way to go about it. If it does have to be GPIO, then an I2C or SPI attached I/O expander chip is a fairly easy solution. I've used an MCP23017 in several Gumstix projects. -- View this message in context: http://gumstix.8.x6.nabble.com/Duovero-GPIO-GPIO-on-OMAP44xx-Duovero-board-with-Parlor-tp4968392p4968399.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Conor O'R. <con...@sc...> - 2013-12-09 19:20:20
|
On Mon, Dec 9, 2013 at 4:44 PM, Scott Ellis <sc...@ju...> wrote: > Hi Guarav, > > You cannot use all 40 pins. Sorry yes. I overstated that somewhat. I meant "as many as are available for that purpose". I was thinking you might need 8 or 9 :-) > It might be more useful if you shared more about what you are > trying to do and what kind of hardware you are accessing. Sure. I think SPI and I2C are nice solutions that work pretty well. You can use an I/O expander like the PCF8574 or the MCP23017 (which looks better, thanks Scott) Doing parallel with GPIO like you might be trying to do might be more messy but is doable. I use the Raspberry Pi as base to search for these things - they have WiringPi for GPIO. Bear in mind that if you do something like pull a Gumstix pin output-low while an input is trying to drive it high, that may damage things. Which is why I2C is safer! Conor. |
From: Scott E. <sc...@ju...> - 2013-12-09 19:28:30
|
Just a dumb example and you'll have to tweak the Makefile for duovero, but might get you started. https://github.com/scottellis/overo-mcp23017 If you have questions ask. -- View this message in context: http://gumstix.8.x6.nabble.com/Duovero-GPIO-GPIO-on-OMAP44xx-Duovero-board-with-Parlor-tp4968392p4968401.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Gaurav C. <gau...@ns...> - 2013-12-10 09:18:52
|
Hello, Thanks Conor and Scott for the suggestions. Ofcourse they are very helpful, but my current requirement is to experiment connecting a device through GPIO pins (and pin headers on that device) if possible without introducing any extra hardware and then process the high-speed data received. The device is currently connected through USB-host and sending data at around 26MBps continuously. So, I want to eliminate USB altogether for data transfer. I hope it may increase data throughput also. Please suggest if its possible and a simple solution exists. Also, can you please explain "/if you do something like pull a Gumstix pin output-low while an input is trying to drive it high/" a little more. Thanks and regards Gaurav On 09/12/2013 19:27, Scott Ellis wrote: > Just a dumb example and you'll have to tweak the Makefile for duovero, > but might get you started. > > https://github.com/scottellis/overo-mcp23017 > > If you have questions ask. > > > > > -- > View this message in context: http://gumstix.8.x6.nabble.com/Duovero-GPIO-GPIO-on-OMAP44xx-Duovero-board-with-Parlor-tp4968392p4968401.html > Sent from the Gumstix mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > Sponsored by Intel(R) XDK > Develop, test and display web and hybrid apps with a single code base. > Download it for free now! > http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Conor O'R. <con...@sc...> - 2013-12-10 09:50:03
|
> The device is currently connected through USB-host and sending data at > around 26MBps continuously. So, I want to eliminate USB altogether for data > transfer. I hope it may increase data throughput also. Serially? Ouch. I can't be sure you can get that high and be able to do anything else at all. Here's a nice benchmarking link for the Pi that may give you an idea: http://codeandlife.com/2012/07/03/benchmarking-raspberry-pi-gpio-speed/ His maximum square wave output is 14MHz - bear in mind that's doing nothing else. But I intend to run SPI (clocked serial, nothing more) at 10MHz so that is doable using the native hardware. For parallel, I'm not convinced you could sync all the bits perfectly but I haven't tried. Generally I'd prefer to use the ARM external bus for that type of thing. > Please suggest if its possible and a simple solution exists. Sure. SPI :-) > Also, can you please explain "if you do something like pull a Gumstix pin > output-low while an input is trying to drive it high" a little more. Imagine you set a GPIO pin to output and then set it high (1). That pin will be driving 1.8V out on that pin. Imagine then that you connect something to that pin that is actively driving low. Then you've just connected that ARM pin to ground. Not a good thing. Just saying to err on the side of caution when using GPIO pins. Conor. |
From: Gaurav C. <gau...@ns...> - 2013-12-10 10:07:04
|
Thanks Conor. Yes, I think you are right. Serially that throughput cannot be achieved and parallely the syncing of bits is a difficult one to achieve. Since the throughput is a priority at the moment, do you think if I am able to sync the bits successfully, I might be reaching near to the 26 MBps mark or further? Thanks and regards Gaurav On 10/12/2013 09:49, Conor O'Rourke wrote: >> The device is currently connected through USB-host and sending data at >> around 26MBps continuously. So, I want to eliminate USB altogether for data >> transfer. I hope it may increase data throughput also. > Serially? Ouch. I can't be sure you can get that high and be able to > do anything else at all. Here's a nice benchmarking link for the Pi > that may give you an idea: > > http://codeandlife.com/2012/07/03/benchmarking-raspberry-pi-gpio-speed/ > > His maximum square wave output is 14MHz - bear in mind that's doing > nothing else. But I intend to run SPI (clocked serial, nothing more) > at 10MHz so that is doable using the native hardware. > > For parallel, I'm not convinced you could sync all the bits perfectly > but I haven't tried. Generally I'd prefer to use the ARM external bus > for that type of thing. > >> Please suggest if its possible and a simple solution exists. > Sure. SPI :-) > >> Also, can you please explain "if you do something like pull a Gumstix pin >> output-low while an input is trying to drive it high" a little more. > Imagine you set a GPIO pin to output and then set it high (1). That > pin will be driving 1.8V out on that pin. Imagine then that you > connect something to that pin that is actively driving low. Then > you've just connected that ARM pin to ground. Not a good thing. Just > saying to err on the side of caution when using GPIO pins. > > Conor. > > ------------------------------------------------------------------------------ > Sponsored by Intel(R) XDK > Develop, test and display web and hybrid apps with a single code base. > Download it for free now! > http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Conor O'R. <con...@sc...> - 2013-12-10 11:00:59
|
(What I'm saying here is speculative, based on the datasheets I have - I haven't done this on this particular board!) Just not through GPIO. Serially, the datasheet says you can push well about 26MBps through SPI. With low enough load capacitance, it says up to 60MHz. Which is why we were wondering what the device is and what your connection options are. In parallel, 26 MBps over 8 lines at 3.2MHz (+ overhead of syncing with selects and clocks etc). Which doesn't seem horribly onerous if you have direct register access on a 1GHz dual processor! I'm out of my depth here though, I haven't written enough raw GPIO code to judge how best to do that. So I don't want to lead you down the wrong path! Conor. On Tue, Dec 10, 2013 at 10:07 AM, Gaurav Chaturvedi <gau...@ns...> wrote: > Thanks Conor. Yes, I think you are right. Serially that throughput > cannot be achieved and parallely the syncing of bits is a difficult one > to achieve. > Since the throughput is a priority at the moment, do you think if I am > able to sync the bits successfully, I might be reaching near to the 26 > MBps mark or further? > > Thanks and regards > Gaurav > > On 10/12/2013 09:49, Conor O'Rourke wrote: >>> The device is currently connected through USB-host and sending data at >>> around 26MBps continuously. So, I want to eliminate USB altogether for data >>> transfer. I hope it may increase data throughput also. >> Serially? Ouch. I can't be sure you can get that high and be able to >> do anything else at all. Here's a nice benchmarking link for the Pi >> that may give you an idea: >> >> http://codeandlife.com/2012/07/03/benchmarking-raspberry-pi-gpio-speed/ >> >> His maximum square wave output is 14MHz - bear in mind that's doing >> nothing else. But I intend to run SPI (clocked serial, nothing more) >> at 10MHz so that is doable using the native hardware. >> >> For parallel, I'm not convinced you could sync all the bits perfectly >> but I haven't tried. Generally I'd prefer to use the ARM external bus >> for that type of thing. >> >>> Please suggest if its possible and a simple solution exists. >> Sure. SPI :-) >> >>> Also, can you please explain "if you do something like pull a Gumstix pin >>> output-low while an input is trying to drive it high" a little more. >> Imagine you set a GPIO pin to output and then set it high (1). That >> pin will be driving 1.8V out on that pin. Imagine then that you >> connect something to that pin that is actively driving low. Then >> you've just connected that ARM pin to ground. Not a good thing. Just >> saying to err on the side of caution when using GPIO pins. >> >> Conor. >> >> ------------------------------------------------------------------------------ >> Sponsored by Intel(R) XDK >> Develop, test and display web and hybrid apps with a single code base. >> Download it for free now! >> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > ------------------------------------------------------------------------------ > Sponsored by Intel(R) XDK > Develop, test and display web and hybrid apps with a single code base. > Download it for free now! > http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Gaurav C. <gau...@ns...> - 2013-12-10 11:28:20
|
Hi, Thanks again Conor. My requirement is to receive the high-speed data (>= 26 MBps) with 100% data guarantee, as it will be used for some analysis later. As nobody has tried this using GPIO before (atleast on this forum), it will take long time to implement I believe. But still I can try this if time permits. Regarding SPI, do you think it will guarantee that the data will be transmitted without loss (you've already mentioned that speed is enough in last post)? If yes, please guide me further into this without any extra hardware requirement. Thanks and regards Gaurav On 10/12/2013 11:00, Conor O'Rourke wrote: > (What I'm saying here is speculative, based on the datasheets I have - > I haven't done this on this particular board!) > > Just not through GPIO. Serially, the datasheet says you can push well > about 26MBps through SPI. With low enough load capacitance, it says up > to 60MHz. Which is why we were wondering what the device is and what > your connection options are. In parallel, 26 MBps over 8 lines at > 3.2MHz (+ overhead of syncing with selects and clocks etc). Which > doesn't seem horribly onerous if you have direct register access on a > 1GHz dual processor! > > I'm out of my depth here though, I haven't written enough raw GPIO > code to judge how best to do that. So I don't want to lead you down > the wrong path! > > Conor. > > On Tue, Dec 10, 2013 at 10:07 AM, Gaurav Chaturvedi > <gau...@ns...> wrote: >> Thanks Conor. Yes, I think you are right. Serially that throughput >> cannot be achieved and parallely the syncing of bits is a difficult one >> to achieve. >> Since the throughput is a priority at the moment, do you think if I am >> able to sync the bits successfully, I might be reaching near to the 26 >> MBps mark or further? >> >> Thanks and regards >> Gaurav >> >> On 10/12/2013 09:49, Conor O'Rourke wrote: >>>> The device is currently connected through USB-host and sending data at >>>> around 26MBps continuously. So, I want to eliminate USB altogether for data >>>> transfer. I hope it may increase data throughput also. >>> Serially? Ouch. I can't be sure you can get that high and be able to >>> do anything else at all. Here's a nice benchmarking link for the Pi >>> that may give you an idea: >>> >>> http://codeandlife.com/2012/07/03/benchmarking-raspberry-pi-gpio-speed/ >>> >>> His maximum square wave output is 14MHz - bear in mind that's doing >>> nothing else. But I intend to run SPI (clocked serial, nothing more) >>> at 10MHz so that is doable using the native hardware. >>> >>> For parallel, I'm not convinced you could sync all the bits perfectly >>> but I haven't tried. Generally I'd prefer to use the ARM external bus >>> for that type of thing. >>> >>>> Please suggest if its possible and a simple solution exists. >>> Sure. SPI :-) >>> >>>> Also, can you please explain "if you do something like pull a Gumstix pin >>>> output-low while an input is trying to drive it high" a little more. >>> Imagine you set a GPIO pin to output and then set it high (1). That >>> pin will be driving 1.8V out on that pin. Imagine then that you >>> connect something to that pin that is actively driving low. Then >>> you've just connected that ARM pin to ground. Not a good thing. Just >>> saying to err on the side of caution when using GPIO pins. >>> >>> Conor. >>> >>> ------------------------------------------------------------------------------ >>> Sponsored by Intel(R) XDK >>> Develop, test and display web and hybrid apps with a single code base. >>> Download it for free now! >>> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> gumstix-users mailing list >>> gum...@li... >>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> ------------------------------------------------------------------------------ >> Sponsored by Intel(R) XDK >> Develop, test and display web and hybrid apps with a single code base. >> Download it for free now! >> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > ------------------------------------------------------------------------------ > Sponsored by Intel(R) XDK > Develop, test and display web and hybrid apps with a single code base. > Download it for free now! > http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Gaurav C. <gau...@ns...> - 2014-01-13 10:56:46
|
Hi All, Hope you had good vacations. Just a reminder, is there anybody trying the GPIO stuff on duoVero (and others as mentioned in my last few discussions under same topic)? If possible, please share. As per my understanding, there seems to be lot of work required for syncing the bits received on GPIO pins and then concatenating them for proper data in order. I am going top try this sometime later, but please share your thoughts on this. Wish you all a very happy new year 2014. Thanks and regards Gaurav On 10/12/2013 11:28, Gaurav Chaturvedi wrote: > Hi, > > Thanks again Conor. My requirement is to receive the high-speed data (>= > 26 MBps) with 100% data guarantee, as it will be used for some analysis > later. > > As nobody has tried this using GPIO before (atleast on this forum), it > will take long time to implement I believe. But still I can try this if > time permits. > Regarding SPI, do you think it will guarantee that the data will be > transmitted without loss (you've already mentioned that speed is enough > in last post)? If yes, please guide me further into this without any > extra hardware requirement. > > Thanks and regards > Gaurav > > On 10/12/2013 11:00, Conor O'Rourke wrote: >> (What I'm saying here is speculative, based on the datasheets I have - >> I haven't done this on this particular board!) >> >> Just not through GPIO. Serially, the datasheet says you can push well >> about 26MBps through SPI. With low enough load capacitance, it says up >> to 60MHz. Which is why we were wondering what the device is and what >> your connection options are. In parallel, 26 MBps over 8 lines at >> 3.2MHz (+ overhead of syncing with selects and clocks etc). Which >> doesn't seem horribly onerous if you have direct register access on a >> 1GHz dual processor! >> >> I'm out of my depth here though, I haven't written enough raw GPIO >> code to judge how best to do that. So I don't want to lead you down >> the wrong path! >> >> Conor. >> >> On Tue, Dec 10, 2013 at 10:07 AM, Gaurav Chaturvedi >> <gau...@ns...> wrote: >>> Thanks Conor. Yes, I think you are right. Serially that throughput >>> cannot be achieved and parallely the syncing of bits is a difficult one >>> to achieve. >>> Since the throughput is a priority at the moment, do you think if I am >>> able to sync the bits successfully, I might be reaching near to the 26 >>> MBps mark or further? >>> >>> Thanks and regards >>> Gaurav >>> >>> On 10/12/2013 09:49, Conor O'Rourke wrote: >>>>> The device is currently connected through USB-host and sending data at >>>>> around 26MBps continuously. So, I want to eliminate USB altogether for data >>>>> transfer. I hope it may increase data throughput also. >>>> Serially? Ouch. I can't be sure you can get that high and be able to >>>> do anything else at all. Here's a nice benchmarking link for the Pi >>>> that may give you an idea: >>>> >>>> http://codeandlife.com/2012/07/03/benchmarking-raspberry-pi-gpio-speed/ >>>> >>>> His maximum square wave output is 14MHz - bear in mind that's doing >>>> nothing else. But I intend to run SPI (clocked serial, nothing more) >>>> at 10MHz so that is doable using the native hardware. >>>> >>>> For parallel, I'm not convinced you could sync all the bits perfectly >>>> but I haven't tried. Generally I'd prefer to use the ARM external bus >>>> for that type of thing. >>>> >>>>> Please suggest if its possible and a simple solution exists. >>>> Sure. SPI :-) >>>> >>>>> Also, can you please explain "if you do something like pull a Gumstix pin >>>>> output-low while an input is trying to drive it high" a little more. >>>> Imagine you set a GPIO pin to output and then set it high (1). That >>>> pin will be driving 1.8V out on that pin. Imagine then that you >>>> connect something to that pin that is actively driving low. Then >>>> you've just connected that ARM pin to ground. Not a good thing. Just >>>> saying to err on the side of caution when using GPIO pins. >>>> >>>> Conor. >>>> >>>> ------------------------------------------------------------------------------ >>>> Sponsored by Intel(R) XDK >>>> Develop, test and display web and hybrid apps with a single code base. >>>> Download it for free now! >>>> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> gumstix-users mailing list >>>> gum...@li... >>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>> ------------------------------------------------------------------------------ >>> Sponsored by Intel(R) XDK >>> Develop, test and display web and hybrid apps with a single code base. >>> Download it for free now! >>> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> gumstix-users mailing list >>> gum...@li... >>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>> >> ------------------------------------------------------------------------------ >> Sponsored by Intel(R) XDK >> Develop, test and display web and hybrid apps with a single code base. >> Download it for free now! >> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users > > ------------------------------------------------------------------------------ > Sponsored by Intel(R) XDK > Develop, test and display web and hybrid apps with a single code base. > Download it for free now! > http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |