Re: Including Lua scripts on filesystem

2023-01-28 Thread Xiang Xiao
You can use the real file system on the device, there are many choices:
romfs, littlefs, fatfs, starmtfs and spiffs.

On Sun, Jan 29, 2023 at 12:59 PM Russell Haley  wrote:

> On Sat, Jan 28, 2023 at 7:35 PM Xiang Xiao 
> wrote:
>
> > You can enable CONFIG_FS_HOSTFS/CONFIG_SIM_HOSTFS, put your scripts into
> > some PC folder and run mount this folder from nsh:
> > mount -t hostfs -o fs=/path/to/your/pc/folder. /data
> >
> > While I appreciate the answer, I am using the sim as a testing platform
> and hoping to move to either an STM32F4/7 or a Sony Spresense. I am hoping
> for a solution that is applicable to an embedded project. If I can't just
> add files to the initial image then I will look at the romfs example and
> maybe the next best thing?
>
>
> >
> > On Sun, Jan 29, 2023 at 2:24 AM Russell Haley 
> > wrote:
> >
> > > Hi,
> > >
> > > Big thanks to Xiang Xiao for pointing me to the sim:lua configuration.
> I
> > > was unable to simply include the defconfig file that you linked to,
> but I
> > > was able to reconfigure for the sim:lua configuration.  I've now got an
> > app
> > > in the examples folder that includes the Lua interpreter. Is there a
> > > tutorial on how to include folders and lua scripts or extra files in
> the
> > > initial file system?
> > >
> > > Much appreciated,
> > > Russ
> > >
> >
>


Re: Including Lua scripts on filesystem

2023-01-28 Thread Russell Haley
On Sat, Jan 28, 2023 at 7:35 PM Xiang Xiao 
wrote:

> You can enable CONFIG_FS_HOSTFS/CONFIG_SIM_HOSTFS, put your scripts into
> some PC folder and run mount this folder from nsh:
> mount -t hostfs -o fs=/path/to/your/pc/folder. /data
>
> While I appreciate the answer, I am using the sim as a testing platform
and hoping to move to either an STM32F4/7 or a Sony Spresense. I am hoping
for a solution that is applicable to an embedded project. If I can't just
add files to the initial image then I will look at the romfs example and
maybe the next best thing?


>
> On Sun, Jan 29, 2023 at 2:24 AM Russell Haley 
> wrote:
>
> > Hi,
> >
> > Big thanks to Xiang Xiao for pointing me to the sim:lua configuration. I
> > was unable to simply include the defconfig file that you linked to, but I
> > was able to reconfigure for the sim:lua configuration.  I've now got an
> app
> > in the examples folder that includes the Lua interpreter. Is there a
> > tutorial on how to include folders and lua scripts or extra files in the
> > initial file system?
> >
> > Much appreciated,
> > Russ
> >
>


Re: Including Lua scripts on filesystem

2023-01-28 Thread Xiang Xiao
You can enable CONFIG_FS_HOSTFS/CONFIG_SIM_HOSTFS, put your scripts into
some PC folder and run mount this folder from nsh:
mount -t hostfs -o fs=/path/to/your/pc/folder. /data


On Sun, Jan 29, 2023 at 2:24 AM Russell Haley  wrote:

> Hi,
>
> Big thanks to Xiang Xiao for pointing me to the sim:lua configuration. I
> was unable to simply include the defconfig file that you linked to, but I
> was able to reconfigure for the sim:lua configuration.  I've now got an app
> in the examples folder that includes the Lua interpreter. Is there a
> tutorial on how to include folders and lua scripts or extra files in the
> initial file system?
>
> Much appreciated,
> Russ
>


Re: Short delay

2023-01-28 Thread Nathan Hartman
On Sat, Jan 28, 2023 at 9:04 AM Gregory Nutt  wrote:

> On 1/28/2023 7:15 AM, Max Kriegleder wrote:
> > I am using the tickless OS setting with 1 USEC_PER_TICK and ultimately
> > I want to control a stepper motor where I need to delay toggling of
> > pins for very short and accurate amounts of time to achieve a certain
> > movement profile of the motor - just for information, maybe I am
> > thinking in the wrong direction
>
> It has been some time since I have heard measurements of interrupt entry
> latency and context switch times for the OS, but I do remember some
> older measurements on an STM32 F4:  It required around 10 uS to do
> either.  Modern MCUs can probably do better but, in any case, you are
> working beyond the resolution of the interrupt/context switch capability.
>
> If for example, you receive a timer interrupt then perform a context
> switch to run a task, that would be expected to require something like
> 20 uS on an STM32 F4.  Could that be the issue?
>
> You can reduce that interrupt latency by using a separate interval timer
> with a high priority, zero latency interrupt; you can eliminate the
> context switch by performing the pin toggling in the interrupt handler.
> That would still result in a significant, but smaller, delay



Controlling stepper motors by toggling pins at "exactly" the right time is
an example of something I would probably use a zero latency interrupt for;
be aware, though, that doing so will probably require register stuffing
since you can't call any OS facilities from a zero latency interrupt.

Zero latency interrupts require support in the CPU architecture. I know
that ARM supports it and it works great in NuttX.

These interrupts exist "outside" the operating system and add no operating
system overhead. Even when the operating system is in a critical section or
any mechanism that would otherwise delay a task switch or interrupt
service, a zero latency interrupt *will* interrupt that and execute right
away.

In my projects, the latency isn't really critical as long as it's
consistent; it's the jitter (variance in latency) that I need to be zero.

Since they exist outside the operating system, there is some complexity to
rendezvousing from zero latency interrupts back into code that exists
"inside" the operating system. You can't, for example, wake up a task from
within a zero latency interrupt. In my projects, in order to trigger normal
code, the last thing in my zero latency interrupt is to trigger a normal
interrupt, for which I use some otherwise unused interrupt vector; within
that interrupt, I can wake up tasks, etc. That separate interrupt is not
zero latency and therefore its execution might be somewhat delayed but it
can wake up tasks, etc.

A bit more on stepper motors: I did a project where I controlled steppers
using step and direction outputs. In my case, I needed the direction pin to
be set first, then I needed the step pin to be pulsed 10us later for 1us.
Instead of trying to do this in software, I used the timer peripherals of
the MCU. This used a STM32 part. I don't have the information in front of
me right now but if I recall correctly, I connected the step signal to a
timer-capable pin and used a combination of the timer's PWM feature and
one-shot. For the PWM, I configured the profile to produce 10us of low
followed by 1us of high output and configured the one-shot feature to
automatically stop the timer enable after one pulse. Maybe it's called one
pulse, rather than one shot. In my zero latency interrupt, I set the
direction output by register-stuffing its GPIO, then I enable the delayed
step output by register-stuffing the timer enable. Then my zero latency
interrupt returns and allows normal code to run and hardware would do the
rest. Be aware that not all STM32 timers support the one-shot/one-pulse,
and even within the same part, some may while others may not, so be extra
careful when designing this part of your circuit.

You could also accomplish the above purely in software via zero latency
interrupts and a state machine.

Hopefully something in this post is useful...

Cheers
Nathan


Article: NuttX trips ChatGPT

2023-01-28 Thread Lee, Lup Yuen
ChatGPT (the AI chatbot) will gladly answer questions about NuttX! But the
answers aren't always correct.

Let's turn this into a learning opportunity, and understand why ChatGPT's
answers are incorrect...

https://lupyuen.github.io/articles/chatgpt

Lup


Re: Simulator, NOR flash file system, MTD

2023-01-28 Thread Alan C. Assis
Thank you very much Ken!

Alexander, if you got it working and want to help others, please write
a guide/tutorial to be included on our Documentation/

It will help others!

BR,

Alan

On 1/28/23, Ken Pettit  wrote:
> Hi Alexander,
>
> Great!  I hope it works for you.
>
> It has been many years since I wrote the Linux FUSE filesystem for
> SmartFS, but I believe HostFS + file_there + filemtd + SmartFS is
> exactly how I tested it.  Use that setup to create the host file, then
> use that file to test the Linux FUSE implementation of SmartFS.  In
> fact, I'm pretty sure that was exactly why I wrote the filemtd
> implementation to begin with.
>
> Ken
>
> On 1/28/23 2:25 AM, Alexander Oryshchenko wrote:
>> Hi Alan, Ken!
>>
>> Thanks!
>> Looks that HostFS + file_there + filemtd + ... may do what I need.
>> In general I need to have file on the host which is organized like NOR
>> FLASH (256b write pages, 4k erase).
>>
>> -Alexander
>>
>>
>> On Fri, Jan 27, 2023 at 9:58 PM Ken Pettit  wrote:
>>
>>> Hey Guys,
>>>
>>> Yes, I had SmartFS running in the simulator at one point, but it was
>>> backed by a big char array.  But I'm trying to understand the use case
>>> ... are you jsut looking for a file system in the simulator to use for
>>> testing an application?  Are you looking for host backed because you
>>> want data to be persistent in the simulator from run to run?  Do you
>>> specifically want to test out NOR flash access type access?  On the
>>> host, does the data need to be in a single file or can it just be in a
>>> directory?
>>>
>>> Because I also wrote a full FS (HostFS) that gives a host backed
>>> filesystem in NuttX, but it works by publishing a host directory to
>>> NuttX, and doesn't really simulate Flash / NOR.  So it depends if you
>>> are specifically looking to implement it as a pseudo NOR flash, if you
>>> are wanting the FS to end up in a single file on the host that looks
>>> like a NOR device, etc.
>>>
>>> If you specifically want NOR simulation that ends up in a single Host
>>> file, then you could probably setup HostFS and then setup SmartFS (or
>>> LittleFs, etc.) to work with an MTD device that is backed by  file MTD
>>> with the file residing in the HostFS mount.
>>>
>>> Also note that if you follow that approach and use SmartFS, I also wrote
>>> a FUSE filesystem for Linux that allows it to natively mount a SmartFS
>>> filesystem contained in a file.
>>>
>>> Ken
>>>
>>> On 1/27/23 11:55 AM, Alan C. Assis wrote:
 Hi Alexander,

 Some time ago Ken Pettit wrote a SmartFS simulator.

 If I'm not wrong it could be used with NuttX SIM(ulator).

 BR,

 Alan

 On 1/27/23, Alexander Oryshchenko  wrote:
> What is the easiest way to use NOR- FFS (SmartFs, Spiffs, LittleFs...)
>>> over
> host's file?
> May be somebody knows NOR FLASH simulator for Linux?
> Any other way?
>
>>>
>
>


Including Lua scripts on filesystem

2023-01-28 Thread Russell Haley
Hi,

Big thanks to Xiang Xiao for pointing me to the sim:lua configuration. I
was unable to simply include the defconfig file that you linked to, but I
was able to reconfigure for the sim:lua configuration.  I've now got an app
in the examples folder that includes the Lua interpreter. Is there a
tutorial on how to include folders and lua scripts or extra files in the
initial file system?

Much appreciated,
Russ


Re: Lua fails to build

2023-01-28 Thread Tim Hardisty
I can't fully explain it...I think DKIM might be a clue. I am coming to the 
conclusion that email is a broken communication medium these days!


On 28/01/2023, 18:14, "Russell Haley" mailto:russ.ha...@gmail.com>> wrote:


On Sat, Jan 28, 2023 at 3:18 AM Tim Hardisty mailto:t...@hardisty.co.uk>> wrote:


> > On 28/01/2023, 08:51, "Russell Haley" wrote:
>
> > I am not receiving emails on this email account.
>
> I believe that the apache mail reflector is the root cause of this, if
> emails are sent with a DKIM signature. The reflector adds new headers which
> cause the DKIM signature to fail. Any email service that checks DKIM will
> then reject the email as SPAM and may not even deliver it. Gmail is the
> "worst" and unilaterally rejects emails for reasons of its own with no
> rational explanation, for no technical reason, and no way to find out why.
> I know this through bitter experience with our work email which rarely gets
> through to any gmail recipient despite emails passing every deliverability
> test I can find!
>
> I have moved to using my personal email for NuttX as that does not use
> DKIM, and my emails now get through to most dev@NuttX subscribers.
>


My problem is that my own email (russ.ha...@winlua.net 
) is failing but I
used to get the nuttx emails on that account. I am responding to you from
gmail now, so gmail seems to work for me?





Re: Simulator, NOR flash file system, MTD

2023-01-28 Thread Ken Pettit

Hi Alexander,

Great!  I hope it works for you.

It has been many years since I wrote the Linux FUSE filesystem for 
SmartFS, but I believe HostFS + file_there + filemtd + SmartFS is 
exactly how I tested it.  Use that setup to create the host file, then 
use that file to test the Linux FUSE implementation of SmartFS.  In 
fact, I'm pretty sure that was exactly why I wrote the filemtd 
implementation to begin with.


Ken

On 1/28/23 2:25 AM, Alexander Oryshchenko wrote:

Hi Alan, Ken!

Thanks!
Looks that HostFS + file_there + filemtd + ... may do what I need.
In general I need to have file on the host which is organized like NOR
FLASH (256b write pages, 4k erase).

-Alexander


On Fri, Jan 27, 2023 at 9:58 PM Ken Pettit  wrote:


Hey Guys,

Yes, I had SmartFS running in the simulator at one point, but it was
backed by a big char array.  But I'm trying to understand the use case
... are you jsut looking for a file system in the simulator to use for
testing an application?  Are you looking for host backed because you
want data to be persistent in the simulator from run to run?  Do you
specifically want to test out NOR flash access type access?  On the
host, does the data need to be in a single file or can it just be in a
directory?

Because I also wrote a full FS (HostFS) that gives a host backed
filesystem in NuttX, but it works by publishing a host directory to
NuttX, and doesn't really simulate Flash / NOR.  So it depends if you
are specifically looking to implement it as a pseudo NOR flash, if you
are wanting the FS to end up in a single file on the host that looks
like a NOR device, etc.

If you specifically want NOR simulation that ends up in a single Host
file, then you could probably setup HostFS and then setup SmartFS (or
LittleFs, etc.) to work with an MTD device that is backed by  file MTD
with the file residing in the HostFS mount.

Also note that if you follow that approach and use SmartFS, I also wrote
a FUSE filesystem for Linux that allows it to natively mount a SmartFS
filesystem contained in a file.

Ken

On 1/27/23 11:55 AM, Alan C. Assis wrote:

Hi Alexander,

Some time ago Ken Pettit wrote a SmartFS simulator.

If I'm not wrong it could be used with NuttX SIM(ulator).

BR,

Alan

On 1/27/23, Alexander Oryshchenko  wrote:

What is the easiest way to use NOR- FFS (SmartFs, Spiffs, LittleFs...)

over

host's file?
May be somebody knows NOR FLASH simulator for Linux?
Any other way?







Re: Lua fails to build

2023-01-28 Thread Russell Haley
On Sat, Jan 28, 2023 at 3:18 AM Tim Hardisty  wrote:

> > On 28/01/2023, 08:51, "Russell Haley" wrote:
>
> > I am not receiving emails on this email account.
>
> I believe that the apache mail reflector is the root cause of this, if
> emails are sent with a DKIM signature. The reflector adds new headers which
> cause the DKIM signature to fail. Any email service that checks DKIM will
> then reject the email as SPAM and may not even deliver it. Gmail is the
> "worst" and unilaterally rejects emails for reasons of its own with no
> rational explanation, for no technical reason, and no way to find out why.
> I know this through bitter experience with our work email which rarely gets
> through to any gmail recipient despite emails passing every deliverability
> test I can find!
>
> I have moved to using my personal email for NuttX as that does not use
> DKIM, and my emails now get through to most dev@NuttX subscribers.
>

My problem is that my own email (russ.ha...@winlua.net) is failing but I
used to get the nuttx emails on that account. I am responding to you from
gmail now, so gmail seems to work for me?


Re: RNDIS

2023-01-28 Thread Alan C. Assis
Other alternative that people can explore in this mean time:

Reverse tethering:

https://github.com/Genymobile/gnirehtet

Since NuttX has support to USB ADB, eventually it could work (I'm not
100% sure it will work)

More info: https://www.youtube.com/watch?v=96J-pHZ1kR0

BR,

Alan

On 1/28/23, Tim Hardisty  wrote:
> If someone has the time and skills to do a CDC-NCM driver I will test it
> straightaway!
>
> As I commented on GitHub - thanks for reopening and, hopefully, I'll find
> what the issue is stopping it working for me and others may find that
> useful: Microsoft have not said they will deprecate it as yet, so there is
> still a use for it until an NCM driver is available.
>
> On 28/01/2023, 14:11, "Alan C. Assis"  > wrote:
>
>
> Ok, I re-opened it.
>
>
> If there are inconsistencies they are not specify of RNDIS driver by
> itself, but could be in the USB implementation of other architectures.
>
>
> BTW, since RNDIS is deprecated it doesn't make sense to invest more time on
> it.
>
>
> Like Michael said, it is time to look for a better alternative that
> works on all OS.
>
>
> BR,
>
>
> Alan
>
>
> On 1/28/23, Tim Hardisty mailto:t...@hardisty.co.uk>>
> wrote:
>> Please don't close my issue. There are too many inconsistencies here to
>> be
>> sure it is closed:
>>
>> Processor - I am not using stm32
>> OS - Windows/Linux/Ubuntu version maybe
>> RNDIS is likely to be deprecated
>>
>> If I can get RNDIS working for me, that is the time to close it.
>>
>> On 28/01/2023, 13:45, "Alan C. Assis" > 
>> >> wrote:
>>
>>
>> Hi Tim,
>>
>>
>> I just confirmed that it still working fine and I'll close your issue.
>>
>>
>> This is a step-by-step process that everyone can follow to get it
>> working:
>>
>>
>> Configure your board:
>> =
>>
>>
>> $ ./tools/configure.sh stm32f4discovery:rndis
>>
>>
>> Compile NuttX to your board:
>> 
>>
>>
>> $ make -j
>>
>>
>> Flash to your board:
>> 
>>
>>
>> $ sudo openocd -f interface/stlink.cfg -f target/stm32f4x.cfg -c init
>> -c "reset halt" -c "flash write_image erase nuttx.bin 0x0800"
>> Open On-Chip Debugger 0.11.0
>> Licensed under GNU GPL v2
>> For bug reports, read
>> http://openocd.org/doc/doxygen/bugs.html
>> 
>> 
>> 
>> Info : auto-selecting first available session transport "hla_swd". To
>> override use 'transport select '.
>> Info : The selected transport took over low-level target control. The
>> results might differ compared to plain JTAG/SWD
>> Info : clock speed 2000 kHz
>> Info : STLINK V2J14S0 (API v2) VID:PID 0483:3748
>> Info : Target voltage: 3.203144
>> Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
>> Info : starting gdb server for stm32f4x.cpu on 
>> Info : Listening on port  for gdb connections
>> target halted due to debug-request, current mode: Thread
>> xPSR: 0x0100 pc: 0x08000188 msp: 0x20003f24
>> Info : device id = 0x10036413
>> Info : flash size = 1024 kbytes
>> auto erase enabled
>> wrote 262144 bytes from file nuttx.bin in 11.043253s (23.182 KiB/s)
>>
>>
>> Info : Listening on port  for tcl connections
>> Info : Listening on port  for telnet connections
>>
>>
>>
>>
>> Reset your board
>> 
>>
>>
>> Run dmesg to confirm that USB RNDIS device was detected:
>> 
>>
>>
>> [ 1099.821480] usb 3-3: new full-speed USB device number 12 using
>> xhci_hcd
>> [ 1099.972379] usb 3-3: New USB device found, idVendor=584e,
>> idProduct=5342, bcdDevice= 0.01
>> [ 1099.972389] usb 3-3: New USB device strings: Mfr=1, Product=2,
>> SerialNumber=3
>> [ 1099.972393] usb 3-3: Product: RNDIS gadget
>> [ 1099.972396] usb 3-3: Manufacturer: NuttX
>> [ 1099.972398] usb 3-3: SerialNumber: 1234
>> [ 1099.988952] usbcore: registered new interface driver cdc_ether
>> [ 1099.990144] rndis_host 3-3:1.0: skipping garbage
>> [ 1099.990641] rndis_host 3-3:1.0: dev can't take 1558 byte packets
>> (max 660), adjusting MTU to 602
>> [ 1099.992089] rndis_host 3-3:1.0 eth0: register 'rndis_host' at
>> usb-:00:14.0-3, RNDIS device, a0:e0:de:ad:ca:fe
>> [ 1099.992102] usbcore: registered new interface driver rndis_host
>> [ 1099.994026] usbcore: registered new interface driver rndis_wlan
>> [ 1099.997001] rndis_host 3-3:1.0 enxa0e0deadcafe: renamed from eth0
>>
>>
>>
>>
>> Configure your Ubuntu or other Linux distro to share network:
>> =
>>
>>
>> Click in the top right corner of your Ubuntu and go to:
>>
>>
>> NuttX Ethernet -> Wired Settings
>>
>>
>> Click in the 'Gear icon' and in the tab "IPv4" select: "Shared to
>> other computers"
>>
>>
>> Click on "Apply" button
>>
>>
>> Disconnect and connect the USB cable to 

Re: RNDIS

2023-01-28 Thread Tim Hardisty
If someone has the time and skills to do a CDC-NCM driver I will test it 
straightaway!

As I commented on GitHub - thanks for reopening and, hopefully, I'll find what 
the issue is stopping it working for me and others may find that useful: 
Microsoft have not said they will deprecate it as yet, so there is still a use 
for it until an NCM driver is available.

On 28/01/2023, 14:11, "Alan C. Assis" mailto:acas...@gmail.com>> wrote:


Ok, I re-opened it.


If there are inconsistencies they are not specify of RNDIS driver by
itself, but could be in the USB implementation of other architectures.


BTW, since RNDIS is deprecated it doesn't make sense to invest more time on it.


Like Michael said, it is time to look for a better alternative that
works on all OS.


BR,


Alan


On 1/28/23, Tim Hardisty mailto:t...@hardisty.co.uk>> 
wrote:
> Please don't close my issue. There are too many inconsistencies here to be
> sure it is closed:
>
> Processor - I am not using stm32
> OS - Windows/Linux/Ubuntu version maybe
> RNDIS is likely to be deprecated
>
> If I can get RNDIS working for me, that is the time to close it.
>
> On 28/01/2023, 13:45, "Alan C. Assis"  
> >> wrote:
>
>
> Hi Tim,
>
>
> I just confirmed that it still working fine and I'll close your issue.
>
>
> This is a step-by-step process that everyone can follow to get it working:
>
>
> Configure your board:
> =
>
>
> $ ./tools/configure.sh stm32f4discovery:rndis
>
>
> Compile NuttX to your board:
> 
>
>
> $ make -j
>
>
> Flash to your board:
> 
>
>
> $ sudo openocd -f interface/stlink.cfg -f target/stm32f4x.cfg -c init
> -c "reset halt" -c "flash write_image erase nuttx.bin 0x0800"
> Open On-Chip Debugger 0.11.0
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.org/doc/doxygen/bugs.html 
> 
>  
> 
> Info : auto-selecting first available session transport "hla_swd". To
> override use 'transport select '.
> Info : The selected transport took over low-level target control. The
> results might differ compared to plain JTAG/SWD
> Info : clock speed 2000 kHz
> Info : STLINK V2J14S0 (API v2) VID:PID 0483:3748
> Info : Target voltage: 3.203144
> Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
> Info : starting gdb server for stm32f4x.cpu on 
> Info : Listening on port  for gdb connections
> target halted due to debug-request, current mode: Thread
> xPSR: 0x0100 pc: 0x08000188 msp: 0x20003f24
> Info : device id = 0x10036413
> Info : flash size = 1024 kbytes
> auto erase enabled
> wrote 262144 bytes from file nuttx.bin in 11.043253s (23.182 KiB/s)
>
>
> Info : Listening on port  for tcl connections
> Info : Listening on port  for telnet connections
>
>
>
>
> Reset your board
> 
>
>
> Run dmesg to confirm that USB RNDIS device was detected:
> 
>
>
> [ 1099.821480] usb 3-3: new full-speed USB device number 12 using xhci_hcd
> [ 1099.972379] usb 3-3: New USB device found, idVendor=584e,
> idProduct=5342, bcdDevice= 0.01
> [ 1099.972389] usb 3-3: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
> [ 1099.972393] usb 3-3: Product: RNDIS gadget
> [ 1099.972396] usb 3-3: Manufacturer: NuttX
> [ 1099.972398] usb 3-3: SerialNumber: 1234
> [ 1099.988952] usbcore: registered new interface driver cdc_ether
> [ 1099.990144] rndis_host 3-3:1.0: skipping garbage
> [ 1099.990641] rndis_host 3-3:1.0: dev can't take 1558 byte packets
> (max 660), adjusting MTU to 602
> [ 1099.992089] rndis_host 3-3:1.0 eth0: register 'rndis_host' at
> usb-:00:14.0-3, RNDIS device, a0:e0:de:ad:ca:fe
> [ 1099.992102] usbcore: registered new interface driver rndis_host
> [ 1099.994026] usbcore: registered new interface driver rndis_wlan
> [ 1099.997001] rndis_host 3-3:1.0 enxa0e0deadcafe: renamed from eth0
>
>
>
>
> Configure your Ubuntu or other Linux distro to share network:
> =
>
>
> Click in the top right corner of your Ubuntu and go to:
>
>
> NuttX Ethernet -> Wired Settings
>
>
> Click in the 'Gear icon' and in the tab "IPv4" select: "Shared to
> other computers"
>
>
> Click on "Apply" button
>
>
> Disconnect and connect the USB cable to force it to get IP.
>
>
> Verify which IP your board got:
> ===
>
>
> $ tail -f /var/log/syslog
> ...
> Jan 28 10:30:24 dev dnsmasq-dhcp[35526]: DHCPDISCOVER(enxa0e0deadcafe)
> 00:e0:de:ad:ca:fe
> Jan 28 10:30:24 dev dnsmasq-dhcp[35526]: DHCPOFFER(enxa0e0deadcafe)
> 10.42.0.86 00:e0:de:ad:ca:fe
> Jan 28 10:30:24 dev dnsmasq-dhcp[35526]: DHCPREQUEST(enxa0e0deadcafe)
> 10.42.0.86 00:e0:de:ad:ca:fe
> Jan 28 10:30:24 dev dnsmasq-dhcp[35526]: DHCPACK(enxa0e0deadcafe)
> 

Re: RNDIS

2023-01-28 Thread Alan C. Assis
Ok, I re-opened it.

If there are inconsistencies they are not specify of RNDIS driver by
itself, but could be in the USB implementation of other architectures.

BTW, since RNDIS is deprecated it doesn't make sense to invest more time on it.

Like Michael said, it is time to look for a better alternative that
works on all OS.

BR,

Alan

On 1/28/23, Tim Hardisty  wrote:
> Please don't close my issue. There are too many inconsistencies here to be
> sure it is closed:
>
> Processor - I am not using stm32
> OS - Windows/Linux/Ubuntu version maybe
> RNDIS is likely to be deprecated
>
> If I can get RNDIS working for me, that is the time to close it.
>
> On 28/01/2023, 13:45, "Alan C. Assis"  > wrote:
>
>
> Hi Tim,
>
>
> I just confirmed that it still working fine and I'll close your issue.
>
>
> This is a step-by-step process that everyone can follow to get it working:
>
>
> Configure your board:
> =
>
>
> $ ./tools/configure.sh stm32f4discovery:rndis
>
>
> Compile NuttX to your board:
> 
>
>
> $ make -j
>
>
> Flash to your board:
> 
>
>
> $ sudo openocd -f interface/stlink.cfg -f target/stm32f4x.cfg -c init
> -c "reset halt" -c "flash write_image erase nuttx.bin 0x0800"
> Open On-Chip Debugger 0.11.0
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.org/doc/doxygen/bugs.html
> 
> Info : auto-selecting first available session transport "hla_swd". To
> override use 'transport select '.
> Info : The selected transport took over low-level target control. The
> results might differ compared to plain JTAG/SWD
> Info : clock speed 2000 kHz
> Info : STLINK V2J14S0 (API v2) VID:PID 0483:3748
> Info : Target voltage: 3.203144
> Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
> Info : starting gdb server for stm32f4x.cpu on 
> Info : Listening on port  for gdb connections
> target halted due to debug-request, current mode: Thread
> xPSR: 0x0100 pc: 0x08000188 msp: 0x20003f24
> Info : device id = 0x10036413
> Info : flash size = 1024 kbytes
> auto erase enabled
> wrote 262144 bytes from file nuttx.bin in 11.043253s (23.182 KiB/s)
>
>
> Info : Listening on port  for tcl connections
> Info : Listening on port  for telnet connections
>
>
>
>
> Reset your board
> 
>
>
> Run dmesg to confirm that USB RNDIS device was detected:
> 
>
>
> [ 1099.821480] usb 3-3: new full-speed USB device number 12 using xhci_hcd
> [ 1099.972379] usb 3-3: New USB device found, idVendor=584e,
> idProduct=5342, bcdDevice= 0.01
> [ 1099.972389] usb 3-3: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
> [ 1099.972393] usb 3-3: Product: RNDIS gadget
> [ 1099.972396] usb 3-3: Manufacturer: NuttX
> [ 1099.972398] usb 3-3: SerialNumber: 1234
> [ 1099.988952] usbcore: registered new interface driver cdc_ether
> [ 1099.990144] rndis_host 3-3:1.0: skipping garbage
> [ 1099.990641] rndis_host 3-3:1.0: dev can't take 1558 byte packets
> (max 660), adjusting MTU to 602
> [ 1099.992089] rndis_host 3-3:1.0 eth0: register 'rndis_host' at
> usb-:00:14.0-3, RNDIS device, a0:e0:de:ad:ca:fe
> [ 1099.992102] usbcore: registered new interface driver rndis_host
> [ 1099.994026] usbcore: registered new interface driver rndis_wlan
> [ 1099.997001] rndis_host 3-3:1.0 enxa0e0deadcafe: renamed from eth0
>
>
>
>
> Configure your Ubuntu or other Linux distro to share network:
> =
>
>
> Click in the top right corner of your Ubuntu and go to:
>
>
> NuttX Ethernet -> Wired Settings
>
>
> Click in the 'Gear icon' and in the tab "IPv4" select: "Shared to
> other computers"
>
>
> Click on "Apply" button
>
>
> Disconnect and connect the USB cable to force it to get IP.
>
>
> Verify which IP your board got:
> ===
>
>
> $ tail -f /var/log/syslog
> ...
> Jan 28 10:30:24 dev dnsmasq-dhcp[35526]: DHCPDISCOVER(enxa0e0deadcafe)
> 00:e0:de:ad:ca:fe
> Jan 28 10:30:24 dev dnsmasq-dhcp[35526]: DHCPOFFER(enxa0e0deadcafe)
> 10.42.0.86 00:e0:de:ad:ca:fe
> Jan 28 10:30:24 dev dnsmasq-dhcp[35526]: DHCPREQUEST(enxa0e0deadcafe)
> 10.42.0.86 00:e0:de:ad:ca:fe
> Jan 28 10:30:24 dev dnsmasq-dhcp[35526]: DHCPACK(enxa0e0deadcafe)
> 10.42.0.86 00:e0:de:ad:ca:fe nuttx
> Jan 28 10:30:29 dev systemd[1]: NetworkManager-dispatcher.service:
> Deactivated successfully.
> ^C
>
>
> Ping this IP to confirm it is working:
> ==
>
>
> alan@dev:~/nuttxspace/nuttx$ ping 10.42.0.86
> PING 10.42.0.86 (10.42.0.86) 56(84) bytes of data.
> 64 bytes from 10.42.0.86: icmp_seq=1 ttl=64 time=0.809 ms
> 64 bytes from 10.42.0.86: icmp_seq=2 ttl=64 time=0.849 ms
> ^C
> --- 10.42.0.86 ping statistics ---
> 2 packets transmitted, 2 received, 0% packet loss, time 1027ms
> rtt min/avg/max/mdev = 0.809/0.829/0.849/0.020 ms
>
>
> Connect to 

Re: Short delay

2023-01-28 Thread Gregory Nutt

On 1/28/2023 7:15 AM, Max Kriegleder wrote:
I am using the tickless OS setting with 1 USEC_PER_TICK and ultimately 
I want to control a stepper motor where I need to delay toggling of 
pins for very short and accurate amounts of time to achieve a certain 
movement profile of the motor - just for information, maybe I am 
thinking in the wrong direction


It has been some time since I have heard measurements of interrupt entry 
latency and context switch times for the OS, but I do remember some 
older measurements on an STM32 F4:  It required around 10 uS to do 
either.  Modern MCUs can probably do better but, in any case, you are 
working beyond the resolution of the interrupt/context switch capability.


If for example, you receive a timer interrupt then perform a context 
switch to run a task, that would be expected to require something like 
20 uS on an STM32 F4.  Could that be the issue?


You can reduce that interrupt latency by using a separate interval timer 
with a high priority, zero latency interrupt; you can eliminate the 
context switch by performing the pin toggling in the interrupt handler.  
That would still result in a significant, but smaller, delay





Re: RNDIS

2023-01-28 Thread Tim Hardisty
Please don't close my issue. There are too many inconsistencies here to be sure 
it is closed:

Processor - I am not using stm32
OS - Windows/Linux/Ubuntu version maybe
RNDIS is likely to be deprecated

If I can get RNDIS working for me, that is the time to close it.

On 28/01/2023, 13:45, "Alan C. Assis" mailto:acas...@gmail.com>> wrote:


Hi Tim,


I just confirmed that it still working fine and I'll close your issue.


This is a step-by-step process that everyone can follow to get it working:


Configure your board:
=


$ ./tools/configure.sh stm32f4discovery:rndis


Compile NuttX to your board:



$ make -j


Flash to your board:



$ sudo openocd -f interface/stlink.cfg -f target/stm32f4x.cfg -c init
-c "reset halt" -c "flash write_image erase nuttx.bin 0x0800"
Open On-Chip Debugger 0.11.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html 

Info : auto-selecting first available session transport "hla_swd". To
override use 'transport select '.
Info : The selected transport took over low-level target control. The
results might differ compared to plain JTAG/SWD
Info : clock speed 2000 kHz
Info : STLINK V2J14S0 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.203144
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : starting gdb server for stm32f4x.cpu on 
Info : Listening on port  for gdb connections
target halted due to debug-request, current mode: Thread
xPSR: 0x0100 pc: 0x08000188 msp: 0x20003f24
Info : device id = 0x10036413
Info : flash size = 1024 kbytes
auto erase enabled
wrote 262144 bytes from file nuttx.bin in 11.043253s (23.182 KiB/s)


Info : Listening on port  for tcl connections
Info : Listening on port  for telnet connections




Reset your board



Run dmesg to confirm that USB RNDIS device was detected:



[ 1099.821480] usb 3-3: new full-speed USB device number 12 using xhci_hcd
[ 1099.972379] usb 3-3: New USB device found, idVendor=584e,
idProduct=5342, bcdDevice= 0.01
[ 1099.972389] usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1099.972393] usb 3-3: Product: RNDIS gadget
[ 1099.972396] usb 3-3: Manufacturer: NuttX
[ 1099.972398] usb 3-3: SerialNumber: 1234
[ 1099.988952] usbcore: registered new interface driver cdc_ether
[ 1099.990144] rndis_host 3-3:1.0: skipping garbage
[ 1099.990641] rndis_host 3-3:1.0: dev can't take 1558 byte packets
(max 660), adjusting MTU to 602
[ 1099.992089] rndis_host 3-3:1.0 eth0: register 'rndis_host' at
usb-:00:14.0-3, RNDIS device, a0:e0:de:ad:ca:fe
[ 1099.992102] usbcore: registered new interface driver rndis_host
[ 1099.994026] usbcore: registered new interface driver rndis_wlan
[ 1099.997001] rndis_host 3-3:1.0 enxa0e0deadcafe: renamed from eth0




Configure your Ubuntu or other Linux distro to share network:
=


Click in the top right corner of your Ubuntu and go to:


NuttX Ethernet -> Wired Settings


Click in the 'Gear icon' and in the tab "IPv4" select: "Shared to
other computers"


Click on "Apply" button


Disconnect and connect the USB cable to force it to get IP.


Verify which IP your board got:
===


$ tail -f /var/log/syslog
...
Jan 28 10:30:24 dev dnsmasq-dhcp[35526]: DHCPDISCOVER(enxa0e0deadcafe)
00:e0:de:ad:ca:fe
Jan 28 10:30:24 dev dnsmasq-dhcp[35526]: DHCPOFFER(enxa0e0deadcafe)
10.42.0.86 00:e0:de:ad:ca:fe
Jan 28 10:30:24 dev dnsmasq-dhcp[35526]: DHCPREQUEST(enxa0e0deadcafe)
10.42.0.86 00:e0:de:ad:ca:fe
Jan 28 10:30:24 dev dnsmasq-dhcp[35526]: DHCPACK(enxa0e0deadcafe)
10.42.0.86 00:e0:de:ad:ca:fe nuttx
Jan 28 10:30:29 dev systemd[1]: NetworkManager-dispatcher.service:
Deactivated successfully.
^C


Ping this IP to confirm it is working:
==


alan@dev:~/nuttxspace/nuttx$ ping 10.42.0.86
PING 10.42.0.86 (10.42.0.86) 56(84) bytes of data.
64 bytes from 10.42.0.86: icmp_seq=1 ttl=64 time=0.809 ms
64 bytes from 10.42.0.86: icmp_seq=2 ttl=64 time=0.849 ms
^C
--- 10.42.0.86 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1027ms
rtt min/avg/max/mdev = 0.809/0.829/0.849/0.020 ms


Connect to your board over telnet:
==


alan@dev:~/nuttxspace/nuttx$ telnet 10.42.0.86
Trying 10.42.0.86...
Connected to 10.42.0.86.
Escape character is '^]'.


NuttShell (NSH) NuttX-12.0.0
nsh>




BR,


Alan


On 1/28/23, Tim Hardisty mailto:t...@hardisty.co.uk>> 
wrote:
>> On 28/01/2023, 00:09, "Masayuki Ishikawa"wrote:
>
>> Shall we move the discussions to the github issues?
>
> https://github.com/apache/nuttx/issues/8325 
> 
>
>
> :)
>
>





Re: RNDIS

2023-01-28 Thread Alan C. Assis
Hi Tim,

I just confirmed that it still working fine and I'll close your issue.

This is a step-by-step process that everyone can follow to get it working:

Configure your board:
=

$ ./tools/configure.sh stm32f4discovery:rndis

Compile NuttX to your board:


$ make -j

Flash to your board:


$ sudo openocd -f interface/stlink.cfg -f target/stm32f4x.cfg -c init
-c "reset halt" -c "flash write_image erase nuttx.bin 0x0800"
Open On-Chip Debugger 0.11.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To
override use 'transport select '.
Info : The selected transport took over low-level target control. The
results might differ compared to plain JTAG/SWD
Info : clock speed 2000 kHz
Info : STLINK V2J14S0 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.203144
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : starting gdb server for stm32f4x.cpu on 
Info : Listening on port  for gdb connections
target halted due to debug-request, current mode: Thread
xPSR: 0x0100 pc: 0x08000188 msp: 0x20003f24
Info : device id = 0x10036413
Info : flash size = 1024 kbytes
auto erase enabled
wrote 262144 bytes from file nuttx.bin in 11.043253s (23.182 KiB/s)

Info : Listening on port  for tcl connections
Info : Listening on port  for telnet connections


Reset your board


Run dmesg to confirm that USB RNDIS device was detected:


[ 1099.821480] usb 3-3: new full-speed USB device number 12 using xhci_hcd
[ 1099.972379] usb 3-3: New USB device found, idVendor=584e,
idProduct=5342, bcdDevice= 0.01
[ 1099.972389] usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1099.972393] usb 3-3: Product: RNDIS gadget
[ 1099.972396] usb 3-3: Manufacturer: NuttX
[ 1099.972398] usb 3-3: SerialNumber: 1234
[ 1099.988952] usbcore: registered new interface driver cdc_ether
[ 1099.990144] rndis_host 3-3:1.0: skipping garbage
[ 1099.990641] rndis_host 3-3:1.0: dev can't take 1558 byte packets
(max 660), adjusting MTU to 602
[ 1099.992089] rndis_host 3-3:1.0 eth0: register 'rndis_host' at
usb-:00:14.0-3, RNDIS device, a0:e0:de:ad:ca:fe
[ 1099.992102] usbcore: registered new interface driver rndis_host
[ 1099.994026] usbcore: registered new interface driver rndis_wlan
[ 1099.997001] rndis_host 3-3:1.0 enxa0e0deadcafe: renamed from eth0


Configure your Ubuntu or other Linux distro to share network:
=

Click in the top right corner of your Ubuntu and go to:

NuttX Ethernet -> Wired Settings

Click in the 'Gear icon' and in the tab "IPv4" select: "Shared to
other computers"

Click on "Apply" button

Disconnect and connect the USB cable to force it to get IP.

Verify which IP your board got:
===

$ tail -f /var/log/syslog
...
Jan 28 10:30:24 dev dnsmasq-dhcp[35526]: DHCPDISCOVER(enxa0e0deadcafe)
00:e0:de:ad:ca:fe
Jan 28 10:30:24 dev dnsmasq-dhcp[35526]: DHCPOFFER(enxa0e0deadcafe)
10.42.0.86 00:e0:de:ad:ca:fe
Jan 28 10:30:24 dev dnsmasq-dhcp[35526]: DHCPREQUEST(enxa0e0deadcafe)
10.42.0.86 00:e0:de:ad:ca:fe
Jan 28 10:30:24 dev dnsmasq-dhcp[35526]: DHCPACK(enxa0e0deadcafe)
10.42.0.86 00:e0:de:ad:ca:fe nuttx
Jan 28 10:30:29 dev systemd[1]: NetworkManager-dispatcher.service:
Deactivated successfully.
^C

Ping this IP to confirm it is working:
==

alan@dev:~/nuttxspace/nuttx$ ping 10.42.0.86
PING 10.42.0.86 (10.42.0.86) 56(84) bytes of data.
64 bytes from 10.42.0.86: icmp_seq=1 ttl=64 time=0.809 ms
64 bytes from 10.42.0.86: icmp_seq=2 ttl=64 time=0.849 ms
^C
--- 10.42.0.86 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1027ms
rtt min/avg/max/mdev = 0.809/0.829/0.849/0.020 ms

Connect to your board over telnet:
==

alan@dev:~/nuttxspace/nuttx$ telnet 10.42.0.86
Trying 10.42.0.86...
Connected to 10.42.0.86.
Escape character is '^]'.

NuttShell (NSH) NuttX-12.0.0
nsh>


BR,

Alan

On 1/28/23, Tim Hardisty  wrote:
>> On 28/01/2023, 00:09, "Masayuki Ishikawa"wrote:
>
>> Shall we move the discussions to the github issues?
>
> https://github.com/apache/nuttx/issues/8325
>
>
> :)
>
>


Short delay

2023-01-28 Thread Max Kriegleder

Hi All,

For a specific use case I need to delay execution on the the order of 
100 - 1 us. The obvious choice would be usleep however I noticed 
that depending on the platform I get something like 124-140 us instead 
of 100 us delay. I have created an issue on github for this 
https://github.com/apache/nuttx/issues/8207, but I think I understand by 
now why usleep cannot achieve what I am looking for - at least in the 
current implementation. I guess I need something along the lines of an 
alarm with very short alarm periods.


I am using the tickless OS setting with 1 USEC_PER_TICK and ultimately I 
want to control a stepper motor where I need to delay toggling of pins 
for very short and accurate amounts of time to achieve a certain 
movement profile of the motor - just for information, maybe I am 
thinking in the wrong direction.


Thanks!
Max



Re: Lua fails to build

2023-01-28 Thread Tim Hardisty
> On 28/01/2023, 08:51, "Russell Haley" wrote:

> I am not receiving emails on this email account. 

I believe that the apache mail reflector is the root cause of this, if emails 
are sent with a DKIM signature. The reflector adds new headers which cause the 
DKIM signature to fail. Any email service that checks DKIM will then reject the 
email as SPAM and may not even deliver it. Gmail is the "worst" and 
unilaterally rejects emails for reasons of its own with no rational 
explanation, for no technical reason, and no way to find out why. I know this 
through bitter experience with our work email which rarely gets through to any 
gmail recipient despite emails passing every deliverability test I can find!

I have moved to using my personal email for NuttX as that does not use DKIM, 
and my emails now get through to most dev@NuttX subscribers.






Re: RNDIS

2023-01-28 Thread Tim Hardisty
> On 28/01/2023, 00:09, "Masayuki Ishikawa"wrote:

> Shall we move the discussions to the github issues?

https://github.com/apache/nuttx/issues/8325


:)



Re: Simulator, NOR flash file system, MTD

2023-01-28 Thread Alexander Oryshchenko
Hi Xiang Xiao,

Thank you! I've missed 1, didn't notice that we have simulators for a few
NOR FLASHs. It is RAM based, but it may be a good point for me to start.

-Alexander

On Fri, Jan 27, 2023 at 9:47 PM Xiang Xiao 
wrote:

> You can try the follow config directly:
> 1.spi flash simulator + smartfs:
>
> https://github.com/apache/nuttx/blob/master/arch/sim/src/sim/sim_initialize.c#L59-L225
> 2.ram mtd + :smartfs/littlefs/nxffs:
>
> https://github.com/apache/nuttx/blob/master/boards/sim/sim/sim/src/sim_bringup.c#L157-L238
>
>
> On Sat, Jan 28, 2023 at 3:14 AM Alexander Oryshchenko <
> a.oryshche...@gmail.com> wrote:
>
> > What is the easiest way to use NOR- FFS (SmartFs, Spiffs, LittleFs...)
> over
> > host's file?
> > May be somebody knows NOR FLASH simulator for Linux?
> > Any other way?
> >
>


Re: Simulator, NOR flash file system, MTD

2023-01-28 Thread Alexander Oryshchenko
Hi Alan, Ken!

Thanks!
Looks that HostFS + file_there + filemtd + ... may do what I need.
In general I need to have file on the host which is organized like NOR
FLASH (256b write pages, 4k erase).

-Alexander


On Fri, Jan 27, 2023 at 9:58 PM Ken Pettit  wrote:

> Hey Guys,
>
> Yes, I had SmartFS running in the simulator at one point, but it was
> backed by a big char array.  But I'm trying to understand the use case
> ... are you jsut looking for a file system in the simulator to use for
> testing an application?  Are you looking for host backed because you
> want data to be persistent in the simulator from run to run?  Do you
> specifically want to test out NOR flash access type access?  On the
> host, does the data need to be in a single file or can it just be in a
> directory?
>
> Because I also wrote a full FS (HostFS) that gives a host backed
> filesystem in NuttX, but it works by publishing a host directory to
> NuttX, and doesn't really simulate Flash / NOR.  So it depends if you
> are specifically looking to implement it as a pseudo NOR flash, if you
> are wanting the FS to end up in a single file on the host that looks
> like a NOR device, etc.
>
> If you specifically want NOR simulation that ends up in a single Host
> file, then you could probably setup HostFS and then setup SmartFS (or
> LittleFs, etc.) to work with an MTD device that is backed by  file MTD
> with the file residing in the HostFS mount.
>
> Also note that if you follow that approach and use SmartFS, I also wrote
> a FUSE filesystem for Linux that allows it to natively mount a SmartFS
> filesystem contained in a file.
>
> Ken
>
> On 1/27/23 11:55 AM, Alan C. Assis wrote:
> > Hi Alexander,
> >
> > Some time ago Ken Pettit wrote a SmartFS simulator.
> >
> > If I'm not wrong it could be used with NuttX SIM(ulator).
> >
> > BR,
> >
> > Alan
> >
> > On 1/27/23, Alexander Oryshchenko  wrote:
> >> What is the easiest way to use NOR- FFS (SmartFs, Spiffs, LittleFs...)
> over
> >> host's file?
> >> May be somebody knows NOR FLASH simulator for Linux?
> >> Any other way?
> >>
>
>


RE: Lua fails to build

2023-01-28 Thread Russell Haley
Hi, 

I am not receiving emails on this email account. I see on the archive that 
Xiang Xiao has replied. I have checked my spam folder but it is empty. I had 
previously subscribed and un-subscribed to this list from this email address 
and I think maybe the mailing list is not sending the emails due to that 
previous cancelation? 

I have now subscribed from my gmail account and hope to have better luck.

Regards,
Russell

Sent from Mail for Windows

From: Russell Haley
Sent: Thursday, January 26, 2023 9:37 PM
To: dev@nuttx.apache.org
Subject: Lua fails to build

Hi,

I am trying to build the Lua interpreter into the sim:nsh sample code using the 
menuconfig (Applications->Interpreters->Lua). The Lua interpreter seems to be 
missing libmath. I tried adding `CFLAGS += -lm` but it didn’t seem to help. Can 
anyone tell me how to add the Lua interpreter correctly?

Thanks,
Russ

Build failure:

…
  LD:  nuttx
  CC:  -x c allsyms.tmp
  /usr/bin/ld: nuttx.rel: in function `numarith':
  
/home/osboxes/nuttx86_64/apps/interpreters/lua/lua-5.4.0/src/lobject.c:80: 
undefined reference to `pow'
  /usr/bin/ld: 
/home/osboxes/nuttx86_64/apps/interpreters/lua/lua-5.4.0/src/lobject.c:81: 
undefined reference to `floor'
  /usr/bin/ld: nuttx.rel: in function `luaV_flttointeger':
  
/home/osboxes/nuttx86_64/apps/interpreters/lua/lua-5.4.0/src/lvm.c:122: 
undefined reference to `floor'
  /usr/bin/ld: nuttx.rel: in function `luaV_modf':
  
/home/osboxes/nuttx86_64/apps/interpreters/lua/lua-5.4.0/src/lvm.c:755: 
undefined reference to `fmod'
  /usr/bin/ld: nuttx.rel: in function `luaV_execute':
  
/home/osboxes/nuttx86_64/apps/interpreters/lua/lua-5.4.0/src/lvm.c:1372: 
undefined reference to `pow'
  /usr/bin/ld: 
/home/osboxes/nuttx86_64/apps/interpreters/lua/lua-5.4.0/src/lvm.c:1380: 
undefined reference to `floor'
  /usr/bin/ld: 
/home/osboxes/nuttx86_64/apps/interpreters/lua/lua-5.4.0/src/lvm.c:1430: 
undefined reference to `pow'
  /usr/bin/ld: 
/home/osboxes/nuttx86_64/apps/interpreters/lua/lua-5.4.0/src/lvm.c:1438: 
undefined reference to `floor'
  /usr/bin/ld: nuttx.rel: in function `math_sin':
  
/home/osboxes/nuttx86_64/apps/interpreters/lua/lua-5.4.0/src/lmathlib.c:41: 
undefined reference to `sin'
  /usr/bin/ld: nuttx.rel: in function `math_cos':
  
/home/osboxes/nuttx86_64/apps/interpreters/lua/lua-5.4.0/src/lmathlib.c:46: 
undefined reference to `cos'
  /usr/bin/ld: nuttx.rel: in function `math_tan':
  
/home/osboxes/nuttx86_64/apps/interpreters/lua/lua-5.4.0/src/lmathlib.c:51: 
undefined reference to `tan'
  /usr/bin/ld: nuttx.rel: in function `math_asin':
  
/home/osboxes/nuttx86_64/apps/interpreters/lua/lua-5.4.0/src/lmathlib.c:56: 
undefined reference to `asin'
  /usr/bin/ld: nuttx.rel: in function `math_acos':
  
/home/osboxes/nuttx86_64/apps/interpreters/lua/lua-5.4.0/src/lmathlib.c:61: 
undefined reference to `acos'
  /usr/bin/ld: nuttx.rel: in function `math_atan':
  
/home/osboxes/nuttx86_64/apps/interpreters/lua/lua-5.4.0/src/lmathlib.c:68: 
undefined reference to `atan2'
  /usr/bin/ld: nuttx.rel: in function `math_floor':
  
/home/osboxes/nuttx86_64/apps/interpreters/lua/lua-5.4.0/src/lmathlib.c:99: 
undefined reference to `floor'
  /usr/bin/ld: nuttx.rel: in function `math_ceil':
  
/home/osboxes/nuttx86_64/apps/interpreters/lua/lua-5.4.0/src/lmathlib.c:110: 
undefined reference to `ceil'
  /usr/bin/ld: nuttx.rel: in function `math_fmod':
  
/home/osboxes/nuttx86_64/apps/interpreters/lua/lua-5.4.0/src/lmathlib.c:128: 
undefined reference to `fmod'
  /usr/bin/ld: nuttx.rel: in function `math_modf':
  
/home/osboxes/nuttx86_64/apps/interpreters/lua/lua-5.4.0/src/lmathlib.c:147: 
undefined reference to `ceil'
  /usr/bin/ld: 
/home/osboxes/nuttx86_64/apps/interpreters/lua/lua-5.4.0/src/lmathlib.c:147: 
undefined reference to `floor'
  /usr/bin/ld: nuttx.rel: in function `math_sqrt':
  
/home/osboxes/nuttx86_64/apps/interpreters/lua/lua-5.4.0/src/lmathlib.c:157: 
undefined reference to `sqrt'
  /usr/bin/ld: nuttx.rel: in function `math_log':
  
/home/osboxes/nuttx86_64/apps/interpreters/lua/lua-5.4.0/src/lmathlib.c:173: 
undefined reference to `log'
  /usr/bin/ld: 
/home/osboxes/nuttx86_64/apps/interpreters/lua/lua-5.4.0/src/lmathlib.c:178: 
undefined reference to `log2'
  /usr/bin/ld: 
/home/osboxes/nuttx86_64/apps/interpreters/lua/lua-5.4.0/src/lmathlib.c:181: 
undefined reference to `log10'
  /usr/bin/ld: 
/home/osboxes/nuttx86_64/apps/interpreters/lua/lua-5.4.0/src/lmathlib.c:183: 
undefined reference to