BBB GPIO pullpup/pulldown patch

[Federico Garcia Cruz]

Hi everyone,
we're working with the latest RTEMS in the Beaglebone and we're using the
GPIO api. We've added the code for configuring the pullup/pulldown resistor
in the Beaglebone. Could anyone give it a shoot?

-- 




Federico Garcia Cruz

Software Engineer


San Lorenzo 47, 3rd Floor, Office 5

Córdoba, Argentina


Phone: +54 351 4217888 / +54 351 4218211




diff --git a/c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c b/c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c
index bd26051..4dede50 100644
--- a/c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c
+++ b/c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c
@@ -269,8 +269,17 @@ rtems_status_code rtems_gpio_bsp_set_resistor_mode(
   uint32_t pin,
   rtems_gpio_pull_mode mode
 ) {
-  /* TODO: Add support for setting up resistor moode */
-  return RTEMS_NOT_DEFINED;
+
+  if (mode == PULL_UP) {
+mmio_set(bbb_conf_reg(bank, pin), BBB_PU_EN);
+mmio_clear(bbb_conf_reg(bank, pin), BBB_PUDEN);
+  } else if (mode == PULL_DOWN) {
+mmio_clear(bbb_conf_reg(bank, pin), BBB_PU_EN);
+mmio_clear(bbb_conf_reg(bank, pin), BBB_PUDEN);
+  } else {
+mmio_set(bbb_conf_reg(bank, pin), BBB_PUDEN);
+  }
+  return RTEMS_SUCCESSFUL;
 }
 
 rtems_vector_number rtems_gpio_bsp_get_vector(uint32_t bank)
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RTEMS Accepted info Google Code-In 2015

[Joel Sherrill]

Hi

We are honored to be in the 2015 edition of the Google Code-In program for
high school students.  Our current list of small task ideas is at:

https://devel.rtems.org/wiki/GCI/Projects

Please volunteer to mentor. It is a very rewarding program and the tasks are
small. Any RTEMS user should be able to help out.

One of the tasks class is beginner and it can be done once by any number of
students. One of the ones for RTEMS it to do the hello world introductory
exercise we require of GSOC students. So if you can use the RSB and run
hello world on a simulator, you are more than qualified. :)

Please pitch in. Many hands make light work. Plus there is a cool t-shirt in
it for you. :)

--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Beagle BSP Improvements (GPIO driver)

[Daniel Gutson]

Hi Ketul,

   we are experiencing a deadlock that seems to be caused by

+#define OBTAIN_LOCK(s) assert( rtems_semaphore_obtain(s,\
+  RTEMS_WAIT,   \
+  RTEMS_NO_TIMEOUT  \
+  ) == RTEMS_SUCCESSFUL )
+

which differs from the previous version. Are you sure this is the
intended behavior for in-interrupt context? What if the semaphore is
already locked?
IIUC this causes either a forever sleep or an assertion in case the
semaphore cannot be acquired.

Thanks,

Daniel.

On Tue, Jun 23, 2015 at 11:53 AM, Ketul Shah  wrote:
> Sorry wrong attachment. Kindly review the recent one.
>
> Thanks.
>
> Best Regards,
> Ketul
>
> On 23 June 2015 at 20:20, Ketul Shah  wrote:
>>
>> Hello all,
>>
>> Sorry as I am updating you related to my GPIO API after a huge delay.
>>
>> I have developed it and tested it on my BBB. I did some big changes in the
>> API taking in the account comment(s)/suggestion(s) from my respective
>> mentors.
>>
>> I am also looking the API developed by Andre working for Raspberry Pi. Now
>> I think it is a good time to merge the gpio code as API is getting more
>> stable and generalized.
>>
>> So now it is good time to take the best things from API and we can have
>> common API for GPIO driver running on every embedded board.
>>
>> Your comment(s) are welcomed.
>>
>> Thanks.
>>
>> Best Regards,
>> Ketul
>>
>> On 29 April 2015 at 06:39, Chris Johns  wrote:
>>>
>>>  [ Just catching up ]
>>>
>>> On 26/04/2015 9:26 pm, Ben Gras wrote:
>>> > All,
>>> >
>>> > I think the API as it is (for digital GPIO's) is pretty close to
>>> > generic. I like my suggestion (gpio_* in my previous mail) better as
>>> > more generic. (More configuration is hidden from the application.)
>>> >
>>> > Joel I just read your presentation.
>>> >
>>> > I have come up with a minimal GPIO API based on the above (so
>>> > ultimately based on the RPI API) that just covers the GPIO digital out
>>> > case but allows expansion (with more defines and functions).
>>> >
>>> > https://devel.rtems.org/wiki/TBR/User/BenGras
>>> >
>>> > Is this an idea? Then we can merge this code implementing a reasonably
>>> > generic API without having to flesh out the whole thing.
>>> >
>>>
>>> How do we define hardware specific details without bloating the API ?
>>>
>>> For example on a zynq project I am working on I needed a GPIO interface
>>> and I decided to use a struct to define the pin and the API takes
>>> references to it. For example to control the write enable pin on a flash
>>> device I have:
>>>
>>> static const gpio_pin_def gpio_Flash_WD =
>>> {
>>>   pin:  4,
>>>   output:   true,
>>>   on:   GPIO_FLASH_WD_EN,
>>>   outen:true,
>>>   volts:gpio_LVCMOS33,
>>>   pullup:   true,
>>>   fast: false,
>>>   tristate: false
>>> };
>>>
>>> and then I have:
>>>
>>>gpio_error ge = gpio_setup_pin(&gpio_Flash_WD);
>>>if (ge != GPIO_NO_ERROR)
>>>return FLASH_WRITE_LOCK_FAIL;
>>>
>>>
>>>
>>> gpio_output(gpio_Flash_WD.pin, GPIO_FLASH_WD_EN);
>>>
>>>
>>>
>>> I need to set the voltage on the pin on the Zynq but this is Zynq
>>> specific.
>>>
>>> We need a way to let a user convey specific hardware details to the BSP
>>> driver through the API plus we need a light weight API with minimal
>>> internal translations. This approach also lets me define an array of
>>> pins and a single set up call configures them.
>>>
>>> So you could have:
>>>
>>> typedef struct
>>> {
>>> int   pin;   /* The pin number. */
>>> bool  output;/* True for output, false for input. */
>>> bool  on;/* True default output is on */
>>> bool  outen; /* True for output enable on, false for off. */
>>> bool  pullup;/* True to enable the pull up. */
>>> bool  tristate;  /* True to enable tri-state. */
>>> void* platform;  /* Opaque hardware specific set up details. */
>>> } gpio_pin_def;
>>>
>>> where the 'platform' references a struct agreed between the BSP (or
>>> device layer) and the user code. For the generic cases this is not
>>> needed and NULL. It also allows layering where a device set up phase of
>>> user code sets the voltages and the generic code can play with the pin
>>> at a generic level, eg direction etc.
>>>
>>> What locking is being considered in this API ?
>>>
>>> Chris
>>
>>
>
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel



-- 

Daniel F. Gutson
Chief Engineering Officer, SPD

San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina

Phone:   +54 351 4217888 / +54 351 4218211
Skype:dgutson
LinkedIn: http://ar.linkedin.com/in/danielgutson
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel