RE: Touchscreen scaling/LVGL
There is nuttx/drivers/input of course - only just remembered; I'll see if anything "generic" fits there for this. >-Original Message- >From: TimH >Sent: Wednesday, May 24, 2023 12:04 PM >To: dev@nuttx.apache.org >Subject: RE: Touchscreen scaling/LVGL > >I'm thinking: > >1) that the LVGL Gregory linked to is a contender for the graphical >interface, only for LVGL of course, to do the calibration >2) The existing calibration routines in nuttx-apps (e.g. ccalibration for >NXWM as suggested by Alan C. Assis) is a great alternative for non-LVGL >implementations >3) Developers can write their own front end if preferred. > >All produce the necessary offsets and scale factors etc. > >In my case, the screen is only used by pudgy, often gloved, fingers so >absolute accuracy is not required; any variations between displays are >not an issue as there are large touch button areas that are difficult to >miss! > >That just leaves the question of where/how to calculate compensated x/y >co-ordinates that take the offsets into account. > >I see there is CONFIG_TSCALIBRATION used by platform_setconfig, currently >only used by mikroe boards that I can see, along with some structs (i.e. >sCalibrationData) but there is no "generic" TSD driver in nuttx/drivers. > >Perhaps that is something that one day might be a useful enhancement, as >it could then standardise the struct(s) etc. and provide "methods" along >the lines of efuse, power/supply, and so on. > >Ultimately, the offsets/scaling do need to be applied somewhere though, >and to me, IOCTL to the ADC driver feels right. In the case of the SAMA5 >a read via the character driver is what actually initiates a TSD sample, >so the overhead of calculating offsets seems acceptable, but other >processors/implementations could do this on a timer etc so it's not a >definitive approach. > >I will implement IOCTLs, using the sCalibrationData struct as the >argument and see how I get on. > >>From: Gregory Nutt >>Sent: Tuesday, May 23, 2023 7:51 PM >> >> >>On 5/23/2023 12:11 PM, Tim Hardisty wrote: >>> Hi, >>> >>> >>> A touchscreen peripheral (SAMA5D2 as it happens) delivers X and Y >>coordinates scaled 0-4095. >>> >>> LVGL wants them scaled to the actual size of the display (800x480 in >>> my >>case). >>> >>> 2) Enhance the chip's TSD driver after all, using a Kconfig setting >>> to >>enable X/Y scaling to the display's size (set in board-specific files >>already). >>> >> >>Many touchscreens require calibration by the application via a >>calibration screen. Hence, only the application knows the scale >>factors to use and so scaling is done by the application. >> >>Scaling could also be done by the driver using calibration information >>provided via an IOCTL. All resistive touchscreens require calibration. >>If your touchscreen does not require calibration, then I suppose it >>could even be provided by a configuration setting. >> >>Raw, unscaled input is also needed by the application, however (in >>order to do calibration, for one). >> >>Scaling in the driver could also be inefficient since the driver does >>not know if the sample will be used or not. It might be better to to >>scale in the application even if calibration is not necessary. >> >>A quick Google provides some references for touchscreen calibration >>with >>LVGL: >> >> * https://forum.lvgl.io/t/calibrate-a-touchscreen-with-tpcal-h/244 >> * https://github.com/jakpaul/lvgl_touch_calibration >> >>The are other calibration displays under nutts-apps/ (not for LVGL) >
RE: Touchscreen scaling/LVGL
I'm thinking: 1) that the LVGL Gregory linked to is a contender for the graphical interface, only for LVGL of course, to do the calibration 2) The existing calibration routines in nuttx-apps (e.g. ccalibration for NXWM as suggested by Alan C. Assis) is a great alternative for non-LVGL implementations 3) Developers can write their own front end if preferred. All produce the necessary offsets and scale factors etc. In my case, the screen is only used by pudgy, often gloved, fingers so absolute accuracy is not required; any variations between displays are not an issue as there are large touch button areas that are difficult to miss! That just leaves the question of where/how to calculate compensated x/y co-ordinates that take the offsets into account. I see there is CONFIG_TSCALIBRATION used by platform_setconfig, currently only used by mikroe boards that I can see, along with some structs (i.e. sCalibrationData) but there is no "generic" TSD driver in nuttx/drivers. Perhaps that is something that one day might be a useful enhancement, as it could then standardise the struct(s) etc. and provide "methods" along the lines of efuse, power/supply, and so on. Ultimately, the offsets/scaling do need to be applied somewhere though, and to me, IOCTL to the ADC driver feels right. In the case of the SAMA5 a read via the character driver is what actually initiates a TSD sample, so the overhead of calculating offsets seems acceptable, but other processors/implementations could do this on a timer etc so it's not a definitive approach. I will implement IOCTLs, using the sCalibrationData struct as the argument and see how I get on. >From: Gregory Nutt >Sent: Tuesday, May 23, 2023 7:51 PM > > >On 5/23/2023 12:11 PM, Tim Hardisty wrote: >> Hi, >> >> >> A touchscreen peripheral (SAMA5D2 as it happens) delivers X and Y >coordinates scaled 0-4095. >> >> LVGL wants them scaled to the actual size of the display (800x480 in my >case). >> >> 2) Enhance the chip's TSD driver after all, using a Kconfig setting to >enable X/Y scaling to the display's size (set in board-specific files >already). >> > >Many touchscreens require calibration by the application via a >calibration screen. Hence, only the application knows the scale factors >to use and so scaling is done by the application. > >Scaling could also be done by the driver using calibration information >provided via an IOCTL. All resistive touchscreens require calibration. >If your touchscreen does not require calibration, then I suppose it could >even be provided by a configuration setting. > >Raw, unscaled input is also needed by the application, however (in order >to do calibration, for one). > >Scaling in the driver could also be inefficient since the driver does not >know if the sample will be used or not. It might be better to to scale >in the application even if calibration is not necessary. > >A quick Google provides some references for touchscreen calibration with >LVGL: > > * https://forum.lvgl.io/t/calibrate-a-touchscreen-with-tpcal-h/244 > * https://github.com/jakpaul/lvgl_touch_calibration > >The are other calibration displays under nutts-apps/ (not for LVGL)
RE: Touchscreen scaling/LVGL
Yes, I like the idea of an IOCTL to do this. >-Original Message- >From: Maciej Wójcik >Sent: Tuesday, May 23, 2023 7:39 PM >To: dev@nuttx.apache.org >Subject: Re: Touchscreen scaling/LVGL > >Maybe additional IOCTL in touch display drivers, for example here >https://github.com/apache/nuttx/blob/master/drivers/input/ads7843e.c#L943 > >Two calls, one accepting calibration matrix, and another to remove it and >come back to raw readings. > >In typical Linux there is an `xinput` command to do it >https://wiki.archlinux.org/title/Calibrating_Touchscreen#Apply_the_Matrix >. > >Am Di., 23. Mai 2023 um 20:37 Uhr schrieb Alan C. Assis >: > >> The LVGL 7.x that was integrated on NuttX had a calibration before >> initialize the demo, I think it was from LVGL itself. >> >> There is also TS calibration that Greg created for TWM4NX: >> apps/graphics/twm4nx/apps/ccalibration.cxx >> >> BR, >> >> Alan >> >> On 5/23/23, Maciej Wójcik wrote: >> > It would be great if NuttX would offer calibration of touch screens >> > out >> of >> > the box. >> > >> > I am not sure where it should go, but I think it could be a wrapper >> > that >> is >> > used by many drivers. >> > >> > I think we have a similar situation with flash filesystems. There >> > are multiple layers that stack on each other. >> > >> > For example here there is `ftl_initialize` (flash translation layer) >> > and then `smart_initialize` (filesystem) >> > >> https://github.com/apache/nuttx/blob/master/boards/arm/stm32/stm32f103 >> -minimum/src/stm32_w25.c#L266 >> > >> > Regarding the calibration itself, you probably know how to implement >> > it, but otherwise you might find this useful >> > https://gitlab.com/nxtlabs/shared-libs/touch-calib-lib/-/wikis/home >> > (explanation and implementation) >> > >> > Coming back to your question, how do other people do it? For me it >> > was >> just >> > user-space code, part of the application. >> > >> > Am Di., 23. Mai 2023 um 20:12 Uhr schrieb Tim Hardisty >> > : >> > >> >> Hi, >> >> >> >> This is perhaps more a POSIX/general programming question than >> >> NuttX but you are all, so often, so very helpful :) >> >> >> >> A touchscreen peripheral (SAMA5D2 as it happens) delivers X and Y >> >> coordinates scaled 0-4095. >> >> >> >> LVGL wants them scaled to the actual size of the display (800x480 >> >> in my case). >> >> >> >> I'm not 100% sure that the chip’s TSD driver is the place to scale >it? >> >> >> >> The TSD driver creates a generic /dev/input0 character driver, >> >> which is what LVGL (set via Kconfig) opens. Scaling within the LVGL >> >> code isn’t right either, I don’t think? >> >> >> >> I can only think of either: >> >> >> >> 1) creating a new character driver that does a translation – >> >> registered as >> >> /dev/input1 (or whatever) that LVGL uses, and this driver reads >> >> input0 when required and returns translated values. >> >> >> >> 2) Enhance the chip's TSD driver after all, using a Kconfig setting >> >> to enable X/Y scaling to the display's size (set in board-specific >> >> files already). >> >> >> >> Both seem a little messy though so perhaps I’m missing something >> obvious? >> >> Can't be the first to need to do this? >> >> >> >> Thanks, >> >> >> >> TimH >> >> >> >> >> > >>
RE: SAMA5(D2) SPI speed is restricted by the driver
>From: Tomek CEDRO >Sent: Friday, April 28, 2023 5:15 PM > >On Thu, Apr 27, 2023 at 5:27 PM Tim Hardisty wrote: >> (..) >> I have been investigating poor MTD performance with a GD25 memory on >SPI0 of a SAMA5D27 processor. >> (..) >> I am very happy to work on the fix and a PR after some feedback. > >I do not have this board / mcu to help testnig, but I guess better >efficiency and new features are highly welcome :-) > >Tim if that helps I can buy selected board for testing, I do not have >time to help with development though, sorry. > >-- I have my custom board and an SAMA5D2 explained eval board so should be OK, thanks. I just want to make sure there's no "good" reason for this before messing it all up! Thanks for taking the time to reply :)
RE: Pass interrupt status to handler
In this case, it's not the low level interrupt handler. It's essentially the "callback" routine that's registered to the generic PIO irq handler. I think! I had hoped that the actually irq state (edge/level/whatever) existed in a struct/argument/whatever and I just hadn't spotted it. I should be able to use the usual poll_waiter stuff if I want to let users know via the UI - but the important thing, realistically, is to shut down USB Host power quickly! >-Original Message- >From: Gregory Nutt >Sent: 27 January 2023 18:47 >To: dev@nuttx.apache.org >Subject: Re: Pass interrupt status to handler > >Typically, if you want to pass a small amount of information from an >interrupt handler to a task, you would use a normal IPC like sigqueue() >(https://pubs.opengroup.org/onlinepubs/7908799/xsh/sigqueue.html) which >allows to send a type union sigval to the task. > >The task would have to catch the signal with something like >sigwaitinfo() >(https://pubs.opengroup.org/onlinepubs/7908799/xsh/sigwaitinfo.html). > >Originally, you could use mq_send() from interrupt handlers to send >interrupt status to tasks, but unfortunately that feature was lost with >some recent commits that redesigned the message handler that were >apparently done without knowledge of that requirement. NOTE that the >documentation is now wrong, it says that you can still messages from >interrupt handlers. That is not true. > >On 1/27/2023 12:15 PM, Nathan Hartman wrote: >> Is there a global structure where you retain state information where >> it would be appropriate to save the most refent known state in a >> volatile variable? >> >> On Fri, Jan 27, 2023 at 1:00 PM Tim Hardisty >wrote: >> >>> Think this is an easy one but it's stumped me so far... >>> >>> I am setting up the USB Overcurrent interrupt and can't find any >>> fully implemented examples. >>> >>> The interrupt is set to both edges as I want to know when the over >>> current state is first set and later hopefully cleared. >>> >>> I can obviously read the state of the input pin, but I sort of feel I >>> should be able to pass the state as an arg to the handler (via xcpt_t >>> handler). >>> >>> Is that possible and, if so, how? >>>
RE: [ANNOUNCE] Apache NuttX 12.0.0 released
I see that a build using upstream/master reports its version as 12.0.0, despite being over 400 commits ahead of the official release (of course). Is there an argument to have "master" report its version as "release+" or something like that, e.g. "V12.0.0+", like U-boot does I believe? Not actually sure where the version is retrieved from tbh! >-Original Message- >From: Alin Jerpelea > >The Apache NuttX project team is proud to announce Apache NuttX 12.0.0 has >been released. > >The release artifacts and Release Notes can be found >at:https://nuttx.apache.org/download/https://nuttx.apache.org/releases/12. >0.0/ > >Thanks, >Alin Jerpelea >on behalf of Apache NuttX PPMC
RE: Apologies
Thanks for the support - another 2 PRs submitted now. But one failed tests with multiple instances of: " Error: Error response from daemon: login attempt to https://ghcr.io/v2/ failed with status: 503 Service Unavailable" Do I need to do anything to get the tests to rerun and hopefully pass? >-Original Message- >From: Tim Hardisty >Sent: 25 November 2022 14:46 >To: dev@nuttx.apache.org >Subject: Apologies > >Some may have seen I've been attempting multiple times to submit PRs for 2 >issues (SAMA5D2 related) and have closed/cancelled/retried numerous >times. > >Bottom line - I am struggling with the whole rebase/squash/merge cycle...as >I'm a complete numpty. Code I can mostly do, but this is the first time working >with a public repo not just my with own private code where I can do whatever >I want ;) > >I will fully "get it", eventually, but have now, at long last, had my first actual >code PR accepted and merged. Thank you for your understanding and >patience! > >Regards, > >TimJTi >--- >PS I believe any email sent to the mail reflector that has been DKIM signed will >end up in recipients spam folder...hence sending this from a non-DKIM signed >email account to see what happens.
Apologies
Some may have seen I've been attempting multiple times to submit PRs for 2 issues (SAMA5D2 related) and have closed/cancelled/retried numerous times. Bottom line - I am struggling with the whole rebase/squash/merge cycle.as I'm a complete numpty. Code I can (mostly!) do, but this is the first time working with a public repo rather than just my own private code, where I can do whatever I want ;) I will fully "get it", eventually, but have now, at long last, had my first actual code PR accepted and merged. Thank you for your understanding and patience! Regards, Tim
SAMA5D2 Flexcom SPI
A year or 2 ago I added flexcom SPI support to the SAMA5D2 but was not confident enough to submit it via PR, and then had to put the project down for a while anyway. I'm back at it now, but I see that since then the underlying support for the main SPI has been changed a little to use, for example, mutex locks rather than semaphores, which is a good thing. Originally, I believe I copied the relevant sam_spi.c file to sam_flexcom_spi.c and changed all the function names to include "flexcom", as well as amending it to correctly sift through the 5 possible flexcom ports to set it all up right, etc. Plus fleshing out hardware/sam_flexcom_spi.h with the missing register definitions etc. Looking at it now, with a bit more experience, and despite the NuttX mantra that code duplication is OK, I am thinking that the core operations are so similar that it would be perhaps neater to enhance sam_spi.c to include the flexcom stuff. What do people think? I need to rework what I've done anyway, so it might as well be done in what's perceived as the "best" way :-)
RE: New names of repositories
+1 >-Original Message- >From: Nathan Hartman >Sent: 22 November 2022 13:30 >To: dev@nuttx.apache.org >Subject: Re: New names of repositories > >After hearing back from Infra about the repository naming convention, all the >recent feedback has been to stay with the default and just remove >"incubator-" from our repo names, giving: > >https://github.com/apache/nuttx >https://github.com/apache/nuttx-apps > >Shall I go ahead and open the Jira ticket to do that? > >Cheers, >Nathan
RE: New names of repositories
+1 :) >-Original Message- > >nuttx and nuttxapps >
RE: New names of repositories
I see all the other two-word Apache repositories use hyphens not underscores, and on GitHub they are URLs which as has been pointed out should ideally be hyphenated? To me the underscore looks wrong...but, in the grand scheme of things, it's just a name and, like Sebastien, I will not lose sleep. I lose enough of that already, getting trying to get NuttX working on the processor I'm using LOL. >-Original Message- >From: Sebastien Lorquet > >Hi, > >I would also very much prefer nuttx and nuttx_apps but the other option will >not prevent me from sleeping well at night. > >Sebastien > >Le 18/11/2022 à 15:46, Gregory Nutt a écrit : >> >>> But NuttX has more features than traditional RTOS(e.g. FreeRTOS). >>> Actually, >>> Xiaomi uses it in the IoT space which has less real time requirements. >>> Other similar OS(e.g. Zephyr) doesn't append rtos suffix. >>> So, I prefer keep nuttx and nuttx-apps. >> >> I just endorsed nuttx_rtos and nuttx_apps, but Xiao is correct. >> nuttx_rtos is redundant since nuttx is the name of the RTOS. >> nuttx_apps are miscellaneous applications tailored for the NuttX RTOS. >> It really is semantically cleaner. >>
write-only interrupt registers
In the midst (still!) of sorting out the SAMA5D2 TSD and ADC support. It is pretty much all working now, with quite a few errors addressed along the way. Guess I'm the only one actually using this processor for real LOL. The last thing I am addressing is a conflict between the interrupts used for the TSD and ADC as it transpires that this processor family's interrupt enable, disable and mask registers are write-only for some odd reason. This means the drivers can't, for example, read the current interrupt enable registers that have perhaps been set up for ADC operation and OR in those needed for TSD operation. The TSD driver especially does some clever "tricks" with changing the pen detect and X/Y/Pressure interrupts depending on a state machine, and I don't want to unravel all of that for no good reason. Only thing I can think of is to add a new member to the relevant SAM_ADC_S struct and have the ADC and TSD drivers save the current state. Seems messy to me - so does anyone have any better ideas that have already been used, in NuttX, in similar circumstances?
Re: Bluetooth+WiFi+NuttX
I meant esp32 not esr32. The naming is too similar lol > On 29 Oct 2022, at 15:51, Tim Hardisty wrote: > > Thanks Alan! SAMA5D2 has RMII so definitely a possibility. EFR32 is a much > better value device compared to SiLabs Bluetooth 5 module currently used, and > has WiFi as a bonus - so I will investigate it's IDE and see how easy it is > to implement a GATT-based solution, or to load HCI firmware so I can be > reasonably confident I'm not digging a big hole for myself if I make this > change. > > > On 29/10/2022, 13:23, "Alan C. Assis" wrote: > >More info here: > > > https://e2e.ti.com/support/processors-group/processors/f/processors-forum/366759/am335x-rmii-direct-connection-between-two-devices > >Same TI guy who said it was impossible latter talk internally and >discovered that there was a customer already using it. > >BTW, you will need to have RMII supported by both MCUs (yes, ESP32 has > RMII). > >BR, > >Alan > >>On 10/29/22, Alan C. Assis wrote: >> Hi Tim, >> >> I just searched if it was possible to connect two Ethernet MAC >> directly without using PHY and it is possible, so it will not involve >> cost for you: >> >> https://stackoverflow.com/questions/39503466/can-two-ethernet-mac-chips-be-connected-directly-without-going-thru-phy >> >> BR, >> >> Alan >> >>> On 10/29/22, Tim Hardisty wrote: >>> Thanks for your clarifications Alan - I have messaged Espressif (your >>> reply >>> ended up in SPAM otherwise I might not have needed to) so I guess I'll get >>> a >>> similar answer. >>> >>> There is HCI (RCP) firmware for the SiLabs module so I can try that - >>> it's >>> the £7 per module saving of Espressif vs. SiLabs, plus getting WiFi for >>> free >>> that appeals. SAMA5D2 has Ethernet - unused on my board so it is not an >>> idea >>> that is completely out of the question: writing USRSOCK for the >>> Espressif >>> module is probably beyond me at this time! >>> >>> On 29/10/2022, 00:20, "Alan C. Assis" wrote: >>> >>>Hi Tim, >>> >>>On 10/28/22, Tim Hardisty wrote: Bit of a tangential question this, but I know there are folk on >>> here >>> who are much more conversant with the way NuttX can be used with WiFi >>> and Bluetooth modules than I am. >>> >>>I think these are important questions and other people could face >>>similar issues in the future. >>> I may have an opportunity forced on me to have to respin my custom >>> board which currently has a SiLabs Bluetooth SoC as well as the main >>> SAMA5D2 processor. I used that module as I already have experience of it - >>> but >>> that predates my NuttX journey. I see there are some very good value combined WiFi + Bluetooth >>> modules >>> now (Espressif for example...and I know there's a well-known proponent >>> of >>> those devices here lol) and, having seen a few other questions here, I am >>> thinking that I can go the HCI route and make use of the Bluetooth Stack in >>> NuttX: and add WiFi capability to my board at the same time. Winner! >>> >>>First let me explain the differences: >>> >>>Espressif modules are not used as external modules on NuttX, >>>everything is integrated inside the chip. >>> >>>During the WildernessLab's presentation on NuttX Workshop their team >>>shown an ESP32 solution sharing WiFi as an external module. >>>But they didn't use the default USRSOCK route, they implemented a new >>>solution at home. >>> I'm hoping I can program up a suitable module with generic radio co-processor software (HCI I think, and whatever is needed for >>> WiFi) >>> and access it via UART from my main processor and have it all under the >>> NuttX system in a much more easily managed manner than a separate app on >>> the SiLabs SoC that just happens to communicate on some way with my >>> main >>> app on the SAMA5D2. Have I got this right? Is an Espressif module a good choice (email >>> me >>> direct if you want to !!)? >>> >>>For Bluetooth (BLE) if there is a HCI firmware to SiLabs chip, then >>> it >>>could be possible to you use it, but you'll need to do some tests and >>>debugging to get things working. >>> >>>For WiFi things are more complex because you need to implement a >>>USRSOCK yourself to the chip. >>> >>>I never tested others possibilities: i.e. share Internet using SLIP >>>between ESP32 and SAMA5D2, should be an easier route if it works, but >>>of course you wil be limited to UART speed. >>> >>>Ethernet could be a better option (since ESP32 has Ethernet >>> hardware), >>>but it seems like an ugly and expensive workaround. >>> >>>BR, >>> >>>Alan >>> >>> >>> >> > >
RE: Is SmartFS limited to 16M memories
I had similar problems trying smart FS with a large device. It was over a year
ago, and I put it on the back burner at the time, but I am sure there was
something that exceeded the max value of a 16 bit integer somewhere and it went
wrong. To me it seemed like it wasn't suited to large devices "out of the box"
and needed some work.
I would be delighted if this is sorted; otherwise I'll be looking at again
sometime in the next few months.
>-Original Message-
>From: Daniel Pereira Carvalho
>Sent: 20 October 2022 13:16
>To: dev@nuttx.apache.org
>Subject: Re: Is SmartFS limited to 16M memories
>
>Hi Ken,
>
>First of all, thanks for your quick response.
>
>One of the first things I tried was to change the values of
>MTD_SMART_SECTOR_SIZE [=2048] and MTD_SMART_SECTOR_CACHE_SIZE
>[=2048] but the smartfs_mount() is still failing to validate the low-level
>format.
>For reference the struct fs->fs_llformat has the following values just before
>the error
>
>fs->fs_llformat.sectorsize:2048
>fs->fs_llformat.availbytes:2043
>fs->fs_llformat.nsectors:16384
>fs->fs_llformat.nfreesectors:16378
>fs->fs_llformat.flags:0 '\000'
>fs->fs_llformat.namesize:16 '\020'
>
>Changing the capacity to W25_JEDEC_CAPACITY_128MBIT and keeping
>MTD_SMART_SECTOR_SIZE and MTD_SMART_SECTOR_CACHE_SIZE the same
>[2048] the file system works as expected. For reference the struct fs-
>>fs_llformat has the following values just before the function validates the
>low level format.
>
>fs->fs_llformat.sectorsize:2048
>fs->fs_llformat.availbytes:2043
>fs->fs_llformat.nsectors:8192
>fs->fs_llformat.nfreesectors:8183
>fs->fs_llformat.flags:1 '\001'
>fs->fs_llformat.namesize:16 '\020'
>
>Thanks
>
>Daniel Pereira de Carvalho
>
>Em qua., 19 de out. de 2022 às 21:26, Ken Pettit
>escreveu:
>
>> Hi Daniel,
>>
>> The SmartFS FS *can* work with devices greater than 16M Bytes. I have
>> used it with a 256MBit / 32M Byte SPI flash before quite successfully.
>>
>> But you have to ensure the logical sector size is large enough. One
>> limitation of the SMART MTD (and therefore SMART FS) implementation is
>> that it uses unsigned 16-bit integers for logical sector numbers.
>> This means you can only have 65536 maximum logical sectors (actually a
>> few less than that, but the code knows how to deal with 65536 values
>> and simply "waste" a few reserved values like zero and 0x).
>>
>> This means that for a 32M byte flash, you would need to ensure the
>> logical sector size is at least 32M / 65536 = 512 bytes. Typically
>> for the SMART MTD layer, a logical sector size of 1024 or 2048 (or
>> larger) is preferred because the code can manage erase blocks / free
>> sector collection management better.
>>
>> In your 'make menuconfig', check your SMART logical sector size and try
>> setting it to 2048. For the W25256JEVIEQ part with 256-byte pages,
>> this will be 8 pages per logical sector, which is a good setting. Of
>> course this also means that the smallest file size is 2K bytes, even
>> if the file only has 1 byte stored in it. That's the price you pay
>> for a structured file system though.
>>
>> Ken
>>
>>
>> On 10/19/22 4:39 PM, Daniel Pereira Carvalho wrote:
>> > Hi guys,
>> >
>> > I am trying to use the memory W25Q256JVEIQ, with SMARTS FS. To do it
>> > I added the support for this memory in "drivers/mtd/w25.c". I just
>> > added
>> the
>> > code below
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > *..#define W25_JEDEC_CAPACITY_256MBIT 0x19 /* 8192x4096 = 256Mbit
>> > memory capacity */../* 256M-bit / 32M-byte (33,554,432) * *
>> > W25Q256JV (Standard
>> > SPI) */else if (capacity == W25_JEDEC_CAPACITY_256MBIT) {
>> > priv->nsectors = NSECTORS_256MBIT; }..*
>> >
>> > The memory initialization seems to go well. I can run the mksmartfs
>> > utility, mount and write to the filesystem. However when I reboot
>> > the
>> board
>> > I can't mount the filesystem again. The function smartfs_mount()
>> > returns the error "ERROR: No low-level format found".
>> >
>> > The documentation says that SMARTS FS is designed to work with 1M
>> > byte to 16M byte in size (though this is not a limitation). So I
>> > changed the
>> > priv->nsectors from NSECTORS_256MBIT to NSECTORS_128MBIT to see if
>> > priv->the
>> > problem was with the size of the memory. After this change the file
>> system
>> > started to work as expected.
>> >
>> > Should SMARTS FS work with memories larger than 16M, since in the
>> > docs it is said that this is not a limitation? If SMART FS is
>> > limited to memories smaller than 16M do you recommend another
>filesystem?
>> >
>> > Thanks
>> >
>> > Daniel Pereira de Carvalho
>> >
>>
>>
RE: [apache/incubator-nuttx] tools/configure.sh: Update USAGE for custom out-of-tree boards (PR #7103)
Short term, I've cloned apache:master afresh, copied my new files to that, then committed it to a new branch in my own fork. No idea if that's the right thing to have done, but the PR is now live, at least! >-Original Message- >From: TimH >Sent: 12 October 2022 16:00 >To: dev@nuttx.apache.org >Subject: RE: [apache/incubator-nuttx] tools/configure.sh: Update USAGE for >custom out-of-tree boards (PR #7103) > >I have created 2 rst files to document out-of-tree custom boards, and also >how to manage custom apps both in and out of tree, and would like to submit >a PR. > >This will be the first time I have submitted a PR, and I'm fairly new to using >GIT >and I'm struggling to understand the (documented) workflow as I just can't >relate to it. > >Here is the history of my interactions with the repositories. > >1) I originally created a fork of the main incubator-nuttx repo, sometime back >in 2021, from the 10.1 release branch. >2) I have created various branches along the way and committed my changes >to my own forked repo >3) My current branch includes a merge of 11.0 RC2 >4) My "master" is 5000+ commits behind apache:master, not surprisingly >5) My current active branch is around 500 commits behind apache:master >6) I have not pulled/merged my own branch to my "master" as github says it >can't do an automatic merge. >5) I can't do a PR back to apache:master from my active branch because, um, it >confuses me! > >Can a Nuttx/GIT old-hand offer some guidance on how I get out of this >seeming muddle so I can get myself in a position to submit PRs? I have other >code I would like to contribute so have to get this sorted, but, equally, don't >want to mess up my ongoing development work by having to pulling in >"random" current patches from apache:master that might break what I'm >doing (i.e. I want to be in control of what master branch/release my work is >based on). > >Hope that makes sense?
RE: [apache/incubator-nuttx] tools/configure.sh: Update USAGE for custom out-of-tree boards (PR #7103)
I have created 2 rst files to document out-of-tree custom boards, and also how to manage custom apps both in and out of tree, and would like to submit a PR. This will be the first time I have submitted a PR, and I'm fairly new to using GIT and I'm struggling to understand the (documented) workflow as I just can't relate to it. Here is the history of my interactions with the repositories. 1) I originally created a fork of the main incubator-nuttx repo, sometime back in 2021, from the 10.1 release branch. 2) I have created various branches along the way and committed my changes to my own forked repo 3) My current branch includes a merge of 11.0 RC2 4) My "master" is 5000+ commits behind apache:master, not surprisingly 5) My current active branch is around 500 commits behind apache:master 6) I have not pulled/merged my own branch to my "master" as github says it can't do an automatic merge. 5) I can't do a PR back to apache:master from my active branch because, um, it confuses me! Can a Nuttx/GIT old-hand offer some guidance on how I get out of this seeming muddle so I can get myself in a position to submit PRs? I have other code I would like to contribute so have to get this sorted, but, equally, don't want to mess up my ongoing development work by having to pulling in "random" current patches from apache:master that might break what I'm doing (i.e. I want to be in control of what master branch/release my work is based on). Hope that makes sense?
Re: [apache/incubator-nuttx] tools/configure.sh: Update USAGE for custom out-of-tree boards (PR #7103)
Hmmm…no, I’ll rummage around to find out how to do that as it sounds like what I’m looking for, thanks. > On 11 Oct 2022, at 19:27, Abdelatif Guettouche > wrote: > > Did you check the "external" directory or are you looking for something > else? > > Basically the external directory allows you to symlink an out of tree > repository (or repositories) that should contain, at least, the minimal > build glues (Makefile and Make.defs). The build system should pick up the > rest. > The external directory is ignored from the tracking system so nothing > impacts the actual apps repo. > >> On Tue, Oct 11, 2022 at 8:07 PM Tim Hardisty >> wrote: >> >> I have walked through the custom apps guide from the cwiki and find that >> it is explaining how to replace the ENTIRE Nuttx Apps directory with a >> custom alternative. >> >> That seems to me to be perhaps of minority interest but I'll include it in >> the documentation I'm writing anyway for completeness. >> >> But is there a way to add a custom folder - in or out of tree - that will >> be included along with the built-in apps and examples? This would allow you >> to include custom appss, and the built-in ones, but not have a problem when >> merging future releases that might cause the building in of the custom apps >> to fail? >> >> Perhaps I'm over thinking it? >> >> On 07/10/2022, 17:25, "TimH" wrote: >> >>Got it - thanks Nathan. I will probably plunder some text from the >> cwiki then, and not feel guilty :-) >> >>> -Original Message- >>> From: Nathan Hartman >>> Sent: 07 October 2022 17:23 >>> To: dev@nuttx.apache.org >>> Subject: Re: [apache/incubator-nuttx] tools/configure.sh: Update >> USAGE for >>> custom out-of-tree boards (PR #7103) >>> >>> On Fri, Oct 7, 2022 at 11:59 AM TimH wrote: >>>> >>>> As per request below, I’m happy to add a paragraph or two regarding >> this, >>> but I am not sure where it should go? >>>> >>>> It could be a section in “guides” or I could add it to the FAQ. >> What is >>> preferred, assuming the Documentation folder in the repo is actually >> the right >>> place for this of course? >>> >>> I think it would best fit in guides under the Documentation folder in >> the repo, >>> and I think that's where all "official" documentation should >> ultimately be. >>> >>>> Related to this, what is the significance of the cwiki >>> (https://cwiki.apache.org/confluence/display/NUTTX) as that has a >> lot more >>> information in it compared to the Nuttx distro’s Documentation >> folder, but is >>> outdated and perhaps not maintained I think? The cwiki has >> information on >>> custom app directory usage that could either be a source of info for >> a more >>> complete “custom environment” guide or is the actually the intended >> place >>> for the custom boards info I’ve been asked to add? >>> >>> From my memory, before NuttX joined the Apache.org Incubator, what's >> now >>> in the CWIKI was in a MediaWiki on the NuttX website. When we joined >> the >>> Incubator, this was somehow migrated to the Apache.org CWIKI. Some (or >>> most?) of it was then migrated again into what is now the >> Documentation >>> folder in the repo. However, there are some differences between the >> two >>> because new documentation has been written under Documentation while >>> some of the docs available in the CWIKI may not have been migrated, >> and I >>> think there are still articles in the CWIKI that have not made it into >>> Documentation. >>> >>> As to what's the purpose of the CWIKI: Some time ago, I asked whether >> we >>> should keep the CWIKI around. Now I can't seem to locate that email >> after a >>> quick search, but as I remember, a few people said they would like to >> keep >>> the CWIKI as a place to collaborate on documentation, as it makes >> real-time >>> collaborative writing easier (without the added friction of making >> PRs) and >>> then migrate finished documents into Documentation. >>> >>> In short, there's some work yet to be done on documentation and it >> isn't a >>> secret that we, like probably most community-driven projects, need >> lots of >>> help improving our documentation!!! >>> >>> Hope that helps. I'd like to say a sincere THANK YOU for any >> improvements >>> you're willing to make, large or small! >>> >>> Cheers, >>> Nathan >> >> >> >>
RE: [RESULT] Release Apache NuttX (Incubating) 11.0.0 [RC2]
>From: TimH >Sent: 07 October 2022 17:45 >To: dev@nuttx.apache.org >Subject: RE: [RESULT] Release Apache NuttX (Incubating) 11.0.0 [RC2] > >>-Original Message- >>From: Nathan Hartman >>Sent: 07 October 2022 17:28 >> >>On Fri, Oct 7, 2022 at 11:10 AM TimH wrote: >>> >>> Would you still like another non-binding +1 vote? >>> >>> I just merged 11.0.0 [RC2] into my 10.3 endeavours with my custom >>> board >>and have successfully built and run a Nuttx shell (after a few changes >>to my custom make.defs). >> >>This vote (in the NuttX PPMC, i.e., dev@nuttx.apache.org) passed, but >>since we're an incubating project (until we graduate), we need a second >>round of voting in the Apache.org IPMC (i.e., >>gene...@incubator.apache.org)... That vote has not closed yet and, yes, >>we would like all the attention we could get on it!! >> >>Let me find that vote thread >> >>Here it is: >>https://lists.apache.org/thread/0h6wq2cqk3ckdttz78964fw4007b51lr >> >>Let us know if you need anything! >> >I'm assuming I have to have subscribed to that mailing list to vote so I just >have, but it is not clear from the welcome email received how to actually get >the relevant mail from Alin downloaded so I can reply? Looks like I need a >message ID to get it, but can't see message IDS anywhere? Assuming that is >the way to do this? OK - found the ID by looking at the raw email on the lists.apache.org webpage...requested it by email...answer received with Alin's email attached but the actual body text is completely missing. But replied anyway, pasting a small snip of text to give it context!
RE: [RESULT] Release Apache NuttX (Incubating) 11.0.0 [RC2]
>-Original Message- >From: Nathan Hartman >Sent: 07 October 2022 17:28 > >On Fri, Oct 7, 2022 at 11:10 AM TimH wrote: >> >> Would you still like another non-binding +1 vote? >> >> I just merged 11.0.0 [RC2] into my 10.3 endeavours with my custom board >and have successfully built and run a Nuttx shell (after a few changes to my >custom make.defs). > >This vote (in the NuttX PPMC, i.e., dev@nuttx.apache.org) passed, but since >we're an incubating project (until we graduate), we need a second round of >voting in the Apache.org IPMC (i.e., gene...@incubator.apache.org)... That >vote has not closed yet and, yes, we would like all the attention we could get >on it!! > >Let me find that vote thread > >Here it is: >https://lists.apache.org/thread/0h6wq2cqk3ckdttz78964fw4007b51lr > >Let us know if you need anything! > I'm assuming I have to have subscribed to that mailing list to vote so I just have, but it is not clear from the welcome email received how to actually get the relevant mail from Alin downloaded so I can reply? Looks like I need a message ID to get it, but can't see message IDS anywhere? Assuming that is the way to do this?
RE: [apache/incubator-nuttx] tools/configure.sh: Update USAGE for custom out-of-tree boards (PR #7103)
Got it - thanks Nathan. I will probably plunder some text from the cwiki then, and not feel guilty :-) >-Original Message- >From: Nathan Hartman >Sent: 07 October 2022 17:23 >To: dev@nuttx.apache.org >Subject: Re: [apache/incubator-nuttx] tools/configure.sh: Update USAGE for >custom out-of-tree boards (PR #7103) > >On Fri, Oct 7, 2022 at 11:59 AM TimH wrote: >> >> As per request below, I’m happy to add a paragraph or two regarding this, >but I am not sure where it should go? >> >> It could be a section in “guides” or I could add it to the FAQ. What is >preferred, assuming the Documentation folder in the repo is actually the right >place for this of course? > >I think it would best fit in guides under the Documentation folder in the repo, >and I think that's where all "official" documentation should ultimately be. > >> Related to this, what is the significance of the cwiki >(https://cwiki.apache.org/confluence/display/NUTTX) as that has a lot more >information in it compared to the Nuttx distro’s Documentation folder, but is >outdated and perhaps not maintained I think? The cwiki has information on >custom app directory usage that could either be a source of info for a more >complete “custom environment” guide or is the actually the intended place >for the custom boards info I’ve been asked to add? > >From my memory, before NuttX joined the Apache.org Incubator, what's now >in the CWIKI was in a MediaWiki on the NuttX website. When we joined the >Incubator, this was somehow migrated to the Apache.org CWIKI. Some (or >most?) of it was then migrated again into what is now the Documentation >folder in the repo. However, there are some differences between the two >because new documentation has been written under Documentation while >some of the docs available in the CWIKI may not have been migrated, and I >think there are still articles in the CWIKI that have not made it into >Documentation. > >As to what's the purpose of the CWIKI: Some time ago, I asked whether we >should keep the CWIKI around. Now I can't seem to locate that email after a >quick search, but as I remember, a few people said they would like to keep >the CWIKI as a place to collaborate on documentation, as it makes real-time >collaborative writing easier (without the added friction of making PRs) and >then migrate finished documents into Documentation. > >In short, there's some work yet to be done on documentation and it isn't a >secret that we, like probably most community-driven projects, need lots of >help improving our documentation!!! > >Hope that helps. I'd like to say a sincere THANK YOU for any improvements >you're willing to make, large or small! > >Cheers, >Nathan
[apache/incubator-nuttx] tools/configure.sh: Update USAGE for custom out-of-tree boards (PR #7103)
As per request below, I’m happy to add a paragraph or two regarding this, but I am not sure where it should go? It could be a section in “guides” or I could add it to the FAQ. What is preferred, assuming the Documentation folder in the repo is actually the right place for this of course? Related to this, what is the significance of the cwiki (https://cwiki.apache.org/confluence/display/NUTTX) as that has a lot more information in it compared to the Nuttx distro’s Documentation folder, but is outdated and perhaps not maintained I think? The cwiki has information on custom app directory usage that could either be a source of info for a more complete “custom environment” guide or is the actually the intended place for the custom boards info I’ve been asked to add? TIA, TimH From: hartmannathan Sent: 22 September 2022 15:00 @TimJTi <https://github.com/TimJTi> : Bear in mind that a distclean will wipe .config so any settings of paths etc. there become irrelevant…that’s what “did me in”! I don't think we have good documentation on how to do custom-out-of-tree boards. Since you're working with an out-of-tree board, would you be willing to write something helpful for including in Documentation? It wouldn't have to be super long and detailed, just how to invoke the configure.sh script, which Kconfig options to set, and gotchas to avoid like distclean wiping the .config! — Reply to this email directly, view it on GitHub <https://github.com/apache/incubator-nuttx/pull/7103#issuecomment-1255066777> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANQZJKNGKLF5PVP4I7SQESTV7RQ45ANCNFSM6AAQNUBOU4> . You are receiving this because you were mentioned. <https://github.com/notifications/beacon/ANQZJKI4BDY4LRTNDNARIJDV7RQ45A5CNFSM6AAQNUBOU6WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSKZ3GJS.gif> Message ID: mailto:apache/incubator-nuttx/pull/7103/c1255066...@github.com> >
RE: [RESULT] Release Apache NuttX (Incubating) 11.0.0 [RC2]
Would you still like another non-binding +1 vote? I just merged 11.0.0 [RC2] into my 10.3 endeavours with my custom board and have successfully built and run a Nuttx shell (after a few changes to my custom make.defs). >-Original Message- >From: Alin Jerpelea >Sent: 22 September 2022 13:20 >To: dev@nuttx.apache.org >Subject: [RESULT] Release Apache NuttX (Incubating) 11.0.0 [RC2] > >Hi, > >The vote closes now as over 72hr have passed. The vote PASSES with 3 >(+3 non-binding) votes from the PPMC, >0 (+1 binding) vote from the IPMC, >3 (+0 non-binding) votes from the developer community, No further +1, 0 or - >1 votes. > >The vote thread: >[1]https://lists.apache.org/thread/rv9pf8gtbcq4zjnydv2h2lsymszzb33f > >I will now bring the vote to gene...@incubator.apache.org to get approval by >the IPMC. >If this vote passes also, the release is accepted and will be published. > >Thanks, >Alin Jerpelea
RE: 11.0.0 - released?
Thanks Alin - I'll wait then :) >From: alin.jerpe...@sony.com >Sent: 07 October 2022 14:51 > >Hi Tim >We are waiting for the IPMC vote so that we can release RC2 as final Best >regards Alin > > >From: TimH >Sent: den 7 oktober 2022 15:48 >Have been waiting for 11.0.0 to be released so I can merge into my 10.3 >efforts. I see 11.0 is on GitHub under releases, but when I start the merge, >files appear to be tagged with nuttx-11.0.0-RC2. I also don't recall seeing an >email here about the release. > > > >Before I continue, can someone confirm that the 11.0 release on GitHub is the >pukka release, please?
11.0.0 - released?
Have been waiting for 11.0.0 to be released so I can merge into my 10.3 efforts. I see 11.0 is on GitHub under releases, but when I start the merge, files appear to be tagged with nuttx-11.0.0-RC2. I also don't recall seeing an email here about the release. Before I continue, can someone confirm that the 11.0 release on GitHub is the pukka release, please?
Re: New UNUSED macro not working
I would think that your variable (a) does not meet the requirement of the & operator (The operand of the address-of operator can be either a function designator or an l-value that designates an object that is not a bit field and is not declared with the register storage-class specifier.) If so the fix that was pushed is not a full and final fix, although it extends - but also changes - the scope of the macro. Regards, Tim. > On 27 Sep 2022, at 18:19, Jernej Turnsek wrote: > > Hi Alan, > > I understand that it should support more variables, but the fact is that > the code, which used to compile, doesn't anymore. > > Maybe others will have the same problem, when porting from Linux to NuttX? > > Jernej > >> On Tue, Sep 27, 2022 at 2:55 PM Alan C. Assis wrote: >> >> Hi Jernej, >> >> There is a discussion about it here: >> >> https://github.com/apache/incubator-nuttx/pull/6779 >> >> The issue with previous implementation was it only worked for integers >> variable. >> >> BR, >> >> Alan >> >>> On 9/27/22, Jernej Turnsek wrote: >>> Hi, >>> >>> when compiling LuaJIT on NuttX with new UNUSED macro I get following >> error: >>> >>> LuaJIT/src/lj_frame.h:70:61: error: lvalue required as unary '&' operand >>> 70 | #define setframe_gc(f, p, tp) (setgcref((f)->fr.func, (p)), >>> UNUSED(tp)) >>> >>> What was the reason to change UNUSED macro from: >>> >>> # define UNUSED(a) ((void)(1 || (a))) >>> >>> to >>> >>> # define UNUSED(a) ((void)(1 || &(a))) >>> >>> Thanks, >>> Jernej >>> >>
Re: SAMA5D3 and D4 DMA
I have reworked the DMA for ATSAMA5D2 but not tested it yet. I will compare to yours and hopefully spot any differences or errors, thank you! Regards, Tim. > On 19 Sep 2022, at 17:18, NXWorld Lee wrote: > > Hi Tim, > SAMA5D2 has 2 XDMA controllers and the definition of peripherals channel is > also different with SAMA5D3 and SAMA5D4. > I will raise a pull request of adding SAMA5D2 XDMA definition to NuttX. > But I didn't test the XDMA driver on any SAMA5Dx platform. > > I run NuttX on SAMA5D3 and SAMA5D2, the maxtouch driver and LCD driver were > OK. > Here is a blog introducing running NuttX graphics on SAMA5D3 Xplained with > LCD display driver. > https://blog.csdn.net/oldman147/article/details/73410473?spm=1001.2014.3001.5502 > > > Best Rds > >> On Mon, Sep 12, 2022 at 10:45 PM TimH wrote: >> >> Thanks Greg - I'm sure someone would have tripped over all of this if >> they'd tried to get DMA working. I will at the very least get it tested as >> best as I can on SAMA5D2 - which it definitely seems I am the only actual >> user of with NuttX! Lucky me lol. >> >>> -Original Message- >>> From: Gregory Nutt >>> >>> I did the D3 and D4 ports years ago and I am not aware of any other use >> of >>> those boards. DMA was partially functional then, but was not well tested >> and >>> was still buggy. There were problems documented in >>> https://github.com/apache/incubator- >>> nuttx/blob/master/boards/arm/sama5/sama5d4-ek/README.txt >>> which look like the same issues with the SAMA5D3x-EK in >>> https://github.com/apache/incubator- >>> nuttx/blob/master/boards/arm/sama5/sama5d3x-ek/README.txt >>> >>> The D2 was more an effort of several people and was based initially on the >>> D4 (which was based on the D3). >>> >>>> On Mon, Sep 12, 2022 at 8:30 AM TimH wrote: >>> >>>> Aargh...too quick to retract. I think definitions for ATSAMA5D3 and >>>> ATSAMA5D4 are swapped and there *may* be inconsistencies, based on a >>>> comparison to datasheets. I don't think anyone has used it as I am 99% >>>> sure it wouldn't have worked as best as I can tell. File with issues is: >>>> >>>> arch/arm/src/sama5/sam_dmac.h >>>> >>>> It was the right file I was looking at, got confused by the presence >>>> of sam_xdmac.h as well as sam_dmac.h. >>>> >>>> I will had "# warning" for ATSAMA5D3 and ATSAMA5D4, and add a new >>>> section for SAMA5D2 which at least I hope to be able to check and >>>> confirm as working. >>>> >>>>> -Original Message- >>>>> From: TimH >>>>> Sent: 12 September 2022 14:54 >>>>> To: dev@nuttx.apache.org >>>>> Subject: RE: SAMA5D3 and D4 DMA >>>>> >>>>> Scrap that for now - was looking in the dma not xdma files >>>>> >>>>>> -Original Message- >>>>>> From: TimH >>>>>> Sent: 12 September 2022 14:14 >>>>>> To: dev@nuttx.apache.org >>>>>> Subject: SAMA5D3 and D4 DMA >>>>>> >>>>>> I am reworking DMA to get it working for the SAMA5D2. It seems to me >>>>>> that there are also errors and inconsistencies in the DMA code for >>>>>> the >>>>>> SAMA5D3 and D4 family. >>>>>> >>>>>> >>>>>> >>>>>> For now I have added "# warning" pre-processor statements. I have no >>>>>> means to check ATSAMA3 or ATSAMA4 devices - so unless someone can >>>>>> confirm that DMA does actually work for those 3 families and I've >>>>>> misunderstood something I will suggest that the warnings remain in >>>>>> place when I >>>>> eventually >>>>>> submit a PR for my work. >>>>> >>>> >>>> >>>> >> >>
Re: Subject: [VOTE] Apache NuttX 11.0.0 (incubating) RC2 release
FYI I will start to get involved with release testing but I have too many in-progress new drivers, and fixes to 10.3 , for my board and arch for it to be viable at this time. And I’m on holiday Regards, Tim. > On 19 Sep 2022, at 10:53, alin.jerpe...@sony.com wrote: > > Please test this release > We need some more votes to be able to create the release > > Best regards > Alin Jerpelea > > > -Original Message- > From: Xiang Xiao > Sent: den 14 september 2022 19:53 > To: dev@nuttx.apache.org > Subject: Re: Subject: [VOTE] Apache NuttX 11.0.0 (incubating) RC2 release > > +1 with tools/checkelease.sh: > ./tools/checkrelease.sh --release 11.0.0-RC2 Downloading release files from > https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/incubator/nuttx/11.0.0-RC2/__;!!JmoZiZGBv3RvKRSx!_AM2wqhyvJXbdzPcQZFOXYpkBNNnZwGoKQnKS8BvvYvbskS3DKRb8iVUnDSCivUymvfOiZxGdtm_vcSa2jG3KyhsDOg$ > gpg: directory '/tmp/nuttx-checkrelease/.gnupg' created > gpg: keybox '/tmp/nuttx-checkrelease/.gnupg/pubring.kbx' created > gpg: /tmp/nuttx-checkrelease/.gnupg/trustdb.gpg: trustdb created > gpg: key E1B6E30DB05D6280: public key "Brennan Ashton " > imported > gpg: key 2B8C7F0EAB22000E: public key "Abdelatif Guettouche (CODE SIGNING > KEY) " imported > gpg: key 4137A71698C5E4DB: public key "Alin Jerpelea " > imported > gpg: key 9E711BAD3264C061: public key "Alin Jerpelea " > imported > gpg: key A57CE1279F1E7328: public key "Alin Jerpelea (CODE SIGNING KEY) < > jerpe...@apache.org>" imported > gpg: key 6E72660F995FBC42: public key "Brennan Ashton < > bash...@brennanashton.com>" imported > gpg: Total number processed: 6 > gpg: imported: 6 > OK: > https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/incubator/nuttx/KEYS__;!!JmoZiZGBv3RvKRSx!_AM2wqhyvJXbdzPcQZFOXYpkBNNnZwGoKQnKS8BvvYvbskS3DKRb8iVUnDSCivUymvfOiZxGdtm_vcSa2jG3QOvIo50$ >is > imported. > Checking apache-nuttx-11.0.0-incubating.tar.gz sha512... > OK: apache-nuttx-11.0.0-incubating.tar.gz sha512 hash matches. > > Checking apache-nuttx-11.0.0-incubating.tar.gz GPG signature: > gpg: Signature made Fri Sep 9 19:17:06 2022 CST > gpg:using RSA key 9208D2E4B800D66F749AD4E94137A71698C5E4DB > gpg: Good signature from "Alin Jerpelea " [unknown] > gpg: WARNING: This key is not certified with a trusted signature! > gpg: There is no indication that the signature belongs to the > owner. > Primary key fingerprint: 9208 D2E4 B800 D66F 749A D4E9 4137 A716 98C5 E4DB > OK: apache-nuttx-11.0.0-incubating.tar.gz gpg signature matches. > > Checking apache-nuttx-11.0.0-incubating.tar.gz for required files: > OK: all required files exist in nuttx. > > Checking apache-nuttx-apps-11.0.0-incubating.tar.gz sha512... > OK: apache-nuttx-apps-11.0.0-incubating.tar.gz sha512 hash matches. > > Checking apache-nuttx-apps-11.0.0-incubating.tar.gz GPG signature: > gpg: Signature made Fri Sep 9 19:17:11 2022 CST > gpg:using RSA key 9208D2E4B800D66F749AD4E94137A71698C5E4DB > gpg: Good signature from "Alin Jerpelea " [unknown] > gpg: WARNING: This key is not certified with a trusted signature! > gpg: There is no indication that the signature belongs to the > owner. > Primary key fingerprint: 9208 D2E4 B800 D66F 749A D4E9 4137 A716 98C5 E4DB > OK: apache-nuttx-apps-11.0.0-incubating.tar.gz gpg signature matches. > > Checking apache-nuttx-apps-11.0.0-incubating.tar.gz for required files: > OK: all required files exist in apps. > > Trying to build nuttx sim:asan... > OK: we were able to build sim:asan. > > Trying to run nuttx sim:asan... > ==25236==WARNING: ASan is ignoring requested __asan_handle_no_return: stack > top: 0x7ffd0b573000; bottom 0x63123000; size: 0x1ced0b55 > (31804422946816) > False positive error reports may follow > For details see > https://urldefense.com/v3/__https://github.com/google/sanitizers/issues/189__;!!JmoZiZGBv3RvKRSx!_AM2wqhyvJXbdzPcQZFOXYpkBNNnZwGoKQnKS8BvvYvbskS3DKRb8iVUnDSCivUymvfOiZxGdtm_vcSa2jG3WBSDneE$ > OK: ostest with ASAN pass. > >> On Fri, Sep 9, 2022 at 7:28 PM Alin Jerpelea wrote: >> >> Hello all, >> Apache NuttX (Incubating) 11.0.0 RC2 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 72hr. >> >> A minimum of 3 binding +1 votes and more binding +1 than binding -1 >> are required to pass. >> >> The Apache requirements for approving a release can be found here [3] >> "Before voting +1 [P]PMC members are required to download the signed >> source code package, compile it as provided, and test the resulting >> executable on their own platform, along with also verifying that the >> package meets the requirements of the ASF policy on releases." >> >> A document to walk through some of this process has been published on >> our project wiki and can be found here [4]. >> >> [ ] +1 accept (indicate what you validated
RE: ADC device close and IRQ
>-Original Message- >From: Nathan Hartman >Sent: 16 September 2022 12:37 > >On Fri, Sep 16, 2022 at 7:33 AM TimH wrote: > >> >From: Nathan Hartman >> >Sent: 16 September 2022 12:31 >> >To: dev@nuttx.apache.org >> >Subject: Re: ADC device close and IRQ >> > >> >On Fri, Sep 16, 2022 at 7:20 AM TimH wrote: >> > >> >> Actually a little more complicated as the detach and disable in adc >> >> close then kills the touch screen driver as well (it uses the ADC). >> >> l'll figure out a way, I'm sure! >> > >> > >> > >> >I haven't looked at the code, but it sounds like any driver being >> >closed >> shuts >> >down the ADC for all drivers. >> > >> >Instead, the driver should keep a reference count. The underlying >> >hardware should be initialized when the first instance of the driver >> >is opened and >> un- >> >initialized only when the last instance of the driver is closed. >> > >> >Cheers >> >Nathan >> >> At present (by default/out of the box) there are two drivers - one for >> the TS, registered as /dev/input0, the other for the ADC, as >> /dev/adc0. There are, indeed, counts for each separate driver, but no >"cross-coupling". >> >> Perhaps the TS driver needs to be rolled into the ADC driver for this chip? > > > >If it's using the same physical hardware peripheral then they will indeed need >to be coordinated somehow, or combined. Not sure what specifically to >suggest here. > >Nathan Since all SAMA5Dx devices provide touchscreen support using the built-in ADC there is definitely an argument to move the touchscreen code into the ADC code. It will need a Kconfig bool to enable/disable this built-in support, as there is no reason a given design might not use an external TS controller chip - the built-in ADC support is only for resistive touchscreens, so any capacitive type will still need the external device, for example.
RE: ADC device close and IRQ
>From: Nathan Hartman >Sent: 16 September 2022 12:31 >To: dev@nuttx.apache.org >Subject: Re: ADC device close and IRQ > >On Fri, Sep 16, 2022 at 7:20 AM TimH wrote: > >> Actually a little more complicated as the detach and disable in adc >> close then kills the touch screen driver as well (it uses the ADC). >> l'll figure out a way, I'm sure! > > > >I haven't looked at the code, but it sounds like any driver being closed shuts >down the ADC for all drivers. > >Instead, the driver should keep a reference count. The underlying hardware >should be initialized when the first instance of the driver is opened and un- >initialized only when the last instance of the driver is closed. > >Cheers >Nathan At present (by default/out of the box) there are two drivers - one for the TS, registered as /dev/input0, the other for the ADC, as /dev/adc0. There are, indeed, counts for each separate driver, but no "cross-coupling". Perhaps the TS driver needs to be rolled into the ADC driver for this chip?
RE: ADC device close and IRQ
Actually a little more complicated as the detach and disable in adc close then kills the touch screen driver as well (it uses the ADC). l'll figure out a way, I'm sure! >-Original Message- >From: TimH >Sent: 15 September 2022 18:48 >To: dev@nuttx.apache.org >Subject: RE: ADC device close and IRQ > >Makes sense! I searched other drivers for where they called the detach but >didn't think to see where those other drivers called the attach! > >Thanks :) > >>-Original Message- >>From: Michal Lenc >>Subject: Re: ADC device close and IRQ >> >>Hi, >> >>> The easy option is to comment out the two calls, but I don't know if that' >>s >>> deemed acceptable, especially as other adc drivers do the same? >> >> >>I do not think this is correct since it is better to disable and detach >>the interrupt >> >>when we close the device. >> >> >>Instead I think the the enabling and attaching should be moved from >>sam_adc_ >>initialize() >> >>to sam_adc_setup() which is called every time the driver is opened from >>the application. >> >>Similar to SAMv7 ADC driver: >> >>https://github.com/apache/incubator- >>nuttx/blob/master/arch/arm/src/samv7/sam >>_afec.c#L845 >> >> >> >> >> >>This would ensure the interrupt is enabled and attached when the driver >>is opened >> >> >>and disabled and detached when it is closed. >> >> >> >> >>Best regards, >> >>Michal Lenc
RE: ADC device close and IRQ
Makes sense! I searched other drivers for where they called the detach but didn't think to see where those other drivers called the attach! Thanks :) >-Original Message- >From: Michal Lenc >Subject: Re: ADC device close and IRQ > >Hi, > >> The easy option is to comment out the two calls, but I don't know if that' >s >> deemed acceptable, especially as other adc drivers do the same? > > >I do not think this is correct since it is better to disable and detach the >interrupt > >when we close the device. > > >Instead I think the the enabling and attaching should be moved >from sam_adc_ >initialize() > >to sam_adc_setup() which is called every time the driver is opened from the >application. > >Similar to SAMv7 ADC driver: > >https://github.com/apache/incubator- >nuttx/blob/master/arch/arm/src/samv7/sam >_afec.c#L845 > > > > > >This would ensure the interrupt is enabled and attached when the driver is >opened > > >and disabled and detached when it is closed. > > > > >Best regards, > >Michal Lenc
ADC device close and IRQ
I have sorted the touchscreen on the SAMA5D2 - minor errors in the init code "as supplied" meaning a couple of registers were not set up right. I have also found that priority inheritance is needed, at least for the ADC example app: I've not sat back or read my books to see why, but it works for now. The issue I now have is that the call to close the ADC device, as opened by the example app, calls sam_adc_shutdown which disables interrupts and detaches them: up_disable_irq(SAM_IRQ_ADC) irq_detach(SAM_IRQ_ADC) Some other arch adc drivers do this too. The problem is that the enabling and attaching is done from sam_adc_initialize, therefore when the device is first registered from board_bringug. The result is that you can never again open the adc for business until a board reset. That doesn't seem right to me? The easy option is to comment out the two calls, but I don't know if that's deemed acceptable, especially as other adc drivers do the same?
RE: g_inode_sem.holder = -1
Thanks Greg - knowing that -1 is not error means I'm not wasting time investigating that, at least! The problem is unrelated to the touchscreen and more an RTOS/NuttX configuration error I think - the ADC example app will run once quite happily, with either 1 sample or 0 (i.e. run forever) - but if I try and run it a second time it gets stuck forever, just like the TS example app does. Something somewhere is misbehaving and causing semwait to wait forever so I'm going through pulling out stuff I've put in to see if it's down to me! >-Original Message- >From: Gregory Nutt >Sent: 14 September 2022 21:07 >To: dev@nuttx.apache.org >Subject: Re: g_inode_sem.holder = -1 > >> The only clue I have is that g_inode_sem.holder is set to -1, which >intuitively seems wrong to me, but this is way beyond me at this time of my >NuttX journey! > >The value -1 is not an error. It means that one thread is waiting to take a >count from the semaphore. The value of the semaphore was 0 when that >thread called sem_wait() (meaning that no counts are available). The count is >decremented to -1 while the thread is suspended waiting for a count. > >So this sound like the thread is waiting for an event that never occurs. > > >On Wed, Sep 14, 2022 at 11:23 AM TimH wrote: > >> Trying to get the touchscreen on my board registered and tested. It >> *seems* to register, and at one random point the touchscreen example >> app did report something that looked useful but I now cannot make any >sense of it. >> >> >> >> The ADC itself is registered and the ADC example app works fine, but >> when I try and open the TS device (/dev/input0) it hangs in >> inode_semtake when the call to nxsem_wait_uninterruptible is called. >> >> >> >> The only clue I have is that g_inode_sem.holder is set to -1, which >> intuitively seems wrong to me, but this is way beyond me at this time >> of my NuttX journey! >> >> >> >> Otherwise I'm suspecting a problem/mismatch with structs perhaps from >> the need to cast (think that's what it's called?) the adc_dev_s struct >> >> >> >> ret = sam_tsd_register( (struct sam_adc_s *) adc, 0) >> >> >> >> Any suggestions very welcome, as always :) >> >>
RE: build board from custom directory
Thank you! I was trying to run it like this: ./tools/configure.sh -l ../CustomBoards/board-name:config-name Perhaps this needs to be added to the configure.sh help text? >-Original Message- >From: Abdelatif Guettouche >Sent: 15 September 2022 11:59 >To: dev@nuttx.apache.org >Subject: Re: build board from custom directory > >There is an option for relative links. The you can pass the path to >configure.sh >Like configure.sh ../boards/custom-board/config/nsh > >On Thu, Sep 15, 2022 at 12:25 PM TimH wrote: > >> A few weeks ago I moved my custom board out of the NuttX >> "nuttx/nuttx/boards" tree to a folder "nuttx/CustomBoards". >> >> >> >> Make menuconfig allows you to specify that folder >> (CONFIG_ARCH_BOARD_CUSTOM_DIR=) >> >> >> >> To try and rule out .config errors for some issues I have at the >> moment I did a make distclean. Which wipes out the .config and the >> reference to my custom board directory. >> >> >> >> What is the correct syntax to tell configure.sh that the board is in a >> custom folder, please? >> >>
build board from custom directory
A few weeks ago I moved my custom board out of the NuttX "nuttx/nuttx/boards" tree to a folder "nuttx/CustomBoards". Make menuconfig allows you to specify that folder (CONFIG_ARCH_BOARD_CUSTOM_DIR=) To try and rule out .config errors for some issues I have at the moment I did a make distclean. Which wipes out the .config and the reference to my custom board directory. What is the correct syntax to tell configure.sh that the board is in a custom folder, please?
g_inode_sem.holder = -1
Trying to get the touchscreen on my board registered and tested. It *seems* to register, and at one random point the touchscreen example app did report something that looked useful but I now cannot make any sense of it. The ADC itself is registered and the ADC example app works fine, but when I try and open the TS device (/dev/input0) it hangs in inode_semtake when the call to nxsem_wait_uninterruptible is called. The only clue I have is that g_inode_sem.holder is set to -1, which intuitively seems wrong to me, but this is way beyond me at this time of my NuttX journey! Otherwise I'm suspecting a problem/mismatch with structs perhaps from the need to cast (think that's what it's called?) the adc_dev_s struct ret = sam_tsd_register( (struct sam_adc_s *) adc, 0) Any suggestions very welcome, as always :)
RE: Cache
I found that the up_enable_dcache function is there, with a call to cp15_enable_dcache, yes; and that function is in my system.map. But nothing calls it that I can find? >-Original Message- >From: Alan Carvalho de Assis >Sent: 13 September 2022 15:01 > >I don't know about sama5, but probably it is done here: arch/arm/src/armv7- >a/ > >On 9/13/22, TimH wrote: >> I will probably hit send then find it.but, right now, I can't see if >> there's anything I need to do to enable DCACHE? >> >> >> >> My .config has CONFIG_ARCH_DCACHE set, and that seems to "enable" all >> the various cache functions, including up_enable_dcache, but I can't >> find any calls to that function in sama5 related code. >> >> >> >> Any clues appreciated!! >> >> >> >>
Cache
I will probably hit send then find it.but, right now, I can't see if there's anything I need to do to enable DCACHE? My .config has CONFIG_ARCH_DCACHE set, and that seems to "enable" all the various cache functions, including up_enable_dcache, but I can't find any calls to that function in sama5 related code. Any clues appreciated!!
RE: SAMA5D3 and D4 DMA
Thanks Greg - I'm sure someone would have tripped over all of this if they'd tried to get DMA working. I will at the very least get it tested as best as I can on SAMA5D2 - which it definitely seems I am the only actual user of with NuttX! Lucky me lol. >-Original Message- >From: Gregory Nutt > > I did the D3 and D4 ports years ago and I am not aware of any other use of >those boards. DMA was partially functional then, but was not well tested and >was still buggy. There were problems documented in >https://github.com/apache/incubator- >nuttx/blob/master/boards/arm/sama5/sama5d4-ek/README.txt >which look like the same issues with the SAMA5D3x-EK in >https://github.com/apache/incubator- >nuttx/blob/master/boards/arm/sama5/sama5d3x-ek/README.txt > >The D2 was more an effort of several people and was based initially on the >D4 (which was based on the D3). > >On Mon, Sep 12, 2022 at 8:30 AM TimH wrote: > >> Aargh...too quick to retract. I think definitions for ATSAMA5D3 and >> ATSAMA5D4 are swapped and there *may* be inconsistencies, based on a >> comparison to datasheets. I don't think anyone has used it as I am 99% >> sure it wouldn't have worked as best as I can tell. File with issues is: >> >> arch/arm/src/sama5/sam_dmac.h >> >> It was the right file I was looking at, got confused by the presence >> of sam_xdmac.h as well as sam_dmac.h. >> >> I will had "# warning" for ATSAMA5D3 and ATSAMA5D4, and add a new >> section for SAMA5D2 which at least I hope to be able to check and >> confirm as working. >> >> >-Original Message- >> >From: TimH >> >Sent: 12 September 2022 14:54 >> >To: dev@nuttx.apache.org >> >Subject: RE: SAMA5D3 and D4 DMA >> > >> >Scrap that for now - was looking in the dma not xdma files >> > >> >>-Original Message- >> >>From: TimH >> >>Sent: 12 September 2022 14:14 >> >>To: dev@nuttx.apache.org >> >>Subject: SAMA5D3 and D4 DMA >> >> >> >>I am reworking DMA to get it working for the SAMA5D2. It seems to me >> >>that there are also errors and inconsistencies in the DMA code for >> >>the >> >>SAMA5D3 and D4 family. >> >> >> >> >> >> >> >>For now I have added "# warning" pre-processor statements. I have no >> >>means to check ATSAMA3 or ATSAMA4 devices - so unless someone can >> >>confirm that DMA does actually work for those 3 families and I've >> >>misunderstood something I will suggest that the warnings remain in >> >>place when I >> >eventually >> >>submit a PR for my work. >> > >> >> >>
RE: SAMA5D3 and D4 DMA
Aargh...too quick to retract. I think definitions for ATSAMA5D3 and ATSAMA5D4 are swapped and there *may* be inconsistencies, based on a comparison to datasheets. I don't think anyone has used it as I am 99% sure it wouldn't have worked as best as I can tell. File with issues is: arch/arm/src/sama5/sam_dmac.h It was the right file I was looking at, got confused by the presence of sam_xdmac.h as well as sam_dmac.h. I will had "# warning" for ATSAMA5D3 and ATSAMA5D4, and add a new section for SAMA5D2 which at least I hope to be able to check and confirm as working. >-Original Message- >From: TimH >Sent: 12 September 2022 14:54 >To: dev@nuttx.apache.org >Subject: RE: SAMA5D3 and D4 DMA > >Scrap that for now - was looking in the dma not xdma files > >>-Original Message- >>From: TimH >>Sent: 12 September 2022 14:14 >>To: dev@nuttx.apache.org >>Subject: SAMA5D3 and D4 DMA >> >>I am reworking DMA to get it working for the SAMA5D2. It seems to me >>that there are also errors and inconsistencies in the DMA code for the >>SAMA5D3 and D4 family. >> >> >> >>For now I have added "# warning" pre-processor statements. I have no >>means to check ATSAMA3 or ATSAMA4 devices - so unless someone can >>confirm that DMA does actually work for those 3 families and I've >>misunderstood something I will suggest that the warnings remain in >>place when I >eventually >>submit a PR for my work. >
RE: SAMA5D3 and D4 DMA
Scrap that for now - was looking in the dma not xdma files >-Original Message- >From: TimH >Sent: 12 September 2022 14:14 >To: dev@nuttx.apache.org >Subject: SAMA5D3 and D4 DMA > >I am reworking DMA to get it working for the SAMA5D2. It seems to me that >there are also errors and inconsistencies in the DMA code for the SAMA5D3 >and D4 family. > > > >For now I have added "# warning" pre-processor statements. I have no means >to check ATSAMA3 or ATSAMA4 devices - so unless someone can confirm that >DMA does actually work for those 3 families and I've misunderstood >something I will suggest that the warnings remain in place when I eventually >submit a PR for my work.
SAMA5D3 and D4 DMA
I am reworking DMA to get it working for the SAMA5D2. It seems to me that there are also errors and inconsistencies in the DMA code for the SAMA5D3 and D4 family. For now I have added "# warning" pre-processor statements. I have no means to check ATSAMA3 or ATSAMA4 devices - so unless someone can confirm that DMA does actually work for those 3 families and I've misunderstood something I will suggest that the warnings remain in place when I eventually submit a PR for my work.
RE: SAMA5D2 DMA
>From: Nathan Hartman >Sent: 09 September 2022 12:50 >To: dev@nuttx.apache.org >Subject: Re: SAMA5D2 DMA > >> Rather than clutter sam_xdmac.h with loads of #if defined (SAMA5D2) >> stuff would it be better to deal with this in the same way as the >> memory and pinmap files, etc, and have: >> >> _sama5d2x_xdmac.h >> _sama5d3x_xdmac.h >> _sama5d4x_xdmac.h >> >> Then change sam_xdmac.h to have the more easy to follow >> >> #if defined(SAMA5D2) >> # include "hardware/_sama5d2x_xdmac.h" >> #elif >> etc >> >> I think that's neater? > > > >I think so. The #if defined stuff makes sense when parts are mostly identical >but if there's so much of it that it makes the file hard to read, then >splitting it >up makes more sense. > Thanks - once I start sorting this out I'll see how many differences there really are and choose the methodology based on that.
RE: SAMA5D2 DMA
>From: TimH >Sent: 07 September 2022 12:14 > >A quick dabble with DMA for the SAMA5D2 chip I'm using suggests the native >NuttX support for this is incorrect and probably applies to SAMA5D3 chips etc. >There are refences in sam_xdmac.c to PIDS that simply don't exist in the >SAMA5D2. > On further inspection it seems sam_xdmac.h is only describing the configuration of a SAMA5D4. The SAMA5D3 and SAMA5D2 have different numbers of channels and different channel definitions Rather than clutter sam_xdmac.h with loads of #if defined (SAMA5D2) stuff would it be better to deal with this in the same way as the memory and pinmap files, etc, and have: _sama5d2x_xdmac.h _sama5d3x_xdmac.h _sama5d4x_xdmac.h Then change sam_xdmac.h to have the more easy to follow #if defined(SAMA5D2) # include "hardware/_sama5d2x_xdmac.h" #elif etc I think that's neater?
RE: Driver for combined battery charger and regulator
Apologies for the long post, but given the absence of many/any voltage
regulator drivers - especially PMICs - I feel I need to get this all sorted and
agreed. So I have looked long and hard at the Nuttx files and Linux
documentation and to see if I have got it right I would like to see if the
following descriptions of the Nuttx struct fields make sense.
struct regulator_desc_s
{
const char *name; /* Friendly name that will be used to
get/set/etc a given regulator. For example "VCC" */
unsigned int n_voltages; /* The number of discrete voltage selector
steps this regulator allows. 0 if linear mapping is to be used instead */
unsigned int vsel_reg;/* The device-specific regulator
"channel", or GPIO output, or similar, for this regulator */
unsigned int vsel_mask; /* Mask, if relevant, to use with vsel_reg*/
unsigned int enable_reg; /* Device specific enable register, if
relevant, for this regulator */
unsigned int enable_mask; /* Mask, if relevant, to use with enable_reg*/
unsigned int enable_time; /* Time taken for the regulator voltage output
voltage to stabilise after being enabled, in microseconds */
unsigned int ramp_delay; /* Set the ramp delay for the regulator. The
driver should select ramp delay equal to or less than(closest) ramp_delay */
unsigned int uv_step; /* Voltage increase with each selector if
linear mapping. 0 if only selector steps are allowed */
unsigned int min_uv; /* Smallest voltage consumers may set*/
unsigned int max_uv; /* Largest voltage consumers may set */
unsigned int apply_uv;/* ?? SEE BELOW [1] */
bool boot_on; /* Set if the regulator is enabled when the
system is initially started SEE BELOW [2].
If the regulator is not enabled by the
hardware or bootloader then it will be enabled when the constraints are applied
*/
};
[1] "apply_uv" is a bool in Linux but an int in Nuttx. In Linux it tells you
whether the "constraint" voltage is applied during init. I think it should be a
bool in Nuttx too? With the ACT8945A, for example, REG1-5 power on by default,
whereas REG6 and 7 do not. The REG1-5 will report back "0" and REG6/6 "1" in
boot_on.
[2] It is not clear, either in Linux or Nuttx, what the "constraint voltage"
that is applied during init will be. Perhaps the NuttX intent is - or should be
- to use an actual value here (hence the int?) which will be applied during
init IF "boot_on" is set on (suggesting it is a parameter that should be passed
TO the regulator register/init function not filled in BY it?
If this is all (nearly) correct, then I think the call to register a regulator
(from board_bringup, say) needs to initialise the following variables in the
regulator_desc_s struct that's passed:
- name For example, in my design, REG1 is "VIODDR"
- vsel_reg In my example it is "REG1" and I need to tell
the ACT8945A driver this.
- vsel_mask (if relevant). Not relevant in my case
- enable_reg, if relevant. Not relevant in my case.
- enable_mask, if relevant. Not relevant in my case.
So we would have (for this i2c device, at least):
FAR struct regulator_desc_s *act8945a_desc_s;
FAR struct i2c_master_s*act89945a_i2c ;
int ret;
act89945a_i2c = board_i2c_init(busno);
if (!act8945a_i2c)
{
Blah blah;
}
act8945a_desc_s->name = "VIODDR";
act8945a_desc_s->vsel_reg = 1;
ret = act8945a_device_init(act8945a_desc_s, act8945a_i2c);
if (ret < 0)
{
Blah blah;
}
The init/register routine will fill in the missing blanks in the structure and
we can go from there to set it up. When needed in the user app, we can do a
"regulator get" to see what we've got and change things as needed.
Does that sound right or am I way off the mark?
If I'm nearly right I might add that I believe there are useful members of the
regulator_desc_s structure missing, such as "active_discharge" that's useful
for the ACT8945A. Maybe also "always on" which tells the driver NEVER to turn
this one off - rather important for PMIC devices I would say, although NuttX
apps aren't quite so likely to mess around with regulators on these custom
boards. I can add these to the struct, of course, as I write my driver.
Final observation - Linux documentation quite clearly states microvolts for all
voltage parameters. That means a simple 3V3 regulator will be set up with the
value 330 passed to the functions, so it has to use uint32_t. Maybe that
makes sense for Linux, but perhaps for Nuttx it should be in millivolts? I see
there's a driver for an AXP202 device and that is clearly assuming millivolts?
RE: Driver for combined battery charger and regulator
Please correct me if I'm still missing something, as there are zero >> clues I can find as to what each ops function (for example) is >> actually supposed to do. >> >> >> >Here is two examples: >https://github.com/apache/incubator- >nuttx/blob/master/drivers/power/supply/regulator_gpio.c >https://github.com/apache/incubator- >nuttx/blob/master/drivers/power/supply/regulator_rpmsg.c 10.3 release that I'm using has no files with reference to (for example) get_voltage_sel. It is impractical to keep a development project up to date with master so I only merge/rebase when there's a formal release. But thank you for these, I will take a look and hopefully they will point me in the right direction.
RE: Driver for combined battery charger and regulator
Looking further, I'm thinking that this driver template has never been used, is undocumented, and is therefore bordering on unusable. Please correct me if I'm still missing something, as there are zero clues I can find as to what each ops function (for example) is actually supposed to do.
RE: Driver for combined battery charger and regulator
>From: Xiang Xiao >Sent: 07 September 2022 13:40 > >On Wed, Sep 7, 2022 at 8:13 PM TimH wrote: > >> >From: Alan Carvalho de Assis >> >Sent: 06 September 2022 13:51 >> >I think for ACT8945A should be included a regulator at >> drivers/power/supply/ >> >and will implement the functions from and >> >will register itself with regulator_register(). >> >> Sorry for the dumb question, but do I use regulator.c directly, or is >> it just a template for my own act8945a.c driver? I can find no other >> files that include regulator.h! >> >> >You need implement regulator_ops_s and call regulator_register, other >drivers which want to enable the power need call regulator_get and >regulator_enable > > >> And if this is very clear from some documentation somewhere, I apologise! >> >> >NuttX regulator framework is similar Linux kernel, so you can reference >this: >https://docs.kernel.org/power/regulator/overview.html >From looking at the Linux documentation then back at Nuttx register.c it leads >me to think I have to register 6 different devices for this 6-output PMIC. Is >that right?
RE: Driver for combined battery charger and regulator
>From: Alan Carvalho de Assis >Sent: 06 September 2022 13:51 >I think for ACT8945A should be included a regulator at drivers/power/supply/ >and will implement the functions from and will >register itself with regulator_register(). Sorry for the dumb question, but do I use regulator.c directly, or is it just a template for my own act8945a.c driver? I can find no other files that include regulator.h! And if this is very clear from some documentation somewhere, I apologise!
SAMA5D2 DMA
A quick dabble with DMA for the SAMA5D2 chip I'm using suggests the native NuttX support for this is incorrect and probably applies to SAMA5D3 chips etc. There are refences in sam_xdmac.c to PIDS that simply don't exist in the SAMA5D2. Can anyone confirm - or correct me if I'm wrong?
RE: Driver for combined battery charger and regulator
Thanks! I think I will take the following approach: - Use Kconfig to determine the default setup (which regulators are enabled, and their voltage). If another user wants to do this manually it can be achieved by disabling them in Kconfig and using ioctl to set them manually - have first initialisation of the device via the device register function - since the ACT8945A has no chip ID register to read, I can readback another register and check it matches what it should be (based on Kconfig and initial setup) and abort the device registration if there's a problem (most likely caused by the device not being there or otherwise failed). Think that should do it. Thank you as ever, Alan, for taking the time to help me. FYI I am awaiting 11.0 release and will then rebase to that, and submit my first PR's for my new drivers >-Original Message- >From: Alan Carvalho de Assis >Sent: 06 September 2022 15:08 >To: dev@nuttx.apache.org >Subject: Re: Driver for combined battery charger and regulator > >Hi Tim, > >I think you can implement a register and a initialization as separated >functions, >if you search you will find some drivers implemented that way. > >I remember a developer that complained about the fact the some sensors are >initialized automatically during the register phase and it was bad for him >because he was developing a low power device, so he needs to go through >ioctl to fix that issue. > >Currently I think the approach is make it works from scratch, but of course it >could be an issue for some usage. > >This is something we need to revisit in the future. > >Other thing is an issue is that some drivers don't have a probe (some kind of >prove of existence), it just assumes the device is there in the SPI/I2C bus and >don't try to talk with it and goes on creating the device file. It makes the >file of >user hard because he see the device at /dev and think that everything is fine. > >BR, > >Alan > >On 9/6/22, TimH wrote: >> Oh - OK! Thanks Alan. Makes my life easier (for now) as I'm not using >> the battery charger element on this board iteration so I can leave it >> for later. >> >> Any thoughts on my mental tussles regarding registering vs. initialising? >> >>>-Original Message- >>>From: Alan Carvalho de Assis >>>Sent: 06 September 2022 13:51 >>>To: dev@nuttx.apache.org >>>Subject: Re: Driver for combined battery charger and regulator >>> >>>Hi Tim, >>> >>>AFAIK we don't have a PMIC with battery regulator in the mainline yet. >>>So you don't have a reference to base on it. >>> >>>You don't need to create a single file with all functions on it, you >>>can create separated file for each specific function. This is how >>>MC13892 is implemented on Linux (please don't look the source code, it >>>is GPL), this chip is a PMIC with regulator, battery charger and LEDs >>>control. >>> >>>I think for ACT8945A should be included a regulator at >>>drivers/power/supply/ and will implement the functions from >>> and will register itself with >>>regulator_register(). >>> >>>Also you will include the battery charger logic at >>>driver/power/battery/ as a separated act8945_batchr.c to avoid mixing >>>things and will export itself as /dev/bat0. >>> >>>But you will need to use spinlock when accessing the I2C bus inside >>>these drivers to avoid both drivers trying to use it while a transfer >>>is in progress. >>> >>>BR, >>> >>>Alan >>> >>>On 9/6/22, TimH wrote: >>>> I'm writing a driver for the Quorvo ACT8945A device. This is a >>>> combined 7-output programmable regulator AND Li-ion battery charger, >>>> all >>>in one. >>>> >>>> >>>> >>>> I see there are existing "regulator.h" and "battery_charger.h" >>>> driver templates. >>>> >>>> >>>> >>>> Would my best approach to be to create a driver using a new (e.g.) >>>> "battery_charger_regulator.h" template combining that existing >>>> functionality or is there another, preferred, approach? >>>> >>>> >>>> >>>> Would the preferred device name be "/dev/bat0"? Or "/dev/act8945a"? >>>> Or something else? >>>> >>>> >>>> >>>> Then, once that is decided, I seem to have a mental block when it >>>> comes to device initialisation vs registering. >>>> >>>> >>>> >>>> In my mind, registering should just create the /dev/ entry and >>>> initialise the relevant structs, but not touch the device itself? >>>> But some drivers do go on to actually set up the device, whereas I >>>> think that should be a separate "init" function called independently >>>> of the >>>"register" >>>> function, or a specific ioctl perhaps? What is the best practice here? >>>> >>>> >>>> >>>> Thanks, >>>> >>>> >>>> >>>> Tim. >>>> >>>> >>>> >>>> >> >>
RE: Driver for combined battery charger and regulator
Oh - OK! Thanks Alan. Makes my life easier (for now) as I'm not using the battery charger element on this board iteration so I can leave it for later. Any thoughts on my mental tussles regarding registering vs. initialising? >-Original Message- >From: Alan Carvalho de Assis >Sent: 06 September 2022 13:51 >To: dev@nuttx.apache.org >Subject: Re: Driver for combined battery charger and regulator > >Hi Tim, > >AFAIK we don't have a PMIC with battery regulator in the mainline yet. >So you don't have a reference to base on it. > >You don't need to create a single file with all functions on it, you can create >separated file for each specific function. This is how >MC13892 is implemented on Linux (please don't look the source code, it is >GPL), this chip is a PMIC with regulator, battery charger and LEDs control. > >I think for ACT8945A should be included a regulator at drivers/power/supply/ >and will implement the functions from and will >register itself with regulator_register(). > >Also you will include the battery charger logic at driver/power/battery/ as a >separated act8945_batchr.c to avoid mixing things and will export itself as >/dev/bat0. > >But you will need to use spinlock when accessing the I2C bus inside these >drivers to avoid both drivers trying to use it while a transfer is in progress. > >BR, > >Alan > >On 9/6/22, TimH wrote: >> I'm writing a driver for the Quorvo ACT8945A device. This is a >> combined 7-output programmable regulator AND Li-ion battery charger, all >in one. >> >> >> >> I see there are existing "regulator.h" and "battery_charger.h" driver >> templates. >> >> >> >> Would my best approach to be to create a driver using a new (e.g.) >> "battery_charger_regulator.h" template combining that existing >> functionality or is there another, preferred, approach? >> >> >> >> Would the preferred device name be "/dev/bat0"? Or "/dev/act8945a"? Or >> something else? >> >> >> >> Then, once that is decided, I seem to have a mental block when it >> comes to device initialisation vs registering. >> >> >> >> In my mind, registering should just create the /dev/ entry and >> initialise the relevant structs, but not touch the device itself? But >> some drivers do go on to actually set up the device, whereas I think >> that should be a separate "init" function called independently of the >"register" >> function, or a specific ioctl perhaps? What is the best practice here? >> >> >> >> Thanks, >> >> >> >> Tim. >> >> >> >>
Driver for combined battery charger and regulator
I'm writing a driver for the Quorvo ACT8945A device. This is a combined 7-output programmable regulator AND Li-ion battery charger, all in one. I see there are existing "regulator.h" and "battery_charger.h" driver templates. Would my best approach to be to create a driver using a new (e.g.) "battery_charger_regulator.h" template combining that existing functionality or is there another, preferred, approach? Would the preferred device name be "/dev/bat0"? Or "/dev/act8945a"? Or something else? Then, once that is decided, I seem to have a mental block when it comes to device initialisation vs registering. In my mind, registering should just create the /dev/ entry and initialise the relevant structs, but not touch the device itself? But some drivers do go on to actually set up the device, whereas I think that should be a separate "init" function called independently of the "register" function, or a specific ioctl perhaps? What is the best practice here? Thanks, Tim.
RE: 10.3 merge issues
Looks like some kind of conflict with syslog settings in the config (either "default SYSLOG device" or "Use SYSLOG for /dev/console". I've not been using syslog, so probably something I'd tried (i.e. stab in the dark!) for some reason in the past that was benign in 10.2 and not in 10.4. Working again on Minicom with either readline or CLE. Back to development now...until 11.0 comes along and I go through it all again lol. >-Original Message- >From: TimH >Sent: 18 August 2022 10:59 >To: dev@nuttx.apache.org >Subject: RE: 10.3 merge issues > >>-Original Message- >>From: Gregory Nutt >>Sent: 17 August 2022 19:16 >>To: dev@nuttx.apache.org >>Subject: Re: 10.3 merge issues >> >> >>> >>> It all boots and I get the nsh prompt but I get continuous: >>> >>> nsh_session: cle failed: 22 >>> >>> I'm assuming that's EINVAL, but I can't work out why? >>> >>> >> >>What kind of terminal do you use? CLE only works with a >>VT100-compatible terminal and will return -EINVAL to nsh_session if the >>terminal does not respond correctly to a VT100 request for the current >cursor position. >> >[Tim] Vt102 on Minicom. Putty behaves the same. > >If I disable CLE and use the basic readline console I get a different error >and it >hangs: > >NuttShell (NSH) NuttX-10.3.0 >nsh> nsh: nsh_session: readline failed: 0 > >Undoubtedly some conflict in my .config from a change between 10.2 and 10.3 >but seems a pretty basic thing to have been changed/broken? Any >suggestions very welcome!
RE: 10.3 merge issues
>-Original Message- >From: Gregory Nutt >Sent: 17 August 2022 19:16 >To: dev@nuttx.apache.org >Subject: Re: 10.3 merge issues > > >> >> It all boots and I get the nsh prompt but I get continuous: >> >> nsh_session: cle failed: 22 >> >> I'm assuming that's EINVAL, but I can't work out why? >> >> > >What kind of terminal do you use? CLE only works with a VT100-compatible >terminal and will return -EINVAL to nsh_session if the terminal does not >respond correctly to a VT100 request for the current cursor position. > [Tim] Vt102 on Minicom. Putty behaves the same. If I disable CLE and use the basic readline console I get a different error and it hangs: NuttShell (NSH) NuttX-10.3.0 nsh> nsh: nsh_session: readline failed: 0 Undoubtedly some conflict in my .config from a change between 10.2 and 10.3 but seems a pretty basic thing to have been changed/broken? Any suggestions very welcome!
RE: 10.3 merge issues
>-Original Message- >From: Nathan Hartman >Sent: 18 August 2022 03:01 >To: dev@nuttx.apache.org >Subject: Re: 10.3 merge issues > >On Wed, Aug 17, 2022 at 3:27 PM Tim Hardisty wrote: > >> I realise, now, I compared mine against 10.2 variants not 10.3...not >> sure why, but there you go. I'll give that a try tomorrow - thanks! > > >Sure thing! Let us know if that fixes it. I'm pretty sure that change in your >board's Make.defs (and there might be a couple of others, that's why I >suggest to compare it to the up-to-date Make.defs of the board you cloned) >should fix the compile issues... > [Tim]Don't know why I compared against previous make.defs examples - silly me! Using the revised syntax it now works - thanks :)
RE: 10.3 merge issues
Thanks for the useful tip "V=1" = didn't know that Alan :)
But nothing additional reported, just the same " no rule to make" error
>-Original Message-
>From: Alan Carvalho de Assis
>Sent: 17 August 2022 18:14
>To: dev@nuttx.apache.org
>Subject: Re: 10.3 merge issues
>
>Hi Tim,
>
>Try to compile with verbose enabled:
>
>$ make V=1
>
>Probably your board is bringing some older definition that is causing a
>variable
>to be created incorrectly, because "-T/something" doesn't appear a valid
>target.
>
>BR,
>
>Alan
>
>On Wednesday, August 17, 2022, TimH wrote:
>
>> Hi All,
>>
>>
>>
>> My project has been in hibernation for 6 months for personal reasons
>> but today was the day I fired the custom board up again to restart
>> porting work.
>>
>>
>>
>> My 10.2-based "in progress" work behaves as before (which was a
>> relief) so I decided I would merge in 10.3 to make sure I restarted
>> with the latest release (not withstanding that 10.4 is close!).
>>
>>
>>
>> Most issues were easily solved by referring to release notes or good ol'
>> Google but I am left with one major and 1 minor problem.
>>
>>
>>
>> 1. Final change that allowed a compile was when I changed the
>> defconfig
>> to have the new:
>>
>>
>>
>> CONFIG_INIT_ENTRYPOINT="nsh_main"
>>
>> CONFIG_INIT_ENTRYNAME="nsh"
>>
>>
>>
>> It all boots and I get the nsh prompt but I get continuous:
>>
>>
>>
>> nsh_session: cle failed: 22
>>
>>
>>
>> I'm assuming that's EINVAL, but I can't work out why?
>>
>>
>>
>> 2. my board Make.defs file is an edited clone of another from the same
>> device (SAMA5D2) and is virtually identical to many other similar
>> files for other chips of course. I am running "Ubuntu 20.04.3 TLS"
>>
>>
>>
>> This is included in virtually all these files for any chip/arch:
>>
>>
>>
>> ifeq ($(CONFIG_CYGWIN_WINTOOL),y)
>>
>> ARCHSCRIPT = -T "${shell cygpath -w
>> $(BOARD_DIR)$(DELIM)scripts$(DELIM)$(LDSCRIPT)}"
>>
>> else
>>
>> ARCHSCRIPT = -T$(BOARD_DIR)$(DELIM)scripts$(DELIM)$(LDSCRIPT)
>>
>> endif
>>
>>
>>
>> But the compiler complains that there's:
>>
>>
>>
>> no rule to make target '-T/home/{rest of the path}'
>>
>>
>>
>> If I remove the -T it is fine.
>>
>>
>>
>> Linux/Ubuntu is including the -T in the path I assume? Seems very odd
>> that
>> 10.2 was OK with this but not 10.3 - so not a Ubuntu issue I assume?
>> Linux skills are definitely lacking, so any suggestions welcomed!
>>
>>
RE: 10.3 merge issues
Yes - I have CONFIG_NSH_CLE defined.
There are no .o files after a make clean
>-Original Message-
>From: Nathan Hartman
>Sent: 17 August 2022 19:10
>To: dev@nuttx.apache.org
>Subject: Re: 10.3 merge issues
>
>On Wed, Aug 17, 2022 at 12:56 PM TimH wrote:
>> 1. Final change that allowed a compile was when I changed the defconfig
>> to have the new:
>>
>>
>>
>> CONFIG_INIT_ENTRYPOINT="nsh_main"
>>
>> CONFIG_INIT_ENTRYNAME="nsh"
>>
>>
>>
>> It all boots and I get the nsh prompt but I get continuous:
>>
>>
>>
>> nsh_session: cle failed: 22
>>
>>
>>
>> I'm assuming that's EINVAL, but I can't work out why?
>
>
>Looks to me like this message is probably printed from nsh_stdlogin(), but I
>cannot understand where the "nsh_session" part of that printout is coming
>from. Do you have CONFIG_NSH_CLE defined? (NSH_CLE in Kconfig).
>
>More below...
>
>
>> 2. my board Make.defs file is an edited clone of another from the same
>> device (SAMA5D2) and is virtually identical to many other similar
>> files for other chips of course. I am running "Ubuntu 20.04.3 TLS"
>>
>> This is included in virtually all these files for any chip/arch:
>>
>> ifeq ($(CONFIG_CYGWIN_WINTOOL),y)
>>
>> ARCHSCRIPT = -T "${shell cygpath -w
>> $(BOARD_DIR)$(DELIM)scripts$(DELIM)$(LDSCRIPT)}"
>>
>> else
>>
>> ARCHSCRIPT = -T$(BOARD_DIR)$(DELIM)scripts$(DELIM)$(LDSCRIPT)
>>
>> endif
>>
>> But the compiler complains that there's:
>>
>> no rule to make target '-T/home/{rest of the path}'
>>
>> If I remove the -T it is fine.
>>
>> Linux/Ubuntu is including the -T in the path I assume? Seems very odd
>> that
>> 10.2 was OK with this but not 10.3 - so not a Ubuntu issue I assume?
>> Linux skills are definitely lacking, so any suggestions welcomed!
>
>
>Regarding question #2:
>
>Dumb question, but after 'make clean' or 'make distclean' could you verify
>there are no stale object files (*.o) anywhere in the nuttx or apps trees? I'm
>asking because I've run into this problem in the past where some obscure
>error in the makefiles caused some stale objects to stay around.
>
>Cheers,
>Nathan
RE: 10.3 merge issues
>-Original Message- >From: Gregory Nutt >Sent: 17 August 2022 19:16 >Subject: Re: 10.3 merge issues > > >> 1. Final change that allowed a compile was when I changed the defconfig >> to have the new: >> >> >> >> CONFIG_INIT_ENTRYPOINT="nsh_main" >> >> CONFIG_INIT_ENTRYNAME="nsh" >> >> >> >> It all boots and I get the nsh prompt but I get continuous: >> >> >> >> nsh_session: cle failed: 22 >> >> >> >> I'm assuming that's EINVAL, but I can't work out why? >> >> > >What kind of terminal do you use? CLE only works with a VT100-compatible >terminal and will return -EINVAL to nsh_session if the terminal does not >respond correctly to a VT100 request for the current cursor position. > [Tim] Minicom (via serial->USB) under WSL (main build/dev environment is a "proper" Linux machine, but run Minicom via WSL for historic reasons) It has a choice of VT102 or ANSI - both behave the same.
10.3 merge issues
Hi All,
My project has been in hibernation for 6 months for personal reasons but
today was the day I fired the custom board up again to restart porting work.
My 10.2-based "in progress" work behaves as before (which was a relief) so I
decided I would merge in 10.3 to make sure I restarted with the latest
release (not withstanding that 10.4 is close!).
Most issues were easily solved by referring to release notes or good ol'
Google but I am left with one major and 1 minor problem.
1. Final change that allowed a compile was when I changed the defconfig
to have the new:
CONFIG_INIT_ENTRYPOINT="nsh_main"
CONFIG_INIT_ENTRYNAME="nsh"
It all boots and I get the nsh prompt but I get continuous:
nsh_session: cle failed: 22
I'm assuming that's EINVAL, but I can't work out why?
2. my board Make.defs file is an edited clone of another from the same
device (SAMA5D2) and is virtually identical to many other similar files for
other chips of course. I am running "Ubuntu 20.04.3 TLS"
This is included in virtually all these files for any chip/arch:
ifeq ($(CONFIG_CYGWIN_WINTOOL),y)
ARCHSCRIPT = -T "${shell cygpath -w
$(BOARD_DIR)$(DELIM)scripts$(DELIM)$(LDSCRIPT)}"
else
ARCHSCRIPT = -T$(BOARD_DIR)$(DELIM)scripts$(DELIM)$(LDSCRIPT)
endif
But the compiler complains that there's:
no rule to make target '-T/home/{rest of the path}'
If I remove the -T it is fine.
Linux/Ubuntu is including the -T in the path I assume? Seems very odd that
10.2 was OK with this but not 10.3 - so not a Ubuntu issue I assume? Linux
skills are definitely lacking, so any suggestions welcomed!
email issues
I've been aware that some of my emails haven't got through to people on this list and, also, that I have not been getting every email from others. Checking our mail server logs it would seem that any email from a sender whose mail server uses DKIM is likely to be rejected by recipient servers that check DKIM. This includes dev@NuttX emails because the apache mail reflector (if that's the right terminology) causes the DKIM signature to be corrupted. Perhaps that's just the way it is - I'm not sure. Since we have also had continual issues with our genuine work emails being rejected by gmail (and only gmail) because of some DKIM issue I just can't work out, I have disabled DKIM from incoming and outgoing emails on our server as a temporary measure. Hope this helps others who have not been getting dev@NuttX emails.
Re: RNDIS and DHCPD
Will check those configs, thanks Alan. But I want the NuttX device to be the DHCP server, so the PC gets an IP address in the same subnet as the NuttX device, assuming the PC is set to get IP addresses via DHCP. I don't think the PC (Linux or Windows) can give the NuttX device an IP address without lots of hassle. My hope is that I can enable my board as a DHCP server and web server: plug it to a PC (USB/RNDIS), use a browser, and get web pages served from the device to configure, and get files. This means I don't need USB MSD and FAT :) On 25/01/2022 20:20, Alan Carvalho de Assis wrote: Hi Tim, Looking my see you can see that I faced some issues with Ubuntu attributing DHCP address to my board, but I think it works if you use a better dhcp server on Linux. I suggest you too look how other boards are configuring it, i.e.: boards/arm/lc823450/lc823450-xgevk/configs/rndis/defconfig boards/arm/stm32/stm32f4discovery/configs/rndis/defconfig BR, Alan On 1/25/22, TimH wrote: First attempt hasn't worked, but not I've investigated or checked my .config yet; but, before I do, is it reasonable to expect NuttX to support DHCP server and USB RNDIS such that a connected PC gets an IP address from the NuttX RNDIS "gadget" allowing connectivity without the PC user having to change adapter settings (assuming the adapter is set for DHCP)? If so, great, I'll persevere. If not, I'll save myself the hassle :)
RNDIS and DHCPD
First attempt hasn't worked, but not I've investigated or checked my .config yet; but, before I do, is it reasonable to expect NuttX to support DHCP server and USB RNDIS such that a connected PC gets an IP address from the NuttX RNDIS "gadget" allowing connectivity without the PC user having to change adapter settings (assuming the adapter is set for DHCP)? If so, great, I'll persevere. If not, I'll save myself the hassle :)
Re: Alternatives to FAT for msd
Definitely an option! Still need a good way to get data on and off easily from Windows/Linux/Mac but a copy-on-write type file system is more than adequate for this product - thanks for the suggestion :) On 22/01/2022 16:48, Tomasz CEDRO wrote: Maybe LittleFS? Embedded, wear level and power failure resistant by design :-) https://github.com/littlefs-project/littlefs
Re: Alternatives to FAT for msd
Now I have RNDIS working on Windows (Linux a work-in-progress) I am back to thinking of the best way forward. If anyone has further thoughts on the following I'm very interested: - FAT/MSD/USB. Still seems the easiest for the customers (think consumer, not necessarily tech-savvy), but FAT is non-journaled, is not good on flash and, anyway, doesn't work with my devices yet (I suspect bugs in the sector512 layer but put this on the back burner for now). - MTP. No NuttX implementation, possibilities of doing it but probably hard work. - RNDIS. Having got this working, it takes me back to "hacking" embedded devices in years gone by, with lots of messing around with net adapter settings, manual IP address, Telnet. Great for techies but not good for end users who want it to work out of the box. For file systems I think I will go back to getting smartFS up and running and take a look at the journaling implementations and see if this can be added to the NuttX SmartFS legally. Then I'm wondering of there's some kind of FAT-to-SmartFS virtual translation possible, so that USB MSD "sees" FAT but that is actually a translation layer to SmartFS. Very little experience of file systems but since this whole move to NuttX is baptism of fire, what the h€ll! If RNDIS can be made user-friendly then that could still be a good path of course. And a solution for tech-savvy customers to do clever things :) I see Linux has FUSE so that is way for Linux (and Mac) to read SmartFS if I understand it right but not, easily, on Windows that I can see Bottom line - I would like to avoid the average user from needing to do anything difficult and, ideally, not have to rely on an app to get connectivity.
Re: Alternatives to FAT for msd
Are there any implementations of MTP using NuttX, or that could be easily and legally ported? On 19/01/2022 18:54, Frank-Christian Kruegel wrote: Am 19.01.2022 um 19:40 schrieb TimH: - an external PC (ideally Linux, Windows and MAC) needs to be able "see" the data via USB (msd) and read/write to the memory (log data, config files, audio files, etc). Hence FAT. There is MTP (https://en.wikipedia.org/wiki/Media_Transfer_Protocol), which operates on a file level, not a block level. Cameras and MP3 players use this. When using MTP you are free to choose any suitable file system since this is never exported to the outside world, and file locking etc is never an issue. Frank-Christian Krügel
Re: RNDIS
There are ways, like there are via some VMs, but I've not tried them. I do have an old, spare, laptop and also a PC so can always load 18.04 on those if all else fails. On 21/01/2022 18:15, Alan Carvalho de Assis wrote: WSL doesn't have USB support AFAIK, I think even WSL2 it doesn't work fine yet. On 1/21/22, TimH wrote: I guess I can try it on WSL too, but I'll also set up my Linux machine to dual boot 20.04 and 18.04. All part of the "Tim gets to grips with Linux" life experience :) On 21/01/2022 16:30, Alan Carvalho de Assis wrote: Hi Tim, did you try other Linux distro? Maybe it could be some incompatibility in recent Linux kernel. I suggest you to test on an old Linux distro (i.e. Ubuntu 18.04 LTS) just to double check. BR, Alan On 1/21/22, Tim wrote: Windows now working properly but not Linux. My board can be powered via the USB and I think it all got confused as I had been leaving the USB cable connected, coupled with not flashing code but using JTAG download for debugging, coupled with not repowering the board very often. I can now telnet from Windows. Linux remains an issue, but I'm looking at whether there are any RNDIS driver updates for Ubuntu or something like that. But, for once, I at least have *something* working :)
Re: RNDIS
I guess I can try it on WSL too, but I'll also set up my Linux machine to dual boot 20.04 and 18.04. All part of the "Tim gets to grips with Linux" life experience :) On 21/01/2022 16:30, Alan Carvalho de Assis wrote: Hi Tim, did you try other Linux distro? Maybe it could be some incompatibility in recent Linux kernel. I suggest you to test on an old Linux distro (i.e. Ubuntu 18.04 LTS) just to double check. BR, Alan On 1/21/22, Tim wrote: Windows now working properly but not Linux. My board can be powered via the USB and I think it all got confused as I had been leaving the USB cable connected, coupled with not flashing code but using JTAG download for debugging, coupled with not repowering the board very often. I can now telnet from Windows. Linux remains an issue, but I'm looking at whether there are any RNDIS driver updates for Ubuntu or something like that. But, for once, I at least have *something* working :)
Re: RNDIS
Nope, doesn't show. So RNDIS is not working right on my board. What a surprise! On 20/01/2022 19:30, Alan Carvalho de Assis wrote: Exactly, knowing Unix/Linux makes your live easier with NuttX. Using "ip list" (or ifconfig) on Linux should display the new USB RNDIS interface. BR, Alan
Re: RNDIS
At home now, but don't recall USB settings of any sort there, just the wired Ethernet adapter of my machine. I set that to the same subnet but that's irrelevant. ifconfig on the Linux machine didn't show a USB adapter, from memory. I'll have to hunt around for USB adapter settings - they're probably there somewhere!! Or Linux is not detecting the RNDIS adapter connection perhaps. Is there an RNDIS equivalent of "msconn"? My Linux abilities are on a par with my NuttX abilities...very very bad! Which is the lesson I'm learning the very hard way...NuttX is extremely hard if you don't know Linux :( On 20/01/2022 18:08, Alan Carvalho de Assis wrote: Hi Tim, You we welcome! Are your Linux usb interface on this 10.0.0.x range as well? Is they are not in the same network class it will not work. BR, Alan On 1/20/22, Tim wrote: Following suggestions relating to FAT/MSD/USB I have been playing with RNDIS following the NuttX Channel video by Alan C. de Assis (thank you Alan - only just found all of your videos!!). It all builds OK and ifconfig suggests all is good: nsh> ifconfig lo Link encap:Local Loopback at UP inet addr:127.0.0.1 DRaddr:127.0.0.1 Mask:255.0.0.0 eth0Link encap:Ethernet HWaddr e0:de:00:ad:be:ef at UP inet addr:10.0.0.2 DRaddr:10.0.0.1 Mask:255.255.255.0 But Linux (Ubuntu 20.04) doesn't "see" it and I can't ping it. Connecting to Windows just results in loads of error messages in nsh to do with unrecognised rndis messages. Leave that for another day. If I try and do a local ping it suggests there's an error with sockets, or ping? nsh> ping 127.0.0.1 psock_socket: ERROR: socket address family unsupported: 2 socket: ERROR: psock_socket() failed: -106 ERROR: socket() failed: 106 nsh> 106 is endpoint already connected; it's the same whether the USB is connected to the Linux machine or not. As usual, any suggestions welcomed!!
Alternatives to FAT for msd
FAT seems broken for NOR flash devices. Spent days getting nowhere. Since FAT and flash devices don't really play well together anyway (already found s512 erases a flash sector at least 4 times when writing a cluster), so I'm wondering, in parallel, if NuttX has other tricks up its sleeve that might achieve the same end? I want t: - write to the flash, for logging, from the app running on the board. This can be done with any FS - or raw - as far as I'm concerned. Not the issue. - an external PC (ideally Linux, Windows and MAC) needs to be able "see" the data via USB (msd) and read/write to the memory (log data, config files, audio files, etc). Hence FAT. With a flash size of between 32 and 128Mbyte, I don't think a ramdisk formatted as FAT holding a copy of the flash data is really the way to go (board only has 64Mbyte RAM anyway). I'm guessing I'll have to keep up the battle - that NuttX is winning - of FAT vs. NOR flash until the bitter end, but if anyone does have other ideas I'm listening!
Re: USB MSD problem
On 22/12/2021 15:55, Alan Carvalho de Assis wrote This is why I always suggest to people getting started to NuttX to create some blogs post to document their progress and discoveries, it will pave the new to all new users. If I want to share what I'm doing with the details of the project etc, where might you suggest I do this?
Re: USB MSD problem
This is a custom board (SAMA5D27-D5M). I suspect what has happened is that multiple "messing around" with configs has broken something basic. To add insult to injury I have messed it all up so badly that the apps directory won't compile in properly either now. I will take your advice and return to basics. I'll start with a clean config based on a similar board and ignore all my new stuff to get the basics working. I will also make the move to latest NuttX and get to grips with GitHub upstream repos so I can better keep up with latest. So, now I break for Christmas and New Year, and will start again in January with a clear head...maybe! I REALLY appreciate your help, Alan...have a good Christmas/New Year...and, sorry, but I'll be back LOL. On 22/12/2021 17:49, Alan Carvalho de Assis wrote: Exactly, something is changing the memory layout and forcing the error to happen. I can try duplicate it later, but I think it could be specific for your board configuration. What board/MCU are you using? BR, Alan On 12/22/21, Tim wrote: Usb_msc_main.c If I add a "return OK" as the first line of main, msconn runs and returns. If I put a printf statement before it, I get a crash. If I do the same in an example app I've written, it is fine. If I put a breakpoint at the printf statement and step over it, into there it gets to "void exit(int status)", then nxtask_exithook(tcb, status, false), then group_leave(tcb). This is crazy...I just don't get this - surely a built in system app should not be crashing like this!!!
Re: FUSB302
On 01/12/2021 18:08, Nathan Hartman wrote: On Wed, Dec 1, 2021 at 11:29 AM Tim wrote: OK, thanks - should have thought to check for any updates - sorry. Yes, still got the 10.1 tree I think it is, from 7 or 8 months. Will need to do whatever I need to do to get the latest but not a priority right now: GitHub still scares me! You can download the 10.2 release which was just released a week ago [1]. [1]https://nuttx.apache.org/download/ Cheers, Nathan Downloading or whatever isn't the issue (I use GitHub desktop) - its the fact that I forked the master NuttX repo and then created a new branch to work on the porting and am not sure - yet - how to manage the bidirectional workflow of "pulling" my own changes back to my own fork, let alone pulling the upstream main repo back to my fork and merging it all - and then doing PRs to get my new stuff potentially incorporated. I'm sure it's just a case of reading and learning really, but I'm concentrating on getting the many new drivers I need written and tested, bugs and missing stuff sorted on existing drivers and chip support, and I haven't even started the actual app. yet. Feel a bit daunted at times!!
Re: Custom audio capabilities
On 20/11/2021 13:40, TimH wrote: Hi, I'm adding arch support for the sama5d2 Class D audio peripheral. This has bass cut/boost and treble cut/boost capabilities which don't fit (as best as I can tell) with the current set of audio driver capabilities and are, quite probably, unique to this device and not applicable to others (right now at least). I don't think this a case where custom board_ioctl commands are relevant as it is chip specific not board specific. This could be a case of I'm the only one who ever wants to expose this so I could go down that route but assuming it's not technically the right approach, what is, please? Thanks, Tim. Since "Feature Unit" controls has run out of bit positions for anything new, how about I add the new sama5d2 boost/cut modes into the Processing Unit category? Not a great fit but perhaps acceptable?
Custom audio capabilities
Hi, I'm adding arch support for the sama5d2 Class D audio peripheral. This has bass cut/boost and treble cut/boost capabilities which don't fit (as best as I can tell) with the current set of audio driver capabilities and are, quite probably, unique to this device and not applicable to others (right now at least). I don't think this a case where custom board_ioctl commands are relevant as it is chip specific not board specific. This could be a case of I'm the only one who ever wants to expose this so I could go down that route but assuming it's not technically the right approach, what is, please? Thanks, Tim.
Re: sama5d27 UPLL
Hi Alan, Thanks for the suggestion - I have GDB and J-Link and am using VS Code as my IDE, which does have some "watch" limitations it seems :( But I have found I was wrong about it being NuttX that's changing the SFR register. It seems that U-boot doesn't set it despite being configured for the 24MHz crystal I'm using. Some research suggests it will only set the register in relation to USB (the usual reason for wanting the 480MHz PLL to work) which is a shortcoming as getting a clock that is an integer multiple of 8MHz for 1Mbit CANbus from the usual 164MHz MCLK for this processor is a pain! I will look to sorting U-boot config to get this to work, or may just swap to a 12MHz crystal as used on the SAMA5D2 boards - not sure why the eval board for the SAMA5D27 changed to using a 24MMhz crystal for no good reason! As always, thanks for taking the time to assist. Regards, Tim. On 09/07/2021 17:30, Alan Carvalho de Assis wrote: Hi Tim, I don't know about the internal clock of SAMA5D27, but maybe some other configuration is changing the SFR. Do you have GDB working on your system? Maybe you can try to use watchpoint at this register position, see here: https://acassis.wordpress.com/2015/07/07/using-watchpoints-in-the-gdb-to-verify-register-access/ I hope it help you to discovery what is going on. BR, Alan On 7/9/21, Tim wrote: Hi, Making slow progress getting MCAN sorted properly on my custom sama5d27 board and when clocking it from the "UPLL" clokc (an internal PLL used to generate a 480MHz clock for the USB interfaces, and a useful clock for higher speed CAN setups) I found that the CAN baud rate was out. This is because there is a special function register (SFR) that has to be set to reflect the crystal frequency used. This is correctly set by the AT91 bootloader and/or Uboot (I can read it at the start of the bringup code OK) but somewhere it is being changed to the wrong value again and I can't find where - a grep for the relevant SFR register in all of the nuttx code doesn't reveal anything (it only exists in my code or the sam_sfr header file as far as I can see) I have done a quick fix by re-writing the correct value in my bringup code but that isn't the right way to sort this. Any suggestions of how to find where/why/how this is being changed? Thanks, Tim.
Re: [Discuss] Migrate the build system to CMake
My view on this...bit of a ramble. I'm new to Nuttx, and have a new/custom board I'm porting it to. Nuttx didn't play nicely/easily with either Windows or MAC for me and I eventually went to Linux; and have no regrets as life is so much easier as result. A full build takes no more than 10seconds compared to minutes using WSL and a complete fail on mac. The current makefile system is a bit clunky, but once you understand it - and it really doesn't take long to do so - it works fine and is similar to the methodology I've used for years and years and years. I have no experience of Cmake so my initial reaction is "oh no, just got to grips with all of this, why would I want to jump ship to some other way of doing it". If Cmake could have shortened the process of getting a new board ported and NuttX running, and made the whole experience better/easier/quicker then it would have been a good thing I would think. But is the point, perhaps, that if you have a project/build that's working for a given board there is little incentive to rework your enironment just to suit a new methodology? I think that may point towards concentrating effort on new and/or very popular boards, but leave others alone (for now). I suspect - for example - that I am one of very few using sama5d2, given the number of errors I've found (!), so is it really worth the effort to change that arch to use Cmake? It may be though! But, as I said, I don't know Cmake so it's very very difficult to give a meaningful opinion. My final thought is "if it ain't broke, don't fix it". Is the current system actually broken?
Re: Memory locations
On 07/06/2021 17:22, Tim wrote: This is probably not really a NuttX question per se, but it relates to getting the MCAN interface for a sama5d2 to work properly. And you are all such knowledgable and helpful people :) The MCAN controllers assume the base address of the message ram is at 0x20+offsets. 0x20 is the internal SRAM whereas everything else is in DDR from 0x200. I will readily confess that this side of programming is my very weakest!! I will, I believe, need to declare - place - MCAN related structures such that they (or at least some elements of them) are in SRAM. Is that possible? "CONFIG_MM_REGIONS" related maybe? What does the internal SRAM get used for as the system.map file lists nothing there at all. Or have I got it wrong and this isn't the way to sort it - perhaps the processor DMA "matrix" stuff (hope not - don't understand the datasheet section on this at all!)? Thanks! Tim. That's some excellent guidance, thanks Nathan - lots of reading/learning needed! I have started playing with the .ld file but haven't seen the message buffer address change as yet; need to learn more about the syntax and/or making sure the build picks up the changes to the board's .ld file. Then I can worry about things overlapping. -- JT Innovations Ltd., Unit 23 Tradecroft Industrial Estate, Wide Street, Portland, Dorset, DT5 2LN, UK Company number 7619086 VAT Registration GB 111 7906 35
Re: Custom board PIO - philosophy
Thanks Alan, I'd forgotten that there's a board-specific sam_mcan.c file (I'm so bogged down creating the correct arch. mcan driver for this processor; based on the one for the samv7)! I will put my custom stuff in there. Obvious now you made me think about it :) On 30/05/2021 11:42, Alan Carvalho de Assis wrote: Hi Tim, Normally an arch CAN driver doesn't have this enable pin or other similar GPIO. But if you plan to do it for your custom driver, it is better to use a generic solution, like the CAN TX/RX pins do. Also UART, SPI and I2C uses this solution. Creating an #ifdef for each board inside your driver is not a good/right solution. You can use some GPIO_CANXYZ_EN_PIN in your driver and inside your board you #define GPIO_CANXYZ_EN_PIN GPIO_PIN_Px BR, Alan On Sunday, May 30, 2021, TimH wrote: Hi all, My custom board has a number of GPIOs that are related to more generic drivers. For example, the CAN implementation uses an arch. CAN driver appropriate for the processor, but has custom GPOs associated to enable/disable the CAN transceivers, and to enable/disable termination resistors. Is the right/best method to extend the CAN driver with these - but perhaps #ifdef them so they only relate to this board (which may end up being submitted to the repositiry - haven't decided yet!) - or handle them in some other way? I hope those with lots of experience of Nuttx can offer an opinion? Thanks, Tim. -- JT Innovations Ltd., Unit 23 Tradecroft Industrial Estate, Wide Street, Portland, Dorset, DT5 2LN, UK Company number 7619086 VAT Registration GB 111 7906 35
Custom board PIO - philosophy
Hi all, My custom board has a number of GPIOs that are related to more generic drivers. For example, the CAN implementation uses an arch. CAN driver appropriate for the processor, but has custom GPOs associated to enable/disable the CAN transceivers, and to enable/disable termination resistors. Is the right/best method to extend the CAN driver with these - but perhaps #ifdef them so they only relate to this board (which may end up being submitted to the repositiry - haven't decided yet!) - or handle them in some other way? I hope those with lots of experience of Nuttx can offer an opinion? Thanks, Tim.
