Re: LVGL moving to Kconfig, how we could integrated better with them

>From LVGL's point of view, I see no problem with a NuttX managed build if the generated configs are available in "". According to our plan only "" needs to be included in "lv_conf.h" and LVGL will take care to internally translate the KConfig configs to LVGL configs. See my proposal about it her

Re: LVGL moving to Kconfig, how we could integrated better with them

Hi Matias, I’ve checked the current LVGL KConfig in NuttX and it seems up to date but some help messages are quite outdated. I think it’d be awesome to somehow use LVGL’s Kconfig to be sure you always have the latest and official version. I wonder if it’s possible to simply rsource LVGL’s KConfig

Re: LVGL moving to Kconfig, how we could integrated better with them

Hi, Thank you, Alan! I'm looking forward to hearing the opinion and remarks of the NuttX developers. Regards, Gabor Alan Carvalho de Assis ezt írta (időpont: 2020. aug. 26., Sze, 2:22): > Hi Everyone, > > Mr. Gábor Kiss-Vámosi contacted and told me that LVGL is moving to use > Kconfig: > > "A

Re: 答复: 答复: [External Mail]Re: defining a BLE GATT server

Let me clarify one thing: The approach we take is a pure userspace solution, it isn't related to NuttX kernel and no plan to upstream it. That is good to know. Thank you.  I will sleep better tonight. The major difference is where to put L2CAP/HCI code(userspace v.s. kernelspace) and it isn

Re: 答复: [External Mail]Re: defining a BLE GATT server

I'm agreeing with you Greg, anything that comes into Apps or the OS must use the socket API. Then we are in agreement.  I am a mother hen and will defend the OS architecture to the teeth (hmm.. hens.. teeth... sorry about the mixed metaphor). I don't get involved in most code changes.  I

RE: 答复: 答复: [External Mail]Re: defining a BLE GATT server

Let me clarify one thing: The approach we take is a pure userspace solution, it isn't related to NuttX kernel and no plan to upstream it. The major difference is where to put L2CAP/HCI code(userspace v.s. kernelspace) and it isn't too hard to migrate to socket interface once the NuttX kernel has

答复: 答复: [External Mail]Re: defining a BLE GATT server

Hi Greg, Brennan Okay, it is enough, I think we have all spent enough time discussing this issue! I agree that this change will not be upstream, Xiaomi will not give up NuttX's Roadmap, which is also Xiang's long-cherished wish. I will abandon later, Thanks for your precious time. BRs, ___

Re: 答复: [External Mail]Re: defining a BLE GATT server

On Wed, Aug 26, 2020 at 9:56 AM Gregory Nutt wrote: > > Lets try to see how we can move this forward, I'm not fully sure I > > fully understand the implications of what you were saying about the > > packet protocol, but I think it is best that we focus the discussion > > on that in the GitHub issu

Re: 答复: [External Mail]Re: defining a BLE GATT server

On 8/26/2020 10:56 AM, Gregory Nutt wrote: Lets bring this back to a constructive place. An Chao I really appreciate the detailed information that you wrote, while I don't think it will be appropriate to include directly upstream it is still valuable to know how you are trying to use this and

Re: 答复: [External Mail]Re: defining a BLE GATT server

Lets bring this back to a constructive place. An Chao I really appreciate the detailed information that you wrote, while I don't think it will be appropriate to include directly upstream it is still valuable to know how you are trying to use this and it helps us make an informed decision movin

Re: 答复: [External Mail]Re: defining a BLE GATT server

Lets bring this back to a constructive place. An Chao I really appreciate the detailed information that you wrote, while I don't think it will be appropriate to include directly upstream it is still valuable to know how you are trying to use this and it helps us make an informed decision moving fo

Re: 答复: 答复: [External Mail]Re: defining a BLE GATT server

Mr.Greg, I really don't understand why you are so angry, and there are so many verbal attacks. I just share a feasibility. What I expect is discussion and respect, not devaluation. If you don't like it, just say it like others. Yes, I am angry.  I am very pissed off that you completely igno

答复: 答复: [External Mail]Re: defining a BLE GATT server

Mr.Greg, I really don't understand why you are so angry, and there are so many verbal attacks. I just share a feasibility. What I expect is discussion and respect, not devaluation. If you don't like it, just say it like others. BRs, 发件人: Gregory Nutt 发送

Re: 答复: [External Mail]Re: defining a BLE GATT server

What you should do is to coordinate and and cooperate with the NuttX team to get help from the community.  If you chose to go your own way and not discussion or cooperation with the team, then you are on your own.  That code will not come into the repository. If you want to do things correc

Re: 答复: [External Mail]Re: defining a BLE GATT server

As mentioned in the title, this is just an experimental project that needs to discuss further the implementation of the bluetooth stack. The implementation of bt stack in userspace does not conflict with the current architecture, this is just a choice. On the contrary, the complete BLE+MESH s

答复: [External Mail]Re: defining a BLE GATT server

As mentioned in the title, this is just an experimental project that needs to discuss further the implementation of the bluetooth stack. The implementation of bt stack in userspace does not conflict with the current architecture, this is just a choice. On the contrary, the complete BLE+MESH solu

Re: defining a BLE GATT server

I fully agree with this. AF_BLUETOOTH is already in place, but it only implements "BTPROTO_L2CAP" all of the GATT and advertising/scanning related functionality is implemented over "BTPROTO_HCI" #define BTPROTO_L2CAP 0 #

Re: LPWORK Queue and USB Host Serial

> -Original Message- > From: Gregory Nutt [mailto:spudan...@gmail.com] > Sent: Wednesday, August 26, 2020 3:34 PM > You must be using an STM32, right? The USB host on STM32 is garbage. No, I'm using a Kinetis K28 with EHCI, and I'm sure that problem is by design of the serial drivers: It

Re: LVGL moving to Kconfig, how we could integrated better with them

On Wed, Aug 26, 2020, 6:53 AM Abdelatif Guettouche < abdelatif.guettou...@gmail.com> wrote: > Generating the Kconfig file has to be done during preconfig otherwise > anything kconfig related won't work. We can't source a file that > doesn't exist yet. > As it is now LVGL is downloaded during cont

Re: LVGL moving to Kconfig, how we could integrated better with them

Maybe we keep a dummy Kconfig and override it during context? (thinking out loud...) On Wed, Aug 26, 2020 at 3:49 PM Abdelatif Guettouche wrote: > > Generating the Kconfig file has to be done during preconfig otherwise > anything kconfig related won't work. We can't source a file that > doesn't

Re: LVGL moving to Kconfig, how we could integrated better with them

Generating the Kconfig file has to be done during preconfig otherwise anything kconfig related won't work. We can't source a file that doesn't exist yet. As it is now LVGL is downloaded during context (the usual), I think sourcing or just copying the Kconfig file from the LVGL folder would cause t

Re: defining a BLE GATT server

On 8/24/2020 8:51 AM, Matias N. wrote: Thanks for the heads up. Would be good to get Xiao Xiang's input on this then. Maybe he already encountered this issue. For now I'm working on the Link Layer, looking at 4.0 spec as a start. If the host layer is reimplemented for 5.0 I understand it shouldn

Re: LVGL moving to Kconfig, how we could integrated better with them

If you can make LVGL optionally NOT generate its own config.h and .config we could indeed just include the Kconfig and Make.defs (as it is done now). I think generating the config file would be part of a "toplevel" LVGL build system which we would completely bypass. Couldn't it be done in the

Re: LPWORK Queue and USB Host Serial

On 8/26/2020 7:28 AM, Gregory Nutt wrote: A short question concerning the use of LPWORK queue in FT232R and CDCACM USB Host drivers: Both block one LPWORK task per opened instance permanently. The FT232R rxdata_work USB transfer returns after each 16ms (USBHOST_FT232R_LATENCY) but since there

Re: LVGL moving to Kconfig, how we could integrated better with them

> If you can make LVGL optionally NOT generate its own config.h and .config we > could indeed just include the Kconfig and Make.defs (as it is done now). I think generating the config file would be part of a "toplevel" LVGL build system which we would completely bypass. > maybe allowing LVGL use

Re: LPWORK Queue and USB Host Serial

A short question concerning the use of LPWORK queue in FT232R and CDCACM USB Host drivers: Both block one LPWORK task per opened instance permanently. The FT232R rxdata_work USB transfer returns after each 16ms (USBHOST_FT232R_LATENCY) but since there are always at least two status bytes tra

Re: 答复: [External Mail]Re: defining a BLE GATT server

I will add my two cents as well.  I have already responded in comments on PR #1651, but I will copy my reponse here form continuity: I am in 100% agreement with Brennan and Matias. I am very opposed to this change because it violates all of the architectural principles that have been establish

Re: LVGL moving to Kconfig, how we could integrated better with them

LVGLs Kconfig in NuttX is used to define macros which are picked up in lv_conf.h. Indeed this is painful to maintain whenever a new LVGL version appears and changes lv_conf_template.h. Including a child Kconfig is no problem. The issue is that in this case NuttX controls the build and not LVGL

Re: LVGL moving to Kconfig, how we could integrated better with them

Of course it would be cool if you could simply do "make menuconfig" on NuttX and have LVGL options appear there, but I believe that would couple LVGL and NuttX build systems which may not be the best idea. I'm not sure if that can be done cleanly (it would always produce one .config and config.

Re: LVGL moving to Kconfig, how we could integrated better with them

Hi Alan and Gabor, I don't think that LVGL use of Kconfig should bother NuttX's since the build is always self contained in a directory. The positive side is that we could store a defconfig for LVGL on NuttX instead of the lv_conf.h that is now. Of course it would be cool if you could simply do

Re: [External Mail]Re: defining a BLE GATT server

An Chao, thanks for the very detailed explanation of how Xiaomi has approach the BLE stack in NuttX, it is quite useful to know when discussing this. However, I agree with Brennan that it is better to maintain compatibility with Linux by exposing the stack via sockets. Best, Matias On Wed, Aug

Re: [External Mail]Re: defining a BLE GATT server

On Wed, Aug 26, 2020, 3:31 AM 安超 wrote: > > Hi Greg, Matias, > > The current implementation of Xiaomi’s Bluetooth stack is different with > the current architecture. > HCI transport layer communication will be based on /dev/ttyS* devices > instead of sockets, > > > > The stack module prefers like