Re: [Discuss] Migrate the build system to CMake

on my fork. The branch on the repo does not yet contain anything, it simply acts as a stable base for the PR (and, of course, protects master from the merge, if it ever happens). On Wed, Jun 9, 2021, at 18:32, Nathan Hartman wrote: > On Wed, Jun 9, 2021 at 3:07 PM Matias N. <mailto:matias%4

Re: [Discuss] Migrate the build system to CMake

d, we rely on yet another external > > > >> tool with bugs in itself, and its idiosyncrasies and workarounds. > > > >> > > > >> > > > >> Moreover: > > > >> > > > >> -the doc about nuttx is not hosted by the n

Re: [Discuss] Migrate the build system to CMake

On Wed, Jun 9, 2021, at 11:08, Nathan Hartman wrote: > On Wed, Jun 9, 2021 at 10:01 AM > wrote: > > > > I like the cmake idea but we should also consider that cmake will have > > implications on all projects that use the NuttX as a base for the SDK or > > custom

Re: [Discuss] Migrate the build system to CMake

est, Matias > > BR, > > Alan > > On 6/9/21, Matias N. mailto:matias%40imap.cc>> wrote: > > Hi everyone, > > > > this thread has received little engagement from the community > > in general, for a change with such impact on daily use of Nu

Re: [Discuss] Migrate the build system to CMake

M Alan Carvalho de Assis <mailto:acassis%40gmail.com>> > wrote: > > > I think we can divide the effort to port all the boards to the new CMake. > > > > I can start take care of ESP32, ESP32-C3 and ESP32-S2. > > > > Let see if we get more people involved

Re: Nimble on U-blox Nina B112 (Nrf52832)

Hi Miguel, if you have questions regarding using nimBLE I suggest you go to their support channels as this is really not NuttX related. Best, Matias On Tue, Jun 8, 2021, at 14:01, Miguel Wisintainer wrote: > Hi Matias > > Have you some example to make the scan ? > > Enviado do Email

Re: [Discuss] Migrate the build system to CMake

Thanks, Alan. > > BR, > > Alan > > On 6/1/21, Matias N. mailto:matias%40imap.cc>> wrote: > > Hi, > > just wanted to add that until this is ready, the gap between master and the > > branch > > widens with every merged PR and this increases the backport

Re: [Discuss] Migrate the build system to CMake

your feedback on this before I continue and ensure the effort will not go to waste. Best, Matias On Sat, May 29, 2021, at 14:06, Matias N. wrote: > Hi, > for anyone not following the relevant PR, please have a look at the current > state here: > > https://github.com/apache/incub

Re: [Discuss] Migrate the build system to CMake

Hi, for anyone not following the relevant PR, please have a look at the current state here: https://github.com/apache/incubator-nuttx/pull/3704 This is now at a point where it can be tested by others. It would be very good to get some help testing what I got so far (sim and stm32f4discovery,

Re: Nimble on U-blox Nina B112 (Nrf52832)

gt; Symbol: NSH_BUILTIN_APPS [=y] > > As you saw I used your "nrf52832-mdk:sdc" and you enabled it there. > > Is it working for you? > > BR, > > Alan > > On 5/25/21, Matias N. mailto:matias%40imap.cc>> wrote: > > The problem with apps lis

Re: Nimble on U-blox Nina B112 (Nrf52832)

The problem with apps listed but not being able to run them is a common error (something worth adding to the FAQ) I faced many times. It is due to not having support for BUILTIN apps on menuconfig (you need general support as well as enabling NSH BUILTIN support). It is strange that the config

Re: Nimble on U-blox Nina B112 (Nrf52832)

Hi Miguel, from the looks of it, it is a problem with NuttX's Bluetooth host-layer. There's an unhandled opcode which corresponds to "scan enable", which is not being recognized when the controller sends "command complete". In my case I used nimBLE for host layer which works well. You can try

Re: CI stuck?

ays ago when GitHub was having some issues and it looks > like they have an active outage now as well that is recovering so I would > suspect that. > > https://www.githubstatus.com/ > > --Brennan > > On Tue, May 18, 2021, 10:17 AM Matias N. <mailto:matias%40imap.cc>&g

CI stuck?

I noticed CI wasn't running jobs and found several runs from 8 hrs ago which were stuck with "internal error" reports. I canceled those (event though there weren't actually running) to see if the queued ones were picked up (which doesn't seem to be the case). Anyone knows what could be

Re: How to share code and Kconfig between different boards

I'm not sure if there's support for custom-board common-code (in the same sense as for in-tree boards). In any case, we've introduced an external/ directory for the purpose of adding external OS level code. Simply point nuttx/external symlink to your common directory. Best, Matias On Wed, May

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

t; > Yes, but that change just exposed an old issue. > > On Wed, Apr 28, 2021 at 2:45 PM Matias N. <mailto:matias%40imap.cc>> wrote: > > > > Wasn't the stack restructure behind the 10.1 release? > > > > Best, > > Matias > > > > On Wed, Apr 28, 2021,

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

Wasn't the stack restructure behind the 10.1 release? Best, Matias On Wed, Apr 28, 2021, at 09:57, Gustavo Henrique Nihei wrote: > Hi folks, > > I believe we should consider backporting the fix from this PR into the > 10.1.0 release: > https://github.com/apache/incubator-nuttx/pull/3614 > > It

Re: Mailing list usability

Most mailing list managers allow turning off sending emails (and also support digest mode). If Apache uses mailman this should be possible to set via administrative interface once you subscribe. Best, Matias On Fri, Apr 23, 2021, at 06:34, Max Kriegleder wrote: > Hi all, > > I am an

Re: Ethernet cable (network interface availability) detection

added? Is it ok to be after Glossary? > > BR, > > Alan > > On 4/14/21, Matias N. mailto:matias%40imap.cc>> wrote: > > We do not yet have a "Networking" section under "OS Components" where a lot > > of network related stuff should > >

Re: Ethernet cable (network interface availability) detection

We do not yet have a "Networking" section under "OS Components" where a lot of network related stuff should be. However, I have thought about a FAQ section for having brief question/answers where this kind of information can be (until a proper section is added). If anyone wants to start this it

Re: ESP32S?

Am Sa., 3. Apr. 2021 um 13:40 Uhr schrieb Matias N. <mailto:matias%40imap.cc>>: > > > Do you see a need for something more? Not sure what other aspects of video > > handling require a specific solution. > > When talking about cameras you also need to s

Re: ESP32S?

My idea was to do something similar to the framebuffer device, using map to access image data and ioctl's to control camera parameters and wait for a frame. Is this mostly how v4l works? Do you see a need for something more? Not sure what other aspects of video handling require a specific

Re: ESP32S?

Thanks Alan. I'll probably give it a try. Best, Matias On Fri, Apr 2, 2021, at 20:43, Alan Carvalho de Assis wrote: > Hi Matias, > > No, AFAIK there is nobody working on camera support. > > BR, > > Alan > > On 4/2/21, Matias N. mailto:matias%40imap.cc>> wrote

ESP32S?

Hi, I'm considering buying one of those ESP32 modules which includes the camera and SD card and I noticed it seems it comes with a single-core variant of the typical ESP32 module. I looked around NuttX and I think there's no explicit support yet but I imagine it shouldn't be hard to add, right?

Re: All PRs stuck in "Queued -- Waiting to run this check..."

We're already using ccache, but it is used intra run (ie, for arm-01, sim, etc). We tried persisting it across runs (from different PRs) but it seems there was issues with that. What I suggest means we have one cache pero board/config. The scripting shouldn't be too difficult but it requires

Re: All PRs stuck in "Queued -- Waiting to run this check..."

On Wed, Mar 31, 2021, at 11:26, Nathan Hartman wrote: > I wonder if we need the tests to be a bit smarter in restricting what they > test. > > For example if the change only affects files in arch/arm/stm32h7 then only > stm32h7 configs will be tested. That can be difficult to do. A header

Re: All PRs stuck in "Queued -- Waiting to run this check..."

On Tue, Mar 30, 2021, at 21:44, Brennan Ashton wrote: > We were sharing cache but ran into some strange issues with collisions and > disabled it unfortunately. Do you remember the exact issue? What if we had one ccache cache per : run shared across runs? (not sure if that would be too much

Re: All PRs stuck in "Queued -- Waiting to run this check..."

On Wed, Mar 31, 2021, at 09:33, Abdelatif Guettouche wrote: > > Also, I agree about simplifying macOS build if it will help while we get to > > q better situation. > > We can have a special test list for macOS that includes just a few > configs from the simulator and other chips. I think just

All PRs stuck in "Queued -- Waiting to run this check..."

Then situation is a bit better now, since we did not continue to submit as many Para. However, the builds are still lagging (there are ones from 20hr ago running). I see many of the new "cancelling duplicates" jobs queued but they have not yet run. I have cancelled a few myself. In case I

Re: All PRs stuck in "Queued -- Waiting to run this check..."

rds) running from our homes > to help it, hehehe. > > Suggestions are welcome! > > BR, > > Alan > > On 3/30/21, Nathan Hartman <mailto:hartman.nathan%40gmail.com>> wrote: > > On Tue, Mar 30, 2021 at 3:30 PM Matias N. > <mailto:matias%40imap.cc>>

Re: All PRs stuck in "Queued -- Waiting to run this check..."

It appears we overwhelmed CI. There are a couple of running jobs (notably one is a macOS run which is taking about 2hrs as of now) but they are for PRs from 12hs ago at least. There are a multitude of queued runs for many recent PRs. The problem is that new runs (from force pushes) do not

Re: mqtt library on NuttX?

/3045 > The little debugging I did showed that fs_getfilep is returning a bad > file structure in case of a socket descriptor. > > I still didn't debug it any further. > > On Sun, Mar 28, 2021 at 11:33 PM Matias N. <mailto:matias%40imap.cc>> wrote: > > > &

Re: mqtt library on NuttX?

sue. > That said, I can submit it later if you guys want. > One question: where do we put the library? > A new "mqtt" folder? > > On Thu, Mar 25, 2021 at 10:59 PM Alan Carvalho de Assis > mailto:acassis%40gmail.com>> wrote: > > > > On 3

Re: userspace assert?

Yes, it seems that is the issue. I will make a PR to remove those lines (I tried removing them and works as expected). Best, Matias On Sat, Mar 27, 2021, at 16:44, Gregory Nutt wrote: > > > Or maybe is sim's up_assert() wrong to exit simulation? Thinking about it, > > doing up_assert() (which

Re: userspace assert?

Or maybe is sim's up_assert() wrong to exit simulation? Thinking about it, doing up_assert() (which would just print the error) and exit() would indeed exit the app only. On Sat, Mar 27, 2021, at 16:30, Matias N. wrote: > I was using assert in an app (testing on sim) and realized the sim exi

userspace assert?

I was using assert in an app (testing on sim) and realized the sim exited upon hitting the assert. From the code I see it calls into up_assert() (which would also be a violation of OS/Userspace separation AFAIK). What about writing a similar simple function that only sends the message to syslog

Re: mqtt library on NuttX?

On Thu, Mar 25, 2021, at 15:21, Alan Carvalho de Assis wrote: > Hi Matias, > > On 3/25/21, Matias N. mailto:matias%40imap.cc>> wrote: > > > > > > On Thu, Mar 25, 2021, at 15:02, Abdelatif Guettouche wrote: > >> Someone was asking the other day

Re: mqtt library on NuttX?

efore as well. Sure, if the mbedTLS PR gets finished it would be a good combination. Best, Matias > > On Thu, Mar 25, 2021 at 6:23 PM Matias N. <mailto:matias%40imap.cc>> wrote: > > > > Great, maybe some draft PR could be submitted? > > > > Regarding SSL,

Re: mqtt library on NuttX?

on NuttX and it is working fine. > > It needs some clean-up to be submitted to apps/ > > BR, > > Alan > > On 3/25/21, Matias N. mailto:matias%40imap.cc>> wrote: > > Hi, > > I was wondering if anyone is already using some MQTT library on NuttX. I see > >

mqtt library on NuttX?

Hi, I was wondering if anyone is already using some MQTT library on NuttX. I see many options some of which look like potential candidates for easy porting, but if anyone already went through this process I would appreciate some feedback. Thanks, Matias

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

021 at 12:51 AM Gregory Nutt <mailto:spudaneco%40gmail.com>> wrote: > > > On 3/24/2021 8:38 AM, Matias N. wrote: > > > So, if I follow correctly, we could maybe have one TLS pointer pointing > > to a struct of pointers, one per each group of globals (one of

Re: USB Host and Bluetooth "dongle".

Not entirely sure about your scenario here, but if the dongle simply expects HCI communication and you manage to get a /dev/ttyUSB0 or whatever on NuttX side, then you should be able to use the bt_uart bridge to expose the controller to NuttX. From then on, you can choose to use NuttX host layer

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

Great, thanks! I was just writing an issue to have this noted somewhere. Best, Matias On Wed, Mar 24, 2021, at 13:23, Gregory Nutt wrote: > I think it is not very much work to implement. Perhaps I will submit a > draft PR for your review. > > > On 3/24/2021 9:34 AM, Matias N.

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

Yes, you're right, TLS is the way to go. I only wonder how to minimize the impact. Could this array inside the TLS struct be grown as needed during runtime? That way if no application calls to getopt() (or any other function requiring similar solution), no extra space on TLS is used. On Wed,

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

ing memory use of every thread. Not sure what is really best here... On Wed, Mar 24, 2021, at 11:51, Gregory Nutt wrote: > On 3/24/2021 8:38 AM, Matias N. wrote: > > So, if I follow correctly, we could maybe have one TLS pointer pointing to > > a struct of pointers, one per e

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

So, if I follow correctly, we could maybe have one TLS pointer pointing to a struct of pointers, one per each group of globals (one of this groups, would be the set of variables used by getopt()), like: struct task_globals_s { struct getopt_globals_s *getopt_globals; /* ...others */ };

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

Of course, I would only call getopt() once. My question was if we use TLS, would the memory use scale with the number of threads? Or would this memory for getopt() only be allocated on getopt() calls? On Wed, Mar 24, 2021, at 10:56, Gregory Nutt wrote: > > >> You would expect getopt() to be

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

On Wed, Mar 24, 2021, at 10:37, Gregory Nutt wrote: > > > Thanks for all answers. I don't entirely understand most of them though as > > I'm not really familiar with the implications of TLS or how to use it > > correctly. Also, do we need per-thread or per-task data here? > > You would

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

Thanks for all answers. I don't entirely understand most of them though as I'm not really familiar with the implications of TLS or how to use it correctly. Also, do we need per-thread or per-task data here? What I'm thinking is that, besides the TLS based solution, adding a non-standard

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

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

avoiding pitfal of reuse of globals in FLAT mode?

Hi, while using getopt() from a task started from NSH I realized subsequent calls reused the global optind and similar variables resulting in different results each time. I'm aware this is expected in FLAT mode and is related to the issue of static C++ constructors (they would only be called

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

rlo > Embedded Software Engineer > NXP Semiconductors, CTO Systems Innovations > > High Tech Campus 46, room 0.64, 5656 AE Eindhoven, The Netherlands > E-mail: cis.van.mie...@nxp.com <mailto:cis.van.mierlo%40nxp.com> > Internet: http://www.nxp.com > > -Original Me

Re: GSoC 2021 - How Mentors and Students will apply?

Just created the issue here: https://github.com/apache/incubator-nuttx/issues/3031 Please let me know if something needs more clarification. Best, Matias On Thu, Mar 11, 2021, at 13:02, Matias N. wrote: > I think I will open a GH issue for this, so as not to derail this thread. > I don'

Re: GSoC 2021 - How Mentors and Students will apply?

ting some prototype of this idea. > > We should to discuss it in more details here. I think Mr. Bhargav is > already subscribed to this mailing list, he could align with you too. > > BR, > > Alan > > On 3/11/21, Matias N. wrote: > > Hi Alan, > > Just saw the propos

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

Calling those functions from applications would be a violation of OS/application isolation, as these are OS level calls. The general idea is that a driver only knows what to do on each sleep level and the IDLE loop uses those functions to drive the change of states of PM system. >From

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

ems Innovations > > High Tech Campus 46, room 0.64, 5656 AE Eindhoven, The Netherlands > E-mail: cis.van.mie...@nxp.com > Internet: http://www.nxp.com > > *From:* Matias N. > *Sent:* Friday, March 5, 2021 4:32 PM > *To:* dev@nuttx.apache.org > *Subject:* [EXT]

Re: Project specific power management configuration

Hi, I'm not entirely sure what is the specific control over PM you need but some time ago I introduced the notion of "governor" which lets you select either the activity based one (which uses a specific algorithm to control states), a greedy governor (which lets an application directly control

Re: Proper handling of arch header files

> DTS mean huge changes and maybe even ditching Kconfig DTS does not replace Kconfig. Kconfig enables OS options and support for features. DTS describes presence of resources and how they are mapped to on-board/on-chip resources (CS line to GPIO is one such example). Moreover, Kconfig does not

Re: Proper handling of arch header files

That is a separate issue from what we're discussing (arch independent GPIO handling) and I agree with you. I would like to eventually move to a different initialization system based on callbacks and a hierarchical resource description strategy which can describe on-board devices but can be

Re: Proper handling of arch header files

On Sat, Feb 6, 2021, at 12:06, Grr wrote: > > No, you wouldn't need that. The device driver will receive a generic GPIO > > handling > > interface and it would simply assert/deassert CS line without knowing the > > specifics > > of the GPIO impementation on the given architecture. > > > That's

Re: Proper handling of arch header files

> That's moving the same problem from one place to another instead of > eliminating it: you need to rewrite some part of the driver for each > chip/subchip. No, you wouldn't need that. The device driver will receive a generic GPIO handling interface and it would simply assert/deassert CS line

Re: Proper handling of arch header files

I understand you are looking for a generic API that can be used from drivers to access GPIOs, right? I understand this may come up in situations like handling CS lines from SPI driver. Currently we handle this by delegating the select line handling to board logic completely. I thought about

Re: Proper handling of arch header files

I'm not entirely following the problem, but it sounds like you could decouple your arch-independent driver logic in an upper-half and then have a lower-half per-arch, using board-common drivers (ie. boards/stm32/drivers). The lower-half would then be able to use stm32 internal headers. In this

Re: testing wapi on esp32 devkitc

Yes, but it was really low level logging and didn't understand much. I'll try again later and paste it here. Best, Matias

RE: I saw a new option for merging in GH: Auto merge when CI completes

Yes this would be a useful feature. Assuming that the trigger disarms if there's a new push in between, which may require new review.

Re: Anyone else getting repeated emails from the GitBox?

I actually delete gitbox messages on arrival. I find GitHub notifications much more usable. Best, Matias

Re: testing wapi on esp32 devkitc

ted though. > > On Thu, Feb 4, 2021 at 11:55 PM Matias N. wrote: > > > > Thanks, now the interface appears. > > What functionality is currently supported? Can I connect to WPA2 AP? Can I > > create an AP? > > > > Also, I'm trying to scan and I get: &

Re: testing wapi on esp32 devkitc

:36, Abdelatif Guettouche wrote: > It could be because there are some issues with getting the paramters from > the flash. Please try disabling Save Paramters from the Wifi Configuration > menu. > > On Thu, Feb 4, 2021, 11:32 PM Matias N. wrote: > > > Hi, > > I'm try

testing wapi on esp32 devkitc

Hi, I'm trying to test WiFi support on ESP32 DevKitC (I used wapi config) and it does not seem to work. I get this: rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2

Re: limitation in SIGEV_THREAD?

:49, Brennan Ashton wrote: > On Sat, Jan 30, 2021 at 6:11 PM Matias N. wrote: > > > > > > > This is actually fairly in line with how the Musl libc implements this (at > > > least from a quick look). There are a few important details in there, but > > &

Re: limitation in SIGEV_THREAD?

> This is actually fairly in line with how the Musl libc implements this (at > least from a quick look). There are a few important details in there, but > it looks quite clean. > > http://git.musl-libc.org/cgit/musl/tree/src/time/timer_create.c > > While Musl is usually not as fast as glibc, I

Re: limitation in SIGEV_THREAD?

I'm thinking again about this. Why wouldn't it be possible to make functions using SIGEV_THREAD (such as timer_settime) create a pthread behind the scenes (only the first time a SIGEV_THREAD is setup)? The underlying watchdog would go to a handler that posts a semaphore/condition variable that the

Re: timerfd

On Sat, Jan 30, 2021, at 12:26, Xiang Xiao wrote: > On Sat, Jan 30, 2021 at 7:00 AM Matias N. wrote: > > > But that isn't a userspace API, is it? It runs the handler in interrupt > > context. > > > > > The core logic for timerfd is part of the kernel(actua

Re: timerfd

, Xiang Xiao wrote: > 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: tim

timerfd

Hi, I would like to implement timerfd interface to overcome some of the issues around handling signals and threads and the limitation of SIGEV_THREAD we discussed. I see eventfd is supported and looking at the implementation I think it can be done relatively simple using most of the existing

Re: Raspberry Pi Pico a nice board for NuttX

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

Re: limitation in SIGEV_THREAD?

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

Re: limitation in SIGEV_THREAD?

needed to correct the implementation of the > > AIO APIs. They also should run on pthreads as well. However, I am not > > aware of any functional shortcoming of the current AIO implementation > > that would justify the change. > > > > The only unattractive thing about t

Re: limitation in SIGEV_THREAD?

tation > that would justify the change. > > The only unattractive thing about this solution is that is does require > more resources and is less efficient in general. > > Greg > > On 1/26/2021 4:26 PM, Matias N. wrote: > > Hi, > > working with nimBLE I found that I had

limitation in SIGEV_THREAD?

Hi, working with nimBLE I found that I had an issue when scheduling a callback to be made from within the signal handler for a timer, which was set with SIGEV_THREAD. The issue was that I was pushing to a POSIX queue from within the handler, and it was failing with BADFD. From debugging I

Re: Raspberry Pi Pico a nice board for NuttX

> Is there any easy way to get all of the register definition header files > in place (with Apache 2 headers)? If there's an SVD file somewhere, you can use this: https://gitlab.com/nuttx_projects/svdgen I've used it many times and requires minimal tweaking afterwards. Best, Matias

Re: software i2c?

Thanks a lot! I will convert it to a proper NuttX driver, test it and open a PR. Best, Matias On Mon, Jan 18, 2021, at 17:05, Fotis Panagiotopoulos wrote: > Also the Maple lib is C++, while my code is pure C. > > The code is not published anywhere, till now. > > I am attaching it here. > If

Re: software i2c?

library, rather I used the lib as a > > basis to write my own think. > > > > At least to the part I remember, it was many years ago. > > > > I am looking for this maple library, but I think that it is not publicly > > available any more. > > The current lib

Re: software i2c?

d to be > checked. > In any case, it may serve as a basis for freshly written NuttX code. > > If this is of any interest to you, please tell me and I can provide the > code. > > > Στις Δευ, 18 Ιαν 2021 στις 7:29 μ.μ., ο/η Matias N. έγραψε: > > > Hi, > > &

software i2c?

Hi, by any chance does anyone have a software I2C implementation laying around (but tested) that could be submitted to NuttX? If the basis is there I can do any required adaptation. Thanks, Matias

Re: adding support for stack coloration on nRF52

Thanks, I tested simply copying the code and it works. I will probably make a PR for that and we can then refactor the code to have a single place for each arch. Best, Matias On Sun, Jan 17, 2021, at 05:06, Xiang Xiao wrote: > On Sat, Jan 16, 2021 at 6:08 PM Matias N. wrote: > > &g

adding support for stack coloration on nRF52

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 it? Also, any reason why this is chip dependant and not

monitoring task stack use from gdb?

Hi, I'm wondering if the gdbinit script could be extended to read task memory usage (as would be displayed by ps command) for each task, when using the info_nxthreads command. It would be really useful to easily detect improper stack size configuration. Best, Matias

Re: condition variables and signals

Thanks Greg for the insight into the problem. The fact that the signal handler runs in the same thread was not something I thought. Also I think it confirms using SIGEV_THREAD for this is the safe approach in this scenario. Best, Matias On Wed, Jan 13, 2021, at 19:06, Gregory Nutt wrote: > > >

Re: condition variables and signals

Thanks. I'm using FLAT mode so no problem. Best, Matias On Wed, Jan 13, 2021, at 11:40, Gregory Nutt wrote: > Just beware of https://github.com/apache/incubator-nuttx/issues/1352 > > On 1/13/2021 8:09 AM, Matias N. wrote: >> Hi, >> thanks for your responses. Yes, upon mo

Re: condition variables and signals

Hi, thanks for your responses. Yes, upon more reading I realized mixing signals with pthread mutexes was not safe. I guess I was getting a race condition inside the mutex locking. As a workaround, I resorted to using SIGEV_THREAD notification for POSIX timers. This appears to work and I guess

Re: condition variables and signals

> Note that I was initially signaling the condition variable from within the > signal handler but this did not work either. However, looking at pthread > documentation this is supposedly not supported: > https://linux.die.net/man/3/pthread_cond_signal > (I'm not sure if that really applies to

Re: condition variables and signals

Ahh ok. Thanks for that, should've looked further into the spec. I assumed from other documentation I read that it could work. So, now I'm a bit stuck on mixing the signal-based POSIX timers with mutexes. I will see about other synchronization mechanism. Best, Matias On Tue, Jan 12, 2021, at

Re: condition variables and signals

I'm not expecting the task to be killed, but the pthread_cond_wait to return when the process receives a signal (which I'm handling in a signal handler). What I need is to exit the pthread_cond_wait upon reception of the signal. As I mentioned, doing pthread_cond_signal from the handler did not

Re: condition variables and signals

The wait I'm referring to is the one on the semaphore underlying to the condition variable (pthread_sem_take on cond->sem). This ends up as a call to nxsem_wait_uninterruptible which loops on the wait to ignore EINTR errors. So I understand that a signal would not interrupt the wait (and thus,

Re: condition variables and signals

As a quick test, I made pthread_cond_wait call to pthread_sem_take with the last argument to true (which then use the interruptible version) and it now cancels the wait. So it would seem that this is a bug right? Best, Matias On Tue, Jan 12, 2021, at 20:13, Matias N. wrote: > Hi, > I'm

condition variables and signals

Hi, I'm having an issue when waiting on a pthread condition variable from the main thread and then a signal handler runs, which should cancel the wait since I have cancellation points enabled, however this did not happen. While debugging I see the main thread blocked when standing inside the

Re: I2C on nRF52840

gt; > niedz., 10 sty 2021 o 05:42 Matias N. napisał(a): > > > I was about to enable error support but I noticed it is disabled in-code. > > From the look of it there's not that > > much else to do but to issue a STOP. > > > > Regarding the error I'm receiving,

Re: nrf52 input buffer

: > It looks like a bug. But for some reason with the input buffer turned off, > reading the input pin still works (nrf52840). > > niedz., 10 sty 2021 o 19:17 Matias N. napisał(a): > > > Hi, > > while debugging the issue I mentioned in the other thread, I found > > so

nrf52 input buffer

Hi, while debugging the issue I mentioned in the other thread, I found something strange: when configuring a pin as input on nRF52, the input buffer is not enabled (by clearing the relevant INPUT bit of the PIN_CFG register):

  1   2   3   >