tty philosophy

[Tim Hardisty]

I am sorting out flexcom support for the SAMA5D2 as there are issues with the 
arch files as well as Kconfig. In doing so, I would like to do it “right”.

 

If flexcoms are assigned as USARTs is the correct philosophy to register them 
sequentially or as per flexcom port number? For example, if (only) flexcoms 2 
and 3 are configured as USARTs should they be ttyFC0 and ttyFC1, or ttyFC2 and 
ttyFC3?

Re: CAN example crashes

[Tim Hardisty]

Thanks Alan - those are already set but don't seem to produce any output on the 
console so may be the error output itself isn't configured right. I'll take a 
look.

On 07/05/2021, 18:49, "Alan Carvalho de Assis"  wrote:

>Hi Tim,

>Try to enable the debug in the menuconfig:

>   Build Setup  --->
>  Debug Options  --->
>[*] Enable Debug Features
>[*]   Enable Error Output
>[*] Enable Warnings Output
>[*]   Enable Informational Debug Output
>
>[*]   CAN Debug Features
>[*] CAN Error Output
>[*] CAN Warnings Output
>[*] CAN Informational Output


>>On 5/7/21, Tim  wrote:
>> Hi,
>>
>>
>>
>> SAMA5D27 (custom board) - trying to complete the port and also check that
>> the CAN interface works on the board, so I'm trying to use the CAN 
example
>> app.
>>
>>
>>
>> The drivers appear to be registered (I see /dev/can0 and /dev/can1) but 
>> the
>> CAN example app crashes when trying to open /dev/can0 and I can't see 
why.
>>
>
>>
>> I am hindered in debugging this fully as yet since:
>>
>>
>>
>> a.   I am new to Nuttx and haven't yet sussed how to enable any low 
level
>> debug-type stuff (I have used menuconfig to enable anything that seems to
>> be
>> related but I'm sure I missed stuff)
>> b.   I haven't yet coerced my Eclipse IDE (under Windows 10, but code
>> configured and compiled using Windows WSL) to "see" the source code
>> properly
>> to enable me to insert breakpoints (Segger J-link). Not wedded to 
Eclipse,
>> but it is a known entity for me and at least downloads/runs/debugs the
>> board!)
>>
>>
>>
>> Can anyone point me in the direction of why, or a way to find out why, 
the
>> call to open the device would crash the board rather than return an 
error?
>> Other devices (such as Flexcom USARTs open OK and work - well, after I
>> fixed
>> some arch issues for Flexcoms on the SAMA5 anyway!!). The board-specific
>> code (sam_can.c) I am using is based on the code for the sama5d2-xult 
>> board
>> and seems pretty trivial, and largely similar to many other architectures
>> and boards.

Re: CAN example crashes

[Tim Hardisty]

>> Is there any description somewhere about this example ?
>>
>There is some in apps/examples/README.md, but not a lot of info.

Not much, no, but the example code is pretty self-explanatory!

Re: Dev environment

[Tim Hardisty]

Thanks Alan. Compiling is no problem it is debugging that is my issue. I see 
from your process that you copied the elf from the WSL environment to the 
Windows /mnt/c ...I haven't tried that but I am not sure it will help eclipse 
find the source code...unless I also replicate the source tree on the Windows 
side perhaps. It is a few more things to try at least, so thank you.
>Hi Tim,
   >
>I don't use Windows or MacOS, but some time ago just tested NuttX on
>WSL to help other to get started to NuttX on Windows, I documented the
>process here:
   >
>https://acassis.wordpress.com/2018/01/10/how-to-build-nuttx-on-windows-10/
>
>I hope it helps you!

>> I need to debug it. I will need to get to that point regardless.
>>

Re: Dev environment

[Tim Hardisty]

Thanks Flavio - I hadn't thought about using a VM; that would avoid yet another 
lump of PC hardware cluttering up the place if I can't get the WSL or MAC 
approach to work.

I am really hating Window at the moment (1 machine can connect to my Mac, the 
other can't...many hours wasted NOT fixing it!) and I had thought it time to 
jump ship to Mac...but Linux seems even more appealing right now!!

On 11/05/2021, 18:24, "Flavio Castro Alves Filho"  
wrote:

Hello Tim,

What I do here to implement a NuttX application is to use an Ubuntu
Server VM (in my case, VMWare).

In this VM, I map my Jlink (which is a nucleo board with changed
firmware). I use Segger tools to load the firmware.

To code, I use VSCode in Windows with SSH access to the VM (I set a
host-only network).

For the toolchain, I use x-pack arm-gcc. The toolchain provided by
ubuntu does not provide gdb.

You can use the VSCode extension with GDB and JLink to run.

Hope it helps.

Best regards,

Flavio

Re: Dev environment

[Tim Hardisty]

I have the board booting from AT91bootstrap and Uboot, from QSPI no problem. 
Downloading code using JLink from Windows/eclipse is fine, but the debugging is 
broken/mis-configured. I will probably have another go at a Windows-hosted 
development environment and have the arm cross compilers installed already: 
since it works for the Atmel "softpack" stuff from which I derived my initial 
board debugging code (before moving to NuttX) I see no reason why it shouldn't 
work for NuttX using tool chains, within Eclipse, once I finally get my head 
around it and find the magic trick!

Seems I have a few things more to try now, at least.

On 11/05/2021, 18:36, "Gregory Nutt"  wrote:


>> It seems that it is possible to run JLink from Windows in WSL.
>I used J-Link under Windows to bring up the SAMA5Dx.  The only tricky 
>thing was booting from an SD card with U-boot.

Re: Dev environment

[Tim Hardisty]

Hmm...do need Windows for my schematic capture and 3D design applications, but 
Mac little used as yet...I'm thinking dual boot Mac/Ubuntu is probably the way 
to go!

On 11/05/2021, 20:30, "Alan Carvalho de Assis"  wrote:

Also, if you are not dependent on Windows, just install Linux on your
computer, it will avoid all those tricks to get the work done ;-)

Re: Dev environment

[Tim Hardisty]

I see from https://www.mail-archive.com/dev@nuttx.apache.org/ that others have 
replied. These have not got through to me so apologies for not yet taking up 
the offers of assistance.

I will try and sort whatever the email issue is and then reply!

RE: Dev environment

[Tim Hardisty]

>From: Alan Carvalho de Assis 
>
>Did you enable CONFIG_DEBUG_CAN_INFO in your menuconfig?
>
>  │ -> Build Setup
>   │
>  │   -> Debug Options
>   │
>  │ -> Enable Debug Features (DEBUG_FEATURES [=y])
>   │
>  │   -> CAN Debug Features (DEBUG_CAN [=y])
>

Indeed I did. And, anyway, even if I hadn't my debug message might appear but 
the system would keep running, but it doesn't: it crashes. I have inserted the 
while(1) to narrow it down to where it crashesit is the call to that debug 
message that does it :(

RE: Dev environment

[Tim Hardisty]

>On 5/12/21, Tim Hardisty  wrote:
>>>From: Alan Carvalho de Assis 
>>>
>>>Did you enable CONFIG_DEBUG_CAN_INFO in your menuconfig?
>>>
>>>  │ -> Build Setup
>>>   │
>>>  │   -> Debug Options
>>>   │
>>>  │ -> Enable Debug Features (DEBUG_FEATURES [=y])
>>>   │
>>>  │   -> CAN Debug Features (DEBUG_CAN [=y])
>>>
>>
>> Indeed I did. And, anyway, even if I hadn't my debug message might
>> appear but the system would keep running, but it doesn't: it crashes.
>> I have inserted the while(1) to narrow it down to where it
>> crashesit is the call to that debug message that does it :(
>>
>
>Try to put a sam_piowrite(PIO_LED_YOURLED, true/false); to between the
>caninfo() and the while(1); just for a double check ;-)
>
>By PIO_LED_YOURLED I mean the LED that is turning ON when your board
>initializes.
>
>Talking about LEDs... other important thing: normally when NuttX crashes the
>board LED start to blink to indicate an issue, is it blinking on your board?

This is a custom board, and no LED such as that. I have removed any LED-related 
stuff from the board.h file...is that the issue? Maybe NuttX absolutely depends 
on some kind of LED?

RE: Assert and Debug issues

[Tim Hardisty]

>>From: disruptivesolution...@gmail.com 

>1) If I enable Debug Assertions the build will not run at all as it halts very 
>very
>early on. Debugger suggests the system is in up_idle().

>> Mostly this is caused by a "fault" somewhere down the line.
>> Does it "print" ABCDE?

Nope, nothing. It simply appears to do nothing. Any messages are not 
"escaping". 

>>Did you enable "debug" in make menuconfig?

As in "Enable Debug Feature"? Yes. If there's something else I missed I can't 
find it!

>2) Any (valid and enabled) call for a debug info/warn/error message produces
>no actual message on the console. Not just in the CAN example but others
>too. Console (and nsh) working fine. For example, the PWM example works
>just fine. If I enable debug messages for this it doesn't crash, still works as
>expected, but no debug message text. FYI I added this to the example to
>prove the point:
>
>  #if defined CONFIG_DEBUG_PWM_INFO
>  printf("PWM_WARN_PRINTF_DEBUG\n");
>  pwmerr("PWMINFO: starting pwm example PWM\n");
>  #else
>printf("JUST A PWM WARN PRINTF\n");
>  #endif
>
>I get the "PWM_WARN_PRINTF_DEBUG" text on the console, but not the
>"PWMINFO:starting pwm example PWM" text. 

>> pwmerr is only when the "error" on PWM occurs. Did you try _info? Or 
>> caninfo? 

Pwmerr will be called as per coding. I called it in the case of no error and it 
should work. But even pwminfo and pwmwarn (or caninfo or canwarn) do not 
produce text EVER. Nor do any other debug calls in any other place. Ever.

>But I am trying to continue to basically prove my board is actually OK from a 
>hardware point of view. 

>> Why should it not be? Does nsh work and USART? (basic functionality?). And 
>> SPI?

Because it's a new board and a new port, and the first time NuttX has been run 
on it. Nsh works, USART works, SPI - not tested yet. I can run built-in apps 
from the nsh console...and it is running the CAN example this way that I see 
the crash; and running the PWM example this way that I see no debug messages.

These things all work with my bare metal code derived from the Atmel "softpack" 
except CAN because I think the softpack CAN code is buggy so I am not 100% sure 
the CAN hardware works right yet. I would rather spend my time getting it 
working under NuttX than bare metal as the bare metal route is not being 
pursued now.

>

>Can anyone offer any insight into why Assert and debug info/warn/error
>messages are "misbehaving" like this? --> I tried to give you some heads up.

>>https://nuttx.apache.org/docs/latest/quickstart/debugging.html

Yes, I have followed that. I have read everything I can find, Googled for 
hours, and no luck yet :(

I should have my full Linux dev environment up and running by Monday and I hope 
I can then debug it properly. But in the mean time I still hope to get basic 
assert and debug messages working!

Re: Dev environment

[Tim Hardisty]

With thanks to Flavio's suggestion (and .json file to point me in the 
right direction) I now have VS Code running under Ubuntu as a full IDE - 
edit/build/debug with Segger jlink all from within VS Code


Had to create custom scripts in the launch.json file to ensure no reset 
on download of nuttx to my sama5d27 otherwise it messed with the 
bootstrap+Uboot config of the processor. Also a bit of faffing to get 
the arm-none-eabi tools from ARM to work (lots of symbolic links needed).


Is this worth documenting and sharing anything anywhere? I know the 
processor is perhaps a bit obscure, but it might help someone - if so, 
please let me know where/how to best share my information, otherwise I 
will simply document as part of my own project.


Tomorrow will see the start of actually debugging the cause of the 
CANbus driver crashes, but I can now actually do this with proper tools 
at my disposal. And once fixed and proven I will then work out how to do 
pull requests to get the fixes made available...I'm nearly coding in the 
21st century now lol.


On 21/05/2021 20:51, Flavio Castro Alves Filho wrote:

Hello Tim,

I use VSCode with GDB and Segger.

But Ubuntu does not come with GDB. So I use x-pack toolchain to build and debug.

It works well.

Best regards,

Flavio


Em sex., 21 de mai. de 2021 às 13:28, Tim  escreveu:

Eventually got a Linux dev environment up and running (first PC purchased 
failed after a few hours...grrr...now have an Intel i5 NUC for this).  Amazed 
how darn fast compilation is compared to WSL (even on my 3.3GHz Zeon-based 
workstation with the -j6 make option) so that in itself means it was a great 
move! Always liked Linux anyway lol.

Eclipse (latest version) still not playing ball - just won't debug. So I'm 
assuming a platform independent setup issue with it; aka finger trouble :(

I am temporarily using Segger Ozone - worked first time and can finally debug. 
Not sure I like it but hey ho.

As an aside, has anyone got a recommendation of a good, graphical, GDB debugger for 
Linux, that place nicely with NuttX? Not bothered about an IDE as such, and I'm 100% 
happy with building via terminal, but a feature rich and easy to use debugger that looks 
up the source code "thoroughly" is an essential.

But, now I can set breakpoints, I found that lack of debug messages on the 
console was because the .config was sending them to RAM not CONSOLE, because 
that's what is in the sama5d2-xult defconfig file I based my custom config on.

Simple explanation, but is this documented anywhere? Can't find that level of 
syslog stuff using make menuconfig?

Also now, at least, I know that the board is crashing in can_hwinitialize when 
it calls can_putreg(priv, SAM_PMC_PCR, regval)...so next week's task is to find 
out what's up with this (it's not my code).


On 5/12/21, Tim Hardisty  wrote:

From: Alan Carvalho de Assis 

Did you enable CONFIG_DEBUG_CAN_INFO in your menuconfig?

  │ -> Build Setup
   │
  │   -> Debug Options
   │
  │ -> Enable Debug Features (DEBUG_FEATURES [=y])
   │
  │   -> CAN Debug Features (DEBUG_CAN [=y])


Indeed I did. And, anyway, even if I hadn't my debug message might
appear but the system would keep running, but it doesn't: it crashes.
I have inserted the while(1) to narrow it down to where it
crashesit is the call to that debug message that does it :(


Try to put a sam_piowrite(PIO_LED_YOURLED, true/false); to between the
caninfo() and the while(1); just for a double check ;-)

By PIO_LED_YOURLED I mean the LED that is turning ON when your board
initializes.

Talking about LEDs... other important thing: normally when NuttX
crashes the board LED start to blink to indicate an issue, is it blinking on 
your

board?

This is a custom board, and no LED such as that. I have removed any LED-
related stuff from the board.h file...is that the issue? Maybe NuttX absolutely
depends on some kind of LED?

Re: CAN example crashes

[Tim Hardisty]

On 07/05/2021 17:48, Tim wrote:

Hi,

  


SAMA5D27 (custom board) - trying to complete the port and also check that
the CAN interface works on the board, so I'm trying to use the CAN example
app



As per my other thread, Linux+VS Code+Segger all up and running so I can 
see what's going on now.


Found an error in sam_can.c for sama5 which was why it was crashing - 
have fixed and will do the necessary PR in due course.


However, the main problem is that the sama5 board files all use "can" 
but it should be "mcan"...so all the register addresses and possibly 
functions/methods are wrong :(


Before I attempt to rework it to use mcan, has anyone actually got 
Nuttx+CAN working on a sama5? It could save me loads if work if so!!??

Re: Memory locations

[Tim Hardisty]

On 07/06/2021 20:45, Gregory Nutt wrote:


I will, I believe, need to declare - place - MCAN related structures 
such

that they (or at least some elements of them) are in SRAM.


You will need to exercise care.  SRAM (called isram in the linker
scripts) is already used for other things including the MMU page table:
https://github.com/patacongo/incubator-nuttx/blob/master/boards/arm/sama5/sama5d2-xult/scripts/dramboot.ld#L21 



The first 112Kb should be available, however, unless the board logic
uses that too.


Thanks Greg - needs no more than 4kbyte. Just got to understand linker 
scripts now lol and will check for any board logic usage there (there's 
none that I've set up for my board, at least)

Re: Memory locations

[Tim Hardisty]

On 07/06/2021 19:06, Nathan Hartman wrote:

On Mon, Jun 7, 2021 at 12:24 PM Tim wrote:

I will, I believe, need to declare - place - MCAN related structures such
that they (or at least some elements of them) are in SRAM.


Yes. It is possible. It is done by adding attributes in the code which
tell the compiler that an object should be located at a particular
address or section.


I have added this to my linker script (and other variations on that 
theme, all of which compile OK with no warnings or errors)


    .isramdata :
    {
    } > isram

and declared

static uint32_tg_mcan0_msgram[MCAN0_MSGRAM_WORDS] 
__attribute__((section(".isramdata"))) = {0};

But it does not place the array in isram :(
system.map states: 20053fc4 D g_mcan0_msgram
which is confirmed by the debugger and an info debug message
Is there anything overruling this? Or a silly mistake, given my 
inexperience with linker scripts?

Any guidance much appreciated!

Re: Memory locations

[Tim Hardisty]

Thanks, but still no cigar :(

I have tried:

    .isramdata_reserve (NOLOAD) :
    {
    *(.isramdata)
    . = ALIGN(4);
    _isramdata_heap_start = ABSOLUTE(.);
    } > isram

and also just

    .isramdata(NOLOAD) :
    {
    *(.isramdata)
    } > isram

along with trying

staticuint32_tg_mcan0_msgram[MCAN0_MSGRAM_WORDS] 
aligned_data(MCAN_ALIGN) locate_data(".isramdata");

where MCAN_ALIGN is ARMV7A_DCACHE_LINESIZE, which is 32
or
static uint32_t g_mcan0_msgram[MCAN0_MSGRAM_WORDS] __attribute__ 
((section (".isramdata")));

and all methods still report this as in SDRAM not ISRAM
On 08/06/2021 13:33, David Sidrane wrote:

Here is a working example.


https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/stm32h7/stm32_spi.c#L715-L716

https://github.com/apache/incubator-nuttx/blob/master/boards/arm/stm32h7/nucleo-h743zi/scripts/flash.ld#L179-L184

You can check it the arm-none-eabi-nm -C nuttx.elf | grep g_mcan0_msgram

David

-Original Message-
From: Tim Hardisty [mailto:t...@jti.uk.com]
Sent: Tuesday, June 08, 2021 4:23 AM
To: dev@nuttx.apache.org
Subject: Re: Memory locations


On 07/06/2021 19:06, Nathan Hartman wrote:

On Mon, Jun 7, 2021 at 12:24 PM Tim wrote:

I will, I believe, need to declare - place - MCAN related structures such
that they (or at least some elements of them) are in SRAM.


Yes. It is possible. It is done by adding attributes in the code which
tell the compiler that an object should be located at a particular
address or section.

I have added this to my linker script (and other variations on that
theme, all of which compile OK with no warnings or errors)

  .isramdata :
  {
  } > isram

and declared

static uint32_tg_mcan0_msgram[MCAN0_MSGRAM_WORDS]
__attribute__((section(".isramdata"))) = {0};
But it does not place the array in isram :(
system.map states: 20053fc4 D g_mcan0_msgram
which is confirmed by the debugger and an info debug message
Is there anything overruling this? Or a silly mistake, given my
inexperience with linker scripts?
Any guidance much appreciated!

Re: Memory locations

[Tim Hardisty]

Thanks, but still no cigar :(

I have tried:

    .isramdata_reserve (NOLOAD) :
    {
    *(.isramdata)
    . = ALIGN(4);
    _isramdata_heap_start = ABSOLUTE(.);
    } > isram

and also just

    .isramdata(NOLOAD) :
    {
    *(.isramdata)
    } > isram

along with trying

staticuint32_tg_mcan0_msgram[MCAN0_MSGRAM_WORDS] 
aligned_data(MCAN_ALIGN) locate_data(".isramdata");

where MCAN_ALIGN is ARMV7A_DCACHE_LINESIZE, which is 32
or
static uint32_t g_mcan0_msgram[MCAN0_MSGRAM_WORDS] __attribute__ 
((section (".isramdata")));

and all methods still report this as in SDRAM not ISRAM
On 08/06/2021 13:33, David Sidrane wrote:

Here is a working example.


https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/stm32h7/stm32_spi.c#L715-L716

https://github.com/apache/incubator-nuttx/blob/master/boards/arm/stm32h7/nucleo-h743zi/scripts/flash.ld#L179-L184

You can check it the arm-none-eabi-nm -C nuttx.elf | grep g_mcan0_msgram

David

-Original Message-
From: Tim Hardisty [mailto:t...@jti.uk.com]
Sent: Tuesday, June 08, 2021 4:23 AM
To: dev@nuttx.apache.org
Subject: Re: Memory locations


On 07/06/2021 19:06, Nathan Hartman wrote:

On Mon, Jun 7, 2021 at 12:24 PM Tim wrote:

I will, I believe, need to declare - place - MCAN related structures such
that they (or at least some elements of them) are in SRAM.


Yes. It is possible. It is done by adding attributes in the code which
tell the compiler that an object should be located at a particular
address or section.

I have added this to my linker script (and other variations on that
theme, all of which compile OK with no warnings or errors)

  .isramdata :
  {
  } > isram

and declared

static uint32_tg_mcan0_msgram[MCAN0_MSGRAM_WORDS]
__attribute__((section(".isramdata"))) = {0};
But it does not place the array in isram :(
system.map states: 20053fc4 D g_mcan0_msgram
which is confirmed by the debugger and an info debug message
Is there anything overruling this? Or a silly mistake, given my
inexperience with linker scripts?
Any guidance much appreciated!

Re: Memory locations

[Tim Hardisty]

On 08/06/2021 14:18, Sebastien Lorquet wrote:

what I would check here (just a live thought process)

* check that the ld file is actually used (ld file is pointed by main
Make.defs IIRC) (easy: just add garbage in it and verify build actually
breaks)



You, sir, have earned the cigar! Garbage added, didn't complain...lulled 
into a false sense of security because VScode coloured it all so nicely 
as *it* had found the declarations in *a* linker script no problem at 
all, just not the right one.



It's using uboot.ld not dramboot.ld and I was editing the latter. Doh! 
Complete idiot!!!



Thank you all who helped me out for your patience!

Re: Lin

[Tim Hardisty]

My custom board has a Lin/K-Line interface using a TJA1021 transceiver, but 
software support is low on the priority/roadmap at this time.

Nevertheless, I would be happy to be involved in testing (I have a CAN/LIN 
analyzer/stream generator) if it helps.

-Original Message-
From: Pavel Pisa 
Hello Simon and others,

On Friday 13 of August 2021 18:50:23 Frank-Christian Kruegel wrote:
> Am 13.08.2021 um 16:50 schrieb Simon Filgis:
> > has anybody implemented a LIN driver for SAME70 USART? The SAME70 USART
> > peripheral is capable of. A SW implementation (sllin.c - Pavel Pisa)
> > would also be interesting!
> >
> > Would you extend sma_lowputc.c and sam_serial.c or would you grep USARTx
> > in a separate file?
>
> Do you need LIN Master or LIN Slave?
>
> LIN Master is easy. It's standard serial.
...
> LIN slave is much more complex, especially if you want to do autobauding
> by measuring the SYNC byte after the break. You might end up with a
> custom serial driver then. If a fixed bitrate is enough the only problem
> is detecting the BREAK signal. A received break signal is basically a 0
> byte with a framing error added. You only need to detect and clear the
> framing error.

I am on the way to vacations now but I am interest in LIN interfacing
discussion when I return. I do not have actual need for LIN support
but getting some reasonable code upstream to NuttX and Linux.

There is my latest version from 2019

  https://github.com/ppisa/linux-lin

and some docs

  https://github.com/ppisa/linux-lin/wiki

Finite state machines and some other ideas from Linux kernel
implementation can be reused on NuttX. As for the API,
I think that to keep size of the applications low
on the targets which do not use TCP or SocketCAN,
NuttX API should be implemented through read, write
(enough for the master) and IOCTLs to maintain slave
responses cache.

As for bitrate autodetection, there are special
HW support in many UARTs for autodetect of the LIN
bitrate. It would worth to add mechanism to setup
it o NuttX. On GNU/Linux where sllin attempts to
be compatible with all UARTs through generic API
it is problematic. On NuttX we can define API,
which can allow to implement LIN specific
low level drivers for chips with special support
ad for other map the API to generic UART low
level part. Or we can conditionally extend  low
level API.

By the way
I return on Sunday August 22. It would be great
if prof. Roberto Bucher's and followup Michal Lenc's
presentation about PySimCoder on NuttX Workshop
can be scheduled on Sunday that I can attend them.

Best wishes
Pavel
-- 
Pavel Pisa
phone:  +420 603531357
e-mail: p...@cmp.felk.cvut.cz
Department of Control Engineering FEE CVUT
Karlovo namesti 13, 121 35, Prague 2
university: http://dce.fel.cvut.cz/
personal:   http://cmp.felk.cvut.cz/~pisa
projects:   https://www.openhub.net/accounts/ppisa
CAN related:http://canbus.pages.fel.cvut.cz/
company:https://www.pikron.com/

sama5D2 class D audio

[Tim Hardisty]

Working through the remaining driver support I need for my custom board and I 
can’t find anything related to audio for the sama5d2 devices (they have Class D 
capability, with lots of modes).

 

Before I dive in and find some time to create a driver from scratch, have I 
missed something? Documentation on audio support in general seems rather 
lacking so any pointers in the right direction would be appreciated (even just 
a suggestion of another processor with similar capability I can use as a 
reference).

 

TIA,

 

Tim.

Re: sama5D2 class D audio

[Tim Hardisty]

Yes, I saw I2S support as well as for external audio codec chips, but nothing 
for the on-chip Class D.

 

Are there any other supported processors that have on-board audio that I can 
use as a “template”? I’ve run out of ideas of what to search for!

 

From: Gregory Nutt 
Reply to: 
Date: Thursday, 19 August 2021 at 21:38
To: 
Subject: Re: sama5D2 class D audio

 

I implemented audo on the SAMA4D3 and D4:

 

./sama5d3x-ek/configs/nxplayer/defconfig:CONFIG_DRIVERS_AUDIO=y

./sama5d4-ek/configs/elf/defconfig:CONFIG_DRIVERS_AUDIO=y

./sama5d4-ek/configs/ipv6/defconfig:CONFIG_DRIVERS_AUDIO=y

./sama5d4-ek/configs/nsh/defconfig:CONFIG_DRIVERS_AUDIO=y

./sama5d4-ek/configs/nxwm/defconfig:CONFIG_DRIVERS_AUDIO=y

 

These, however, used I2S for interface to an WM8904 DAC.

 

On 8/19/2021 12:41 PM, Tim Hardisty wrote:

Working through the remaining driver support I need for my custom board and I 
can’t find anything related to audio for the sama5d2 devices (they have Class D 
capability, with lots of modes).

 

 

 

Before I dive in and find some time to create a driver from scratch, have I 
missed something? Documentation on audio support in general seems rather 
lacking so any pointers in the right direction would be appreciated (even just 
a suggestion of another processor with similar capability I can use as a 
reference).

 

 

 

TIA,

 

 

 

Tim.

 

 

 

Re: SPI EEPROM

[Tim Hardisty]

That’s AT24 I2C not AT25 SPI EEPROM unfortunatel,  and from a quick look it 
“just worked” ☹

 

 

 

From: Alan Carvalho de Assis 
Reply to: 
Date: Tuesday, 24 August 2021 at 18:01
To: 
Subject: Re: SPI EEPROM

 

Hi Tim,

 

You are right, Documentation is one of our "Achilles tendon".

 

But, of course, some times it is also the user search fault, maybe

they don't have the Google-fun skills yet (please don't take it as

personal).

 

If you search for NuttX EEPROM Tutorial

 

It will returns this tutorial:

 

https://www.youtube.com/watch?v=qzjf2JtgYN0

 

Please get us to improve this situation, write a tutorial at:

nuttx/Documentation/guides/ about it.

 

BR,

 

Alan

 

On 8/24/21, Tim  wrote:

The more time I spend with nuttx the more I think I just haven't found some

treasure trove of documentation somewhere. All I seem to end up doing is

searching every single file for some kind of clue as to what to do!

 

 

 

I have an SPI EEPROM device. Menuconfig allows me to set it up, lovely! I

end up with

 

CONFIG_EEPROM=y

 

CONFIG_SPI_EE_25XX=y

 

 

 

(Also SPI mode and frequency).

 

 

 

Now what..

 

 

 

If I search for either of those CONFIG parameters, the first is not

referenced anywhere (apart from my .config), the second confirms that it

will include spi_xx25xx.c as a source. Getting there..

 

 

 

It'll be ee25xx_initialize(FAR struct spi_dev_s *dev, FAR char *devname,

int

devtype, int readonly) I need to call - makes sense.

 

 

 

Only there is no explanation, or examples of, how to make that call, and a

Google search doesn't help either.

 

 

 

Next step will be to look for examples of spi_dev_s and see if I can deduce

it somehow.

 

 

 

Just how am I supposed to know how to call that initialisation code? Which

is why I started this question with the observation that surely I must be

missing something somewhere!!??

 

 

 

Yes, it's a bit of a whinge, but also a request for help..please :)

 

 

 

Re: SPI EEPROM

[Tim Hardisty]

I have 3 different SAMA5D2 eval board and have used them for years. I have had 
my custom board running “bare metal” code based on the Atmel code with no 
problems. Everything works, including the many many custom device on the board. 
I can swim. Using Lvgl too.

 

I made the decision to move to NuttX as I hoped it would make it easier to 
write the final app as I need USB host, USB device, and a file system. It 
feels, right now, like it was a bad move as the documentation is seemingly 
incomplete.

 

There is no point me getting yet another eval board just to prove that boards 
that are already supported work. Or should work - the SAMA5 eval boards are 
“supported” but are full of errors (e.g. flexcom is based on SAMA5D3 which is 
different; SAMA5D2 has MCAN but the D3 has CAN and needs a completely different 
driver; and so on. PRs to follow!!). As I have found, even basic devices such 
as nor flash or SPI EEPROM have only minimal support and, more importantly, no 
documentation that’s worth using.

 

I will just have to keep struggling, googling, grepping, and hoping to hit 
lucky. I will add to the documentation once I have it working. If I get it 
working.

 

And this is not aimed at you, Alan, as I know you are trying hard to help.

 

 

 

From: Alan Carvalho de Assis 
Reply to: 
Date: Tuesday, 24 August 2021 at 19:42
To: 
Subject: Re: SPI EEPROM

 

Hi Tim,

 

The process to get AT25 SPI is similar, but for SPI you need to get

the CS pin configure besides the other four SPI pins.

 

Is this your first time using SPI on NuttX?

 

There are some tutorials at NuttX Channel explaining how to use SPI on

NuttX, like using SDCard over SPI. I suggest you to start with a board

that has everything in place already, like the STM32F4Discovery or

BluePill (stm32f103-minimum).

 

Also the guys from MicroROS wrote a more technical tutorial about how

SPI works on NuttX:

 

https://github.com/micro-ROS/NuttX/issues/29

 

There is not theoretical class of swimming, you need to enter in the

water, just start in the shallow place: stm32 + sdcard spi for

example.

 

BR,

 

Alan

 

On 8/24/21, Tim Hardisty  wrote:

That’s AT24 I2C not AT25 SPI EEPROM unfortunatel,  and from a quick look it

“just worked” ☹

 

 

 

 

 

 

 

From: Alan Carvalho de Assis 

Reply to: 

Date: Tuesday, 24 August 2021 at 18:01

To: 

Subject: Re: SPI EEPROM

 

 

 

Hi Tim,

 

 

 

You are right, Documentation is one of our "Achilles tendon".

 

 

 

But, of course, some times it is also the user search fault, maybe

 

they don't have the Google-fun skills yet (please don't take it as

 

personal).

 

 

 

If you search for NuttX EEPROM Tutorial

 

 

 

It will returns this tutorial:

 

 

 

https://www.youtube.com/watch?v=qzjf2JtgYN0

 

 

 

Please get us to improve this situation, write a tutorial at:

 

nuttx/Documentation/guides/ about it.

 

 

 

BR,

 

 

 

Alan

 

 

 

On 8/24/21, Tim  wrote:

 

The more time I spend with nuttx the more I think I just haven't found some

 

treasure trove of documentation somewhere. All I seem to end up doing is

 

searching every single file for some kind of clue as to what to do!

 

 

 

 

 

 

 

I have an SPI EEPROM device. Menuconfig allows me to set it up, lovely! I

 

end up with

 

 

 

CONFIG_EEPROM=y

 

 

 

CONFIG_SPI_EE_25XX=y

 

 

 

 

 

 

 

(Also SPI mode and frequency).

 

 

 

 

 

 

 

Now what..

 

 

 

 

 

 

 

If I search for either of those CONFIG parameters, the first is not

 

referenced anywhere (apart from my .config), the second confirms that it

 

will include spi_xx25xx.c as a source. Getting there..

 

 

 

 

 

 

 

It'll be ee25xx_initialize(FAR struct spi_dev_s *dev, FAR char *devname,

 

int

 

devtype, int readonly) I need to call - makes sense.

 

 

 

 

 

 

 

Only there is no explanation, or examples of, how to make that call, and a

 

Google search doesn't help either.

 

 

 

 

 

 

 

Next step will be to look for examples of spi_dev_s and see if I can deduce

 

it somehow.

 

 

 

 

 

 

 

Just how am I supposed to know how to call that initialisation code? Which

 

is why I started this question with the observation that surely I must be

 

missing something somewhere!!??

 

 

 

 

 

 

 

Yes, it's a bit of a whinge, but also a request for help..please :)

 

 

 

 

 

 

 

 

 

Re: SPI EEPROM

[Tim Hardisty]

AT24 is I2C and this is well supported in NuttX. AT25 is SPI and is what I have 
(AT25128) and it is not well supported, with no example code or boards that 
support it (that I can find)

 

 

 

 

From: Gregory Nutt 
Reply to: 
Date: Tuesday, 24 August 2021 at 20:11
To: 
Subject: Re: SPI EEPROM

 

 

That’s AT24 I2C not AT25 SPI EEPROM unfortunatel,  and from a quick look it 
“just worked” ☹

 

There is support for the AT24 in other SAM boards.  Search for AT24 in 

defconfigs, I find

 

boards/arm/samv7/same70-xplained/

boards/arm/samv7/samv71-xult/

boards/arm/xmc4/xmc4500-relax

 

There is even simulated AT24 support:

 

boars/sim/sim/sim

 

You should be able to duplicate the logic from the samv7 boards.

 

 

Re: Re[2]: SPI EEPROM

[Tim Hardisty]

Thanks Vadim – that’s pretty much the conclusion I had come to.

 

Tim.

 

 

 


Subject: Re[2]: SPI EEPROM

 

 

Hi Tim,

 

You could search for any spi device being initialized. Search for spi_dev_s 
being declared in boards folder for some board, use it as an example and do the 
same initialization.

 

 

Re: SPI EEPROM

[Tim Hardisty]

Thanks Alan – all my SPI pins are configured. That was easy to work out :)

I will follow this tomorrow and I’m sure it will all seem easier in the morning!

 

From: Alan Carvalho de Assis 
Reply to: 
Date: Tuesday, 24 August 2021 at 20:59
To: 
Subject: Re: SPI EEPROM

 

Hi Tim,

 

It is very straightforward, basically you will replace:

 

FAR struct i2c_master_s *i2c;

 

i2c = stm32_i2cbus_initialize(AT24_I2C_BUS);

 

mtd = at24c_initialize(i2c);

 

 

WITH:

 

 

FAR struct spi_dev_s *spi;

 

spi = sam_spibus_initialize(AT25_SPI_PORTNO);

 

mtd = at25_initialize(spi);

 

 

But of course, if you don't know how to configure the SPI pins

(including the GPIO pin CS), nothing will work.

 

For Atmel/Microchip SAMxx family SPI, I think

boards/arm/samv7/samv71-xult/src/sam_st7789.c could be a good

reference.

 

BR,

 

Alan

 

On 8/24/21, Tim Hardisty  wrote:

AT24 is I2C and this is well supported in NuttX. AT25 is SPI and is what I

have (AT25128) and it is not well supported, with no example code or boards

that support it (that I can find)

 

 

 

 

 

 

 

 

 

From: Gregory Nutt 

Reply to: 

Date: Tuesday, 24 August 2021 at 20:11

To: 

Subject: Re: SPI EEPROM

 

 

 

 

 

That’s AT24 I2C not AT25 SPI EEPROM unfortunatel,  and from a quick look it

“just worked” ☹

 

 

 

There is support for the AT24 in other SAM boards.  Search for AT24 in

 

defconfigs, I find

 

 

 

boards/arm/samv7/same70-xplained/

 

boards/arm/samv7/samv71-xult/

 

boards/arm/xmc4/xmc4500-relax

 

 

 

There is even simulated AT24 support:

 

 

 

boars/sim/sim/sim

 

 

 

You should be able to duplicate the logic from the samv7 boards.

 

 

 

 

 

 

 

Re: SPI EEPROM

[Tim Hardisty]

That isn't quite right, Alan, as the mtd at25_initialize routine is for 
SPI FLASH not SPI EEPROM - it tries to read an ID.


I have replied to my other thread with the solution for AT25 SPI EEPROM, 
for others to refer to if they want


On 24/08/2021 20:59, Alan Carvalho de Assis wrote:

Hi Tim,

It is very straightforward, basically you will replace:

FAR struct i2c_master_s *i2c;

i2c = stm32_i2cbus_initialize(AT24_I2C_BUS);

mtd = at24c_initialize(i2c);


WITH:


FAR struct spi_dev_s *spi;

spi = sam_spibus_initialize(AT25_SPI_PORTNO);

mtd = at25_initialize(spi);


But of course, if you don't know how to configure the SPI pins
(including the GPIO pin CS), nothing will work.

For Atmel/Microchip SAMxx family SPI, I think
boards/arm/samv7/samv71-xult/src/sam_st7789.c could be a good
reference.

BR,

Alan

On 8/24/21, Tim Hardisty  wrote:

AT24 is I2C and this is well supported in NuttX. AT25 is SPI and is what I
have (AT25128) and it is not well supported, with no example code or
boards
that support it (that I can find)









From: Gregory Nutt 
Reply to: 
Date: Tuesday, 24 August 2021 at 20:11
To: 
Subject: Re: SPI EEPROM





That’s AT24 I2C not AT25 SPI EEPROM unfortunatel,  and from a quick look
it
“just worked” ☹



There is support for the AT24 in other SAM boards.  Search for AT24 in

defconfigs, I find



boards/arm/samv7/same70-xplained/

boards/arm/samv7/samv71-xult/

boards/arm/xmc4/xmc4500-relax



There is even simulated AT24 support:



boars/sim/sim/sim



You should be able to duplicate the logic from the samv7 boards.

Re: nxfss on MT25Q nor flash

[Tim Hardisty]

My board is now correctly registering the SPI instance and binding the 
relevant SPI and CS to the SPI Flash driver.



It was an uphill struggle, but thanks to all your various suggestions I 
have got there and learned more than I wanted to!


Next hurdle is to trawl through other boards to learn how to "automount" 
my SPI flash as a file system - maybe SMART or maybe MXFSS; right now, 
any file system mounting from my board or app init function would be good :)


On 24/08/2021 16:53, Alan Carvalho de Assis wrote:

Hi Tim,

It seams like MT25Q uses the m25px.c driver, so I assume you are
enabling the CONFIG_MT25Q_MEMORY_TYPE right?

Next you need to configure our board SPI CS pin, please take a look
at: arm/stm32/mikroe-stm32f4/src/stm32_spi.c

Then before try to setup the NXFFS you need to confirm that the Flash
NOR was detected correctly.

BR,

Alan

On 8/24/21, Tim  wrote:

Does anyone have any pointers on how to setup nxfss (or any filesystem for
that matter) on an MT25Q nor flash?



I cannot find any code for any other boards that makes any sense to me and
I
feel this should be a pretty basic thing to want to do? I believe I have
set
up all the SPI stuff and now need to (auto)mount it in my bringup or app
init code, but I'm stuck :(



"CONFIG_HAVE_M25P" is as far as I have got.



SAMA5D27 device.



TIA,



Tim.

Re: which filesystem?

[Tim Hardisty]

Hi Ken,

 

You fell for my 100% unintentional trap…thread title didn’t match content! I’d 
started one message, saved it as a draft, then changed my mind on what to ask 
but didn’t change the title. Doh!

 

I did try SmartFS and really like the sound of it, but it didn’t work “out of 
the box”. I think it is because it can’t cope with 256Mbit devices; I got a 
number of errors to do with sector sizes (from memory) and a quick debug 
suggestion that perhaps some variables are defined as 16 bit: not sure, and 
might return to it.

 

To answer your question – which was the original intent of this help request, 
the aim is fundamentally data logging. Users will log data (at 20Hz, say; 
multiple parameters) then occasionally pull them off for external analysis, 
delete, and start again. So I don’t think wear levelling is actually an issue; 
just speed and ease of pulling data off to spit out over USB or Bluetooth LE, 
on an occasional basis.

 

One file open for write is fine with what I currently envision, but who knows. 
SmartFS has much appeal as a “just in case”.  I have more DRAM than I know what 
to do with :)

 

Tim.

 

 

 

From: Ken Pettit 
Reply to: 
Date: Wednesday, 25 August 2021 at 18:12
To: 
Subject: Re: which filesystem?

 

Hey Tim,

 

Selection of filesystem is kind of a personal choice.  Each filesystem 

has different features / benefits.  I have never used NXFFS but I know 

it absolutely works with the caveat that you can only have one file open 

for writing at a time.  Because of this, I wrote SmartFS, which doesn't 

have this limitation, but also adds extra RAM usage for each open file.  

So as you see, there are tradeoffs.  There is also LittleFS and SPIFFS 

to choose from to make it even more complicated.

 

So I guess you first should ask, what features do I need from the FS?  

Directory support?  Wear leveling?  Multiple open files for write?  

Maybe a list of the features needed from the FS will help.

 

Ken

 

On 8/25/21 10:04 AM, Tim wrote:

I seem to have got over most of my SPI flash and EEPROM issues now and my

256Mb SPI flash is properly recognised.

 

 

 

I think I am at the last hurdle. Here is the console output, along with my

question of the day :)

 

 

 

Successfully initialized M25P SPI

 

m25p_initialize: dev: 0x2005b970

 

m25p_readid: priv: 0x2005b990

 

m25p_readid: manufacturer: 20 memory: ba capacity: 19

 

m25p_initialize: Return 0x2005b990

 

Successfully bound SPI0 CS1 to the SPI FLASH driver

 

m25p_ioctl: cmd: 1537

 

m25p_ioctl: blocksize: 256 erasesize: 4096 neraseblocks: 8192

 

m25p_ioctl: return 0

 

m25p_bread: startblock:  nblocks: 1

 

m25p_read: offset:  nbytes: 256

 

m25p_waitwritecomplete: Complete

 

m25p_read: return nbytes: 256

 

nxffs_nextentry: No entry found

 

nxffs_limits: No inodes found

 

nxffs_limits: Free FLASH region begins at offset: 5

 

nxffs_limits: First inode at offset 5

 

Succesfully initialised NXFSS

 

nx_mount: ERROR: Failed to find block driver (null)

 

Failed to mount the NXFSS volume -15

 

 

 

I believe the block driver would be "/dev/M25P" (M25P, for example) but

there is no code I have found that specifies the block driver location. I

have:

 

 

 

ret = nxfss_initialize(mtd);

 

 

 

then

 

 

 

ret = nx_mount("NULL, "/mnt/M25P", 0, NUL);

 

 

 

and that seems to be in common with other "bringup" code; using NULL rather

than "/dev/something".

 

 

 

Just need the last piece of this jigsaw if anyone could be so kind :)

 

 

 

Re: which filesystem?

[Tim Hardisty]

Thanks Greg – and apologies for the wrong thread subject.

 

I have seen references in the code to FTL but stupidly thought it was some 
other kind of FS. A non-Linux/Posix/Unix background means I am not totally 
across the mtd/block driver terminology etc. I did use Unix, but that was 
around 45 years ago!.

 

You have provided the “magic bullet” I need, and I am confident I will now get 
it working quickly in the morning.

 

Tim.

 

 

 

From: Gregory Nutt 
Reply to: 
Date: Wednesday, 25 August 2021 at 18:14
To: 
Subject: Re: which filesystem?

 

m25p_initialize() does not generate a block driver.  I creates an MTD 

driver.  To get a block driver, you have to wrap the MTD driver 

instances in an FTL (FLASH Translation Layer) instance.  These should be 

examples:

 

$ find . -name "*.c" | xargs grep -l ftl_initialize | xargs grep -l 

nxffs_initialize

./arm/cxd56xx/common/src/cxd56_flash.c

./arm/lpc43xx/bambino-200e/src/lpc43_appinit.c

./arm/lpc43xx/lpc4330-xplorer/src/lpc43_appinit.c

./arm/lpc43xx/lpc4357-evb/src/lpc43_appinit.c

./arm/sam34/sam4e-ek/src/sam_at25.c

./arm/sam34/sam4s-xplained-pro/src/sam_nandflash.c

./arm/sama5/sama5d2-xult/src/sam_at25.c

./arm/sama5/sama5d2-xult/src/sam_nandflash.c

./arm/sama5/sama5d3-xplained/src/sam_at25.c

./arm/sama5/sama5d3-xplained/src/sam_nandflash.c

./arm/sama5/sama5d3x-ek/src/sam_at24.c

./arm/sama5/sama5d3x-ek/src/sam_at25.c

./arm/sama5/sama5d3x-ek/src/sam_nandflash.c

./arm/sama5/sama5d4-ek/src/sam_at25.c

./arm/sama5/sama5d4-ek/src/sam_nandflash.c

./arm/samd5e5/metro-m4/src/sam_at24.c

./arm/samv7/samv71-xult/src/sam_bringup.c

./arm/stm32/cloudctrl/src/stm32_w25.c

./arm/stm32/fire-stm32v2/src/stm32_w25.c

./arm/stm32/shenzhou/src/stm32_w25.c

./arm/stm32/stm32f103-minimum/src/stm32_at24.c

./arm/stm32l4/stm32l476vg-disco/src/stm32_appinit.c

./arm/tiva/tm4c123g-launchpad/src/tm4c_at24.c

./mips/pic32mx/mirtoo/src/pic32_appinit.c

./xtensa/esp32/esp32-devkitc/src/esp32_spiflash.c

./xtensa/esp32/esp32-ethernet-kit/src/esp32_spiflash.c

./xtensa/esp32/esp32-wrover-kit/src/esp32_spiflash.c

 

The block driver should be called /dev/mtdblockN where N is the minor 

device number passed as the first argument to ftl_initialize().

 

On 8/25/2021 11:04 AM, Tim wrote:

I seem to have got over most of my SPI flash and EEPROM issues now and my

256Mb SPI flash is properly recognised.

 

 

 

I think I am at the last hurdle. Here is the console output, along with my

question of the day :)

 

 

 

Successfully initialized M25P SPI

 

m25p_initialize: dev: 0x2005b970

 

m25p_readid: priv: 0x2005b990

 

m25p_readid: manufacturer: 20 memory: ba capacity: 19

 

m25p_initialize: Return 0x2005b990

 

Successfully bound SPI0 CS1 to the SPI FLASH driver

 

m25p_ioctl: cmd: 1537

 

m25p_ioctl: blocksize: 256 erasesize: 4096 neraseblocks: 8192

 

m25p_ioctl: return 0

 

m25p_bread: startblock:  nblocks: 1

 

m25p_read: offset:  nbytes: 256

 

m25p_waitwritecomplete: Complete

 

m25p_read: return nbytes: 256

 

nxffs_nextentry: No entry found

 

nxffs_limits: No inodes found

 

nxffs_limits: Free FLASH region begins at offset: 5

 

nxffs_limits: First inode at offset 5

 

Succesfully initialised NXFSS

 

nx_mount: ERROR: Failed to find block driver (null)

 

Failed to mount the NXFSS volume -15

 

 

 

I believe the block driver would be "/dev/M25P" (M25P, for example) but

there is no code I have found that specifies the block driver location. I

have:

 

 

 

ret = nxfss_initialize(mtd);

 

 

 

then

 

 

 

ret = nx_mount("NULL, "/mnt/M25P", 0, NUL);

 

 

 

and that seems to be in common with other "bringup" code; using NULL rather

than "/dev/something".

 

 

 

Just need the last piece of this jigsaw if anyone could be so kind :)

 

 

 

Re: which filesystem?

[Tim Hardisty]

I am only just getting the point of having the luxury to think about what FS to 
use lol. My 1st thought was indeed FAT and USB MSD for sure…but I made the 
randome decision to put a USB-C connector and FUSB controller on the board and 
haven’t got that working yet.

 

The beauty of NuttX is it gives me all these choices and, despite my “rants” of 
yesterday I still know it was the right choice for this board/product :)

 

From: Gregory Nutt 

 

To answer your question – which was the original intent of this help request, 
the aim is fundamentally data logging. Users will log data (at 20Hz, say; 
multiple parameters) then occasionally pull them off for external analysis, 
delete, and start again. So I don’t think wear levelling is actually an issue; 
just speed and ease of pulling data off to spit out over USB or Bluetooth LE, 
on an occasional basis.

 

Hmmm.. If you don't care about about wear-leveling but you want to get 

data from USB (via USB MSC?), then you should consider FAT.  You can 

export and mount the SPI FLASH-based FAT file system on any host just as 

though it were a any other USB FLASH driver.

 

FLASH file systems only exist to handle wear-leveling and bad block 

handling.  (I think I do have some ancient FAT bad block logic somewhere 

that I never got merged upstream).

 

 

 

Re: which filesystem?

[Tim Hardisty]

Thanks Sara – I’m having a problem with your emails…via my work server they are 
rejected, and my personal email marks them as spam, but delivers them and 
messes up the formatting.

 

I can see you have some good suggestions so I will try and unravel it all and 
reply tomorrow.

 

From: Sara da Cunha Monteiro de Souza 
Reply to: "dev@nuttx.apache.org" 
Date: Wednesday, 25 August 2021 at 19:15
To: "dev@nuttx.apache.org" 
Subject: Re: which filesystem?

 

Em qua., 25 de ago. de 2021 às 15:12, Sara da Cunha Monteiro de Souza < 
saramonteirosouz...@gmail.com> escreveu: > Hy Tim, > > 1. PTAL at: > 
https://www.mail-archive.com/dev@nuttx.apache.org/msg06767.html and see > if 
the issues you found with SMARTFS > can be solved with the proper 
configurations and commands. > Just jump to the last message. 

Naffs - format?

[Tim Hardisty]

Today's dumb question!

Having got a mounted nxffs spi flash "drive", I had a quick try earlier today 
to store some data.

If I did:

nsh> ls > /mnt/flash/file1.txt

there was a major crash.

If I enabled the startup scan it sat there for 20+ minutes before I gave up and 
halted it (it was still doing stuff via SPI to the memory, and info debug 
enabled showed lots going on)...but then the same nsh command worked and the 
file was created.

This suggests to me the file system may need to be formatted or "created" maybe 
but...guess what...I can't find anything in any guides to suggest this is 
needed. SmartFS seems to need it - "nsh> mksmartfs /dev/smart0" for example - 
but not had time to play more with that yet).

Or is it because the flash device is full of duff stuff from all my messing 
around and just needs to be erased and I start again (not thought of that until 
now).

Be gentle... :)

Re: Naffs - format?

[Tim Hardisty]

(no insult intended…naffs was a typo!)

 

From: Tim Hardisty 

 

Today's dumb question!

 

Having got a mounted nxffs spi flash "drive", I had a quick try earlier today 
to store some data.

 

If I did:

 

nsh> ls > /mnt/flash/file1.txt

 

there was a major crash.

 

If I enabled the startup scan it sat there for 20+ minutes before I gave up and 
halted it (it was still doing stuff via SPI to the memory, and info debug 
enabled showed lots going on)...but then the same nsh command worked and the 
file was created.

 

This suggests to me the file system may need to be formatted or "created" maybe 
but...guess what...I can't find anything in any guides to suggest this is 
needed. SmartFS seems to need it - "nsh> mksmartfs /dev/smart0" for example - 
but not had time to play more with that yet).

 

Or is it because the flash device is full of duff stuff from all my messing 
around and just needs to be erased and I start again (not thought of that until 
now).

 

Be gentle... :)

 

 

 

Re: NuttX Monthly Meetup

[Tim Hardisty]

What sort of agenda, or purpose, Alan?

Sounds like a good idea but some suggestion of what to expect would be good :)

 

On 22/09/2021, 18:20, "Alan Carvalho de Assis"  wrote:

Dear NuttXers,

We want to do monthly meets with our developers and users.

The first online meet will be this Friday (2021/09/24) at 18:00 GMT.

Everybody can join using this link:

https://meet.jit.si/NuttXMeetup

BR,

Alan

Re: Poll: Which OS are you using to compile NuttX?

[Tim Hardisty]

Needs a LinkedIn login?



From: Alan Carvalho de Assis 
Reply to: "dev@nuttx.apache.org" 
Date: Friday, 24 September 2021 at 20:20
To: dev 
Subject: Poll: Which OS are you using to compile NuttX?

Hi Everyone, Please help us to discover which OS people are using most to 
compile NuttX: 
https://www.linkedin.com/feed/update/urn:li:activity:6847246067046596609/ It 
will help us to decide how better support your host OS. BR, Alan

Re: Poll: Which OS are you using to compile NuttX?

[Tim Hardisty]

Linux

 

On 24/09/2021, 21:07, "Alan Carvalho de Assis"  wrote:

Sorry guys, I suppose you are using LinkedIn too.

Yes, probably it will collect some data from you, but you are using a
better MS gather:

"Sent from Mail for Windows"

So, if you are already in the hell, please give a warm hug in the Lucifer 
:-D

Now, let be serious here: for those who don't have LinkedIn access,
please reply this email with one of these options:

1) Linux
2) MacOS
3) Windows using Cygwin
4) Windows Native

Thank you for the understanding.

BR,

Alan

On 9/24/21, Russell Haley  wrote:
> The link gives me “This post cannot be displayed”. I am logged into the
> Microsoft data collection site known as LinkedIn.
>
> Sent from Mail for Windows
>
> From: Tim Hardisty
> Sent: Friday, September 24, 2021 12:54 PM
> To: dev@nuttx.apache.org
> Subject: Re: Poll: Which OS are you using to compile NuttX?
>
> Needs a LinkedIn login?
>
>
>
> From: Alan Carvalho de Assis 
> Reply to: "dev@nuttx.apache.org" 
> Date: Friday, 24 September 2021 at 20:20
> To: dev 
> Subject: Poll: Which OS are you using to compile NuttX?
>
> Hi Everyone, Please help us to discover which OS people are using most to
> compile NuttX:
> https://www.linkedin.com/feed/update/urn:li:activity:6847246067046596609/ 
It
> will help us to decide how better support your host OS. BR, Alan
>
>

Re: USB MSD problem

[Tim Hardisty]

On 22/12/2021, 20:15, "Alan Carvalho de Assis"  wrote:

>On 12/22/21, TimH  wrote:
>> On 22/12/2021 15:55, Alan Carvalho de Assis wrote
>> If I want to share what I'm doing with the details of the project etc,
>> where might you suggest I do this?
>If you want share your progress and findings, it is better to create a 
blog.

Is there a specific NuttX blog site you were thinking of? Otherwise I'll do my 
own somewhere/somehow!

Re: USB MSD problem

[Tim Hardisty]

Yes, I now think so. I know I looked at stack settings but (without benefit of 
access to my Linux work machine from home) if I recall they are spread around 
the place and I suspect - from other advise here - that it is the app stack 
size that is inadequate.

Hopefully a break from it all will make it all seem simpler next week!

On 26/12/2021, 21:38, "Jukka Laitinen"  wrote:

Could it simply be a stack overflow?

Alan Carvalho de Assis kirjoitti keskiviikko 22. joulukuuta 2021:
> Exactly, something is changing the memory layout and forcing the error
> to happen.

Re: MT25P vs MT25Q bulk erase difference - how to fix?

[Tim Hardisty]

Thanks - makes sense. I am still not 100% convinced the M25P code is 
actually correct for the M25Q. It's a work-in-progress.



This is what I have added, and all other things being equal, I will use 
it in the driver where there are subtle differences needed.



structm25p_dev_s
{
structmtd_dev_smtd; /* MTD interface */
FARstructspi_dev_s*dev; /* Saved SPI interface instance */
uint8_tsectorshift; /* 16 or 18 */
uint8_tpageshift; /* 8 */
uint16_tnsectors; /* 128 or 64 */
uint32_tnpages; /* 32,768 or 65,536 */
***uint16_tmanufacturer**; **/* detected manufacturer */*
***uint16_tmemory**; **/* detected memory type */*
#ifdefCONFIG_M25P_SUBSECTOR_ERASE
uint8_tsubsectorshift; /* 0, 12 or 13 (4K or 8K) */
#endif
};

and

SPI_SEND(priv->dev, M25P_RDID);
manufacturer= SPI_SEND(priv->dev, M25P_DUMMY);
memory= SPI_SEND(priv->dev, M25P_DUMMY);
capacity= SPI_SEND(priv->dev, M25P_DUMMY);
/* Deselect the FLASH and unlock the bus */
SPI_SELECT(priv->dev, SPIDEV_FLASH(0), false);
m25p_unlock(priv->dev);
/* save the manufacturer and memory type */
***priv**->**manufacturer**= **manufacturer**;*
***priv**->**memory**= **memory**;*
and in the erase function
/* Send the "Bulk Erase (BE)" instruction or "Die Erase" as appropriate*/
if(priv->manufacturer== M25P_MANUFACTURER&&
(priv->memory== MT25Q_MEMORY_TYPE|| priv->memory== MT25QU_MEMORY_TYPE))
{
SPI_SEND(priv->dev, M25Q_DE);
}
else
{
SPI_SEND(priv->dev, M25P_BE);
}
On 18/01/2022 16:36, Sebastien Lorquet wrote:

Hello,

If the Die Erase is similar in function to the bulk erase, then it can
be used instead, but this has to be done at runtime to support all the
chips in the same driver. So no @define or CONFIG_ option, because
choosing one would excude the others, and if you have both on a board
this would be bad.

The runtime fix is not heavy. My recommended way is:

-add a uint8_t device_manufacturer field in the m25px structure,
initialized when the JEDEC ID is obtained from the device (IIRC,
m25px_initialize or something like that)

-then, use this field in the m25px_erase method to choose the correct
command(, and parameters if needed).


I woud appreciate if you agreed to share your changes beforehand (eg
pull request) so I can review this simple change, because i'm using this
driver in a professional project and I would like to make sure there are
no regressions.

Thank you,

Sebastien

Le 18/01/2022 à 16:41, Tim a écrit :
As I still get deeper and deeper into why FAT doesn't work on my 
MT25Q NOR

flash device, I have found a minor error in m25px.c

The M25P devices have a bulk erase command (0xC7) but this is not 
supported

by the MT25Q, which has a "die erase" command (0xC4) instead and 0xC7 is
meaningless.

There is a #define for this as expected:

#define M25P_BE    0xc7

Adding

#define M25Q_DE    0xc4

Make sense but...

When the device manufacturer ID is read this is actually saved, so it 
can't

be tested at runtime to choose the right command.

The straightforward fix is to move the #define for M25_BE to within 
the code

that tests the manufacturer ID (to ensure it's a valid device for these
functions) but that is a bit messy and moves the #define away from 
all the

other related #defines. Doesn't feel right.

There is no unique CONFIG_ attribute that says whether it is or isn't
expecting to find an M25P or M25Q (which is reasonable) so I can't use
conditional #defines.

And don't want to mess up other people's boards by changing Kconfig 
in any
way that isn't backwards compatible, although the inviolable 
"Sometimes Code
Duplication is OK" might suggest it would be better to copy out 
m25px.c as
m25lx.c and make the change so that Kconfig demands you choose one or 
the
other or both of the two types...and if I find more 
errors/differences that

may ultimately make sense of course.

Can anyone suggest the "NuttX way" to do this, assuming I don't find a
myriad of other errors/differences that "force" duplication?

Re: RNDIS

[Tim Hardisty]

Thanks Alanm - my lack on Linux knowledge failed me again. Never used 
dmesg...luckily I like learning lol.



From Linux machine:

[ 3399.181365] usb 1-2: new high-speed USB device number 21 using xhci_hcd
[ 3399.337980] usb 1-2: New USB device found, idVendor=584e, 
idProduct=5342, bcdDevice= 0.01
[ 3399.337985] usb 1-2: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3

[ 3399.337987] usb 1-2: Product: RNDIS NuttX
[ 3399.337988] usb 1-2: Manufacturer: NuttX
[ 3399.337990] usb 1-2: SerialNumber: 1234
[ 3399.339311] rndis_host 1-2:1.0: skipping garbage
[ 3399.339551] rndis_host 1-2:1.0: dev can't take 1558 byte packets (max 
1364), adjusting MTU to 1306

[ 3399.339857] rndis_host 1-2:1.0: RNDIS_MSG_QUERY(0x01010101) failed, -32
[ 3399.339859] rndis_host 1-2:1.0: rndis get ethaddr, -32
[ 3399.339930] rndis_host: probe of 1-2:1.0 failed with error -32
[ 3399.339996] rndis_wlan 1-2:1.0: skipping garbage
[ 3399.340140] rndis_wlan 1-2:1.0: dev can't take 1558 byte packets (max 
1364), adjusting MTU to 1306



No debug warnings in nuttx for USB or network.

So now hunting through the menuconfig to find relevant settings!


On 20/01/2022 23:45, Alan Carvalho de Assis wrote:

Please verify if dmesg can give use some hint about the issue.

On 1/20/22, TimH  wrote:

Nope, doesn't show. So RNDIS is not working right on my board. What a
surprise!

On 20/01/2022 19:30, Alan Carvalho de Assis wrote:

Exactly, knowing Unix/Linux makes your live easier with NuttX.

Using "ip list" (or ifconfig) on Linux should display the new USB
RNDIS interface.

BR,

Alan

Re: SPI problem

[Tim Hardisty]

>From my own struggles to get a board (custom board as it happens, but like 
>others that were there) I found:

 
Board support was often incomplete. Look at other boards to see where and how 
SPI is initialised and registered. You may find something basic is missing.
Stack size. Random errors occur if there’s insufficient stack
 

Just because a board is there, neither assume the support is complete nor 
correct!

 

For example, for my SAMA5D27-based boards I found:

 
Errors in PIO mapping (from memory, PIO C and D had incorrect addresses. PIOD 
was missing from Kconfig)
CAN support had compile errors.
It shouldn’t actually have used CAN as that A5D2 processor uses “mcan” needing 
a different set of drivers to the A5D3 or D4 processors in that family
Other peripherals had no support at all – Flexcom and ClassD Audio, for example.
 

I suppose that if a particular eval board has a set of specific peripherals 
actually used, then support has probably been tried – but if the eval board for 
yours doesn’t have anything connected to SPI then whoever ported the board 
would have nothing there to test it with.

 

Bottom line – ASSUME NOTHING!!

 

 

 

From: Roberto Bucher 
Reply to: 
Date: Sunday, 6 March 2022 at 08:54
To: 
Subject: SPI problem

 

When I enable some dubug configs



I get the following error by enter in the serial shell:

sert: Assertion failed at file:spi/spi_driver.c line: 358
arm_registerdump: R0: 0001 R1: 2004e840 R2: 40004800  R3: 20010684
arm_registerdump: R4: 2004e7a0 R5: 0002 R6: 2004f370  FP: 20010670
arm_registerdump: R8:  SB:  SL:  R11: 
arm_registerdump: IP: 0003 SP: 2004f370 LR: 08005fad  PC: 0800648e
arm_registerdump: xPSR: 6100 PRIMASK:  CONTROL: 0004
arm_registerdump: EXC_RETURN: ffe9
arm_dump_stack: User Stack:

On the line 358 of spi_driver.c there is this assertion:

  /* Sanity check */

  DEBUGASSERT(spi != NULL && (unsigned)bus < 1000);

Any Idea?

Best regards

Roberto

Re: 10.3 merge issues

[Tim Hardisty]

I realise, now, I compared mine against 10.2 variants not 10.3...not sure why, 
but there you go. I'll give that a try tomorrow - thanks!

On 17/08/2022, 20:19, "Nathan Hartman"  wrote:

On Wed, Aug 17, 2022 at 3:15 PM Nathan Hartman  
wrote:
>
> On Wed, Aug 17, 2022 at 2:38 PM TimH  wrote:
> > >> no rule to make target  '-T/home/{rest of the path}'
>
> See commit: 
https://github.com/apache/incubator-nuttx/commit/8defb843aa2e1d49b08b1cb7155aea97e1721b6c
>
> There have been some refactorings in the build system to reduce code
> duplication.
>
> So instead of writing all this:
>
> ifeq ($(CONFIG_CYGWIN_WINTOOL),y)
> ARCHSCRIPT = -T "${shell cygpath -w
> $(BOARD_DIR)$(DELIM)scripts$(DELIM)$(LDSCRIPT)}"
> else
> ARCHSCRIPT = -T$(BOARD_DIR)$(DELIM)scripts$(DELIM)$(LDSCRIPT)
> endif
>
> Now you only have to write:
> ARCHSCRIPT += $(BOARD_DIR)$(DELIM)scripts$(DELIM)$(LDSCRIPT)
>
> I recommend to compare your Make.defs with that of the board you
> cloned and bring over all changes.


This is the PR: https://github.com/apache/incubator-nuttx/pull/5496

Cheers,
Nathan

Re: Driver for combined battery charger and regulator

[Tim Hardisty]

>>> Please correct me if I'm still missing something, as there are zero
>>> clues I can find as to what each ops function (for example) is
>>> actually supposed to do.
>>
>>
>>
>>Here is two examples:
>>https://github.com/apache/incubator-
>>nuttx/blob/master/drivers/power/supply/regulator_gpio.c
>>https://github.com/apache/incubator-
>>nuttx/blob/master/drivers/power/supply/regulator_rpmsg.c

>thank you for these, I will take a look and hopefully they will point me 
>in the right direction.

Please: what are the purpose of:

set_voltage_sel
get_voltage_sel

Re: Driver for combined battery charger and regulator

[Tim Hardisty]

   >> Please: what are the purpose of:
>>
>> set_voltage_sel
>> get_voltage_sel
>>

>FYI: https://www.kernel.org/doc/html/v4.12/driver-api/regulator.html


Alan to the rescue again :-)

Perhaps Nuttx needs a warning to newcomers: "enter without Linux knowledge at 
your peril" LOL

Re: Driver for combined battery charger and regulator

[Tim Hardisty]

On Wed, Sep 7, 2022 at 1:03 PM Tim Hardisty  wrote:
>>
>>
>> >>> Please correct me if I'm still missing something, as there are 
zero
>> >>> clues I can find as to what each ops function (for example) is
>> >>> actually supposed to do.
>> >>
>> >>
>> >>
>> >>Here is two examples:
>> >>https://github.com/apache/incubator-
>> >>nuttx/blob/master/drivers/power/supply/regulator_gpio.c
>> >>https://github.com/apache/incubator-
>> >>nuttx/blob/master/drivers/power/supply/regulator_rpmsg.c
>>
>> >thank you for these, I will take a look and hopefully they will 
point me
>> >in the right direction.
>>
> Please: what are the purpose of:
>>
>> set_voltage_sel
>> get_voltage_sel


>This really should be documented in the definition of struct
>regulator_ops_s in include/nuttx/power/regulator.h, particularly what
>is the difference between set_voltage and set_voltage_sel.

I agree - this should be there as comments. I will eventually submit a PR for 
my driver and, if it's not done by then, I will add these in the same PR 

>That said, based on reading the code at _regulator_do_set_voltage() in
>drivers/power/supply/regulator.c, it appears that:

>1) set_voltage() is given a minimum and maximum desired voltage in
>microvolts and sets (if possible) the regulator's voltage selector to
>generate something between those bounds. It is up to the lower-half
>driver to look at the desired min and max voltage and figure out what
>the selector should be, whereas:

>2) set_voltage_sel() is given the selector value itself and sets that.
>The lower-half driver doesn't make decisions in this case; the
>upper-half driver iterates through all available voltages to decide
>which one is the "best" and then calls the lower-half driver with that
>selector value.

>The logic in _regulator_do_set_voltage() is such that if the
>lower-half driver provides set_voltage(), it prefers to call that; if
>not, then I assume it's a more "primitive" driver and therefore the
>upper-half decides the selector value.

This is a great help, Nathan: thank you. The ACT8945A only allows discrete 
voltages to be set (64 values) so the set_voltage_sel may one way to sort this, 
although I already have code to select the right register value by some 
mathematical shenigans so could put that in the lower half and make use of the 
min and max values.

It is all making sense now: lack of comments, and no examples in 10.3, are what 
done me in.

Re: Driver for combined battery charger and regulator

[Tim Hardisty]

On 08/09/2022, 18:07, "Xiang Xiao"  wrote:

On Fri, Sep 9, 2022 at 12:19 AM TimH  wrote:


>>   unsigned int apply_uv;/* ?? SEE BELOW [1] */
>Yes, bool is more suitable than int for apply_uv.
Thanks for confirming/agreeing - once 11.0 is released and I rebase my own work 
I'll do a PR to change this (and add comments to the driver files).

>>[2] It is not clear, either in Linux or Nuttx, what the "constraint
>>voltage" that is applied during init will be. Perhaps the NuttX intent is 
-
>>or should be - to use an actual value here (hence the int?) which will be
>>applied during init IF "boot_on" is set on (suggesting it is a parameter
>>that should be passed TO the regulator register/init function not filled 
in
>>BY it?
>
>
> boot_on in NuttX is simple, the common code will enable the regulator if
> boot_on is true otherwise disable it in regulaotr_register.

OK, makes sense, thanks.

> If this is all (nearly) correct, then I think the call to register a
> regulator 

Yes, I think so.


> If I'm nearly right I might add that I believe there are useful members of
> the regulator_desc_s structure missing, such as "active_discharge" that's
> useful for the ACT8945A. 

   
   > The fields in regulator_desc_s are designed for the common regulator
   > framework code, so it's better to put a new field to this struct if the
   > common does the different action based on it. If the new info is only used
   > by a specific driver, regulator_dev_s::priv is a better place.

The two I suggested are in the Linux spec and are common things for processor 
PMICs. These would be good candidates to add to the common code I think.

>> Final observation - Linux documentation quite clearly states microvolts
>> for all voltage parameters. 

>
>
> The initial design follows Linux convention, that's why the field ends 
with
> _uv not _mv.. uint32_t can hold 4293.967295V with uV which is enough in
> most case.
OK I will use uv. Think it might mean the AXP202 driver needs fixing...it is 
using battery charger framework for regulator functions so someone probably 
needs to revisit it at some point.

Re: [apache/incubator-nuttx] tools/configure.sh: Update USAGE for custom out-of-tree boards (PR #7103)

[Tim Hardisty]

I have walked through the custom apps guide from the cwiki and find that it is 
explaining how to replace the ENTIRE Nuttx Apps directory with a custom 
alternative.

That seems to me to be perhaps of minority interest but I'll include it in the 
documentation I'm writing anyway for completeness.

But is there a way to add a custom folder - in or out of tree - that will be 
included along with the built-in apps and examples? This would allow you to 
include custom appss, and the built-in ones, but not have a problem when 
merging future releases that might cause the building in of the custom apps to 
fail?

Perhaps I'm over thinking it?

On 07/10/2022, 17:25, "TimH"  wrote:

Got it - thanks Nathan. I will probably plunder some text from the cwiki 
then, and not feel guilty :-)

>-Original Message-
>From: Nathan Hartman 
>Sent: 07 October 2022 17:23
>To: dev@nuttx.apache.org
>Subject: Re: [apache/incubator-nuttx] tools/configure.sh: Update USAGE for
>custom out-of-tree boards (PR #7103)
>
>On Fri, Oct 7, 2022 at 11:59 AM TimH  wrote:
>>
>> As per request below, I’m happy to add a paragraph or two regarding this,
>but I am not sure where it should go?
>>
>> It could be a section in “guides” or I could add it to the FAQ. What is
>preferred, assuming the Documentation folder in the repo is actually the 
right
>place for this of course?
>
>I think it would best fit in guides under the Documentation folder in the 
repo,
>and I think that's where all "official" documentation should ultimately be.
>
>> Related to this, what is the significance of the cwiki
>(https://cwiki.apache.org/confluence/display/NUTTX) as that has a lot more
>information in it compared to the Nuttx distro’s Documentation folder, but 
is
>outdated and perhaps not maintained I think? The cwiki has information on
>custom app directory usage that could either be a source of info for a more
>complete “custom environment” guide or is the actually the intended place
>for the custom boards info I’ve been asked to add?
>
>From my memory, before NuttX joined the Apache.org Incubator, what's now
>in the CWIKI was in a MediaWiki on the NuttX website. When we joined the
>Incubator, this was somehow migrated to the Apache.org CWIKI. Some (or
>most?) of it was then migrated again into what is now the Documentation
>folder in the repo. However, there are some differences between the two
>because new documentation has been written under Documentation while
>some of the docs available in the CWIKI may not have been migrated, and I
>think there are still articles in the CWIKI that have not made it into
>Documentation.
>
>As to what's the purpose of the CWIKI: Some time ago, I asked whether we
>should keep the CWIKI around. Now I can't seem to locate that email after a
>quick search, but as I remember, a few people said they would like to keep
>the CWIKI as a place to collaborate on documentation, as it makes real-time
>collaborative writing easier (without the added friction of making PRs) and
>then migrate finished documents into Documentation.
>
>In short, there's some work yet to be done on documentation and it isn't a
>secret that we, like probably most community-driven projects, need lots of
>help improving our documentation!!!
>
>Hope that helps. I'd like to say a sincere THANK YOU for any improvements
>you're willing to make, large or small!
>
>Cheers,
>Nathan

Re: [apache/incubator-nuttx] tools/configure.sh: Update USAGE for custom out-of-tree boards (PR #7103)

[Tim Hardisty]

If external is historic, what is the preferred way to include a custom 
out-of-tree (i.e. non-public) App in a build, in a way that won't get trashed 
if a distclean or Nuttx upgrade merge is done?

On 11/10/2022, 20:08, "Gregory Nutt"  wrote:


> Did you check the "external" directory or are you looking for something
> else?
>
> Basically the external directory allows you to symlink an out of tree
> repository (or repositories) that should contain, at least, the minimal
> build glues (Makefile and Make.defs).  The build system should pick up the
> rest.
> The external directory is ignored from the tracking system so nothing
> impacts the actual apps repo.

The "external" directory is typically a symbolic link.  It is mostly of 
historical interest because you can place any symbolic link to an 
external directory (or directories)  containing a Kconfig and Makefile 
in the apps/ directory and it (or they) will be built.  The only thing 
special about the "external" directory is that it is properly ignored in 
apps/.gitignore

Re: Anna-b112 Bluetooth module support

[Tim Hardisty]

With apologies for joining in - at only a slight tangent I hope - but is the 
advantage to a NuttX app that uses the NuttX Bluetooth stack with the radio 
device in H4 API mode, compared to using the Bluetooth SoC device as a 
coprocessor using its own stack, that it becomes a simple device that can be 
read/written to rather than needing a custom SPI or USART interface protocol to 
be written?

I have a similar situation to Ivan in that I have a board with a SiLabs 
Bluetooth LE SoC and I have assumed I'd use it's stack and SiLabs tools to 
create my Bluetooth LE App, and have it communicate with my "main" app via an 
SPI interface in some custom (not yet designed) way - but perhaps I'm missing 
out on something easier by doing it that way?

> On 14 Oct 2022, at 13:53, Alan C. Assis  wrote:
> 
> Hi Ivan,
> 
> Ok, understood the issue!
> 
> Maybe U-Block has an HCI H4 firmware that you can use on Anna-B112
> instead of this AT firmware. It's always a good idea to use and follow
> the standard, this is a compelling motivation to use NuttX in the
> first place! :-)
> 
> BR,
> 
> Alan
> 
>> On 10/14/22, Embedded Systems  wrote:
>> Hello Alan,
>> 
>> Unfortunately we cannot use the module as HCI H4, we can control it only
>> with AT commands. So in our case IMXRT is running nuttx and its connected
>> to the BLE module with uart and control it with AT commands, so far i just
>> implemented an application in nuttx which controls the module from the user
>> space. The aplication is using a UART char driver to communicate with the
>> module and everything else is managed in the application , but i dont think
>> this is a good way to use the module and i wish to make a driver in nuttx
>> for it, My problem is that i dont see a good way to implement the driver
>> and connect it with the already existing nuttx Bluetooth functionalities .
>> 
>> 
>> Best regards,
>> Ivan
>> 
>>> On Thu, Oct 13, 2022 at 11:59 PM Alan C. Assis  wrote:
>>> 
>>> Hi Ivan,
>>> 
>>> Normally using external BLE modules that follows the HCI H4 is easier
>>> than porting to some chip with internal BLE and application in the
>>> same chip.
>>> 
>>> You can see how it is done in the sim and also here:
>>> 
>>> boards/arm/stm32/stm32f4discovery/src/stm32_hciuart.c
>>> 
>>> BR,
>>> 
>>> Alan
>>> 
>>> On 10/13/22, Embedded Systems  wrote:
 Hello Alan,
 
 Its good to hear from you too.
 
 So, you don't to flash NuttX inside Anna-B112, but just want to use it
 as external BT BLE module, right?
 
 The Anna module is flashed with u-blox connect and we are using it as
 external ble module, the module has the whole ble stack embedded in the
 u-box connect and is controlled via AT commands, thats why i am not
 sure
 how exactly to port it for Nuttx in a suitable way.
 
 Best regars,
 Ivan ucherdzhiev
 
 
 На чт, 13.10.2022 г., 18:31 Alan C. Assis  написа:
 
> Hi Ivan,
> 
> Nice to hear news from you!
> 
> So, you don't to flash NuttX inside Anna-B112, but just want to use it
> as external BT BLE module, right?
> 
> In this case you need to enable the "Bluetooth H4 UART"
> 
> There are some examples on NuttX about how to use it.
> 
> Also you can opt for using NuttX internal BLE Stack (that derives from
> an old BLE Stack that Intel integrated on Zephyr and that was released
> for Arduino/Genuino under BSD License) or you can use the NimBLE stack
> that is more complete and also have examples on NuttX.
> 
> Using the internal stack could be more challenging, but it will help
> to improve our own stack.
> 
> BR,
> 
> Alan
> 
> On 10/13/22, Embedded Systems  wrote:
>> Hello Nuttx Community,
>> 
>> First i would like to say that i really hope that everybody is doing
> well!
>> I am sorry that long time i didn't had a chance to contribute
>>> anything,
> but
>> life is moving in a very fast pace for me lately.
>> 
>> For our sport Wearable system i am working on integration of a
>> Bluetooth
>> module Anna-B112, it is a very interesting small module. The version
> which
>> we are using is preflashed with Ublox u-connect software and the
>>> module
> is
>> based on nRF52832 nordic chip. I would like to ask for advice on how
>> exactly to implement a relevant support for this to suit Nuttx
> architecture
>> because i wish to contribute this port when its done. I am familiar
>> that
>> Nuttx has Bluetooth stack and also support for HCI bluetooth
>> modules,
>> but
>> the difference here is that ANNA-B112 has its stack embedder in the
> nordic
>> chip and the module is controlled via AT commands through UART, so i
>>> am
> not
>> exactly sure how to implement the driver for this module. To me it
>> looks
>> like it has to bypass the nuttx bluetooth stack (because it already
>>> has

RE: ADC device close and IRQ

[Tim Hardisty]

Now I am very much more familiar with the SAMA5Dx ADC and Touch Screen 
Controller (TSC) driver code, the more I think it is making life really 
difficult having the TSD code separate to the ADC code - they are just too 
closely related especially given all the combinations of ADC channels and/or 
TSC control requirements, and common interrupts etc.

I am minded to subsume the relevant sam_tsc code into the sam_adc code and 
rationalise it that way.

Does that seem a reasonable approach or is there a very good reason to keep 
them separate?

>-Original Message-
>From: Nathan Hartman 
>Sent: 16 September 2022 12:31
>To: dev@nuttx.apache.org
>Subject: Re: ADC device close and IRQ
>
>On Fri, Sep 16, 2022 at 7:20 AM TimH  wrote:
>
>> Actually a little more complicated as the detach and disable in adc
>> close then kills the touch screen driver as well (it uses the ADC).
>> l'll figure out a way, I'm sure!
>
>
>
>I haven't looked at the code, but it sounds like any driver being closed 
>shuts
>down the ADC for all drivers.
>
>Instead, the driver should keep a reference count. The underlying hardware
>should be initialized when the first instance of the driver is opened and 
>un-
>initialized only when the last instance of the driver is closed.
>
>Cheers
>Nathan

Bluetooth+WiFi+NuttX

[Tim Hardisty]

Bit of a tangential question this, but I know there are folk on here who are 
much more conversant with the way NuttX can be used with WiFi and Bluetooth 
modules than I am.

I may have an opportunity forced on me to have to respin my custom board which 
currently has a SiLabs Bluetooth SoC as well as the main SAMA5D2 processor. I 
used that module as I already have experience of it - but that predates my 
NuttX journey.

I see there are some very good value combined WiFi + Bluetooth modules now 
(Espressif for example...and I know there's a well-known proponent of those 
devices here lol) and, having seen a few other questions here, I am thinking 
that I can go the HCI route and make use of the Bluetooth Stack in NuttX: and 
add WiFi capability to my board at the same time. Winner!

I'm hoping I can program up a suitable module with generic radio co-processor 
software (HCI I think, and whatever is needed for WiFi) and access it via UART 
from my main processor and have it all under the NuttX system in a much more 
easily managed manner than a separate app on the SiLabs SoC that just happens 
to communicate on some way with my main app on the SAMA5D2.

Have I got this right? Is an Espressif module a good choice (email me direct if 
you want to !!)?

Thanks,

Tim.
--
t...@jti.uk.com

Re: Bluetooth+WiFi+NuttX

[Tim Hardisty]

Due to processor power limitations? For this application a WiFi interface would 
be rarely used apart from a means to configure the product. Bluetooth will be 
GATT based to allow monitoring of sensor data on a phone app (sometime in the 
fure, due to the Bluetooth SIG fees involved!!).

So if the WiFi performance is average it won't matter much. But of the 
Bluetooth stack in NuttX is likely a performance bottleneck I am probably 
better off sticking with plan a and offload all Bluetooth LE Gatt stuff to the 
SiLabs module and simply exchange data as required via SPI.

On 29/10/2022, 01:06, "Disruptive Solutions"  
wrote:

I tried some Wifi and Bluetooth but know that some MCUs cannot handle them
very well at the same time.

Op za 29 okt. 2022 1:20 a.m. schreef Alan C. Assis :

> Hi Tim,
>
    > On 10/28/22, Tim Hardisty  wrote:
> > Bit of a tangential question this, but I know there are folk on here who
> > are much more conversant with the way NuttX can be used with WiFi and
> > Bluetooth modules than I am.
> >
>
> I think these are important questions and other people could face
> similar issues in the future.
>
> > I may have an opportunity forced on me to have to respin my custom board
> > which currently has a SiLabs Bluetooth SoC as well as the main SAMA5D2
> > processor. I used that module as I already have experience of it - but
> that
> > predates my NuttX journey.
> >
> > I see there are some very good value combined WiFi + Bluetooth modules
> now
> > (Espressif for example...and I know there's a well-known proponent of
> those
> > devices here lol) and, having seen a few other questions here, I am
> thinking
> > that I can go the HCI route and make use of the Bluetooth Stack in 
NuttX:
> > and add WiFi capability to my board at the same time. Winner!
> >
>
> First let me explain the differences:
>
> Espressif modules are not used as external modules on NuttX,
> everything is integrated inside the chip.
>
> During the WildernessLab's presentation on NuttX Workshop their team
> shown an ESP32 solution sharing WiFi as an external module.
> But they didn't use the default USRSOCK route, they implemented a new
> solution at home.
>
> > I'm hoping I can program up a suitable module with generic radio
> > co-processor software (HCI I think, and whatever is needed for WiFi) and
> > access it via UART from my main processor and have it all under the 
NuttX
> > system in a much more easily managed manner than a separate app on the
> > SiLabs SoC that just happens to communicate on some way with my main app
> on
> > the SAMA5D2.
> >
> > Have I got this right? Is an Espressif module a good choice (email me
> direct
> > if you want to !!)?
> >
>
> For Bluetooth (BLE) if there is a HCI firmware to SiLabs chip, then it
> could be possible to you use it, but you'll need to do some tests and
> debugging to get things working.
>
> For WiFi things are more complex because you need to implement a
> USRSOCK yourself to the chip.
>
> I never tested others possibilities: i.e. share Internet using SLIP
> between ESP32 and SAMA5D2, should be an easier route if it works, but
> of course you wil be limited to UART speed.
>
> Ethernet could be a better option (since ESP32 has Ethernet hardware),
> but it seems like an ugly and expensive workaround.
>
> BR,
>
> Alan
>

Re: Bluetooth+WiFi+NuttX

[Tim Hardisty]

Thanks for your clarifications Alan - I have messaged Espressif (your reply 
ended up in SPAM otherwise I might not have needed to) so I guess I'll get a 
similar answer.

There is HCI (RCP) firmware for the SiLabs module so I can try that - it's the 
£7 per module saving of Espressif vs. SiLabs, plus getting WiFi for free that 
appeals. SAMA5D2 has Ethernet - unused on my board so it is not an idea that is 
completely out of the question:  writing USRSOCK for the Espressif module is 
probably beyond me at this time!

On 29/10/2022, 00:20, "Alan C. Assis"  wrote:

Hi Tim,

    On 10/28/22, Tim Hardisty  wrote:
> Bit of a tangential question this, but I know there are folk on here who
> are much more conversant with the way NuttX can be used with WiFi and
> Bluetooth modules than I am.
>

I think these are important questions and other people could face
similar issues in the future.

> I may have an opportunity forced on me to have to respin my custom board
> which currently has a SiLabs Bluetooth SoC as well as the main SAMA5D2
> processor. I used that module as I already have experience of it - but 
that
> predates my NuttX journey.
>
> I see there are some very good value combined WiFi + Bluetooth modules now
> (Espressif for example...and I know there's a well-known proponent of 
those
> devices here lol) and, having seen a few other questions here, I am 
thinking
> that I can go the HCI route and make use of the Bluetooth Stack in NuttX:
> and add WiFi capability to my board at the same time. Winner!
>

First let me explain the differences:

Espressif modules are not used as external modules on NuttX,
everything is integrated inside the chip.

During the WildernessLab's presentation on NuttX Workshop their team
shown an ESP32 solution sharing WiFi as an external module.
But they didn't use the default USRSOCK route, they implemented a new
solution at home.

> I'm hoping I can program up a suitable module with generic radio
> co-processor software (HCI I think, and whatever is needed for WiFi) and
> access it via UART from my main processor and have it all under the NuttX
> system in a much more easily managed manner than a separate app on the
> SiLabs SoC that just happens to communicate on some way with my main app 
on
> the SAMA5D2.
>
> Have I got this right? Is an Espressif module a good choice (email me 
direct
> if you want to !!)?
>

For Bluetooth (BLE) if there is a HCI firmware to SiLabs chip, then it
could be possible to you use it, but you'll need to do some tests and
debugging to get things working.

For WiFi things are more complex because you need to implement a
USRSOCK yourself to the chip.

I never tested others possibilities: i.e. share Internet using SLIP
between ESP32 and SAMA5D2, should be an easier route if it works, but
of course you wil be limited to UART speed.

Ethernet could be a better option (since ESP32 has Ethernet hardware),
but it seems like an ugly and expensive workaround.

BR,

Alan

Re: Bluetooth+WiFi+NuttX

[Tim Hardisty]

Thanks Alan! SAMA5D2 has RMII so definitely a possibility. EFR32 is a much 
better value device compared to SiLabs Bluetooth 5 module currently used, and 
has WiFi as a bonus - so I will investigate it's IDE and see how easy it is to 
implement a GATT-based solution, or to load HCI firmware so I can be reasonably 
confident I'm not digging a big hole for myself if I make this change.


On 29/10/2022, 13:23, "Alan C. Assis"  wrote:

More info here:


https://e2e.ti.com/support/processors-group/processors/f/processors-forum/366759/am335x-rmii-direct-connection-between-two-devices

Same TI guy who said it was impossible latter talk internally and
discovered that there was a customer already using it.

BTW, you will need to have RMII supported by both MCUs (yes, ESP32 has 
RMII).

BR,

Alan

On 10/29/22, Alan C. Assis  wrote:
> Hi Tim,
>
> I just searched if it was possible to connect two Ethernet MAC
> directly without using PHY and it is possible, so it will not involve
> cost for you:
>
> 
https://stackoverflow.com/questions/39503466/can-two-ethernet-mac-chips-be-connected-directly-without-going-thru-phy
>
> BR,
>
> Alan
>
> On 10/29/22, Tim Hardisty  wrote:
>> Thanks for your clarifications Alan - I have messaged Espressif (your
>> reply
>> ended up in SPAM otherwise I might not have needed to) so I guess I'll 
get
>> a
>> similar answer.
>>
>> There is HCI (RCP) firmware for the SiLabs module so I can try that -
>> it's
>> the £7 per module saving of Espressif vs. SiLabs, plus getting WiFi for
>> free
>> that appeals. SAMA5D2 has Ethernet - unused on my board so it is not an
>> idea
>> that is completely out of the question:  writing USRSOCK for the
>> Espressif
>> module is probably beyond me at this time!
>>
>> On 29/10/2022, 00:20, "Alan C. Assis"  wrote:
>>
>> Hi Tim,
>>
>> On 10/28/22, Tim Hardisty  wrote:
>> > Bit of a tangential question this, but I know there are folk on
>> here
>> who
>> > are much more conversant with the way NuttX can be used with WiFi
>> and
>> > Bluetooth modules than I am.
>> >
>>
>> I think these are important questions and other people could face
>> similar issues in the future.
>>
>> > I may have an opportunity forced on me to have to respin my custom
>> board
>> > which currently has a SiLabs Bluetooth SoC as well as the main
>> SAMA5D2
>> > processor. I used that module as I already have experience of it -
>> but
>> that
>> > predates my NuttX journey.
>> >
>> > I see there are some very good value combined WiFi + Bluetooth
>> modules
>> now
>> > (Espressif for example...and I know there's a well-known proponent
>> of
>> those
>> > devices here lol) and, having seen a few other questions here, I am
>> thinking
>> > that I can go the HCI route and make use of the Bluetooth Stack in
>> NuttX:
>> > and add WiFi capability to my board at the same time. Winner!
>> >
>>
>> First let me explain the differences:
>>
>> Espressif modules are not used as external modules on NuttX,
>> everything is integrated inside the chip.
>>
>> During the WildernessLab's presentation on NuttX Workshop their team
>> shown an ESP32 solution sharing WiFi as an external module.
>> But they didn't use the default USRSOCK route, they implemented a new
>> solution at home.
>>
>> > I'm hoping I can program up a suitable module with generic radio
>> > co-processor software (HCI I think, and whatever is needed for
>> WiFi)
>> and
>> > access it via UART from my main processor and have it all under the
>> NuttX
>> > system in a much more easily managed manner than a separate app on
>> the
>> > SiLabs SoC that just happens to communicate on some way with my
>> main
>> app on
>> > the SAMA5D2.
>> >
>> > Have I got this right? Is an Espressif module a good choice (email
>> me
>> direct
>> > if you want to !!)?

Re: write-only interrupt registers

[Tim Hardisty]

I had a brain-splat. This is a non-issue. 40 years doing software and I 
randomly still get the basics wrong!

On 03/11/2022, 18:19, "TimH"  wrote:

lsof/crefs/somethings else?

[Tim Hardisty]

I have pretty much ironed out all the issues with the SAMA5 touchscreen (TSD) 
and ADC drivers, making sure they actually work correctly for the D2 variant 
and look like they should work for the D3 and D4 variants, and fixed bugs along 
the way. I will do a PR in due course but still have one high-level issue I am 
struggling to resolve, through inexperience.

The TSD relies on the ADC of course, but any given board may use either or 
both. And we can't know whether TSD or ADC will be opened first, nor which may 
be closed first, or at all.

Currently an ADC close disables interrupts and up disables them, and detaches 
them - but that kills the TSD of course.

For now, in the SAM ADC driver, I have #defined out the up disable and irq 
detach if the TSD is configured (CONFIG_SAMA5_TSD), and just make sure the ADC 
interrupts are disabled in the interrupt register, and similarly in the TSD 
driver. Each driver up enables the interrupt when first opened. This works, but 
does mean nothing ever up disables or detaches the interrupts, even if all TSD 
and ADC file instances are closed.

The ADC uses a cref count, managed by the higher and generic ADC code. The TSD 
code uses its own cref as it's SAMA5 specific, and I don't think the higher ADC 
code should be tampered with by me just to suit the obscure SAMA5 devices.

My thoughts are:

1) don't worry about it and just leave the interrupts attached and up enabled, 
but ensure the ADC interrupts are disabled at the register level on a close
2) Use something like lsof so the ADC driver can see if there's a TSD driver 
open, and vice versa, during a close. Is there an equivalent to lsof in NuttX?
3) Add a new flag to the SAMA5 ADC drivers that counts something that isn't an 
open as such but can be used by TSD and ADC drivers during a close. Number of 
calls to initialise the ADC perhaps, as the TSD board bringup code will call 
ADC init and vice versa.  That would mean exposing the relevant device 
structure(s) via the .h files - not sure if that's frowned upon?

Or something else I haven't thought of, of course!

Will a PR be ignored if it fails checks?

[Tim Hardisty]

As subject really. My (first real) PR failed some checks due to an unused 
variable. An easy fix, but I wanted to wait for any other feedback before 
resubmittingbut not much point waiting if the fail will mean no one reviews 
it lol.

What's the process?

Re: Will a PR be ignored if it fails checks?

[Tim Hardisty]

Hi Alin,

Ok - will do.

I ran the checkpatch script as per guides - should I have done something else 
as well before submitting a PR?

Thanks,

Tim.

On 16/11/2022, 08:00, "alin.jerpe...@sony.com"  wrote:

Hi Tim,

Please fix the warning / error without waiting for someone to review it. 

Best regards
Alin


-Original Message-
    From: Tim Hardisty  
Sent: den 15 november 2022 20:25
To: dev@nuttx.apache.org
Subject: Will a PR be ignored if it fails checks?

As subject really. My (first real) PR failed some checks due to an unused 
variable. An easy fix, but I wanted to wait for any other feedback before 
resubmittingbut not much point waiting if the fail will mean no one reviews 
it lol.

What's the process?

Re: Will a PR be ignored if it fails checks?

[Tim Hardisty]

Thanks Nathan - I have already left such a comment on the PR.

On 15/11/2022, 22:14, "Nathan Hartman"  wrote:

On Tue, Nov 15, 2022 at 2:25 PM Tim Hardisty 
wrote:

> As subject really. My (first real) PR failed some checks due to an unused
> variable. An easy fix, but I wanted to wait for any other feedback before
> resubmittingbut not much point waiting if the fail will mean no one
> reviews it lol.
>
> What's the process?



PRs are not ignored. Generally you can just fix the problem and push to the
branch.

For certain test failures, sometimes we even ignore the failures and merge,
such as if the PR fixes a typo or something and there's a NXSTYLE violation
elsewhere in the file that has been there for a long time and would be
nontrivial to fix and totally outside the scope of the PR.

For important test failures, like compiler warnings or whatever, they
should be fixed.

You could comment on the PR that you know about the fail and would like
other feedback in the meantime.

Also feel free to request reviews on Git Hub from people who generally work
on those areas.

Hope this helps
Nathan

Github check/Ubuntu version

[Tim Hardisty]

The checks on the few PRs I've done give an error " The ubuntu-18.04 
environment is deprecated, consider switching to ubuntu-20.04(ubuntu-latest), 
or ubuntu-22.04 instead."

Is that me (my machine is on 22.04 though) or a script/github problem?

Re: New names of repositories

[Tim Hardisty]

Might I humbly suggest that "if it isn't broken, don't fix it"?

Just stick with the names already in use (minus the incubator, as will happen 
anyway). Just tried searching the Apache website for "RTOS" and NuttX is top of 
the list; searching the Apache GitHub repositories similarly and NuttX is the 
only repo that comes up.

If it does go to a vote, you can guess what mine will be for :)

On 20/11/2022, 19:02, "Nathan Hartman"  wrote:

On Sun, Nov 20, 2022 at 9:46 AM Gregory Nutt  wrote:
> Could we simplify the options before a vote be discussing the
> possibilities that you have listed with INFRA?

Okay, I did that, and I have received responses from Infra that are
quite helpful:

(1) Infra requires repos to be named ${project}-${reponame} because of
technical reasons related to LDAP. (This was not previously documented,
but a note has been added to [1] in response to my question.)

(2) If we don't request otherwise, Infra will by default simply remove
"incubator-" from our repo names, so we would get:

* https://github.com/apache/nuttx
* https://github.com/apache/nuttx-apps

(3) When renaming repos, Infra is careful to preserve our existing
stars and forks. (They can, upon request, archive the repos and create
new ones, which would lose the existing stars and forks, but we
definitely don't want that!)

Additional note: I looked through the list of Apache repos at [2] (all
81 pages of them!!) and none had underscores or CamelCase.

So, bottom line, it looks like the name 'nuttx-apps' is pretty much set
in stone (unless we want to change 'apps' to something else), and
regarding the main repo, it could be one of the following (I'm just
including the items that were suggested earlier):

* nuttx
* nuttx-core
* nuttx-rtos
* nuttx-kernel
* nuttx-${something}

So that narrows down what we need to decide, which should make our
lives easier. :-)

[1] https://infra.apache.org/project-repo-policy.html

[2] https://github.com/orgs/apache/repositories

I have permission to share this reply verbatim:

[[[

On Sun, Nov 20, 2022 at 1:33 PM fluxo  wrote:
>
>
>
> > On Nov 20, 2022, at 9:20 AM, Nathan Hartman  
wrote:
> >
> > Hi all,
> >
> > Over in NuttX-land, we just graduated the Incubator and are having a
> > community-wide discussion [1] regarding what to name our repositories.
> >
> > We're *not* ready to rename them yet, since there is still a debate
> > going on.
> >
> > Rather, I'm writing only to ask some questions so we can narrow down
> > our choices:
> >
> > (1) Does Infra have a convention or preference on the use of hyphens,
> > underscores, CamelCase, for repo names, i.e., are any of these
> > preferred, not allowed, etc:
> >
> > https://github.com/apache/nuttx/nuttx-apps
> > https://github.com/apache/nuttx/nuttx_apps
> > https://github.com/apache/nuttx/NuttXApps
> >
> > (2) Is it possible to put our repos in a subdirectory, e.g.,
> >
> > https://github.com/apache/nuttx/nuttx
> > https://github.com/apache/nuttx/apps
>
> Congratulations on your graduation!
>
> The Infra convention requires project repos to be named with the 
convention of $project-$reponame in order to map the project LDAP group to the 
permissions scheme.
>
> Examples for the above would thus be:
>
> https://github.com/apache/nuttx
> https://github.com/apache/nuttx-apps
>
> When the time comes, please open an Infra Jira ticket to rename your 
repositories, considering the aforementioned naming scheme. We can do so in a 
way that preserves the existing stars/forks and redirects the old name. If you 
wish to start anew you may also do that by creating new repos via 
https://selfserve.apache.org/ and Infra can archive the old incubator repos.
>
> Do be careful if you file the incubator -> TLP ticket that without 
knowledge of your desires for renaming, Infra would simply remove 'incubator-' 
from the name of the repo(s).
>
> Up to you(r project.)
>
> > (Background info: In our pre-Incubator days, the repos were called
> > 'nuttx' and 'apps'.)
> >
> > (3) If there is a repo naming convention, is it documented somewhere
> > that I can share with our mailing list?
>
> It's documented insofar as much as selfserve will only allow the creation 
of repos following the pattern I mentioned.
>
> -fluxo (Chris)
> ASF Infra
>
>
> >
> > Thank you very much,
> > Nathan
> >
> > [1] https://lists.apache.org/thread/2o3rrh0qnoh53j4ro0gxompxr13lc59d
>

]]]

Cheers,
Nathan

Apologies

[Tim Hardisty]

Some may have seen I've been attempting multiple times to submit PRs for 2 
issues (SAMA5D2 related) and have closed/cancelled/retried numerous times.

Bottom line - I am struggling with the whole rebase/squash/merge cycle...as I'm 
a complete numpty. Code I can mostly do, but this is the first time working 
with a public repo not just my with own private code where I can do whatever I 
want ;)

I will fully "get it", eventually, but have now, at long last, had my first 
actual code PR accepted and merged. Thank you for your understanding and 
patience!

Regards,

TimJTi
---
PS I believe any email sent to the mail reflector that has been DKIM signed 
will end up in recipients spam folder...hence sending this from a non-DKIM 
signed email account to see what happens.

Re: Apologies

[Tim Hardisty]

That's a great reference - now bookmarked. Thank you!!

On 25/11/2022, 19:59, "Fotis Panagiotopoulos"  wrote:

Hi Tim,

Someone told me about this:

https://github.com/k88hudson/git-flight-rules

I haven't read it myself, but they say it is good.

I hope you find it helpful.

On Fri, Nov 25, 2022, 21:31 Alan C. Assis  wrote:

> Hi Tim,
>
> Don't worry, after you get used to it things become easier.
>
> If you have some ideas to improve the documentation to make it easier to
> the next "Tim", please don't hesitate to submit a PR :-D
>
> BR,
>
> Alan
>
> On Friday, November 25, 2022, TimH  wrote:
>
> > Some may have seen I've been attempting multiple times to submit PRs for
> 2
> > issues (SAMA5D2 related) and have closed/cancelled/retried numerous
> times.
> >
> > Bottom line - I am struggling with the whole rebase/squash/merge
> cycle.as
> > I'm a complete numpty. Code I can (mostly!) do, but this is the first
> time
> > working with a public repo rather than just my own private code, where I
> > can
> > do whatever I want ;)
> >
> > I will fully "get it", eventually, but have now, at long last, had my
> first
> > actual code PR accepted and merged. Thank you for your understanding and
> > patience!
> >
> > Regards,
> >
> > Tim
> >
> >
>

Re: Apologies

[Tim Hardisty]

OK, thanks.

Are CI checks something I could/should use for the commits to my own fork, 
before submitting a PR?

On 26/11/2022, 16:50, "Alan C. Assis"  wrote:

This is a CI issue. We just need to restart it manually.

Maybe we could add some tests to retry automatically when errors like
this happen.

On 11/26/22, TimH  wrote:
> Thanks for the support - another 2 PRs submitted now.
>
> But one failed tests with multiple instances of:
>
> " Error: Error response from daemon: login attempt to https://ghcr.io/v2/
> failed with status: 503 Service Unavailable"
>
> Do I need to do anything to get the tests to rerun and hopefully pass?
>
    >>-Original Message-
>>From: Tim Hardisty 
>>Sent: 25 November 2022 14:46
>>To: dev@nuttx.apache.org
>>Subject: Apologies
>>
>>Some may have seen I've been attempting multiple times to submit PRs for 2
>>issues (SAMA5D2 related) and have closed/cancelled/retried numerous
>>times.
>>
>>Bottom line - I am struggling with the whole rebase/squash/merge
>> cycle...as
>>I'm a complete numpty. Code I can mostly do, but this is the first time
> working
>>with a public repo not just my with own private code where I can do
> whatever
>>I want ;)
>>
>>I will fully "get it", eventually, but have now, at long last, had my
>> first
> actual
>>code PR accepted and merged. Thank you for your understanding and
>>patience!
>>
>>Regards,
>>
>>TimJTi
>>---
>>PS I believe any email sent to the mail reflector that has been DKIM
>> signed
> will
>>end up in recipients spam folder...hence sending this from a non-DKIM
> signed
>>email account to see what happens.
>
>

Re: Debugging a specific application

[Tim Hardisty]

Not sure if it helps, but the built-in apps can be easily debugged, so could 
you perhaps include your application as a custom app, selected via the NuttX 
Kconfig so it gets built in, then start it from the nsh?

A workaround maybe, but might help?

On 30/11/2022, 05:40, "Roberto Bucher"  wrote:

Hi

I'm working on my nucleo-144 board, trying to get a microROS working 
again under NuttX.

Thanks to a unique change in a microROS file, I've reached to recompile 
all the files again and I can obtain the microros application as 
described here:

https://github.com/micro-ROS/micro_ros_nuttx_app  apps/microros

The application doesn't correctly work yet, and I'm looking for the 
problem. I'd like to debug the microros application, but the debugger 
shows (as expected) the nsh task. It is possible to start the specific 
"microros" generated program or I have to set it as entry point? 
Otherwise, how can I attach this task to the debugger? I'm able to debug 
the nsh application with the methods described on the NuttX 
documentation about debugger. Thanks in advance Roberto

Re: Code donation

[Tim Hardisty]

I have interest in your settings storage, with the probability of adding yaml 
output since I was going to do something similar for my current project (once I 
get over the pain of getting NuttX fixed for the arch I'm using).

As have been suggested, maybe push it to github and I/we can clone what's of 
interest, see if it makes sense, then get it working right for NuttX and do a 
PR...in the fullness of time (i.e. I'm a slow worker!)

On 04/12/2022, 16:55, "Fotis Panagiotopoulos"  wrote:

Hello everyone!

Christmas arrived a bit earlier for NuttX as I would like to donate some of
my personal code to the community!

A bit of context.
Over the years that I am working on embedded systems, I have developed lots
of software that I use in my projects.
Some of it is quite general-purpose, or useful for other applications, and
I have found my self reusing it
quite often. In fact, there are some things that I use in practically all
firmwares that I have developed over
the last years.

I always wanted to open-source this software so other people can benefit
from it.
But I never managed to do so. Open-sourcing needs some effort, the software
needs maintenance, documentation
and support, and most importantly in most cases a "porting layer" needs to
be developed.
Last but not least, every project needs a bit of "marketing" and
"advertising" so others can learn about
your work and use it.

For the last couple of years I have been using NuttX a lot, and I have
ported most of the aforementioned software
to NuttX. I believe that NuttX and its community are perfect for me to
publish my code, instead of creating
a ton of small repos, of questionable usefulness and increasing my workload
considerably.

It is very important that I can get immediate feedback from the community,
learn what people are actually
interested in (instead of investing on software that no one needs), and
provide actual and *working*
samples of the code (as NuttX already supports a ton of different boards
and arches).

Using POSIX as the porting layer is also awesome.

That being said, my free time is still exceptionally limited and I cannot
do this myself.
I still need the help of the community, and most importantly I need to see
interest in a piece of
software before putting any work on it.

So, what I offer:
* I offer various codes, fully featured, production ready and tested.
* All code will be offered for free (of course) and under Apache licensing.
* I will provide support to those working on these codes, to my best
ability.
* I will contribute to testing everything integrated to NuttX, as hardware
availability allows me.
* I will do some licensing check, to ensure code is 100% original and mine,
or state the licenses of the projects I borrowed code from.

What I ask for:
I need people that are interested in each of these codes to integrate them
into NuttX apps.
You just have to pick what it is interesting to you, contact me to provide
you with the code,
and integrate it to NuttX. You will need to:
* Add the code into the NuttX apps repo, and ensure Kconfig and the build
system use the code properly (should be trivial).
* Adapt the file format and the coding style to the NuttX one (this may
need some work, but it can also be automated).
* Provide an example app, something that someone can run to use or demo the
new code.
* Test and verify the example app on actual hardware (I may be able to
cross-check it on my hardware too).

The code that I offer (for the moment):


*** Lua v5.2.4 ***
I know that there is already a Lua app for NuttX.
But for anyone using it, it may be beneficial to use my work.

First and foremost, I have ported the eLua LTR patch to Lua 5.2. This patch
dramatically reduces the memory usage of Lua.
In fact, I found out that it is crucial to have this patch enabled for any
actual real-life usage of Lua on any "normal" MCU.

I have created a Kconfig for all Lua configurations, so it can integrate
with NuttX better.

I have also made some other minor changes to the code that might be
interesting for you.
For example there is a simplistic sandboxing option.


*** MQTT Broker ***
Yes, a full-blown, spec-compliant MQTT Broker!
To my knowledge there is no other open-source and portable MQTT broker for
embedded systems.

It follows the MQTT v3.1.1 specification as closely as possible. I think
there is only one violation, needed due to its embedded nature,
but in all practical cases you may consider it fully compliant.

It has been tested with dozens of devices, and it performs greatly.
There are a couple of things that may need to be improved, but are trivial,
and will not affect the normal use of the soft

USB host - HID keyboard and other things

[Tim Hardisty]

Hi all,

I have finally got the USB interfaces working on my custom board (SAMA5D27) 
and, as a host, can see USB memory sticks, mount them and read/write to them. 
Also working as a USB device, using USB-C instead of OTG with an FUSB302 
controller to auto switch between the 2 modes. To say I’m very pleased is an 
understatement

I have now enabled HID keyboard and after a bit of messing around with the 
config it is now registering as /dev/kbda. If I run the hidkbd example I am not 
getting any characters though – it is stuck waiting for input. Same if I choose 
it as for USB console – the connect is seen, but no characters are delivered.

Is there some other step I’ve missed? In case it’s relevant, it’s actually a 
USB-C keyboard (that works fine on my Linux NUC).

Also: since, ultimately, the design needs to determine what sort of host device 
has been connected (keyboard or memory stick to start with) what is the 
technique needed to determine the device type connected? What do I poll or read 
to find the enumerated devices? In Linux there are various things such as 
“usb-devices” or “lsusb”

Thanks,

TimJTi.

Re: USB host - HID keyboard and other things

[Tim Hardisty]

Thanks – now I know what the likely issue is I can happily put this on the 
back-burner as it’s “only software” lol.

Next battle is to get RNDIS working – so many random Kconfig settings needed it 
seems.

From: Gregory Nutt 
Date: Thursday, 19 January 2023 at 19:18
To: dev@nuttx.apache.org 
Subject: Re: USB host - HID keyboard and other things
On 1/19/2023 1:12 PM, Alan C. Assis wrote:

> I think the currently NuttX USB Keyboard driver needs to be extended
> to support more keyboards. Do do that someone need to inspect the USB
> communication and figure out what is going on.

Unless someone has extended the driver, the USB keyboard driver only supports 
the so-called "boot keyboard" protocol. 
https://deskthority.net/wiki/USB#Keyboard_Boot_Protocol

Re: USB host - HID keyboard and other things

[Tim Hardisty]

Ultimately I need to make sure it works with most/any USB-C keyboard that 
customers might choose to plugin (or, at least, a style/type of keyboard that 
is widely available), but it’s not a priority right now.

From: Alan C. Assis 
Date: Thursday, 19 January 2023 at 20:08
To: dev@nuttx.apache.org 
Subject: Re: USB host - HID keyboard and other things
Hi Tim,

Look at page 85 here:
https://www.usb.org/sites/default/files/documents/hid1_11.pdf

"F.5 Keyboard: Using the Keyboard Boot Protocol
This section explains some of the detail behind the requirements
listed in Appendix G.4.
To use the boot protocol, the system should do the following:
- Select a Configuration which includes a bInterfaceSubClass of 1, “Boot
Interface Subclass,” and a bInterfaceProtocol of 1, “Keyboard”.
- Do a Set_Protocol to ensure the device is in boot mode. By default, the device
comes up in non-boot mode (must read the Report descriptor to know the
protocol), so this step allows the system to put the device into the predefined
boot protocol mode."

You can check if your keyboard supported it way:

$ lsusb -d : -v

Where : is your USB vendor:product keyboard id.

You should see it:

  bInterfaceClass 3 Human Interface Device
  bInterfaceSubClass  1 Boot Interface Subclass
  bInterfaceProtocol  1 Keyboard

BR,

Alan

On 1/19/23, Tim Hardisty  wrote:
> Thanks – now I know what the likely issue is I can happily put this on the
> back-burner as it’s “only software” lol.
>
> Next battle is to get RNDIS working – so many random Kconfig settings needed
> it seems.
>
> From: Gregory Nutt 
> Date: Thursday, 19 January 2023 at 19:18
> To: dev@nuttx.apache.org 
> Subject: Re: USB host - HID keyboard and other things
> On 1/19/2023 1:12 PM, Alan C. Assis wrote:
>
>> I think the currently NuttX USB Keyboard driver needs to be extended
>> to support more keyboards. Do do that someone need to inspect the USB
>> communication and figure out what is going on.
>
> Unless someone has extended the driver, the USB keyboard driver only
> supports the so-called "boot keyboard" protocol.
> https://deskthority.net/wiki/USB#Keyboard_Boot_Protocol
>

USB host - HID keyboard and other things

[Tim Hardisty]

Hi all,

I have finally got the USB interfaces working on my custom board (SAMA5D27) 
and, as a host, can see USB memory sticks, mount them and read/write to them. 
Also working as a USB device, using USB-C instead of OTG with an FUSB302 
controller to auto switch between the 2 modes. To say I'm very pleased is an 
understatement

I have now enabled HID keyboard and after a bit of messing around with the 
config it is now registering as /dev/kbda. If I run the hidkbd example I am not 
getting any characters though - it is stuck waiting for input. Same if I choose 
it as for USB console - the connect is seen, but no characters are delivered.

Is there some other step I've missed? In case it's relevant, it's actually a 
USB-C keyboard (that works fine on my Linux NUC).

Also: since, ultimately, the design needs to determine what sort of host device 
has been connected (keyboard or memory stick to start with) what is the 
technique needed to determine the device type connected? What do I poll or read 
to find the enumerated devices? In Linux there are various things such as 
"usb-devices" or "lsusb"

Thanks,

TimJTi.

PING

[Tim Hardisty]

Hi all,

I'm trying to get RNDIS working. It nearly does - Windows sees the "gadget" and 
it has the right IP address etc. But I can't ping my board.

Probably some buried config setting that I'm yet to find, so I thought I'd try 
pinging the Windows (11) PC from my board instead, so enabled the built-in ping 
example app.

It compiles OK but the app is not available from the shell:  typing "?" at the 
nsh prompt, and the app isn't listed  whereas others that I've enabled are 
there.

Any ideas?

Thanks,

Tim.

Re: PING

[Tim Hardisty]

I did turn the firewall off, just in case, but still no ping response *from* my 
board. Windows usually allows outward pings without problem. But this may be 
more relevant once I can get the NuttX ping to Windows available.

Linux not even seeing my board with RNDIS, but think I found that when I last 
tried this, years ago.

> On 25/01/2023, 19:11, "Gregory Nutt" mailto:spudan...@gmail.com>> wrote:

> The windows firewall usually blocks pings (at least incoming pings). 
> May sure that you configure the firewall to permit this operation.

>On 1/25/2023 1:01 PM, Tim Hardisty wrote:
>> Hi all,
>>
>> I'm trying to get RNDIS working. It nearly does - Windows sees the "gadget" 
>> and it has the right IP address etc. But I can't ping my board.
>>
>> Probably some buried config setting that I'm yet to find, so I thought I'd 
>> try pinging the Windows (11) PC from my board instead, so enabled the 
>> built-in ping example app.
>>
>> It compiles OK but the app is not available from the shell: typing "?" at 
>> the nsh prompt, and the app isn't listed whereas others that I've enabled 
>> are there.
>>

Re: PING

[Tim Hardisty]

Hi Alan - yes, I'm doing that to check what I missed for RNDIS (followed your 
video guide btw), but I can't explain why the PING app isn't available: any 
thoughts on that?

> On 25/01/2023, 23:12, "Alan C. Assis" mailto:acas...@gmail.com>> wrote:

> When you had double about your configuration, the best option is
> looking some working board config example.

> In this case take a look at boards/stm32f4discovery/configs/rndis/defconfig

> On 1/25/23, Tim Hardisty mailto:t...@hardisty.co.uk>> 
> wrote:
>> I did turn the firewall off, just in case, but still no ping response *from*
>> my board. Windows usually allows outward pings without problem. But this may
> be more relevant once I can get the NuttX ping to Windows available.
>>
>> Linux not even seeing my board with RNDIS, but think I found that when I
>> last tried this, years ago.
>>
>>> On 25/01/2023, 19:11, "Gregory Nutt" >> <mailto:spudan...@gmail.com>
>> <mailto:spudan...@gmail.com <mailto:spudan...@gmail.com>>> wrote:
>>
>>> The windows firewall usually blocks pings (at least incoming pings).
>>> May sure that you configure the firewall to permit this operation.
>>
>>>On 1/25/2023 1:01 PM, Tim Hardisty wrote:
>>>> Hi all,
>>>>
>>>>I'm trying to get RNDIS working. It nearly does - Windows sees the
>>>> "gadget" and it has the right IP address etc. But I can't ping my board.
>>>>
>>>> Probably some buried config setting that I'm yet to find, so I thought
>>>> I'd try pinging the Windows (11) PC from my board instead, so enabled the
>>>> built-in ping example app.
>>>>
>>>> It compiles OK but the app is not available from the shell: typing "?" at
>>>> the nsh prompt, and the app isn't listed whereas others that I've enabled
>>>> are there.

RE: PING

[Tim Hardisty]

Aha! - was missing the CONFIG_SYSTEM_PING!

I looked at the CONFIG_NETUTILS_PING help and it said it depended on NET_ICMP 
and was selected by SYSTEM_PING...that confused me.

Thanks!

I can run ping now but it fails with:

ERROR: socket() failed: 93

That's "protocol not supported", so I will dig deeper and continue my 
comparison of defconfigs.


>-Original Message-
>From: Alan C. Assis 
>Sent: 26 January 2023 12:21
>To: dev@nuttx.apache.org
>Subject: Re: PING
>
>Hi Tim,
>
>Did you enable ICMP protocol?
>
>Basically you need these flags:
>
>CONFIG_NET_ICMP
>CONFIG_NETUTILS_PING
>CONFIG_SYSTEM_PING
>
>BR,
>
>Alan
>
>On 1/26/23, Tim Hardisty  wrote:
>> Hi Alan - yes, I'm doing that to check what I missed for RNDIS
>> (followed your video guide btw), but I can't explain why the PING app isn't
>available:
>> any thoughts on that?
>>
>> > On 25/01/2023, 23:12, "Alan C. Assis" > <mailto:acas...@gmail.com>> wrote:
>>
>>> When you had double about your configuration, the best option is
>>> looking some working board config example.
>>
>>> In this case take a look at
>>> boards/stm32f4discovery/configs/rndis/defconfig
>>
>>> On 1/25/23, Tim Hardisty >> <mailto:t...@hardisty.co.uk>>
>>> wrote:
>>>> I did turn the firewall off, just in case, but still no ping
>>>> response
>>>> *from*
>>>> my board. Windows usually allows outward pings without problem. But
>>>> this may
>>> be more relevant once I can get the NuttX ping to Windows available.
>>>>
>>>> Linux not even seeing my board with RNDIS, but think I found that
>>>> when I last tried this, years ago.
>>>>
>>>>> On 25/01/2023, 19:11, "Gregory Nutt" >>>> <mailto:spudan...@gmail.com>
>>>> <mailto:spudan...@gmail.com <mailto:spudan...@gmail.com>>>
>wrote:
>>>>
>>>>> The windows firewall usually blocks pings (at least incoming pings).
>>>>> May sure that you configure the firewall to permit this operation.
>>>>
>>>>>On 1/25/2023 1:01 PM, Tim Hardisty wrote:
>>>>>> Hi all,
>>>>>>
>>>>>>I'm trying to get RNDIS working. It nearly does - Windows sees the
>>>>>>"gadget" and it has the right IP address etc. But I can't ping my
>>>>>>board.
>>>>>>
>>>>>> Probably some buried config setting that I'm yet to find, so I
>>>>>> thought I'd try pinging the Windows (11) PC from my board instead,
>>>>>> so enabled the built-in ping example app.
>>>>>>
>>>>>> It compiles OK but the app is not available from the shell: typing "?"
>>>>>> at
>>>>>> the nsh prompt, and the app isn't listed whereas others that I've
>>>>>> enabled are there.
>>
>>

RE: PING

[Tim Hardisty]

I have CDC-ECM working just fine to my Linux machine. Ping now working too.

I cannot get RNDIS to work. It is seen by Windows and has an IP, but pings in 
either direction fail.

If I ping from my board to the windows machine I get:

arp_send: ERROR: arp_wait failed: -110

Looks like arp is failing for some reason but I have no idea, despite having 
compared defconfig files that have RNDIS enabled :(

>-Original Message-
>From: Alan C. Assis 
>Sent: 26 January 2023 12:21
>To: dev@nuttx.apache.org
>Subject: Re: PING
>
>Hi Tim,
>
>Did you enable ICMP protocol?
>
>Basically you need these flags:
>
>CONFIG_NET_ICMP
>CONFIG_NETUTILS_PING
>CONFIG_SYSTEM_PING
>
>BR,
>
>Alan
>
>On 1/26/23, Tim Hardisty  wrote:
>> Hi Alan - yes, I'm doing that to check what I missed for RNDIS
>> (followed your video guide btw), but I can't explain why the PING app isn't
>available:
>> any thoughts on that?
>>
>> > On 25/01/2023, 23:12, "Alan C. Assis" > <mailto:acas...@gmail.com>> wrote:
>>
>>> When you had double about your configuration, the best option is
>>> looking some working board config example.
>>
>>> In this case take a look at
>>> boards/stm32f4discovery/configs/rndis/defconfig
>>
>>> On 1/25/23, Tim Hardisty >> <mailto:t...@hardisty.co.uk>>
>>> wrote:
>>>> I did turn the firewall off, just in case, but still no ping
>>>> response
>>>> *from*
>>>> my board. Windows usually allows outward pings without problem. But
>>>> this may
>>> be more relevant once I can get the NuttX ping to Windows available.
>>>>
>>>> Linux not even seeing my board with RNDIS, but think I found that
>>>> when I last tried this, years ago.
>>>>
>>>>> On 25/01/2023, 19:11, "Gregory Nutt" >>>> <mailto:spudan...@gmail.com>
>>>> <mailto:spudan...@gmail.com <mailto:spudan...@gmail.com>>>
>wrote:
>>>>
>>>>> The windows firewall usually blocks pings (at least incoming pings).
>>>>> May sure that you configure the firewall to permit this operation.
>>>>
>>>>>On 1/25/2023 1:01 PM, Tim Hardisty wrote:
>>>>>> Hi all,
>>>>>>
>>>>>>I'm trying to get RNDIS working. It nearly does - Windows sees the
>>>>>>"gadget" and it has the right IP address etc. But I can't ping my
>>>>>>board.
>>>>>>
>>>>>> Probably some buried config setting that I'm yet to find, so I
>>>>>> thought I'd try pinging the Windows (11) PC from my board instead,
>>>>>> so enabled the built-in ping example app.
>>>>>>
>>>>>> It compiles OK but the app is not available from the shell: typing "?"
>>>>>> at
>>>>>> the nsh prompt, and the app isn't listed whereas others that I've
>>>>>> enabled are there.
>>
>>

Re: PING

[Tim Hardisty]

I've been through 3 different Windows RNDIS drivers and they all behave the 
same. One more variant to try tomorrow from some searching.

As you saw RNDIS is a Microsoft thing, and supposedly should just work. There's 
probably a change that Windows made that has broken thingsjust for a change!

On 26/01/2023, 19:58, "Gregory Nutt" mailto:spudan...@gmail.com>> wrote:


On 1/26/2023 1:52 PM, Gregory Nutt wrote:
> Perhaps you need a driver on Windows? It appears so from a quick 
> Google where I find articles like:
>
> https://learn.microsoft.com/en-us/windows-hardware/drivers/network/overview-of-remote-ndis--rndis-
>  
> 
>  
>
> https://supportcommunity.zebra.com/s/article/14464?language=en_US 
> 
> https://support.lenovo.com/us/en/downloads/ds558735-rndis-driver-for-windows-10-lenovo-thinksystem-sr635-and-sr655
>  
> 
>  




Hmm... probably not. The first article above says:


"Microsoft provides an NDIS miniport driver, Rndismp.sys, which
implements the Remote NDIS message set and communicates with generic
bus transport drivers, which in turn communicate with the
appropriate bus driver. This NDIS miniport driver is implemented and
maintained by Microsoft and is distributed as part of Windows."


You still might want to use Device Manager to check which driver was 
selected.

Re: PING

[Tim Hardisty]

RNDIS didn't work on Ubuntu for me (maybe need to find a driver), but CDC-ECM 
is the right protocol for Linux I think.

My wish is to get RNDIS and CDC-ECM enabled (as a composite device I think) so 
users have no need to download or install drivers for Windows or Linux. Mac 
probably needs something installed away from the dreaded Apple Store but that 
is usual!

Arp failing is a pretty fundamental problem! 

On 26/01/2023, 19:47, "Alan C. Assis" mailto:acas...@gmail.com>> wrote:


Hi Tim,


I think someone already commented of this issue using RNDIS on Windows.


It works fine with Linux (not sure about MacOS). So it will requires
some investigation to understand what is going on.


Try to use it connected to some Linux machine to confirm.


BR,


Alan


On 1/26/23, Tim Hardisty mailto:t...@hardisty.co.uk>> 
wrote:
> I have CDC-ECM working just fine to my Linux machine. Ping now working too.
>
> I cannot get RNDIS to work. It is seen by Windows and has an IP, but pings
> in either direction fail.
>
> If I ping from my board to the windows machine I get:
>
> arp_send: ERROR: arp_wait failed: -110
>
> Looks like arp is failing for some reason but I have no idea, despite having
> compared defconfig files that have RNDIS enabled :(
>
>>-Original Message-
>>From: Alan C. Assis mailto:acas...@gmail.com>>
>>Sent: 26 January 2023 12:21
>>To: dev@nuttx.apache.org <mailto:dev@nuttx.apache.org>
>>Subject: Re: PING
>>
>>Hi Tim,
>>
>>Did you enable ICMP protocol?
>>
>>Basically you need these flags:
>>
>>CONFIG_NET_ICMP
>>CONFIG_NETUTILS_PING
>>CONFIG_SYSTEM_PING
>>
>>BR,
>>
>>Alan
>>
>>On 1/26/23, Tim Hardisty mailto:t...@hardisty.co.uk>> 
>>wrote:
>>> Hi Alan - yes, I'm doing that to check what I missed for RNDIS
>>> (followed your video guide btw), but I can't explain why the PING app
>>> isn't
>>available:
>>> any thoughts on that?
>>>
>>> > On 25/01/2023, 23:12, "Alan C. Assis" >> > <mailto:acas...@gmail.com>
>>> <mailto:acas...@gmail.com <mailto:acas...@gmail.com>>> wrote:
>>>
>>>> When you had double about your configuration, the best option is
>>>> looking some working board config example.
>>>
>>>> In this case take a look at
>>>> boards/stm32f4discovery/configs/rndis/defconfig
>>>
>>>> On 1/25/23, Tim Hardisty mailto:t...@hardisty.co.uk>
>>>> <mailto:t...@hardisty.co.uk <mailto:t...@hardisty.co.uk>>>
>>>> wrote:
>>>>> I did turn the firewall off, just in case, but still no ping
>>>>> response
>>>>> *from*
>>>>> my board. Windows usually allows outward pings without problem. But
>>>>> this may
>>>> be more relevant once I can get the NuttX ping to Windows available.
>>>>>
>>>>> Linux not even seeing my board with RNDIS, but think I found that
>>>>> when I last tried this, years ago.
>>>>>
>>>>>> On 25/01/2023, 19:11, "Gregory Nutt" >>>>> <mailto:spudan...@gmail.com>
>>>>>> <mailto:spudan...@gmail.com <mailto:spudan...@gmail.com>>
>>>>> <mailto:spudan...@gmail.com <mailto:spudan...@gmail.com> 
>>>>> <mailto:spudan...@gmail.com <mailto:spudan...@gmail.com>>>>
>>wrote:
>>>>>
>>>>>> The windows firewall usually blocks pings (at least incoming pings).
>>>>>> May sure that you configure the firewall to permit this operation.
>>>>>
>>>>>>On 1/25/2023 1:01 PM, Tim Hardisty wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>>I'm trying to get RNDIS working. It nearly does - Windows sees the
>>>>>>>"gadget" and it has the right IP address etc. But I can't ping my
>>>>>>>board.
>>>>>>>
>>>>>>> Probably some buried config setting that I'm yet to find, so I
>>>>>>> thought I'd try pinging the Windows (11) PC from my board instead,
>>>>>>> so enabled the built-in ping example app.
>>>>>>>
>>>>>>> It compiles OK but the app is not available from the shell: typing
>>>>>>> "?"
>>>>>>> at
>>>>>>> the nsh prompt, and the app isn't listed whereas others that I've
>>>>>>> enabled are there.
>>>
>>>
>

Re: USB host - HID keyboard and other things

[Tim Hardisty]

I have traced the USB communication and it gets as far as it polling for new 
data, but never gets any. It is all detected, instantiated properly, and so 
forth – just doesn’t get data. So, as suggested, a protocol issue. The keyboard 
I’m using reports itself as subclass BOOTIF and protocol KEYBOARD so I think it 
ought to work.

That said, the HID keyboard driver is also broken as multiple plugs/unplugs 
causes a crash. I’m thinking memory leak but not investigated yet.


From: Gregory Nutt 
Date: Thursday, 19 January 2023 at 19:18

On 1/19/2023 1:12 PM, Alan C. Assis wrote:

> I think the currently NuttX USB Keyboard driver needs to be extended
> to support more keyboards. Do do that someone need to inspect the USB
> communication and figure out what is going on.
>
> Unless someone has extended the driver, the USB keyboard driver only
> supports the so-called "boot keyboard" protocol.
> https://deskthority.net/wiki/USB#Keyboard_Boot_Protocol

RE: [OT] Who is contribution with NuttX?

[Tim Hardisty]

>Tim Hardisty = 15

That be me :)

JT Innovations Ltd

Or JTi for short.
 

RNDIS

[Tim Hardisty]

Seems that RNDIS on Linux is deprecated as it's deemed insecure, so I need to 
use CDC-ECM for Linux (which works), but there's no generic driver for that in 
Windows (unless anyone knows differently?).



So I am still trying to get RNDIS working...2 days of prodding and poking so 
far and no luck :(



Can anyone confirm that they have actually had RNDIS working to a Windows 10 or 
11 machine recently? With Nuttx 11 or 12 maybe? And, if so, share a working 
.config with me?

RE: RNDIS

[Tim Hardisty]

Just what I read, perhaps it *will* be deprecated...

Modprobe does suggest that rndis_host is, indeed, present so, in that case, 
RNDIS doesn't work on Linux either!

>-Original Message-
>From: Alan C. Assis 
>Sent: 27 January 2023 16:12
>To: dev@nuttx.apache.org
>Subject: Re: RNDIS
>
>Strange, it still available here:
>
>$ sudo modprobe rndis_host
>
>BR,
>
>Alan
>
>On 1/27/23, Tim Hardisty  wrote:
>> Seems that RNDIS on Linux is deprecated as it's deemed insecure, so I
>> need to use CDC-ECM for Linux (which works), but there's no generic
>> driver for that in Windows (unless anyone knows differently?).
>>
>>
>>
>> So I am still trying to get RNDIS working...2 days of prodding and
>> poking so far and no luck :(
>>
>>
>>
>> Can anyone confirm that they have actually had RNDIS working to a
>> Windows 10 or 11 machine recently? With Nuttx 11 or 12 maybe? And, if
>> so, share a working .config with me?
>>
>>

Pass interrupt status to handler

[Tim Hardisty]

Think this is an easy one but it's stumped me so far...

I am setting up the USB Overcurrent interrupt and can't find any fully 
implemented examples.

The interrupt is set to both edges as I want to know when the over current 
state is first set and later hopefully cleared.

I can obviously read the state of the input pin, but I sort of feel I should be 
able to pass the state as an arg to the handler (via xcpt_t handler).

Is that possible and, if so, how?

RE: Pass interrupt status to handler

[Tim Hardisty]

No, not that I've created, although there might be one related to all the PIO I 
guess. Think I hoped that the basic NuttX interrupt mechanisms might inherently 
hold the state but couldn't immediately see it (including via debug).

No big deal - reading the PIO status is no issue, and I don't need to retain 
the state: if the input is low, there's an overcurrent state and if high 
there's not: kill power or don't, maybe notify any waiters to let the user 
know, that sort of thing.

>-Original Message-
>From: Nathan Hartman 
>Sent: 27 January 2023 18:15
>To: dev@nuttx.apache.org
>Subject: Re: Pass interrupt status to handler
>
>Is there a global structure where you retain state information where it
>would be appropriate to save the most refent known state in a volatile
>variable?
>
>On Fri, Jan 27, 2023 at 1:00 PM Tim Hardisty  wrote:
>
>> Think this is an easy one but it's stumped me so far...
>>
>> I am setting up the USB Overcurrent interrupt and can't find any fully
>> implemented examples.
>>
>> The interrupt is set to both edges as I want to know when the over
>> current state is first set and later hopefully cleared.
>>
>> I can obviously read the state of the input pin, but I sort of feel I
>> should be able to pass the state as an arg to the handler (via xcpt_t
>> handler).
>>
>> Is that possible and, if so, how?
>>

Re: RNDIS

[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: Lua fails to build

[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

[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 
<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 
> <https://github.com/apache/nuttx/issues/8325>
>
>
> :)
>
>

Re: RNDIS

[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"  <mailto:acas...@gmail.com>
> <mailto:acas...@gmail.com <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 
> <http://openocd.org/doc/doxygen/bugs.html>
> <http://openocd.org/doc/doxygen/bugs.html> 
> <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" but

Re: Lua fails to build

[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 
<mailto: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?

Custom SAMA5 dual-role ("OTG") usb

[Tim Hardisty]

I am implementing non-standard dual-role USB support for my SAMA5D27 board, 
using an external usb-c controller (FUSB302) to determine the required role and 
then set things up as necessary.

Nearly there and, although it is mostly board-specific, it does need some minor 
changes to one or more core "arch" files (e.g. sam_udphs.c).

These changes need to/must be neutral to 99.9% users of NuttX using SAMA5 
processors. I'd been hoping to do this via my board's custom Kconfig but 
currently the main SAMA5 Kconfig prevents the selection of something I need for 
this. Although for a good reason (to prevent a board turning on Vbus +5V to a 
port that is 99.8% of the time used as a device port) there are plenty of 
guards in the underlying code to #undef the option just in case.

Unless someone has a better idea, my proposal is:

1) to have a CONFIG_SAMA5_USB_DRP option in the SAMA5 Kconfig. If set, it will 
disable the Kconfig "depends on" that prevents the selection of the relevant 
usb port as a host. Just for SAMA5 - but it could be just for SAM5D2 if 
preferred to further limit it?
2) The CONFIG_SAMA5_USB_DRP option will be used to modify the #undef guards in 
the SAMA5 usb code.
3) The same option will be used disable/enable code as required, to allow for 
dual-role port functionality
4) I could include #warning directives if CONFIG_SAMA5_USB_DRP is set to ensure 
anyone setting it sits backs and thinks!

Does that all seem reasonable?

I can post as an issue on GitHub if wanted, for discussion pending a PR 
(assuming I do actually get this to work as wanted)?

Thanks,

TimH/TimJTi

RE: Custom SAMA5 dual-role ("OTG") usb

[Tim Hardisty]

>-Original Message-
>From: Tim Hardisty 
>Sent: 03 February 2023 11:13
>1) to have a CONFIG_SAMA5_USB_DRP option in the SAMA5 Kconfig.

Actually - I just found of course I can put that option in my board's Kconfig 
which would be better and much safer.

Re: RNDIS

[Tim Hardisty]

> On 28/01/2023, 14:11, "Alan C. Assis"  wrote:

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

Just for completeness, there was indeed a fix needed in the SAMA5 sam_udphs.c 
code.

This is now done and merged to master.

RNDIS is now working for this processor with Linux and Win11.

Ioctl numbering

[Tim Hardisty]

I just completed a driver for a usb misc driver. I created my own sequential 
list of ioctl numbers (albeit based on a list from a similar driver), declared 
in the driver's header file.

I'm now doing a driver for an ambient light and proximity sensor and I see 
there is a dedicated sensors ioctl header file that lists many custom ioctls 
for many many sensors, with no duplication.

From my limited knowledge ioctl numbering ought to be unique just in case an 
incorrect ioctl is passed to a driver?

So, for my new driver, I think the right approach is for me to add new and 
unique entries at the end of the file for this new sensor - yes?

If so, ought we to also create an ioctl header file for usbmisc (and no doubt 
elsewhere)? But, that said, there is commonality between most of the ioctls for 
me new usbmisc driver and 2 existing ones so perhaps they ought at the very 
least to use the same numbers?

Or should there even be a global all-encompassing list of driver ioctl numbers?

What's the best practice here?

Byte to int32/big and little endian

[Tim Hardisty]

As is so often the case, I need to pack an array of 4x uint8_t  into a 
uint32_t. Obviously there are many ways to do this and we all have our 
favourite. For NuttX:

1) have I missed a library function that does this already?
2) to cope with big and little end is there a NuttX CONFIG or other parameter 
that will give the endian-ness of the arch being built to ensure the byte 
packing is done correctly?

Thx, TimH.

Re: Byte to int32/big and little endian

[Tim Hardisty]

On 25/02/2023, 11:47, "Karel Kočí" mailto:cyn...@email.cz>> 
wrote:

>I would use union (that is host ordering) and to convert to specific ordering 
>you can use functions like htobe32 (big endian) and htole32 (little endian), 
> those are available.

> Excerpts from Tim Hardisty's message of February 25, 2023 11:26 am:
>> As is so often the case, I need to pack an array of 4x uint8_t into a 
>> uint32_t. Obviously there are many ways to do this and we all have our 
>> favourite. For NuttX:
>> 
>> 1) have I missed a library function that does this already?
>> 2) to cope with big and little end is there a NuttX CONFIG or other 
>> parameter that will give the endian-ness of the arch being built to ensure 
>> the byte packing is done correctly?

When using a union is it fair to assume that it is the responsibility of an app 
rather than a driver to sort endian-ness? I can find no references in the NuttX 
code base to changing endian-ness?

Perhaps I'm over-thinking!

Re: Byte to int32/big and little endian

[Tim Hardisty]

On 26/02/2023, 12:37, "spudaneco" mailto:spudan...@gmail.com>> wrote:

> I can find no references in the NuttX code base to changing 
> endian-ness?Search for CONFIG_ENDIAN_BIG

Could have sworn I searched for that as had come across that CONFIG option. 
Search fail...sorry. I will look at what the drivers that check that do and 
follow suit. Thanks!

RE: Byte to int32/big and little endian

[Tim Hardisty]

>From: Karel Kočí 
>Sent: 26 February 2023 20:05
>
>Excerpts from Tim Hardisty's message of February 26, 2023 12:17 pm:
>>
>> On 25/02/2023, 11:47, "Karel Kočí" > wrote:
>>
>>>I would use union (that is host ordering) and to convert to specific
>>>ordering you can use functions like htobe32 (big endian) and htole32
>>>(little endian),  those are available.
>>
>>> Excerpts from Tim Hardisty's message of February 25, 2023 11:26 am:
 As is so often the case, I need to pack an array of 4x uint8_t into a
>uint32_t. Obviously there are many ways to do this and we all have our
>favourite. For NuttX:

 1) have I missed a library function that does this already?
 2) to cope with big and little end is there a NuttX CONFIG or other
>parameter that will give the endian-ness of the arch being built to
>ensure the byte packing is done correctly?
>>
>> When using a union is it fair to assume that it is the responsibility
>of an app rather than a driver to sort endian-ness? I can find no
>references in the NuttX code base to changing endian-ness?
>>
>> Perhaps I'm over-thinking!
>>
>
>
>The example might be helpful. Lets start with absolute basic just to be
>sure we understand each other:
>
>  union {
>uint32_t u32;
>uint8_t u8[4];
>  } foo;
>
>  foo.u32 = 42; // This uses host's endianness and the compiler's
>responsibility
>  // The following prints most significant byte on the big endian and
>least
>  // significant byte on the little endian. Probably nothing new...
>  printf("%d\n", foo.u8[0]);
>
>The point is that compiler always knows the correct endianness and uses
>it. That is also what you accept as argument in most functions (commonly
>expected when order is not documented).
>
>Now when you are implementing chip specific driver you know endianness
>and thus there is no need to do swap when it matches.
>On the other hand, when you are implementing generic driver, expected to
>be running on any CPU, you need to ensure that swap happens when ever it
>is required (endianness doesn't match). The common approach, not just in
>NuttX, are those functions I pointed previously. The manual page for them
>is endian (https://man7.org/linux/man-pages/man3/endian.3.html).
>
>I think that you are overthinking it and you missed the library call. 😉

Yes, I missed the library call (never written portable drivers before, nor used 
public domain software like NuttX, so not aware of that sort of thing). And, in 
my case, this is reading 4 bytes in sequence from an 12c device and then 
packing them into a uint32_t to be read by the character driver read function.

I have found a fair few references suggesting unions are not portable if you 
write to one union element and read from another, and perhaps needing to be C89 
compliant makes it worse?

I'm think a simple byte packing macro that takes account of CONFIG_ENDIAN_BIG 
(as per other drivers) is the safest - for me at least!

But this must be such a common thing to need to do I'm surprised I'm struggling 
to find an obvious example to refer to in chip driver code here - suggesting 
inconsistency and lack of "core" macro functions that would be useful?

VS Code debugging

[Tim Hardisty]

I have been using VS code with a Segger Jlink for debugging so far but am 
struggling to find the cause of a problem in a driver I'm writing and I think 
the VS Code debug setup may be lacking.

Before I spend time getting openOCD installed and following the various guides 
for that, with NuttX, that exist, has anyone used VS Code to more thoroughly 
debug NuttX (threads, memory exceptions/errors) rather than just relying on 
breakpoints?

Thanks,

TimH

RE: VS Code debugging

[Tim Hardisty]

Thanks Bartok. Seems, as usual, I am Mr. DumbHead as I am already using a 
CortexA5.svd file and do, indeed, see Cortex registers. But IO am not 100% 
convinced the svd is totally right so I'm trying to track one down for the 
SAMA5D2 family.

What I can't do is trace the cause of an exception. The earliest entry in the 
call stack is:

arm_vectordata@0x200081a4

I am using that address, at least, to pinpoint the file at issue from the .map 
output, but no joy fixing it yet!

I am now looking at the PX4 debug files you suggested but some of the options 
aren't liked by my VS Code environment/extensions and they are not recognised 
by GDB (e.g. "backtrace" or "showtasks"). I can't manually type these commands 
in either so it suggests the set up isn't thread or task aware as I'd sort of 
twigged.

I will press on and hopefully find a solution to make the debugging environment 
more comprehensive.

Thanks for taking the time to reply :)

>From: Bartek22 
>Sent: 03 March 2023 07:00
>
>Take a look at PX4 project on github. I work with this setup with my own
>projects with nuttx and everything works great. They are generating some
>files from cmake so take a look at platforms/nuttx directory and
>CMakeLists files inside and add .svd files for your mcu and everything
>should work.
>Best regards,
>Bartek
>
>czw., 2 mar 2023, 20:24 użytkownik Tim Hardisty 
>napisał:
>
>> I have been using VS code with a Segger Jlink for debugging so far but
>> am struggling to find the cause of a problem in a driver I'm writing
>> and I think the VS Code debug setup may be lacking.
>>
>> Before I spend time getting openOCD installed and following the
>> various guides for that, with NuttX, that exist, has anyone used VS
>> Code to more thoroughly debug NuttX (threads, memory
>> exceptions/errors) rather than just relying on breakpoints?
>>
>> Thanks,
>>
>> TimH
>>

Help me understand file open/close behaviours?

[Tim Hardisty]

Hi all,

The bug I thought I had in a driver I'm developing (well, one of them!) appears 
to be related to file closing.

- I have a related example-type app I'm using to exercise and check the driver. 
It opens 2 "files" (O-RDONLY) to read data from the device driver
- I have enabled CONFIG_SIGKILL_ACTION to allow me to ctrl-c from the console 
if the app is misbehaving or, I thought, just to exit it.

The behaviours I see are:

1) If I ctrl-c, the open files are not closed and if I re-run the app, the 
system crashes. It is the very first printf statement of the app that causes 
the crash, at the point the printf routine calls lib_fflush (not looked further 
yet).
2) If I ensure the test app reads console input too, and map a character 
received character (e.g. 'x') to a clean exit, I can then re-run the app 
without issue.

I don't think I saw this behaviour with the previous driver I did, so I have 
probably changed something via menuconfig, but I still would have thought/hoped 
that this sort of behaviour wouldn't happen regardless?

Anyone got any suggestions or hints (other than go back to school!)?

TimH