Re: Access GPIO pins over Lua
Hi, with Luajit, one could use FFI to access NuttX GPIO functions directly. But I am afraid that Luajit is currently available only for CM7. On the other hand, one can write standard Lua extension in C and use it with plain Lua to access GPIOs. There are numerous examples of how to do it on internet. Regards, Jernej On Fri, Mar 15, 2024 at 5:20 PM Michal Lenc wrote: > Hello, > > has anyone tried accessing GPIO pins over Lua? I have tried LED example > presented at NuttX workshop a year or two ago and userled driver is > working fine, but using the same code on GPIO registered pin fails > (assert on open). I suppose io.open is implemented only for userleds and > does not work for GPIO? Thanks. > > Best regards, > > Michal Lenc > >
Touchscreen calibration
My board uses built-in SAMA5 TSD peripheral to interface with a resistive touchscreen on a 5" TFT. Early on I implemented (and had merged) an ioctl to allow the low level driver to scale the x/y data to match the display resolution but I am now finding it actually needs a multipoint calibration to get the accuracy required. The maths for this is well documented and I found an MIT-licensed calibration solution for LVGL - which is what I'm using anyway. It works, but is not generic, and is mixing Apache and MIT licenses of course. I was thinking that it might be a good idea to proffer a generic solution for this in NuttX but found: 1. NXWM already has this in principle (not tried it to be fair) 2. The sam tsd driver is not a generic driver, as such, so x/y data does not pass through an appropriate upper-half layer where calibration data might best live, and be used by any low level driver managing tsd interfaces (like, I think, the off-chip tsd controllers that are supported use) My first thought is whether it might be feasible to run the NXWM system - to gain access to touchscreen calibration routines when needed - and then handover to lvgl. But it doesn't "feel" right but perhaps someone has done this? Otherwise would it be a better idea to rework the sam tsd to pass through a/the generic upper half driver where calibration data can live, but leave it to the user app to implement the actual mechanism (graphical screens, but not tied to lvgl etc) to gather the required coefficients. Thoughts?
GhostRace (CVE-2024-2193) is a variation of Spectre v1 (CVE-2017-5753)
https://thehackernews.com/2024/03/ghostrace-new-data-leak-vulnerability.html Is NuttX affected too? -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: Rust in the OS?
On 3/15/2024 11:10 PM, Saurav Pal wrote: All in all, I am *against* Rust being introduced in the kernel. However, I am fine with the language being in the very leaf nodes. Like some drivers, userspace applications, or userspace filesystems (FUSE)... especially those that only interact with the kernel over a fixed interface, and are not depended on by anything other than its own subprogram in the kernel. That was my initial impression as well. Certainly no one wants to see Rust scattered all over the OS like explosive diarrhea. But I have had time to think more about it. I think that a better use of effort would be to re-implement Rust OS drivers in C than to implement Rust environmental support for smaller leaf functions. A C re-implementation would be a welcomed by all, would not add any OS build complexity or design complexity, and would only require one toolchain and debugger (for the OS), and no changes to the OS build system. As a bonus, the re-implemented C driver could probably be considered an original work and more easily incorporated as a true part of the OS* *Disclaimer: I am not an attorney.
