Re: [PATCH] dev: Add NXP SC16IS752 serial device driver
On 16/12/16 05:22, Chris Johns wrote: I already spend more than one man week in vain to do this and eventually gave up. What was the issue? This two years ago. Maybe its now easier. The main issue was the i386 BSP. -- 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 15/12/16 23:34, Chris Johns wrote: On 15/12/2016 18:02, Sebastian Huber wrote: On 14/12/16 22:15, Chris Johns wrote: On 15/12/2016 00:39, Sebastian Huber wrote: [...] 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. Yes, the footprint would be smaller. If we provide self-contained threads, then the footprint would be much smaller, e.g. no object administration, no heap. Great. This is a powerful reason to look at moving in this direction and removing the remaining POSIX usage in libstdthreads. A brief audit of rtems.git shows the change is possible with less than 30 Classic task creates and a similar number of semaphore creates so a full change look reachable which is nice. Should we look at moving all internal services to C11 and standardise it? I think there is value in doing this. It can be a post 4.12 branch activity. In contrast to the C11 mutexes, I don't see a real value in moving from Classic API tasks to C11 threads. The Classic API you have more control over task attributes, modes, priority, stack size, etc. I created two tickets: https://devel.rtems.org/ticket/2842 https://devel.rtems.org/ticket/2843 Joel, Gedare, what is your opinion with respect to C11 mutexes? -- 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 17/12/16 3:26 am, Sebastian Huber wrote: > > > On 15/12/16 23:34, Chris Johns wrote: >> On 15/12/2016 18:02, Sebastian Huber wrote: >>> On 14/12/16 22:15, Chris Johns wrote: On 15/12/2016 00:39, Sebastian Huber wrote: > [...] 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. >>> >>> Yes, the footprint would be smaller. If we provide self-contained >>> threads, then the footprint would be much smaller, e.g. no object >>> administration, no heap. >> >> Great. This is a powerful reason to look at moving in this direction >> and removing the remaining POSIX usage in libstdthreads. >> >> A brief audit of rtems.git shows the change is possible with less than >> 30 Classic task creates and a similar number of semaphore creates so a >> full change look reachable which is nice. >> >> Should we look at moving all internal services to C11 and standardise >> it? I think there is value in doing this. It can be a post 4.12 branch >> activity. > > In contrast to the C11 mutexes, I don't see a real value in moving from > Classic API tasks to C11 threads. The Classic API you have more control > over task attributes, modes, priority, stack size, etc. As an interim solution this is possible but we should consider and plan the long term solution. I took a closer look at C11 threads and see the thread support is not suitable. I have concerns about mixing the API to get a "tiny" image and was hoping a single API could do this, ie the attributes of the API should be consistent across all calls and meet a minimum set of required functionality. The lack of thread attributes raises a difficult issue we need to consider a little more. I do not like the idea of a thread created with thrd_create and then needing attributes set by the another API. I thinking mixing is an architecturally poor path to follow. The C11 mutex is thin and the storage model is attractive. The FreeBSD man page for C11 functions states: As of ISO/IEC 9899:2011 (``ISO C11''), the C standard includes an API for writing multithreaded applications. Since POSIX.1 already includes a threading API that is used by virtually any multithreaded application, the interface provided by the C standard can be considered superfluous. Should we be looking at the POSIX interface and doing this work there? That is move the POSIX implementation away from the RTEMS object model. Could this be done and would the same mutex performance be achieved? If the same storage model and performance can be gained with POSIX why not look at moving in this direction. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] dev: Add NXP SC16IS752 serial device driver
On 17/12/16 3:15 am, Sebastian Huber wrote: > > > On 16/12/16 05:22, Chris Johns wrote: >>> I already spend more than one man week in vain to do this >>> and eventually gave up. >> >> What was the issue? > > This two years ago. Maybe its now easier. The main issue was the i386 BSP. > I made some changes earlier this year in the PC BSP. Would you please be able to have a look to see if this has helped improve things? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
rtems RTEMS_BINARY_SEMAPHORE can not block
hi,
I test binary semaphore used for mutex,but I find it can not block
my simple test code is
struct zynq_qspi
{
rtems_id sem_bus;
rtems_id sem_done;
bool inited;
const uint8_t *txbuf;
uint8_t *rxbuf;
int32_t bytes_to_transfer;
int32_t bytes_to_receive;
};
static struct zynq_qspi zynq_qspi_inst={
.inited = false,
.txbuf = 0,
.rxbuf = 0,
.bytes_to_transfer = 0,
.bytes_to_receive = 0
};
int zynq_qspi_init(void)
{
rtems_status_code status;
status = rtems_semaphore_create(
rtems_build_name('q', 's', 'p', 'i'), 0,
RTEMS_BINARY_SEMAPHORE | RTEMS_PRIORITY |
RTEMS_INHERIT_PRIORITY,0, &zynq_qspi_inst.sem_bus);
if (status != RTEMS_SUCCESSFUL)
{
printf("create qspi bus sem failure!\n");
return -1;
}
/*below is test*/
status = rtems_semaphore_obtain(zynq_qspi_inst.sem_bus, RTEMS_WAIT, 100);
if (status != RTEMS_SUCCESSFUL)
{
printf("%d get qspi bus sem failure!\n", __LINE__);
return -1;
}
status = rtems_semaphore_obtain(zynq_qspi_inst.sem_bus, RTEMS_WAIT,
100);
if (status != RTEMS_SUCCESSFUL)
{
printf("%d get qspi bus sem failure!\n", __LINE__);
return -1;
}
status = rtems_semaphore_obtain(zynq_qspi_inst.sem_bus, RTEMS_WAIT,
100);
if (status != RTEMS_SUCCESSFUL)
{
printf("%d get qspi bus sem failure!\n", __LINE__);
return -1;
}
/*status = rtems_semaphore_create(
rtems_build_name('q', 's', 'p', 'd'), 0,
RTEMS_BINARY_SEMAPHORE|RTEMS_GLOBAL, 0,
&zynq_qspi_inst.sem_done);
if (status != RTEMS_SUCCESSFUL)
{
printf("create qspi done sem failure!\n");
rtems_semaphore_delete(zynq_qspi_inst.sem_bus);
return -1;
}
zynq_slcr_qspi_cfg();
zynq_qspi_cfg();
status = rtems_interrupt_handler_install(ZYNQ_QSPI_IRQ_NUM,
"qspi", RTEMS_INTERRUPT_UNIQUE, zynq_qspi_interrupt,
(rtems_irq_hdl_param)(&zynq_qspi_inst));
if (status != RTEMS_SUCCESSFUL)
{
printf("error:register zynq qspi irq failure!\n ");
rtems_semaphore_delete(zynq_qspi_inst.sem_bus);
rtems_semaphore_delete(zynq_qspi_inst.sem_done);
return -1;
}
*/
zynq_qspi_inst.inited = true;
return 0;
}
I create semaphore with count is 0,so I think I should get sem failure,but it
sucessfully,change RTEMS_BINARY_SEMAPHORE | RTEMS_PRIORITY |
RTEMS_INHERIT_PRIORITY to default attribute will block .
I used git version of rtems4.12___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
