[PATCH 5/6] dev: Use C11 mutex for SPI framework
Update #2776.
---
cpukit/dev/include/dev/spi/spi.h | 6 +++--
cpukit/dev/spi/spi-bus.c | 54 ++--
testsuites/libtests/spi01/init.c | 2 --
3 files changed, 22 insertions(+), 40 deletions(-)
diff --git a/cpukit/dev/include/dev/spi/spi.h b/cpukit/dev/include/dev/spi/spi.h
index 66bbac2..d5d1900 100644
--- a/cpukit/dev/include/dev/spi/spi.h
+++ b/cpukit/dev/include/dev/spi/spi.h
@@ -25,7 +25,9 @@
#include
-#include
+#include
+#include
+
#include
#ifdef __cplusplus
@@ -96,7 +98,7 @@ struct spi_bus {
/**
* @brief Mutex to protect the bus access.
*/
- rtems_id mutex;
+ mtx_t mutex;
/**
* @brief Maximum Speed in Hz
diff --git a/cpukit/dev/spi/spi-bus.c b/cpukit/dev/spi/spi-bus.c
index dd84b02..7f022f8 100644
--- a/cpukit/dev/spi/spi-bus.c
+++ b/cpukit/dev/spi/spi-bus.c
@@ -33,20 +33,20 @@
static void spi_bus_obtain(spi_bus *bus)
{
- rtems_status_code sc;
+ int error;
- sc = rtems_semaphore_obtain(bus->mutex, RTEMS_WAIT, RTEMS_NO_TIMEOUT);
- _Assert(sc == RTEMS_SUCCESSFUL);
- (void) sc;
+ error = mtx_lock(&bus->mutex);
+ _Assert(error == thrd_success);
+ (void) error;
}
static void spi_bus_release(spi_bus *bus)
{
- rtems_status_code sc;
+ int error;
- sc = rtems_semaphore_release(bus->mutex);
- _Assert(sc == RTEMS_SUCCESSFUL);
- (void) sc;
+ error = mtx_unlock(&bus->mutex);
+ _Assert(error == thrd_success);
+ (void) error;
}
static void spi_bus_set_defaults(spi_bus *bus, spi_ioc_transfer *msg)
@@ -298,39 +298,26 @@ static int spi_bus_setup_default(
return -EIO;
}
-static int spi_bus_do_init(
+static void spi_bus_do_init(
spi_bus *bus,
void (*destroy)(spi_bus *bus)
)
{
- rtems_status_code sc;
-
- sc = rtems_semaphore_create(
-rtems_build_name('S', 'P', 'I', ' '),
-1,
-RTEMS_BINARY_SEMAPHORE | RTEMS_INHERIT_PRIORITY | RTEMS_PRIORITY,
-0,
-&bus->mutex
- );
- if (sc != RTEMS_SUCCESSFUL) {
-(*destroy)(bus);
-rtems_set_errno_and_return_minus_one(ENOMEM);
- }
+ int error;
bus->transfer = spi_bus_transfer_default;
bus->setup = spi_bus_setup_default;
bus->destroy = destroy;
bus->bits_per_word = 8;
- return 0;
+
+ error = mtx_init(&bus->mutex, mtx_recursive);
+ _Assert(error == thrd_success);
+ (void) error;
}
void spi_bus_destroy(spi_bus *bus)
{
- rtems_status_code sc;
-
- sc = rtems_semaphore_delete(bus->mutex);
- _Assert(sc == RTEMS_SUCCESSFUL);
- (void) sc;
+ mtx_destroy(&bus->mutex);
}
void spi_bus_destroy_and_free(spi_bus *bus)
@@ -342,8 +329,8 @@ void spi_bus_destroy_and_free(spi_bus *bus)
int spi_bus_init(spi_bus *bus)
{
memset(bus, 0, sizeof(*bus));
-
- return spi_bus_do_init(bus, spi_bus_destroy);
+ spi_bus_do_init(bus, spi_bus_destroy);
+ return 0;
}
spi_bus *spi_bus_alloc_and_init(size_t size)
@@ -353,12 +340,7 @@ spi_bus *spi_bus_alloc_and_init(size_t size)
if (size >= sizeof(*bus)) {
bus = calloc(1, size);
if (bus != NULL) {
- int rv;
-
- rv = spi_bus_do_init(bus, spi_bus_destroy_and_free);
- if (rv != 0) {
-return NULL;
- }
+ spi_bus_do_init(bus, spi_bus_destroy_and_free);
}
}
diff --git a/testsuites/libtests/spi01/init.c b/testsuites/libtests/spi01/init.c
index 990d3ec..c08661b 100644
--- a/testsuites/libtests/spi01/init.c
+++ b/testsuites/libtests/spi01/init.c
@@ -277,8 +277,6 @@ static void Init(rtems_task_argument arg)
#define CONFIGURE_MAXIMUM_TASKS 1
-#define CONFIGURE_MAXIMUM_SEMAPHORES 1
-
#define CONFIGURE_INITIAL_EXTENSIONS RTEMS_TEST_INITIAL_EXTENSION
#define CONFIGURE_RTEMS_INIT_TASKS_TABLE
--
1.8.4.5
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 2/6] termios: Add TERMIOS_IRQ_SERVER_DRIVEN
From: Alexander Krutwig
Add a new interrupt server driven Termios mode (TERMIOS_IRQ_DRIVEN).
This mode is identical to the interrupt driven mode except that a mutex
is used for device level locking. The intended use case for this mode
are device drivers that use the interrupt server, e.g. SPI or I2C
connected devices.
Update #2839.
---
cpukit/libcsupport/include/rtems/termiostypes.h | 10 ++
cpukit/libcsupport/src/termios.c| 3 ++-
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/cpukit/libcsupport/include/rtems/termiostypes.h
b/cpukit/libcsupport/include/rtems/termiostypes.h
index 81d28c2..ffe172c 100644
--- a/cpukit/libcsupport/include/rtems/termiostypes.h
+++ b/cpukit/libcsupport/include/rtems/termiostypes.h
@@ -57,7 +57,8 @@ struct rtems_termios_rawbuf {
typedef enum {
TERMIOS_POLLED,
TERMIOS_IRQ_DRIVEN,
- TERMIOS_TASK_DRIVEN
+ TERMIOS_TASK_DRIVEN,
+ TERMIOS_IRQ_SERVER_DRIVEN
} rtems_termios_device_mode;
struct rtems_termios_tty;
@@ -74,7 +75,7 @@ typedef struct rtems_termios_device_context {
/* Used for TERMIOS_POLLED and TERMIOS_IRQ_DRIVEN */
rtems_interrupt_lock interrupt;
-/* Used for TERMIOS_TASK_DRIVEN */
+/* Used for TERMIOS_IRQ_SERVER_DRIVEN or TERMIOS_TASK_DRIVEN */
rtems_id mutex;
} lock;
@@ -161,8 +162,9 @@ typedef struct {
/**
* @brief Polled read.
*
- * In case mode is TERMIOS_IRQ_DRIVEN or TERMIOS_TASK_DRIVEN, then data is
- * received via rtems_termios_enqueue_raw_characters().
+ * In case mode is TERMIOS_IRQ_DRIVEN, TERMIOS_IRQ_SERVER_DRIVEN or
+ * TERMIOS_TASK_DRIVEN, then data is received via
+ * rtems_termios_enqueue_raw_characters().
*
* @param[in] context The Termios device context.
*
diff --git a/cpukit/libcsupport/src/termios.c b/cpukit/libcsupport/src/termios.c
index 3bc5bb8..d3757df 100644
--- a/cpukit/libcsupport/src/termios.c
+++ b/cpukit/libcsupport/src/termios.c
@@ -275,7 +275,8 @@ drainOutput (struct rtems_termios_tty *tty)
static bool
needDeviceMutex (rtems_termios_tty *tty)
{
- return tty->handler.mode == TERMIOS_TASK_DRIVEN;
+ return tty->handler.mode == TERMIOS_IRQ_SERVER_DRIVEN
+|| tty->handler.mode == TERMIOS_TASK_DRIVEN;
}
static void
--
1.8.4.5
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 4/6] termios: Use C11 mutex for global state
Update #2840.
---
cpukit/libcsupport/include/rtems/libio.h| 5 +++-
cpukit/libcsupport/include/rtems/termiostypes.h | 2 ++
cpukit/libcsupport/src/termios.c| 36 ++---
cpukit/libcsupport/src/termiosinitialize.c | 32 ++
cpukit/sapi/include/confdefs.h | 2 +-
testsuites/sptests/Makefile.am | 2 +-
testsuites/sptests/configure.ac | 1 -
testsuites/sptests/spfatal20/Makefile.am| 24 -
testsuites/sptests/spfatal20/spfatal20.doc | 19 -
testsuites/sptests/spfatal20/spfatal20.scn | 3 ---
testsuites/sptests/spfatal20/testcase.h | 22 ---
11 files changed, 18 insertions(+), 130 deletions(-)
delete mode 100644 testsuites/sptests/spfatal20/Makefile.am
delete mode 100644 testsuites/sptests/spfatal20/spfatal20.doc
delete mode 100644 testsuites/sptests/spfatal20/spfatal20.scn
delete mode 100644 testsuites/sptests/spfatal20/testcase.h
diff --git a/cpukit/libcsupport/include/rtems/libio.h
b/cpukit/libcsupport/include/rtems/libio.h
index a87031c..4310cba 100644
--- a/cpukit/libcsupport/include/rtems/libio.h
+++ b/cpukit/libcsupport/include/rtems/libio.h
@@ -1808,7 +1808,10 @@ typedef struct rtems_termios_callbacks {
intoutputUsesInterrupts;
} rtems_termios_callbacks;
-void rtems_termios_initialize (void);
+RTEMS_INLINE_ROUTINE void rtems_termios_initialize( void )
+{
+ /* Nothing to do, provided only for backward/forward compatibility */
+}
/*
* CCJ: Change before opening a tty. Newer code from Eric is coming
diff --git a/cpukit/libcsupport/include/rtems/termiostypes.h
b/cpukit/libcsupport/include/rtems/termiostypes.h
index 0a9da78..7ed6098 100644
--- a/cpukit/libcsupport/include/rtems/termiostypes.h
+++ b/cpukit/libcsupport/include/rtems/termiostypes.h
@@ -28,6 +28,8 @@
extern "C" {
#endif
+extern mtx_t rtems_termios_ttyMutex;
+
/**
* @defgroup TermiostypesSupport RTEMS Termios Device Support
*
diff --git a/cpukit/libcsupport/src/termios.c b/cpukit/libcsupport/src/termios.c
index 6ff6043..99bca7c 100644
--- a/cpukit/libcsupport/src/termios.c
+++ b/cpukit/libcsupport/src/termios.c
@@ -81,8 +81,6 @@ struct rtems_termios_linesw rtems_termios_linesw[MAXLDISC] =
int rtems_termios_nlinesw =
sizeof (rtems_termios_linesw) / sizeof (rtems_termios_linesw[0]);
-extern rtems_id rtems_termios_ttyMutex;
-
static size_t rtems_termios_cbufsize = 256;
static size_t rtems_termios_raw_input_size = 128;
static size_t rtems_termios_raw_output_size = 64;
@@ -156,21 +154,16 @@ inputUnlock (rtems_termios_tty *tty)
unlock (&tty->imtx);
}
-static rtems_status_code
+static void
rtems_termios_obtain (void)
{
- return rtems_semaphore_obtain (rtems_termios_ttyMutex, RTEMS_WAIT,
-RTEMS_NO_TIMEOUT);
+ lock (&rtems_termios_ttyMutex);
}
static void
rtems_termios_release (void)
{
- rtems_status_code sc;
-
- sc = rtems_semaphore_release (rtems_termios_ttyMutex);
- _Assert (sc == RTEMS_SUCCESSFUL);
- (void) sc;
+ unlock (&rtems_termios_ttyMutex);
}
rtems_status_code rtems_termios_device_install(
@@ -658,15 +651,13 @@ rtems_termios_open (
const rtems_termios_callbacks *callbacks
)
{
- rtems_status_code sc;
struct rtems_termios_tty *tty;
+ rtems_termios_obtain ();
+
/*
* See if the device has already been opened
*/
- sc = rtems_termios_obtain ();
- if (sc != RTEMS_SUCCESSFUL)
-return sc;
for (tty = rtems_termios_ttyHead ; tty != NULL ; tty = tty->forw) {
if ((tty->major == major) && (tty->minor == minor))
@@ -734,13 +725,10 @@ rtems_termios_close_tty (rtems_termios_tty *tty, void
*arg)
rtems_status_code
rtems_termios_close (void *arg)
{
- rtems_status_code sc;
rtems_libio_open_close_args_t *args = arg;
struct rtems_termios_tty *tty = args->iop->data1;
- sc = rtems_termios_obtain ();
- if (sc != RTEMS_SUCCESSFUL)
-rtems_fatal_error_occurred (sc);
+ rtems_termios_obtain ();
if (tty->refcount == 1) {
if (tty->forw == NULL) {
@@ -1912,7 +1900,6 @@ rtems_termios_imfs_open (rtems_libio_t *iop,
const char *path, int oflag, mode_t mode)
{
rtems_termios_device_node *device_node;
- rtems_status_code sc;
rtems_libio_open_close_args_t args;
struct rtems_termios_tty *tty;
@@ -1923,10 +1910,7 @@ rtems_termios_imfs_open (rtems_libio_t *iop,
args.flags = iop->flags;
args.mode = mode;
- sc = rtems_termios_obtain ();
- if (sc != RTEMS_SUCCESSFUL) {
-rtems_set_errno_and_return_minus_one (ENXIO);
- }
+ rtems_termios_obtain ();
tty = rtems_termios_open_tty (device_node->major, device_node->minor, &args,
device_node->tty, device_node, NULL);
@@ -1942,7 +1926,6 @@ rtems_termios_imfs_open (rtems_libio_t *iop,
static int
rtems_termios_imfs_close (rtems_libio_t *iop)
{
- rtems_status_code sc;
rtems_libio_open_close_args_t args;
struct rtems_termios_tty *tty;
@@ -1951,10 +1934,7 @@ rtems_termios_i
[PATCH 3/6] termios: Use C11 mutex for input/output
Use C11 mutexes instead of Classic semaphores as a performance
optimization and to simplify the application configuration.
A performance of Classic semaphores vs. C11 mutexes was measured on the
arm/atsam BSP. A NXP SC16IS752 was connected via SPI. The RTEMS
application used one task to read from the device and write it
immediately back (look back via task). A development system constantly
transmitted data at 115200 bits per second.
CPU usage by function with Classic semaphores:
name__|ratio___
CPU_Thread_Idle_body | 22.454%
atsam_spi_setup_transfer | 6.767%
Objects_Get | 5.859%
atsam_spi_interrupt | 4.483%
Event_Seize | 3.867%
rtems_termios_enqueue_raw_characters | 3.804%
Timecounter_Binuptime | 3.715%
Scheduler_priority_Block | 3.104%
rtems_semaphore_release | 3.018%
Scheduler_priority_Unblock| 2.901%
rtems_termios_read_tty| 2.777%
ARMV7M_NVIC_Interrupt_dispatch| 2.750%
rtems_semaphore_obtain| 2.627%
Thread_Do_dispatch| 2.351%
ARMV7M_Interrupt_service_leave| 2.086%
iproc | 1.919%
CPU usage by function with C11 mutexes:
name__|ratio___
CPU_Thread_Idle_body | 33.395%
atsam_spi_setup_transfer | 6.061%
atsam_spi_interrupt | 4.690%
Mutex_recursive_Release | 3.011%
Event_Seize | 2.955%
ARMV7M_NVIC_Interrupt_dispatch| 2.885%
rtems_termios_enqueue_raw_characters | 2.771%
rtems_termios_read_tty| 2.722%
Timecounter_Binuptime | 2.653%
Thread_Do_dispatch| 2.240%
Scheduler_priority_Block | 2.112%
ARMV7M_Interrupt_service_leave| 2.100%
Scheduler_priority_Unblock| 1.919%
Mutex_recursive_Acquire | 1.876%
iproc | 1.773%
The change resulted in 10% more total idle time on the system.
Update #2840.
---
cpukit/libcsupport/include/rtems/termiostypes.h | 7 +-
cpukit/libcsupport/src/termios.c| 159
cpukit/sapi/include/confdefs.h | 2 +-
testsuites/sptests/Makefile.am | 2 +-
testsuites/sptests/configure.ac | 2 -
testsuites/sptests/spfatal18/Makefile.am| 24
testsuites/sptests/spfatal18/spfatal18.doc | 19 ---
testsuites/sptests/spfatal18/spfatal18.scn | 3 -
testsuites/sptests/spfatal18/testcase.h | 25
testsuites/sptests/spfatal19/Makefile.am| 24
testsuites/sptests/spfatal19/spfatal19.doc | 19 ---
testsuites/sptests/spfatal19/spfatal19.scn | 3 -
testsuites/sptests/spfatal19/testcase.h | 25
13 files changed, 85 insertions(+), 229 deletions(-)
delete mode 100644 testsuites/sptests/spfatal18/Makefile.am
delete mode 100644 testsuites/sptests/spfatal18/spfatal18.doc
delete mode 100644 testsuites/sptests/spfatal18/spfatal18.scn
delete mode 100644 testsuites/sptests/spfatal18/testcase.h
delete mode 100644 testsuites/sptests/spfatal19/Makefile.am
delete mode 100644 testsuites/sptests/spfatal19/spfatal19.doc
delete mode 100644 testsuites/sptests/spfatal19/spfatal19.scn
delete mode 100644 testsuites/sptests/spfatal19/testcase.h
diff --git a/cpukit/libcsupport/include/rtems/termiostypes.h
b/cpukit/libcsupport/include/rtems/termiostypes.h
index ffe172c..0a9da78 100644
--- a/cpukit/libcsupport/include/rtems/termiostypes.h
+++ b/cpukit/libcsupport/include/rtems/termiostypes.h
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#ifdef __cplusplus
extern "C" {
@@ -76,7 +77,7 @@ typedef struct rtems_termios_device_context {
rtems_interrupt_lock interrupt;
/* Used for TERMIOS_IRQ_SERVER_DRIVEN or TERMIOS_TASK_DRIVEN */
-rtems_id mutex;
+mtx_t mutex;
} lock;
void ( *lock_acquire )(
@@ -283,8 +284,8 @@ typedef struct rtems_termios_tty {
/*
* Mutual-exclusion semaphores
*/
- rtems_id isem;
- rtems_id osem;
+ mtx_t imtx;
+ mtx_t omtx;
/*
* The canonical (cooked) character buffer
diff --git a/cpukit/libcsupport/src/termios.c b/cpukit/libcsupport/src/termios.c
index d3757df..6ff6043 100644
--- a/cpukit/libcsupport/src/termios.c
+++ b/cpukit/libcsupport/src/termios.c
@@ -112,6 +112,50 @@ static rtems_task
rtems_termios_txdaemon(rtems_task_argument argument);
#define TERMIOS_RX_PROC_EVENT RTEMS_EVENT_1
#define TERMIOS_RX_TERMINATE_EVENT RTEMS_EVENT_0
+static void
+lock (mtx_t *mtx)
+{
+ int error;
+
+ error = mtx_lock (mtx);
+ _Assert (error == thrd_success);
+ (void)error;
+
[PATCH 1/6] termios: Use mutex for task driven mode
Termios has a task driven mode (TERMIOS_TASK_DRIVEN). This mode aims to
avoid long sections with disabled interrupts. This is only partly
implemented since the device level state is still protected by disabled
interrupts. Use a mutex to protect the device level state in task driven
mode to fix this issue.
Update #2838.
---
cpukit/libcsupport/include/rtems/termiostypes.h | 26 +++--
cpukit/libcsupport/src/termios.c| 78 -
2 files changed, 97 insertions(+), 7 deletions(-)
diff --git a/cpukit/libcsupport/include/rtems/termiostypes.h
b/cpukit/libcsupport/include/rtems/termiostypes.h
index a852c1d..81d28c2 100644
--- a/cpukit/libcsupport/include/rtems/termiostypes.h
+++ b/cpukit/libcsupport/include/rtems/termiostypes.h
@@ -70,7 +70,23 @@ struct rtems_termios_tty;
* rtems_termios_device_install().
*/
typedef struct rtems_termios_device_context {
- rtems_interrupt_lock interrupt_lock;
+ union {
+/* Used for TERMIOS_POLLED and TERMIOS_IRQ_DRIVEN */
+rtems_interrupt_lock interrupt;
+
+/* Used for TERMIOS_TASK_DRIVEN */
+rtems_id mutex;
+ } lock;
+
+ void ( *lock_acquire )(
+struct rtems_termios_device_context *,
+rtems_interrupt_lock_context *
+ );
+
+ void ( *lock_release )(
+struct rtems_termios_device_context *,
+rtems_interrupt_lock_context *
+ );
} rtems_termios_device_context;
/**
@@ -86,7 +102,7 @@ RTEMS_INLINE_ROUTINE void
rtems_termios_device_context_initialize(
const char *name
)
{
- rtems_interrupt_lock_initialize( &context->interrupt_lock, name );
+ rtems_interrupt_lock_initialize( &context->lock.interrupt, name );
}
/**
@@ -96,7 +112,7 @@ RTEMS_INLINE_ROUTINE void
rtems_termios_device_context_initialize(
* is only used if profiling is enabled.
*/
#define RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER( name ) \
- { RTEMS_INTERRUPT_LOCK_INITIALIZER( name ) }
+ { { RTEMS_INTERRUPT_LOCK_INITIALIZER( name ) } }
/**
* @brief Termios device handler.
@@ -408,7 +424,7 @@ RTEMS_INLINE_ROUTINE void rtems_termios_device_lock_acquire(
rtems_interrupt_lock_context *lock_context
)
{
- rtems_interrupt_lock_acquire( &context->interrupt_lock, lock_context );
+ ( *context->lock_acquire )( context, lock_context );
}
/**
@@ -423,7 +439,7 @@ RTEMS_INLINE_ROUTINE void rtems_termios_device_lock_release(
rtems_interrupt_lock_context *lock_context
)
{
- rtems_interrupt_lock_release( &context->interrupt_lock, lock_context );
+ ( *context->lock_release )( context, lock_context );
}
/**
diff --git a/cpukit/libcsupport/src/termios.c b/cpukit/libcsupport/src/termios.c
index b972b4f..3bc5bb8 100644
--- a/cpukit/libcsupport/src/termios.c
+++ b/cpukit/libcsupport/src/termios.c
@@ -272,6 +272,12 @@ drainOutput (struct rtems_termios_tty *tty)
}
}
+static bool
+needDeviceMutex (rtems_termios_tty *tty)
+{
+ return tty->handler.mode == TERMIOS_TASK_DRIVEN;
+}
+
static void
rtems_termios_destroy_tty (rtems_termios_tty *tty, void *arg, bool last_close)
{
@@ -318,8 +324,11 @@ rtems_termios_destroy_tty (rtems_termios_tty *tty, void
*arg, bool last_close)
(tty->handler.mode == TERMIOS_TASK_DRIVEN))
rtems_semaphore_delete (tty->rawInBuf.Semaphore);
- if (tty->device_context == &tty->legacy_device_context)
-rtems_interrupt_lock_destroy (&tty->legacy_device_context.interrupt_lock);
+ if (needDeviceMutex (tty)) {
+rtems_semaphore_delete (tty->device_context->lock.mutex);
+ } else if (tty->device_context == &tty->legacy_device_context) {
+rtems_interrupt_lock_destroy (&tty->legacy_device_context.lock.interrupt);
+ }
free (tty->rawInBuf.theBuf);
free (tty->rawOutBuf.theBuf);
@@ -327,6 +336,50 @@ rtems_termios_destroy_tty (rtems_termios_tty *tty, void
*arg, bool last_close)
free (tty);
}
+static void
+deviceAcquireMutex(
+ rtems_termios_device_context *ctx,
+ rtems_interrupt_lock_context *lock_context
+)
+{
+ rtems_status_code sc;
+
+ sc = rtems_semaphore_obtain (ctx->lock.mutex, RTEMS_WAIT, RTEMS_NO_TIMEOUT);
+ _Assert (sc == RTEMS_SUCCESSFUL);
+ (void) sc;
+}
+
+static void
+deviceReleaseMutex(
+ rtems_termios_device_context *ctx,
+ rtems_interrupt_lock_context *lock_context
+)
+{
+ rtems_status_code sc;
+
+ sc = rtems_semaphore_release (ctx->lock.mutex);
+ _Assert (sc == RTEMS_SUCCESSFUL);
+ (void) sc;
+}
+
+static void
+deviceAcquireInterrupt(
+ rtems_termios_device_context *ctx,
+ rtems_interrupt_lock_context *lock_context
+)
+{
+ rtems_interrupt_lock_acquire (&ctx->lock.interrupt, lock_context);
+}
+
+static void
+deviceReleaseInterrupt(
+ rtems_termios_device_context *ctx,
+ rtems_interrupt_lock_context *lock_context
+)
+{
+ rtems_interrupt_lock_release (&ctx->lock.interrupt, lock_context);
+}
+
static rtems_termios_tty *
rtems_termios_open_tty(
rtems_device_major_number major,
@@ -341,6 +394,7 @@ rtems_termios_open_tty(
if (tty == NULL) {
static char c = 'a';
+rtems_termios_device_context *ctx;
[PATCH 6/6] dev: Use C11 mutex for I2C framework
---
cpukit/dev/i2c/i2c-bus.c | 54 +---
cpukit/dev/include/dev/i2c/i2c.h | 4 ++-
testsuites/libtests/i2c01/init.c | 2 --
3 files changed, 20 insertions(+), 40 deletions(-)
diff --git a/cpukit/dev/i2c/i2c-bus.c b/cpukit/dev/i2c/i2c-bus.c
index 0f27d06..696bef5 100644
--- a/cpukit/dev/i2c/i2c-bus.c
+++ b/cpukit/dev/i2c/i2c-bus.c
@@ -33,20 +33,20 @@
void i2c_bus_obtain(i2c_bus *bus)
{
- rtems_status_code sc;
+ int error;
- sc = rtems_semaphore_obtain(bus->mutex, RTEMS_WAIT, RTEMS_NO_TIMEOUT);
- _Assert(sc == RTEMS_SUCCESSFUL);
- (void) sc;
+ error = mtx_lock(&bus->mutex);
+ _Assert(error == thrd_success);
+ (void) error;
}
void i2c_bus_release(i2c_bus *bus)
{
- rtems_status_code sc;
+ int error;
- sc = rtems_semaphore_release(bus->mutex);
- _Assert(sc == RTEMS_SUCCESSFUL);
- (void) sc;
+ error = mtx_unlock(&bus->mutex);
+ _Assert(error == thrd_success);
+ (void) error;
}
int i2c_bus_transfer(i2c_bus *bus, i2c_msg *msgs, uint32_t msg_count)
@@ -280,40 +280,25 @@ static int i2c_bus_set_clock_default(i2c_bus *bus,
unsigned long clock)
return -EIO;
}
-static int i2c_bus_do_init(
+static void i2c_bus_do_init(
i2c_bus *bus,
void (*destroy)(i2c_bus *bus)
)
{
- rtems_status_code sc;
-
- sc = rtems_semaphore_create(
-rtems_build_name('I', '2', 'C', ' '),
-1,
-RTEMS_BINARY_SEMAPHORE | RTEMS_INHERIT_PRIORITY | RTEMS_PRIORITY,
-0,
-&bus->mutex
- );
- if (sc != RTEMS_SUCCESSFUL) {
-(*destroy)(bus);
-
-rtems_set_errno_and_return_minus_one(ENOMEM);
- }
+ int error;
bus->transfer = i2c_bus_transfer_default;
bus->set_clock = i2c_bus_set_clock_default;
bus->destroy = destroy;
- return 0;
+ error = mtx_init(&bus->mutex, mtx_recursive);
+ _Assert(error == thrd_success);
+ (void) error;
}
void i2c_bus_destroy(i2c_bus *bus)
{
- rtems_status_code sc;
-
- sc = rtems_semaphore_delete(bus->mutex);
- _Assert(sc == RTEMS_SUCCESSFUL);
- (void) sc;
+ mtx_destroy(&bus->mutex);
}
void i2c_bus_destroy_and_free(i2c_bus *bus)
@@ -325,8 +310,8 @@ void i2c_bus_destroy_and_free(i2c_bus *bus)
int i2c_bus_init(i2c_bus *bus)
{
memset(bus, 0, sizeof(*bus));
-
- return i2c_bus_do_init(bus, i2c_bus_destroy);
+ i2c_bus_do_init(bus, i2c_bus_destroy);
+ return 0;
}
i2c_bus *i2c_bus_alloc_and_init(size_t size)
@@ -336,12 +321,7 @@ i2c_bus *i2c_bus_alloc_and_init(size_t size)
if (size >= sizeof(*bus)) {
bus = calloc(1, size);
if (bus != NULL) {
- int rv;
-
- rv = i2c_bus_do_init(bus, i2c_bus_destroy_and_free);
- if (rv != 0) {
-return NULL;
- }
+ i2c_bus_do_init(bus, i2c_bus_destroy_and_free);
}
}
diff --git a/cpukit/dev/include/dev/i2c/i2c.h b/cpukit/dev/include/dev/i2c/i2c.h
index 2ace4fc..6180a3f 100644
--- a/cpukit/dev/include/dev/i2c/i2c.h
+++ b/cpukit/dev/include/dev/i2c/i2c.h
@@ -32,6 +32,8 @@
#include
#include
+#include
+
#ifdef __cplusplus
extern "C" {
#endif /* __cplusplus */
@@ -139,7 +141,7 @@ struct i2c_bus {
/**
* @brief Mutex to protect the bus access.
*/
- rtems_id mutex;
+ mtx_t mutex;
/**
* @brief Default slave device address.
diff --git a/testsuites/libtests/i2c01/init.c b/testsuites/libtests/i2c01/init.c
index 0d6fc83..30e249d 100644
--- a/testsuites/libtests/i2c01/init.c
+++ b/testsuites/libtests/i2c01/init.c
@@ -659,8 +659,6 @@ static void Init(rtems_task_argument arg)
#define CONFIGURE_MAXIMUM_TASKS 1
-#define CONFIGURE_MAXIMUM_SEMAPHORES 1
-
#define CONFIGURE_INIT_TASK_STACK_SIZE (RTEMS_MINIMUM_STACK_SIZE + 2 *
EEPROM_SIZE)
#define CONFIGURE_INITIAL_EXTENSIONS RTEMS_TEST_INITIAL_EXTENSION
--
1.8.4.5
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Update Atsam BSP Support
I would like to refresh this topic. On 05/10/16 16:17, Gedare Bloom wrote: That makes sense. On Wed, Oct 5, 2016 at 1:17 AM, Sebastian Huber wrote: >One way to keep this in sync would be to simply write the README of each BSP >in a certain format, e.g. trac wiki and then simply include the content from >Git in trac. For example via a modified variant of > >https://trac.edgewall.org/attachment/wiki/MacroBazaar/Include.3.py > > >Something like this in trac: > >[[RTEMSGitInclude(c/src/lib/libbsp/arm/atsam/README)]] > Would it be possible to add such a Trac add-on? I guess I can modify it so that it works for our purpose, but I don't know how to install it. It would be quite nice if we can write BSP README files in reStructuredText placed in the Git repository that show up on the wiki. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] dev: Add NXP SC16IS752 serial device driver
From: Alexander Krutwig
Update #2841.
---
cpukit/dev/Makefile.am| 7 +
cpukit/dev/include/dev/serial/nxp-sc16is752.h | 165 +
cpukit/dev/preinstall.am | 9 +
cpukit/dev/serial/nxp-sc16is752-regs.h| 108 +++
cpukit/dev/serial/nxp-sc16is752-spi.c | 126 +
cpukit/dev/serial/nxp-sc16is752.c | 257 ++
6 files changed, 672 insertions(+)
create mode 100644 cpukit/dev/include/dev/serial/nxp-sc16is752.h
create mode 100644 cpukit/dev/serial/nxp-sc16is752-regs.h
create mode 100644 cpukit/dev/serial/nxp-sc16is752-spi.c
create mode 100644 cpukit/dev/serial/nxp-sc16is752.c
diff --git a/cpukit/dev/Makefile.am b/cpukit/dev/Makefile.am
index 2b65390..cdc3fe8 100644
--- a/cpukit/dev/Makefile.am
+++ b/cpukit/dev/Makefile.am
@@ -15,6 +15,10 @@ include_dev_spidir = $(includedir)/dev/spi
include_dev_spi_HEADERS =
include_dev_spi_HEADERS += include/dev/spi/spi.h
+include_dev_serialdir = $(includedir)/dev/serial
+include_dev_serial_HEADERS =
+include_dev_serial_HEADERS += include/dev/serial/nxp-sc16is752.h
+
include_linuxdir = $(includedir)/linux
include_linux_HEADERS =
include_linux_HEADERS += include/linux/i2c.h
@@ -33,6 +37,9 @@ libdev_a_SOURCES += i2c/i2c-bus.c
libdev_a_SOURCES += i2c/i2c-dev.c
libdev_a_SOURCES += i2c/switch-nxp-pca9548a.c
libdev_a_SOURCES += spi/spi-bus.c
+libdev_a_SOURCES += serial/nxp-sc16is752.c
+libdev_a_SOURCES += serial/nxp-sc16is752-spi.c
+libdev_a_SOURCES += serial/nxp-sc16is752-regs.h
include $(srcdir)/preinstall.am
include $(top_srcdir)/automake/local.am
diff --git a/cpukit/dev/include/dev/serial/nxp-sc16is752.h
b/cpukit/dev/include/dev/serial/nxp-sc16is752.h
new file mode 100644
index 000..9d6cc59
--- /dev/null
+++ b/cpukit/dev/include/dev/serial/nxp-sc16is752.h
@@ -0,0 +1,165 @@
+/*
+ * Copyright (c) 2016 embedded brains GmbH. All rights reserved.
+ *
+ * embedded brains GmbH
+ * Dornierstr. 4
+ * 82178 Puchheim
+ * Germany
+ *
+ *
+ * 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 _DEV_SERIAL_SC16IS752_H
+#define _DEV_SERIAL_SC16IS752_H
+
+#include
+
+#ifdef __cplusplus
+extern "C" {
+#endif /* __cplusplus */
+
+/**
+ * @defgroup NXP-SC16IS752 Device Support
+ *
+ * @ingroup TermiostypesSupport
+ *
+ * @brief NXP-SC16IS752 Device Support Internal Data Structures
+ */
+
+typedef struct sc16is752_context sc16is752_context;
+
+/**
+ * @brief SC16IS752 device context.
+ */
+struct sc16is752_context {
+ rtems_termios_device_context base;
+
+ int (*write_reg)(
+sc16is752_context *ctx,
+uint8_t addr,
+const uint8_t *data,
+size_t len
+ );
+
+ int (*read_reg)(
+sc16is752_context *ctx,
+uint8_t addr,
+uint8_t *data,
+size_t len
+ );
+
+ bool (*first_open)(sc16is752_context *ctx);
+
+ void (*last_close)(sc16is752_context *ctx);
+
+ /**
+ * @brief Interrupt install handler must be given by user before termios
device
+ * creation.
+ */
+ bool (*install_irq)(sc16is752_context *ctx);
+
+ /**
+ * @brief Interrupt remove handler must be given by user before termios
device
+ * creation.
+ */
+ void (*remove_irq)(sc16is752_context *ctx);
+
+ /**
+ * @brief Mode must be given by user before termios device creation.
+ */
+ enum {
+SC16IS752_MODE_RS232,
+SC16IS752_MODE_RS485
+ } mode;
+
+ /**
+ * @brief Input frequency (dependent on crystal) must be given by user before
+ * termios device creation
+ */
+ uint32_t input_frequency;
+
+ rtems_termios_tty *tty;
+
+ /**
+ * @brief Shadow interrupt enable register (IER).
+ */
+ uint8_t ier;
+
+ /**
+ * @brief Characters placed into transmit FIFO.
+ */
+ uint8_t tx_in_progress;
+
+ /**
+ * @brief Count of free characters in the transmit FIFO.
+ */
+ uint8_t tx_fifo_free;
+};
+
+/**
+ * @brief SC16IS752 SPI context.
+ */
+typedef struct {
+ sc16is752_context base;
+
+ int fd;
+
+ /*
+ * @brief chip select shall be set by user before spi bus creation.
+ */
+ uint8_t cs;
+
+ /*
+ * @brief Message speed shall be set by user before spi bus creation.
+ */
+ uint32_t speed_hz;
+
+ /*
+ * SPI bus path shall be provided by the user before spi bus creation.
+ */
+ const char *spi_path;
+} sc16is752_spi_context;
+
+/**
+ * @brief SC16IS752 I2C context.
+ */
+typedef struct {
+ sc16is752_context base;
+ int fd;
+ /*
+ * SPI bus path shall be provided by the user before i2c bus creation.
+ */
+ const char *bus_path;
+} sc16is752_i2c_context;
+
+const rtems_termios_device_handler sc16is752_termios_handler;
+
+/**
+ * @brief The interrupt handler for receive and transmit operations.
+ *
+ * @param[in] arg Function argument.
+ */
+void sc16is752_interrupt_handler(void *arg);
+
+/**
+ * @brief Creates a termios device that runs in polled mode.
+ *
+ * @param[in] spi_ctx Poin
C11 Re: [PATCH 3/6] termios: Use C11 mutex for input/output
On 15/12/2016 00:39, Sebastian Huber wrote: Use C11 mutexes instead of Classic semaphores as a performance optimization and to simplify the application configuration. The use of C11 mutexes has not been agreed too and we need to discuss this in more detail before we allow use within RTEMS. I would like to see positive agreement from all core maintainers before this and similar patches can be merged. RTEMS has required the use of the Classic API because: 1. Available on all architectures, BSPs and tool sets. 2. Always present in a build. 3. Was considered faster than POSIX. The Classic API provides a base level of required functionality because it is always available in supported tool sets and leads to the smallest footprint because we do not need to link in more than one API. I understand things change and move on so it is great to see this change being proposed and our existing base line being challenged. I see from your performance figures C11 mutexes are better and the resources are allocated as needed and used which is a better model than the Classic API's configuration table. This is nice. Do all architectures and BSPs have working C11 support? Is there tests in the RTEMS testsuite for C11 threading services? What target resources are used to support this API, ie code and RAM usage? Would the "tiny" footprint be smaller if all internal services including compiler thread support are made C11? Could this actually be done? Parts of POSIX has been creeping in over time so the position is a little confused at the moment. I am not sure about a bits and pieces approach, maybe a full switch is made. Does C11 work on LLVM (I hear support is close)? Where is the C11 API implemented? Is the threading code outside the RTEMS source tree and what effect does that have on those looking to certify RTEMS? Does a change like this require a coding standard update? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: C11 Re: [PATCH 3/6] termios: Use C11 mutex for input/output
Can someone help clarify the issue? Is this a “required compiler to build RTEMS” question? That is, are the compilers currently required to build the RTEMS Sebastian modified guaranteed to support C11 mutexes, and is it desirable to be more conservative about what compiler is needed? If C11 mutexes guarantee what Sebastian needs and unknown compiler support isn’t required then allow it. Note that I haven’t researched this, I’m just guessing that the C11 mutexes may guarantee less than the classic semaphores, and are being implemented at the compiler level, and that this minimum level of compiler support is OK for building RTEMS. > On Dec 14, 2016, at 16:15 , Chris Johns wrote: > > On 15/12/2016 00:39, Sebastian Huber wrote: >> Use C11 mutexes instead of Classic semaphores as a performance >> optimization and to simplify the application configuration. > > The use of C11 mutexes has not been agreed too and we need to discuss > this in more detail before we allow use within RTEMS. I would like to > see positive agreement from all core maintainers before this and similar > patches can be merged. > > RTEMS has required the use of the Classic API because: > > 1. Available on all architectures, BSPs and tool sets. > 2. Always present in a build. > 3. Was considered faster than POSIX. > > The Classic API provides a base level of required functionality because > it is always available in supported tool sets and leads to the smallest > footprint because we do not need to link in more than one API. > > I understand things change and move on so it is great to see this change > being proposed and our existing base line being challenged. > > I see from your performance figures C11 mutexes are better and the > resources are allocated as needed and used which is a better model than > the Classic API's configuration table. This is nice. > > Do all architectures and BSPs have working C11 support? > > Is there tests in the RTEMS testsuite for C11 threading services? > > What target resources are used to support this API, ie code and RAM usage? > > Would the "tiny" footprint be smaller if all internal services including > compiler thread support are made C11? Could this actually be done? Parts > of POSIX has been creeping in over time so the position is a little > confused at the moment. I am not sure about a bits and pieces approach, > maybe a full switch is made. > > Does C11 work on LLVM (I hear support is close)? > > Where is the C11 API implemented? Is the threading code outside the > RTEMS source tree and what effect does that have on those looking to > certify RTEMS? > > Does a change like this require a coding standard update? > > Chris > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel Peter - Peter Dufault HD Associates, Inc. Software and System Engineering This email, like most email, is delivered unencrypted via internet email protocols subject to interception and tampering. Contact HDA to discuss methods we can use that ensure secure communication. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] dev: Add NXP SC16IS752 serial device driver
On 15/12/2016 01:23, Sebastian Huber wrote: From: Alexander Krutwig Update #2841. --- cpukit/dev/Makefile.am| 7 + cpukit/dev/include/dev/serial/nxp-sc16is752.h | 165 + cpukit/dev/preinstall.am | 9 + cpukit/dev/serial/nxp-sc16is752-regs.h| 108 +++ cpukit/dev/serial/nxp-sc16is752-spi.c | 126 + cpukit/dev/serial/nxp-sc16is752.c | 257 ++ 6 files changed, 672 insertions(+) create mode 100644 cpukit/dev/include/dev/serial/nxp-sc16is752.h create mode 100644 cpukit/dev/serial/nxp-sc16is752-regs.h create mode 100644 cpukit/dev/serial/nxp-sc16is752-spi.c create mode 100644 cpukit/dev/serial/nxp-sc16is752.c I see this change adds serial drivers to the cpukit/dev tree. Is this where all new serial drivers are to be located? I am happy to see this happen but we need suitable documentation about this and any rules etc developers need to know including "add all new serial drivers here". Do we have documentation about the cpukit/dev tree? What happens to the existing drivers we have in libchip and other locations? Is the aim to have all driver move to cpukit/dev? For the record I support the cpukit/dev driver tree and think libchip should be removed. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Update Atsam BSP Support
On 15/12/2016 00:54, Sebastian Huber wrote: I would like to refresh this topic. On 05/10/16 16:17, Gedare Bloom wrote: That makes sense. On Wed, Oct 5, 2016 at 1:17 AM, Sebastian Huber wrote: >One way to keep this in sync would be to simply write the README of each BSP >in a certain format, e.g. trac wiki and then simply include the content from >Git in trac. For example via a modified variant of > >https://trac.edgewall.org/attachment/wiki/MacroBazaar/Include.3.py > > >Something like this in trac: > >[[RTEMSGitInclude(c/src/lib/libbsp/arm/atsam/README)]] > Would it be possible to add such a Trac add-on? I guess I can modify it so that it works for our purpose, but I don't know how to install it. Lets see if this is the way we should go before we head down this path. Any support added needs to be secure and this simple issue complicates what we can or should use in Trac. It would be quite nice if we can write BSP README files in reStructuredText placed in the Git repository that show up on the wiki. I support using the ReST format. I am not convinced the Wiki is the best place to land this documentation. These READMEs are really good documentation and we need better BSP documentation. Having it included in the release documentation would be nice. Why not add this documentation to the rtems-docs.git repo? Having the BSP doco in the rtems-docs.git repo means we can make and publish the doc formats we support, ie HTML and PDF, because that repo has all the support needed to build the documentation. It is also supported as part of the release procedure. If the desire is to keep this documentation close to the source, which is attractive, and using rtems-docs.git is a good idea then we need to figure out how to handle this. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Update Atsam BSP Support
On 15/12/16 01:24, Chris Johns wrote: On 15/12/2016 00:54, Sebastian Huber wrote: I would like to refresh this topic. On 05/10/16 16:17, Gedare Bloom wrote: That makes sense. On Wed, Oct 5, 2016 at 1:17 AM, Sebastian Huber wrote: >One way to keep this in sync would be to simply write the README of each BSP >in a certain format, e.g. trac wiki and then simply include the content from >Git in trac. For example via a modified variant of > >https://trac.edgewall.org/attachment/wiki/MacroBazaar/Include.3.py > > >Something like this in trac: > >[[RTEMSGitInclude(c/src/lib/libbsp/arm/atsam/README)]] > Would it be possible to add such a Trac add-on? I guess I can modify it so that it works for our purpose, but I don't know how to install it. Lets see if this is the way we should go before we head down this path. Any support added needs to be secure and this simple issue complicates what we can or should use in Trac. Yes. It would be quite nice if we can write BSP README files in reStructuredText placed in the Git repository that show up on the wiki. I support using the ReST format. I am not convinced the Wiki is the best place to land this documentation. These READMEs are really good documentation and we need better BSP documentation. Having it included in the release documentation would be nice. We already have BSP documentation on the wiki. We have also BSP documentation in the README files. What we really need is to document things only once for a specific domain and present it to the user where it expects the information. Using README files in ReST format gives us the opportunity to present the same information * in the source tree as a simple text file, * in the wiki via plug-in, and * in a user manual via sphinx. Why not add this documentation to the rtems-docs.git repo? Why not move the documentation back into the rtems.git repo? I think is it very nice if you have the BSP sources and a basic documentation in the same directory. Having the BSP doco in the rtems-docs.git repo means we can make and publish the doc formats we support, ie HTML and PDF, because that repo has all the support needed to build the documentation. It is also supported as part of the release procedure. If the desire is to keep this documentation close to the source, which is attractive, and using rtems-docs.git is a good idea then we need to figure out how to handle this. I still think that it was not good to move the documentation sources into a separate repository. We have a lot of copy and paste in the documentation and duplicated information in the header files and the documentation files. One option to simplify this would be a XML file which defines and documents the RTEMS interfaces (data types, functions, defines, macros, etc.) and then use a generator to produce header (maybe even with Doxygen comments) files, documentation files and also test cases. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] dev: Add NXP SC16IS752 serial device driver
On 14/12/16 22:59, Chris Johns wrote: On 15/12/2016 01:23, Sebastian Huber wrote: From: Alexander Krutwig Update #2841. --- cpukit/dev/Makefile.am| 7 + cpukit/dev/include/dev/serial/nxp-sc16is752.h | 165 + cpukit/dev/preinstall.am | 9 + cpukit/dev/serial/nxp-sc16is752-regs.h| 108 +++ cpukit/dev/serial/nxp-sc16is752-spi.c | 126 + cpukit/dev/serial/nxp-sc16is752.c | 257 ++ 6 files changed, 672 insertions(+) create mode 100644 cpukit/dev/include/dev/serial/nxp-sc16is752.h create mode 100644 cpukit/dev/serial/nxp-sc16is752-regs.h create mode 100644 cpukit/dev/serial/nxp-sc16is752-spi.c create mode 100644 cpukit/dev/serial/nxp-sc16is752.c I see this change adds serial drivers to the cpukit/dev tree. Yes, and it was in total more than one man month of work to make this possible. Its not a small thing. Is this where all new serial drivers are to be located? I am happy to see this happen but we need suitable documentation about this and any rules etc developers need to know including "add all new serial drivers here". The preferred place for drivers should be the cpukit. We need however a suitable abstraction of the low-level hardware access. We don't have this at the moment except for I2C and SPI. Do we have documentation about the cpukit/dev tree? Documentation of the new SPI and I2C frameworks is on my todo list. I will add some notes to the console driver chapter. What happens to the existing drivers we have in libchip and other locations? Is the aim to have all driver move to cpukit/dev? Yes, this should be the aim, however, I don't see that anyone has time to do this. I already spend more than one man week in vain to do this and eventually gave up. For the record I support the cpukit/dev driver tree and think libchip should be removed. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: C11 Re: [PATCH 3/6] termios: Use C11 mutex for input/output
On 14/12/16 22:43, Peter Dufault wrote: Can someone help clarify the issue? Is this a “required compiler to build RTEMS” question? That is, are the compilers currently required to build the RTEMS Sebastian modified guaranteed to support C11 mutexes, and is it desirable to be more conservative about what compiler is needed? If C11 mutexes guarantee what Sebastian needs and unknown compiler support isn’t required then allow it. Note that I haven’t researched this, I’m just guessing that the C11 mutexes may guarantee less than the classic semaphores, and are being implemented at the compiler level, and that this minimum level of compiler support is OK for building RTEMS. The C11 support is not a compiler issue. The is a part of the C standard library and for RTEMS this header file is provided by Newlib: https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/include/threads.h;h=9fb08b03d1eb20024c0d680a7924336ec7ea57bb;hb=HEAD This header file is compatible to C89 (with the next Newlib release). I imported several parts of the FreeBSD for this purpose. The C11 provided functions are implemented in RTEMS: https://git.rtems.org/rtems/tree/cpukit/libstdthreads -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: C11 Re: [PATCH 3/6] termios: Use C11 mutex for input/output
On 14/12/16 22:15, Chris Johns wrote: On 15/12/2016 00:39, Sebastian Huber wrote: Use C11 mutexes instead of Classic semaphores as a performance optimization and to simplify the application configuration. The use of C11 mutexes has not been agreed too and we need to discuss this in more detail before we allow use within RTEMS. I would like to see positive agreement from all core maintainers before this and similar patches can be merged. A patch is a good thing to start such a discussion. RTEMS has required the use of the Classic API because: 1. Available on all architectures, BSPs and tool sets. 2. Always present in a build. 3. Was considered faster than POSIX. 3. is not the case. From an API point of view the POSIX operations could be faster than the Classic API since the parameter evaluation is simpler. The Classic API provides a base level of required functionality because it is always available in supported tool sets and leads to the smallest footprint because we do not need to link in more than one API. Compared to self-contained objects (like the C11 mutexes for example) the overhead of the Classic objects is huge in terms of run-time, memory footprint, code size (object administration) and complexity (object administration, use of a heap, unlimited objects, configuration). I understand things change and move on so it is great to see this change being proposed and our existing base line being challenged. I see from your performance figures C11 mutexes are better and the resources are allocated as needed and used which is a better model than the Classic API's configuration table. This is nice. Do all architectures and BSPs have working C11 support? Yes, all architectures and BSPs support the C11 mutexes, condition variables, thread-specific storage (mapped to POSIX keys), once support (mapped to POSIX once) in all configurations. The C11 threads are mapped to POSIX threads (for simplicity, not a hard requirement). Is there tests in the RTEMS testsuite for C11 threading services? https://git.rtems.org/rtems/tree/testsuites/sptests/spstdthreads01/init.c What target resources are used to support this API, ie code and RAM usage? On a 32-bit target: (gdb) p sizeof(Semaphore_Control) $1 = 72 (gdb) p sizeof(mtx_t) $2 = 20 With Thumb-2 instruction set: size ./arm-rtems4.12/c/atsamv/cpukit/score/src/libscore_a-mutex.o ./arm-rtems4.12/c/atsamv/cpukit/score/src/libscore_a-condition.o ./arm-rtems4.12/c/atsamv/cpukit/libstdthreads/libstdthreads_a-*.o textdata bss dec hex filename 704 0 0 704 2c0 ./arm-rtems4.12/c/atsamv/cpukit/score/src/libscore_a-mutex.o 536 0 0 536 218 ./arm-rtems4.12/c/atsamv/cpukit/score/src/libscore_a-condition.o 4 0 0 4 4 ./arm-rtems4.12/c/atsamv/cpukit/libstdthreads/libstdthreads_a-call_once.o 100 0 0 100 64 ./arm-rtems4.12/c/atsamv/cpukit/libstdthreads/libstdthreads_a-cnd.o 104 0 0 104 68 ./arm-rtems4.12/c/atsamv/cpukit/libstdthreads/libstdthreads_a-mtx.o 156 0 0 156 9c ./arm-rtems4.12/c/atsamv/cpukit/libstdthreads/libstdthreads_a-thrd.o 40 0 0 40 28 ./arm-rtems4.12/c/atsamv/cpukit/libstdthreads/libstdthreads_a-tss.o size ./arm-rtems4.12/c/atsamv/cpukit/rtems/src/librtems_a-sem* textdata bss dec hex filename 496 0 0 496 1f0 ./arm-rtems4.12/c/atsamv/cpukit/rtems/src/librtems_a-semcreate.o 152 0 0 152 98 ./arm-rtems4.12/c/atsamv/cpukit/rtems/src/librtems_a-semdelete.o 68 0 0 68 44 ./arm-rtems4.12/c/atsamv/cpukit/rtems/src/librtems_a-semflush.o 28 0 0 28 1c ./arm-rtems4.12/c/atsamv/cpukit/rtems/src/librtems_a-semident.o 48 0 0 48 30 ./arm-rtems4.12/c/atsamv/cpukit/rtems/src/librtems_a-sem.o 428 0 0 428 1ac ./arm-rtems4.12/c/atsamv/cpukit/rtems/src/librtems_a-semobtain.o 464 0 0 464 1d0 ./arm-rtems4.12/c/atsamv/cpukit/rtems/src/librtems_a-semrelease.o 312 0 0 312 138 ./arm-rtems4.12/c/atsamv/cpukit/rtems/src/librtems_a-semsetpriority.o The libscore_a-mutex.o contains more than one function. For example we have (Cortex-M7 target): 7000c5f0 <_Mutex_recursive_Acquire>: 7000c5f0: 2380movsr3, #128; 0x80 7000c5f2: f3ef 8111 mrs r1, BASEPRI 7000c5f6: f383 8812 msr BASEPRI_MAX, r3 7000c5fa: 4a12ldr r2, [pc, #72] ; (7000c644 <_Mutex_recursive_Acquire+0x54>) 7000c5fc: 68c3ldr r3, [r0, #12] 7000c5fe: 6912ldr r2, [r2, #16] 7000c600: b91bcbnzr3, 7000c60a <_Mutex_recursive_Acquire+0x1a> 7000c602: 60c2str r2, [r0, #12] 7000c604:
