Re: [Breaking change] Echo character by serial driver
Hi, In my opinion we should keep the memory usage as low as possible +1 for menu config Best Regards Alin On Sat, 11 Mar 2023, 05:13 Xiang Xiao, wrote: > On Sat, Mar 11, 2023 at 9:51 AM Gregory Nutt wrote: > > > > > On 3/10/2023 7:44 PM, Huang Qi wrote: > > > >> The ECHO behavior can be disabled ONLY if TERMIOS are enabled. > > > >> TERIMIOS is now required by POSIX and, further, if TERMIOS is not > > > >> system, many features are now broken. Like hiding the password > when > > > >> logging into NSH. > > > > Yes maybe we should select TERMIOS if some features really need it ? > > > Most apps don't need it, only > > > > termcurse/nsh login rely on it now in my known. > > > > > > > The those Kconfig files should select TERMIOS_SERIAL, right? > > > > > > Yes, this is a chioce, or we can make TERMIOS enabled forcely, but > > > will cause a extra 1KB overhead for all target. > > > > > That 1Kb number seems large to me. Most of that is in the lower-half, > > UART driver, right? If so then the size would vary dramatically from > > chip-to-chip. > > > > > Terminal setting include two part: > >1. Hardware related setting(e.g. baud rate, parity check etc) >2. Software related setting(e.g. echo, \r\n<->\n etc) > > The major code size increase comes from the first item, but it's > unfortunate that TERMIOS_SERIAL controls both settings. > So, here is my suggestion: > >1. TERMIOS_SERIAL only control the hardware related setting >2. The software setting is always enabled >3. isconsole decide the initial software setting > - isconsole equals false, disable all special process > - isconsole equals true, enable \r\n<->\n, echo and crtl+c handling >4. terminal aware function or application change the terminal to raw >mode and restore to the original setting before exit >5. other normal application could assume that the terminal do all >special process > > This could achieve POSIX compliance with the minimal cost. > > > > > > As a percentage growth, I suppose even 1Kb is not so large. Probably > > less then 2% > > >
Re: [Breaking change] Echo character by serial driver
Agree! +1 On 3/11/23, Alin Jerpelea wrote: > Hi, > > In my opinion we should keep the memory usage as low as possible > +1 for menu config > > Best Regards > Alin > > On Sat, 11 Mar 2023, 05:13 Xiang Xiao, wrote: > >> On Sat, Mar 11, 2023 at 9:51 AM Gregory Nutt wrote: >> >> > >> > On 3/10/2023 7:44 PM, Huang Qi wrote: >> > > >> The ECHO behavior can be disabled ONLY if TERMIOS are enabled. >> > > >> TERIMIOS is now required by POSIX and, further, if TERMIOS is not >> > > >> system, many features are now broken. Like hiding the password >> when >> > > >> logging into NSH. >> > > > Yes maybe we should select TERMIOS if some features really need it >> > > > ? >> > > Most apps don't need it, only >> > > > termcurse/nsh login rely on it now in my known. >> > > >> > > > The those Kconfig files should select TERMIOS_SERIAL, right? >> > > >> > > Yes, this is a chioce, or we can make TERMIOS enabled forcely, but >> > > will cause a extra 1KB overhead for all target. >> > > >> > That 1Kb number seems large to me. Most of that is in the lower-half, >> > UART driver, right? If so then the size would vary dramatically from >> > chip-to-chip. >> > >> > >> Terminal setting include two part: >> >>1. Hardware related setting(e.g. baud rate, parity check etc) >>2. Software related setting(e.g. echo, \r\n<->\n etc) >> >> The major code size increase comes from the first item, but it's >> unfortunate that TERMIOS_SERIAL controls both settings. >> So, here is my suggestion: >> >>1. TERMIOS_SERIAL only control the hardware related setting >>2. The software setting is always enabled >>3. isconsole decide the initial software setting >> - isconsole equals false, disable all special process >> - isconsole equals true, enable \r\n<->\n, echo and crtl+c handling >>4. terminal aware function or application change the terminal to raw >>mode and restore to the original setting before exit >>5. other normal application could assume that the terminal do all >>special process >> >> This could achieve POSIX compliance with the minimal cost. >> >> >> > >> > As a percentage growth, I suppose even 1Kb is not so large. Probably >> > less then 2% >> > >> >
Sensor implementation
I submitted a PR for a driver for the Broadcom APDS-9922 ambient light and proximity sensor, written with what one might call the "traditional" method of setting up the device via ioctl, then reading data when available according to the device setup, via poll notify. The reviewer (Hi Alan - I'm not complaining!!) has suggested it perhaps ought to use the "new" sensor methodology with a sensor_lower_half_s etc. Looking at sensors that use this I can't see any that have the range of set-up options of this device and are just "there", in the main apart from calibration, for example. Nor any NuttX documentation I can see? Is this following a Linux methodology, like the power devices now do? When I did a power supply device drive I was pointed in the direction of Linux documentation that (after much reading and cogitation) helped explain what NuttX was essentially emulating and, with the addition of some more members to the regulator_desc_s struct it was then fine and I wrote it that way. I am still not convinced that this ALS/Proximity sensor necessarily fits the "new" sensor methodology but if someone can point me in the direction of relevant documentation I will gladly take a look. Thx, TimH
Re: NuttX Hardware
1. boxes are safest to transport electronics. even boxes of boxes. imagine someone will jump over the package. bags are not good :-) 2. you can mark shipment a "gift: old collectioner electronics boards" and value $10 total it will be the tax free at the risk of loosing everything valuable (maybe some insurance is possible but then real value must be known and provided). 3. maybe cheapest local delivery of all bundle to Brazil/ USA, then local arrangement + redistribution would be least painful logistics? 4. for international delivery FedEx is the best as they calculate all taxes and customs upon order so there are no additional expenses and surprises upon delivery (tested with USA Taiwan Singapore Europe UK). -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: [Breaking change] Echo character by serial driver
+1 :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info On Sat, Mar 11, 2023, 12:54 Alin Jerpelea: > Hi, > > In my opinion we should keep the memory usage as low as possible > +1 for menu config > > Best Regards > Alin >
Re: 答复: 答复: 答复: [External Mail]Re: [Breaking change] Echo character by serial driver
Please consult Unix manual and source code (for instance any of the BSD). Linux was never a reference in Unix world, it was about to mimic Unix, but was not even self-compatible. Not a good reference point. See how big mess it introduced in current drivers implementation (i.e. drm kms) and their propagation to other OS. Is this similar situation here? Device driver should not provide any additional processing / silent rewrite of data, just provide raw data, that is then processed by the application. Driver may be configured by ioctl/sysclt, to enable additional / specific behavior (i.e. debug, buffer size, latency, etc), so the user always knows exactly what the driver does. I am pro Greg approach, so driver is always simple and generic, everything else is up to application. This is the Unix way and you will know how most things work, because they all work the same generic standardized way, as simple as possible, nothing else happens "in the background unnoticed". If a specific device needs a specific handling by a generic driver, then "quirks" may be used. That explicitly mark "specific" behavior for a given device (and only this device). -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: 答复: 答复: 答复: [External Mail]Re: [Breaking change] Echo character by serial driver
It is true that Linux is not fully POSIX compliant (e.g., https://linuxhint.com/is_linux_posix_compliant/). But Linux folk have gone to a lot of work to clean up a Linux specification with the LSB: https://refspecs.linuxfoundation.org/lsb.shtml and that generally adopts POSIX standards. We use the the term "Linux" loosely here. POSIX specifies the interface between applications and an operating system. However, the user application never interacts directly with Linux which resides in kernel space but rather with various user space libraries like libc that, in turn, interface with Linux via call gates (uncontrolled and not not prototype-able C interfaces). So more correctly, it is the GNU libraries that determine the user application interface. Calling this Gnu/Linux is more accurate but that phrase manages to piss off everyone. NuttX has evolved over the years in regard to what it uses as its standards base. 1. Originally, in the beginning, NuttX was a very tiny OS (think FreeRTOS or ChibiOS) with a very limited user interface but drawing primarily from POSIX interface definitions. Since NuttX provides both the OS and the libc, we can safely call this interface NuttX. 2. Later the project adopted OpenGroup.org as the standards base. OpenGroup.org is a good clean POSIX definition and no user interface could come in that was not specified by OpenGroup.org. OpenGroup.org is THE Unix spcification. Documentation (like the Inviolables.md) still claim that OpenGroup.org is the standards base. 3. Most NuttX users are also Linux users so there has always been pressure to follow Linux interface definitions (the LSB). After Xiaomi adopted NuttX, the pressure to adopt the LSB as the specification base (NSB?) was irresistible. From my point of view, I am just happy that we can point to specifications and say, "NuttX is compliant with that" -- whether that is OpenGroup.org or the LSB. I have led technical teams for several decades and one thing I have learned is that everyone does thing differently and as a technical leader, you have to stand back and simply ask does the propose solution work? Does the proposed solution meet the need? If yes, then you just have to accept the solution and let the rest go as personal preference. Unless you are the BDFL as I was for so many years. Also, the TERMIOS changes are POSIX and compliant with the LSB, OpenGroup.org and, I am sure, BSD. A bunch of caveats. - Use of the term POSIX compliance OS in regard to any OS that is not POSIX certified is a trademark violation, but people say this all of the time. - http://get.posixcertified.ieee.org/certification_guide.html - POSIX is a trademark of the IEEE - Unix is a trademark of OpenGroup.org - Linux is a trademark of Linux Torvalds On 3/11/2023 12:08 PM, Tomek CEDRO wrote: Please consult Unix manual and source code (for instance any of the BSD). Linux was never a reference in Unix world, it was about to mimic Unix, but was not even self-compatible. Not a good reference point. See how big mess it introduced in current drivers implementation (i.e. drm kms) and their propagation to other OS. Is this similar situation here? Device driver should not provide any additional processing / silent rewrite of data, just provide raw data, that is then processed by the application. Driver may be configured by ioctl/sysclt, to enable additional / specific behavior (i.e. debug, buffer size, latency, etc), so the user always knows exactly what the driver does. I am pro Greg approach, so driver is always simple and generic, everything else is up to application. This is the Unix way and you will know how most things work, because they all work the same generic standardized way, as simple as possible, nothing else happens "in the background unnoticed". If a specific device needs a specific handling by a generic driver, then "quirks" may be used. That explicitly mark "specific" behavior for a given device (and only this device). -- CeDeROM, SQ7MHZ,http://www.tomek.cedro.info
Re: 答复: 答复: 答复: [External Mail]Re: [Breaking change] Echo character by serial driver
On Sun, Mar 12, 2023 at 2:09 AM Tomek CEDRO wrote: > Please consult Unix manual and source code (for instance any of the BSD). > Linux was never a reference in Unix world, it was about to mimic Unix, but > was not even self-compatible. Not a good reference point. See how big mess > it introduced in current drivers implementation (i.e. drm kms) and their > propagation to other OS. Is this similar situation here? > > This change isn't specific to Linux: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/termios.h.html > Device driver should not provide any additional processing / silent rewrite > of data, just provide raw data, that is then processed by the application. > Driver may be configured by ioctl/sysclt, to enable additional / specific > behavior (i.e. debug, buffer size, latency, etc), so the user always knows > exactly what the driver does. > > I am pro Greg approach, so driver is always simple and generic, everything > else is up to application. This is the Unix way and you will know how most > things work, because they all work the same generic standardized way, as > simple as possible, nothing else happens "in the background unnoticed". > > If a specific device needs a specific handling by a generic driver, then > "quirks" may be used. That explicitly mark "specific" behavior for a given > device (and only this device). > > All changes are controlled by ioctl and specified by standard, please read the spec: https://pubs.opengroup.org/onlinepubs/9699919799/functions/tcsetattr.html https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/termios.h.html > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >
Re: Sensor implementation
On Sun, Mar 12, 2023 at 12:12 AM Tim Hardisty wrote: > I submitted a PR for a driver for the Broadcom APDS-9922 ambient light and > proximity sensor, written with what one might call the "traditional" > method of setting up the device via ioctl, then reading data when available > according to the device setup, via poll notify. > > The reviewer (Hi Alan - I'm not complaining!!) has suggested it perhaps > ought to use the "new" sensor methodology with a sensor_lower_half_s etc. > > Looking at sensors that use this I can't see any that have the range of > set-up options of this device and are just "there", in the main apart from > calibration, for example. Nor any NuttX documentation I can see? > > Is this following a Linux methodology, like the power devices now do? When > I did a power supply device drive I was pointed in the direction of Linux > documentation that (after much reading and cogitation) helped explain what > NuttX was essentially emulating and, with the addition of some more members > to the regulator_desc_s struct it was then fine and I wrote it that way. > > I am still not convinced that this ALS/Proximity sensor necessarily fits > the "new" sensor methodology but if someone can point me in the direction > of relevant documentation I will gladly take a look. > > Here is an intro video: https://www.youtube.com/watch?v=ESpAE6wqy9o > Thx, > > TimH > > >
Re: Sensor implementation
On 3/11/23, Xiang Xiao wrote: > On Sun, Mar 12, 2023 at 12:12 AM Tim Hardisty wrote: > >> I submitted a PR for a driver for the Broadcom APDS-9922 ambient light >> and >> proximity sensor, written with what one might call the "traditional" >> method of setting up the device via ioctl, then reading data when >> available >> according to the device setup, via poll notify. >> >> The reviewer (Hi Alan - I'm not complaining!!) has suggested it perhaps >> ought to use the "new" sensor methodology with a sensor_lower_half_s etc. >> >> Looking at sensors that use this I can't see any that have the range of >> set-up options of this device and are just "there", in the main apart >> from >> calibration, for example. Nor any NuttX documentation I can see? >> >> Is this following a Linux methodology, like the power devices now do? >> When >> I did a power supply device drive I was pointed in the direction of Linux >> documentation that (after much reading and cogitation) helped explain >> what >> NuttX was essentially emulating and, with the addition of some more >> members >> to the regulator_desc_s struct it was then fine and I wrote it that way. >> >> I am still not convinced that this ALS/Proximity sensor necessarily fits >> the "new" sensor methodology but if someone can point me in the direction >> of relevant documentation I will gladly take a look. >> >> > Here is an intro video: https://www.youtube.com/watch?v=ESpAE6wqy9o > Thank you Xiang! Since this subsystem is more complex than original char driver sensor, is there plans for Documentation ? Tim, I suggest you to take a look at LTR-308 sensoe (ltr308.c) is it also an ALS. So you can use it as reference. BR, Alan
Re: [Breaking change] Echo character by serial driver
Generally I like to lean towards low flash footprint. However I accept the arguments in favor of POSIX compliance. How to find a balance? I think Xiang Xiao's idea makes sense: always enable the parts that have a minimal impact on flash footprint, while leaving the heavier parts conditional on a Kconfig. So we get the best of both worlds. So yes, we will still have Kconfig and low footprint:-) Cheers Nathan On Sat, Mar 11, 2023 at 12:38 PM Tomek CEDRO wrote: > +1 :-) > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > On Sat, Mar 11, 2023, 12:54 Alin Jerpelea: > > > Hi, > > > > In my opinion we should keep the memory usage as low as possible > > +1 for menu config > > > > Best Regards > > Alin > > > > >
Re: 答复: 答复: 答复: [External Mail]Re: [Breaking change] Echo character by serial driver
ACK! :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info On Sat, Mar 11, 2023, 23:53 Xiang Xiao wrote: > On Sun, Mar 12, 2023 at 2:09 AM Tomek CEDRO wrote: > > > Please consult Unix manual and source code (for instance any of the BSD). > > Linux was never a reference in Unix world, it was about to mimic Unix, > but > > was not even self-compatible. Not a good reference point. See how big > mess > > it introduced in current drivers implementation (i.e. drm kms) and their > > propagation to other OS. Is this similar situation here? > > > > > This change isn't specific to Linux: > https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/termios.h.html > > > > Device driver should not provide any additional processing / silent > rewrite > > of data, just provide raw data, that is then processed by the > application. > > Driver may be configured by ioctl/sysclt, to enable additional / specific > > behavior (i.e. debug, buffer size, latency, etc), so the user always > knows > > exactly what the driver does. > > > > I am pro Greg approach, so driver is always simple and generic, > everything > > else is up to application. This is the Unix way and you will know how > most > > things work, because they all work the same generic standardized way, as > > simple as possible, nothing else happens "in the background unnoticed". > > > > If a specific device needs a specific handling by a generic driver, then > > "quirks" may be used. That explicitly mark "specific" behavior for a > given > > device (and only this device). > > > > > All changes are controlled by ioctl and specified by standard, please read > the spec: > https://pubs.opengroup.org/onlinepubs/9699919799/functions/tcsetattr.html > https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/termios.h.html > > > > -- > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > >
