Re: [PATCH] Proposal for new GPIO API and example implementation for STM32F4 BSP
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 simple
and generic. It has some opaque type structures that need to be implemented by
BSP. The functions include initialization, configuration, reading, writing, and
toggle. I took inspiration from the Wiring framework. I also have an example
implementation for the STM32F4 BSP.
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.
I would love to get feedback from all of you.
Thank you,
Duc Doan
---
bsps/arm/stm32f4/gpio/gpio.c | 39 +++
bsps/include/bsp/gpio2.h | 129 +++
2 files changed, 168 insertions(+)
create mode 100644 bsps/arm/stm32f4/gpio/gpio.c
create mode 100644 bsps/include/bsp/gpio2.h
diff --git a/bsps/arm/stm32f4/gpio/gpio.c b/bsps/arm/stm32f4/gpio/gpio.c
new file mode 100644
index 00..40aea3febd
--- /dev/null
+++ b/bsps/arm/stm32f4/gpio/gpio.c
@@ -0,0 +1,39 @@
+#include
+#include
+#include
+#include
+
+struct rtems_gpio_t {
+GPIO_TypeDef *port;
+};
+
+struct rtems_gpio_pin_t {
+uint16_t pin_mask;
+};
+
+struct rtems_gpio_config_t {
+GPIO_InitTypeDef *config;
+}
+
+__weak rtems_status_code rtems_gpio_initialize(void) {
+return RTEMS_SUCCESSFUL;
+}
+
+rtems_status_code rtems_gpio_configure(rtems_gpio_t *gpiox,
rtems_gpio_config_t *config) {
+HAL_GPIO_Init(gpiox->port, config->config);
+return RTEMS_SUCCESSFUL;
+}
+
+rtems_status_code rtems_gpio_write_pin(rtems_gpio_t *gpiox, rtems_gpio_pin_t
*pin, rtems_gpio_pin_state value) {
+HAL_GPIO_WritePin(gpiox->port, pin->pin_mask, value);
+return RTEMS_SUCCESSFUL;
+}
+
+rtems_gpio_pin_state rtems_gpio_read_pin(rtems_gpio_t *gpiox, rtems_gpio_pin_t
*pin) {
+return HAL_GPIO_ReadPin(gpiox->port, pin->pin_mask);
+}
+
+rtems_status_code rtems_gpio_toggle_pin(rtems_gpio_t *gpiox, rtems_gpio_pin_t
*pin) {
+HAL_GPIO_TogglePin(gpiox->port, pin->pin_mask);
+return RTEMS_SUCCESSFUL;
+}
diff --git a/bsps/include/bsp/gpio2.h b/bsps/include/bsp/gpio2.h
new file mode 100644
index 00..ef10d1729a
--- /dev/null
+++ b/bsps/include/bsp/gpio2.h
@@ -0,0 +1,129 @@
+/**
+ * @file
+ *
+ * @ingroup rtems_gpio2
+ *
+ * @brief RTEMS GPIO new API definition.
+ */
+
+ /*
+ * Copyright (c) 2022 Duc Doan
+ *
+ * The license and distribution terms for this file may be
+ * found in the file LICENSE in this distribution or at
+ * http://www.rtems.org/license/LICENSE.
+ */
+
+#ifndef LIBBSP_SHARED_GPIO2_H
+#define LIBBSP_SHARED_GPIO2_H
+
+#include
+#include
+
+#ifdef __cplusplus
+extern "C" {
+#endif /* __cplusplus */
+
+/**
+ * @name GPIO data structures
+ *
+ * @{
+ */
+
+/**
+ * @brief GPIO bit set and reset enumeration.
+ */
+typedef enum {
+RTEMS_GPIO_PIN_SET = 0,
+RTEMS_GPIO_PIN_RESET
+} rtems_gpio_pin_state;
Is set and reset the only state a pin can have? Or is that field thought
to be extended with (for example) open drain or similar states if a
device supports that?
Beneath that: Not a fan of SET == 0. I think RESET == 0 would be better
because than you can use it as a boolean without conversion.
+
+/**
+ * @brief Opaque type for a GPIO object.
+ *To be implemented by BSP.
+ *
+ * @details This could represent the unit that owns GPIO pins.
+ * For example, it would be a port for ARM Cortex-M.
+ */
+typedef struct rtems_gpio_t rtems_gpio_t;
Does that mean it is (for example) a GPIO controller? In that case maybe
call it "rtems_gpio_ctrl_t". My first guess from the name would have
been that it is already a pin.
I assume that you don't plan to publish the definition of the struct
rtems_gpio_t, right? With that the application can only use pointers.
Where does the application get the pointer from?
Same is true for the structures below: How would I initialize one of
these objects in the application?
+
+/**
+ * @brief Opaque type for a GPIO pin object.
+ *To be implemented by BSP.
+ */
+typedef struct rtems_gpio_pin_t rtems_gpio_pin_t;
+
+/**
+ * @brief Opaque type for configuration of a GPIO object.
+ *To be implemented by BSP.
+ */
+typedef struct rtems_gpio_config_t;
+
+/** @} */
+
+/**
+ * @name GPIO Functions
+ *
+ * @{
+ */
+
+/**
+ * @brief Initialization for GPIO. To be implemented by User Application.
+ *
+ * @retval RTEMS_SUCCESSFUL GPIO successfully initialized.
+ * @retval RTEMS_UNSATISFIED Could not initialize GPIO object.
+ */
+extern rtems_status_code rtems_gpio_initialize(void);
+
What would be done in that function?
Why does the application has to implement it?
Where would it be called?
+/**
+ * @brief Configures a GPIO object.
+ *
Fix GICv3 with R52 builds
Hi This patch fixes the r52 build. I have no means to test this change. Thanks Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] arm/gicv3: Fix building arm/r52
From: Chris Johns --- bsps/include/dev/irq/arm-gicv3.h | 5 + 1 file changed, 5 insertions(+) diff --git a/bsps/include/dev/irq/arm-gicv3.h b/bsps/include/dev/irq/arm-gicv3.h index a79368ebdf..aac02fa191 100644 --- a/bsps/include/dev/irq/arm-gicv3.h +++ b/bsps/include/dev/irq/arm-gicv3.h @@ -335,7 +335,12 @@ static void gicv3_init_cpu_interface(uint32_t cpu_index) } /* Enable interrupt groups 0 and 1 */ +#ifdef ARM_MULTILIB_ARCH_V4 + WRITE_SR(ICC_IGRPEN0, 0x1); + WRITE_SR(ICC_IGRPEN1, 0x1); +#else gic_icc_write(IGRPEN1, 1); +#endif WRITE_SR(ICC_CTLR, 0x0); } -- 2.24.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
GCC 12 warnings in testsuite
Hi This patch fixes a number of easy warnings gcc 12 is now generating in the testsuite. There is a single addition of a pragma to silence a warning related. The patch does not cover: - Some fixes posted by Matt - Two warnings related to a pointer returned by malloc - Any warnings related to the validation tests. This is the notice there are issues in the validation tests that need to be sorted Thanks Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] testsuite: Fix gcc 12 warnings
From: Chris Johns
---
testsuites/libtests/POSIX/readv.c | 2 +-
testsuites/libtests/POSIX/sigismember.c | 2 +-
testsuites/libtests/POSIX/sigprocmask.c | 3 ++-
testsuites/libtests/POSIX/writev.c| 2 +-
testsuites/psxtests/psxhdrs/arpa/inet/inet_ntop.c | 2 +-
testsuites/psxtests/psxhdrs/fcntl/openat.c| 4 ++--
testsuites/psxtests/psxhdrs/netdb/gethostbyaddr.c | 2 +-
.../psxhdrs/pthread/pthread_attr_getdetachstate.c | 4 ++--
.../psxtests/psxhdrs/pthread/pthread_attr_getguardsize.c | 4 ++--
.../psxhdrs/pthread/pthread_attr_getinheritsched.c| 4 ++--
.../psxtests/psxhdrs/pthread/pthread_attr_getschedparam.c | 4 ++--
.../psxhdrs/pthread/pthread_attr_getschedpolicy.c | 4 ++--
.../psxtests/psxhdrs/pthread/pthread_attr_getscope.c | 4 ++--
.../psxtests/psxhdrs/pthread/pthread_attr_getstack.c | 2 +-
.../psxtests/psxhdrs/pthread/pthread_attr_getstackaddr.c | 2 +-
.../psxtests/psxhdrs/pthread/pthread_attr_getstacksize.c | 4 ++--
.../psxtests/psxhdrs/pthread/pthread_attr_setschedparam.c | 4 ++--
testsuites/psxtests/psxhdrs/pthread/pthread_cond_init.c | 2 +-
.../psxtests/psxhdrs/pthread/pthread_cond_timedwait.c | 2 +-
.../psxhdrs/pthread/pthread_condattr_getpshared.c | 2 +-
testsuites/psxtests/psxhdrs/pthread/pthread_create.c | 2 +-
.../psxhdrs/pthread/pthread_mutex_getprioceiling.c| 4 ++--
testsuites/psxtests/psxhdrs/pthread/pthread_mutex_init.c | 2 +-
.../psxtests/psxhdrs/pthread/pthread_mutex_timedlock.c| 2 +-
.../psxhdrs/pthread/pthread_mutexattr_getprioceiling.c| 2 +-
.../psxhdrs/pthread/pthread_mutexattr_getprotocol.c | 4 ++--
.../psxhdrs/pthread/pthread_mutexattr_getpshared.c| 4 ++--
testsuites/psxtests/psxhdrs/sys/select/pselect.c | 4 ++--
testsuites/psxtests/psxhdrs/sys/socket/bind.c | 2 +-
testsuites/psxtests/psxhdrs/sys/socket/connect.c | 6 +++---
testsuites/psxtests/psxhdrs/sys/socket/getsockopt.c | 2 +-
testsuites/psxtests/psxhdrs/sys/socket/send.c | 2 +-
testsuites/psxtests/psxhdrs/sys/socket/sendmsg.c | 2 +-
testsuites/psxtests/psxhdrs/sys/socket/sendto.c | 4 ++--
testsuites/psxtests/psxhdrs/sys/socket/setsockopt.c | 2 +-
testsuites/psxtests/psxhdrs/sys/stat/futimens.c | 4 ++--
testsuites/psxtests/psxhdrs/sys/stat/utimensat.c | 4 ++--
testsuites/psxtests/psxhdrs/sys/time/utimes.c | 8
testsuites/psxtests/psxhdrs/termios/cfgetispeed.c | 4 ++--
testsuites/psxtests/psxhdrs/termios/cfgetospeed.c | 4 ++--
testsuites/psxtests/psxhdrs/termios/cfsetispeed.c | 4 ++--
testsuites/psxtests/psxhdrs/termios/cfsetospeed.c | 4 ++--
testsuites/psxtests/psxhdrs/termios/tcgetattr.c | 4 ++--
testsuites/psxtests/psxhdrs/termios/tcsetattr.c | 4 ++--
testsuites/psxtests/psxhdrs/time/asctime.c| 2 +-
testsuites/psxtests/psxhdrs/time/asctime_r.c | 2 +-
testsuites/psxtests/psxhdrs/time/clock_settime.c | 2 +-
testsuites/psxtests/psxhdrs/time/ctime.c | 2 +-
testsuites/psxtests/psxhdrs/time/ctime_r.c| 2 +-
testsuites/psxtests/psxhdrs/time/gmtime.c | 2 +-
testsuites/psxtests/psxhdrs/time/gmtime_r.c | 2 +-
testsuites/psxtests/psxhdrs/time/localtime.c | 2 +-
testsuites/psxtests/psxhdrs/time/localtime_r.c| 2 +-
testsuites/psxtests/psxhdrs/time/strftime.c | 2 +-
testsuites/psxtests/psxhdrs/unistd/setgroups.c| 2 +-
testsuites/psxtests/psxhdrs/utime/utime.c | 2 +-
testsuites/psxtests/psxhdrs/wchar/mbsinit.c | 4 ++--
testsuites/psxtests/psxkey07/init.c | 3 ++-
testsuites/psxtests/psxkey08/init.c | 2 +-
testsuites/psxtests/psxmsgq01/init.c | 2 +-
testsuites/sptests/sp68/init.c| 2 +-
testsuites/sptests/spfatal32/init.c | 5 +
62 files changed, 96 insertions(+), 89 deletions(-)
diff --git a/testsuites/libtests/POSIX/readv.c
b/testsuites/libtests/POSIX/readv.c
index a980e9468c..6b0bf63f94 100644
--- a/testsuites/libtests/POSIX/readv.c
+++ b/testsuites/libtests/POSIX/readv.c
@@ -14,7 +14,7 @@
int main(void)
{
- struct iovec iov;
+ struct iovec iov = { 0 };
int count = 4;
ssize_t ret;
diff --git a/testsuites/libtests/POSIX/sigismember.c
b/testsuites/libtests/POSIX/sigismember.c
index ed980b70f0..f4c7d37cb2 100644
--- a/testsuites/libtests/POSIX/sigismember.c
+++ b/testsuites/libtests/POSIX/sigismember.c
@@ -14,7 +14,7 @@
int main(void)
{
- sigset_t set;
+ sigset_t set = { 0 };
int status;
status = sigismember(&set, 21);
diff --git a/testsuites/libtests/POSIX/sigprocmask.c
b/testsuites/libtests/POSIX/sigp
Re: [PATCH 13/13] jffs2: Update baseline version to Linux v5.9
On 11/06/2022 03:57, Chris Johns wrote: I will take a look at the heap fragmentation under large block writes as a background task. I have openedhttps://devel.rtems.org/ticket/4664 to track this issue. In 2018 I replaced the first fit allocator with TLSF due to heap fragmentation issues in combination with JFFS2 in an RTEMS application operating 24/7. Since then we no longer observed heap fragmentation issues. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems-libbsd commit] freebsd/nfsv4: Fix misaligned 64bit user dirent write
On 20/06/2022 04:57, Chris Johns wrote: Module:rtems-libbsd Branch:6-freebsd-12 Commit:c56a34f54767decf3e398651c30bea9ebbd9572a Changeset:http://git.rtems.org/rtems-libbsd/commit/?id=c56a34f54767decf3e398651c30bea9ebbd9572a Author:Chris Johns Date: Mon Jun 20 12:44:41 2022 +1000 freebsd/nfsv4: Fix misaligned 64bit user dirent write The tl2 is a pointer to uint32_t. On which platform did this case a problem? Platforms should support misaligned load/store operations to normal memory. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
