<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Using examples of working APIs is a good idea. But be careful not to <br>
copy any code from that framework because the license (GPL) wouldn't be <br>
compatible.</blockquote><div><br></div><div>Sure, I don't copy their code but only see what functions should be in a GPIO API (like read, write, toggle, pinmode).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Is set and reset the only state a pin can have? Or is that field thought <br>
to be extended with (for example) open drain or similar states if a <br>
device supports that?</div></blockquote><div><br></div><div>I think it can be extended but I have only put in the most basic states for now.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br></div><div>Beneath that: Not a fan of SET == 0. I think RESET == 0 would be better <br>
because than you can use it as a boolean without conversion.<span class="gmail-im"><br></span></div></blockquote><div><br></div><div>You are right, that was my mistake. I have fixed it.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Does that mean it is (for example) a GPIO controller? In that case maybe <br>
call it "rtems_gpio_ctrl_t". My first guess from the name would have <br>
been that it is already a pin.</div></blockquote><div> </div><div>I have made changes in my newest patch, and rtems_gpio_t is now essentially a pin.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Same is true for the structures below: How would I initialize one of <br>
these objects in the application?</div></blockquote><div><br></div><div>The example initialization of those structures can be found in my sample blink code: <a href="https://github.com/dtbpkmte/GSoC-2022-RTEMS-Sample-Apps/blob/main/RTEMS_Blink_API/src/init.c">https://github.com/dtbpkmte/GSoC-2022-RTEMS-Sample-Apps/blob/main/RTEMS_Blink_API/src/init.c</a> . The definition of the structures are defined by BSP. Here are STM32F4's definitions:</div><div>/********************* CODE BEGINS ***************************************/<br></div><div>struct rtems_gpio_t {<br>    GPIO_TypeDef *port;<br>    uint16_t pin;<br>};<br><br>/**<br>  * This structure should be initialized to 0 <br>  *<br>  * This structure holds configuration options for STM32F4-specific<br>  * GPIO. The 2 specific modes are Event and Alternate modes. Select<br>  * a mode by setting the correct field (is_event_mode or is_alternate_mode)<br>  * to 1.<br>  */<br>struct rtems_gpio_config_t {<br>    uint32_t speed;             /* Speed of the pin. Must be specified */<br>                                   <br>    uint32_t interrupt_mode;    /* The type of interrupt trigger of the pin <br>                                   Use if the pin is in Interrupt mode */<br>                                   <br>    uint32_t is_event_mode;     /* Sets to 1 if the pin is in event mode,<br>                                   0 other wise.<br>                                   Use if the pin is in Event mode */<br>    uint32_t event_mode;        /* The type of event trigger of the pin <br>                                   Use if the pin is in Event mode */<br>    <br>    uint32_t is_alternate_mode; /* Sets to 1 if the pin is in Alternate mode,<br>                                   0 other wise.<br>                                   Use if the pin is in Alternate mode */<br>    uint32_t alternate_mode;    /* Open drain or Push-pull mode<br>                                   Use if the pin is in Alternate mode */<br>    uint32_t alternate_fn;      /* The alternate function of the pin<br>                                   Use if the pin is in Alternate mode */<br>};</div><div>/********************* CODE ENDS ***************************************/</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>What would be done in that function?<br>
<br>
Why does the application has to implement it?<br>
<br>
Where would it be called?<span class="gmail-im"><br></span></div></blockquote><div><br></div><div>The initialize function is meant to perform setup code for the GPIO. For example, for the STM32, it would be enabling the clocks of the ports. The application needs to implement it if they want to use GPIO because the peripheral needs initialization. They don't have to, though, if they want to do that initialization somewhere else. This function is called in bsp_start(). It is already implemented as a weak, empty function, so there is no problem if the user doesn't implement it.<br></div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">What would be possible error cases? Is one "UNSATISFIED" enough or <br>
should it be able to return other errors too (like the return value from <br>
an I2C transfer because the pin is connected to some SPI-GPIO extender).</blockquote><div><br></div><div> I think "UNSATISFIED" is enough because these are quite low-level. I think the return values from more complicated things like I2C should be handled in other functions (like the I2C API), and I want to keep the GPIO thing portable. I am open to more discussion though, because I am not sure I can think of all use cases of this GPIO API.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>If the write can fail, the read can also fail. Do we need an error <br>
return value too?</div></blockquote> </div><div>Yes, I think that's a good idea. I changed it as below:</div><div><br></div><div>/**<br>  * @brief Reads the digital value of a pin.<br>  *<br>  * @param[in] gpiox The GPIO object that owns the pin.<br>  *<br>  * @param[out] value The state of the pin.<br>  *<br>  * @retval RTEMS_SUCCESSFUL Pin succesfully read.<br>  * @retval RTEMS_UNSATISFIED Could not read pin.<br>  */<br>extern rtems_status_code rtems_gpio_read_pin(rtems_gpio_t *gpiox, rtems_gpio_pin_state *value);</div><div><br></div><div>Best,</div><div><br></div><div>Duc Doan<br></div></div>