Re: ESP32S?
Hi, I would love to see video support in nuttx. I worked with video4linux a few years ago. What I loved was how to deal with memory buffers from the user space. The video4linux API allows the device configuration and also a registration of an undefined amount of memory buffers (usually related to the video/image frame size) by an user space task. Then the task simply waits for the next captured frame via a blocking ioctl call to the opened video character device. Once a frame is captured, the driver wakes up the userspace task and tells in which of the registered memory buffer the content of the last frame was captured. I found that API so quite easy, so I think we should have something similar in nuttx. The Video4Linux API is huge for historical reasons, and I think we do not need support for a lot of functionality for older hardware and should have a focus on video input devices first. The vl42 API should be a good starting point. But I can't help out here very much because of the lack of camera hardware. I only have an USB camera that supports uvc (usb video class) what I think should also be a thing that nuttx should support. Unfortunately, I'm not a USB expert. Marco Am Sa., 3. Apr. 2021 um 06:31 Uhr schrieb Gregory Nutt : > One thing that we have always been missing is a video subsystem. This > would be something similar to the audio/ subsystem which is basically a > way of connecting audio streams between audio sources (like > apps/system/nxplayer), audio processors (codecs, equalizers, etc. which > would go in audio/), and audio sinks most of which are in drivers/audio > (but also apps/system/nxrecorder). > > People have said that we need something like Video4Linux but I don't > really know very much about that. I also think Sony recently > contributed some video support under drivers/video but, again, I know > nothing about that really (video-related drivers should go under > drivers/video, but system video support should really go under video/). > > It would be nice to get some people together who are interested in video > to develop an architecture and roadmap for video support. I can't > imagine that we would be happy with the results if we just develop video > support organically. > > I say this because I spent some time developing camera support with the > SAMA5D's a few years back and was hamper because after writing the > camera driver, I really didn't know how to integrate it. > > Greg > > On 4/2/2021 8:30 PM, Matias N. wrote: > > 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: > >>> I've looked into this a bit further. It seems NuttX supports the OV2640 > >>> command interface (via I2C) with video/ov2640.c driver. However, the > data > >>> transfer is handled separately. From what I read, on ESP32, the I2S > >>> peripheral is used to handle the data transfer using DMA. So this > means that > >>> an ESP32 specific driver would need to be written so that it transfers > image > >>> data using I2S. > >>> > >>> Any chance anyone already did this? Seems a bit complex. > >>> > >>> Best, > >>> Matias > >>> > >>> On Thu, Apr 1, 2021, at 12:18, Matias N. wrote: > >>>> I'm merely experimenting myself but as a test I will try to read the > >>>> camera and offer images via a webserver. I believe the camea is > supported > >>>> in NuttX already. > >>>> > >>>> Best, > >>>> Matias > >>>> > >>>> On Thu, Apr 1, 2021, at 11:40, Grr wrote: > >>>>> I have a bunch of those modules I plan to use as security cameras and > >>>>> automation control nodes, preferably under NuttX, so I have a couple > of > >>>>> questions: > >>>>> > >>>>> 1-How far away is the camera support? > >>>>> > >>>>> 2-How about WiFi? > >>>>> > >>>>> TIA > >>>>> Grr > >>>>> > >>>>> > >>>>> El jue, 1 abr 2021 a las 8:34, Matias N. ( matias%40imap.cc>>) escribió: > >>>>>> __ > >>>>>> Yeah, I was under the impression it was single core due to the "S" > as in > &g
Re: ESP32S?
Hi, I would love to see video support in nuttx. I worked with video4linux a few years ago. What I loved was how to deal with memory buffers from the user space. The video4linux API allows the device configuration and also a registration of an undefined amount of memory buffers (usually related to the video/image frame size) by an user space task. Then the task simply waits for the next captured frame via a blocking ioctl call to the opened video character device. Once a frame is captured, the driver wakes up the userspace task and tells in which of the registered memory buffer the content of the last frame was captured. I found that API so quite easy, so I think we should have something similar in nuttx. The Video4Linux API is huge for historical reasons, and I think we do not need support for a lot of functionality for older hardware and should have a focus on video input devices first. The vl42 API should be a good starting point. But I can't help out here very much because of the lack of camera hardware. I only have an USB camera that supports uvc (usb video class) what I think should also be a thing that nuttx should support. Unfortunately, I'm not a USB expert. Marco Am Sa., 3. Apr. 2021 um 06:31 Uhr schrieb Gregory Nutt : > One thing that we have always been missing is a video subsystem. This > would be something similar to the audio/ subsystem which is basically a > way of connecting audio streams between audio sources (like > apps/system/nxplayer), audio processors (codecs, equalizers, etc. which > would go in audio/), and audio sinks most of which are in drivers/audio > (but also apps/system/nxrecorder). > > People have said that we need something like Video4Linux but I don't > really know very much about that. I also think Sony recently > contributed some video support under drivers/video but, again, I know > nothing about that really (video-related drivers should go under > drivers/video, but system video support should really go under video/). > > It would be nice to get some people together who are interested in video > to develop an architecture and roadmap for video support. I can't > imagine that we would be happy with the results if we just develop video > support organically. > > I say this because I spent some time developing camera support with the > SAMA5D's a few years back and was hamper because after writing the > camera driver, I really didn't know how to integrate it. > > Greg > > On 4/2/2021 8:30 PM, Matias N. wrote: > > 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: > >>> I've looked into this a bit further. It seems NuttX supports the OV2640 > >>> command interface (via I2C) with video/ov2640.c driver. However, the > data > >>> transfer is handled separately. From what I read, on ESP32, the I2S > >>> peripheral is used to handle the data transfer using DMA. So this > means that > >>> an ESP32 specific driver would need to be written so that it transfers > image > >>> data using I2S. > >>> > >>> Any chance anyone already did this? Seems a bit complex. > >>> > >>> Best, > >>> Matias > >>> > >>> On Thu, Apr 1, 2021, at 12:18, Matias N. wrote: > >>>> I'm merely experimenting myself but as a test I will try to read the > >>>> camera and offer images via a webserver. I believe the camea is > supported > >>>> in NuttX already. > >>>> > >>>> Best, > >>>> Matias > >>>> > >>>> On Thu, Apr 1, 2021, at 11:40, Grr wrote: > >>>>> I have a bunch of those modules I plan to use as security cameras and > >>>>> automation control nodes, preferably under NuttX, so I have a couple > of > >>>>> questions: > >>>>> > >>>>> 1-How far away is the camera support? > >>>>> > >>>>> 2-How about WiFi? > >>>>> > >>>>> TIA > >>>>> Grr > >>>>> > >>>>> > >>>>> El jue, 1 abr 2021 a las 8:34, Matias N. ( matias%40imap.cc>>) escribió: > >>>>>> __ > >>>>>> Yeah, I was under the impression it was single core due to the "S" > as in > &g
Testmail
Re: Testmail
Am Sa., 3. Apr. 2021 um 10:06 Uhr schrieb Marco : Sorry for spamming here, but showing my last reply in the mailing list was so slowly. It took about 30 minutes or more. Is this the default case? Marco >
Re: ESP32S?
Hi Matias, yes, this is more or less the way how v4l works. But v4l allows more flexibility. It is not restricted to cameras only. v4l allows handling different types of input and output devices such as cameras, monitors whatever. I'm only a bit familiar with camera input devices. The question is if your suggested approach is working with cameras of any type? I would not opt for defining a completely new interface. Linux has this done in the past xx years. And the v4l API version 2 is the result that currently works quite well, I think. I think this is the way Nuttx should go, even with a less featured or just simpler interface. But this is just my personal opinion. Marco Am Sa., 3. Apr. 2021 um 13:40 Uhr schrieb Matias N. : > 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 solution. > > Best, > Matias >
Re: ESP32S?
Am Sa., 3. Apr. 2021 um 13:40 Uhr schrieb Matias N. : > 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 specify the camera output format. This is mostly a raw format YUV for mipi cameras, but can also be e.g. mjpeg or h264 when supported by the camera. A lot of cameras providing different output formats nowadays. According to your map idea. Your implementation (the driver) must ensure that data capturing is locked during accessing the buffer by the user space task. I don't know how the driver must handle this in terms of communication with the camera. When working with v4l2 you need at least 2 registered framebuffer for that reason. One is locked for capturing and the other for processing by the application. I think there are other things to consider, but that's what I have currently in my mind. > > Best, > Matias >
1wire subsystem
Hi I currently working on a sensor driver for a temperature sensor DS18B20 connected on a 1wire bus. It seems to be that logic exists under drivers/1wire/1wire.c that provides a common mechanism to select a sensor on the bus by their unique rom code. I'm not quite sure if that procedure is specific for sensors from vendor maxim integrated or if it's 1wire specific. But the interface for that implementation is under drivers/1wire/1wire_internal.h at the moment. When this implementation is 1wire specific, I would ask if we can move the interface specification to include/nuttx/1wire/1wire_master.h I would expect something similar to the i2c interface. Currently, I can't use the logic because of restricted access to that interface from the sensors subdirectory. Marco
Re: 1wire subsystem
Hi Alan, yes of course, moving to include/nuttx/1wire/1wire_master.h also means splitting into different header files 1wire_master.h 1wire_slave.h and so on. Maybe juha doesn't knew if this is 1wire specific. I think the fact that only maxim integrated/or dallas provides chips for the 1wire bus it is a quasi-standard. ;) At least I didn't found 1wire chips from other vendors. Marco Am Sa., 3. Apr. 2021 um 15:47 Uhr schrieb Alan Carvalho de Assis < acas...@gmail.com>: > Hi Marco, > > This code was submitted by Juha, maybe he has some rational why it was > put there. > > In fact the structures and functions definition seam to be generic and > should be at include/ > > But, including that file inside 1wire_master.h is not correct, because > it was has slaves definition. > > BR, > > Alan > > On 4/3/21, Marco wrote: > > Hi > > > > I currently working on a sensor driver for a temperature sensor DS18B20 > > connected on a 1wire bus. > > > > It seems to be that logic exists under drivers/1wire/1wire.c that > provides > > a common mechanism to select a sensor on the bus by their unique rom > code. > > I'm not quite sure if that procedure is specific for sensors from vendor > > maxim integrated or if it's 1wire specific. But the interface for that > > implementation is under drivers/1wire/1wire_internal.h at the moment. > > When this implementation is 1wire specific, I would ask if we can move > the > > interface specification to include/nuttx/1wire/1wire_master.h > > I would expect something similar to the i2c interface. > > Currently, I can't use the logic because of restricted access to that > > interface from the sensors subdirectory. > > > > Marco > > >
Re: 1wire subsystem
Hi Juha, thx for your response. I will be carefully moving the interface to the include directory and hopefully do not breaking the existing implementation (ds28e17). I'm not so happy with the semaphore handling around the master interface that requires that each driver must know about that. I would like to have something like the i2c interface. Just simple write/read/transfer calls taking necessary operations (lock/reset/select) hidden from the caller. It seems to be the same procedure before reading or writing from/to the bus and is not sensor-specific. I'm also not a 1wire expert. It's my first time using this bus. So I also don't know if something is missing. I need a driver for my temperature sensor only. But what I see your work looks good and complete so far. Am Di., 6. Apr. 2021 um 08:34 Uhr schrieb Juha Niskanen (Haltian) < juha.niska...@haltian.com>: > Hi, > > Adding that subsystem was my first experience with 1-wire. I don't like > tinkering with buses like I2C/SPI/1-wire, especially about 1-wire I have > forgotten nearly all details already. Feel free to re-organize this any way > you like. > > -Juha > > -- > *From:* Marco > *Sent:* Saturday, April 3, 2021 5:03 PM > *To:* dev@nuttx.apache.org > *Cc:* Juha Niskanen (Haltian) > *Subject:* Re: 1wire subsystem > > Hi Alan, > yes of course, moving to include/nuttx/1wire/1wire_master.h also means > splitting into different header files 1wire_master.h 1wire_slave.h and so > on. > Maybe juha doesn't knew if this is 1wire specific. I think the fact that > only maxim integrated/or dallas provides chips for the 1wire bus it is a > quasi-standard. ;) > At least I didn't found 1wire chips from other vendors. > > Marco > > Am Sa., 3. Apr. 2021 um 15:47 Uhr schrieb Alan Carvalho de Assis < > acas...@gmail.com>: > > Hi Marco, > > This code was submitted by Juha, maybe he has some rational why it was > put there. > > In fact the structures and functions definition seam to be generic and > should be at include/ > > But, including that file inside 1wire_master.h is not correct, because > it was has slaves definition. > > BR, > > Alan > > On 4/3/21, Marco wrote: > > Hi > > > > I currently working on a sensor driver for a temperature sensor DS18B20 > > connected on a 1wire bus. > > > > It seems to be that logic exists under drivers/1wire/1wire.c that > provides > > a common mechanism to select a sensor on the bus by their unique rom > code. > > I'm not quite sure if that procedure is specific for sensors from vendor > > maxim integrated or if it's 1wire specific. But the interface for that > > implementation is under drivers/1wire/1wire_internal.h at the moment. > > When this implementation is 1wire specific, I would ask if we can move > the > > interface specification to include/nuttx/1wire/1wire_master.h > > I would expect something similar to the i2c interface. > > Currently, I can't use the logic because of restricted access to that > > interface from the sensors subdirectory. > > > > Marco > > > >
ZeroMQ
Hello, I've been experimenting to build ZeroMQ work with NuttX and I wanted to share my results so far. TLDR: it works Please, understand that I am very new to NuttX so please tell me with any conceptual errors I might be facing! https://github.com/casaroli/incubator-nuttx/tree/zeromq I think we need to be able to use this library both from kernel code and from applications, so I guessed this would fit along libxx and libdsp, etc. So I basically copied many stuff from those directories into libs/libzmq Still needs a lot of work, so next steps are to find a way to run the tests, then to make platform.hpp defines use nuttx/config.h, add czmq (higher level interface). However, in the current state, I could get IPC through Unix Domain Sockets and TCP. inproc also works fine. I wrote some simple examples (not on the repo) and they work. I want to know if anyone else is interested in helping with this (make ZeroMQ/czmq, nng, etc. work). Thank you.
Re: ZeroMQ
I am doing this. Will share in a couple of weeks. On Mon, 6 Feb 2023 at 09:41, Sebastien Lorquet wrote: > Hi, > > this is very interesting, thanks for sharing this. > > Did anyone already integrate nng in NuttX ? > > Sebastien > > Le 04/02/2023 à 03:02, David S. Alessio a écrit : > > All, > > > > ZeroMQ is/was quite popular, but its author redesigned it, created a > much cleaner implementation called “nanomsg”, > > ref: https://nanomsg.org/documentation-zeromq.html < > https://nanomsg.org/documentation-zeromq.html> > > ref: https://nanomsg.org/index.html < > https://nanomsg.org/index.html> > > > > And then he rewrote it again: > > ref: https://nng.nanomsg.org/RATIONALE.html < > https://nng.nanomsg.org/RATIONALE.html> > > and called it nng: > > ref: https://nng.nanomsg.org <https://nng.nanomsg.org/> > > > > So, in short, if one is interested in ZeroMQ and NuttX, I’d suggest > nanomsg would be a much more efficient replacement; and finally the best > choice of the three IMHO would be nng for an embedded system (Cortex-M3/4 > class) system. > > > > Just my $0.025, I hope it’s helpful. > > > > Cheers, > > -david > > > > > > > >> On Feb 3, 2023, at 2:24 AM, Xiang Xiao > wrote: > >> > >> On Fri, Feb 3, 2023 at 4:31 PM Marco Casaroli > >> marco.casar...@midokura.com.invalid>> wrote: > >> > >>> Hello, > >>> > >>> I've been experimenting to build ZeroMQ work with NuttX and I wanted to > >>> share my results so far. > >>> > >>> TLDR: it works > >>> > >>> Please, understand that I am very new to NuttX so please tell me with > any > >>> conceptual errors I might be facing! > >>> > >>> https://github.com/casaroli/incubator-nuttx/tree/zeromq > >>> > >>> I think we need to be able to use this library both from kernel code > and > >>> from applications, so I guessed this would fit along libxx and libdsp, > etc. > >>> > >>> > >> Kernel code needs to call some special API(e.g. kmm_malloc, psock_send > and > >> file_open), I amn't sure whether is it easy to adjust ZeroMQ for this > type > >> of change. > >> > >> > >>> So I basically copied many stuff from those directories into > libs/libzmq > >>> > >>> Still needs a lot of work, so next steps are to find a way to run the > >>> tests, then to make platform.hpp defines use nuttx/config.h, add czmq > >>> (higher level interface). > >>> > >>> However, in the current state, I could get IPC through Unix Domain > Sockets > >>> and TCP. inproc also works fine. > >>> > >>> I wrote some simple examples (not on the repo) and they work. > >>> > >>> I want to know if anyone else is interested in helping with this (make > >>> ZeroMQ/czmq, nng, etc. work). > >>> > >>> > >> Yes, it's definitely good to support more 3rd party general libraries. > >> > >> > >>> Thank you. > > >
Re: Build system is broken
Try make V=1 On Tue, 7 Mar 2023 at 09:18, Sebastien Lorquet wrote: > Hi, > > This morning I updated my working copy, ran git pull origin master and > rebuilt my OS > > Now when I run make I get no output. But the cpu fan works. > > Only the last line of the console shows text, there is no log makefile > anymore. > > This is AWFUL! > > What happened? > > Was make updated by linux mint? > > Were makefiles in nuttx updated in such a profound way? > > I frankly dont understand. > > Sebastien > >
RP2350 port
Hello, I got my hands on some Raspberry Pi Pico 2 boards and I can finally run NuttX on them. It took some work, since the M33 core is a bit different than the M0 on the old RP2040. It is working now (nsh and usbnsh configs at least) and even ostest is passing. For my initial PoC, I just edited many files in the rp2040 port but I will create a new rp23xx port and I have some questions on how to organize the files: 1 Where should I put the arch files? Should I put them in arch/arm/src/rp23xx or should they be in a different path that could be reused by the RISC-V and ARM boards? Should we make another arch subdir like arch/multi? Or just have rp23xx in both risc-v and arm directories? If so, then what about the files that are the same and could be reused. Where to put them? Should I care to reuse these files or I can just copy them over when we make the risc-v port? 2. How should I differentiate the boards? should I call raspberry-pi-pico2-arm and raspberry-pi-pico2-riscv? 3. Some of the files could be shared / reused by rp2040 (ARM Cortex M0) and rp23xx (riscv and ARM Cortex M33), how should I proceed to reuse these files and have them in a common directory. What directory would be best? I plan on pushing a PR with the modifications later this week. Thank you!
RP2350 port part 2
Hello again, I have followed Greg's advice and put the files in arch/arm/rp23xx I have some more questions for you. I start a new email thread to not generate noise in the previous discussion. 1. The RP port needs some hardware (include) files from pico-sdk. Should I: a. put the instructions how to download pico sdk and set PICO_SDK_PATH so we can use the files from there b. download the pico-sdk automatically in the Makefile and use it to build c. copy the relevant files from pico-sdk to Nuttx tree 2. (if answer to Q1 is option a, then), should I reformat the imported code to match NuttX or I can just drop the files there without any modifications? (they are BSD-licensed) 3. Should I aim to make this port work on rp2040 (and rename it to rp2xxx) - the drivers are very similar, or should I keep it separated and target rp23xx only? 4. How should I test the peripherals? I don't have all the LCD displays and the other accessories supported by RP2040 port. Should I: a. keep the peripherals code for LCD, etc and hope that it will work (explain in the documentation that it is not tested) b. just add the minimum code without those peripherals support c. buy the missing stuff or find other people to test it before I open the PR by the way, of anyone is interested in testing and helping there is my WIP branch (very dirty for now) here it is: https://github.com/casaroli/nuttx/tree/pico2 My next steps are to test SMP, UART1, SPI, I2C, ADC, DMA (that I can do without other accessories). Thank you.
Re: RP2350 port part 2
On Thu, Aug 29, 2024 at 11:34 AM wrote: > On 2024-08-29 11:17:06, Marco Casaroli wrote: > > I have some more questions for you. I start a new email thread to not > > generate noise in the previous discussion. > > > > 1. The RP port needs some hardware (include) files from pico-sdk. Should > I: > Nuttx does not include nor use any of the OEM SDK. This is double edge > sword. > It takes longer to implement driver, but those drivers are usually better > fitted, better quality and less buggy than OEM drivers. > > If these are only register definitions than you may be able to get away > with > this (if license permits it and by doing some reformating). Including code > is probably a no go. > Thank you for the clarification. These are not drivers. The driver are indeed part of the port. These files are just register definitions and structs, so only .h files, not .c. I could generate it with SVDConv, or just copy the already generated code from their sdk. Should I reformat the generated code? (I am talking about this code: https://github.com/apache/nuttx/tree/master/arch/arm/src/rp2040/hardware) > > > 2. (if answer to Q1 is option a, then), should I reformat the imported > code > > to match NuttX or I can just drop the files there without any > > modifications? (they are BSD-licensed) > Usually reformat won't cut it as you need to follow Nuttx specifi API. > Second thing is maintaning that code. OEM code tries to handle all possible > cases, so there are a lot of code. And drivers usually need only a small > subset of features that is required for it to work. Not going for corner > cases > make code so much smaller and easier to maintaing. If you reformat OEM > code, > someone has to maintain it - and just copying updated file from OEM will > not > work. > > As in question 1, the drivers are in the NuttX port and not imported by the SDK > > > > 3. Should I aim to make this port work on rp2040 (and rename it to > rp2xxx) > > - the drivers are very similar, or should I keep it separated and target > > rp23xx only? > Code deduplication is always good thing. Problem is that it's a lot of work > to kickstart it. Because of that there are tons of duplicated code - > especially > for stm32, stm32wl5 and stm32wb. They are mostly the same, but are still > duplicated. > > I will ignore RP2040 for now. > > > > 4. How should I test the peripherals? I don't have all the LCD displays > and > > the other accessories supported by RP2040 port. Should I: > > > > a. keep the peripherals code for LCD, etc and hope that it will work > > (explain in the documentation that it is not tested) > > b. just add the minimum code without those peripherals support > > c. buy the missing stuff or find other people to test it before I open > the > > PR > Best is C of course :) but noone will expect from you to buy stuff to write > the drivers - you do it only if you want to support project using not only > your time but also money. So go B. It's better to not have things than have > them half cooked in buggy state (I'm looking at you zephyr). > I will remove the code for stuff I cannot test right now. Thank you. > > -- > > .-.---.--.-. > | Michal Lyszczek | Embedded C, Linux | Company Address| .-. > opensource | > | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| > supporter | > | https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\ > & | > | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) > programer | > > `--^--^--^-' >
Re: NuttX "gadget": resolve its host name via CDC/NCM connection
Why not just write a DNS-SD daemon that will send some URP packets and then the peers can resolve the hostname? http://www.dns-sd.org On Wed, 9 Oct 2024 at 02:04, Tim Hardisty wrote: > Not a NuttX question, as such, more a basic embedded device networking > question. But you’re all so helpful, and it’s NuttX things I need to do > this :-) > > I have just tried the recently added CDC/NCM USB networking and it works > very nicely. Coupled with DHCPD, I can have a PC (Windows or Linux; not > tried MAC yet) get an IP address and immediately I can exchange data > (well…ping between them). And I have set a hostname for my NuttX “gadget” > and uname reports it properly. > > My intention is to implement a simple web server on the device so as to be > able to plug in to it via usb, go to a browser, and go to “http://gadget” > rather than “http://10.0.0.10” (for example). > > This is DNS…but my embedded networking knowledge is limited and I am not > sure what NuttX tools/daemons/examples/whatever I need to use for this? > > I don’t think a hosts file on the gadget is right, as the PC can’t use > that to match hostname to IP (and editing a hosts file on the PC is not an > option in this case). So probably the gadget needs to also be a DNS server? > But I can’t find much information on how to use the NuttX implementation of > this. > > Have I got that right or am I missing something? > > Happy to repay “information that leads to a successful prosecution” ;-) by > adding to the NuttX “How To” documentation if appropriate > > Thanks, > > TimJTi.
POSIX environ variable
Hello, I am sorry if this was already discussed before. I could not find concrete information in the documentation or the mailing list history. According to POSIX specifications [1]: > The array is pointed to by the external variable environ, which is defined as: > > extern char **environ; But in NuttX, it is defined differently [2], when CONFIG_DISABLE_ENVIRON is not set, like: > # define environ get_environ_ptr() Which calls a function [3] and gets its result. This gives problems if the apps try to do things like: > environ = ...; Which is, in fact, fairly common [4, 5, 6]. So I have two questions: 1. What is the cleanest way to work around the environment update these apps are trying to do? What are the changes I should make to the app code so that it can correctly handle setting the environment? 2. Is there any way we can update NuttX to actually define environ like POSIX specifies, so that we can handle these apps without modifications? Thank you very much. BR // Marco Casaroli [1] https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/basedefs/V1_chap08.html [2] https://github.com/apache/nuttx/blob/0fad2ee73f5431cbe34cc02253909f290938cd12/include/stdlib.h#L70 [3] https://github.com/apache/nuttx/blob/0fad2ee73f5431cbe34cc02253909f290938cd12/sched/environ/env_getenvironptr.c#L57 [4] https://github.com/landley/toybox/blob/c47184b389d5bf97135afbf55aa4a41bc29812eb/lib/env.c#L29 [5] https://github.com/landley/toybox/blob/c47184b389d5bf97135afbf55aa4a41bc29812eb/toys/pending/sh.c#L1379 [6] https://github.com/mirror/busybox/blob/371fe9f71d445d18be28c82a2a6d82115c8af19d/shell/ash.c#L10574
Re: RP2040 multiple GPIO interrupts
Hello, You can do this in software: check the line status if it is low, then you set the interrupt to rising edge and if it is high you set to falling edge, any time the interrupt happens, you carefully change to falling or rising depending on the status. On Mon, Mar 17, 2025 at 22:18 Matteo Golin wrote: > Hello everyone, > > I have an application wherein I am using a W5500-EVB Pico as the MCU for a > network controlled system. I need to connect > several switch inputs into this MCU. The switches are normally held high > via the RP2040's internal pullups, and pulled > low when flipped. > > The problem I'm encountering is that it appears that the current RP2040 > support only allows for one type of interrupt > per pin: either rising edge or falling edge. I need to trigger on both > rising and falling edge to accurately track the > state of the switch. I'm wondering if anyone else has had a similar issue > or has suggestions about how I can resolve > this. > > Thanks, > > -- > Matteo Golin >
