From: <ms...@ea...> - 2010-03-20 14:51:58
|
<html><body><span style="font-family:Verdana; color:#000000; font-size:10pt;"><div>One thing I found when using reading/writing to i2c-3 is that the driver shifts the address you give it in the ioctl left by 1. Maybe that's a documented feature, but it caused me a lot of pain. <br><br></div> <blockquote id="replyBlockquote" webmail="1" style="border-left: 2px solid blue; margin-left: 8px; padding-left: 8px; font-size: 10pt; color: black; font-family: verdana;"> <div id="wmQuoteWrapper"> -------- Original Message --------<br> Subject: Re: [Gumstix-users] I2C<br> From: "Erik Rodriguez" <eri...@ce...><br> Date: Sat, March 20, 2010 4:07 am<br> To: "General mailing list for gumstix users."<br> <gum...@li...><br> <br> Thanks, Dave. Any idea when the Overo Fire will be back in stock?<br> <br> Sent while out of the office.<br> <br> On Mar 19, 2010, at 10:37 PM, "Dave Hylands" <dhy...@gm...> wrote:<br> <br> > HI Erik,<br> ><br> > On Fri, Mar 19, 2010 at 10:11 PM, Erik Rodriguez<br> > <eri...@ce...> wrote:<br> >> All,<br> >><br> >> Where do I find the source files needed to compile a program making <br> >> use of<br> >> I2C bus? I have found several versions of i2c-dev.h, and even more <br> >> of the<br> >> files required by that.<br> ><br> > You only need i2c-dev.h.<br> ><br> > The documentation is in the linux Documentation/i2c/dev-interface<br> ><br> > I've written several programs which use the i2c-dev interface. It can<br> > be used for i2c devices which don't otherwise have a linux driver.<br> > The TPS60950 for example, has a dedicated driver, so you can't use<br> > i2c-dev to talk to it.<br> ><br> > -- <br> > Dave Hylands<br> > Shuswap, BC, Canada<br> > <a target="_blank" href="http://www.DaveHylands.com/">http://www.DaveHylands.com/</a><br> ><br> > --- <br> > --- <br> > --- <br> > ---------------------------------------------------------------------<br> > Download Intel&#174; Parallel Studio Eval<br> > Try the new software tools for yourself. Speed compiling, find bugs<br> > proactively, and fine-tune applications for parallel performance.<br> > See why Intel Parallel Studio got high marks during beta.<br> > <a target="_blank" href="http://p.sf.net/sfu/intel-sw-dev">http://p.sf.net/sfu/intel-sw-dev</a><br> > _______________________________________________<br> > gumstix-users mailing list<br> > gum...@li...<br> > <a target="_blank" href="https://lists.sourceforge.net/lists/listinfo/gumstix-users">https://lists.sourceforge.net/lists/listinfo/gumstix-users</a><br> <br> ------------------------------------------------------------------------------<br> Download Intel&#174; Parallel Studio Eval<br> Try the new software tools for yourself. Speed compiling, find bugs<br> proactively, and fine-tune applications for parallel performance.<br> See why Intel Parallel Studio got high marks during beta.<br> <a target="_blank" href="http://p.sf.net/sfu/intel-sw-dev">http://p.sf.net/sfu/intel-sw-dev</a><br> _______________________________________________<br> gumstix-users mailing list<br> gum...@li...<br> <a target="_blank" href="https://lists.sourceforge.net/lists/listinfo/gumstix-users">https://lists.sourceforge.net/lists/listinfo/gumstix-users</a><br> </div> </blockquote></span></body></html> |
From: Dave H. <dhy...@gm...> - 2010-03-20 16:12:03
|
Hi, On Sat, Mar 20, 2010 at 7:51 AM, <ms...@ea...> wrote: > One thing I found when using reading/writing to i2c-3 is that the driver > shifts the address you give it in the ioctl left by 1. Maybe that's a > documented feature, but it caused me a lot of pain. That's because the address is a 7-bit field and occupies the upper 7-bits of the first byte. The bottom bit is a R/W bit. Lots of vendors mash the two things together and call it the address byte, which is where the confusion comes from. They'll further confuse things by saying that there is a read address and a write address, when,in fact, there is a single address with a R/W bit. The authors of the linux driver decided to use the terminology found in the i2c specification. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ |
From: Matt S. <ms...@ea...> - 2010-03-22 11:25:10
|
Thanks for the explanation Dave. Still seems odd as the address that Honeywell states is a +1 for read so it would be that the low order bit is R/W. And that addressing is how I've used it with PICS and with RS232->I2C chips. Regardless, I just hope the info spares others some time and frustration. -----Original Message----- From: Dave Hylands [mailto:dhy...@gm...] Sent: Saturday, March 20, 2010 12:12 PM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] I2C Hi, On Sat, Mar 20, 2010 at 7:51 AM, <ms...@ea...> wrote: > One thing I found when using reading/writing to i2c-3 is that the > driver shifts the address you give it in the ioctl left by 1. Maybe > that's a documented feature, but it caused me a lot of pain. That's because the address is a 7-bit field and occupies the upper 7-bits of the first byte. The bottom bit is a R/W bit. Lots of vendors mash the two things together and call it the address byte, which is where the confusion comes from. They'll further confuse things by saying that there is a read address and a write address, when,in fact, there is a single address with a R/W bit. The authors of the linux driver decided to use the terminology found in the i2c specification. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ ---------------------------------------------------------------------------- -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.791 / Virus Database: 271.1.1/2754 - Release Date: 03/20/10 03:33:00 |
From: <cod...@gm...> - 2010-03-22 13:14:50
|
I've recently been informed that our project will be using IO expansion boards on the i2c bus for our project. Do the GPIO pins on these boards get exposed in sysfs in the same way as the pins coming off the 40-pin header of the summit board? With the pins on the header, they all show up in /sys/class/gpio and I can read/write to them as normal files. With the i2c-connected expansion cards, will I be able to do this as well? e.g., echo XXX > /sys/class/gpio/export && echo 0 > /sys/class/gpio/gpioXXX/value. On Mon, Mar 22, 2010 at 7:25 AM, Matt Singer <ms...@ea...> wrote: > > Thanks for the explanation Dave. Still seems odd as the address that > Honeywell states is a +1 for read so it would be that the low order bit is > R/W. And that addressing is how I've used it with PICS and with RS232->I2C > chips. > > Regardless, I just hope the info spares others some time and frustration. > > > -----Original Message----- > From: Dave Hylands [mailto:dhy...@gm...] > Sent: Saturday, March 20, 2010 12:12 PM > To: General mailing list for gumstix users. > Subject: Re: [Gumstix-users] I2C > > Hi, > > On Sat, Mar 20, 2010 at 7:51 AM, <ms...@ea...> wrote: > > One thing I found when using reading/writing to i2c-3 is that the > > driver shifts the address you give it in the ioctl left by 1. Maybe > > that's a documented feature, but it caused me a lot of pain. > > That's because the address is a 7-bit field and occupies the upper 7-bits > of > the first byte. The bottom bit is a R/W bit. Lots of vendors mash the two > things together and call it the address byte, which is where the confusion > comes from. > > They'll further confuse things by saying that there is a read address and > a > write address, when,in fact, there is a single address with a R/W bit. > > The authors of the linux driver decided to use the terminology found in the > i2c specification. > > -- > Dave Hylands > Shuswap, BC, Canada > http://www.DaveHylands.com/ > > > ---------------------------------------------------------------------------- > -- > Download Intel® Parallel Studio Eval Try the new software tools for > yourself. Speed compiling, find bugs proactively, and fine-tune > applications > for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.791 / Virus Database: 271.1.1/2754 - Release Date: 03/20/10 > 03:33:00 > > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Matt S. <ms...@ea...> - 2010-03-22 13:22:26
|
Yes, if you use one of the chips that are supported by kernel drivers. _____ From: cod...@gm... [mailto:cod...@gm...] Sent: Monday, March 22, 2010 9:15 AM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] I2C I've recently been informed that our project will be using IO expansion boards on the i2c bus for our project. Do the GPIO pins on these boards get exposed in sysfs in the same way as the pins coming off the 40-pin header of the summit board? With the pins on the header, they all show up in /sys/class/gpio and I can read/write to them as normal files. With the i2c-connected expansion cards, will I be able to do this as well? e.g., echo XXX > /sys/class/gpio/export && echo 0 > /sys/class/gpio/gpioXXX/value. On Mon, Mar 22, 2010 at 7:25 AM, Matt Singer <ms...@ea...> wrote: Thanks for the explanation Dave. Still seems odd as the address that Honeywell states is a +1 for read so it would be that the low order bit is R/W. And that addressing is how I've used it with PICS and with RS232->I2C chips. Regardless, I just hope the info spares others some time and frustration. -----Original Message----- From: Dave Hylands [mailto:dhy...@gm...] Sent: Saturday, March 20, 2010 12:12 PM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] I2C Hi, On Sat, Mar 20, 2010 at 7:51 AM, <ms...@ea...> wrote: > One thing I found when using reading/writing to i2c-3 is that the > driver shifts the address you give it in the ioctl left by 1. Maybe > that's a documented feature, but it caused me a lot of pain. That's because the address is a 7-bit field and occupies the upper 7-bits of the first byte. The bottom bit is a R/W bit. Lots of vendors mash the two things together and call it the address byte, which is where the confusion comes from. They'll further confuse things by saying that there is a read address and a write address, when,in fact, there is a single address with a R/W bit. The authors of the linux driver decided to use the terminology found in the i2c specification. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ ---------------------------------------------------------------------------- -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.791 / Virus Database: 271.1.1/2754 - Release Date: 03/20/10 03:33:00 ---------------------------------------------------------------------------- -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.791 / Virus Database: 271.1.1/2754 - Release Date: 03/21/10 15:33:00 |
From: <cod...@gm...> - 2010-03-24 14:03:37
|
How do I determine if the chip is supported by kernel drivers? I'm told we'll be using the MCP23017. This is on Gumstix Overo. The pins we were told to use on the expansion board are GPA# instead of GPIO### (e.g., GPA0 vs. GPIO171). If these are exposed in /sys/class/gpio/GPA# similarly to GPIOs, that would be great. On Mon, Mar 22, 2010 at 9:22 AM, Matt Singer <ms...@ea...> wrote: > > Yes, if you use one of the chips that are supported by kernel drivers. > > > ------------------------------ > *From:* cod...@gm... [mailto:cod...@gm...] > *Sent:* Monday, March 22, 2010 9:15 AM > > *To:* General mailing list for gumstix users. > *Subject:* Re: [Gumstix-users] I2C > > I've recently been informed that our project will be using IO expansion > boards on the i2c bus for our project. Do the GPIO pins on these boards get > exposed in sysfs in the same way as the pins coming off the 40-pin header of > the summit board? With the pins on the header, they all show up in > /sys/class/gpio and I can read/write to them as normal files. > > With the i2c-connected expansion cards, will I be able to do this as well? > e.g., echo XXX > /sys/class/gpio/export && echo 0 > > /sys/class/gpio/gpioXXX/value. > > On Mon, Mar 22, 2010 at 7:25 AM, Matt Singer <ms...@ea...>wrote: > >> >> Thanks for the explanation Dave. Still seems odd as the address that >> Honeywell states is a +1 for read so it would be that the low order bit is >> R/W. And that addressing is how I've used it with PICS and with RS232->I2C >> chips. >> >> Regardless, I just hope the info spares others some time and frustration. >> >> >> -----Original Message----- >> From: Dave Hylands [mailto:dhy...@gm...] >> Sent: Saturday, March 20, 2010 12:12 PM >> To: General mailing list for gumstix users. >> Subject: Re: [Gumstix-users] I2C >> >> Hi, >> >> On Sat, Mar 20, 2010 at 7:51 AM, <ms...@ea...> wrote: >> > One thing I found when using reading/writing to i2c-3 is that the >> > driver shifts the address you give it in the ioctl left by 1. Maybe >> > that's a documented feature, but it caused me a lot of pain. >> >> That's because the address is a 7-bit field and occupies the upper 7-bits >> of >> the first byte. The bottom bit is a R/W bit. Lots of vendors mash the two >> things together and call it the address byte, which is where the confusion >> comes from. >> >> They'll further confuse things by saying that there is a read address and >> a >> write address, when,in fact, there is a single address with a R/W bit. >> >> The authors of the linux driver decided to use the terminology found in >> the >> i2c specification. >> >> -- >> Dave Hylands >> Shuswap, BC, Canada >> http://www.DaveHylands.com/ >> >> >> ---------------------------------------------------------------------------- >> -- >> Download Intel® Parallel Studio Eval Try the new software tools for >> yourself. Speed compiling, find bugs proactively, and fine-tune >> applications >> for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> No virus found in this incoming message. >> Checked by AVG - www.avg.com >> Version: 9.0.791 / Virus Database: 271.1.1/2754 - Release Date: 03/20/10 >> 03:33:00 >> >> >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.791 / Virus Database: 271.1.1/2754 - Release Date: 03/21/10 > 15:33:00 > > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > |
From: Matt S. <ms...@ea...> - 2010-03-24 14:19:34
|
Look in the kernel source.... drivers/gpio/Kconfig MAX7300 MAX732X PCA953X PCF857X ADP5588 So looks like you have to write a new driver for that Microchip part. _____ From: cod...@gm... [mailto:cod...@gm...] Sent: Wednesday, March 24, 2010 10:03 AM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] I2C How do I determine if the chip is supported by kernel drivers? I'm told we'll be using the MCP23017. This is on Gumstix Overo. The pins we were told to use on the expansion board are GPA# instead of GPIO### (e.g., GPA0 vs. GPIO171). If these are exposed in /sys/class/gpio/GPA# similarly to GPIOs, that would be great. On Mon, Mar 22, 2010 at 9:22 AM, Matt Singer <ms...@ea...> wrote: Yes, if you use one of the chips that are supported by kernel drivers. _____ From: cod...@gm... [mailto:cod...@gm...] Sent: Monday, March 22, 2010 9:15 AM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] I2C I've recently been informed that our project will be using IO expansion boards on the i2c bus for our project. Do the GPIO pins on these boards get exposed in sysfs in the same way as the pins coming off the 40-pin header of the summit board? With the pins on the header, they all show up in /sys/class/gpio and I can read/write to them as normal files. With the i2c-connected expansion cards, will I be able to do this as well? e.g., echo XXX > /sys/class/gpio/export && echo 0 > /sys/class/gpio/gpioXXX/value. On Mon, Mar 22, 2010 at 7:25 AM, Matt Singer <ms...@ea...> wrote: Thanks for the explanation Dave. Still seems odd as the address that Honeywell states is a +1 for read so it would be that the low order bit is R/W. And that addressing is how I've used it with PICS and with RS232->I2C chips. Regardless, I just hope the info spares others some time and frustration. -----Original Message----- From: Dave Hylands [mailto:dhy...@gm...] Sent: Saturday, March 20, 2010 12:12 PM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] I2C Hi, On Sat, Mar 20, 2010 at 7:51 AM, <ms...@ea...> wrote: > One thing I found when using reading/writing to i2c-3 is that the > driver shifts the address you give it in the ioctl left by 1. Maybe > that's a documented feature, but it caused me a lot of pain. That's because the address is a 7-bit field and occupies the upper 7-bits of the first byte. The bottom bit is a R/W bit. Lots of vendors mash the two things together and call it the address byte, which is where the confusion comes from. They'll further confuse things by saying that there is a read address and a write address, when,in fact, there is a single address with a R/W bit. The authors of the linux driver decided to use the terminology found in the i2c specification. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ ---------------------------------------------------------------------------- -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.791 / Virus Database: 271.1.1/2754 - Release Date: 03/20/10 03:33:00 ---------------------------------------------------------------------------- -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.791 / Virus Database: 271.1.1/2754 - Release Date: 03/21/10 15:33:00 ---------------------------------------------------------------------------- -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.791 / Virus Database: 271.1.1/2767 - Release Date: 03/24/10 03:33:00 |
From: Dave H. <dhy...@gm...> - 2010-03-24 14:20:22
|
Hi, On Wed, Mar 24, 2010 at 7:03 AM, <cod...@gm...> wrote: > How do I determine if the chip is supported by kernel drivers? I'm told > we'll be using the MCP23017. This is on Gumstix Overo. I did some googling and there doesn't appear to even be a linux driver for this chip. > The pins we were told to use on the expansion board are GPA# instead of > GPIO### (e.g., GPA0 vs. GPIO171). If these are exposed in > /sys/class/gpio/GPA# similarly to GPIOs, that would be great. I'm confused. Since this is an i2c bus, shouldn't you be connecting it to the i2c bus on the expansion board? The interrupt line(s) should go to a GPIO pin, but the SDA and SCL signals on the chip should connect to the SDA and SCL signals on the board. Will you be running the part at 1.8v? If so then you won't need any voltage converters between the chip and the expansion board. The GPIO pins are exposed in /sys/class only using their GPIO numbers. You won't see GPA0. You'll see GPIO171. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ |
From: <cod...@gm...> - 2010-03-24 15:15:00
|
Interesting. In a separate email, it was suggested I use MCP23017. I was unaware that there wouldn't be a linux driver for it. I don't deal with the hardware side of things here, so I'm not sure what voltages things will be run at. The chart I am going by here lists the MCP23017 connected to GPIO184 (I2C CLK) and GPIO185 (I2C DATA). Then a separate listing of some buttons that will be on that bus listed as GPA0 - GPA5. I don't know what GPIOs those GPA numbers would use. So I'm a bit confused myself. On Wed, Mar 24, 2010 at 10:20 AM, Dave Hylands <dhy...@gm...> wrote: > Hi, > > On Wed, Mar 24, 2010 at 7:03 AM, <cod...@gm...> wrote: > > How do I determine if the chip is supported by kernel drivers? I'm told > > we'll be using the MCP23017. This is on Gumstix Overo. > > I did some googling and there doesn't appear to even be a linux driver > for this chip. > > > The pins we were told to use on the expansion board are GPA# instead of > > GPIO### (e.g., GPA0 vs. GPIO171). If these are exposed in > > /sys/class/gpio/GPA# similarly to GPIOs, that would be great. > > I'm confused. Since this is an i2c bus, shouldn't you be connecting it > to the i2c bus on the expansion board? The interrupt line(s) should go > to a GPIO pin, but the SDA and SCL signals on the chip should connect > to the SDA and SCL signals on the board. > > Will you be running the part at 1.8v? If so then you won't need any > voltage converters between the chip and the expansion board. > > The GPIO pins are exposed in /sys/class only using their GPIO numbers. > You won't see GPA0. You'll see GPIO171. > > -- > Dave Hylands > Shuswap, BC, Canada > http://www.DaveHylands.com/ > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: ScottEllis <sco...@gm...> - 2010-03-24 17:52:06
|
You don't need a device driver to use the MCP23017. There is a working example right off the gumstix user wiki http://www.gumstix.net/wiki/index.php?title=Category:How_to_-_i2c Look down near the bottom for the overo-mcp23017 link. You'll need the user manual for the MCP23017 but you can google that. I chose that device for an I2C example deliberately just because it is so simple. Take a look at the manual, you'll see. coderdrone wrote: > > Interesting. In a separate email, it was suggested I use MCP23017. I was > unaware that there wouldn't be a linux driver for it. > > I don't deal with the hardware side of things here, so I'm not sure what > voltages things will be run at. The chart I am going by here lists the > MCP23017 connected to GPIO184 (I2C CLK) and GPIO185 (I2C DATA). Then a > separate listing of some buttons that will be on that bus listed as GPA0 - > GPA5. I don't know what GPIOs those GPA numbers would use. So I'm a bit > confused myself. > > On Wed, Mar 24, 2010 at 10:20 AM, Dave Hylands <dhy...@gm...> wrote: > >> Hi, >> >> On Wed, Mar 24, 2010 at 7:03 AM, <cod...@gm...> wrote: >> > How do I determine if the chip is supported by kernel drivers? I'm >> told >> > we'll be using the MCP23017. This is on Gumstix Overo. >> >> I did some googling and there doesn't appear to even be a linux driver >> for this chip. >> >> > The pins we were told to use on the expansion board are GPA# instead of >> > GPIO### (e.g., GPA0 vs. GPIO171). If these are exposed in >> > /sys/class/gpio/GPA# similarly to GPIOs, that would be great. >> >> I'm confused. Since this is an i2c bus, shouldn't you be connecting it >> to the i2c bus on the expansion board? The interrupt line(s) should go >> to a GPIO pin, but the SDA and SCL signals on the chip should connect >> to the SDA and SCL signals on the board. >> >> Will you be running the part at 1.8v? If so then you won't need any >> voltage converters between the chip and the expansion board. >> >> The GPIO pins are exposed in /sys/class only using their GPIO numbers. >> You won't see GPA0. You'll see GPIO171. >> >> -- >> Dave Hylands >> Shuswap, BC, Canada >> http://www.DaveHylands.com/ >> >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://old.nabble.com/Re%3A-I2C-tp27969201p28018896.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: <cod...@gm...> - 2010-03-24 18:41:44
|
I sometimes forget about the Gumstix User Wiki because until recently (within the last week) gumstix.net was blocked on our entire enterprise network at work. I did see the overo-mcp23017 project you posted before. I'll have to look at it more indepth. When using the i2c expansion cards, wouldn't the GPIOs on there just be exposed in /sys/class/gpio like the GPIOs on the 40-pin header are? All of my GPIO programming so far has consisted of opening these GPIO files (through Qt/Embedded's QFile) and reading them, or just executing a 'system("echo 0 > /sys/class/gpio/gpioXXX/value") to write to the pins. I was hoping that would work for these i2c cards as well. Either way, I don't actually have access to the actual boards yet, just the software that I write, which can't be tested until I get the boards. On Wed, Mar 24, 2010 at 1:52 PM, ScottEllis <sco...@gm...>wrote: > > You don't need a device driver to use the MCP23017. > > There is a working example right off the gumstix user wiki > > http://www.gumstix.net/wiki/index.php?title=Category:How_to_-_i2c > > Look down near the bottom for the overo-mcp23017 link. > > You'll need the user manual for the MCP23017 but you can google that. > > I chose that device for an I2C example deliberately just because it is > so simple. Take a look at the manual, you'll see. > > > coderdrone wrote: > > > > Interesting. In a separate email, it was suggested I use MCP23017. I > was > > unaware that there wouldn't be a linux driver for it. > > > > I don't deal with the hardware side of things here, so I'm not sure what > > voltages things will be run at. The chart I am going by here lists the > > MCP23017 connected to GPIO184 (I2C CLK) and GPIO185 (I2C DATA). Then a > > separate listing of some buttons that will be on that bus listed as GPA0 > - > > GPA5. I don't know what GPIOs those GPA numbers would use. So I'm a bit > > confused myself. > > > > On Wed, Mar 24, 2010 at 10:20 AM, Dave Hylands <dhy...@gm...> > wrote: > > > >> Hi, > >> > >> On Wed, Mar 24, 2010 at 7:03 AM, <cod...@gm...> wrote: > >> > How do I determine if the chip is supported by kernel drivers? I'm > >> told > >> > we'll be using the MCP23017. This is on Gumstix Overo. > >> > >> I did some googling and there doesn't appear to even be a linux driver > >> for this chip. > >> > >> > The pins we were told to use on the expansion board are GPA# instead > of > >> > GPIO### (e.g., GPA0 vs. GPIO171). If these are exposed in > >> > /sys/class/gpio/GPA# similarly to GPIOs, that would be great. > >> > >> I'm confused. Since this is an i2c bus, shouldn't you be connecting it > >> to the i2c bus on the expansion board? The interrupt line(s) should go > >> to a GPIO pin, but the SDA and SCL signals on the chip should connect > >> to the SDA and SCL signals on the board. > >> > >> Will you be running the part at 1.8v? If so then you won't need any > >> voltage converters between the chip and the expansion board. > >> > >> The GPIO pins are exposed in /sys/class only using their GPIO numbers. > >> You won't see GPA0. You'll see GPIO171. > >> > >> -- > >> Dave Hylands > >> Shuswap, BC, Canada > >> http://www.DaveHylands.com/ > >> > >> > >> > ------------------------------------------------------------------------------ > >> Download Intel® Parallel Studio Eval > >> Try the new software tools for yourself. Speed compiling, find bugs > >> proactively, and fine-tune applications for parallel performance. > >> See why Intel Parallel Studio got high marks during beta. > >> http://p.sf.net/sfu/intel-sw-dev > >> _______________________________________________ > >> gumstix-users mailing list > >> gum...@li... > >> https://lists.sourceforge.net/lists/listinfo/gumstix-users > >> > > > > > ------------------------------------------------------------------------------ > > Download Intel® Parallel Studio Eval > > Try the new software tools for yourself. Speed compiling, find bugs > > proactively, and fine-tune applications for parallel performance. > > See why Intel Parallel Studio got high marks during beta. > > http://p.sf.net/sfu/intel-sw-dev > > _______________________________________________ > > gumstix-users mailing list > > gum...@li... > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > > > -- > View this message in context: > http://old.nabble.com/Re%3A-I2C-tp27969201p28018896.html > Sent from the Gumstix mailing list archive at Nabble.com. > > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: ScottEllis <sco...@gm...> - 2010-03-24 19:13:23
|
You could certainly write a kernel driver for the device and expose a standard sysfs gpio interface to the pins if you wanted. That's what some people have done in the linux tree for some other I/O expanders. But gpio devices like those and the MCP aren't the same sort of gpio as the built-in gpio on the gumstix. For one thing, you can't really do anything with them in interrupt context. The I2C bus is way too slow. All you can really do is queue work to a function that can sleep. If you had to use the device from within other kernel code, then a kernel module might be handy. But since you are doing all your GPIO work from userland, I don't see what you would gain from it. Just abstract the MCP interface away in some userland code. It still looks like file i/o. If you are in QT using C++ already, just write a class for it. That would be simplest. You might want to bring back the interrupt output lines on the MCP to some real GPIO on the gumstix. But that depends on your app's requirements, whether or how often you are polling, are they for output only, etc.. You'd know that better then anyone else. -- View this message in context: http://old.nabble.com/Re%3A-I2C-tp27969201p28019901.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: <cod...@gm...> - 2010-03-24 19:41:01
|
Ok. I didn't realize that's what the linux kernel driver would provide: the standard sysfs interface for the GPIOs (among other things). So no kernel driver, no sysfs interface for these GPIOs. I'll check out the MCP sample source code linked from the wiki. I'm just so used to simply writing 1s and 0s to the pins, I'm not sure (yet) what bits to write to the file handles, or what address to use for the slave device, if I'm using the right terminology from the sample code. I'll look more into it. On Wed, Mar 24, 2010 at 3:13 PM, ScottEllis <sco...@gm...>wrote: > > You could certainly write a kernel driver for the device and expose a > standard sysfs gpio interface to the pins if you wanted. That's what > some people have done in the linux tree for some other I/O expanders. > But gpio devices like those and the MCP aren't the same sort of gpio > as the built-in gpio on the gumstix. For one thing, you can't really do > anything with them in interrupt context. The I2C bus is way too slow. > All you can really do is queue work to a function that can sleep. > > If you had to use the device from within other kernel code, then a kernel > module might be handy. But since you are doing all your GPIO work from > userland, I don't see what you would gain from it. Just abstract the MCP > interface away in some userland code. It still looks like file i/o. If you > are > in QT using C++ already, just write a class for it. That would be simplest. > > You might want to bring back the interrupt output lines on the MCP to some > real GPIO on the gumstix. But that depends on your app's requirements, > whether or how often you are polling, are they for output only, etc.. > You'd know that better then anyone else. > > > -- > View this message in context: > http://old.nabble.com/Re%3A-I2C-tp27969201p28019901.html > Sent from the Gumstix mailing list archive at Nabble.com. > > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |