For nuttx port some functional modules

[Gong Darcy]

hi all,

I plan to port certain modules to nuttx.

Do not know whether there are people willing to get involved.

1) elua script langage

2) pawn script langage

3) Chibi ( 802.15.4 Wireless )

4) btstack Bluetooth protocol stack, UART or USB port )

I think elua is most easily.

Chibi is not difficult, but he mainly uses at86rf230 chip module. I
can't buy off-the-shelf modules, want to use cc2520 to replace.

Btstack itself can be used in uCOS. GitHub is a uubt project is based
on the chibios. I want to port to the nuttx, but the USB part I am not
familiar with.

regards

darcy

[Gregory N]

Hi, Darcy,

Post by Gong Darcy
I plan to port certain modules to nuttx.
Do not know whether there are people willing to get involved.
1) elua script langage
2) pawn script langage
3) Chibi ( 802.15.4 Wireless )
4) btstack Bluetooth protocol stack, UART or USB port )
I think elua is most easily.
Chibi is not difficult, but he mainly uses at86rf230 chip module. I
can't buy off-the-shelf modules, want to use cc2520 to replace.
Btstack itself can be used in uCOS. GitHub is a uubt project is based
on the chibios. I want to port to the nuttx, but the USB part I am not
familiar with.

There is an issue about what should be done with these ports when you complete them. I don't think that there should be forks in the NuttX source tree. That is a dead-end solution. I cannot support them (some are bigger than NuttX) and they will become obsolete in a few months. So it does not make sense to check them into the NuttX SVN.

I have checked a few things smaller projects into NuttX (like FreeModBus, for example), but that is because the projects were small and the open source projects have been abandoned.

But if the projects are large and/or active, the change for NuttX support should be incorporated into the correct repository, not NuttX. For example, I have spoken with Yann Morin who runs the kconfig-frontends projects. He will be happy to incorporate the Windows support when it is functional.

Greg

[Sebastien Lorquet]

Post by Gregory N
But if the projects are large and/or active, the change for NuttX support
should be incorporated into the correct repository, not NuttX. For example, I
have spoken with Yann Morin who runs the kconfig-frontends projects. He will
be happy to incorporate the Windows support when it is functional.

Well, if pdcurses lacks functionnality to edit text fields, then we're stuck there.
We can give Yann Morin a patch to make the code compile in msys, but it will
create a malfunctioning binary, so... not very useful...

Sebastien

[Gregory Nutt]

Post by Sebastien Lorquet

Post by Gregory N
But if the projects are large and/or active, the change for NuttX support should be incorporated into the correct repository, not NuttX. For example, I have spoken with Yann Morin who runs the kconfig-frontends projects. He will be happy to incorporate the Windows support when it is functional.

Well, if pdcurses lacks functionnality to edit text fields, then we're stuck there.
We can give Yann Morin a patch to make the code compile in msys, but  it will create a malfunctioning binary, so... not very useful...

Perhaps mconf or qconf will not be usable, but it still ought to be possible to use conf which gets started by:

make config

Although not as pretty as mconf or qconf output, it still has value.  It is better than hand-modifying configuration files.


Greg

[Sebastien Lorquet]

Ah, if you see it that way, then it makes sense, yes.

Regards
Sebastien

Post by Gregory N

Post by Sebastien Lorquet

Post by Gregory N
But if the projects are large and/or active, the change for NuttX support

should be incorporated into the correct repository, not NuttX. For example, I
have spoken with Yann Morin who runs the kconfig-frontends projects. He will
be happy to incorporate the Windows support when it is functional.

Post by Sebastien Lorquet
Well, if pdcurses lacks functionnality to edit text fields, then we're stuck

there.

Post by Sebastien Lorquet
We can give Yann Morin a patch to make the code compile in msys, but it

will create a malfunctioning binary, so... not very useful...
Perhaps mconf or qconf will not be usable, but it still ought to be possible
make config
Although not as pretty as mconf or qconf output, it still has value. It is
better than hand-modifying configuration files.
Greg

[Gregory N]

Post by Sebastien Lorquet
Well, if pdcurses lacks functionnality to edit text fields, then we're stuck there.
We can give Yann Morin a patch to make the code compile in msys, but it will
create a malfunctioning binary, so... not very useful...

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.

This morning I was thinking: I build mconf under Cygwin and run it all of the time. There are no issues with edit text fields in the Cygwin mconf. It works great. And the Cygwin mconf build works right out of the box with no code changes or mysterious libraries.

So if the Cygwin mconf works without issues, then perhaps the only thing that we might need to do is to get the the Cygwin mconf packaged so that it runs under a native CMD.exe window. It turns out that this might not be too difficult.

(I actually use the ConEmu window instead of the stock cmd window because it has a few more creature comforts.)

Post by Sebastien Lorquet
cd \cygwin\home\patacongo\projects\nuttx\nuttx-code\nuttx
\cygwin\usr\local\bin\mconf Kconfig

This did not work because mconf could not find cyggcc_s-1.dll which is located in \cygwin\bin. There must be some Windows environment variable that controls the library search path. If so, then \cygwin\bin needs to be added to that path. (Does anyone know how to do that?)

Post by Sebastien Lorquet
cd \cygwin\bin
\cygwin\usr\local\bin\mconf cygwin\home\patacongo\projects\nuttx\nuttx-code\nuttx\Kconfig

And this almost worked. mconf started and complained that it could not find arch/Kconfig which is included by the top-level Kconf. This is not surprising since the current directory is \cygwin\bin and there is no arch/Kconfig there.

3) For testing, I simply removed the source commands from the top-level Kconf and tried again. I was surprised to see that the Cygwin ncurses appears to work in the CMD.exe window! See ConEmuKconfig.png at http://tech.groups.yahoo.com/group/nuttx/files/.

Of course, the display is not correct because mconf could not find .config in the current directory (hence, it asks to load a .config file).

When I exit and save the .config file, mconfig saves a generic .config file at \cygwin\bin.

So there are a few issues but it seems to me that this passes some basic proof of concept. It might be possible to use a properly wrapped Cygwin mconf program to provide the configurator in a Windows CMD.exe window.

Thoughts?

Greg

[Gregory N]

Post by Gregory N
Of course, the display is not correct because mconf could not find .config in the current directory (hence, it asks to load a .config file).

By copying .config and Kconfig to \cygwin\bin. I was able to run mconfig normally from \cygwin\bin. I was able to verify that the text edit fields work perfectly well in the CMD.exe shell.

I think that the Cygwin will work fine... but I will need to tinker with it more.

Greg

[Freddie Chopin]

Post by Gregory N
This did not work because mconf could not find cyggcc_s-1.dll which is
located in \cygwin\bin. There must be some Windows environment variable
that controls the library search path. If so, then \cygwin\bin needs to
be added to that path. (Does anyone know how to do that?)

Yest, there is - it's called PATH. Windows first searches for the DLL in
the folder where the binary is (or the folder you're running it from?),
than it checks the folders from PATH. The easiest solution is to have
the DLLs with the binary in the same folder.

4\/3!!

[Gregory N]

Post by Freddie Chopin

Post by Gregory N
This did not work because mconf could not find cyggcc_s-1.dll which is
located in \cygwin\bin. There must be some Windows environment variable
that controls the library search path. If so, then \cygwin\bin needs to
be added to that path. (Does anyone know how to do that?)

Yest, there is - it's called PATH. Windows first searches for the DLL in
the folder where the binary is (or the folder you're running it from?),
than it checks the folders from PATH. The easiest solution is to have
the DLLs with the binary in the same folder.

Thanks, Freddie. That does the job and at least lets me get to the next level of problems. I am embarassed by my ignornance of Windows, but that is the way it is.

I tried creating a little directory with that just bundles all of the Cygwin DLLs need to run mconf. Here is what I came up with:

$ ls -l kconfig-frontends/
total 3404
-rwxr-xr-x 1 patacongo None 220035 Dec 22 07:03 conf.exe
-rwxr-xr-x 1 patacongo None 44558 Dec 22 07:09 cyggcc_s-1.dll
-rwxr-xr-x 1 patacongo None 249870 Dec 22 07:11 cygncursesw-10.dll
-rwxr-xr-x 1 patacongo None 2666500 Dec 22 07:09 cygwin1.dll
-rwxr-xr-x 1 patacongo None 291418 Dec 22 07:02 mconf.exe

But this is still not usable. Here is a summary of all of the problems that I see now.

1) Getting the APPSDIR from an environment variable in the top-level Kconfig does not work. I suspect that this is because the Cygwin mconf will use the Cygwin environment variables and not the Windows environment varialbes.

config APPSDIR
string
- option env="APPSDIR"
+ default "../apps"

2) And possibly related to 1), mconf fails to source the APPSDIR Kconfig file.

Kconfig:484 can't open file "../apps/Kconfig"

The other sourced Kconfig files are accessed with no problem... only this one generates the error.

[Continued testing with 'source "$APPSDIR/Kconfig"' removed]

3) Then I get this error:

Error opening terminal: cygwin

I gather from from Googling that this has to do with failing to find the terminal in the terminfo data.

a) mconf works fine in the CMD.exe window if I execute it from \cygwin\bin, but
b) does not work if I just add \cygwin\bin to the PATH variable and try to execute it in the NuttX directory.
c) However, if I add \cygwin\usr\local\bin;\cygwin\usr\bin;\cygwin\bin to the PATH variable, mconf works does work correctly in the CMD.exe shell.

4) conf.exe works fine in all contexts.

I am thinking that it may not be easy to detangle mconf from Cygwin.

Greg

[Freddie Chopin]

Some time ago I've heard that there's an option (or a define?) that
would tell cygwin's gcc to generate a binary that would be more stand-alone.

http://www.delorie.com/howto/cygwin/mno-cygwin-howto.html

I don't know whether that option works still, as I've also heard it was
removed.

4\/3!!

[Freddie Chopin]

Post by Freddie Chopin
I don't know whether that option works still, as I've also heard it was
removed.

Indeed, I've just found info that this option was long deprecated and
removed in gcc 4.7.0.

4\/3!!

[Sébastien Lorquet]

to get rid of dll dependencies I think that the -Bstatic gcc option
(when called as a linker) will use static libs instead of DLLs.
I don't know if cygwin libs are available as static libs.

The other option would be to understand what goes into
cygncursesw-1.0.dll and port whatever is required to fix pdcurses!
Then a mingw build could produce a working mingw binary, just like the
gnuwin32 ones.
We weren't so far from a native win32 mconf.exe, only the text box did
not work.

Sebastien

Post by Freddie Chopin

Post by Freddie Chopin
I don't know whether that option works still, as I've also heard it was
removed.

Indeed, I've just found info that this option was long deprecated and
removed in gcc 4.7.0.
4\/3!!

[Gregory N]

Post by Sébastien Lorquet
to get rid of dll dependencies I think that the -Bstatic gcc option
(when called as a linker) will use static libs instead of DLLs.
I don't know if cygwin libs are available as static libs.

I don't see any cygwin*.a files, but they might be hidden somewhere.

But this is really just a packaging issue. There are really only two issues that I know of:

1) The Packaging Issue

All of the DLLs that are needed are those that I listed in a previous email. But something else is needed (not a DLL). That is something to do with the terminfo data. With just the DLLs, the code fails because it cannot open the console.

If I execute in the CMD.exe shell with the PATH variable set up to access Cygwin's /usr/local/bin, /usr/bin, and /bin directories, then mconf works fine under the CMD.exe window. The terminal is recognized and opened and the ncurses works well in it (see the updated ConEmuKconfig.png at http://tech.groups.yahoo.com/group/nuttx/files/).

But this is not a good solution. This would preclude using GNUWin32 (I am using a .bat file that temporarily sets the PATH variable to run Cygwin code, then restores the original PATH when it is done).

2) An environment variable issue.

The current Kconfig implementation uses environment variables to locate the apps/ directory. The syntax in the top level Kconfig file to get the the value of the environment variable does not work when the Cygwin mconf is run in the CMD.exe window.

set APPSDIR=%appsdir%
mconf Kconfig

mconfig then reports that APPSDIR is not defined, presumably because mconf cannot see the DOS environment?

My understanding is that bash will sample and convert all of the DOS paths when it starts. But perhaps this logic is doesn't happen when mconf runs outside of Bash.

The above reference .PNG was created from an CMD.exe window with 1) the PATH variable modified as above,and 2) this change to the top-level Kconfig:

config APPSDIR
string
- option env="APPSDIR"
+ default "../apps"

Post by Sébastien Lorquet
The other option would be to understand what goes into
cygncursesw-1.0.dll and port whatever is required to fix pdcurses!
Then a mingw build could produce a working mingw binary, just like the
gnuwin32 ones.
We weren't so far from a native win32 mconf.exe, only the text box did
not work.

This could be a pretty big project, however. I don't know if anyone wants to take on fixing pdcurses.

Greg

[Gong Darcy]

hi Greg,

I don't understand, these are very useful features?
For example, a scripting language.
Because nuttx shell no such as " do... While " or " for " this kind of
cycle control.
If they do not fit as a core component library. On the apps as an
additional function library is also good.
Bluetooth and 802.15.4 communication is very important. I think you will love.

I know you are busy, I hope that other friends can participate in the
development of.
I hardware development experience. Hope to jointly study to find
someone. I am very difficult in the short term solutions to these
problems.

regards
darcy

Post by Gregory N
Hi, Darcy,

Post by Gong Darcy
I plan to port certain modules to nuttx.
Do not know whether there are people willing to get involved.
1) elua script langage
2) pawn script langage
3) Chibi ( 802.15.4 Wireless )
4) btstack Bluetooth protocol stack, UART or USB port )
I think elua is most easily.
Chibi is not difficult, but he mainly uses at86rf230 chip module. I
can't buy off-the-shelf modules, want to use cc2520 to replace.
Btstack itself can be used in uCOS. GitHub is a uubt project is based
on the chibios. I want to port to the nuttx, but the USB part I am not
familiar with.

There is an issue about what should be done with these ports when you complete them. I don't think that there should be forks in the NuttX source tree. That is a dead-end solution. I cannot support them (some are bigger than NuttX) and they will become obsolete in a few months. So it does not make sense to check them into the NuttX SVN.
I have checked a few things smaller projects into NuttX (like FreeModBus, for example), but that is because the projects were small and the open source projects have been abandoned.
But if the projects are large and/or active, the change for NuttX support should be incorporated into the correct repository, not NuttX. For example, I have spoken with Yann Morin who runs the kconfig-frontends projects. He will be happy to incorporate the Windows support when it is functional.
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/

[Gregory Nutt]

Hi, Darcy,

Post by Gong Darcy
I don't understand, these are very useful features?
For example, a scripting language.
Because nuttx shell no such as " do... While " or " for " this kind of
cycle control.
If they do not fit as a core component library. On the apps as an
additional function library is also good.
Bluetooth and 802.15.4 communication is very important. I think you will love.
I know you are busy, I hope that other friends can participate in the
development of.
I hardware development experience. Hope to jointly study to find
someone. I am very difficult in the short term solutions to these
problems.

I agree that they are useful, that is not the issue.  I support your effort 100%. The question is:  Where should you maintain your modified code?  Where would you retain your eLua changes for example?


They are different projects and do not belong the the NuttX repository.  A NuttX eLua port belongs in the eLua repository.  It belongs here: http://www.eluaproject.net/.  It does not make sense to put unsupport-able code in NuttX that will become obsolete in a few months.


By this logic, the NuttX repository would become the "mother" of all repositories, including some fork of every major project.  It just cannot work that way.  You might be more appropriate to do something like I did with FICL at apps/interpreters/ficl.  There is a modified Makefile there, with a patch, and a README.txt describing the patch.

I had the same for kconfig-frontends, but I recently forked the whole kconfig-frontends.  But, I hope, that is temporary and when the changes are complete, I will remove the kconfig-frontends fork.


Greg

[Gong Darcy]

hi Greg,

I will try my best to make these functions do not become a burden on nuttx.

I agree that they are useful, that is not the issue. I support your effort 100%. The question is: Where should you maintain your modified code? Where would you retain your eLua changes for example?

I just want to use the eLuaprojects embed version of the Lua script engine.
It is a relatively independent modules.

I have a question.
The rtl8187 driver and wireless network can be used?
How should I compile?
I think in the Shenzhou or stm32f4discovery drive up test.
Will it be a problem?

darcy

[Gregory Nutt]

I agree that they are useful, that is not the issue.  I support your effort 100%. The question is:  Where should you maintain your modified code?  Where would you retain your eLua changes for example?

I just want to use the eLuaprojects embed version of the Lua script engine. It is a relatively independent modules.

Perhaps just checking in a patch showing how to integrate it would be sufficient.

I have a question.
The rtl8187 driver and wireless network can be used?
How should I compile?
I think in the Shenzhou or stm32f4discovery drive up test.
Will it be a problem?

That was an effort started by some members of this forum last year, but they have since given up.  It was partially tested.  The showstopper is that you need to have an 802.11 stack.  You need the 802.11 stack to identify access points and to a establish the connection.  Without that, the driver does nothing.

To install it in the NuttX source tree.  You use the this script.

misc/drivers/rtl8787/INSTALL.sh (note that the driver is GPL)

Here is an example:

nuttx/configs/olimex-lpc1766stk/wlan
apps/examples/wlan

Greg

[Gong Darcy]

hi Greg,

I ordered a stm32f103+wifi open source module.
Later I upload the WiFi protocol stack part. May be useful to everyone.

The STM32F103VET6 + WM-G-MR-08 WIFI programme in China with very wide.
Chip +WIFI cost less than $7, Wifi module $2-$2.4.

The WM-G-MR-08 module, with a large number of Chinese products in low
cost mobile phone ( copycat mobile phone / shanzhai mobile phone).
Is currently in the IAR under the compiler. Test firmware to occupy
flash about 150kB ( including UIP ), memory consumption 16kB. The
TCP/IP protocol stack is used in UIP (manufacturers that do the
simplified ).

Other introduction:
The TM32 WIFI driver code: complete support for WEP/Open, WEP/Shared,
encryption mode.
Support basic network model ( Infrastructure mode ) and point to point
connection mode ( Ad-Hoc mode, supports both WEP encryption ).
UIP network protocol stack: support for ARP, ICMP, UDP, TCP, DHCP
Server, Web Server.
Android DEMO source code: mobile phone control LED lamp example code,
mobile phone control relay example code, mobile phone control buzzer
code examples.

Official :WEP algorithm open source. But WPA/WPA2 is not open source.

I hope someone can join in the WiFi and Bluetooth driven port.

darcy

Post by Gong Darcy
I have a question.
The rtl8187 driver and wireless network can be used?
How should I compile?
I think in the Shenzhou or stm32f4discovery drive up test.
Will it be a problem?

That was an effort started by some members of this forum last year, but they have since given up. It was partially tested. The showstopper is that you need to have an 802.11 stack. You need the 802.11 stack to identify access points and to a establish the connection. Without that, the driver does nothing.
To install it in the NuttX source tree. You use the this script.
misc/drivers/rtl8787/INSTALL.sh (note that the driver is GPL)
nuttx/configs/olimex-lpc1766stk/wlan
apps/examples/wlan
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/

[Michael Smith]

I agree that they are useful, that is not the issue. I support your effort 100%. The question is: Where should you maintain your modified code? Where would you retain your eLua changes for example?
They are different projects and do not belong the the NuttX repository. A NuttX eLua port belongs in the eLua repository. It belongs here: http://www.eluaproject.net/. It does not make sense to put unsupport-able code in NuttX that will become obsolete in a few months.

Greg,

To be fair, Lua updates about once every year or two. It's not something that would change particularly rapidly.

With that said, the Lua 5.2.1 port I have is structured as a wrapper around the Lua distribution, in the same general spirit as the Ficl wrapper. If Darcy wants to play tester (I had a previous taker that wandered off) then I'm more than happy to share...

= Mike

[Michael Smith]

Darcy,

I already have Lua 5.2.1 ported to NuttX; I would be happy to share it if anyone is interested. Porting eLua in its entirety doesn't make a lot of sense, as it would conflict with the NuttX driver layer in many cases. I have ported the eLua interpreter pieces as well (and I'd be happy to share those, too), but stock 5.2.1 is easier on memory.

The biggest outstanding piece of work required to make Lua work well is to replace or enhance the NuttX memory allocator. It's very slow once memory is fragmented, and it's very inefficient at handling lots of small allocations. A slab or even buddy allocator for small (8-64 byte) objects would make a huge difference.

I may still have a branch with the pawnscript port I did a while back. I could never convince folks to use a language whose name can't be pronounced here in the USA without half the audience collapsing in childish giggling. It's a pity because it's a great tool, though Compuphase have done nothing to deal with the major 64-bit issues in the compiler or VM for several years, so I'm not sure whether it has a future.

I could also share a port of a recent Squirrel, if you're looking for alternatives. I know that Alberto has a slightly tweaked "embedded" Squirrel that he did for the Electric Imp guys; it might be possible to get your hands on the diffs if you find that memory is tight.

= Mike

Post by Gong Darcy
hi all,
I plan to port certain modules to nuttx.
Do not know whether there are people willing to get involved.
1) elua script langage
2) pawn script langage
3) Chibi ( 802.15.4 Wireless )
4) btstack Bluetooth protocol stack, UART or USB port )
I think elua is most easily.
Chibi is not difficult, but he mainly uses at86rf230 chip module. I
can't buy off-the-shelf modules, want to use cc2520 to replace.
Btstack itself can be used in uCOS. GitHub is a uubt project is based
on the chibios. I want to port to the nuttx, but the USB part I am not
familiar with.
regards
darcy

[Gregory Nutt]

Post by Michael Smith
The biggest outstanding piece of work required to make Lua work well is to replace or enhance the NuttX memory allocator. It's very slow once memory is fragmented, and it's very inefficient at handling lots of small allocations. A slab or even buddy allocator for small (8-64 byte) objects would make a huge difference.

Have you looked at the granule allocator at mm/mm_gran*.  See mm/README.txt.  It should do well if you pick a good granule size.  It has some behavior like a SLAB allocator, but pretty lightweight.

Post by Michael Smith
I may still have a branch with the pawnscript port I did a while back. I could never convince folks to use a language whose name can't be pronounced here in the USA without half the audience collapsing in childish giggling. It's a pity because it's a great tool, though Compuphase have done nothing to deal with the major 64-bit issues in the compiler or VM for several years, so I'm not sure whether it has a future.

I once got an email saying that NuttX has an off-color double meaning in some northern European language.  I believe that because if you Google for NuttX, most of the sites deal with the RTOS but a percentage are porn-related.

Post by Michael Smith
I could also share a port of a recent Squirrel, if you're looking for alternatives. I know that Alberto has a slightly tweaked "embedded" Squirrel that he did for the Electric Imp guys; it might be possible to get your hands on the diffs if you find that memory is tight.

I also have a HTTP-based VPN that I wrote a long time about for communications with embedded devices behind a firewall.  I might resurrect that someday too.

Greg

[Michael Smith]

Post by Michael Smith
The biggest outstanding piece of work required to make Lua work well is to replace or enhance the NuttX memory allocator. It's very slow once memory is fragmented, and it's very inefficient at handling lots of small allocations. A slab or even buddy allocator for small (8-64 byte) objects would make a huge difference.

Have you looked at the granule allocator at mm/mm_gran*. See mm/README.txt. It should do well if you pick a good granule size. It has some behavior like a SLAB allocator, but pretty lightweight.

I did take a quick look at it, but it wasn't immediately clear whether I'd have to pick initial granule sizes or whether it would do it for me. Even just a single granule sized for the Lua number object would make an enormous improvement.

Malloc is another one of those things I try to stay away from, because I know that if I don't, I'm going to get sucked into it again. 8)

Post by Michael Smith
I could also share a port of a recent Squirrel, if you're looking for alternatives. I know that Alberto has a slightly tweaked "embedded" Squirrel that he did for the Electric Imp guys; it might be possible to get your hands on the diffs if you find that memory is tight.

I also have a HTTP-based VPN that I wrote a long time about for communications with embedded devices behind a firewall. I might resurrect that someday too.

Is this the sort of thing that argues for a 'contrib' archive? Basically a place to put things that might be a bit out of date, but still useful as a starting point to save someone having to repeat everything? I know that 'contrib' is usually a place that hard work goes to die, but the alternatives all seem worse…

= Mike

[Gong Darcy]

hi Michael,
If you share these, I am very glad to study and test them.
I need script function.

Thanks for your information, I found http://electricimp.com.
Very good!
A few months ago, I once thought of similar products.
But my mind is not complete, also very original.

regrads
darcy

Post by Gregory N
**
Darcy,
I already have Lua 5.2.1 ported to NuttX; I would be happy to share it if
anyone is interested. Porting eLua in its entirety doesn't make a lot of
sense, as it would conflict with the NuttX driver layer in many cases. I
have ported the eLua interpreter pieces as well (and I'd be happy to share
those, too), but stock 5.2.1 is easier on memory.
The biggest outstanding piece of work required to make Lua work well is to
replace or enhance the NuttX memory allocator. It's very slow once memory
is fragmented, and it's very inefficient at handling lots of small
allocations. A slab or even buddy allocator for small (8-64 byte) objects
would make a huge difference.
I may still have a branch with the pawnscript port I did a while back. I
could never convince folks to use a language whose name can't be pronounced
here in the USA without half the audience collapsing in childish giggling.
It's a pity because it's a great tool, though Compuphase have done nothing
to deal with the major 64-bit issues in the compiler or VM for several
years, so I'm not sure whether it has a future.
I could also share a port of a recent Squirrel, if you're looking for
alternatives. I know that Alberto has a slightly tweaked "embedded"
Squirrel that he did for the Electric Imp guys; it might be possible to get
your hands on the diffs if you find that memory is tight.
= Mike
hi all,
I plan to port certain modules to nuttx.
Do not know whether there are people willing to get involved.
1) elua script langage
2) pawn script langage
3) Chibi ( 802.15.4 Wireless )
4) btstack Bluetooth protocol stack, UART or USB port )
I think elua is most easily.
Chibi is not difficult, but he mainly uses at86rf230 chip module. I
can't buy off-the-shelf modules, want to use cc2520 to replace.
Btstack itself can be used in uCOS. GitHub is a uubt project is based
on the chibios. I want to port to the nuttx, but the USB part I am not
familiar with.
regards
darcy

[Michael Smith]

Darcy,

Hopefully Gmail is OK with this attachment; if not, let me know and I can host it for you. This bundle includes both Lua and eLua, as well as the linenoise line editor, and I added support for the line editor to vanilla Lua as well.

Note that if you are just looking for *a* scripting language, then Forth is very hard to beat. Greg includes some support for Ficl, which is a very powerful environment. If you need to work with less skilled programmers, it can be more difficult to teach. 8(

= Mike

Post by Gong Darcy
If you share these, I am very glad to study and test them.
I need script function.

[Michael Smith]

Well, bother. My apologies for sending this to the list; I didn't actualiy mean to spam you all with an enormous tarball like that.

= Mike

Post by Gregory N
Darcy,
Hopefully Gmail is OK with this attachment; if not, let me know and I can host it for you. This bundle includes both Lua and eLua, as well as the linenoise line editor, and I added support for the line editor to vanilla Lua as well.
Note that if you are just looking for *a* scripting language, then Forth is very hard to beat. Greg includes some support for Ficl, which is a very powerful environment. If you need to work with less skilled programmers, it can be more difficult to teach. 8(
= Mike
<nuttx_lua.tar.gz>

Post by Gong Darcy
If you share these, I am very glad to study and test them.
I need script function.

[Gong Darcy]

hi michael,

Thank you very much, I was reading your code.
Ask elua and Lua what is the difference?

regrads
darcy

Post by Gregory N
Darcy,
Hopefully Gmail is OK with this attachment; if not, let me know and I can
host it for you. This bundle includes both Lua and eLua, as well as the
linenoise line editor, and I added support for the line editor to vanilla
Lua as well.
Note that if you are just looking for *a* scripting language, then Forth is
very hard to beat. Greg includes some support for Ficl, which is a very
powerful environment. If you need to work with less skilled programmers, it
can be more difficult to teach. 8(
= Mike
If you share these, I am very glad to study and test them.
I need script function.

[Michael Smith]

eLua is a complete runtime that includes the Lua interpreter and drivers for low-level hardware. In my archive, the eLua port is just the eLua version of the Lua interpreter. I had hoped that the version used by eLua would be a bit more memory-efficient, but that seems not to have been the case.

The plain Lua interpreter is newer (5.2.1 vs. 5.1.4 for the one I took from eLua). Unless you have a very specific reason, I would not use the eLua version.

= Mike

Post by Gong Darcy
hi michael,
Thank you very much, I was reading your code.
Ask elua and Lua what is the difference?
regrads
darcy

Post by Gregory N
Darcy,
Hopefully Gmail is OK with this attachment; if not, let me know and I can
host it for you. This bundle includes both Lua and eLua, as well as the
linenoise line editor, and I added support for the line editor to vanilla
Lua as well.
Note that if you are just looking for *a* scripting language, then Forth is
very hard to beat. Greg includes some support for Ficl, which is a very
powerful environment. If you need to work with less skilled programmers, it
can be more difficult to teach. 8(
= Mike
If you share these, I am very glad to study and test them.
I need script function.

[Gong Darcy]

hi Michael,

I'm trying to port of lua to nuttx.

Lua cited locale.h as well as setjmp.h

I can't find the file. Can provide?

Github/px4 I couldn't find the code.

Appears in linenoise on key definitions, nor.

Give a test example of lua?

regrads

darcy

Post by Michael Smith
**
eLua is a complete runtime that includes the Lua interpreter and drivers
for low-level hardware. In my archive, the eLua port is just the eLua
version of the Lua interpreter. I had hoped that the version used by eLua
would be a bit more memory-efficient, but that seems not to have been the
case.
The plain Lua interpreter is newer (5.2.1 vs. 5.1.4 for the one I took
from eLua). Unless you have a very specific reason, I would not use the
eLua version.
= Mike
hi michael,
Thank you very much, I was reading your code.
Ask elua and Lua what is the difference?
regrads
darcy

Post by Gregory N
Darcy,
Hopefully Gmail is OK with this attachment; if not, let me know and I can
host it for you. This bundle includes both Lua and eLua, as well as the
linenoise line editor, and I added support for the line editor to vanilla
Lua as well.
Note that if you are just looking for *a* scripting language, then Forth

is

Post by Gregory N
very hard to beat. Greg includes some support for Ficl, which is a very
powerful environment. If you need to work with less skilled programmers,

it

Post by Gregory N
can be more difficult to teach. 8(
= Mike
If you share these, I am very glad to study and test them.
I need script function.