For nuttx port some functional modules

[Gregory N]

Yesterday I released NuttX-6.24 with the first "advertised" native Windows build support. There are still two big missing parts: (1) a configure.sh counterpart, and much more importanly (2) mconf running natively under in a CMD.exe shell under Windows.

Since writing that, I have solved (1). There is now a tools/configure.bat and a tools/configure.c. The configure.bat is just a thin layer: If checks if configure.exe exists, then executes it to instantiate the configuration. If configure.exe does not exist, then it first creates it using minggw-gcc.exe

But (2) is still an issue.

Lately, I have been tinkering with pieces of kconfig-frontends and I am pretty sure that I could do something like the following:

The kconfig-frontends depends on low-level YACC/LEX code. The YACC/LEX code generates a data set describing the configuration and provides C interfaces to manage the configuration data set. This is the "back end" used by all of the kconfig-frontends: The frontends basically provide the different user experience and the backend manages the configuration.

The C code generated from the YACC/LEX has no dependencies at all (other than libintl which is not a big issue) and so is portable. The frontends (other than 'conf') do have major system dependencies and, hence, are the root of the portability problem.

I believe that I could modify the YACC code so that instead of generating a data set it would generate another interpreted program. In fact, the logic for create such a program for the case of Tcl/Tk already exists in the Linux 2.4 kernel. See for example, http://fxr.watson.org/fxr/source/scripts/?v=linux-2.4.22.

The format of the configuration files was different in the 2.4 kernel (Config.in files vs Kconfig files), but functionally equivalent.

When you did 'make xconfig' in the 2.4 kernel, a two step process was initiated. In the first step, the logic in scripts/Makefile ran. The kconfig.tk target in that Makefile created the Tcl program. Then in the second step, the top-level Makefile executed the Tcl/Tk program. The configuration was then done with the Tcl/Tk GUI which is nicer than the mconf GUI, but not as nice as the gconf GUI.

The file scripts/tkparse.c did all of the work and could easily be leveraged to generate a Tcl program in the same way (http://fxr.watson.org/fxr/source/scripts/tkparse.c?v=linux-2.4.22). That would be almost free. Tcl/Tk is available for Windows, but it not so commonly used.

The reason later kernels did not use Tcl/Tk is due largely to the fact that many people do not like Tcl/Tk. But perhaps a similar configuration strategy using some Windows-friendly scripting language like C# or Java/Swing might be appropriate?

So let me re-phrase the problem:

1) The kconfig-frontends works nicely in many environments (Linux, Cygwin, ..), but not native Windows. It cannot be build directly under native Windows. You cannot even configure it under Windows because the configuration script is bash script.

2) There are some round-about ways to get a Windows kconfig-frontends mconf executable. (a) Using MSYS, but the build process is much more complex than the average person can handle and there are bugs in pdcurses that prevent it from working properly. Or (b) using Cygwin but this requires a large installation and the tool will not work properly outside of the Cygwin "sandbox" without a lot of special setup.

One alternative is to:

Use a simple C program to auto-generate a Windows-compatible script to do the configuration. The creation program would only depend on mingw-gcc and the generated script would to fully compatible with the Windows environment, perhaps C# or Java/Swing.

Any inputs? As you see, I am still struggling with a solution that the would work well, be easy to use and would not require many special tools.

Any thoughts?

Greg

[Freddie Chopin]

mconf - being a bit buggy (readline) - is usable, you just have to edit
the text values "outside" which is not a big deal (;

I think that the most usable frontend is qconf that uses Qt and as a Qt
app doesn't have much dependancies on the system (other than Qt [; ) - I
managed to compile that, but it crashes at startup - it can be some very
minor issue with the dlls, but I'm not an Qt expert...

4\/3!!

[Gregory N]

Post by Freddie Chopin
mconf - being a bit buggy (readline) - is usable, you just have to edit
the text values "outside" which is not a big deal (;
I think that the most usable frontend is qconf that uses Qt and as a Qt
app doesn't have much dependancies on the system (other than Qt [; ) - I
managed to compile that, but it crashes at startup - it can be some very
minor issue with the dlls, but I'm not an Qt expert...

This option, as well as the option to use the Cygwin version, are both listed in the top-level README.txt file. These are the current plan of record but I don't think that either the MSYS mconf or qconf are usable solutions.

The Cygwin solution is closer. At least the mconf works. I don't have Qt installed, but the Cygwin gconf (GTK-base) seems to work fine: See Cwygin-gconf.png at http://tech.groups.yahoo.com/group/nuttx/files/. If some work were put into properly bundling the Cygwin tools, these good be real functional tools.

But neither the buggy MSYS options or the awkward Cygwin options feel good to me. I am looking for something more natural for the Windows environment. Something that I can build and use in the native Windows environment without Bash, Cygwin, or MSYS (which is still Cygwin).

Greg

[Richard Cochran]

Post by Gregory N
But neither the buggy MSYS options or the awkward Cygwin options
feel good to me. I am looking for something more natural for the
Windows environment. Something that I can build and use in the
native Windows environment without Bash, Cygwin, or MSYS (which is
still Cygwin).

If you decide that a tcltk solution is acceptable, then I would be
willing to help write the tk gui. I just happen to love* that
language, and I think it would be well suited to this task.

Thanks,
Richard

* Well, okay, love it too strong a word. Let's say "really like" instead ;)

[Mike Smith]

Tcl/Tk is quite possibly one of the easier tool sets to use for this task; you can build a self-contained starkit pretty easily.

Sent from my iPad

Post by Richard Cochran

Post by Gregory N
But neither the buggy MSYS options or the awkward Cygwin options
feel good to me. I am looking for something more natural for the
Windows environment. Something that I can build and use in the
native Windows environment without Bash, Cygwin, or MSYS (which is
still Cygwin).

If you decide that a tcltk solution is acceptable, then I would be
willing to help write the tk gui. I just happen to love* that
language, and I think it would be well suited to this task.
Thanks,
Richard
* Well, okay, love it too strong a word. Let's say "really like" instead ;)

[Gregory N]

Hi, Richard,

Post by Richard Cochran

Post by Gregory N
But neither the buggy MSYS options or the awkward Cygwin options
feel good to me. I am looking for something more natural for the
Windows environment. Something that I can build and use in the
native Windows environment without Bash, Cygwin, or MSYS (which is
still Cygwin).

If you decide that a tcltk solution is acceptable, then I would be
willing to help write the tk gui. I just happen to love* that
language, and I think it would be well suited to this task.

I would be glad to have your help. I have several things up in the air and a few other time commitments coming up, so I will not be able to work on this full time. How would you like to work together? Do you want to share the code in some repository? If you like you can take over the project altogether!

Here are the resources that I have:

1. I have a very stripped down version of conf that builds without configure, automake, and friends. My intention was to change the YACC code so that it generated Tcl/Tk instead of a data set.

2. I have all of the Tck/Tk generation logic from the Linux 2.4 kernel.

If you want to see that Linux 2.4 Tcl/Tk code, here is how you can get it. First download Linux 2.4.31 from kernel.org. Then:

$ tar jxf linux-2.4.31.tar.bz2
$ make xconfig
rm -f include/asm
( cd include ; ln -sf asm-i386 asm)
make -C scripts kconfig.tk
make[1]: Entering directory `/home/patacongo/projects/Linux/linux-2.4.31/scripts'
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -c -o tkparse.o tkparse.c
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -c -o tkcond.o tkcond.c
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -c -o tkgen.o tkgen.c
gcc -o tkparse tkparse.o tkcond.o tkgen.o
cat header.tk >> ./kconfig.tk
./tkparse < ../arch/i386/config.in >> kconfig.tk
echo "set defaults \"arch/i386/defconfig\"" >> kconfig.tk
echo "set ARCH \"i386\"" >> kconfig.tk
cat tail.tk >> kconfig.tk
chmod 755 kconfig.tk
make[1]: Leaving directory `/home/patacongo/projects/Linux/linux-2.4.31/scripts'
wish -f scripts/kconfig.tk

Above you can see all of the steps how the Linux Makefile auto-generated the Tcl/Tk code. After the 'wish -f scripts/kconfig.tk', the Tck/Tk configuration window pops up. I have uploaded a screenshot of the initial configuration window here: http://tech.groups.yahoo.com/group/nuttx/files/Linux%202.4%20Configuration/ . I also uploaded the kconfig.tk file so that you can see the generated Tcl/Tk (it might now work well without the .config file).

I actually like the Tcl/Tk GUI. linux2-xconfig.png is the opening window. It is just a collection of buttons. Most buttons open a menu in another window. So you can end up with lots of tiny windows each with a menu in it. For example, if you presss the "Memory Technology Devices (MTD)" button, you get the MTD menu of mtd-xconfig.png.

Let me know what you would like to do.

Greg

[Richard Cochran]

Post by Gregory N
1. I have a very stripped down version of conf that builds without configure, automake, and friends. My intention was to change the YACC code so that it generated Tcl/Tk instead of a data set.

Can you publish this? (Yacc is okay for me to work with)

Post by Gregory N
Let me know what you would like to do.

I also remember the 2.4 Tk interface, and I actually liked it better
that the Qt and Gtk variants. I'll will start with that, and then
perhaps try to modernize its look and feel.

Thanks,
Richard

[Gregory N]

Post by Richard Cochran

Post by Gregory N
1. I have a very stripped down version of conf that builds without configure, automake, and friends. My intention was to change the YACC code so that it generated Tcl/Tk instead of a data set.

Can you publish this? (Yacc is okay for me to work with)

I put what I have now here http://tech.groups.yahoo.com/group/nuttx/files/Linux%202.4%20Configuration/ as tclconf.tar.gz. As I said it is just the kconfig-frontends conf stripped down to the bare minimum. It use the pre-built YACC .c files.

Greg

[Alan Carvalho de Assis]

Hi Richard,

Post by Richard Cochran
I also remember the 2.4 Tk interface, and I actually liked it better
that the Qt and Gtk variants. I'll will start with that, and then
perhaps try to modernize its look and feel.

About a modern look and feel with Tk, I remember of InstallJammer
project, this project is stalled/discontinued but the files still
available at their site: http://www.installjammer.com

Maybe you could take a look for reference.

Best Regards,

Alan

[Richard Cochran]

Post by Gregory N
Let me know what you would like to do.

Okay, so I looked at the old Linux kconfig.tk and the tclconf, and I
took a second look at qconf and gconf, to remind myself of how much I
dislike them. The older kconfig.tk won't help us, since it did its own
parsing of the now obsolete config.in language. Here is what I have in
mind.

I don't see a need to alter the yacc grammar files at all. The kconfig
frontends all share a little C library that parses the Kconfig and the
.config files into an internal binary representation with linked lists
of things like "struct symbol", "struct property", "struct menu", and
so on. It will be easy enough to adapt the minimal tclconf.c program
to walk these lists and produce the needed tcltk scripts.

This is chance for me to make the kconfig tool that I always wanted,
with features like:

- custom views
- selecting subsets by regex
- multiple simultaneous views
- web-like navigation through the options, with a "back" button
- topologically sorted dependency view (to find out what is preventing
an option from being selected).

Since any program like tclconf will have to be GPL, and since the new
features may be interesting to a wider audience than just the nuttx
crowd, I propose going about this as a new contribution to the
kconfig-frontends project.

Within nuttx, I would create a stand alone makefile (or two, one for
Linux, one for windoze) that simply compiles and links the needed C
files out of kconfig-frontends. The autotools stuff is surely
overkill, and we can just ignore it. Also, the code already compiles
and runs fine without any other libraries (except the standard C
library). Not even libintl is needed.

Thoughts?

Thanks,
Richard

[Gong Darcy]

Hi Freddie,

Python kconfiglib+pyqt is definitely a good idea.

:)

darcy

Post by Freddie Chopin
mconf - being a bit buggy (readline) - is usable, you just have to edit
the text values "outside" which is not a big deal (;
I think that the most usable frontend is qconf that uses Qt and as a Qt
app doesn't have much dependancies on the system (other than Qt [; ) - I
managed to compile that, but it crashes at startup - it can be some very
minor issue with the dlls, but I'm not an Qt expert...
4\/3!!

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/nuttx/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/nuttx/join
(Yahoo! ID required)

<*> To change settings via email:
nuttx-digest-***@public.gmane.org
nuttx-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
nuttx-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Kevin Franzen]

This is probably a little off topic, but, I did a quick look at Tcl/Tk. It reminded me of Forth (years ago I used polyForth). I thought this style of coding was no longer commonplace. Thoughts? Opinions?

Kevin

[Gregory N]

Hi, Kevin,

Post by Kevin Franzen
This is probably a little off topic, but, I did a quick look at Tcl/Tk. It reminded me of Forth (years ago I used polyForth). I thought this style of coding was no longer commonplace. Thoughts? Opinions?

As a general purpose programming language, I would agree. Tcl/Tk (the Tool Control Language and its Toolkit) is pretty old and it shows in its style. However, it is still used in certain quarters... especially in automated testing. It is the heart of most of the classic testing frameworks. Many large test organizations are still committed to Tcl/Tk because of the years they have invested in test environments.

Tcl/Tk has two things to recommend it: It integrates with C nicely so that you can drive C-based tests with scripts. And Tk ... You can get get the coolest GUIs with next to no effort. It is this latter capability that motivates the discussion of Tcl/Tk for configuration displays.

I am sure that there are newer testing languages that surpass Tcl/Tk. I don't really keep up with that.

Greg

[Mohammad Elwakeel]

Hello,

It might seem a bit odd, but why don't we think of Lua scripting language.
I mean, it also works well with C and the lua C runtime is not that
challenge to port.

Regards,
Mohammad

Post by Gregory N
**
Hi, Kevin,

Post by Kevin Franzen
This is probably a little off topic, but, I did a quick look at Tcl/Tk.

It reminded me of Forth (years ago I used polyForth). I thought this style
of coding was no longer commonplace. Thoughts? Opinions?
As a general purpose programming language, I would agree. Tcl/Tk (the Tool
Control Language and its Toolkit) is pretty old and it shows in its style.
However, it is still used in certain quarters... especially in automated
testing. It is the heart of most of the classic testing frameworks. Many
large test organizations are still committed to Tcl/Tk because of the years
they have invested in test environments.
Tcl/Tk has two things to recommend it: It integrates with C nicely so that
you can drive C-based tests with scripts. And Tk ... You can get get the
coolest GUIs with next to no effort. It is this latter capability that
motivates the discussion of Tcl/Tk for configuration displays.
I am sure that there are newer testing languages that surpass Tcl/Tk. I
don't really keep up with that.
Greg

[Richard Cochran]

Post by Gregory N
Tcl/Tk has two things to recommend it: It integrates with C nicely
so that you can drive C-based tests with scripts. And Tk ... You
can get get the coolest GUIs with next to no effort. It is this
latter capability that motivates the discussion of Tcl/Tk for
configuration displays.

Also:

- Small runtime (including gui)
- Portable gui scripts, cross platform
- Easy install on all platforms

Post by Gregory N
I am sure that there are newer testing languages that surpass
Tcl/Tk. I don't really keep up with that.

I don't know about one language "surpassing" another, probably a
matter of opinion. For me, the drawbacks of tcltk are:

- Quoting rules can be tricky to understand
- Hard to make really large applications without creating spagetti

But I think this is also true of other scripting languages, too.

Thanks,
Richard

[Michael Smith]

Post by Kevin Franzen
This is probably a little off topic, but, I did a quick look at Tcl/Tk. It reminded me of Forth (years ago I used polyForth). I thought this style of coding was no longer commonplace. Thoughts? Opinions?

Kevin,

Tcl bears essentially no resemblance whatsoever to Forth (ref: I have written several medium-sized Tcl applications; it is my go-to scripting language of choice and has been for ~15 years. I have written a number of OpenFirmware device drivers in Forth and built a number of small single-purpose embedded systems using the language).

Whilst I'm not sure what you mean by "this style of coding", but both Tcl and Forth are very much alive and kicking. Tcl in particular isn't "sexy", but it is an immensely capable language and you'll find it in a lot of interesting places (EDA tools, test and automation frameworks, etc. etc.)

For some more context on Tcl, Salvatore Sanfilippo's 2006 article is worth a read: http://antirez.com/articoli/tclmisunderstood.html - Note that in the years since it was penned, many of the language's direction issues have been resolved and the recent 8.6 release shows a solid return to form.

= Mike

[Gregory N]

Hello,

Post by Mohammad Elwakeel
It might seem a bit odd, but why don't we think of Lua scripting language.
I mean, it also works well with C and the lua C runtime is not that
challenge to port.

There are two different discussions involving scripting languages here and I think the topics are getting confused.

First, there is a discussion about the logistics of providing runtime support for Lua and Go in NuttX. Lua has already been ported but is in limbo (see http://tech.groups.yahoo.com/group/nuttx/files/lua/). These are scripting languages that run on the target.

Then there is unrelated discussion of using Tcl/Tk on the host (not target) to support configuration. This is being considered because the kconfig-frontends don't port well to Windows. Tcl/Tk, on the other hand, is at least available on all platforms and a nearly compatible Tcl/Tk configurator is available from the Linux 2.4 kernel.

There has been no discussion (yet) of porting Tcl/Tk to NuttX.

Greg

[David Alessio]

In an effort to add to the confusion let me suggest wxLua would be a good
cross-platform candidate for the config GUI.

Taking a step or two back, why reinvent the wheel? What's wrong with using
the "make [gqx]config" from the Linux 3.x tree?

Post by Mohammad Elwakeel
**
Hello,

Post by Mohammad Elwakeel
It might seem a bit odd, but why don't we think of Lua scripting

language.

Post by Mohammad Elwakeel
I mean, it also works well with C and the lua C runtime is not that
challenge to port.

There are two different discussions involving scripting languages here and
I think the topics are getting confused.
First, there is a discussion about the logistics of providing runtime
support for Lua and Go in NuttX. Lua has already been ported but is in
limbo (see http://tech.groups.yahoo.com/group/nuttx/files/lua/). These
are scripting languages that run on the target.
Then there is unrelated discussion of using Tcl/Tk on the host (not
target) to support configuration. This is being considered because the
kconfig-frontends don't port well to Windows. Tcl/Tk, on the other hand, is
at least available on all platforms and a nearly compatible Tcl/Tk
configurator is available from the Linux 2.4 kernel.
There has been no discussion (yet) of porting Tcl/Tk to NuttX.
Greg

[Richard Cochran]

Post by David Alessio
In an effort to add to the confusion let me suggest wxLua would be a good
cross-platform candidate for the config GUI.

I really dislike wxWidgets. Every single time I have used it, it was awful.

Post by David Alessio
Taking a step or two back, why reinvent the wheel? What's wrong with using
the "make [gqx]config" from the Linux 3.x tree?

xconfig - does not exist, alias for qconfig
qconfig - getting Qt development libs on windows is a pain
gconfig - getting gtk development libs on windows is an even bigger pain

That is why.

Thanks,
Richard

[Gong Darcy]

hi Greg,

I don't use the Lua cause stm32f107 memory is too small... Network
environment and Lua cannot be used at the same time. Now I use sh
script functions.
Recently I was ordered to do research on android. By titanium moblie.
Temporarily unable to learn nuttx.

darcy

Post by Mohammad Elwakeel
Hello,

Post by Mohammad Elwakeel
It might seem a bit odd, but why don't we think of Lua scripting language.
I mean, it also works well with C and the lua C runtime is not that
challenge to port.

There are two different discussions involving scripting languages here and I
think the topics are getting confused.
First, there is a discussion about the logistics of providing runtime
support for Lua and Go in NuttX. Lua has already been ported but is in limbo
(see http://tech.groups.yahoo.com/group/nuttx/files/lua/). These are
scripting languages that run on the target.
Then there is unrelated discussion of using Tcl/Tk on the host (not target)
to support configuration. This is being considered because the
kconfig-frontends don't port well to Windows. Tcl/Tk, on the other hand, is
at least available on all platforms and a nearly compatible Tcl/Tk
configurator is available from the Linux 2.4 kernel.
There has been no discussion (yet) of porting Tcl/Tk to NuttX.
Greg

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/nuttx/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/nuttx/join
(Yahoo! ID required)

<*> To change settings via email:
nuttx-digest-***@public.gmane.org
nuttx-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
nuttx-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Paul.Y.Zhang]

Hi, Darcy,

What about Lua on stm32f407, which embeds 512K/1MB flash and 192KB RAM,
is it enough?

- Paul

Post by Gong Darcy
hi Greg,
I don't use the Lua cause stm32f107 memory is too small... Network
environment and Lua cannot be used at the same time. Now I use sh
script functions.
Recently I was ordered to do research on android. By titanium moblie.
Temporarily unable to learn nuttx.
darcy

Post by Mohammad Elwakeel
Hello,

Post by Mohammad Elwakeel
It might seem a bit odd, but why don't we think of Lua scripting language.
I mean, it also works well with C and the lua C runtime is not that
challenge to port.

There are two different discussions involving scripting languages here and I
think the topics are getting confused.
First, there is a discussion about the logistics of providing runtime
support for Lua and Go in NuttX. Lua has already been ported but is in limbo
(see http://tech.groups.yahoo.com/group/nuttx/files/lua/). These are
scripting languages that run on the target.
Then there is unrelated discussion of using Tcl/Tk on the host (not target)
to support configuration. This is being considered because the
kconfig-frontends don't port well to Windows. Tcl/Tk, on the other hand, is
at least available on all platforms and a nearly compatible Tcl/Tk
configurator is available from the Linux 2.4 kernel.
There has been no discussion (yet) of porting Tcl/Tk to NuttX.
Greg

------------------------------------
Yahoo! Groups Links

[David Alessio]

Hi Darcy,

You might also consider the NXP LPC43xx series (fastest Cortex M4, 204 MHz) with 264k SRAM (external RAM also possible). The LPC43xx series is actually a dual processor core, Cortex M4 for the main OS, and an M0 for IO if needed.

Regards,
-david

Post by Paul.Y.Zhang
Hi, Darcy,
What about Lua on stm32f407, which embeds 512K/1MB flash and 192KB RAM,
is it enough?
- Paul

Post by Gong Darcy
hi Greg,
I don't use the Lua cause stm32f107 memory is too small... Network
environment and Lua cannot be used at the same time. Now I use sh
script functions.
Recently I was ordered to do research on android. By titanium moblie.
Temporarily unable to learn nuttx.
darcy

Post by Mohammad Elwakeel
Hello,

Post by Mohammad Elwakeel
It might seem a bit odd, but why don't we think of Lua scripting language.
I mean, it also works well with C and the lua C runtime is not that
challenge to port.

There are two different discussions involving scripting languages here and I
think the topics are getting confused.
First, there is a discussion about the logistics of providing runtime
support for Lua and Go in NuttX. Lua has already been ported but is in limbo
(see http://tech.groups.yahoo.com/group/nuttx/files/lua/). These are
scripting languages that run on the target.
Then there is unrelated discussion of using Tcl/Tk on the host (not target)
to support configuration. This is being considered because the
kconfig-frontends don't port well to Windows. Tcl/Tk, on the other hand, is
at least available on all platforms and a nearly compatible Tcl/Tk
configurator is available from the Linux 2.4 kernel.
There has been no discussion (yet) of porting Tcl/Tk to NuttX.
Greg

------------------------------------
Yahoo! Groups Links

--
Paul

[Michael Smith]

Paul,

I posted patches a while back to the list that integrate lua 5.2.1 with NuttX. They were developed on the STM32F4.

= Mike

Post by Paul.Y.Zhang
Hi, Darcy,
What about Lua on stm32f407, which embeds 512K/1MB flash and 192KB RAM,
is it enough?
- Paul

Post by Gong Darcy
hi Greg,
I don't use the Lua cause stm32f107 memory is too small... Network
environment and Lua cannot be used at the same time. Now I use sh
script functions.
Recently I was ordered to do research on android. By titanium moblie.
Temporarily unable to learn nuttx.
darcy

Post by Mohammad Elwakeel
Hello,

Post by Mohammad Elwakeel
It might seem a bit odd, but why don't we think of Lua scripting language.
I mean, it also works well with C and the lua C runtime is not that
challenge to port.

There are two different discussions involving scripting languages here and I
think the topics are getting confused.
First, there is a discussion about the logistics of providing runtime
support for Lua and Go in NuttX. Lua has already been ported but is in limbo
(see http://tech.groups.yahoo.com/group/nuttx/files/lua/). These are
scripting languages that run on the target.
Then there is unrelated discussion of using Tcl/Tk on the host (not target)
to support configuration. This is being considered because the
kconfig-frontends don't port well to Windows. Tcl/Tk, on the other hand, is
at least available on all platforms and a nearly compatible Tcl/Tk
configurator is available from the Linux 2.4 kernel.
There has been no discussion (yet) of porting Tcl/Tk to NuttX.
Greg

------------------------------------
Yahoo! Groups Links

--
Paul

[Paul.Y.Zhang]

Mike,

Thanks. But I am still strugling with STM32F4 openocd (on windows) +
stlink +gdb(in cygwin). It still can not work normally.

Paul

Post by Michael Smith
Paul,
I posted patches a while back to the list that integrate lua 5.2.1
with NuttX. They were developed on the STM32F4.
= Mike

Post by Paul.Y.Zhang
Hi, Darcy,
What about Lua on stm32f407, which embeds 512K/1MB flash and 192KB RAM,
is it enough?
- Paul

Post by Gong Darcy
hi Greg,
I don't use the Lua cause stm32f107 memory is too small... Network
environment and Lua cannot be used at the same time. Now I use sh
script functions.
Recently I was ordered to do research on android. By titanium moblie.
Temporarily unable to learn nuttx.
darcy

Post by Mohammad Elwakeel
Hello,

Post by Mohammad Elwakeel
It might seem a bit odd, but why don't we think of Lua scripting

language.

Post by Gong Darcy

Post by Mohammad Elwakeel

Post by Mohammad Elwakeel
I mean, it also works well with C and the lua C runtime is not that
challenge to port.

There are two different discussions involving scripting languages

here and I

Post by Gong Darcy

Post by Mohammad Elwakeel
think the topics are getting confused.
First, there is a discussion about the logistics of providing runtime
support for Lua and Go in NuttX. Lua has already been ported but

is in limbo

Post by Gong Darcy

Post by Mohammad Elwakeel
(see http://tech.groups.yahoo.com/group/nuttx/files/lua/). These are
scripting languages that run on the target.
Then there is unrelated discussion of using Tcl/Tk on the host

(not target)

Post by Gong Darcy

Post by Mohammad Elwakeel
to support configuration. This is being considered because the
kconfig-frontends don't port well to Windows. Tcl/Tk, on the other

hand, is

Post by Gong Darcy

Post by Mohammad Elwakeel
at least available on all platforms and a nearly compatible Tcl/Tk
configurator is available from the Linux 2.4 kernel.
There has been no discussion (yet) of porting Tcl/Tk to NuttX.
Greg

------------------------------------
Yahoo! Groups Links

--
Paul

[Michael Smith]

You should be able to run the stlink gdb proxy directly, without having to involve openocd.

= Mike

Mike,
Thanks. But I am still strugling with STM32F4 openocd (on windows) + stlink +gdb(in cygwin). It still can not work normally.
Paul

Post by Michael Smith
Paul,
I posted patches a while back to the list that integrate lua 5.2.1 with NuttX. They were developed on the STM32F4.
= Mike

Post by Paul.Y.Zhang
Hi, Darcy,
What about Lua on stm32f407, which embeds 512K/1MB flash and 192KB RAM,
is it enough?
- Paul

Post by Gong Darcy
hi Greg,
I don't use the Lua cause stm32f107 memory is too small... Network
environment and Lua cannot be used at the same time. Now I use sh
script functions.
Recently I was ordered to do research on android. By titanium moblie.
Temporarily unable to learn nuttx.
darcy

Post by Mohammad Elwakeel
Hello,

Post by Mohammad Elwakeel
It might seem a bit odd, but why don't we think of Lua scripting language.
I mean, it also works well with C and the lua C runtime is not that
challenge to port.

There are two different discussions involving scripting languages here and I
think the topics are getting confused.
First, there is a discussion about the logistics of providing runtime
support for Lua and Go in NuttX. Lua has already been ported but is in limbo
(see http://tech.groups.yahoo.com/group/nuttx/files/lua/). These are
scripting languages that run on the target.
Then there is unrelated discussion of using Tcl/Tk on the host (not target)
to support configuration. This is being considered because the
kconfig-frontends don't port well to Windows. Tcl/Tk, on the other hand, is
at least available on all platforms and a nearly compatible Tcl/Tk
configurator is available from the Linux 2.4 kernel.
There has been no discussion (yet) of porting Tcl/Tk to NuttX.
Greg

------------------------------------
Yahoo! Groups Links

--
Paul

--
Paul

[Paul.Y.Zhang]

Hi Mike,

Excuse me, what's the meaning "stlink gdb proxy" you mentioned?

- Paul

Post by Michael Smith
You should be able to run the stlink gdb proxy directly, without having to involve openocd.
= Mike

[Mike Smith]

It's sometimes referred to as a "gdb server"; see here: http://www.chibios.org/dokuwiki/doku.php?id=chibios:guides:stlink_eclipse

= Mike

Post by Paul.Y.Zhang
Hi Mike,
Excuse me, what's the meaning "stlink gdb proxy" you mentioned?
- Paul

Post by Michael Smith
You should be able to run the stlink gdb proxy directly, without
having to involve openocd.
= Mike

--
Paul

[Gerd v. Egidy]

Hi Paul,

Post by Paul.Y.Zhang
Thanks. But I am still strugling with STM32F4 openocd (on windows) +
stlink +gdb(in cygwin). It still can not work normally.

Which version of openocd are you using? Before 0.6.1 I had to apply some
patches to make it work, but since 0.6.1 it works out of the box for me. But
I'm using Linux, haven't tried it on windows.

One issue I had was that nuttx lets the MCU sleep when idle. When the
sleepmode is active, the debugger can usually not connect to it. But there is
a register to keep the debugging macrocell active even in sleep mode.

Here is what I added to my openocd board config to activate this:

source [find mem_helper.tcl]

$_TARGETNAME configure -event reset-init {
# allow debugging during sleep/stop/standby modes:
# set DBG_SLEEP, DBG_STOP and DBG_STANDBY bits in DBGMCU_CR
mmw 0xe0042004 0x7 0x0
}

Maybe this helps you too.

Kind regards,

Gerd

[Freddie Chopin]

Post by Gerd v. Egidy
One issue I had was that nuttx lets the MCU sleep when idle. When the
sleepmode is active, the debugger can usually not connect to it. But there is
a register to keep the debugging macrocell active even in sleep mode.
source [find mem_helper.tcl]
$_TARGETNAME configure -event reset-init {
# set DBG_SLEEP, DBG_STOP and DBG_STANDBY bits in DBGMCU_CR
mmw 0xe0042004 0x7 0x0
}
Maybe this helps you too.

That's exactly what this mini-article is about:
http://nuttx.org/doku.php?id=wiki:howtos:jtag-debugging
(;

4\/3!!

[Paul.Y.Zhang]

Greg, Mike, Freddie, Gerd, Darcy, ...

Thank you! Nuttx worked with Segger J-link GDBserver finally.
Exciting! :-)

I tried severial gdbservers (OpenOCD on stlink, Atollic gdbserver on
stlink, Segger on J-link) with different build tools(codesourcery,
buildroot, freescale's ...), finally it worked. From my experiments, the
result seems Segger Jlink GDBserver is best. OpenOCD also works, but
maybe not good as Segger.

Anyway, thanks for all your zeal.

Paul

Post by Freddie Chopin

Post by Gerd v. Egidy
One issue I had was that nuttx lets the MCU sleep when idle. When the
sleepmode is active, the debugger can usually not connect to it. But there is
a register to keep the debugging macrocell active even in sleep mode.
source [find mem_helper.tcl]
$_TARGETNAME configure -event reset-init {
# set DBG_SLEEP, DBG_STOP and DBG_STANDBY bits in DBGMCU_CR
mmw 0xe0042004 0x7 0x0
}
Maybe this helps you too.

http://nuttx.org/doku.php?id=wiki:howtos:jtag-debugging
(;
4\/3!!

[Gong Darcy]

hi Greg,

see this http://dl.dropbox.com/u/10406197/kconfiglib.html and
https://github.com/ulfalizer/Kconfiglib
Using Python implementation of the kconfig configuration function. Because
Python can run under windows, so I think, requires only minor
adjustmentskconfiglibcan achieveyourfunction
. I have not tested this library. But browse the code. There are menu
package and other functions. Should be amended to replace kconfig.

darcy

**

Yesterday I released NuttX-6.24 with the first "advertised" native

Windows build support. There are still two big missing parts: (1) a
configure.sh counterpart, and much more importanly (2) mconf running
natively under in a CMD.exe shell under Windows.
Since writing that, I have solved (1). There is now a tools/configure.bat
and a tools/configure.c. The configure.bat is just a thin layer: If checks
if configure.exe exists, then executes it to instantiate the configuration.
If configure.exe does not exist, then it first creates it using
minggw-gcc.exe
But (2) is still an issue.
Lately, I have been tinkering with pieces of kconfig-frontends and I am
The kconfig-frontends depends on low-level YACC/LEX code. The YACC/LEX
code generates a data set describing the configuration and provides C
interfaces to manage the configuration data set. This is the "back end"
used by all of the kconfig-frontends: The frontends basically provide the
different user experience and the backend manages the configuration.
The C code generated from the YACC/LEX has no dependencies at all (other
than libintl which is not a big issue) and so is portable. The frontends
(other than 'conf') do have major system dependencies and, hence, are the
root of the portability problem.
I believe that I could modify the YACC code so that instead of generating
a data set it would generate another interpreted program. In fact, the
logic for create such a program for the case of Tcl/Tk already exists in
the Linux 2.4 kernel. See for example,
http://fxr.watson.org/fxr/source/scripts/?v=linux-2.4.22.
The format of the configuration files was different in the 2.4 kernel
(Config.in files vs Kconfig files), but functionally equivalent.
When you did 'make xconfig' in the 2.4 kernel, a two step process was
initiated. In the first step, the logic in scripts/Makefile ran. The
kconfig.tk target in that Makefile created the Tcl program. Then in the
second step, the top-level Makefile executed the Tcl/Tk program. The
configuration was then done with the Tcl/Tk GUI which is nicer than the
mconf GUI, but not as nice as the gconf GUI.
The file scripts/tkparse.c did all of the work and could easily be
leveraged to generate a Tcl program in the same way (
http://fxr.watson.org/fxr/source/scripts/tkparse.c?v=linux-2.4.22). That
would be almost free. Tcl/Tk is available for Windows, but it not so
commonly used.
The reason later kernels did not use Tcl/Tk is due largely to the fact
that many people do not like Tcl/Tk. But perhaps a similar configuration
strategy using some Windows-friendly scripting language like C# or
Java/Swing might be appropriate?
1) The kconfig-frontends works nicely in many environments (Linux, Cygwin,
..), but not native Windows. It cannot be build directly under native
Windows. You cannot even configure it under Windows because the
configuration script is bash script.
2) There are some round-about ways to get a Windows kconfig-frontends
mconf executable. (a) Using MSYS, but the build process is much more
complex than the average person can handle and there are bugs in pdcurses
that prevent it from working properly. Or (b) using Cygwin but this
requires a large installation and the tool will not work properly outside
of the Cygwin "sandbox" without a lot of special setup.
Use a simple C program to auto-generate a Windows-compatible script to do
the configuration. The creation program would only depend on mingw-gcc and
the generated script would to fully compatible with the Windows
environment, perhaps C# or Java/Swing.
Any inputs? As you see, I am still struggling with a solution that the
would work well, be easy to use and would not require many special tools.
Any thoughts?
Greg

[Gregory Nutt]

Hi, Darcy,

see this http://dl.dropbox.com/u/10406197/kconfiglib.html and https://github.com/ulfalizer/Kconfiglib

Using Python implementation of the kconfig configuration function.Because Python can run under windows,so I think,requires only mino adjustments kconfig lib can achieve your function.I have not tested this library. But browse the code.There are menu package and other functions.Should be amended toreplace kconfig.

Very interesting.  Thanks for the links!

This seems to be the Python equivalent of the kconfig-frontends parser (see http://ymorin.is-a-geek.org/hg/kconfig-frontends/file/4a8dfa9d75a6/libs/parser).  I did not see any GUI code there or in the examples.  But I did not examine the code carefully.  I think that it would be necessary to develop a Python GUI front end of some kind.  Isn't that true?  I don't know anything about Python.  How easy is is to develop GUIs with Python?  I am not qualified to do that without some Python learning.


The kconfig-frontends parser is not a problem under Windows.  It is YACC/LEX based but the resulting C code builds cleanly under Windows with no depenendencies (other than libintl which is easily removed).  Keeping the YACC will help to adapt to changes to the kconfig language as it evolves.


With Python kconfig parser there are then four ways to solve the problem:

1) Get kconfig-frontends building and running natively under Windows.  Certainly building it natively is not going to happen since it is so dependent on Bash configure scripts, automake, Linux libraries, etc..  kconfig-frontends can be built under Cygwin or MSYS, but (1) so far, none of these solutions are usable in the native Windows environment for various reasons, and (2) this would require a binary distribution of tools for the native Windows user and so far I have not been in the business of distributing binaries.

2) Extract the parser from kconfig-frontends and develop a native Windows C++ front end.  This actually might not be difficult using Visual Studio and lots of GUI wizards.  I have not considered this.  I don't own a recent copy of Visual Studio and am not sufficiently courageous to try with is MinGW-GCC.


3) Extract the parser from kconfig-frontends and develop a simple C application that auto-generates a Windows-friendly script in say, C#, Java/Swing, or Tcl/Tk.  This seems pretty easy given the available resources.  This is why Tcl./Tk is getting discussion.


4) And now... Use Kconfiglib and develop a Python GUI front end.  I don't know enough about Python to comment beyond this.

Greg

[Richard Cochran]

Post by Gregory Nutt
4) And now... Use Kconfiglib and develop a Python GUI front end.  I
don't know enough about Python to comment beyond this.

You *can* write a python gui, if you know what you are doing. There
are multiple gui toolkits to choose from, and one of them is tk!

http://docs.python.org/2/faq/gui.html

Still you have to choose the toolkit carefully in order to ensure that
it really works cross platform. I don't have any experience with this
sort of python, but I imagine that it can be done.

Thanks,
Richard

[Gong Darcy]

hi Greg,

I recently busy. I think the weekend will test the library, to write anexample
.

I want to do pyqt GUI, or delphi+python can be.

It is also found that the PHP of a kconfig parser.

Http://torkiljohnsen.com/nooku-framework-documentation/Koowa_Config/KConfig.html

The grammar of PHP and C similar.

Through the command line call, can also generate menu and configuration.
http://code.google.com/p/php5delphi/ In Delphi using php.

darcy

Post by Paul.Y.Zhang
**
Hi, Darcy,

Post by Gong Darcy
see this http://dl.dropbox.com/u/10406197/kconfiglib.html and

https://github.com/ulfalizer/Kconfiglib
Using Python implementation of the kconfig configuration function.Because
Python can run under windows,so I think,requires only mino adjustments
kconfig lib can achieve your function.I have not tested this library. But
browse the code.There are menu package and other functions.Should be
amended toreplace kconfig.
Very interesting. Thanks for the links!
This seems to be the Python equivalent of the kconfig-frontends parser
(see
http://ymorin.is-a-geek.org/hg/kconfig-frontends/file/4a8dfa9d75a6/libs/parser).
I did not see any GUI code there or in the examples. But I did not examine
the code carefully. I think that it would be necessary to develop a Python
GUI front end of some kind. Isn't that true? I don't know anything about
Python. How easy is is to develop GUIs with Python? I am not qualified to
do that without some Python learning.
The kconfig-frontends parser is not a problem under Windows. It is
YACC/LEX based but the resulting C code builds cleanly under Windows with
no depenendencies (other than libintl which is easily removed). Keeping
the YACC will help to adapt to changes to the kconfig language as it
evolves.
1) Get kconfig-frontends building and running natively under Windows.
Certainly building it natively is not going to happen since it is so
dependent on Bash configure scripts, automake, Linux libraries, etc..
kconfig-frontends can be built under Cygwin or MSYS, but (1) so far, none
of these solutions are usable in the native Windows environment for various
reasons, and (2) this would require a binary distribution of tools for the
native Windows user and so far I have not been in the business of
distributing binaries.
2) Extract the parser from kconfig-frontends and develop a native Windows
C++ front end. This actually might not be difficult using Visual Studio
and lots of GUI wizards. I have not considered this. I don't own a recent
copy of Visual Studio and am not sufficiently courageous to try with is
MinGW-GCC.
3) Extract the parser from kconfig-frontends and develop a simple C
application that auto-generates a Windows-friendly script in say, C#,
Java/Swing, or Tcl/Tk. This seems pretty easy given the available
resources. This is why Tcl./Tk is getting discussion.
4) And now... Use Kconfiglib and develop a Python GUI front end. I don't
know enough about Python to comment beyond this.
Greg