RE: [GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1487: libc: Avoid ctype function to evaluate the argument more than once

Let's restart the problem: it's definitely a bug that ctype macros evaluate it's argument more than once. If the code size is more important than the speed, let's change all macros to normal function that we get the correction behavior and save the code size at the same time. > -Original Me

RE: [GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1487: libc: Avoid ctype function to evaluate the argument more than once

age- > From: Xiang Xiao > Sent: Friday, July 31, 2020 4:08 PM > To: dev@nuttx.apache.org > Subject: RE: [GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change > in pull request #1487: libc: Avoid ctype function to > evaluate the argument more than once > > Let&

RE: [GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1487: libc: Avoid ctype function to evaluate the argument more than once

43255 is less than 'normal function':43275 > > Am I missing something? > > -Original Message- > From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com] > Sent: Friday, July 31, 2020 3:19 AM > To: dev@nuttx.apache.org > Subject: RE: [GitHub] [incubator-nuttx] xiaox

RE: [GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #1487: libc: Avoid ctype function to evaluate the argument more than once

Macro version still evaluate the argument more than once regardless you name it kisdigit or isdigit. I am fine with any following combination: 1.lookup table for both userspace and kernel 2.normal function for both userspace and kernel 3.lookup table for userspace and normal function for kernel Bu

RE: new documentation

I looked at the content last week, but forget to send my feedback email, sorry. I definitely support the idea: the document is managed and released as the source code and collect all documents in one place. This step is very important to keep the consistent between the implementation and the docu

RE: Roadmap?

I would see the automation test on the roadmap, thanks. > -Original Message- > From: Matias N. > Sent: Wednesday, August 5, 2020 4:59 AM > To: dev@nuttx.apache.org > Subject: Re: Roadmap? > > Having a (public) roadmap is very good idea, it guides and organizes efforts > over time and al

RE: Pre-check flow

> -Original Message- > From: Ramya N > Sent: Monday, August 10, 2020 10:42 PM > To: dev@nuttx.apache.org > Subject: Pre-check flow > > Hi, > > 1. In the NuttX Pre-check flow, docker image is built from "Pre-built > Toolchain" of each architecture. If the pre-built toolchain is not >

RE: Board-specific drivers in NuttX 9.1.0.

"drivers" folder still support, but it's optional now to avoid the empty folder spread under "boards" directory. Here is the patch for your reference: commit 8b20b97d26e78c47d4c083a4c99490fb87c588d7 Author: Xiang Xiao Date: Sat May 23 02:22:49 2020 +0800 build:

RE: Board-specific drivers in NuttX 9.1.0.

rivers in NuttX 9.1.0. > > On Tue, Aug 11, 2020 at 1:14 PM Fotis Panagiotopoulos > wrote: > > The structure proposed by Xiang Xiao is not working for me. > > > > By looking in the Makefiles, I did understand that the structure has > > changed a bit.

RE: cpp cxx help - No thread API

Do you have this in your boards/Make.defs: ARCHCXXFLAGS += -D__NuttX__ -nostdinc++ Since there are many complex setting to make C++ library work on NuttX, but this setting spread in different Make.defs, I plan to enhance the experience in the next couple weeks(actually, all is done in our interna

RE: cpp cxx help - No thread API

Yes, include setting is done in the recently: commit d32e9c38dfb0659a7f3c0cf586ba1584cd7eb3d6 Author: Xiang Xiao Date: Sat Jul 11 18:37:40 2020 +0800 boards: Move the C/C++ search path to the common place so all boards support uClibc++/libc++ automatically Signed-off-by

RE: Build failed in Jenkins: NuttX-Nightly-Build #250

Note: already fixed by https://github.com/apache/incubator-nuttx/pull/1566 > -Original Message- > From: Apache Jenkins Server > Sent: Wednesday, August 12, 2020 3:59 PM > To: dev@nuttx.apache.org > Subject: Build failed in Jenkins: NuttX-Nightly-Build #250 > > See

RE: cpp cxx help - No thread API

error: '::quick_exit' has > > not been declared > > 156 | using ::quick_exit; > > | ^~ > > make[1]: *** [Makefile:80: libxx_cxa_atexit.o] Error 1 > > make[1]: Leaving directory '/nuttx/nuttx/libs/libxx' > > make: *** [too

RE: cpp cxx help - No thread API

16, > from /nuttx/nuttx/include/libcxx/ostream:138, > from /nuttx/nuttx/include/libcxx/istream:163, > from /nuttx/nuttx/include/libcxx/random:1646, > from libcxx/algorithm.cxx:11: > /nuttx/nuttx/include/locale.h:1

RE: cpp cxx help - No thread API

libcxx to github.com/nuttx to > make it more official. > > What do you think? Other (better) option should including official support to > NuttX on llvm libcxx. > > BR, > > Alan > > On 8/14/20, Xiang Xiao wrote: > > This is because Alan's porting i

RE: cpp cxx help - No thread API

Only PMC/committer have the permission to update those repositories if I remember correctly, so we can manage github.com/nuttx using the same Apache process. > -Original Message- > From: Gregory Nutt > Sent: Saturday, August 15, 2020 3:27 AM > To: dev@nuttx.apache.org > Subject: Re: cpp

RE: cpp cxx help - No thread API

bi/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/lib/thumb/v7- > m/nofp//libsupc++.a(vterminate.o) > _sbss > /nuttx/nuttx_patch/nuttx/staging/libarch.a(stm32_start.o) > ... > > > > > On Fri, Aug 14, 2020 at 8:24 PM Xiang Xiao > wrote: > >

RE: 答复: 答复: [External Mail]Re: defining a BLE GATT server

Let me clarify one thing: The approach we take is a pure userspace solution, it isn't related to NuttX kernel and no plan to upstream it. The major difference is where to put L2CAP/HCI code(userspace v.s. kernelspace) and it isn't too hard to migrate to socket interface once the NuttX kernel has

RE: supporting tickless and non-tickless using arch_timer/alarm/rtc

> -Original Message- > From: Matias N. > Sent: Thursday, September 3, 2020 6:31 AM > To: dev@nuttx.apache.org > Subject: supporting tickless and non-tickless using arch_timer/alarm/rtc > > Hi, > I'm looking into implementing tickless on nRF52 (first using systick, since > it is an easy o

RE: max sleep and tickless with no alarm

Yes, it's better to auto select SCHED_TICKLESS_LIMIT_MAX_SLEEP under config TIMER_ARCH/ALARM_ARCH. > -Original Message- > From: Matias N. > Sent: Friday, September 4, 2020 12:09 AM > To: dev@nuttx.apache.org > Subject: Re: max sleep and tickless with no alarm > > Actually, I see this in

RE: supporting tickless and non-tickless using arch_timer/alarm/rtc

Yes, arch_timer change the interrupt interval without stopping the timer first to reduce the timer drift as much as possible. So the timer driver has to remove the restriction from the code. > -Original Message- > From: Matias N. > Sent: Friday, September 4, 2020 2:13 AM > To: dev@nuttx.

Re: Warnings in Renesas common files

Bhindhiya, Why not follow the approach taken by other arch? On Fri, Sep 18, 2020 at 9:34 PM Bhindhiya Raja wrote: > > Hello Team, > > We are trying to include Renesas RX65N architecture in GitHub pre-check which > requires code to have 0 warnings to be successful. > > Call to up_copystate() in t

Re: parallelizing mkdep?

Yes, this is what we are considering to change. It desn't only improve the parallelization, but also avoids generating the full library(e.g. libc) dependency if the user just changes one source file. On Sun, Sep 27, 2020 at 10:55 AM Matias N. wrote: > > Hi, > as a test I changed the depend genera

Re: parallelizing mkdep?

king > anything. > Do you intend to create a PR in this regard? Otherwise I can create one with > this code > > Best, > Matias > > On Sun, Sep 27, 2020, at 10:42, Xiang Xiao wrote: > > Yes, this is what we are considering to change. It desn't only improve >

Re: [DISCUSS] NuttX 10.0.0 Release schedule

I would prefer that this regression get resolved before we announce the 10.0 release candidate: https://github.com/apache/incubator-nuttx/issues/1804 Thanks Xiang On Fri, Sep 25, 2020 at 12:34 AM Adam Feuer wrote: > > Alin, > > Thanks, I would love your help on the next release, I'm looking forw

Re: Cannot build H7 configuration using Ubuntu for Windows 10

it selects CONFIG_HOST_WINDOWS=y but the HOSTEXEEXT should > > be an empty string, not .exe. That is the root cause of the problem. > > > > This is commit 567962bd626 introduced the error > > > > commit 567962bd6263bf8809fb63c739f6ec668c69c416 > >

RE: Cannot build H7 configuration using Ubuntu for Windows 10

BTW, since Ubuntu for Windows 10 is same as Native Ubuntu, should we remove CONFIG_WINDOWS_UBUNTU(-u) support and let user select CONFIG_HOST_LINUX(-l) instead? This will reduce the maintain effort and avoid the misunderstanding that we don't support other Linux Distribution on Windows. > -

Re: interrupt priorities on nRF52

On Mon, Oct 26, 2020 at 4:52 AM Matias N. wrote: > Hi, > while working on nRF52 BLE link-layer I experienced some problems due to > delayed ISRs. This can be quite problematic > for handling all the tight timings required by the standard. I eventually > reached an implementation that can deal wit

Re: interrupt priorities on nRF52

t; the fence level used (NVIC_SYSH_DISABLE_PRIORITY) on the disable. The > system > > will crash due to reentrancy on the common vector, if the values, and > vector > > are not managed properly. > > > > > > -Original Message- > > From: Xiang Xiao

Re: Question regarding `WATCHDOG_AUTOMONITOR_BY_CAPTURE`

watchdog_register return watchdog_upperhalf_s * pointer, so lowerhalf could save the return value some place. Here is an example: https://github.com/FishsemiCode/nuttx/blob/song-u1/drivers/timers/dw_wdt.c#L350 On Thu, Nov 12, 2020 at 4:59 AM Sara da Cunha Monteiro de Souza < saramonteirosouz...@gm

Re: [VOTE] Apache NuttX 10.0.0 (incubating) RC0 release

+1 All outputs are good from ./tools/checkrelease.sh --release 10.0.0-RC0. Build sim:smp and run both ostest and smp successfully. On Fri, Nov 27, 2020 at 9:29 AM Alan Carvalho de Assis wrote: > Thank you Nathan, it is consistent with what I saw for other boards config! > > On 11/27/20, Nathan H

Re: STM32L5 and TrustedFirmware-M

On Wed, Dec 9, 2020 at 10:48 PM Michael Jung wrote: > Hello, > > I recently bought an STM32L52E-DK development kit and I am playing around > with ST's port of ARM's TrustedFirmware-M (see ST's UM2671). I would like > to basically leave this untouched, but replace ST's 'non-secure' > demo-applica

Re: ADXL372 sensor test fail

nuttx/include/errno.h define ENODEV to 19: #define ENODEV 19 and nuttx/drivers/sensors/adxl372.c return ENODEV if id mismatch: static int adxl372_dvr_open(FAR void *instance_handle, int32_t arg) { /* Read the ID registers */ pnpid = adxl372_read_id(priv); priv->readonly = false

Re: stm32F407G-disc1 USBNSH Doesn't work

Thiha, it may relate to the bug in usb console and fix by: https://github.com/apache/incubator-nuttx-apps/pull/521 please try it. Thanks Xiang On Thu, Dec 3, 2020 at 5:51 AM Alan Carvalho de Assis wrote: > Hi Thiha, > > My stm32f4discovery board is MB997B (not the newer version). > > It is stra

Re: Suggestion for change in Watchdog Timer Support Menu

The concern make sense, could you provide a patch? On Fri, Dec 18, 2020 at 11:55 AM Sara da Cunha Monteiro de Souza < saramonteirosouz...@gmail.com> wrote: > Hey friends, > > I have some suggestions for change for the Watchdog Timer Support Menu. > > 1. The first suggestion is to set the Keep ali

Re: Submit SGA on behalf o Sony Corporation for donation of the source files in Apache NuttX

Should we send SGA to secret...@apache.org instead? On Mon, Dec 21, 2020 at 7:48 PM Alan Carvalho de Assis wrote: > Hi Alin, > > The attachment didn't come up, because this mailing list only accepts > some kinds of documents: .txt, .jpg, etc, even .patch is not > acceptable, I already asked the

Re: Nightly build?

Jenkins use the real machine to do the build, so it can find many parallel build issues which is very hard to reproduce in github VM environment. On Thu, Dec 24, 2020 at 8:03 AM Brennan Ashton wrote: > The GitHub build is also building all configurations just splits across > multiple workers. >

Re: libcxx and buildroot toolchain

On Fri, Jan 8, 2021 at 9:57 AM Anthony Merlino wrote: > Hey all, > > Would someone be willing to share their experience with libcxx and their > toolchain? This toolchain should work: https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm > I've

Re: libcxx and buildroot toolchain

7;t release yet. Once the new release is out, I will remove all patches from the NuttX repo. > > Best, > Anthony > > > On Sat, Jan 9, 2021, 7:32 AM Xiang Xiao wrote: > > > On Fri, Jan 8, 2021 at 9:57 AM Anthony Merlino > > wrote: > > > > > Hey a

RE: Anyone using Clang?

sim on macOS is built by clang, so I think the result should be good in general. > -Original Message- > From: Anthony Merlino > Sent: Monday, January 11, 2021 5:42 AM > To: dev@nuttx.apache.org > Subject: Anyone using Clang? > > Hi all, > > Subject line says it all. I'm curious if anyon

Re: libcxx and buildroot toolchain

idx*) __exidx_end = ABSOLUTE(.); } > ROM > Best, > Anthony > > > > > > On Sat, Jan 9, 2021 at 11:57 AM Xiang Xiao > wrote: > > > On Sat, Jan 9, 2021 at 8:11 AM Anthony Merlino > > wrote: > > > > > Thanks for the info Xiang! I

Re: SD Card automounter events

inotify is a very important addition to the NuttX filesystem, but the work isn't small too. On Thu, Jan 14, 2021 at 10:58 PM Fotis Panagiotopoulos wrote: > Hi, > > So, it seems that it is not possible without kernel modifications. > > I was about to create a new driver to notify my application f

Re: adding support for stack coloration on nRF52

On Sat, Jan 16, 2021 at 6:08 PM Matias N. wrote: > Hi, > I would like to add this feature so I can measure used stack on nRF52. I'm > trying to figure out what > is needed and it would seem I need to replicate the go_nx_start() function > found on other _start.c > files. Is that all there is to i

Re: Multiple SYSLOG channels

On Thu, Jan 21, 2021 at 7:27 AM Fotis Panagiotopoulos wrote: > Hi, > > I am in need of having the syslog to output to multiple channels. > There shall be a file in an SD card where syslog will always output the > messages. > Simultaneously I need to be able to see the log in real-time in a serial

Re: NuttX: big accomplishment and next steps

Nathan, thanks for raising the proposal. We want to join the license clearing effort and will resolve some engineer resource for it in this year. Thanks Xiang On Thu, Jan 21, 2021 at 10:22 AM Nathan Hartman wrote: > Hi folks, > > Last year we received 50 ICLAs and 7 SGAs. That is a big > accomp

Re: limitation in SIGEV_THREAD?

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

RE: limitation in SIGEV_THREAD?

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

Re: stdout

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

Re: PIC32 build fail

On Fri, Jan 29, 2021 at 9:20 AM Barbiani wrote: > Hello, > > Has anyone tested the pic32 build lately? I am using the pic32mx7mmb. > > Yes, MIPS target is on the CI checklist: https://github.com/apache/incubator-nuttx-testing/blob/master/testlist/other.dat#L13-L22 It is setting the processor as

Re: PIC32 build fail

; > On 1/28/2021 8:53 PM, Barbiani wrote: > > Pinguino does work without a glitch. > > > > > > On Thu, Jan 28, 2021 at 11:29 PM Xiang Xiao > > wrote: > > > >> On Fri, Jan 29, 2021 at 9:20 AM Barbiani wrote: > >> > >>> Hello, > >>

RE: PIC32 build fail

How about we generate the toolchain binary and publish it on some github repo? > -Original Message- > From: Brennan Ashton > Sent: Friday, January 29, 2021 11:49 PM > To: dev@nuttx.apache.org > Subject: Re: PIC32 build fail > > On Fri, Jan 29, 2021, 4:39 AM Barbiani wrote: > > > I was

RE: timerfd

timerfd is a very nice feature, but is it better to call wd_* api than timer_ api? > -Original Message- > From: Matias N. > Sent: Saturday, January 30, 2021 10:01 AM > To: dev@nuttx.apache.org > Subject: timerfd > > Hi, > > I would like to implement timerfd interface to overcome some o

Re: timerfd

ere are two programming style: 1. The push mode: library/kernel calls your callback once something happens. 2. The pull mode: your thread block in poll/select or read/write call and wake up when something happens. > Best, > Matias > > On Sat, Jan 30, 2021, at 09:41, Xiang Xiao

Re: Proper handling of arch header files

On Fri, Feb 5, 2021 at 3:49 AM Grr wrote: > Hello to all > > I'm developing a Linux-like GPIO system and I need to reach arch > definitions (for example STM32_GPIOE_BSRR) in a portable way > > NuttX already support pinctrl and gpio peripheral: https://github.com/apache/incubator-nuttx/blob/master

Re: Proper handling of arch header files

On Fri, Feb 5, 2021 at 12:26 PM Grr wrote: > > NuttX already support pinctrl and gpio peripheral: > > > > > https://github.com/apache/incubator-nuttx/blob/master/include/nuttx/ioexpander/ioexpander.h > > > > > > > https://github.com/apache/incubator-nuttx/blob/master/include/nuttx/ioexpander/gpio

RE: Proper handling of arch header files

> -Original Message- > From: Grr > Sent: Friday, February 5, 2021 11:56 PM > To: dev@nuttx.apache.org > Subject: Re: Proper handling of arch header files > > > > > > We achieve this by: > > > >1. Chip driver implement io expander driver to encapsulate the gpio > >hardware > >

Re: Task with statically allocated stack

On Sat, Feb 6, 2021 at 7:38 AM Gregory Nutt wrote: > > > I am using NuttX-v10.0.1. > > This is fixed in 625eef20f00fbe9bdb4995ad9dfb24b71227e954, which came at > a > > later time. > > Hmm.. I guess I still don't understand the failure. That change was: > > #ifdef CONFIG_STACK_COLORATION >

RE: Board-level Ethernet PHY operations in STM32.

> -Original Message- > From: Grr > Sent: Sunday, February 21, 2021 3:07 AM > To: dev@nuttx.apache.org > Subject: Re: Board-level Ethernet PHY operations in STM32. > > When is using internal OS interfaces from another OS subsystem (or an app) OK > and not modularity rape? > psock_/fi

Re: Upstreaming stm32l5 work - License Headers

Here is the list: https://people.apache.org/committer-index.html On Tue, Mar 2, 2021 at 4:05 PM Michael Jung wrote: > Hello everybody, > > I would like to start upstreaming my work on STM32L5 support. It is heavily > based on available code for STM32L4. I would like to use the ASF copyright > he

Can Haltian signal SGA?

Juha, could you please discuss with your manager whether is it possible for Haltian to sign "Software Grant Agreement" for NuttX? http://www.apache.org/licenses/contributor-agreements.html So we can convert Haltian's contribution from BSD to Apache license(e.g. https://github.com/apache/incubator-n

Re: Can Haltian signal SGA?

t though. > > Ken > > On 3/5/21 1:56 AM, Xiang Xiao wrote: > > Juha, could you please discuss with your manager whether is it possible > for > > Haltian to sign "Software Grant Agreement" for NuttX? > > http://www.apache.org/licenses/contributor-agreements

RE: Symbol tables, ELF binaries, and mksymtab

> -Original Message- > From: Byron Ellacott > Sent: Friday, March 12, 2021 9:02 PM > To: dev@nuttx.apache.org > Subject: Symbol tables, ELF binaries, and mksymtab > > Hi, > > I've been working on ELF binary loading for the eZ80. I'm compiling with > CONFIG_SYSTEM_NSH=m to produce a s

Re: Tasks software watchdog timer

Why not to use the hardware watchdog timer which is more reliable and simple than the pure software solution? On Sun, Mar 14, 2021 at 5:49 AM Fotis Panagiotopoulos wrote: > Hi everybody! > > I am in need of per-task software watchdog timers. > I would like to somehow monitor my tasks, and ensure

Re: Tasks software watchdog timer

elf). > > If you want to catch some task/thread in an infinite loop, the hardware watchdog monitor in nuttx can do it for you. > I would like to monitor multiple things independently, the system's tasks. > > > Στις Κυρ, 14 Μαρ 2021 στις 5:22 μ.μ., ο/η Xiang Xiao < > x

Re: Tasks software watchdog timer

On Sun, Mar 14, 2021 at 9:40 AM Johnny Billquist wrote: > On 2021-03-14 17:36, Xiang Xiao wrote: > > On Sun, Mar 14, 2021 at 8:27 AM Fotis Panagiotopoulos < > f.j.pa...@gmail.com> > > wrote: > > > >>> Why not to use the hardware watchdog timer which

Re: Using C++ STL in Nuttx

On Mon, Mar 15, 2021 at 6:00 PM Flavio Castro Alves Filho < flavio.al...@gmail.com> wrote: > Hello, > > I am trying to use STL in a simple C++ Hello project and I am getting > compilation error.s > > Is STL supported in NuttX? Can I use it? > > Yes, you can. Please reference the following config a

Re: Using C++ STL in Nuttx

nning make export and uncompressing > > the zip file into my environment) and tried to build again and I it is > > still not compiling. > > > > Finally, I added the '#include and it is still not > working. > > > > I wil test now inside the NuttX structure.

Re: Using C++ STL in Nuttx

On Tue, Mar 16, 2021 at 11:24 PM Gregory Nutt wrote: > > >> I had to change my file names, from cpp to cxx. Is it mandatory to > >> change the file extension to use C++? > >> > > No, .cxx is just the default extension. You can change the default value > in > > Makefile like this: > > CXXEXT=.cpp

Re: Using C++ STL in Nuttx

gt; How should I address this kind of problem? > > You need tell compiler stop to search the toolchain provided c++ library by -nostdinc++ > Best regards, > > Flavio > > Em ter., 16 de mar. de 2021 às 12:34, Xiang Xiao > escreveu: > > > > On Tue, Mar 16, 2021

Re: Using C++ STL in Nuttx

On Tue, Mar 16, 2021 at 10:20 AM Flavio Castro Alves Filho < flavio.al...@gmail.com> wrote: > Hello Xiang, > > Em ter., 16 de mar. de 2021 às 14:01, Xiang Xiao > escreveu: > > > > On Tu > > > > > This project use the modern C++ feature, so you must

Re: Using C++ STL in Nuttx

>> >> Again, the coding standard does currently require the .cxx extension: >> >> https://cwiki.apache.org/confluence/display/NUTTX/Coding+Standard#cplusplus >> >> I would consider that up for discussion and subject to community >> concurrence. Which ever is selected, the extension should be used

Re: Using C++ STL in Nuttx

G_USART2_RXBUFSIZE=128 > CONFIG_USART2_SERIAL_CONSOLE=y > CONFIG_USART2_TXBUFSIZE=128 > CONFIG_USER_ENTRYPOINT="nsh_main" > > Any idea of what is missing? > > Best regards, > > Flavio > > Em ter., 16 de mar. de 2021 às 14:32, Xiang Xiao > escreveu: >

Re: Using C++ STL in Nuttx

lated to something on my branch. > > > > I was using a quite old version, based on release 10 branch. > > > > Now using master as branch, the testlibcxx compiled correctly. > > Tomorrow I will try my experiments and report here. > > > > Best regard

Re: [EXT] Re: Project specific power management configuration

Yes, it's better to list new API exposed to the userspace and finalize API set after discussion. Then we discuss how to expose them to userspace: 1.driver 2.procfs 3.boardctl 4.sysctl On Fri, Mar 19, 2021 at 9:31 PM Matias N. wrote: > There's somewhat of a (reduced) PM interface to userspace, vi

Re: avoiding pitfal of reuse of globals in FLAT mode?

On Wed, Mar 24, 2021 at 9:18 AM Matias N. wrote: > > > On Tue, Mar 23, 2021, at 22:09, Nathan Hartman wrote: > > On Tue, Mar 23, 2021 at 8:39 PM Matias N. matias%40imap.cc>> wrote: > > > > > Hi, > > > while using getopt() from a task started from NSH I realized subsequent > > > calls reused the

Re: Sleep Resolution

Why not call up_udelay or up_mdelay? The arch/soc should provide a best implementation for you. On Thu, Mar 25, 2021 at 2:00 AM Fotis Panagiotopoulos wrote: > If you are using an ARM MCU you may find the following helpful. > You must ensure that it cannot be scheduled out in any way though... >

Re: Sleep Resolution

Another way to avoid the calibration is to reuse the hardware timer in the busy loop: https://github.com/apache/incubator-nuttx/blob/master/drivers/timers/arch_alarm.c#L60-L74 https://github.com/apache/incubator-nuttx/blob/master/drivers/timers/arch_timer.c#L122-L144 On Thu, Mar 25, 2021 at 11:42

Re: Sleep Resolution

very hard to achieve the required accuracy even with the high end CPU. But since the standard defines nano_sleep, up_ndelay looks not so unreasonable. > El mié, 24 mar 2021 a las 22:34, Xiang Xiao () > escribió: > > > Another way to avoid the calibration is to reuse the hardw

Re: How to ensure HEAP will not overlap static DMA buffer?

Fotis, you define many symbols(e.g. __gp_ram?_bss_start__) in your linker script. My question is how the common init code knows the number of these symbols? On Fri, Mar 26, 2021 at 9:46 AM Fotis Panagiotopoulos wrote: > Oh, sorry. > Attached again as .txt. Is it OK now? > > > A tool that takes t

Re: How to ensure HEAP will not overlap static DMA buffer?

IMO. > (I think I have done this in the past in a similar way, but I don't have > access to this code anymore). > > > On Fri, Mar 26, 2021, 20:56 Xiang Xiao wrote: > > > Fotis, you define many symbols(e.g. __gp_ram?_bss_start__) in your linker > > script. M

Re: Running the simulator with the MM debug features enabled causes assertion to fail.

Tanushree, Could you try this patch with the latest mainline? https://github.com/apache/incubator-nuttx/pull/3228 On Mon, Mar 29, 2021 at 11:13 PM Gregory Nutt wrote: > The system has never worked reliably with either memory manager or > scheduler debug enabled. That is because the debug output

Re: Running the simulator with the MM debug features enabled causes assertion to fail.

ain for your help, > Tanushree > > > On Mon, Mar 29, 2021 at 10:27 AM Xiang Xiao > wrote: > >> Tanushree, Could you try this patch with the latest mainline? >> https://github.com/apache/incubator-nuttx/pull/3228 >> >> On Mon, Mar 29, 2021 at 11:13 PM Grego

Re: ESP32S?

video driver contributed by Sony, already mimic v4l2 interface: https://github.com/apache/incubator-nuttx/blob/master/drivers/video/video.c We can enhance this driver by: 1.Split the upper/lower half interface 2.Add more ioctl On Sat, Apr 3, 2021 at 6:00 AM Matias N. wrote: > I looked around to

[Discuss] Migrate the build system to CMake

A new issue is opened recently to address this topic: https://github.com/apache/incubator-nuttx/issues/3455 This proposal has the depth of the impact in our daily working, so it's very important to get the feedback from the community before the real action is taken. If you have any concern or sugge

Re: Nonexistent CONFIG_FILE_MODE?

beside the privilege, it's more useful to modify the timestamp for IoT device by utime: https://pubs.opengroup.org/onlinepubs/009604599/functions/utime.html BTW, the permission is meaningless in FLAT mode with the unsafe language(e.g. C/C++). On Mon, Apr 26, 2021 at 2:39 AM Gregory Nutt wrote: >

Re: Trying to build nxflat example in simulator

Sure, thanks for your contribution. On Tue, Apr 27, 2021 at 12:03 AM Tanushree Baindur < tanushree.bain...@gmail.com> wrote: > Thank you so much for your replies. > > > I tried to edit some makefiles in order to disable the document generation > but I still get the same error. I need to look at t

Re: Replacing SmartFS to LittleFS

LittleFS can talk directly with the standard MTD driver, so you just need: 1. Call register_mtddriver in your board file 2. Run mount from nsh like this: mount -t littlefs -o autoformat /dev/mtd /mnt On Wed, Apr 28, 2021 at 8:03 PM Flavio Castro Alves Filho < flavio.al...@gmail

Re: Replacing SmartFS to LittleFS

r call mount function from board_initialize like this: mount("/dev/mtd", "/mnt", "littlefs", 0, "autoformat"); > Best regards, > > Flavio > > > Em qua., 28 de abr. de 2021 às 09:33, Xiang Xiao > escreveu: > > > > LittleFS can tal

Re: [VOTE] Apache NuttX 10.1.0 (incubating) RC1 release

+1, test with sim+wsl2 On Sat, May 1, 2021 at 2:50 PM Alin Jerpelea wrote: > Hello all, > Apache NuttX (Incubating) 10.1.0 RC1 has been staged under [1] and it's > time to vote on accepting it for release. If approved we will seek > final release approval from the IPMC. Voting will be open for 7

Re: Support for disk full detection using LittleFS

On Fri, May 28, 2021 at 8:21 PM Flavio Castro Alves Filho < flavio.al...@gmail.com> wrote: > Hello, > > I am using LittleFS to store information on an external dataflash. > > I need to know if the memory is full. I saw that the nsh provides the > df command, which as far as I understood is a cat f

Re: Undefined reference to longjmp/setjmp

Since setjmp and longjmp need be called from userspace, the location is moved to: libs/libc/machine/arch Here is the related issue and PR: https://github.com/apache/incubator-nuttx/issues/2478 https://github.com/apache/incubator-nuttx/pull/3315 On Thu, Jun 10, 2021 at 2:51 AM David S. Alessio wr

Re: Undefined reference to longjmp/setjmp

It would be great to put NuttX special build files to apps/interpreters folder after you finish the port, so other people can benefit from your work and improve it in the future. For the code change, I would suggest that: 1. If the api called by 3rd party is very common in other Unix variants but N

Re: Introduction + incoming RISC-V port(s)

> > There's a LOT of duplication within arch/risc-v and where there is > divergence, it's not always clear it's intentional or if it's just missed > merges. It's an area where weak symbols (don't call a function if it wasn't > linked) and C++ virtual overrides could really clean things up. I g

Re: Duplicate task_spawn()

Thanks for reporting this issue. There a method to simplify the implementation and keep the compatibility, please try these patch: https://github.com/apache/incubator-nuttx/pull/4027 https://github.com/apache/incubator-nuttx-apps/pull/791 On Thu, Jul 1, 2021 at 8:40 PM Sebastien Lorquet wrote: >

Re: LPC1769 Progmem

Here has some discussion about the naming: https://github.com/apache/incubator-nuttx/pull/3834 On Fri, Jul 2, 2021 at 6:28 PM Fotis Panagiotopoulos wrote: > Hello, > > I am porting an old application to NuttX. > This is running on a hardware board that uses the NXP LPC1769 MCU. > I am in need of

Re: Tickless mode for iMXRT MCU

To avoid the accumulation of conversion error, the count in timer driver should use the same time unit as the hardware. BTW, your timer driver has to implement the up_alarm_xxx functions. On Sun, Jul 11, 2021 at 9:10 AM Gregory Nutt wrote: > Actually, the situation is much worse: > > https://git

Re: NuttX ELF loadable applications and modules build broken probably for the most targets.

On Sat, Jul 17, 2021 at 4:10 PM Pavel Pisa wrote: > Hello everybody, > > CONFIG_EXAMPLES_MODULE and or CONFIG_EXAMPLES_ELF is enabled then > build fails (i.e. for tools/configure.sh lx_cpu:nsh) on my system. > I use Debian provided arm-none-eabi-gcc by default. The error reported: > > > -

RE: NuttX ELF loadable applications and modules build broken probably for the most targets.

> -Original Message- > From: Pavel Pisa > Sent: Monday, July 19, 2021 10:46 PM > To: dev@nuttx.apache.org; Xiang Xiao > Cc: Gregory Nutt ; Michal Lenc ; > Abdelatif Guettouche > ; Alan Carvalho de Assis > Subject: Re: NuttX ELF loadable applications

Re: Workshop: Put on nuttx.apache.org?

It's good to add a new section in online document, pointing to each workshop video or series since many people is unware of the nuttx.event website. On Thu, Aug 26, 2021 at 6:54 PM Alin Jerpelea wrote: > Hi, > I agree with Alan, I think that "events.nuttx" is a dynamic page that will > help us k

Re: Podling Nuttx Report Reminder - October 2021

Nanthan, is it time to move the report to the official location? Thanks for summary the accurate information. On Thu, Sep 30, 2021 at 9:41 PM Nathan Hartman wrote: > Hi all, > > I've updated the initial draft of our report for October 6. > > Please review and feel free to fix any issues or let m

  1   2   3   4   5   6   >