On Thu, Jan 28, 2021 at 3:16 AM Grr wrote:
> I opted for The Right Thing(TM) and implemented a simple serial input echo
> capabilities for serial driver introducing use of ECHO flag in
> drivers/serial/serial.c and proper configuration options in menuconfig
>
> Now the interface of an interactive
ELF solution has to load the code to RAM, the overhead is too big to use for
XIP system.
> -Original Message-
> From: Matias N.
> Sent: Thursday, January 28, 2021 2:17 AM
> To: dev@nuttx.apache.org
> Subject: Re: limitation in SIGEV_THREAD?
>
> I think the independent ELF solution would
There's an SVD file, so no need to use any other headers:
https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2040/hardware_regs/rp2040.svd
We discussed in the past about the license that would apply to a header
auto-generated from the SVD but I'm not sure if we arrived at any conclusion
Hi,
> Copyright © 2020 Raspberry Pi (Trading) Ltd. The documentation of the RP2040
> microcontroller is licensed under a Creative Commons
> Attribution-NoDerivatives 4.0 International (CC BY-ND). Portions Copyright ©
> 2019 Synopsys, Inc. All rights reserved. Used with permission. Synopsys &
>
Hi Nathan,
I started fixing nxstyle errors in preparation of the license change
I will continue cleaning the files so that we can update the licenses in clean
PRs
Best regards
Alin
-Original Message-
From: Nathan Hartman
Sent: den 26 januari 2021 16:05
To: dev@nuttx.apache.org
Subj
I opted for The Right Thing(TM) and implemented a simple serial input echo
capabilities for serial driver introducing use of ECHO flag in
drivers/serial/serial.c and proper configuration options in menuconfig
Now the interface of an interactive serial program works the same in Linux
and NuttX :)
Perhaps you could use a pool of application threads as is done with
the kernel threads for the low-priority work queue. So you could have
a small number of threads that service all tasks. When a user-space
thread is needed, it could be removed from the pool and be assigned to
the task to r
I think the independent ELF solution would again not be very good for
constrained systems.
The again, reading about SIGEV_THREAD makes me think that the specs are very
loose in terms of
what is guaranteed by the thread running the callback.
These kind of issues (and the fact that mixing signals
My thinking is that maybe upon setting up the first SIGEV_THREAD notification
for a task, a child thread would be created, which would act as a worker,
waiting on some semaphore for example. The bad thing is that it would linger
until task is finished (not sure even how easy would be to ensu
All global C++ objects are constructed in init task, so if these objects
call open, fopen or fstream related API, the similar issue happens too. How
can we fix this issue?
In order to do that, I think that each application task would have to
separately linked as they are with ELF modules or in
My thinking is that maybe upon setting up the first SIGEV_THREAD notification
for a task, a child thread would be created, which would act as a worker,
waiting on some semaphore for example. The bad thing is that it would linger
until task is finished (not sure even how easy would be to ensure i
All global C++ objects are constructed in init task, so if these objects
call open, fopen or fstream related API, the similar issue happens too. How
can we fix this issue?
BTW, is it acceptable to create a pthread in each task to
process SIGEV_THREAD dedicatedly in the small embedded device? Can we
12 matches
Mail list logo
