Hello Duc,
Am 29.06.22 um 13:46 schrieb Duc Doan:
Hello Christian,
I have been writing the complete API and also implementation for
STM32F4. A patch is coming soon.
On Mon, 2022-06-27 at 13:33 +0200, Christian MAUDERER wrote:
Regarding pin groups: I think it's worth to think a bit about how
Hello Christian,
I have been writing the complete API and also implementation for
STM32F4. A patch is coming soon.
On Mon, 2022-06-27 at 13:33 +0200, Christian MAUDERER wrote:
> Regarding pin groups: I think it's worth to think a bit about how the
> structure could be extended. You don't have to
Hello Duc,
Am 27.06.22 um 12:39 schrieb Duc Doan:
Hello Christian and Karel,
On Mon, 2022-06-27 at 08:29 +0200, Christian MAUDERER wrote:
Please think about whether you want to start at 0 or at 1!
I want it to start at 0.
Be really careful with that syntax. If you use increasing numbers
Hello Christian and Karel,
On Mon, 2022-06-27 at 08:29 +0200, Christian MAUDERER wrote:
> Please think about whether you want to start at 0 or at 1!
>
I want it to start at 0.
>
> Be really careful with that syntax. If you use increasing numbers
> like
> you suggested, every controller would
Hello Duc,
just one remark.
On 6/27/22 05:34, Duc Doan wrote:
rtems_gpio_ctrl_t *ctrl0 = bsp_gpio_get_ctrl(60); //corresponds to
GPIOD pin 12 on F4
^ if your ctrl structure knows you are working with pin 60
rtems_gpio_write(ctrl, 60, RTEMS_GPIO_PIN_SET);
then you do not need to use it
Hello Duc,
Am 27.06.22 um 05:34 schrieb Duc Doan:
Hello Karel and Christian,
I am thinking of this way: referring to a pin using a number. Each BSP
will map that pin number to its specific port and pin. For example, for
STM32F4 which has 16 pins per GPIO port, pin 6 will correspond to GPIOA
Hello Karel and Christian,
I am thinking of this way: referring to a pin using a number. Each BSP
will map that pin number to its specific port and pin. For example, for
STM32F4 which has 16 pins per GPIO port, pin 6 will correspond to GPIOA
pin 6, and pin 20 will correspond to GPIOB pin 4. The
On 6/26/22 10:49, Duc Doan wrote:
#define rtems_gpio_get_ctrl(_driver, _arg, _out) \
_driver##_gpio_get_ctrl( _arg , _out )
In the application code:
rtems_gpio_get_ctrl(stm32f4, GPIOD, _ctrl);
rtems_gpio_get_ctrl(stm32f4, GPIOA, _ctrl);
It's only a different method of writing the same.
Hello Christian and Karel,
On Sun, 2022-06-26 at 10:02 +0200, o...@c-mauderer.de wrote:
> Hello Karel and Duc,
>
> Am 26.06.22 um 09:24 schrieb Duc Doan:
> > Hello Karel,
> >
> > I came up with this solution: making a macro that returns a
> > function
> > depending on driver/BSP name.
> >
> >
Hello Christian,
On Sun, 2022-06-26 at 09:50 +0200, o...@c-mauderer.de wrote:
> Is setting the pull really independent of the mode? Most controller
> that
> I know have a pull-Up only on Inputs. Sometimes on an Open-Drain
> output.
> Sometimes in another controller (but you might ignore that
Hello Karel and Duc,
Am 26.06.22 um 09:24 schrieb Duc Doan:
Hello Karel,
I came up with this solution: making a macro that returns a function
depending on driver/BSP name.
/**
* @brief Get an GPIO control object.
*
* This macro requires BSPs/drivers to correctly implement
*
Hello Duc,
Am 25.06.22 um 13:43 schrieb Duc Doan:
Hello Christian,
On Fri, 2022-06-24 at 17:32 +0200, o...@c-mauderer.de wrote:
Be careful with everything that depends on the BSP. Again: Please
think
about an i2c GPIO expander. That chip can be used on different BSPs.
It
can be even an
Hello Karel,
I came up with this solution: making a macro that returns a function
depending on driver/BSP name.
/**
* @brief Get an GPIO control object.
*
* This macro requires BSPs/drivers to correctly implement
* function _gpio_get_ctrl(void *arg,
* rtems_gpio_ctrl_t **out).
*
Hello Duc,
one reminder, your API should be more or less portable. That means the
example which you produce as a testing example should be API-wise
portable between various BSPs. Is that clear?
I know, I know, sometimes user led 1 on F4 is on different port/pin on
F7 and then on H7 you
Hello Christian,
I forgot to send the sample code. Here it a code to turn on an LED:
/*/
// Obtain the pointer to the instance (port D)
rtems_gpio_ctrl_t *ctrl;
stm32f4_gpio_get_ctrl(GPIOD, );
// enable clocks for port D
rtems_gpio_initialize(ctrl);
//
Hello Christian,
On Fri, 2022-06-24 at 17:32 +0200, o...@c-mauderer.de wrote:
> Be careful with everything that depends on the BSP. Again: Please
> think
> about an i2c GPIO expander. That chip can be used on different BSPs.
> It
> can be even an independent driver that can be used by a user on
Hello Duc,
Am 24.06.22 um 16:28 schrieb Duc Doan:
Hello Christian,
On Thu, 2022-06-23 at 18:30 +0200, o...@c-mauderer.de wrote:
Another tricky part can be how to handle pins or pin groups. At the
moment I just used an "unsigned" for a single pin. That wouldn't be
able
to handle a pin group.
Hello Christian,
On Thu, 2022-06-23 at 18:30 +0200, o...@c-mauderer.de wrote:
> Another tricky part can be how to handle pins or pin groups. At the
> moment I just used an "unsigned" for a single pin. That wouldn't be
> able
> to handle a pin group. Maybe a pin group needs it's own type or some
Hello Duc,
Am 23.06.22 um 13:36 schrieb Duc Doan:
On Tue, 2022-06-21 at 17:23 +0200, o...@c-mauderer.de wrote:
OK. So every BSP that want's to use that API will have a different
rtems_gpio_config_t (or every other structure) that is defined in
(for
example) bsp.h? The application has to know
On Tue, 2022-06-21 at 17:23 +0200, o...@c-mauderer.de wrote:
> OK. So every BSP that want's to use that API will have a different
> rtems_gpio_config_t (or every other structure) that is defined in
> (for
> example) bsp.h? The application has to know the details of the
> current
> BSP and
Am 21.06.22 um 16:31 schrieb Duc Doan:
Using examples of working APIs is a good idea. But be careful not to
copy any code from that framework because the license (GPL) wouldn't be
compatible.
Sure, I don't copy their code but only see what functions should be in a
GPIO API (like
>
> Using examples of working APIs is a good idea. But be careful not to
> copy any code from that framework because the license (GPL) wouldn't be
> compatible.
Sure, I don't copy their code but only see what functions should be in a
GPIO API (like read, write, toggle, pinmode).
Is set and
Hello Duc,
Am 14.06.22 um 16:46 schrieb Duc Doan:
Dear all,
I am proposing a new GPIO API for RTEMS. The current API is kind of tailored to
some specific hardware and therefore may require some overhead to make it fit
for others. The one I am proposing is not finished but it is aimed to be
Dear all,
I am proposing a new GPIO API for RTEMS. The current API is kind of tailored to
some specific hardware and therefore may require some overhead to make it fit
for others. The one I am proposing is not finished but it is aimed to be simple
and generic. It has some opaque type
24 matches
Mail list logo
