From: xiooozzz<xio...@16...> - 2012-05-31 01:50:39
|
GPIO17~GPIO22 is originally used by mmc3, which doesn't exist. So, i use them on my purpose. GPIO21 is used for heartbeat LED, i didn't use it. Here is my code, which is quite simple: static int command_out(unsigned int para) { int i; i=para; i&=1; gpio_direction_output(GPIO17, i); para=(para>>1); i=para; i&=1; gpio_direction_output(GPIO18, i); para=(para>>1); i=para; i&=1; gpio_direction_output(GPIO19, i); para=(para>>1); i=para; i&=1; gpio_direction_output(GPIO20, i); para=(para>>1); i=para; i&=1; gpio_direction_output(GPIO22, i); para=(para>>1); printk(KERN_INFO"Send IO, %X. \n",temp_get_gpio()); return 0; } static int temp_get_gpio(void) { int i=0,temp=0; i=gpio_get_value(GPIO22); temp|=i; temp=temp<<1; i=gpio_get_value(GPIO20); temp|=i; temp=temp<<1; i=gpio_get_value(GPIO19); temp|=i; temp=temp<<1; i=gpio_get_value(GPIO18); temp|=i; temp=temp<<1; i=gpio_get_value(GPIO17); temp|=i; return temp; } I called command_out with para=0x11; and serial console replyed "Send IO, 11. " This would mean the programme write the Control Register successfully, and the current voltage on Pins (GPIO17~GPIO22) ought to be high-low-low-low-high. But it does'nt seem to be like this. The actual voltage is always high-high-high-high-low, even other para is set. I have request the gpio on initial fuction, which turn out successful: if (gpio_request(65,"")||gpio_direction_output(65, 1))//request gpio resources { return -EBUSY; } if (gpio_request(17,"")||gpio_direction_input(17)//request gpio resources { return -EBUSY; } if (gpio_request(18,"")||gpio_direction_input(18))//request gpio resources { return -EBUSY; } if (gpio_request(19,"")||gpio_direction_input(19))//request gpio resources { return -EBUSY; } if (gpio_request(20,"")||gpio_direction_input(20))//request gpio resources { return -EBUSY; } if (gpio_request(22,"")||gpio_direction_input(22))//request gpio resources { return -EBUSY; } How ever, the same method works well on GPIO65, GPIO50, GPIO151 and other GPIOs, but it just does'nt works on GPIO17~GPIO22. Does anyone know any information about this? I even doubt my COM is a bad product. My COM product ID is GS3503E-R2889. 2012-05-31 xiooozzz |
From: Alex G. <al...@al...> - 2012-05-31 02:39:12
|
On 31/05/2012 11:53 AM, xiooozzz wrote: > GPIO17~GPIO22 is originally used by mmc3, which doesn't exist. > So, i use them on my purpose. > GPIO21 is used for heartbeat LED, i didn't use it. > Here is my code, which is quite simple: Some of those should be useable. Have you set the pin mux ? see http://wiki.gumstix.org/index.php?title=GPIO and http://www.jumpnowtek.com/index.php?option=com_content&view=article&id=54&Itemid=60 |
From: Keane, B. (STRX) <ben...@ka...> - 2012-05-31 07:32:57
|
I am using a 3.3 Kernel, so depending on your Kernel version the function calls might have changed.. But .. Try adding into your kernel board file (kernel/arch/arm/mach-omap2/board-overo.c) in the overo_init() (or make a new __init function and call that) omap_mux_init_gpio(17, OMAP_PIN_INPUT); if (gpio_request_one(17, GPIOF_IN, "GPIO17") == 0) gpio_export(17, 1); else printk(KERN_ERR "could not obtain gpio for " "17\n"); And make sure you include CONFIG_OMAP_MUX=y This allows you to change your muxing in the kernel (instead of in u-boot) and it exports the pin so you can access it via sysfs. You may have to go hunting for other functions that take the GPIO .. Like the LED module. >-----Original Message----- >From: xiooozzz [mailto:xio...@16...] >Sent: Thursday, 31 May 2012 11:54 AM >To: gum...@li... >Subject: [Gumstix-users] GPIO17~GPIO22: unprogrammable? > >GPIO17~GPIO22 is originally used by mmc3, which doesn't exist. > So, i use them on my purpose. > GPIO21 is used for heartbeat LED, i didn't use it. > Here is my code, which is quite simple: > static int command_out(unsigned int para) > { > int i; > i=para; i&=1; gpio_direction_output(GPIO17, i); para=(para>>1); > i=para; i&=1; gpio_direction_output(GPIO18, i); para=(para>>1); > i=para; i&=1; gpio_direction_output(GPIO19, i); para=(para>>1); > i=para; i&=1; gpio_direction_output(GPIO20, i); para=(para>>1); > i=para; i&=1; gpio_direction_output(GPIO22, i); para=(para>>1); > printk(KERN_INFO"Send IO, %X. \n",temp_get_gpio()); > return 0; > } > static int temp_get_gpio(void) > { > int i=0,temp=0; > i=gpio_get_value(GPIO22); > temp|=i; > temp=temp<<1; > i=gpio_get_value(GPIO20); > temp|=i; > temp=temp<<1; > i=gpio_get_value(GPIO19); > temp|=i; > temp=temp<<1; > i=gpio_get_value(GPIO18); > temp|=i; > temp=temp<<1; > i=gpio_get_value(GPIO17); > temp|=i; > return temp; > } > > I called command_out with para=0x11; and serial console >replyed "Send IO, 11. " > This would mean the programme write the Control Register >successfully, and the current voltage on Pins (GPIO17~GPIO22) >ought to be high-low-low-low-high. > But it does'nt seem to be like this. The actual voltage is >always high-high-high-high-low, even other para is set. > I have request the gpio on initial fuction, which turn out >successful: > if (gpio_request(65,"")||gpio_direction_output(65, >1))//request gpio resources > { > return -EBUSY; > } > if >(gpio_request(17,"")||gpio_direction_input(17)//request gpio resources > { > return -EBUSY; > } > if >(gpio_request(18,"")||gpio_direction_input(18))//request gpio resources > { > return -EBUSY; > } > if >(gpio_request(19,"")||gpio_direction_input(19))//request gpio resources > { > return -EBUSY; > } > if >(gpio_request(20,"")||gpio_direction_input(20))//request gpio resources > { > return -EBUSY; > } if >(gpio_request(22,"")||gpio_direction_input(22))//request gpio resources > { > return -EBUSY; > } > > How ever, the same method works well on GPIO65, GPIO50, >GPIO151 and other GPIOs, but it just does'nt works on GPIO17~GPIO22. > Does anyone know any information about this? > I even doubt my COM is a bad product. > My COM product ID is GS3503E-R2889. > > >2012-05-31 >xiooozzz > >--------------------------------------------------------------- >--------------- >Live Security Virtual Conference >Exclusive live event will cover all the ways today's security >and threat landscape has changed and how IT managers can >respond. Discussions will include endpoint security, mobile >security and the latest in malware threats. >http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >_______________________________________________ >gumstix-users mailing list >gum...@li... >https://lists.sourceforge.net/lists/listinfo/gumstix-users > >______________________________________________________________________ >CAUTION: This message was sent via the Public Internet and its >authenticity cannot be guaranteed. > PROPRIETARY: This e-mail contains proprietary information some or all of which may be legally privileged. It is intended for the recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the authority by replying to this e-mail. If you are not the intended recipient you must not use, disclose, distribute, copy, print, or rely on this e-mail. |