Re: Device Discovery
Hi Xiang, I meant multiple daemons in reference to what Alan mentioned about there being daemons to detect the various components currently. Hope this clears it. Regards, SP On Wed, Feb 21, 2024 at 12:00 PM Xiang Xiao wrote: > Even though PCs just have one udev daemon, I don't see why MCU needs > multiple daemon. > > On Wed, Feb 21, 2024 at 2:07 PM Saurav Pal wrote: > > > Hi, > > > > Thanks for the clarification. > > > > Also, am I right in thinking it would increase performance if there was a > > single daemon working rather than multiple? (I am thinking in terms of > > context switches for tasks, even if, say, somehow the memory consumption > > remains the same). > > > > Regards, > > SP > > > > On Tue, Feb 20, 2024 at 10:13 PM Xiang Xiao > > wrote: > > > > > Since all devices expose through vfs (/dev, /proc), udev could be > > > implemented through inotify API. > > > > > > On Tue, Feb 20, 2024 at 11:31 PM Alan C. Assis > > wrote: > > > > > > > Hi Saurav, > > > > > > > > There is not something like a "udev" for NuttX, but there are > > > > daemons/services used to detect when a SDCard is plugged, when a USB > > > > device is attached, etc. > > > > > > > > We could add something like a lite "udev" for NuttX. > > > > > > > > Best Regards, > > > > > > > > Alan > > > > > > > > On 2/20/24, Saurav Pal wrote: > > > > > Hi all, > > > > > > > > > > I am not able to understand how NuttX performs device discovery. I > am > > > > > trying to look for something that is similar to "udev". Can someone > > > > please > > > > > help me understand? > > > > > > > > > > Thanks in advance. > > > > > Regards, > > > > > SP > > > > > > > > > > > > > > >
Re: Device Discovery
Even though PCs just have one udev daemon, I don't see why MCU needs multiple daemon. On Wed, Feb 21, 2024 at 2:07 PM Saurav Pal wrote: > Hi, > > Thanks for the clarification. > > Also, am I right in thinking it would increase performance if there was a > single daemon working rather than multiple? (I am thinking in terms of > context switches for tasks, even if, say, somehow the memory consumption > remains the same). > > Regards, > SP > > On Tue, Feb 20, 2024 at 10:13 PM Xiang Xiao > wrote: > > > Since all devices expose through vfs (/dev, /proc), udev could be > > implemented through inotify API. > > > > On Tue, Feb 20, 2024 at 11:31 PM Alan C. Assis > wrote: > > > > > Hi Saurav, > > > > > > There is not something like a "udev" for NuttX, but there are > > > daemons/services used to detect when a SDCard is plugged, when a USB > > > device is attached, etc. > > > > > > We could add something like a lite "udev" for NuttX. > > > > > > Best Regards, > > > > > > Alan > > > > > > On 2/20/24, Saurav Pal wrote: > > > > Hi all, > > > > > > > > I am not able to understand how NuttX performs device discovery. I am > > > > trying to look for something that is similar to "udev". Can someone > > > please > > > > help me understand? > > > > > > > > Thanks in advance. > > > > Regards, > > > > SP > > > > > > > > > >
Re: Device Discovery
Hi, Thanks for the clarification. Also, am I right in thinking it would increase performance if there was a single daemon working rather than multiple? (I am thinking in terms of context switches for tasks, even if, say, somehow the memory consumption remains the same). Regards, SP On Tue, Feb 20, 2024 at 10:13 PM Xiang Xiao wrote: > Since all devices expose through vfs (/dev, /proc), udev could be > implemented through inotify API. > > On Tue, Feb 20, 2024 at 11:31 PM Alan C. Assis wrote: > > > Hi Saurav, > > > > There is not something like a "udev" for NuttX, but there are > > daemons/services used to detect when a SDCard is plugged, when a USB > > device is attached, etc. > > > > We could add something like a lite "udev" for NuttX. > > > > Best Regards, > > > > Alan > > > > On 2/20/24, Saurav Pal wrote: > > > Hi all, > > > > > > I am not able to understand how NuttX performs device discovery. I am > > > trying to look for something that is similar to "udev". Can someone > > please > > > help me understand? > > > > > > Thanks in advance. > > > Regards, > > > SP > > > > > >
Re: Assert macro causing problems when building Sqlite
Here is the fix: https://github.com/apache/nuttx/pull/11734. sqlite porting is also upstreamed: https://github.com/apache/nuttx-apps/pull/2297 On Tue, Feb 20, 2024 at 3:17 PM Jernej Turnsek wrote: > Hi, > > the same problem as new UNUSED macro was causing me problems when building > external libraries, like LuaJIT, an assert macro is also causing problems > when building Sqlite3 library. Sqlite code has a lot of assert statements > which are usually excluded when NDEBUG is set. But when assert is defined > as: > > #ifdef NDEBUG > # define assert(f) ((void)(1 || (f))) > # define VERIFY(f) assert(f) > #else > > compiler throws undefined variable errors all the time. With simple (void)0 > definition there is no problem. Yet another reason to evaluate this change > of UNUSED and assert macro? > > Jernej >
Nuttx not starting after jumping from bootloader
Hello Nuttx team, I'm currently working on an embedded project that uses a bootloader and an application. The target is a STM32G0B1VCI6 chip. I'm using the initial address (0x0800 ) for the bootloader with 40K of size. Application starts at 0x0800 A000 with 216K of size. Before jumping to the application I'm setting the main stack pointer and configuring the vector table to point to the start address of the app. I see that the app is executed but it remains in the function irq_initialize and doing some debug I noticed that it is stuck in the assert function, in an infinite loop: [cid:image003.jpg@01DA63E7.A577AD90] I wonder if nuttx has some dependencies with the initial addresses or if there is something that must be configured before jumping. This is the code I have for the jumping: [cid:image004.png@01DA63E7.A577AD90] Where NUTTX_APPLICATION_ENTRY_POINT is 0x0800A000. I did a different test using another application (without nuttx) and the bootloader can jump without any problem and the application can be executed. I would appreciate your help. Thanks José Daniel Ambrocio Embedded SW Engineer
Re: Better FPGA support on NuttX //was Re: [OT] Projects for GSoC 2024
You have many options for LED control and some of them are not small... The colorlight i9 has a 45K device that's medium size in my view then you have the ones that were used for bitcoin mining that have large devices like the Zynq models, and are super cheap nowadays since those boards were superseded by ASICs and nobody want them On Tue, Feb 20, 2024 at 1:21 PM Alan C. Assis wrote: > Hi Victor, thank you very much for this information and this link. > > I found a nice project using that board: > > https://github.com/lucysrausch/colorlight-led-cube > > I remember also seeing some FPGA board to control LEDs panel that > could be used as ordinary FPGA dev tool. But I think these boards > don't have much LE internally, right? > > Best Regards, > > Alan > > On 2/19/24, Victor Suarez Rovere wrote: > > Reference to cheap FPGA boards (< $20) were added to the new repo, more > > docs will follow there: https://github.com/cederom/nuttx-fpga > > So, FPGA is not strictly related to $$$ > > >
Re: Device Discovery
Since all devices expose through vfs (/dev, /proc), udev could be implemented through inotify API. On Tue, Feb 20, 2024 at 11:31 PM Alan C. Assis wrote: > Hi Saurav, > > There is not something like a "udev" for NuttX, but there are > daemons/services used to detect when a SDCard is plugged, when a USB > device is attached, etc. > > We could add something like a lite "udev" for NuttX. > > Best Regards, > > Alan > > On 2/20/24, Saurav Pal wrote: > > Hi all, > > > > I am not able to understand how NuttX performs device discovery. I am > > trying to look for something that is similar to "udev". Can someone > please > > help me understand? > > > > Thanks in advance. > > Regards, > > SP > > >
Re: Better FPGA support on NuttX //was Re: [OT] Projects for GSoC 2024
Hi Victor, thank you very much for this information and this link. I found a nice project using that board: https://github.com/lucysrausch/colorlight-led-cube I remember also seeing some FPGA board to control LEDs panel that could be used as ordinary FPGA dev tool. But I think these boards don't have much LE internally, right? Best Regards, Alan On 2/19/24, Victor Suarez Rovere wrote: > Reference to cheap FPGA boards (< $20) were added to the new repo, more > docs will follow there: https://github.com/cederom/nuttx-fpga > So, FPGA is not strictly related to $$$ >
Re: Device Discovery
Hi Saurav, There is not something like a "udev" for NuttX, but there are daemons/services used to detect when a SDCard is plugged, when a USB device is attached, etc. We could add something like a lite "udev" for NuttX. Best Regards, Alan On 2/20/24, Saurav Pal wrote: > Hi all, > > I am not able to understand how NuttX performs device discovery. I am > trying to look for something that is similar to "udev". Can someone please > help me understand? > > Thanks in advance. > Regards, > SP >
Device Discovery
Hi all, I am not able to understand how NuttX performs device discovery. I am trying to look for something that is similar to "udev". Can someone please help me understand? Thanks in advance. Regards, SP
Community Over Code Asia 2024 Travel Assistance Applications now open!
Hello to all users, contributors and Committers! The Travel Assistance Committee (TAC) are pleased to announce that travel assistance applications for Community over Code Asia 2024 are now open! We will be supporting Community over Code Asia, Hangzhou, China July 26th - 28th, 2024. TAC exists to help those that would like to attend Community over Code events, but are unable to do so for financial reasons. For more info on this year's applications and qualifying criteria, please visit the TAC website at < https://tac.apache.org/ >. Applications are already open on https://tac-apply.apache.org/, so don't delay! The Apache Travel Assistance Committee will only be accepting applications from those people that are able to attend the full event. Important: Applications close on Friday, May 10th, 2024. Applicants have until the the closing date above to submit their applications (which should contain as much supporting material as required to efficiently and accurately process their request), this will enable TAC to announce successful applications shortly afterwards. As usual, TAC expects to deal with a range of applications from a diverse range of backgrounds; therefore, we encourage (as always) anyone thinking about sending in an application to do so ASAP. For those that will need a Visa to enter the Country - we advise you to apply now so that you have enough time in case of interview delays. So do not wait until you know if you have been accepted or not. We look forward to greeting many of you in Hangzhou, China in July, 2024! Kind Regards, Gavin (On behalf of the Travel Assistance Committee)
Re: fcntl F_SETLK, F_SETLKW, F_GETLK
here is the patch set: https://github.com/apache/nuttx/pull/11724 On Tue, Feb 20, 2024 at 3:29 PM Jernej Turnsek wrote: > Cool. Is there a possibility to share your work via PM? This way I can test > the solution on my side also. > Jernej > > On Tue, Feb 20, 2024 at 8:23 AM Xiang Xiao > wrote: > > > We have implemented file lock to support the database engine like sqlite > > and unqlite. The implementation will go upstream soon. > > > > On Tue, Feb 20, 2024 at 3:04 PM Jernej Turnsek > > > wrote: > > > > > Hi, > > > I would like to use Sqlite on NuttX and I have managed to successfully > > > build the Sqlite3 library. When running the library, I have noticed > that > > > Sqlite is using fcntl F_SETLK and F_SETLKW for locking and those are > not > > > implemented on NuttX. Is there a plan to implement this in the future? > > > > > > Regards, > > > Jernej > > > > > >
