Re: Addition of New Chip STM32F427AI
The STM32F427AI is in the same family as STM32F427xx (STM32F427V, STM32F427Z, STM32F427I) and STM32F429xx, which are already supported. The first thing to do is to decide which is of the supported parts is most like the STM32F427AI. Mostly likely it is just a difference in memory size or something similar. The package STM32F427AI has more pins so some other functionality must be brought out. On 2/12/2024 2:06 PM, Alan C. Assis wrote: Hi Janardhan, You can start looking at which STM32F4xx chip existent on NuttX is more similar to STM32F427AI and start your port based on it. You can do it using the chip datasheet and/or reference manual, writing down the difference in peripherals, registers, etc. Normally STM32 devices share many features, but sometimes they have small incompatibilities. So, look the existing chips on NuttX (nuttx/arch/arm/src/stm32/hardware/ and nuttx/arch/arm/include/stm32/ Best Regards, Alan On Mon, Feb 12, 2024 at 8:50 AM Janardhan Silwal < janardhansil...@outlook.com> wrote: Hi Community, I have a board which uses STM32F427AI, and was planning on running a middleware which runs over nuttx, but only noticed, after the board arrived from manufacturing that there is no option to select, STM32F427AI from the menuconfig/qconfig. I don't have an option to replace the chip to the ones which are currently supported and thus, want to add the support for STM32F427AI, but don't know where to start. Hoping to get some direction, from where I can start. Thanks in advance. janardhan
Re: Detecting FS
Hi Greg, Thanks for the clarification! That was what I was looking for, the part about the need for explicitly stating the FS. Regards, SP On Tue, 13 Feb, 2024, 02:05 Gregory Nutt, wrote: > You would need to mount with -t vfat. That is how it the system knows > that the file system is vfat. > > It seems like you should be able to omit the file system type when > mounting and let the system figure out the file system type, but that > does not appear to be supported. > > On 2/12/2024 2:30 PM, Saurav Pal wrote: > > Hi Alan, > > > > Thanks for the reply. I had gone through that global array but I couldn't > > find what I was looking for. > > > > In a different phrasing, what I don't understand is how is it detected > > which file system was used to format a storage device. > > > > Like, let's say I have a HDD in my PC formatted with VFAT, and if I use > it > > with NuttX, how will it detect VFAT is being used? > > > > Magic numbers are unique for FSs, but I have not seen / missed where they > > are being stored on the disk for identification. > > > > Regards, > > SP > > > > On Tue, 13 Feb, 2024, 01:42 Alan C. Assis, wrote: > > > >> Hi Saurav, > >> > >> Please take a look at "static const struct fsmap_t g_bdfsmap[]" in the > file > >> nuttx/fs/mount/fs_mount.c > >> > >> You will figure-out how the "magic" happens. > >> > >> Best Regards, > >> > >> Alan > >> > >> On Mon, Feb 12, 2024 at 9:20 AM Saurav Pal > wrote: > >> > >>> Hi all, > >>> > >>> I am trying to write some docs for VFS in NuttX, but there's one thing > >> I've > >>> been stumbling on for some time. > >>> > >>> How are the file systems detected from the storage devices? For > example, > >> if > >>> I have a storage device which has been formatted using VFAT...after > (say) > >>> power on, how does NuttX detect that vfat was used to format the > storage > >>> device? > >>> > >>> From what I can see, NuttX does not have a "superblock" concept > >> explicitly > >>> defined, nor does it seem to require the file systems to store magic > >>> numbers in the disk in any way. > >>> > >>> Thanks in advance. > >>> Regards, > >>> SP > >>> >
Re: Detecting FS
You would need to mount with -t vfat. That is how it the system knows that the file system is vfat. It seems like you should be able to omit the file system type when mounting and let the system figure out the file system type, but that does not appear to be supported. On 2/12/2024 2:30 PM, Saurav Pal wrote: Hi Alan, Thanks for the reply. I had gone through that global array but I couldn't find what I was looking for. In a different phrasing, what I don't understand is how is it detected which file system was used to format a storage device. Like, let's say I have a HDD in my PC formatted with VFAT, and if I use it with NuttX, how will it detect VFAT is being used? Magic numbers are unique for FSs, but I have not seen / missed where they are being stored on the disk for identification. Regards, SP On Tue, 13 Feb, 2024, 01:42 Alan C. Assis, wrote: Hi Saurav, Please take a look at "static const struct fsmap_t g_bdfsmap[]" in the file nuttx/fs/mount/fs_mount.c You will figure-out how the "magic" happens. Best Regards, Alan On Mon, Feb 12, 2024 at 9:20 AM Saurav Pal wrote: Hi all, I am trying to write some docs for VFS in NuttX, but there's one thing I've been stumbling on for some time. How are the file systems detected from the storage devices? For example, if I have a storage device which has been formatted using VFAT...after (say) power on, how does NuttX detect that vfat was used to format the storage device? From what I can see, NuttX does not have a "superblock" concept explicitly defined, nor does it seem to require the file systems to store magic numbers in the disk in any way. Thanks in advance. Regards, SP
Re: Detecting FS
Hi Alan, Thanks for the reply. I had gone through that global array but I couldn't find what I was looking for. In a different phrasing, what I don't understand is how is it detected which file system was used to format a storage device. Like, let's say I have a HDD in my PC formatted with VFAT, and if I use it with NuttX, how will it detect VFAT is being used? Magic numbers are unique for FSs, but I have not seen / missed where they are being stored on the disk for identification. Regards, SP On Tue, 13 Feb, 2024, 01:42 Alan C. Assis, wrote: > Hi Saurav, > > Please take a look at "static const struct fsmap_t g_bdfsmap[]" in the file > nuttx/fs/mount/fs_mount.c > > You will figure-out how the "magic" happens. > > Best Regards, > > Alan > > On Mon, Feb 12, 2024 at 9:20 AM Saurav Pal wrote: > > > Hi all, > > > > I am trying to write some docs for VFS in NuttX, but there's one thing > I've > > been stumbling on for some time. > > > > How are the file systems detected from the storage devices? For example, > if > > I have a storage device which has been formatted using VFAT...after (say) > > power on, how does NuttX detect that vfat was used to format the storage > > device? > > > > From what I can see, NuttX does not have a "superblock" concept > explicitly > > defined, nor does it seem to require the file systems to store magic > > numbers in the disk in any way. > > > > Thanks in advance. > > Regards, > > SP > > >
Re: Detecting FS
Hi Saurav, Please take a look at "static const struct fsmap_t g_bdfsmap[]" in the file nuttx/fs/mount/fs_mount.c You will figure-out how the "magic" happens. Best Regards, Alan On Mon, Feb 12, 2024 at 9:20 AM Saurav Pal wrote: > Hi all, > > I am trying to write some docs for VFS in NuttX, but there's one thing I've > been stumbling on for some time. > > How are the file systems detected from the storage devices? For example, if > I have a storage device which has been formatted using VFAT...after (say) > power on, how does NuttX detect that vfat was used to format the storage > device? > > From what I can see, NuttX does not have a "superblock" concept explicitly > defined, nor does it seem to require the file systems to store magic > numbers in the disk in any way. > > Thanks in advance. > Regards, > SP >
Re: Addition of New Chip STM32F427AI
Hi Janardhan, You can start looking at which STM32F4xx chip existent on NuttX is more similar to STM32F427AI and start your port based on it. You can do it using the chip datasheet and/or reference manual, writing down the difference in peripherals, registers, etc. Normally STM32 devices share many features, but sometimes they have small incompatibilities. So, look the existing chips on NuttX (nuttx/arch/arm/src/stm32/hardware/ and nuttx/arch/arm/include/stm32/ Best Regards, Alan On Mon, Feb 12, 2024 at 8:50 AM Janardhan Silwal < janardhansil...@outlook.com> wrote: > Hi Community, > > I have a board which uses STM32F427AI, and was planning on running a > middleware which runs over nuttx, but only noticed, after the board arrived > from manufacturing that there is no option to select, STM32F427AI from the > menuconfig/qconfig. > > I don't have an option to replace the chip to the ones which are currently > supported and thus, want to add the support for STM32F427AI, but don't > know where to start. > > Hoping to get some direction, from where I can start. > > Thanks in advance. > janardhan >
Detecting FS
Hi all, I am trying to write some docs for VFS in NuttX, but there's one thing I've been stumbling on for some time. How are the file systems detected from the storage devices? For example, if I have a storage device which has been formatted using VFAT...after (say) power on, how does NuttX detect that vfat was used to format the storage device? >From what I can see, NuttX does not have a "superblock" concept explicitly defined, nor does it seem to require the file systems to store magic numbers in the disk in any way. Thanks in advance. Regards, SP
Addition of New Chip STM32F427AI
Hi Community, I have a board which uses STM32F427AI, and was planning on running a middleware which runs over nuttx, but only noticed, after the board arrived from manufacturing that there is no option to select, STM32F427AI from the menuconfig/qconfig. I don't have an option to replace the chip to the ones which are currently supported and thus, want to add the support for STM32F427AI, but don't know where to start. Hoping to get some direction, from where I can start. Thanks in advance. janardhan
Re: NuttX + MicroPython + ESP32 / ESP32-C3
Hi, The embed port method they suggested on my issue ticket looks promising. I'm looking at this right now. Sebastien Le 10/02/2024 à 10:24, Victor Suarez Rovere a écrit : I ported Micropython to various platforms (CPU and FPGA), including peripherals like Video output, so I can help with porting to NuttX: See my developments: https://github.com/suarezvictor/micropython/tree/litex-rebase/ports/litex#readme Who else can contribute? On Fri, Feb 9, 2024 at 2:27 PM Sebastien Lorquet wrote: Hi, Not sure I'm going to wait24Q3 :-) I'm certainly not focussed enough :-) https://github.com/micropython/micropython/issues/13632 Let's see what they think. The only real issue is "how to build a micropython port that links to a static lib" :) And maybe how to avoid duplicating mbedtls and some other libs in some cases... but that can wait. Sebastien Le 09/02/2024 à 18:16, Tomek CEDRO a écrit : Yes exactly, I was also thinking to make MicroPython a NuttX application, just like we have Python on desktop, so it builds out of the box and provides generic access no matter what arch/board, no hardcoded hardware specific stuff, all hardware interaction done though /dev :-) I am switching from hardware project right now more into a software development right now but I am still rushing so I will have more time for that around 2024Q3 but we can create a dedicated fork repo and play there when stuff is ready we can push to both upstreams..? :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info On Fri, Feb 9, 2024 at 6:07 PM Sebastien Lorquet wrote: Hi, I found the deletion commit: https://github.com/apache/nuttx-apps/commit/abcb66cb20d85b910d55854de51b197eaa468e8b I think it should not work like that today. Also, it looks like it does not come with micropython libraries... We should contribute anything required in micropython itself so it can be built as a kind of library, and have the absolute required minimum in nuttx-apps to allow linking with this lib. What do you think? Sebastien Le 09/02/2024 à 16:09, Tomek CEDRO a écrit : Hey there Sebastien :-) NuttX is so well organized that writing bare C here is far more efficient "rapid prototyping" so I had no more need to use MicoPython as it turned out memory hungry for bigger applications. But still I am fan of Python so we could resurrect the idea :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info On Fri, Feb 9, 2024 at 4:04 PM Sebastien Lorquet wrote: Hi, I think I may like to have micropython work again on NuttX. Where can I find the latest efforts on this project, to try my hand on it? Sebastien Le 26/10/2021 à 04:16, Tomasz CEDRO a écrit : On Mon, Oct 25, 2021 at 7:45 PM Xiang Xiao wrote: On Mon, Oct 25, 2021 at 11:37 PM Tomasz CEDRO wrote: On Mon, Oct 25, 2021 at 4:44 PM Alan Carvalho de Assis wrote: Hi Tomasz, MicroPython was integrated in NuttX at some time ago, but it started to crash and was removed. Yup, I saw some websites stating it work here but I could not find among interpreters. Thanks for the hint Alan :-) I think someone started a discussion about it on discord, but I don't know what happened later. I would prefer to keep critical discussions here on the list as they are easier to find later on and may give hints to the others :-) Stuff like IRC or Discord I may prefer for short term tasks :-) As I told you ESP32-C3 has a good support on NuttX and Xiaomi is already using it internally (it passed on their certification process). Yup :-) NuttX claims full support for ESP32-C3 while Zephyr lags behind in this area (only GPIO, UART and BLE is currently implemented). I know that already, thanks :-) But my question was closely related to MicroPython and NuttX and SoC driver support / architecture that is still unknown to me, sorry, maybe this will clarify: 1. Is there some sort of HAL in NuttX that when driver for a SoC is ported makes it available freely for every other functionality already implemented (like in Zephyr)? No, NuttX doesn't like HAL, but NuttX defines many device driver interfaces(from uart, i2c, spi to gpio...). All expose their functionality as device files(e.g. /dev/ttyS0, /dev/gpio). Other complex devices expose through: 1. File system API(e.g. block device, flash, mtd...) 2. Socket API(e.g. ethernet, WiFi, CAN...) Thank you Xiao! Looks more and more like Unix on MCU :-) 2. Would dedicated functionalities, like MicroPython, require separate implementation of drivers for each SoC or will it use existing drivers? Since all above functionality is exposed to userspace through the standard interface. MicroPython port can be done in a general way which means that once you finish the porting, all boards supported by NuttX will get the same functionality freely. BTW, since NuttX is very similar to Unix/Linux, it's very easy to start the porting from the Unix/Linux version. Actually, My colleague(Chao An) finished MicroPython initial NuttX
