Re: faq: context vs global variables
Hello Tomek, you may also have a look here: https://github.com/fjpanag/code_for_nuttx/tree/main/settings On Sun, Apr 30, 2023 at 3:12 PM Alan C. Assis wrote: > On 4/30/23, Tomek CEDRO wrote: > > On Sat, Apr 29, 2023 at 10:16 PM Alan C. Assis wrote: > >> Take a look at apps/system/cfgdata it could or could not be what you > >> are looking for. > >> Also take a look at ReleaseNotes for more details. > > > > Wow thanks for the cfgdata hint Alan! :-) > > > > -- > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > > > You are welcome! I think this is another "hidden" feature that needs > some documentation. > > BR, > > Alan >
imxrt interrupt locking
I am developing a driver which is processing peripheral interrupts every 6.4 microseconds and every 16th interrupt calling notify function from HP work queue. But scheduling workqueue does lock interrupts (through critical section) up to 20us sometimes, causing my peripheral missing interrupts. The same thing occurs if calling the notify function with nxsem_post directly from ISR. DMA is not an option. I am working with the NXP RT1064 board. How can I wake the read function without locking interrupts? Thanks.
Re: imxrt interrupt locking
On Thu, May 4, 2023 at 5:46 AM Jernej Turnsek wrote: > I am developing a driver which is processing peripheral interrupts every > 6.4 microseconds and every 16th interrupt calling notify function from HP > work queue. But scheduling workqueue does lock interrupts (through critical > section) up to 20us sometimes, causing my peripheral missing interrupts. > The same thing occurs if calling the notify function with nxsem_post > directly from ISR. DMA is not an option. I am working with the NXP RT1064 > board. How can I wake the read function without locking interrupts? Thanks. > That chip is Arm Cortex M7. I think zero-latency interrupts are supported on that. If so, you could try to use that to service the 6.4us interrupt. Zero-latency interrupts cannot use OS services because they exist outside the OS. Therefore, to rendezvous with the hp queue, each 16th interrupt, trigger an otherwise unused interrupt vector, which will be serviced by a "normal" ISR, which can in turn hand off the data to the hp queue. There's a page about this somewhere... Nathan
Re: imxrt interrupt locking
On Thu, May 4, 2023 at 7:11 AM Nathan Hartman wrote: > On Thu, May 4, 2023 at 5:46 AM Jernej Turnsek > wrote: > >> I am developing a driver which is processing peripheral interrupts every >> 6.4 microseconds and every 16th interrupt calling notify function from HP >> work queue. But scheduling workqueue does lock interrupts (through >> critical >> section) up to 20us sometimes, causing my peripheral missing interrupts. >> The same thing occurs if calling the notify function with nxsem_post >> directly from ISR. DMA is not an option. I am working with the NXP RT1064 >> board. How can I wake the read function without locking interrupts? >> Thanks. >> > That chip is Arm Cortex M7. I think zero-latency interrupts are supported > on that. If so, you could try to use that to service the 6.4us interrupt. > > Zero-latency interrupts cannot use OS services because they exist outside > the OS. Therefore, to rendezvous with the hp queue, each 16th interrupt, > trigger an otherwise unused interrupt vector, which will be serviced by a > "normal" ISR, which can in turn hand off the data to the hp queue. > > There's a page about this somewhere... > I found it in the old wiki: https://cwiki.apache.org/confluence/display/NUTTX/High+Performance%2C+Zero+Latency+Interrupts I don't see it in the repo Documentation. This is an important thing that should be in the repo. Cheers Nathan
Re: Article: NuttX for PinePhone: Phone Calls and Text Messages
On Thu, May 4, 2023 at 8:12 AM alin.jerpe...@sony.com wrote: > This is great progress ! > With an UI will be easier to handle Some important architectural decisions will have to take place when designing the UI part for whole system and userland applications and their interoperability (including external application store or something like that in future). I have been fighting with "mobile applications" for Android and iOS for years and there is no good stable and coherent solution right now.. and probably there will never be as these enforced changes seems to be part of the design.. in fact it all seems a "moving disaster" for me, aka "catch the rabbit" game. I worked with native tools (Android Studio and XCode), cross platform JavaScript (ReactNative, Vue), recently Python (Kivy). I also at some point considered using LVGL on SDL2 then putting it all together into a mobile application. Recently I even considered compiling whole NuttX + LVGL + SDL and linking into a mobile application, after seeing NuttX + LVGL demo on my desktop. There is still a unavoidable dependency on a mobile platform SDK, NDK, etc, that constantly changes, and it is hard to catch. I hope things will never get that way in NuttX :-) NuttX as independent (mobile) platform seems unavoidable for people that just want simple things working. Maybe even on older hardware that will again provide week or more battery life time :-) We just cannot get ourselves into a "modern mobile world mess" please :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: imxrt interrupt locking
Hi, thanks. Will take a look. On Thu, May 4, 2023 at 1:25 PM Nathan Hartman wrote: > On Thu, May 4, 2023 at 7:11 AM Nathan Hartman > wrote: > > > On Thu, May 4, 2023 at 5:46 AM Jernej Turnsek > > wrote: > > > >> I am developing a driver which is processing peripheral interrupts every > >> 6.4 microseconds and every 16th interrupt calling notify function from > HP > >> work queue. But scheduling workqueue does lock interrupts (through > >> critical > >> section) up to 20us sometimes, causing my peripheral missing interrupts. > >> The same thing occurs if calling the notify function with nxsem_post > >> directly from ISR. DMA is not an option. I am working with the NXP > RT1064 > >> board. How can I wake the read function without locking interrupts? > >> Thanks. > >> > > That chip is Arm Cortex M7. I think zero-latency interrupts are supported > > on that. If so, you could try to use that to service the 6.4us interrupt. > > > > Zero-latency interrupts cannot use OS services because they exist outside > > the OS. Therefore, to rendezvous with the hp queue, each 16th interrupt, > > trigger an otherwise unused interrupt vector, which will be serviced by a > > "normal" ISR, which can in turn hand off the data to the hp queue. > > > > There's a page about this somewhere... > > > > > I found it in the old wiki: > > > https://cwiki.apache.org/confluence/display/NUTTX/High+Performance%2C+Zero+Latency+Interrupts > > I don't see it in the repo Documentation. This is an important thing that > should be in the repo. > > Cheers > Nathan >
Re: Article: NuttX for PinePhone: Phone Calls and Text Messages
On Thu, May 4, 2023 at 7:52 AM Tomek CEDRO wrote: > On Thu, May 4, 2023 at 8:12 AM alin.jerpe...@sony.com wrote: > > This is great progress ! > > With an UI will be easier to handle > > Some important architectural decisions will have to take place when > designing the UI part for whole system and userland applications and > their interoperability (including external application store or > something like that in future). > > I have been fighting with "mobile applications" for Android and iOS > for years and there is no good stable and coherent solution right > now.. and probably there will never be as these enforced changes seems > to be part of the design.. in fact it all seems a "moving disaster" > for me, aka "catch the rabbit" game. > > I worked with native tools (Android Studio and XCode), cross platform > JavaScript (ReactNative, Vue), recently Python (Kivy). I also at some > point considered using LVGL on SDL2 then putting it all together into > a mobile application. Recently I even considered compiling whole NuttX > + LVGL + SDL and linking into a mobile application, after seeing NuttX > + LVGL demo on my desktop. There is still a unavoidable dependency on > a mobile platform SDK, NDK, etc, that constantly changes, and it is > hard to catch. I hope things will never get that way in NuttX :-) > > NuttX as independent (mobile) platform seems unavoidable for people > that just want simple things working. Maybe even on older hardware > that will again provide week or more battery life time :-) > > We just cannot get ourselves into a "modern mobile world mess" please :-) > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > I have seen those fast-moving-target frameworks described as having the "lifecycle of yogurt" in multiple places around the internet. +1 for stability!!! Nathan
Re: Article: NuttX for PinePhone: Phone Calls and Text Messages
On Thu, May 4, 2023 at 7:47 PM Nathan Hartman wrote: > I have seen those fast-moving-target frameworks described as having the > "lifecycle of yogurt" in multiple places around the internet. > > +1 for stability!!! Hahahah I also like and use that term, but it is not fun to work with them :-) :-) In one of my projects where application is supposed to work in shell and graphical mode there are sets of functions/objects that perform operation and those operations can be called from independent modules that provide CLI and GUI access. There are even different GUI frameworks possible to use (i.e. QT, FLTK, etc) by using different ui module of the application, or none, just the CLI. Maybe this could be kind of approach for NuttX Apps that should provide CLI interface by default and optional GUI (i.e. LVGL) when compiled for "NuttX Mobile"..? :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
