Re: Problems and a bug in samd2l2 ADC code

[Bernd Walter]

On Fri, Oct 30, 2020 at 12:26:33PM +0100, Bernd Walter wrote:
> On Thu, Oct 29, 2020 at 07:39:16PM -0300, Alan Carvalho de Assis wrote:
> > Ok, now I understood the issue you found
> > 
> > Yes, arch/arm/include/samd2l2/sam_adc.h is wrong.
> > 
> > I think this file shouldn't exit, it doesn't exist to other arches.
> 
> OK - I will take a look into this and change it to match other arches.
> But I like to find the other ADC problem before I rearrange the code.
> Might take a few days.

Well, thiss is all weird.
My Chip is a SAMD21E17A, so it has only 16k RAM.
I had been using in in another project with my own IO code and NXFFS on
an SPI flash (W25), but had to reduce stack sizes to have enough RAM
for the NXFFS.
This was with old NuttX code, shortly before the Apache change.
This project runs on a similar board, but uses different IO.
One of the IOs I need is the ADC and NuttX had no ADC support for the
SAMD21 in the code I had been using, therefor I upgraded in that project.
I'm running FreeBSD and had to work arround a few additional Linuxisms,
like calling "make" from a shell script and expect it to be GNU make.
Anyways - the board is tight on IO Pins and I have no UART left for console.
I did all my debugging with gdb and a bunch of LEDs.
This is the first part of my main routine:
int
main()
{
tm16_init();
//  // enable first digit as test
//  for (;;) {
//  tm16_setbmp(3, 0x01);
//  usleep(100);
//  }
//
LED_data[STATUS_LED] = 1;
LED_data[ERROR_LED] = 1;
LED_out();
LED_out();
sleep(1);
LED_data[ERROR_LED] = 0;
LED_out();

boardctl(BOARDIOC_INIT, 0);

config_init();

serial_init();

#ifdef CONFIG_SAMD2L2_ADCx
if (sam_adc_setup() < 0) {
syslog(LOG_ERR, "Failed to initialize the ADC driver\n");
}
#endif
...

tm16_init is just bit bang, also LED_out(), which delivers data to the tm1653
chip I'm using to drive the LEDs.
config_init() tries to read json config file from NXFFS, which should have been
mounted after boardctl.
serial_init() is empty for later use.
Up until sam_adc_setup gets called, /dev/null gets init, the via
board_app_initialize() I mount procfs and my SPI flash.
When sam_adc_setup() gets called somehow the inodes tables it searches in
seem to be corrup, at least the result makes no sense for me, but I don't
understand that code path and memory structures well enough yet.
If I call sam_adc_setup() before boardctl() it does init, but fails to
open later when I try to use it.
Then I thought, lets reduce memory usage and don't mount the NXFFS for now.
Without that (which also inits the SPI), it never returns from boardctl().

I'm open for ideas.
My current plan is to setup a Linux system and try plain NuttX on an
Arduino Zero.

> > Its content should be inside the arch/arm/src/samd2l2/sam_adc.h
> > 
> > BR,
> > 
> > Alan
> > 
> > On 10/29/20, Bernd Walter  wrote:
> > > On Thu, Oct 29, 2020 at 06:33:46PM -0300, Alan Carvalho de Assis wrote:
> > >> I don't think it is wrong.
> > >
> > > Well - inlcuding and requiring two files with the same protector clearly
> > > is wrong.
> > >
> > >> See: arch/arm/src/stm32/stm32_adc.h
> > >
> > > There is no arch/arm/include/stm32/stm32_adc.h
> > > There is a arch/arm/src/stm32/hardware/stm32_adc.h, which uses
> > > __ARCH_ARM_SRC_STM32H7_HARDWARE_STM32_ADC_H, so no collision
> > >
> > > arch/arm/include/samd2l2/sam_adc.h
> > > arch/arm/src/samd2l2/sam_adc.h
> > > Both use the same protector
> > > There is also arch/arm/src/samd2l2/hardware/samd_adc.h, which uses
> > > __ARCH_ARM_SRC_SAMD2L2_HARDWARE_SAMD_ADC_H, so no collision with
> > > this file.
> > >
> > > arch/arm/include/samd2l2/sam_adc.h used to be named adc.h with
> > > a matching protector name and originally had no collision.
> > >
> > >>
> > >> Now look inside boards/arm/stm32/ and you will find many board that
> > >> includes this file same way.
> > >
> > > As I said - there is no arch/arm/include/stm32/stm32_adc.h
> > > This is likely very unique to those two archs:
> > > [239]cicely7> ls -al arch/arm/include/*/*adc.h
> > > -rw-r--r--  1 ticso  1000  3395 Oct 29 20:42 
> > > arch/arm/include/cxd56xx/adc.h
> > > -rw-r--r--  1 ticso  1000  2798 Oct 29 20:42
> > > arch/arm/include/samd2l2/sam_adc.h
> > >
> > > As you can see, the cxd56xx isn't prefixed, which is the same it had been
> > > for the samd2l2 until 6bff1f4df4ae3e4fc21d7d98afdbfdcc855a6ed2 changed the
> > > filename and protector name.
> > >
> > >> On 10/29/20, Bernd Walter  wrote:
> > >> > On Thu, Oct 29, 2020 at 05:42:58PM -0300, Alan Carvalho de Assis wrote:
> > >> >> Hello,
> > >> >>
> > >> >> On 10/29/20, Bernd Walter  wrote:
> > >> >> > On Thu, Oct 29, 2020 at 08:51:13AM -0300, Alan Carvalho de Assis
> > >> >> > wrote:
> > >> >> >> Hi Bernd,
> > >> >> >>
> > >> >> >> It was "working" few mont ago. I put working covered by quotes
> > >> >> >> because
> > >> >> >> the ADC converti

Re: Problems and a bug in samd2l2 ADC code

[Alan Carvalho de Assis]

Hi Bernd,

On 11/2/20, Bernd Walter  wrote:
sic
>
> Well, thiss is all weird.
> My Chip is a SAMD21E17A, so it has only 16k RAM.
> I had been using in in another project with my own IO code and NXFFS on
> an SPI flash (W25), but had to reduce stack sizes to have enough RAM
> for the NXFFS.

Well, 16KB is really the bottom line, you probably will face issues
because you are trying to add fancy things like json, etc. I don't
suggest people to use NuttX on MCUs with less than 32KB because at end
of the day they will want to add some other subsystem to their
firmware and things will not work well.

> This was with old NuttX code, shortly before the Apache change.
> This project runs on a similar board, but uses different IO.
> One of the IOs I need is the ADC and NuttX had no ADC support for the
> SAMD21 in the code I had been using, therefor I upgraded in that project.
> I'm running FreeBSD and had to work arround a few additional Linuxisms,
> like calling "make" from a shell script and expect it to be GNU make.
> Anyways - the board is tight on IO Pins and I have no UART left for
> console.

In the past NuttX had a better support to BSDs because we used to have
a contributor that was running OpenBSD. If you want to help to make
NuttX run better on FreeBSD and other, please submit a patch to fix
it. :-)

> I did all my debugging with gdb and a bunch of LEDs.
> This is the first part of my main routine:
> int
> main()
> {
> tm16_init();
> //  // enable first digit as test
> //  for (;;) {
> //  tm16_setbmp(3, 0x01);
> //  usleep(100);
> //  }
> //
> LED_data[STATUS_LED] = 1;
> LED_data[ERROR_LED] = 1;
> LED_out();
> LED_out();
> sleep(1);
> LED_data[ERROR_LED] = 0;
> LED_out();
>
> boardctl(BOARDIOC_INIT, 0);
>
> config_init();
>
> serial_init();
>
> #ifdef CONFIG_SAMD2L2_ADCx
> if (sam_adc_setup() < 0) {
> syslog(LOG_ERR, "Failed to initialize the ADC driver\n");
> }
> #endif
> ...
>

Let's to ignore the fact you are violating the userspace/kernel layer.
Try to avoid doing it. Your application needs to use access the LEDs
using the USERLEDS support. There is an example to stm32f103-minimum
board.

> tm16_init is just bit bang, also LED_out(), which delivers data to the
> tm1653
> chip I'm using to drive the LEDs.
> config_init() tries to read json config file from NXFFS, which should have
> been

Instead using json, maybe you could use Inifile, please take a look on
FSUTILS_INIFILE. I think it will use less memory than JSON.

> mounted after boardctl.
> serial_init() is empty for later use.
> Up until sam_adc_setup gets called, /dev/null gets init, the via
> board_app_initialize() I mount procfs and my SPI flash.
> When sam_adc_setup() gets called somehow the inodes tables it searches in
> seem to be corrup, at least the result makes no sense for me, but I don't
> understand that code path and memory structures well enough yet.
> If I call sam_adc_setup() before boardctl() it does init, but fails to
> open later when I try to use it.
> Then I thought, lets reduce memory usage and don't mount the NXFFS for now.
> Without that (which also inits the SPI), it never returns from boardctl().
>

Try to use the Custom board late initialization, maybe it could help you.

Normally I prefer to do everything booting the NSH and calling my
application from its prompt, only when everything is working I change
the entry point to my application.

> I'm open for ideas.
> My current plan is to setup a Linux system and try plain NuttX on an
> Arduino Zero.
>

This should be a better idea because you will have 32KB of RAM. They
after getting it working you can remove not necessary features to
eventually get it working reliable on 16KB RAM.

In the past I got NuttX running on less than 2KB RAM, but it was a PoC
and all main subsystem were removed, including the VFS. It mean I was
violating the abstraction like you did! :-D

Look here: https://www.flickr.com/photos/79703543@N00/18013069041/sizes/h/

See the usage RAM from the 'free' command.

BR,

Alan

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

[Alan Carvalho de Assis]

Hi Gábor,

On 11/2/20, Gábor Kiss-Vámosi  wrote:
sic
>
> Why is it not an issue with other projects you use in NuttX? Have we missed
> something?
>

This is the first time we need to integrate with an external library
that uses Kconfig and have more configuration options. All other
libraryies/applications are most fixed and they don't evolve other the
time.

It should be nice if kconfig-frontend was more dynamic: we could
select the option: [x] Enable LVGL and then it show up a download
progress bar screen and after the tarball is decompressed it display
the LVGL Kconfig.

But for today, let's just get your Kconfig and put it at
apps/graphics/lvgl/ it should be enough. And we just need to do it a
time when a new LVGL version is released.

BR,

Alan

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

[Alan Carvalho de Assis]

whoa, I did so many mistakes (it happens everything I don't sleep well)

Let's see it:

On 11/2/20, Alan Carvalho de Assis  wrote:
> Hi Gábor,
>
> On 11/2/20, Gábor Kiss-Vámosi  wrote:
> sic
>>
>> Why is it not an issue with other projects you use in NuttX? Have we
>> missed
>> something?
>>
>
This is the first time we need to integrate with an external library
that uses Kconfig and have more configuration options. All other
libraries/applications are mostly fixed and they don't evolve over the
time.

It should be nice if kconfig-frontend was more dynamic: we could
to select the option: [x] Enable LVGL and then it show up a download
progress bar screen and after the tarball is decompressed it displays
the LVGL Kconfig.

But for today, let's just get your Kconfig and put it at
apps/graphics/lvgl/ it should be enough. And we just need to do it a
time when a new LVGL version is released.

BR,

Alan
>

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

[Matias N.]

On Mon, Nov 2, 2020, at 09:51, Gábor Kiss-Vámosi wrote:
> Hi,
> 
>> BTW, is LVGL going to provide a script to convert the Kconfig to a
>> lv_config.h of some sort?  If that's the case we'll only have to call
>> the script after we download the tarball.
> 
> Yes, We have lv_conf_internal.h 
>  that 
> translates the Kconfig values to LVGL configs.  Besides, lv_conf_kconfig.h 
>  contains 
> some special "if"s to handle type not supported by Kconfig. The header 
> created by Kconfig can be included here as well. See the example for ESP in 
> the link.

I understand that we can consider each project to be configured separately, but 
IMHO it would be great if we could just
use your Kconfig files as part of Kconfig system (having the Kconfig files 
downloaded previously, as I suggested). If your internal headers assume that 
each symbol will be translated to CONFIG_ and if you allow for an 
external header to be included ("#include ") via some symbolic 
link, dummy file or macro, NuttX would supply the macros generated during our 
configuration stage.

> 
>> Since we will download the LVGL tarball with a Kconfig, we cannot
>> display the menuconfig before it is downloaded and decompressed.
>> And because its download depends on selected item on menuconfig we a
>> classic dilemma here. :-)
> 
> Why is it not an issue with other projects you use in NuttX? Have we missed 
> something?

Well, that is why it would be "awkward" as others mentioned: no other project 
we depend on AFAIK is based on Kconfig. And for projects requiring some 
different configuration stage, we apply some patch (not ideal) to add NuttX 
support. So, our build system is very simple:

- initialize based configuration for board-config combination (using own 
script, which setups build environment and places initial .config)
- make menuconfig
- make

During make there's a "context" stage which downloads all third-party tarballs 
and extract them.

Best,
Matias

> 
> Regards,
> Gabor
> 
>  
> 
> Matias N.  ezt írta (időpont: 2020. nov. 1., V, 20:13):
>> __
>> Hi Alan,
>> 
>> On Sun, Nov 1, 2020, at 14:52, Alan Carvalho de Assis wrote:
>>> Since we will download the LVGL tarball with a Kconfig, we cannot
>>> display the menuconfig before it is downloaded and decompressed.
>>> And because its download depends on selected item on menuconfig we a
>>> classic dilemma here. :-)
>> 
>> Yes, I understand the problem.
>> 
>>> 
>>> An option could be including a Kconfig in apps/graphics/ that just let
>>> the user to enable to Kconfig, and then during the building process
>>> after the download and decompress of the lvgl.tar.gz the menuconfig is
>>> called just to let the user to fine tune the LVGL configuration. This
>>> is just an idea, because currently we do all the configuration in a
>>> single step, but breaking down this process in two phases we could
>>> simplify this kind of issue. Probably this idea could get some
>>> resistance, what do you think?
>> 
>> Well, I was just arguing against this strategy exactly (or anything changing 
>> our standard configuration
>> workflow). Having two separate configuration processes, added
>> targets, extra config file, is all just added complexity for no good reason.
>> I don't see how this helps us at all. The current process
>> of configuring LVGL from a submenu of our config is the best approach.
>> 
>> What I suggested is to ship LVGL's *official* Kconfig file as part of our 
>> repo. Compared
>> to our current approach, we would use an official solution which we know 
>> works for the LVGL version
>> we are using. Moreover, we build not be maintaining this file, it would be 
>> maintained by LVGL.
>> We would just download it whenever we decide to upgrade to another LVGL 
>> release.
>> 
>> Note the comment from Zephyr guys on this (last line): 
>> https://github.com/lvgl/lvgl/pull/1875#issuecomment-720086968
>> They essentially do what I'm suggesting.
>> 
>>> 
>>> BTW, if LVGL projects just create a Kconfig similar to
>>> apps/graphics/lvgl/Kconfig already will help because, because until
>>> now for each LVGL release we need to create a new Kconfig.
>> 
>> That is exactly my point in how the above approach would indeed benefit us 
>> (instead of us
>> just having to complicate our configuration/build system).
>> 
>> Best,
>> Matias

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

[Matias N.]

Hi Gabor,

we just recently added a __NuttX__ macro as part of our base compilation flags, 
so I guess it should be:

#ifdef __NuttX__
#include 
#endif

What do others think?

BTW, are you thinking of a single root Kconfig or a series of nested Kconfigs? 
The latter would be a bit more difficult to handle the way I suggested.

Best,
Matias

On Mon, Nov 2, 2020, at 10:43, Gábor Kiss-Vámosi wrote:
> I see, thanks for the explanation. 
> 
>> I understand that we can consider each project to be configured separately, 
>> but IMHO it would be great if we could just
>> use your Kconfig files as part of Kconfig system (having the Kconfig files 
>> downloaded previously, as I suggested). If your internal headers assume that 
>> each symbol will be translated to CONFIG_ and if you allow for an 
>> external header to be included ("#include ") via some 
>> symbolic link, dummy file or macro, NuttX would supply the macros generated 
>> during our configuration stage.
> 
> 
> Seems clear from our side. Please let me know what snippet I should for 
> NuttX. Similar to:
> #if defined ESP_PLATFORM
> #include "sdkconfig.h"
> #include "esp_attr.h"
> #endif
> 
> Regards,
> Gabor
>  
> 
> Matias N.  ezt írta (időpont: 2020. nov. 2., H, 14:33):
>> __
>> On Mon, Nov 2, 2020, at 09:51, Gábor Kiss-Vámosi wrote:
>>> Hi,
>>> 
 BTW, is LVGL going to provide a script to convert the Kconfig to a
 lv_config.h of some sort?  If that's the case we'll only have to call
 the script after we download the tarball.
>>> 
>>> Yes, We have lv_conf_internal.h 
>>>  that 
>>> translates the Kconfig values to LVGL configs.  Besides, lv_conf_kconfig.h 
>>>  contains 
>>> some special "if"s to handle type not supported by Kconfig. The header 
>>> created by Kconfig can be included here as well. See the example for ESP in 
>>> the link.
>> 
>> I understand that we can consider each project to be configured separately, 
>> but IMHO it would be great if we could just
>> use your Kconfig files as part of Kconfig system (having the Kconfig files 
>> downloaded previously, as I suggested). If your internal headers assume that 
>> each symbol will be translated to CONFIG_ and if you allow for an 
>> external header to be included ("#include ") via some 
>> symbolic link, dummy file or macro, NuttX would supply the macros generated 
>> during our configuration stage.
>> 
>>> 
 Since we will download the LVGL tarball with a Kconfig, we cannot
 display the menuconfig before it is downloaded and decompressed.
 And because its download depends on selected item on menuconfig we a
 classic dilemma here. :-)
>>> 
>>> Why is it not an issue with other projects you use in NuttX? Have we missed 
>>> something?
>> 
>> Well, that is why it would be "awkward" as others mentioned: no other 
>> project we depend on AFAIK is based on Kconfig. And for projects requiring 
>> some different configuration stage, we apply some patch (not ideal) to add 
>> NuttX support. So, our build system is very simple:
>> 
>> - initialize based configuration for board-config combination (using own 
>> script, which setups build environment and places initial .config)
>> - make menuconfig
>> - make
>> 
>> During make there's a "context" stage which downloads all third-party 
>> tarballs and extract them.
>> 
>> Best,
>> Matias
>> 
>>> 
>>> Regards,
>>> Gabor
>>> 
>>>  
>>> 
>>> Matias N.  ezt írta (időpont: 2020. nov. 1., V, 20:13):
 __
 Hi Alan,
 
 On Sun, Nov 1, 2020, at 14:52, Alan Carvalho de Assis wrote:
> Since we will download the LVGL tarball with a Kconfig, we cannot
> display the menuconfig before it is downloaded and decompressed.
> And because its download depends on selected item on menuconfig we a
> classic dilemma here. :-)
 
 Yes, I understand the problem.
 
> 
> An option could be including a Kconfig in apps/graphics/ that just let
> the user to enable to Kconfig, and then during the building process
> after the download and decompress of the lvgl.tar.gz the menuconfig is
> called just to let the user to fine tune the LVGL configuration. This
> is just an idea, because currently we do all the configuration in a
> single step, but breaking down this process in two phases we could
> simplify this kind of issue. Probably this idea could get some
> resistance, what do you think?
 
 Well, I was just arguing against this strategy exactly (or anything 
 changing our standard configuration
 workflow). Having two separate configuration processes, added
 targets, extra config file, is all just added complexity for no good 
 reason.
 I don't see how this helps us at all. The current process
 of configuring LVGL from a submenu of our config is the best approach.
 
 What I suggested is to ship LVGL's *official* 

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

[Gábor Kiss-Vámosi]

I see, thanks for the explanation.

I understand that we can consider each project to be configured separately,
> but IMHO it would be great if we could just
> use your Kconfig files as part of Kconfig system (having the Kconfig files
> downloaded previously, as I suggested). If your internal headers assume
> that each symbol will be translated to CONFIG_ and if you allow for
> an external header to be included ("#include ") via some
> symbolic link, dummy file or macro, NuttX would supply the macros generated
> during our configuration stage.



Seems clear from our side. Please let me know what snippet I should for
NuttX. Similar to:
#if defined ESP_PLATFORM
#include "sdkconfig.h"
#include "esp_attr.h"
#endif

Regards,
Gabor


Matias N.  ezt írta (időpont: 2020. nov. 2., H, 14:33):

> On Mon, Nov 2, 2020, at 09:51, Gábor Kiss-Vámosi wrote:
>
> Hi,
>
> BTW, is LVGL going to provide a script to convert the Kconfig to a
> lv_config.h of some sort?  If that's the case we'll only have to call
> the script after we download the tarball.
>
>
> Yes, We have lv_conf_internal.h
> 
> that translates the Kconfig values to LVGL configs.  Besides,
> lv_conf_kconfig.h
>  contains
> some special "if"s to handle type not supported by Kconfig. The header
> created by Kconfig can be included here as well. See the example for ESP in
> the link.
>
>
> I understand that we can consider each project to be configured
> separately, but IMHO it would be great if we could just
> use your Kconfig files as part of Kconfig system (having the Kconfig files
> downloaded previously, as I suggested). If your internal headers assume
> that each symbol will be translated to CONFIG_ and if you allow for
> an external header to be included ("#include ") via some
> symbolic link, dummy file or macro, NuttX would supply the macros generated
> during our configuration stage.
>
>
> Since we will download the LVGL tarball with a Kconfig, we cannot
> display the menuconfig before it is downloaded and decompressed.
> And because its download depends on selected item on menuconfig we a
> classic dilemma here. :-)
>
>
> Why is it not an issue with other projects you use in NuttX? Have we
> missed something?
>
>
> Well, that is why it would be "awkward" as others mentioned: no other
> project we depend on AFAIK is based on Kconfig. And for projects requiring
> some different configuration stage, we apply some patch (not ideal) to add
> NuttX support. So, our build system is very simple:
>
> - initialize based configuration for board-config combination (using own
> script, which setups build environment and places initial .config)
> - make menuconfig
> - make
>
> During make there's a "context" stage which downloads all third-party
> tarballs and extract them.
>
> Best,
> Matias
>
>
> Regards,
> Gabor
>
>
>
> Matias N.  ezt írta (időpont: 2020. nov. 1., V, 20:13):
>
>
> Hi Alan,
>
> On Sun, Nov 1, 2020, at 14:52, Alan Carvalho de Assis wrote:
>
> Since we will download the LVGL tarball with a Kconfig, we cannot
> display the menuconfig before it is downloaded and decompressed.
> And because its download depends on selected item on menuconfig we a
> classic dilemma here. :-)
>
>
> Yes, I understand the problem.
>
>
> An option could be including a Kconfig in apps/graphics/ that just let
> the user to enable to Kconfig, and then during the building process
> after the download and decompress of the lvgl.tar.gz the menuconfig is
> called just to let the user to fine tune the LVGL configuration. This
> is just an idea, because currently we do all the configuration in a
> single step, but breaking down this process in two phases we could
> simplify this kind of issue. Probably this idea could get some
> resistance, what do you think?
>
>
> Well, I was just arguing against this strategy exactly (or anything
> changing our standard configuration
> workflow). Having two separate configuration processes, added
> targets, extra config file, is all just added complexity for no good
> reason.
> I don't see how this helps us at all. The current process
> of configuring LVGL from a submenu of our config is the best approach.
>
> What I suggested is to ship LVGL's *official* Kconfig file as part of our
> repo. Compared
> to our current approach, we would use an official solution which we know
> works for the LVGL version
> we are using. Moreover, we build not be maintaining this file, it would be
> maintained by LVGL.
> We would just download it whenever we decide to upgrade to another LVGL
> release.
>
> Note the comment from Zephyr guys on this (last line):
> https://github.com/lvgl/lvgl/pull/1875#issuecomment-720086968
> They essentially do what I'm suggesting.
>
>
> BTW, if LVGL projects just create a Kconfig similar to
> apps/graphics/lvgl/Kconfig already will help because, because until
> now for each LVGL release we need to crea

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

[Gábor Kiss-Vámosi]

Hi,

BTW, is LVGL going to provide a script to convert the Kconfig to a
> lv_config.h of some sort?  If that's the case we'll only have to call
> the script after we download the tarball.


Yes, We have lv_conf_internal.h
 that
translates the Kconfig values to LVGL configs.  Besides, lv_conf_kconfig.h
 contains
some special "if"s to handle type not supported by Kconfig. The header
created by Kconfig can be included here as well. See the example for ESP in
the link.

Since we will download the LVGL tarball with a Kconfig, we cannot
> display the menuconfig before it is downloaded and decompressed.
> And because its download depends on selected item on menuconfig we a
> classic dilemma here. :-)


Why is it not an issue with other projects you use in NuttX? Have we missed
something?

Regards,
Gabor



Matias N.  ezt írta (időpont: 2020. nov. 1., V, 20:13):

> Hi Alan,
>
> On Sun, Nov 1, 2020, at 14:52, Alan Carvalho de Assis wrote:
>
> Since we will download the LVGL tarball with a Kconfig, we cannot
> display the menuconfig before it is downloaded and decompressed.
> And because its download depends on selected item on menuconfig we a
> classic dilemma here. :-)
>
>
> Yes, I understand the problem.
>
>
> An option could be including a Kconfig in apps/graphics/ that just let
> the user to enable to Kconfig, and then during the building process
> after the download and decompress of the lvgl.tar.gz the menuconfig is
> called just to let the user to fine tune the LVGL configuration. This
> is just an idea, because currently we do all the configuration in a
> single step, but breaking down this process in two phases we could
> simplify this kind of issue. Probably this idea could get some
> resistance, what do you think?
>
>
> Well, I was just arguing against this strategy exactly (or anything
> changing our standard configuration
> workflow). Having two separate configuration processes, added
> targets, extra config file, is all just added complexity for no good
> reason.
> I don't see how this helps us at all. The current process
> of configuring LVGL from a submenu of our config is the best approach.
>
> What I suggested is to ship LVGL's *official* Kconfig file as part of our
> repo. Compared
> to our current approach, we would use an official solution which we know
> works for the LVGL version
> we are using. Moreover, we build not be maintaining this file, it would be
> maintained by LVGL.
> We would just download it whenever we decide to upgrade to another LVGL
> release.
>
> Note the comment from Zephyr guys on this (last line):
> https://github.com/lvgl/lvgl/pull/1875#issuecomment-720086968
> They essentially do what I'm suggesting.
>
>
> BTW, if LVGL projects just create a Kconfig similar to
> apps/graphics/lvgl/Kconfig already will help because, because until
> now for each LVGL release we need to create a new Kconfig.
>
>
> That is exactly my point in how the above approach would indeed benefit us
> (instead of us
> just having to complicate our configuration/build system).
>
> Best,
> Matias
>