Re: FAT FS on mtd partition of NOR flash

[Tim Hardisty]

I will only be making a few 100 changes over the life of the product. It’s a 
holding area for a new firmware image to be written via USBMSD by the user and 
used by MCUboot to write out (raw) to the main boot flash. Ideally I would like 
a “FAT translator” that allows (say) a LittleFS partition to be seen as FAT via 
USB but I don’t think such a thing exists.

Obviously FAT is useless on flash for more “normal” things, which is why I have 
a 32MByte NOR flash running LittleFS for syslog and userlogs. In the limit I 
may just use a FAT formatted RAMdisk for the upgrade staging, but it depends on 
how much RAM my app ends up needing.

> On 1 Nov 2024, at 15:12, Xiang Xiao  wrote:
> 
> it mayn't work as you expect. FatFS updates some fixed location very
> frequently, your flash device may stop working after you make ten thousand
> changes.
> 
> On Fri, Nov 1, 2024 at 8:06 PM Tim hardisty  wrote:
> 
>> I am successfully creating a FAT FS on a QSPI NOR flash - the problem
>> was an error in the flash driver when 512 byte sector emulation was
>> being used. I do this in my bringup code:
>> struct qspi_dev_s *qspi_flashmem;
>> 
>> qspi_flashmem = sam_qspi_initialize(0);
>> ...
>> mtd_qspi = gd55_initialize(qspi_flashmem, 0);
>> ...
>> mtd_qspi0 = mtd_partition(mtd_qspi, 0, QSPI0_SIZE);...
>> ...
>> ret = register_mtddriver("/dev/qspi0", mtd_qspi0, 0744, NULL);
>> ...
>> mtd_qspi1 = mtd_partition(mtd_qspi, QSPI0_SIZE, QSPI1_SIZE);
>> ...
>> ret = register_mtddriver("/dev/qspi1", mtd_qspi1, 0755, NULL);
>> ret = nx_mount("/dev/qspi1", "/mnt/qspi1lfs", "littlefs", 0, "autoformat");
>> etc.
>> 
>> The GD55 driver is using 512 byte simulation, but s512_initialize()
>> works just as well.
>> 
>> I can then use mkfatfs to create a FAT FS and mount it and all is good.
>> 
>> mkfats fs is not available to use in bringup code as I understand it
>> otherwise I would mount the FS in my bringup too.
>> 
>> On 01/11/2024 02:07, Xiang Xiao wrote:
>>> On Wed, Oct 30, 2024 at 2:00 AM Tim Hardisty 
>>> wrote:
>>> 
>>>> Whilst FAT on a NOR flash may generally be seen a not such a great
>>>> idea...please ignore that and confirm if...
>>>> 
>>>> ...I am right in deducing that I can't simply make a FAT file system on
>>>> (say) the third mtd partition (with 512 byte sector emulation)
>>>> (partitions 0, 1 and 2 are "raw" data) since FAT will treat the entire
>>>> flash devices as a "volume" and so fail to find a partition table at the
>>>> bottom end of the flash device?
>>> 
>>> The partition is different from the file system. A file system can mount
>> on
>>> either a block/mtd device, or a partition. FAT can work only with the
>> block
>>> device, so you can't mount FAT on a flash(mtd) device, only the special
>>> designed file system(e.g. littlefs, smartfs, spiffs) can work with mtd
>>> device directly. The traditional block based file system need FTL(flash
>>> translation layer) to work with mtd device, so you can try dhara if you
>>> really want to use FAT on flash device:
>>> https://github.com/apache/nuttx/blob/master/drivers/mtd/dhara.c
>>> 
>>> If so, it no doubt explains why I can
>>>> format a FAT FS but not mount it.
>>>> 
>>>> 
>>> Which command do you use to format the device or partition?
>>> 
>>> I could - perhaps should -  re-jig my partitions so partition 0 is used
>>>> for FAT, rather than partition 3, but before I do that are there any FAT
>>>> FA/NuttX gurus who can let me know if there is a way to do this (and
>>>> save me the hassle of reworking my bootstrap and MCUboot locations etc.
>>>> for now)?
>>> 
>>> You can format the device with GPT/MBR partition by:
>>> https://github.com/apache/nuttx-apps/tree/master/fsutils/mkgpt
>>> https://github.com/apache/nuttx-apps/tree/master/fsutils/mkmbr
>>> But, the raw flash device normally doesn't use GPT/MBR partition, instead
>>> hardcode the  partition in the code directly since CPU normally could run
>>> firmware directly on flash devices which normally define a proprietary
>>> partition scheme. For this case, you can use PTABLE/TXTABLE:
>>> https://github.com/apache/nuttx/blob/master/fs/partition/fs_ptable.c
>>> https://github.com/apache/nuttx/blob/master/fs/partition/fs_txtable.c
>>> 
>> 

Re: FAT FS on mtd partition of NOR flash

[Tim hardisty]

I am successfully creating a FAT FS on a QSPI NOR flash - the problem 
was an error in the flash driver when 512 byte sector emulation was 
being used. I do this in my bringup code:

struct qspi_dev_s *qspi_flashmem;

qspi_flashmem = sam_qspi_initialize(0);
...
mtd_qspi = gd55_initialize(qspi_flashmem, 0);
...
mtd_qspi0 = mtd_partition(mtd_qspi, 0, QSPI0_SIZE);...
...
ret = register_mtddriver("/dev/qspi0", mtd_qspi0, 0744, NULL);
...
mtd_qspi1 = mtd_partition(mtd_qspi, QSPI0_SIZE, QSPI1_SIZE);
...
ret = register_mtddriver("/dev/qspi1", mtd_qspi1, 0755, NULL);
ret = nx_mount("/dev/qspi1", "/mnt/qspi1lfs", "littlefs", 0, "autoformat");
etc.

The GD55 driver is using 512 byte simulation, but s512_initialize() 
works just as well.


I can then use mkfatfs to create a FAT FS and mount it and all is good.

mkfats fs is not available to use in bringup code as I understand it 
otherwise I would mount the FS in my bringup too.


On 01/11/2024 02:07, Xiang Xiao wrote:

On Wed, Oct 30, 2024 at 2:00 AM Tim Hardisty 
wrote:


Whilst FAT on a NOR flash may generally be seen a not such a great
idea...please ignore that and confirm if...

...I am right in deducing that I can't simply make a FAT file system on
(say) the third mtd partition (with 512 byte sector emulation)
(partitions 0, 1 and 2 are "raw" data) since FAT will treat the entire
flash devices as a "volume" and so fail to find a partition table at the
bottom end of the flash device?


The partition is different from the file system. A file system can mount on
either a block/mtd device, or a partition. FAT can work only with the block
device, so you can't mount FAT on a flash(mtd) device, only the special
designed file system(e.g. littlefs, smartfs, spiffs) can work with mtd
device directly. The traditional block based file system need FTL(flash
translation layer) to work with mtd device, so you can try dhara if you
really want to use FAT on flash device:
https://github.com/apache/nuttx/blob/master/drivers/mtd/dhara.c

If so, it no doubt explains why I can

format a FAT FS but not mount it.



Which command do you use to format the device or partition?

I could - perhaps should -  re-jig my partitions so partition 0 is used

for FAT, rather than partition 3, but before I do that are there any FAT
FA/NuttX gurus who can let me know if there is a way to do this (and
save me the hassle of reworking my bootstrap and MCUboot locations etc.
for now)?


You can format the device with GPT/MBR partition by:
https://github.com/apache/nuttx-apps/tree/master/fsutils/mkgpt
https://github.com/apache/nuttx-apps/tree/master/fsutils/mkmbr
But, the raw flash device normally doesn't use GPT/MBR partition, instead
hardcode the  partition in the code directly since CPU normally could run
firmware directly on flash devices which normally define a proprietary
partition scheme. For this case, you can use PTABLE/TXTABLE:
https://github.com/apache/nuttx/blob/master/fs/partition/fs_ptable.c
https://github.com/apache/nuttx/blob/master/fs/partition/fs_txtable.c

Re: FAT FS on mtd partition of NOR flash

[Tim Hardisty]

But it’s not really a guide on a specific topic (such as creating a custom 
board). It’s a collection of things that achieve a specific set of 
functionalities for a unique purpose, from which others might get inspiration 
or clues to help them?

> On 31 Oct 2024, at 20:25, Alan C. Assis  wrote:
> 
> You can put it here:
> 
> https://nuttx.apache.org/docs/latest/guides/index.html
> 
> On Thu, Oct 31, 2024 at 4:57 PM Tim Hardisty 
> wrote:
> 
>> Is there a documentation section that might be good for mini case-studies?
>> I can imagine this being a place for a “mini-blog” that are happy to share
>> but don’t have our own blog? Perhaps 100’s of personal blogs is not a good
>> place for information: it should be in one place I think?)
>> 
>>> On 31 Oct 2024, at 19:52, Alan C. Assis  wrote:
>>> 
>>> Hi Nathan,
>>> 
>>> True!
>>> 
>>> And using Flash + Partitions + different FS + MCUBoot + USB MSC is
>>> something that could help other people to implement their solution.
>>> 
>>> BR,
>>> 
>>> Alan
>>> 
>>> On Thu, Oct 31, 2024 at 4:36 PM Nathan Hartman >> 
>>> wrote:
>>> 
>>>> On Thu, Oct 31, 2024 at 2:51 PM Alan C. Assis 
>> wrote:
>>>> 
>>>>> Hi Tim,
>>>>> 
>>>>> It would be nice if you can write down the steps you took, if you have
>> a
>>>>> blog to document it.
>>>> 
>>>> 
>>>> 
>>>> Or put it directly in NuttX's Documentation. It will be helpful for
>> others!
>>>> 
>>>> Maybe a document about "How To Use File Systems" with a section about
>> FAT
>>>> on NOR flash.
>>>> 
>>>> When other developers document other possibilities, over time we will
>>>> accumulate documentation about many combinations of file systems and
>>>> storage technologies.
>>>> 
>>>> Thoughts?
>>>> 
>>>> Cheers
>>>> Nathan
>>>> 
>> 
>> 

Re: FAT FS on mtd partition of NOR flash

[Tim Hardisty]

Is there a documentation section that might be good for mini case-studies? I 
can imagine this being a place for a “mini-blog” that are happy to share but 
don’t have our own blog? Perhaps 100’s of personal blogs is not a good place 
for information: it should be in one place I think?)

> On 31 Oct 2024, at 19:52, Alan C. Assis  wrote:
> 
> Hi Nathan,
> 
> True!
> 
> And using Flash + Partitions + different FS + MCUBoot + USB MSC is
> something that could help other people to implement their solution.
> 
> BR,
> 
> Alan
> 
> On Thu, Oct 31, 2024 at 4:36 PM Nathan Hartman 
> wrote:
> 
>> On Thu, Oct 31, 2024 at 2:51 PM Alan C. Assis  wrote:
>> 
>>> Hi Tim,
>>> 
>>> It would be nice if you can write down the steps you took, if you have a
>>> blog to document it.
>> 
>> 
>> 
>> Or put it directly in NuttX's Documentation. It will be helpful for others!
>> 
>> Maybe a document about "How To Use File Systems" with a section about FAT
>> on NOR flash.
>> 
>> When other developers document other possibilities, over time we will
>> accumulate documentation about many combinations of file systems and
>> storage technologies.
>> 
>> Thoughts?
>> 
>> Cheers
>> Nathan
>> 

Re: FAT FS on mtd partition of NOR flash

[Tim Hardisty]

Totally happy to add to documentation and/or guides. Once I have what I’m doing 
working I can post here again with a summary of what I did - and why - and seek 
suggestions on what would be a guide and what would be better in documentation.

It also looks like the s512_initialize function is deprecated (at least for 
QSPI flash) in favor of 512 byte simulation. I will look through the pulls to 
see when that dates from and perhaps reach out to them, as there doesn’t seem 
to be any documentation on it.

> On 31 Oct 2024, at 19:35, Nathan Hartman  wrote:
> 
> On Thu, Oct 31, 2024 at 2:51 PM Alan C. Assis  wrote:
> 
>> Hi Tim,
>> 
>> It would be nice if you can write down the steps you took, if you have a
>> blog to document it.
> 
> 
> 
> Or put it directly in NuttX's Documentation. It will be helpful for others!
> 
> Maybe a document about "How To Use File Systems" with a section about FAT
> on NOR flash.
> 
> When other developers document other possibilities, over time we will
> accumulate documentation about many combinations of file systems and
> storage technologies.
> 
> Thoughts?
> 
> Cheers
> Nathan

Re: FAT FS on mtd partition of NOR flash

[Tim Hardisty]

Alan - the reasoning was explained earlier in this conversation, but I will 
summarize once I have it 100% working with multiple partitions, USBMSD, MCUboot 
etc.

As an aside I will take a look at other QSPI drivers as they may have the same 
problem as I found with the write status flag (not surprisingly my GD55 driver 
is based on existing code!).


> On 31 Oct 2024, at 18:49, Alan C. Assis  wrote:
> 
> Hi Tim,
> 
> It would be nice if you can write down the steps you took, if you have a
> blog to document it.
> 
> Why do you need a partition with LittleFS and another with FAT with USB
> Mass Storage?
> 
> Do you want to copy the file from computer to board to firmware update or
> just to copy logs and other files from the board?
> 
> Maybe you could consider using USBMTP because it is more reliable, but I
> think we are still missing a userspace part of it.
> I think Xiang Xiao said they will provide it someday, but since nobody ever
> tried to use it or requested it, it never arrived :-)
> 
> BR,
> 
> Alan
> 
> On Thu, Oct 31, 2024 at 3:28 PM Tim Hardisty 
> wrote:
> 
>> I have got this working - the only problem I had was a bug in the QSPI
>> NOR flash driver (GigaDevice GD55 series) I am writing in parallel to
>> allow for what I want.
>> 
>> I missed something in the datasheet whereby if you send >256 bytes in a
>> single write sequence, it will overwrite the first 256 bytes with the
>> later data. The checking of the write-in-progress status bit was outside
>> the sector programming loop. Doh!
>> 
>> For completeness, and to answer the points made:
>> 
>>  * I need to use existing POSIX/NuttX functionality
>>  * I want FAT on a section of my NOR flash. It will get few writes
>>(100's perhaps) for the life of the product and is the perfect fit
>>here to allow USBMTD
>>  * mtd_partition is, as I understand it, just creating character
>>drivers at various offsets in the flash.
>>  * MCUboot - in NuttX at least - wants primary and secondary slots
>>configured as /dev/xxx character drivers - hence me using partitions
>>  * I can create 1, 2, 4 such partitions with no problem, and use
>>character driver methods to read/write to them
>>  * LittleFS does also format on such a partition and works fine
>>  * mkfatfs (now!) creates a FAT file system on my chosen partition
>> 
>> Happy days!
>> 
>> On 30/10/2024 19:43, Tomek CEDRO wrote:
>>> Ugh, mobiles, sorry :-) I meant whole disk at some offset of memory..
>>> and by disk I mean just the "partition" (or whatever you name it) you
>>> want to use as the filesystem storage not necessarily the whole disk
>>> with partitions (not sure why you want to use partitions) :-)
>>> 
>>> I do not know the details but if I had a single memory that would be
>>> shared among different task including having some filesystem I would
>>> just try to create a filesystem at selected memory region (without
>>> partitions) :-)
>>> 
>>> Quick search shows that it should be possible to use LittleFS directly
>>> on a predefined part of memory region. No need to use partitions. You
>>> should be even able to create many filesystems in different parts of
>>> memory if you need more "partitions".
>>> 
>>> 
>> https://devzone.nordicsemi.com/f/nordic-q-a/94606/memory-allocation-for-littlefs-and-running-out-of-space
>>> 
>>> You can say that part of memory is a disk image to be mounted as
>>> filesystem (in a computer nomenclature). You may want to map that part
>>> of memory to a /dev/mem0 and then mount /dev/mem0 in /mnt/storage0. On
>>> FreeBSD for instance I can use any file as disk image with mdconfig
>>> utility that maps the file to /dev/mdN device and then I can use that
>>> device just as an ordinary disk. Another example is RAMFS that enables
>>> given amount of RAM to be mounted as directory to store files with
>>> superior access speed as compared to hard disk. Embedded system should
>>> not even need to create such bloat.. maybe no mapping is even
>>> necessary just provide address and size and use littlefs over there
>>> :-)
>>> 
>>> Hope that helps somehow :-P
>>> Tomek
>>> 
>>> 
>>> On Wed, Oct 30, 2024 at 7:37 PM Tim Hardisty
>> wrote:
>>>> A typo maybe? What do you mean by a “while” disk, please?
>>>> 
>>>>> On 30 Oct 2024, at 18:33, Tomek CEDRO wrote:
>>>>> 
>>>>> how about creating a while disk at memor

Re: FAT FS on mtd partition of NOR flash

[Tim Hardisty]

I have got this working - the only problem I had was a bug in the QSPI 
NOR flash driver (GigaDevice GD55 series) I am writing in parallel to 
allow for what I want.


I missed something in the datasheet whereby if you send >256 bytes in a 
single write sequence, it will overwrite the first 256 bytes with the 
later data. The checking of the write-in-progress status bit was outside 
the sector programming loop. Doh!


For completeness, and to answer the points made:

 * I need to use existing POSIX/NuttX functionality
 * I want FAT on a section of my NOR flash. It will get few writes
   (100's perhaps) for the life of the product and is the perfect fit
   here to allow USBMTD
 * mtd_partition is, as I understand it, just creating character
   drivers at various offsets in the flash.
 * MCUboot - in NuttX at least - wants primary and secondary slots
   configured as /dev/xxx character drivers - hence me using partitions
 * I can create 1, 2, 4 such partitions with no problem, and use
   character driver methods to read/write to them
 * LittleFS does also format on such a partition and works fine
 * mkfatfs (now!) creates a FAT file system on my chosen partition

Happy days!

On 30/10/2024 19:43, Tomek CEDRO wrote:

Ugh, mobiles, sorry :-) I meant whole disk at some offset of memory..
and by disk I mean just the "partition" (or whatever you name it) you
want to use as the filesystem storage not necessarily the whole disk
with partitions (not sure why you want to use partitions) :-)

I do not know the details but if I had a single memory that would be
shared among different task including having some filesystem I would
just try to create a filesystem at selected memory region (without
partitions) :-)

Quick search shows that it should be possible to use LittleFS directly
on a predefined part of memory region. No need to use partitions. You
should be even able to create many filesystems in different parts of
memory if you need more "partitions".

https://devzone.nordicsemi.com/f/nordic-q-a/94606/memory-allocation-for-littlefs-and-running-out-of-space

You can say that part of memory is a disk image to be mounted as
filesystem (in a computer nomenclature). You may want to map that part
of memory to a /dev/mem0 and then mount /dev/mem0 in /mnt/storage0. On
FreeBSD for instance I can use any file as disk image with mdconfig
utility that maps the file to /dev/mdN device and then I can use that
device just as an ordinary disk. Another example is RAMFS that enables
given amount of RAM to be mounted as directory to store files with
superior access speed as compared to hard disk. Embedded system should
not even need to create such bloat.. maybe no mapping is even
necessary just provide address and size and use littlefs over there
:-)

Hope that helps somehow :-P
Tomek


On Wed, Oct 30, 2024 at 7:37 PM Tim Hardisty wrote:

A typo maybe? What do you mean by a “while” disk, please?


On 30 Oct 2024, at 18:33, Tomek CEDRO wrote:

how about creating a while disk at memory offset? :-)

--
CeDeROM, SQ7MHZ,http://www.tomek.cedro.info

On Wed, Oct 30, 2024, 11:58 Tim Hardisty wrote:


Thanks for taking the time to reply. My thinking is undoubtedly flawed - I
think I assumed that carving up a 128Mbyte QSPI NOR flash into a number of
partitions would allow each registered device partition to behave
independently so I could do with them what I wanted. For example:

/dev/qspi0 - bootstrap and MCUboot code (i.e. raw data)
/dev/qspi0 - MCUboot primary slot (also raw data)
/dev/qspi1 - MCUboot secondary slot (also raw data)
/dev/qspi2 - MCUboot scratch area (also raw data)
/dev/qspi3 - FAT partition for USBMSD. This would be a union FS to allow
log files from a different NOR flash running LittleFS to be “seen” by a
host PC and uploaded, as well as a location for users to copy new firmware
to, for firmware upgrades, etc.

The 128Mbyte QSPI is the main boot memory and actually has to have its
AT91 boot loader at address 0 - so I won’t be able to have FAT as partition
0, nor put a MBR or partition table there.

So I think I am stuffed, unless there’s a way of “isolating” a partition
in the way I originally conceived, so that the mount operation genuinely
only looks at the partitioned space.

As you can tell, this is on the fringe of my (very limited)
NuttX/Posix/FAT knowledge!

If this is just not possible, I will revert to plan B and use CDC/NCM with
a NuttX web-server to provide a front end for the user to up and down load
files.


On 29 Oct 2024, at 23:24, Tomek CEDRO wrote:

That depends on what partition schema do you use. If MBR then first
512 bytes are the partition table and the boot code (like on PC),
there is a limit of 4 partitions (that on PC was solved by makind
"extended partition" and then first 512 bytes of that partition
enabled another partitions). GPT for instance does not have this
limitation and it contains backup table at the end of device. Also you
may use MBR disk schema wi

Re: FAT FS on mtd partition of NOR flash

[Tim Hardisty]

A typo maybe? What do you mean by a “while” disk, please?

> On 30 Oct 2024, at 18:33, Tomek CEDRO  wrote:
> 
> how about creating a while disk at memory offset? :-)
> 
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> 
> On Wed, Oct 30, 2024, 11:58 Tim Hardisty  wrote:
> 
>> Thanks for taking the time to reply. My thinking is undoubtedly flawed - I
>> think I assumed that carving up a 128Mbyte QSPI NOR flash into a number of
>> partitions would allow each registered device partition to behave
>> independently so I could do with them what I wanted. For example:
>> 
>> /dev/qspi0 - bootstrap and MCUboot code (i.e. raw data)
>> /dev/qspi0 - MCUboot primary slot (also raw data)
>> /dev/qspi1 - MCUboot secondary slot (also raw data)
>> /dev/qspi2 - MCUboot scratch area (also raw data)
>> /dev/qspi3 - FAT partition for USBMSD. This would be a union FS to allow
>> log files from a different NOR flash running LittleFS to be “seen” by a
>> host PC and uploaded, as well as a location for users to copy new firmware
>> to, for firmware upgrades, etc.
>> 
>> The 128Mbyte QSPI is the main boot memory and actually has to have its
>> AT91 boot loader at address 0 - so I won’t be able to have FAT as partition
>> 0, nor put a MBR or partition table there.
>> 
>> So I think I am stuffed, unless there’s a way of “isolating” a partition
>> in the way I originally conceived, so that the mount operation genuinely
>> only looks at the partitioned space.
>> 
>> As you can tell, this is on the fringe of my (very limited)
>> NuttX/Posix/FAT knowledge!
>> 
>> If this is just not possible, I will revert to plan B and use CDC/NCM with
>> a NuttX web-server to provide a front end for the user to up and down load
>> files.
>> 
>>> On 29 Oct 2024, at 23:24, Tomek CEDRO  wrote:
>>> 
>>> That depends on what partition schema do you use. If MBR then first
>>> 512 bytes are the partition table and the boot code (like on PC),
>>> there is a limit of 4 partitions (that on PC was solved by makind
>>> "extended partition" and then first 512 bytes of that partition
>>> enabled another partitions). GPT for instance does not have this
>>> limitation and it contains backup table at the end of device. Also you
>>> may use MBR disk schema with no partitions that is pretty common with
>>> some unformatted pendrives and simple USB MSC emulation on tiny MCUs
>>> with USB device.
>>> 
>>> Also FAT does not seem perfect solution for embedded storage because
>>> of 1 possible data corruption on power loss and 2 memory wear leveling
>>> because some locations are used far more often than the others (i.e.
>>> atime that can be disabled). There are other filesystems designed with
>>> embedded application by design :-)
>>> 
>>> Are you sure that partition table is okay and you are formatting /
>>> mounting the correct partition? :-)
>>> 
>>> Tomek
>>> 
>>> 
>>> On Tue, Oct 29, 2024 at 7:00 PM Tim Hardisty 
>> wrote:
>>>> 
>>>> Whilst FAT on a NOR flash may generally be seen a not such a great
>>>> idea...please ignore that and confirm if...
>>>> 
>>>> ...I am right in deducing that I can't simply make a FAT file system on
>>>> (say) the third mtd partition (with 512 byte sector emulation)
>>>> (partitions 0, 1 and 2 are "raw" data) since FAT will treat the entire
>>>> flash devices as a "volume" and so fail to find a partition table at the
>>>> bottom end of the flash device? If so, it no doubt explains why I can
>>>> format a FAT FS but not mount it.
>>>> 
>>>> I could - perhaps should -  re-jig my partitions so partition 0 is used
>>>> for FAT, rather than partition 3, but before I do that are there any FAT
>>>> FA/NuttX gurus who can let me know if there is a way to do this (and
>>>> save me the hassle of reworking my bootstrap and MCUboot locations etc.
>>>> for now)?
>>>> 
>>> 
>>> 
>>> --
>>> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>> 
>> 

Re: FAT FS on mtd partition of NOR flash

[Tim Hardisty]

Thanks for taking the time to reply. My thinking is undoubtedly flawed - I 
think I assumed that carving up a 128Mbyte QSPI NOR flash into a number of 
partitions would allow each registered device partition to behave independently 
so I could do with them what I wanted. For example:

/dev/qspi0 - bootstrap and MCUboot code (i.e. raw data)
/dev/qspi0 - MCUboot primary slot (also raw data)
/dev/qspi1 - MCUboot secondary slot (also raw data)
/dev/qspi2 - MCUboot scratch area (also raw data)
/dev/qspi3 - FAT partition for USBMSD. This would be a union FS to allow log 
files from a different NOR flash running LittleFS to be “seen” by a host PC and 
uploaded, as well as a location for users to copy new firmware to, for firmware 
upgrades, etc.

The 128Mbyte QSPI is the main boot memory and actually has to have its AT91 
boot loader at address 0 - so I won’t be able to have FAT as partition 0, nor 
put a MBR or partition table there.

So I think I am stuffed, unless there’s a way of “isolating” a partition in the 
way I originally conceived, so that the mount operation genuinely only looks at 
the partitioned space.

As you can tell, this is on the fringe of my (very limited) NuttX/Posix/FAT 
knowledge!

If this is just not possible, I will revert to plan B and use CDC/NCM with a 
NuttX web-server to provide a front end for the user to up and down load files.

> On 29 Oct 2024, at 23:24, Tomek CEDRO  wrote:
> 
> That depends on what partition schema do you use. If MBR then first
> 512 bytes are the partition table and the boot code (like on PC),
> there is a limit of 4 partitions (that on PC was solved by makind
> "extended partition" and then first 512 bytes of that partition
> enabled another partitions). GPT for instance does not have this
> limitation and it contains backup table at the end of device. Also you
> may use MBR disk schema with no partitions that is pretty common with
> some unformatted pendrives and simple USB MSC emulation on tiny MCUs
> with USB device.
> 
> Also FAT does not seem perfect solution for embedded storage because
> of 1 possible data corruption on power loss and 2 memory wear leveling
> because some locations are used far more often than the others (i.e.
> atime that can be disabled). There are other filesystems designed with
> embedded application by design :-)
> 
> Are you sure that partition table is okay and you are formatting /
> mounting the correct partition? :-)
> 
> Tomek
> 
> 
> On Tue, Oct 29, 2024 at 7:00 PM Tim Hardisty  wrote:
>> 
>> Whilst FAT on a NOR flash may generally be seen a not such a great
>> idea...please ignore that and confirm if...
>> 
>> ...I am right in deducing that I can't simply make a FAT file system on
>> (say) the third mtd partition (with 512 byte sector emulation)
>> (partitions 0, 1 and 2 are "raw" data) since FAT will treat the entire
>> flash devices as a "volume" and so fail to find a partition table at the
>> bottom end of the flash device? If so, it no doubt explains why I can
>> format a FAT FS but not mount it.
>> 
>> I could - perhaps should -  re-jig my partitions so partition 0 is used
>> for FAT, rather than partition 3, but before I do that are there any FAT
>> FA/NuttX gurus who can let me know if there is a way to do this (and
>> save me the hassle of reworking my bootstrap and MCUboot locations etc.
>> for now)?
>> 
> 
> 
> -- 
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

FAT FS on mtd partition of NOR flash

[Tim Hardisty]

Whilst FAT on a NOR flash may generally be seen a not such a great 
idea...please ignore that and confirm if...


...I am right in deducing that I can't simply make a FAT file system on 
(say) the third mtd partition (with 512 byte sector emulation) 
(partitions 0, 1 and 2 are "raw" data) since FAT will treat the entire 
flash devices as a "volume" and so fail to find a partition table at the 
bottom end of the flash device? If so, it no doubt explains why I can 
format a FAT FS but not mount it.


I could - perhaps should -  re-jig my partitions so partition 0 is used 
for FAT, rather than partition 3, but before I do that are there any FAT 
FA/NuttX gurus who can let me know if there is a way to do this (and 
save me the hassle of reworking my bootstrap and MCUboot locations etc. 
for now)?

Re: Power safe file systems for NuttX

[Tim Hardisty]

GigaDevice GD55 NOR flash, up to 4Gbit. I use a 1Gbit variant and am just 
writing the driver for it.

Would expect LittleFS will work on it, and I can try it once driver is working, 
next week hopefully.

> On 18 Oct 2024, at 15:19, Matteo Golin  wrote:
> 
> Hello everyone,
> 
> Matteo from InSpace again with more questions.
> 
> We are currently in the process of selecting some non-volatile memory for our 
> telemetry system so that we can log our
> flight data while our rocket is in the air. We're having some trouble 
> settling on an option because of a few uncommonly
> encountered events that happen in our rocket.
> 
> Typically our rockets hit around Mach 1.8 and they can experience a ton of 
> vibrations while in the air. To circumvent
> any write interruptions, we wanted to use flash memory that can be soldered 
> directly to the board. Unfortunately the NOR
> flash packages we've found are pretty small in terms of capacity, and it 
> appears from our research that NuttX's support
> for NAND flash has not been tested on real hardware yet, only simulated NAND 
> memory.
> 
> The goal was to have some kind of very reliably connected (soldered) non 
> volatile memory for in-flight logging, and then
> copy all the logs to the SD card upon landing for easy removal and placement 
> into a laptop, etc.
> 
> We've now found a microSD card slot which locks in the card so that it 
> doesn't easily lose connection during vibration
> (though still not perfect). I am wondering if it may be possible to just log 
> directly to the SD card to avoid having to
> consider another type of memory. The SD card is also quite cheap memory.
> 
> For this setup, I would want to have two equal partitions on the SD card 
> (which would be around 32GB in total
> capacity). One partition a FAT file system, and one a power-safe file system. 
> The power safe partition would be used for
> logging in flight to avoid corruption on power loss/discontinuity, and the 
> FAT file system would be copied to upon
> landing so that data is easily accessible from a laptop.
> 
> I'm not sure if this is possible within NuttX as I'm not familiar with how 
> the OS handles SD card/memory partitions. In
> addition, I was hoping to use littlefs for the power-safe file system but I 
> am not sure that it works with SD devices.
> I've found evidence online of some people using it with SD cards, but not 
> sure about how that may interact with using it
> through NuttX.
> 
> If anyone has used littlefs on an SD card, or knows of a different power-safe 
> file system we could use (I couldn't find
> any in the file system listings) that would be great. Or if there are any 
> suggestions for memory options (we're still
> investigating) supported by NuttX that could contain at least around 200MB of 
> data.
> 
> Thank you,
> Matteo
> 

UnionFS: >2 bindings?

[Tim Hardisty]

I am looking at a way to expose 3x on-board MTD NOR flash and an EEPROM device 
(2 formatted with LittleFS and the larger NOR flash probably with FAT) to users 
so they can download log files, upload new firmware for MCUboot to use, or 
customization files etc.

This will probably be via USBMSD (hence FAT being a likely choice for the third 
system, especially as it will have MUCH fewer erases needed over the lifetime 
of the product) and/or via a device-hosted web server over CDC/NCM.

I’m thinking a UnionFS is possibly a way to do this but the relevant fs driver 
is hard-coded to only allow 2 bindings and I would need 3.

Before I look at embarking on expanding that to be a few more:

a) Is my idea sound or is there a better/easier POSIX/NuttX approach to this?
b) If sound, is there a fundamental problem with expanding what we have to 
allow for 3 or 4 - or even a Kconfig-set “n” bindings -  other than the hours 
needed to achieve it!?

Thanks!!

Re: NuttX "gadget": resolve its host name via CDC/NCM connection

[Tim Hardisty]

Yes - my initial research suggests mDNS and Bonjour/Avahi are essentially- if 
not actually - the same. I’m sure there’s some code out there, hopefully good 
enough - and lacking license restrictions - so if I get it working I’ll submit 
a PR.

I have my “gadget” acting as DHCP and web servers now, and can plug USB into 
Linux or Windows and get “no messing about by the user” browsing but only by IP 
address at the moment.

Playing around with USB MSD as a parallel activity and, as per usual, it plays 
with Linux out of the NuttX box but not Windows. Sigh.

> On 9 Oct 2024, at 18:49, Nathan Hartman  wrote:
> 
> Isn't there Bonjour/Avahi that can make something like this work on a
> local network, at least when accessed from a computer that supports
> Bonjour/Avahi? I think this is how printers are automatically
> discovered on a network.
> 
> On Wed, Oct 9, 2024 at 9:02 AM Tim Hardisty  wrote:
>> 
>> Yes - I think mDNS might be a good way so I am looking at this. If I get
>> it working can work on a PR to add such a thing as a NETUTIL and/or
>> example :-)
>> 
>> “http://gadget.local <http://gadget.local/>" is fine and (probably) correct 
>> anyway.
>> 
>> On 09/10/2024 07:34, David Alessio wrote:
>>>> On Oct 8, 2024, at 12:56 PM, Tim Hardisty wrote:
>>>> 
>>>> Not a NuttX question, as such, more a basic embedded device networking 
>>>> question. But you’re all so helpful, and it’s NuttX things I need to do 
>>>> this :-)
>>>> 
>>>> I have just tried the recently added CDC/NCM USB networking and it works 
>>>> very nicely. Coupled with DHCPD, I can have a PC (Windows or Linux; not 
>>>> tried MAC yet) get an IP address and immediately I can exchange data 
>>>> (well…ping between them). And I have set a hostname for my NuttX “gadget” 
>>>> and uname reports it properly.
>>>> 
>>>> My intention is to implement a simple web server on the device so as to be 
>>>> able to plug in to it via usb, go to a browser, and go to “http://gadget” 
>>>> rather than “http://10.0.0.10” (for example).
>>>> 
>>>> This is DNS…but my embedded networking knowledge is limited and I am not 
>>>> sure what NuttX tools/daemons/examples/whatever I need to use for this?
>>>> 
>>>> I don’t think a hosts file on the gadget is right, as the PC can’t use 
>>>> that to match hostname to IP (and editing a hosts file on the PC is not an 
>>>> option in this case). So probably the gadget needs to also be a DNS 
>>>> server? But I can’t find much information on how to use the NuttX 
>>>> implementation of this.
>>>> 
>>>> Have I got that right or am I missing something?
>>>> 
>>>> Happy to repay “information that leads to a successful prosecution” ;-) by 
>>>> adding to the NuttX “How To” documentation if appropriate
>>>> 
>>>> Thanks,
>>>> 
>>>> TimJTi.
>>> The first thought that comes to my mind is to run an mDNS responder on the 
>>> NuttX side.  Its hostname will need to be “gadget”.  You may need to settle 
>>> for “http://gadget.local <http://gadget.local/>"

Re: NuttX "gadget": resolve its host name via CDC/NCM connection

[Tim Hardisty]

Thanks for the suggestion - every day's a learning day so more bedtime 
reading :-)


On 09/10/2024 13:39, Marco Casaroli wrote:

Why not just write a DNS-SD daemon that will send some URP packets and then
the peers can resolve the hostname?

http://www.dns-sd.org


On Wed, 9 Oct 2024 at 02:04, Tim Hardisty wrote:


Not a NuttX question, as such, more a basic embedded device networking
question. But you’re all so helpful, and it’s NuttX things I need to do
this :-)

I have just tried the recently added CDC/NCM USB networking and it works
very nicely. Coupled with DHCPD, I can have a PC (Windows or Linux; not
tried MAC yet) get an IP address and immediately I can exchange data
(well…ping between them). And I have set a hostname for my NuttX “gadget”
and uname reports it properly.

My intention is to implement a simple web server on the device so as to be
able to plug in to it via usb, go to a browser, and go to “http://gadget”
rather than “http://10.0.0.10” (for example).

This is DNS…but my embedded networking knowledge is limited and I am not
sure what NuttX tools/daemons/examples/whatever I need to use for this?

I don’t think a hosts file on the gadget is right, as the PC can’t use
that to match hostname to IP (and editing a hosts file on the PC is not an
option in this case). So probably the gadget needs to also be a DNS server?
But I can’t find much information on how to use the NuttX implementation of
this.

Have I got that right or am I missing something?

Happy to repay “information that leads to a successful prosecution” ;-) by
adding to the NuttX “How To” documentation if appropriate

Thanks,

TimJTi.

Re: NuttX "gadget": resolve its host name via CDC/NCM connection

[Tim Hardisty]

Yes - I think mDNS might be a good way so I am looking at this. If I get 
it working can work on a PR to add such a thing as a NETUTIL and/or 
example :-)


“http://gadget.local <http://gadget.local/>" is fine and (probably) correct 
anyway.

On 09/10/2024 07:34, David Alessio wrote:

On Oct 8, 2024, at 12:56 PM, Tim Hardisty wrote:

Not a NuttX question, as such, more a basic embedded device networking 
question. But you’re all so helpful, and it’s NuttX things I need to do this :-)

I have just tried the recently added CDC/NCM USB networking and it works very 
nicely. Coupled with DHCPD, I can have a PC (Windows or Linux; not tried MAC 
yet) get an IP address and immediately I can exchange data (well…ping between 
them). And I have set a hostname for my NuttX “gadget” and uname reports it 
properly.

My intention is to implement a simple web server on the device so as to be able 
to plug in to it via usb, go to a browser, and go to “http://gadget” rather 
than “http://10.0.0.10” (for example).

This is DNS…but my embedded networking knowledge is limited and I am not sure 
what NuttX tools/daemons/examples/whatever I need to use for this?

I don’t think a hosts file on the gadget is right, as the PC can’t use that to 
match hostname to IP (and editing a hosts file on the PC is not an option in 
this case). So probably the gadget needs to also be a DNS server? But I can’t 
find much information on how to use the NuttX implementation of this.

Have I got that right or am I missing something?

Happy to repay “information that leads to a successful prosecution” ;-) by 
adding to the NuttX “How To” documentation if appropriate

Thanks,

TimJTi.

The first thought that comes to my mind is to run an mDNS responder on the NuttX side.  
Its hostname will need to be “gadget”.  You may need to settle for “http://gadget.local 
<http://gadget.local/>"

Re: NuttX "gadget": resolve its host name via CDC/NCM connection

[Tim Hardisty]

I am already using dhcpd and it successfully allocates an IP address to 
the Host PC connected over CDC/NCM - I can ping in both directions 
successfully. I should therefore be able to use (something like) the 
webserver example and server pages by using a URL such as 
http://10.0.0.2 - I am trying this out now.


Being able to browse to "http://gadget"; or "http://gadget.local"; would 
be nicer so I am looking an mDNS etc.


On 09/10/2024 12:58, spudaneco wrote:

There is this that I wrotw many years 
ago:https://github.com/apache/nuttx-apps/tree/master/netutils/dhcpd



Sent from my Galaxy
 Original message From:michal.lyszc...@bofc.pl Date: 10/8/24  11:01 PM  (GMT-06:00) To:dev@nuttx.apache.org Subject: 
Re: NuttX "gadget": resolve its host name via CDC/NCM connection On 2024-10-08 20:56:00, Tim Hardisty wrote:> My intention 
is to implement a simple web server on the device so as to be> able to plug in to it via usb, go to a browser, and go to 
“http://gadget”> rather than “http://10.0.0.10” (for example).> > This is DNS…but my embedded networking knowledge is limited 
and I am not> sure what NuttX tools/daemons/examples/whatever I need to use for this? > > I don’t think a hosts file on the 
gadget is right, as the PC can’t use> that to match hostname to IP (and editing a hosts file on the PC is not an> option in this 
case). So probably the gadget needs to also be a DNS> server? But I can’t find much information on how to use the NuttX> 
implementation of this.> > Have I got that right or am I missing something?The thing you want to do, while possible is not really 
feasable. Yes, youmust host DNS server on nuttx. I don't think there is anything ready to go,embedded devices usually do not act as a 
DNS. Then you would have to pushDNS server to the host via DHCP. Problem is, that now you will overwrite DNSaddress on your host pc and 
you won't be able to resolve anything else otherthan what your nuttx 'gadget' device can. You could forward requests toexternal DNS, 
but that again requires nuttx to have internet. So DHCP/DNS onnuttx is not really good option.Having it reversed (DHCP/DNS on host pc) 
could probably solve the problem withsome upnp magic. But that will require user to have upnp or some kind ofzeroconf enabled on host 
pc as well.To my knowledge it's not possible to do what you want in portable manner.You can try some hacks, but the will not work for 
anyone - hence I would notrecommend them.I have never ever met a embedded device that would do what you describe.It's always via IP 
address. So do what others do, and allow access viaIP address only. That's the only portable way that I know of.-- 
.-.---.--.-.| Michal Lyszczek | Embedded C, Linux |   Company 
Address    |  .-. opensource || +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 |  oo|  supporter ||https://bofc.pl 
`.--: Brzezinka Sredzka PL | /`'\  & || GPG FF1EBFE7E3A974B1 | Bits of Code | NIP:   813 349 58 78 |(\_;/) 
programer |`--^--^--^-'

NuttX "gadget": resolve its host name via CDC/NCM connection

[Tim Hardisty]

Not a NuttX question, as such, more a basic embedded device networking 
question. But you’re all so helpful, and it’s NuttX things I need to do this :-)

I have just tried the recently added CDC/NCM USB networking and it works very 
nicely. Coupled with DHCPD, I can have a PC (Windows or Linux; not tried MAC 
yet) get an IP address and immediately I can exchange data (well…ping between 
them). And I have set a hostname for my NuttX “gadget” and uname reports it 
properly.

My intention is to implement a simple web server on the device so as to be able 
to plug in to it via usb, go to a browser, and go to “http://gadget” rather 
than “http://10.0.0.10” (for example).

This is DNS…but my embedded networking knowledge is limited and I am not sure 
what NuttX tools/daemons/examples/whatever I need to use for this? 

I don’t think a hosts file on the gadget is right, as the PC can’t use that to 
match hostname to IP (and editing a hosts file on the PC is not an option in 
this case). So probably the gadget needs to also be a DNS server? But I can’t 
find much information on how to use the NuttX implementation of this.

Have I got that right or am I missing something?

Happy to repay “information that leads to a successful prosecution” ;-) by 
adding to the NuttX “How To” documentation if appropriate

Thanks,

TimJTi.

Re: [VOTE] Apache NuttX 12.7.0 RC0 release

[Tim Hardisty]

Hi.

It was because the NuttX framebuffer driver *in LVGL* rendered directly 
to the NuttX /dev/fb0 device, causing tearing issues and artefacts. It 
should have had a second buffer that LVGL rendered to rather than direct 
to the device driver's framebuffer memory.


I raised a nuttx-apps issue here : 
https://github.com/apache/nuttx-apps/issues/2416


and cross-referenced here: https://github.com/apache/nuttx-apps/issues/2461

The final fix, in LVGL, was here:

https://github.com/lvgl/lvgl/pull/6580

I also had a brief discussion here about it when I was trying to 
understand the issues:


https://www.mail-archive.com/dev@nuttx.apache.org/msg11509.html

I never had any issues with the framebuffer example app though.

Sneak preview that I'm happy to share only here for now - as the product 
is still a few weeks away from launch - of what I'm doing; it works with 
NuttX (master) and LVGL 9.2. The file linked to is an MP4 shared from my 
own NAS so hopefully the link works.


http://gofile.me/2MJqt/dBf6BZgKj


Regards,

Tim.

On 07/10/2024 14:23, Tomek CEDRO wrote:

Thank you Tim could you please pinpoint the issue with LCD / FB? Anyone
with that hardware help is more than welcome!! It would be great to have
graphics working + new lvgl in upcoming release :-)

I would go:
1. test on older release known to work. just to confirm working hardware.
2. try some really basic application that draws red rectangle on red
background (something like that) just to confirm working lcd / spi / fb.
can use nxwidgets if lvgl broken.
3. review / change configuration parameters to see if this is the problem.
4. try git bisect between master head and known working configuration to
find what introduced the problem.

Thank you!! :-)

--
CeDeROM, SQ7MHZ,http://www.tomek.cedro.info

On Mon, Oct 7, 2024, 14:37 Tim Hardisty wrote:


FYI, I tried RC0 on my SAMA5D2 custom board with no issues. My app and
LVGL demos (with LVGL V9.1 - with known issues - and V9.2) run OK as
does the FB example app, so I would think any issues are possibly
arch-specific rather than 100% down to LVGL.

I did try OSTEST but I gave up waiting for it to complete to try 
- I have never run it before so I have no idea how long it would be
expected to run for before completion!

On 07/10/2024 08:15, Alin Jerpelea wrote:

Hi all,

the voting is closed

We will fix the bugs and start the RC1 test and vote process

Please link fixes to this thread

Best regards
Alin

On Mon, 7 Oct 2024, 09:12 raiden00pl, wrote:


I fully agree with Tomek. If possible, let's delay the release for a

while

and fix what's broken, or at least find the broken

configurations/features.

What I have tested so far:
- [X] sim/foc - fixed
- [X] sim/smp - **broken**
- [X] sim/nsh - OK
- [X] sim/crypto - OK
- [X] sim/elf - OK
- [X] sim/fb - OK
- [X] sim/lvgl_fb - OK

- [X] nrf52840-dk/adc - OK
- [X] nrf52840-dk/pwm - OK
- [X] nrf52840-dk/highpri - **boken**
other highpri examples also broken
- [X] nrf52840-dk/sdc_nimble - OK
- [X] nrf52840-dk/sdc - OK
- [X] nrf52840-dk/composite - OK
- [X] nrf52840-dk/timer - fixed
- [X] nrf52840-dk/tickelss - OK
- [X] nrf52840-dk/qspi - OK

- [X] stm32f4disco/nsh - OK
- [X] stm32f4disco/elf - OK
- [X] stm32f4disco/module - OK
- [X] stm32f4disco/usbnsh - OK

- [X] stm32g071b-disco/oled - fixed

- [X] stm32f746g-disco/nsh - OK
- [X] stm32f746g-disco/fb - *broken* (not related to LVGL)
- [X] stm32f746g-disco/nxdemo - *broken* (not related to LVGL)
- [X] stm32f746g-disco/audio - OK

What else I want to test:
stm32h7 AMP, nrf53, nrf91, x86_64, some CAN examples, maybe FOC on real
hardware, maybe IEEE802.15.4 on nrf52.
But I don't know how much patience I'll have, it's a completely boring

job.

pon., 7 paź 2024 o 01:20 Tomek CEDRO napisał(a):


Please lets wait for LVGL 9.2.1 release, we have patches ready to get
in sync, this is quite important and demanded feature to land in a
release, and I am sure this will attract new users/developers to the
NuttX community because this will be also announced to the broad LVGL
community :-)

Also we should fix ESP32 bootloader / esptool building unusable
firmware image, this platform is too popular to have this kind of
problem.

If anyone has a free moment to verify in depth the memory leak that
would be also very good to know why that happens - is it ostest
problem or nsh / os problem coming from recent updates?

I know Alin the release process is time consuming and cost you lots of
effort, and additional problems cost you additional work time, we all
much appreciate that!! <3 :-)

Release quality is far more important than quantity, its not only
about bumping numbers. I know from other projects that rushing the
release with known problems behind may be strongly discouraging and
pushes people away from a project. We all want to create a reliable
solution that works out of the box with no surprises right? :-)

Have a good day folks :-)
Tomek


On Sat, Oct 5, 2024 at 1

Re: [VOTE] Apache NuttX 12.7.0 RC0 release

[Tim Hardisty]

FYI, I tried RC0 on my SAMA5D2 custom board with no issues. My app and 
LVGL demos (with LVGL V9.1 - with known issues - and V9.2) run OK as 
does the FB example app, so I would think any issues are possibly 
arch-specific rather than 100% down to LVGL.


I did try OSTEST but I gave up waiting for it to complete to try  
- I have never run it before so I have no idea how long it would be 
expected to run for before completion!


On 07/10/2024 08:15, Alin Jerpelea wrote:

Hi all,

the voting is closed

We will fix the bugs and start the RC1 test and vote process

Please link fixes to this thread

Best regards
Alin

On Mon, 7 Oct 2024, 09:12 raiden00pl,  wrote:


I fully agree with Tomek. If possible, let's delay the release for a while
and fix what's broken, or at least find the broken configurations/features.

What I have tested so far:
- [X] sim/foc - fixed
- [X] sim/smp - **broken**
- [X] sim/nsh - OK
- [X] sim/crypto - OK
- [X] sim/elf - OK
- [X] sim/fb - OK
- [X] sim/lvgl_fb - OK

- [X] nrf52840-dk/adc - OK
- [X] nrf52840-dk/pwm - OK
- [X] nrf52840-dk/highpri - **boken**
   other highpri examples also broken
- [X] nrf52840-dk/sdc_nimble - OK
- [X] nrf52840-dk/sdc - OK
- [X] nrf52840-dk/composite - OK
- [X] nrf52840-dk/timer - fixed
- [X] nrf52840-dk/tickelss - OK
- [X] nrf52840-dk/qspi - OK

- [X] stm32f4disco/nsh - OK
- [X] stm32f4disco/elf - OK
- [X] stm32f4disco/module - OK
- [X] stm32f4disco/usbnsh - OK

- [X] stm32g071b-disco/oled - fixed

- [X] stm32f746g-disco/nsh - OK
- [X] stm32f746g-disco/fb - *broken* (not related to LVGL)
- [X] stm32f746g-disco/nxdemo - *broken* (not related to LVGL)
- [X] stm32f746g-disco/audio - OK

What else I want to test:
stm32h7 AMP, nrf53, nrf91, x86_64, some CAN examples, maybe FOC on real
hardware, maybe IEEE802.15.4 on nrf52.
But I don't know how much patience I'll have, it's a completely boring job.

pon., 7 paź 2024 o 01:20 Tomek CEDRO  napisał(a):


Please lets wait for LVGL 9.2.1 release, we have patches ready to get
in sync, this is quite important and demanded feature to land in a
release, and I am sure this will attract new users/developers to the
NuttX community because this will be also announced to the broad LVGL
community :-)

Also we should fix ESP32 bootloader / esptool building unusable
firmware image, this platform is too popular to have this kind of
problem.

If anyone has a free moment to verify in depth the memory leak that
would be also very good to know why that happens - is it ostest
problem or nsh / os problem coming from recent updates?

I know Alin the release process is time consuming and cost you lots of
effort, and additional problems cost you additional work time, we all
much appreciate that!! <3 :-)

Release quality is far more important than quantity, its not only
about bumping numbers. I know from other projects that rushing the
release with known problems behind may be strongly discouraging and
pushes people away from a project. We all want to create a reliable
solution that works out of the box with no surprises right? :-)

Have a good day folks :-)
Tomek


On Sat, Oct 5, 2024 at 11:11 AM Tim Hardisty 
wrote:

FYI you can no longer change LVGL version from Kconfig AFAIK, but you

can force the use of any version you want by checking out the version you
want from the LVGL repo but have to do a manual copy of the LVGL K config
into the NuttX Apps LVGL Kconfig. It’s a bit messy but works!



On 5 Oct 2024, at 10:56, Alin Jerpelea  wrote:

@Tim and Tomek

My bad ! We are using 9.1.0 for 12.7.0 release
I was looking on an older branch . A simple PR will fix it after LVGL

is

release

Best regards
Alin



On Sat, Oct 5, 2024 at 10:52 AM Tim Hardisty <

timhardist...@gmail.com

wrote:

12.7 should be using LVGL 9.1. 9.1 has a specific frame buffer

problem

fixed in 9.2.

I have a custom SAMA5D2 board with an LCD running NuttX master and

LVGL

9.2 and I will try the RC on Monday.


On 5 Oct 2024, at 10:33, Alin Jerpelea 

wrote:

Hi Tomek,
Thanks for testing and providing feedback.

1. There are memory leak problems reported
This is something that we should test on more boards

2. There are LVGL screen problems reported.
NuttX 12.7 uses LVGL 8.3.3 by default but this can be changed in

the

menu

config LVGL_VERSION
string "LVGL Version"
default "8.3.3"

3.I have found a problem on ESP32 with esptool version 4.7
Can be updated locally or we can include it in RC1 and restart the

vote

Considering that we have known bugs in the release that affect some

boards

we have 2 options:
1) we can stop the release and delay it for an unknown amount of

time

until

the bugs are fixed (in some cases for external projects)
2) we can release and specify what are the known bugs

https://cwiki.apache.org/confluence/display/NUTTX/NuttX+12.7.0

I would like to propose the second option


On Sat, Oct 5, 2024 at 2:00 AM Tomek CEDRO 

wrote:

Hello world :-)

There goes -1 from me, sorry :-P :-P

Re: [VOTE] Apache NuttX 12.7.0 RC0 release

[Tim Hardisty]

FYI you can no longer change LVGL version from Kconfig AFAIK, but you can force 
the use of any version you want by checking out the version you want from the 
LVGL repo but have to do a manual copy of the LVGL K config into the NuttX Apps 
LVGL Kconfig. It’s a bit messy but works!


> On 5 Oct 2024, at 10:56, Alin Jerpelea  wrote:
> 
> @Tim and Tomek
> 
> My bad ! We are using 9.1.0 for 12.7.0 release
> I was looking on an older branch . A simple PR will fix it after LVGL is
> release
> 
> Best regards
> Alin
> 
> 
>> On Sat, Oct 5, 2024 at 10:52 AM Tim Hardisty 
>> wrote:
>> 
>> 12.7 should be using LVGL 9.1. 9.1 has a specific frame buffer problem
>> fixed in 9.2.
>> 
>> I have a custom SAMA5D2 board with an LCD running NuttX master and LVGL
>> 9.2 and I will try the RC on Monday.
>> 
>>>> On 5 Oct 2024, at 10:33, Alin Jerpelea  wrote:
>>> 
>>> Hi Tomek,
>>> Thanks for testing and providing feedback.
>>> 
>>> 1. There are memory leak problems reported
>>> This is something that we should test on more boards
>>> 
>>> 2. There are LVGL screen problems reported.
>>> NuttX 12.7 uses LVGL 8.3.3 by default but this can be changed in the menu
>>> 
>>> config LVGL_VERSION
>>> string "LVGL Version"
>>> default "8.3.3"
>>> 
>>> 3.I have found a problem on ESP32 with esptool version 4.7
>>> Can be updated locally or we can include it in RC1 and restart the vote
>>> 
>>> Considering that we have known bugs in the release that affect some
>> boards
>>> we have 2 options:
>>> 1) we can stop the release and delay it for an unknown amount of time
>> until
>>> the bugs are fixed (in some cases for external projects)
>>> 2) we can release and specify what are the known bugs
>>> 
>>> https://cwiki.apache.org/confluence/display/NUTTX/NuttX+12.7.0
>>> 
>>> I would like to propose the second option
>>> 
>>>> On Sat, Oct 5, 2024 at 2:00 AM Tomek CEDRO  wrote:
>>>> 
>>>> Hello world :-)
>>>> 
>>>> There goes -1 from me, sorry :-P :-P
>>>> 
>>>> 1. There are memory leak problems reported that I tried to confirm on
>>>> STM32F769. Is it ostest problem only or more general memory management
>>>> issue?
>>>> 
>>>> before ostest total/used: 483056 / 10112.
>>>> after ostest total/used: 483056 / 10200.
>>>> 
>>>> 2. There are LVGL screen problems reported. This may be solved with
>>>> LVGL 9.2.1 release that should show up within days and its inclusion
>>>> is in the PRs. Or we have display driver to fix. I would also
>>>> recommend testing with previous NuttX releases on the same hardware to
>>>> confirm the possible regression. Gabor is very keen to NuttX and it
>>>> would be really nice to show working demo of LVGL 9.2.1 on 12.7.0 also
>>>> to attract newcomers to the project.
>>>> 
>>>> https://github.com/apache/nuttx/issues/13825
>>>> https://github.com/lvgl/lvgl/pull/6981
>>>> 
>>>> 3. I have found a problem on ESP32 with esptool version 4.7 that
>>>> produces faulty unusable firmware with no warning / error. I found a
>>>> commit that bumps esptool to 4.8 in order to build on CI with new
>>>> bootloader from ESP IDF. Otherwise I would not know why it does not
>>>> run. But we should handle this situation with error message and/or use
>>>> older bootloader with 4.7 (?) otherwise people may get discouraged at
>>>> first contact with NuttX.
>>>> 
>>>> https://github.com/apache/nuttx/issues/13824
>>>> 
>>>> 
>>>> If there is any reason the 12.7.0 really should be released right now
>>>> for some serious reason I can change my vote to 0 not to block the
>>>> release. Otherwise we should focus on fixing those 3 discovered issues
>>>> in order to provide high quality no-surprises release :-)
>>>> 
>>>> 
>>>> Here returns the subject of distributed testing farms so we could test
>>>> NuttX builds locally on a real hardware that we have at hand. I
>>>> started building one. But we also need some scripts that will make
>>>> this task easy to setup by everyone interested in a repeatable way.
>>>> This is a separate discussion already taking place on dev@.
>>>> 
>>>> 
>>>> I have contacte

Re: [VOTE] Apache NuttX 12.7.0 RC0 release

[Tim Hardisty]

12.7 should be using LVGL 9.1. 9.1 has a specific frame buffer problem fixed in 
9.2.

I have a custom SAMA5D2 board with an LCD running NuttX master and LVGL 9.2 and 
I will try the RC on Monday.

> On 5 Oct 2024, at 10:33, Alin Jerpelea  wrote:
> 
> Hi Tomek,
> Thanks for testing and providing feedback.
> 
> 1. There are memory leak problems reported
> This is something that we should test on more boards
> 
> 2. There are LVGL screen problems reported.
> NuttX 12.7 uses LVGL 8.3.3 by default but this can be changed in the menu
> 
> config LVGL_VERSION
> string "LVGL Version"
> default "8.3.3"
> 
> 3.I have found a problem on ESP32 with esptool version 4.7
> Can be updated locally or we can include it in RC1 and restart the vote
> 
> Considering that we have known bugs in the release that affect some boards
> we have 2 options:
> 1) we can stop the release and delay it for an unknown amount of time until
> the bugs are fixed (in some cases for external projects)
> 2) we can release and specify what are the known bugs
> 
> https://cwiki.apache.org/confluence/display/NUTTX/NuttX+12.7.0
> 
> I would like to propose the second option
> 
>> On Sat, Oct 5, 2024 at 2:00 AM Tomek CEDRO  wrote:
>> 
>> Hello world :-)
>> 
>> There goes -1 from me, sorry :-P :-P
>> 
>> 1. There are memory leak problems reported that I tried to confirm on
>> STM32F769. Is it ostest problem only or more general memory management
>> issue?
>> 
>> before ostest total/used: 483056 / 10112.
>> after ostest total/used: 483056 / 10200.
>> 
>> 2. There are LVGL screen problems reported. This may be solved with
>> LVGL 9.2.1 release that should show up within days and its inclusion
>> is in the PRs. Or we have display driver to fix. I would also
>> recommend testing with previous NuttX releases on the same hardware to
>> confirm the possible regression. Gabor is very keen to NuttX and it
>> would be really nice to show working demo of LVGL 9.2.1 on 12.7.0 also
>> to attract newcomers to the project.
>> 
>> https://github.com/apache/nuttx/issues/13825
>> https://github.com/lvgl/lvgl/pull/6981
>> 
>> 3. I have found a problem on ESP32 with esptool version 4.7 that
>> produces faulty unusable firmware with no warning / error. I found a
>> commit that bumps esptool to 4.8 in order to build on CI with new
>> bootloader from ESP IDF. Otherwise I would not know why it does not
>> run. But we should handle this situation with error message and/or use
>> older bootloader with 4.7 (?) otherwise people may get discouraged at
>> first contact with NuttX.
>> 
>> https://github.com/apache/nuttx/issues/13824
>> 
>> 
>> If there is any reason the 12.7.0 really should be released right now
>> for some serious reason I can change my vote to 0 not to block the
>> release. Otherwise we should focus on fixing those 3 discovered issues
>> in order to provide high quality no-surprises release :-)
>> 
>> 
>> Here returns the subject of distributed testing farms so we could test
>> NuttX builds locally on a real hardware that we have at hand. I
>> started building one. But we also need some scripts that will make
>> this task easy to setup by everyone interested in a repeatable way.
>> This is a separate discussion already taking place on dev@.
>> 
>> 
>> I have contacted local STM in Poland and asked if they can provide
>> free sample develkits to test NuttX on them and demo a reference
>> design. I have STM32F769I-DISCO but with no LCD so I cannot help with
>> LVGL at this point sorry.
>> 
>> Thank you :-)
>> Tomek
>> 
>> 
>> === BUILD HOST ===
>> 
>> % uname -a
>> FreeBSD octagon 13.3-RELEASE-p7 FreeBSD 13.3-RELEASE-p7 GENERIC amd64
>> 
>> % git branch
>> * (HEAD detached at nuttx-12.7.0-RC0)
>> 
>> % git log --oneline -5
>> 10e44f8915 (HEAD, tag: nuttx-12.7.0-RC0, origin/releases/12.7)
>> riscv_fork.c: Fix race condition when handling parent integer
>> registers
>> 2d3c94411b riscv_fork.c: Fix vfork() for kernel mode + SMP
>> d1fec65e1b riscv: use g_running_task store current regs
>> 57f84aaca8 sensor: Added 6dof motion and gesture related types. For
>> details, see:
>> https://developer.android.com/reference/android/hardware/SensorEvent#values
>> a4e90b7268
>> 
>> inlclude/uorb.h:Update data types to be sorted by macro definition.
>> 
>> %  git branch
>> * (HEAD detached at nuttx-12.7.0-RC0)
>> 
>> % git log --oneline -5
>> ac11e3cba (HEAD, tag: nuttx-12.7.0-RC0, origin/releases/12.7) Adapt
>> the new header file path of va_format.
>> b4d794cbd Makefile:complete missing DEPPATH
>> f81a09428 nshlib: add support for pkill command
>> 767c8ea6c uorb: enable O_CLOEXEC explicit
>> bae15dfd5 nshlib: enable O_CLOEXEC explicit to avoid potential fd leak
>> 
>> 
>> === TARGETS ===
>> 
>> 1. ESP32 (FAIL).
>> 2. ESP32-C3 (PASS).
>> 3. STM32F769I-DISCO (PASS).
>> 
>> 
>> 
>> === ESP32 ===
>> 
>> % gmake clean distclean
>> 
>> % xtensa-esp32-elf-cc --version
>> xtensa-esp32-elf-cc (crossto

Re: [VOTE] Apache NuttX 12.7.0 RC0 release

[Tim Hardisty]

I have had lots of issues with LVGL 9.1 as used in NuttX, but on SAMA5D2. The 
framebuffer was being rendered to directly causing tearing. I have also seen 
LVGL repo issues relating to STM32, I think. LVGL V9.2 fixes my issues.

Don’t necessarily assume it’s a board fault!

Regards,

Time

> On 4 Oct 2024, at 11:26, Fotis Panagiotopoulos  wrote:
> 
> I am running some tests on actual STM32 hardware for this release.
> 
> I am stuck with stm32f746g-disco:lvgl configuration on a Discovery
> STM32F746 board, the screen displays garbage.
> I start to suspect that this may be an issue with my board, rather than
> NuttX.
> 
> Does anyone have this board to test this specific build?
> 
>> On Fri, Oct 4, 2024 at 11:54 AM Ville Juven 
>> wrote:
>> 
>> Issue seen with rv-virt:knsh64 as well. After first ostest run the memory
>> usage rises by ~500 bytes, but the consequent runs do not increase it
>> further.
>> 
>> Something is allocated once from kheap that is never freed again.
>> 
>> nsh> free
>> total   used   freemaxusedmaxfree  nused
>> nfree
>>  Kmem:2063416  117042051712  331682051040 41
>>3
>>  Page:4194304 11878440755204075520
>> nsh> free
>> total   used   freemaxusedmaxfree  nused
>> nfree
>>  Kmem:2063416  121682051248  543202040560 46
>>5
>>  Page:4194304 11878440755204075520
>> nsh> free
>> total   used   freemaxusedmaxfree  nused
>> nfree
>>  Kmem:2063416  121682051248  543682040560 46
>>5
>>  Page:4194304 11878440755204075520
>> nsh>
>> 
>> Running some other process does not show this behavior:
>> nsh> free
>> total   used   freemaxusedmaxfree  nused
>> nfree
>>  Kmem:2063416  117042051712  331682051040 41
>>3
>>  Page:4194304 11878440755204075520
>> nsh> getprime
>> Set thread priority to 10
>> Set thread policy to SCHED_RR
>> Start thread #0
>> thread #0 started, looking for primes < 1, doing 10 run(s)
>> thread #0 finished, found 1230 primes, last one was 9973
>> Done
>> getprime took 118 msec
>> nsh> free
>> total   used   freemaxusedmaxfree  nused
>> nfree
>>  Kmem:2063416  117042051712  371522051040 41
>>3
>>  Page:4194304 11878440755204075520
>> nsh>
>> 
>> -Ville
>> 
>> From: yfliu2008 
>> Sent: Friday, October 4, 2024 4:07 AM
>> To: dev 
>> Subject: Re:[VOTE] Apache NuttX 12.7.0 RC0 release
>> 
>> +1 for CanMV230 device.
>> 
>> Checked with Canmv230 on Oct 4th, 2024 from Ubuntu 23.04 desktop.
>> 
>> 
>> In general is works, with  minor issues:
>> - Two kernel mode configs `nsbi` and `knsh` both show used memory growth
>> after ostest.
>> - The protected mode `pnsh` facing tight stack for NSH app, thus lead to
>> weird free memory status. After tweaking kconfig with a larger stack size
>> config, it looks fine.
>> 
>> 
>> Given the fact that no real k230 project is known, I am ok to go ahead
>> with this RC.
>> 
>> 
>> 
>> 
>> 
>> ### toolchain
>> 
>> 
>> Toolchain name: `gcc-riscv64-unknown-elf 10.2.0-0ubuntu1` on Ubuntu 22.04
>> 
>> 
>> ```shell
>> $ riscv64-unknown-elf-gcc -v
>> Using built-in specs.
>> Target: riscv64-unknown-elf
>> Thread model: single
>> Supported LTO compression algorithms: zlib
>> gcc version 10.2.0 ()
>> ```
>> 
>> 
>> ### nsh
>> 
>> 
>> ```
>> ## Starting application at 0x0600 ...
>> ABC
>> NuttShell (NSH) NuttX-12.7.0
>> nsh> cat /proc/version
>> NuttX version 12.7.0 10e44f8915 Oct  4 2024 08:20:24 canmv230:nsh
>> nsh> free
>>                  total  
>>     used       free    maxused  
>>  maxfree  nused  nfree
>>       Umem:   16585336       8024
>>   16577312       8704   16577312     22
>>      1
>> nsh> ps
>>   PID GROUP PRI POLICY   TYPE    NPX STATE  
>>  EVENT     SIGMASK           STACK
>>  USED  FILLED COMMAND
>>     0     0   0 FIFO     Kthread  
>> - Ready              
>> 002032000816  40.1%  Idle_Task
>>     1     1 100 RR       Task  
>>    - Running          
>>   003024002304  76.1%  nsh_main
>> nsh> ostest >/dev/null; rm -r /var; free
>> stdio_test: write fd=2
>> stdio_test: Standard I/O Check: fprintf to stderr
>> setvbuf_test: Using NO buffering
>> setvbuf_test: Using default FULL buffering
>> setvbuf_test: Using FULL buffering, buffer size 64
>> setvbuf_test: Using FULL buffering, pre-allocated buffer
>> setvbuf_test: Using LINE buffering, buffer size 64
>> setvbuf_test: Using FULL buffering, pre-allocated buffer
>>                  total  
>>     used       free    maxused  
>>  maxfree  nused  nfree
>>       Umem:   16585336       8024
>>   16577312      51024   16577312     22
>>      1
>> nsh>
>> ```
>> 
>> 
>> ### pnsh
>> 
>> 
>> 
>> 
>> ```
>> Bytes tr

Re: Github Issue Labels

[Tim Hardisty]

+1 from me!!

On 21/07/2024 00:55, Daniel Appiagyei wrote:

Hi,
Is anyone opposed to:
- creating more specific github issue labels,
- encouraging everyone to use them, and
- setting up permissions on github such that anyone that has contributed to
the repo has the ability to add/remove labels?

This would help a ton if anyone is curious about any reported issues on
their board or platform. Github lets you filter by labels. This is
something that zephyr does really well. Click the following link

and check out the labels filter.

What I'd like to see is a *platform* label with the following variants:
- platform: NXP
- platform: nRF
- platform: 

I'd also like the availability of more specific platform labels:
- platform: STM32
- platform: STM32F4 (if this isn't too specific)
- platform: IMXRT
- platform: IMXRT1064 (again, if this isn't too specific)


I'd also think that some priority labels would be good:
- priority: low, priority: medium, priority: high

Additionally, using the label of 'bug' or 'enhancement' would make it
easier to understand what the 400+ open issues pertain to.

Thanks for the consideration!
Best,
Daniel

Re: LVGL and LCD driver - SAMA5D2

[Tim Hardisty]

I think I am satisfied that what I am seeing is a basic fault with the 
LVGL V9/NuttX framebuffer driver.


LVGL V8/NuttX had, as LVGL traditionally needs, 2 buffers (full frame, 
or partial, as required) and switches between them.


LVGL V9/NuttX directly uses the "/dev/fb0" framebuffer as best as I can 
tell.


I believe it needs a rework of the lvgl framebuffer driver - which is 
probably down to LVGL rather than NuttX people to sort; but I may see if 
I can create a custom driver using the LVGL guidelines for now.


On 14/06/2024 11:13, Tim Hardisty wrote:


Thank you Gregory. I will read all of this and, so far, have skim read 
the first you linked to and now understand it a little better already 
and it confirms that the SAMA5D2 does indeed have a frame buffer 
interface, that I register in my board bringup (so longer ago I'd 
forgotten LOL) - but it could be that I could "upgrade" this since the 
LCDC peripheral probably supports more than 1 layer with. various 
advance functionalities - but NuttX may not of course.


I would like to use LVGL rather than NX simply because of the good 
quality and flexible widgets that quickly allow a nice UI to be built.


Since the framebuffer example app works AOK, with no obvious image 
defects, I am sure it's fundamentally OK.


I also recall that my brief experimentation with LVGL V8 via NuttX, 
using the example app, worked with no visible artifacts, so I am 
leaning towards some setup or other incompatibility between LVGL V9 
(which purports to have NuttX support and was only recently 
incorporated into NuttX to supersede V8) and NuttX, or the SAMA5, or 
similar.


I will investigate further today as there are a whole heap of LVGL 
settings with no documentation that I can find - either at LVGL or at 
NuttX - so it could be I just need to find the the correct, arcane, 
incantations. And also try reverting to LVGL V8 to compare behaviours 
if necessary.


On 14/06/2024 03:39, Gregory Nutt wrote:


On 6/13/2024 8:32 PM, Gregory Nutt wrote:

On 6/13/2024 11:56 AM, Gregory Nutt wrote:
Changing the existing driver interface would break the NX graphics. 
NX graphics is mis-named.  It is not a graphics system like LVGL, 
but a windowing system like X.  Whatever you do should not break 
the windowing system and, in fact, really should optionally 
integrate with the windowing system.


There is some graphics support in apps/ now (called NxGraphics), 
but that was never really fully developed. LVGL has the better 2D 
graphics.  NxGraphics can provide a Z-axis as well if properly 
integrated with LVGL.  There are several examples of window 
managers that run on top of NX graphics  NxTerms, NxWM, a tiny port 
of a TWM-like window manger called Twm4Nx.  These must not be broken.


So you have a few options:  (1) Provide dual graphics that are 
completely separate so that the existing graphic framework is not 
trashed.  That would not be cool.  Or (2) Integrate LVGL with NX 
Windows, or (3) both.  Then you could have multiple LVGL windows.. 
which is really pretty cool. There would possible be some 
performance hit, however.  The simplest LVGL integration would be 
to use per Window framebuffers.  The current framebuffer driver 
supports the whole screen.  That is not the way other graphic 
systems work.  Rather they provide a framebuffer per Window.  That 
naturally supports Windows and cleanly provides multi-threaded 
access to the display.


Here are URLs to some relevant documentation.  I may or may not have 
ever been leveraged into  nuttx/Documentation.


  * 
https://cwiki.apache.org/confluence/display/NUTTX/Framebuffer+Character+Driver
  * 
https://cwiki.apache.org/confluence/display/NUTTX/NX+Graphics+Subsystem


  * 
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629474
  * 
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629473




A couple more references that most people are not aware of:

 * 
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629398
 * 
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629401

Re: LVGL and LCD driver - SAMA5D2

[Tim Hardisty]

Thank you Gregory. I will read all of this and, so far, have skim read 
the first you linked to and now understand it a little better already 
and it confirms that the SAMA5D2 does indeed have a frame buffer 
interface, that I register in my board bringup (so longer ago I'd 
forgotten LOL) - but it could be that I could "upgrade" this since the 
LCDC peripheral probably supports more than 1 layer with. various 
advance functionalities - but NuttX may not of course.


I would like to use LVGL rather than NX simply because of the good 
quality and flexible widgets that quickly allow a nice UI to be built.


Since the framebuffer example app works AOK, with no obvious image 
defects, I am sure it's fundamentally OK.


I also recall that my brief experimentation with LVGL V8 via NuttX, 
using the example app, worked with no visible artifacts, so I am leaning 
towards some setup or other incompatibility between LVGL V9 (which 
purports to have NuttX support and was only recently incorporated into 
NuttX to supersede V8) and NuttX, or the SAMA5, or similar.


I will investigate further today as there are a whole heap of LVGL 
settings with no documentation that I can find - either at LVGL or at 
NuttX - so it could be I just need to find the the correct, arcane, 
incantations. And also try reverting to LVGL V8 to compare behaviours if 
necessary.


On 14/06/2024 03:39, Gregory Nutt wrote:


On 6/13/2024 8:32 PM, Gregory Nutt wrote:

On 6/13/2024 11:56 AM, Gregory Nutt wrote:
Changing the existing driver interface would break the NX graphics. 
NX graphics is mis-named.  It is not a graphics system like LVGL, 
but a windowing system like X.  Whatever you do should not break the 
windowing system and, in fact, really should optionally integrate 
with the windowing system.


There is some graphics support in apps/ now (called NxGraphics), but 
that was never really fully developed.  LVGL has the better 2D 
graphics.  NxGraphics can provide a Z-axis as well if properly 
integrated with LVGL.  There are several examples of window managers 
that run on top of NX graphics NxTerms, NxWM, a tiny port of a 
TWM-like window manger called Twm4Nx.  These must not be broken.


So you have a few options:  (1) Provide dual graphics that are 
completely separate so that the existing graphic framework is not 
trashed.  That would not be cool.  Or (2) Integrate LVGL with NX 
Windows, or (3) both.  Then you could have multiple LVGL windows.. 
which is really pretty cool.  There would possible be some 
performance hit, however.  The simplest LVGL integration would be to 
use per Window framebuffers.  The current framebuffer driver 
supports the whole screen.  That is not the way other graphic 
systems work.  Rather they provide a framebuffer per Window.  That 
naturally supports Windows and cleanly provides multi-threaded 
access to the display.


Here are URLs to some relevant documentation.  I may or may not have 
ever been leveraged into  nuttx/Documentation.


  * 
https://cwiki.apache.org/confluence/display/NUTTX/Framebuffer+Character+Driver
  * 
https://cwiki.apache.org/confluence/display/NUTTX/NX+Graphics+Subsystem


  * 
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629474
  * 
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629473




A couple more references that most people are not aware of:

 * 
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629398
 * 
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629401

LVGL and LCD driver - SAMA5D2

[Tim Hardisty]

I am getting in a mental pickle regarding LVGL (V9) and NuttX, in 
conjunction with the SAMA5D2 with it's built in LCD Controller peripheral.


In the past - bare metal - I have simply set up two buffers so one can 
be written to while the other is copied out to the actual display. But 
now NuttX is "in the way" ;-)


The NuttX support for V9 LVGL allows you to set it up to use a NuttX LCD 
device - but I am pretty sure that us expecting a NuttX device driver 
such as /dev/lcd0. The default configuration for the SAMA5 - I believe - 
is to create /dev/fb0. I have that device driver registered and it works 
- e.g. using the framebuffer example without issue.


I can get LVGL to use /dev/fb0 but the display "tears" and I think that 
is because LVGL writes to the same single buffer set up for the SAMA5D2 
LCDC, but I can't work out how to get it all to work with 2 buffers. Or 
it's for some other reason maybe, but I can't fathom what it might be.


Should I, somehow, convert the framebuffer to a "simpler" driver that 
lvgl can work with to create 2 buffers? How?


Or does it need some work at the SAMA5D2 end of things? What?

Or do I need a "custom" lvgl fb interface of some sorts instead? Any 
examples?


Thoughts and suggestions would be much appreciated!

Thanks,

Tim

Re: [VOTE] Apache NuttX 12.5.1 RC0 release

[Tim Hardisty]

+1 non-binding. On my custom board:

NuttX  12.5.1-RC0 3fcd063148 Apr  9 2024 16:22:37 arm jti-xxx

arm-none-eabi-gcc -v
Supported LTO compression algorithms: zlib
gcc version 13.2.1 20231009 (Arm GNU Toolchain 13.2.rel1 (Build arm-13.7))

On 09/04/2024 08:40, Alin Jerpelea wrote:

Hello all,
Apache NuttX 12.5.1 RC0 has been staged under [1] and it's
time to vote on accepting it for release. Voting will be open for 72hr.

A minimum of 3 binding +1 votes and more binding +1 than binding -1 are
required to pass.

The Apache requirements for approving a release can be found here [3]
"Before voting +1 PMC members are required to download the signed
source code package, compile it as provided, and test the resulting
executable on their own platform, along with also verifying that the
package meets the requirements of the ASF policy on releases."

A document to walk through some of this process has been published on
our project wiki and can be found here [4].

[ ] +1 accept (indicate what you validated - e.g. performed the non-RM
items in [4])
[ ] -1 reject (explanation required)

Thank you all,
Alin Jerpelea

SCM Information:
   Release tag: nuttx-12.5.1-RC0
   Hash for the release nuttx tag: 9e8753d6256619a7bfa72f4596eb1e481f1c97a2
   Hash for the release nuttx-apps tag: 63dd3547fdc9a0412f0e04df5d8a8be480dd6935

[1] https://dist.apache.org/repos/dist/dev/nuttx/12.5.1-RC0/
[2] https://raw.githubusercontent.com/apache/nuttx/nuttx-12.5.1-RC0/ReleaseNotes
[3] https://www.apache.org/dev/release.html#approving-a-release
[4] 
https://cwiki.apache.org/confluence/display/NUTTX/Validating+a+staged+Release

Re: Run app when device starts

[Tim Hardisty]

make menuconfig

RTOS Features ->Tasks and Scheduling -> Application entry point

also

RTOS Features ->Tasks and Scheduling ->Application Name

On 18/03/2024 19:44, Gustavo Soares wrote:

Hello!

I've built an application to run on NuttX and I'd like to know if it's possible 
to make it start when the device starts so I don't have to connect into the 
console to run it.

Touchscreen calibration

[Tim Hardisty]

My board uses built-in SAMA5 TSD peripheral to interface with a 
resistive touchscreen on a 5" TFT. Early on I implemented (and had 
merged) an ioctl to allow the low level driver to scale the x/y data to 
match the display resolution but I am now finding it actually needs a 
multipoint calibration to get the accuracy required.


The maths for this is well documented and I found an MIT-licensed 
calibration solution for LVGL - which is what I'm using anyway. It 
works, but is not generic, and is mixing Apache and MIT licenses of course.


I was thinking that it might be a good idea to proffer a generic 
solution for this in NuttX but found:


1. NXWM already has this in principle (not tried it to be fair)
2. The sam tsd driver is not a generic driver, as such, so x/y data
   does not pass through an appropriate upper-half layer where
   calibration data might best live, and be used by any low level
   driver managing tsd interfaces (like, I think, the off-chip tsd
   controllers that are supported use)

My first thought is whether it might be feasible to run the NXWM system 
- to gain access to touchscreen calibration routines when needed - and 
then handover to lvgl. But it doesn't "feel" right but perhaps someone 
has done this?


Otherwise would it be a better idea to rework the sam tsd to pass 
through a/the generic upper half driver where calibration data can live, 
but leave it to the user app to implement the actual mechanism 
(graphical screens, but not tied to lvgl etc) to gather the required 
coefficients.


Thoughts?

Re: debugassert vs assert in apps

[Tim Hardisty]

Would a variation on this proposal be to add app-specific 
NXAPP_DEBUGASSERT etc.? This would then be "global" but unique to apps, 
not overlap with O/S DEBUGASSERTs, and make for a simpler global 
search/replace of current DEBUGASSERT in apps, and just need a one-off 
new set of entries in the apps' Kconfig?


Over time, the NX apps debug "system" could be expanded/enhanced to 
allow app-by-app "APPNAME_ENABLE_DEBUG" that is similar to the OS DEBUG 
system, but would be quicker/easier to implement in one hit for now?


(Accidentally sent this before as a direct reply to Nathan: sorry!)

On 03/01/2024 16:43, Nathan Hartman wrote:

On Wed, Jan 3, 2024 at 11:22 AM Gregory Nutt  wrote:

On 1/3/2024 10:11 AM, Fotis Panagiotopoulos wrote:

That would seem a little odd since there was a PR a few years ago to

change all instances of assert/ASSERT to DEBUGASSERT to save code size.

How is that so?

As I see here:
https://github.com/apache/nuttx/blob/master/include/assert.h#L122
assert defined exactly as DEBUGASSERT.

There shouldn't be any code size difference at all.

When CONFIG_DEBUG_ASSERTIONS is not defined, then all occurrences of
DEBUGASSERT compile to nothing (actually the current version compiles to
an expression that is optimized out):

 #undef DEBUGASSERT  /* Like ASSERT, but only if
 CONFIG_DEBUG_ASSERTIONS is defined */

 #ifdef CONFIG_DEBUG_ASSERTIONS
 #  define DEBUGASSERT(f) _ASSERT(f, __DEBUG_ASSERT_FILE__,
 __DEBUG_ASSERT_LINE__)
 #else
 #  define DEBUGASSERT(f) ((void)(1 || (f)))
 #endif

This value, ((void)(1 || (f))), is completely removed by the optimizer
because of short-circuiting and dead code removal.  So the code is much
smaller if CONFIG_DEBUG_ASSERTIONS is not enabled.  If DEBUGASSERT() is
replaced with assert() than that code bloat would be unconditional,
although somewhat less than when assertions are enabled.

This same kind of logic also applies to  DEBUGPANIC and DEBUGVERIFY.

Xiao Xiang made that change to reduce the size as needed by their
products.  He is the person you should be talking to.


Maybe we need NX_DEBUGASSERT, NX_DEBUGPANIC, NX_DEBUGVERIFY. The NX
prefix would make it more clear that this is NuttX-specific. These
would be used in the OS only, not in applications, and
CONFIG_DEBUG_ASSERTIONS would continue to control if these are real or
optimized out.

Applications that need their own specific, Kconfig-controlled debug
assertion, should define one themselves, and their own Kconfig to
optimize it out. Rationale: If you are debugging an application,
enable assertions only in that application, not everywhere throughout
the system.

Cheers
Nathan

Re: debugassert vs assert in apps

[Tim Hardisty]

If someone can post with a consensus/decision once there is one, it 
would be most useful!


On 03/01/2024 17:35, Fotis Panagiotopoulos wrote:

Just to be clear, I am always referring to the standard C assert()
function/macro.

Not the unconditional NuttX ASSERT() macro. Notice the capitalization!

(Which is another confusing point worth improving... +1 for NX_ASSERT() )

On Wed, Jan 3, 2024 at 7:32 PM Fotis Panagiotopoulos
wrote:


I am sorry, but I still don't see the difference.

See this line here:
https://github.com/apache/nuttx/blob/master/include/assert.h#L119

When NDEBUG is defined, assert also compiles to nothing.
As it ought to do.

(NDEBUG definition is also controlled by Kconfig, with CONFIG_NDEBUG)

So, is there an actual difference that I currently have overseen?

On Wed, Jan 3, 2024 at 6:54 PM Tomek CEDRO  wrote:


+1 :-)

--
CeDeROM, SQ7MHZ,http://www.tomek.cedro.info

On Wed, Jan 3, 2024, 17:44 Gregory Nutt  wrote:


+1

On 1/3/2024 10:43 AM, Nathan Hartman wrote:

On Wed, Jan 3, 2024 at 11:22 AM Gregory Nutt

wrote:

On 1/3/2024 10:11 AM, Fotis Panagiotopoulos wrote:

That would seem a little odd since there was a PR a few years ago

to

change all instances of assert/ASSERT to DEBUGASSERT to save code

size.

How is that so?

As I see here:
https://github.com/apache/nuttx/blob/master/include/assert.h#L122
assert defined exactly as DEBUGASSERT.

There shouldn't be any code size difference at all.

When CONFIG_DEBUG_ASSERTIONS is not defined, then all occurrences of
DEBUGASSERT compile to nothing (actually the current version

compiles to

an expression that is optimized out):

  #undef DEBUGASSERT  /* Like ASSERT, but only if
  CONFIG_DEBUG_ASSERTIONS is defined */

  #ifdef CONFIG_DEBUG_ASSERTIONS
  #  define DEBUGASSERT(f) _ASSERT(f, __DEBUG_ASSERT_FILE__,
  __DEBUG_ASSERT_LINE__)
  #else
  #  define DEBUGASSERT(f) ((void)(1 || (f)))
  #endif

This value, ((void)(1 || (f))), is completely removed by the

optimizer

because of short-circuiting and dead code removal.  So the code is

much

smaller if CONFIG_DEBUG_ASSERTIONS is not enabled.  If DEBUGASSERT()

is

replaced with assert() than that code bloat would be unconditional,
although somewhat less than when assertions are enabled.

This same kind of logic also applies to  DEBUGPANIC and DEBUGVERIFY.

Xiao Xiang made that change to reduce the size as needed by their
products.  He is the person you should be talking to.

Maybe we need NX_DEBUGASSERT, NX_DEBUGPANIC, NX_DEBUGVERIFY. The NX
prefix would make it more clear that this is NuttX-specific. These
would be used in the OS only, not in applications, and
CONFIG_DEBUG_ASSERTIONS would continue to control if these are real or
optimized out.

Applications that need their own specific, Kconfig-controlled debug
assertion, should define one themselves, and their own Kconfig to
optimize it out. Rationale: If you are debugging an application,
enable assertions only in that application, not everywhere throughout
the system.

Cheers
Nathan

Re: Correct way to manage LCD backlight brightness

[Tim Hardisty]

Thanks Alan,

As per usual, the obvious escaped me - a character driver makes sense of 
course. I will implement this, for now, as a board-specific driver and 
when its working, and I have time, I will look at transitioning it to be 
a generic NuttX driver.


On 03/01/2024 20:17, Alan C. Assis wrote:

Hi Tim,

AFAIK NuttX doesn't have a standard way to do it.
It is normally done at board level (do a "git grep backlight" inside
boards/ to see some examples).

A proper way to do that should be implementing a backlight subsystem, like
a subset of Linux backlight subsystem:
https://docs.kernel.org/gpu/backlight.html

I think you could create a simple char device driver (at
drivers/lcd/backlight.c) that will receive IOCTLs to set the backlight
dimming.

Best Regards,

Alan


On Wed, Jan 3, 2024 at 3:03 PM Tim Hardisty  wrote:


My SAMA5 board has an LCD with variable brightness (pwm controlled).

arch/arm/src/chip/sam_lcd.c has a function called "sam_backlight) that
takes a level value, but it appears to be local to that file, and the
only call to it is in the LCD init functions in that file, complete with
a comment that says:

 /REVISIT: Backlight level could be dynamically adjustable/

That's what I need.

But from an app perspective I can't get my mind around what the right
function call would be to ripple that down to something low level and
board specific. So if I change the processor, for example, the app will
still work and not rely (for example) on board ioctls.

Can someone point me in the direction of the "right" way to handle this,
please? Once I know the "flow" I can work out how and where it is best
to expose the right function.

Thanks!

Correct way to manage LCD backlight brightness

[Tim Hardisty]

My SAMA5 board has an LCD with variable brightness (pwm controlled).

arch/arm/src/chip/sam_lcd.c has a function called "sam_backlight) that 
takes a level value, but it appears to be local to that file, and the 
only call to it is in the LCD init functions in that file, complete with 
a comment that says:


   /REVISIT: Backlight level could be dynamically adjustable/

That's what I need.

But from an app perspective I can't get my mind around what the right 
function call would be to ripple that down to something low level and 
board specific. So if I change the processor, for example, the app will 
still work and not rely (for example) on board ioctls.


Can someone point me in the direction of the "right" way to handle this, 
please? Once I know the "flow" I can work out how and where it is best 
to expose the right function.


Thanks!

Re: LittleFS Implementation using MTD for NOR flash

[Tim Hardisty]

Standard POSIX file opens etc. Look at the various offerings in nuttx-apps to 
get the idea.

> On 28 Dec 2023, at 16:44, Janardhan Silwal  
> wrote:
> 
> Hi,
> 
> I tried using the template that you provied.
> 
> I have gotten the mtd partition blocks mounted using littefs. And tried 
> creating and writing a test message to the file via nsh shell.
> The file seems to have been created, and the test message does exist even 
> after power cycling.
> 
> So, now how do I go about creating application which creates, write to and 
> read from file on the mounted partition?
> 
> Best Regards,
> 
> Janardhan
> 
> From: Tim Hardisty 
> Sent: Thursday, December 28, 2023 20:36
> To: dev@nuttx.apache.org 
> Subject: Re: LittleFS Implementation using MTD for NOR flash
> 
> FYI - if you type the / character in menuconfig it will allow you to
> search for things (e.g. /MT25 will show two entries relating to MT25
> memory - the MTD settings and the actual flash ID of the device you're
> using (which will need to exist in the relevant driver code of course -
> so with your code editor search all files in the project for MT25Q
> related data and you'll find the data in m25px.c I think)
> 
>> On 28/12/2023 14:28, Janardhan Silwal wrote:
>> which driver did you use?
>> I didn't see MT25QL SPI flash in menu config so I went ahead and wrote one!
>> 
>> Best regards,
>> Janardhan
>> 
>> From: Tim Hardisty
>> Sent: Thursday, December 28, 2023 19:15
>> To:dev@nuttx.apache.org  
>> Subject: Re: LittleFS Implementation using MTD for NOR flash
>> 
>> I have only ever used NuttX "directly" with my apps running over it
>> rather than any other middleware or anything, so I can't answer that.
>> 
>> My board has been fitted with a MT25QL01GBBB8ESF, and has worked fine,
>> so your flash is most likely supported already?
>> 
>>> On 28/12/2023 12:12, Janardhan Silwal wrote:
>>> Hi,
>>> 
>>> I am using MT25QL, 1Gbit series flash memory.
>>> 
>>> Thanks for the template.
>>> Would running in this format over the middleware running over nuttx also 
>>> follow the same approach?
>>> 
>>> Best Regards,
>>> Janardhan
>>> 
>>> From: Tim Hardisty
>>> Sent: Thursday, December 28, 2023 17:31
>>> To:dev@nuttx.apache.org   
>>> Subject: Re: LittleFS Implementation using MTD for NOR flash
>>> 
>>> Hi,
>>> 
>>> What flash are you using out of interest?
>>> 
>>> But, the basic approach (in or called from your board bringup for
>>> example) is:
>>> 
>>> 
>>> spi_flash= sam_spibus_initialize(PORT); /* this call is arch dependent */
>>> if(!spi_flash)
>>> {
>>> /* Do something */
>>> }
>>> #ifdefined(CONFIG_MTD_M25P)
>>> mtd = m25p_initialize(spi_flash, MINOR);
>>> #elifdefined(CONFIG_MTD_GD25)
>>> mtd = gd25_initialize(spi_flash, MINOR);
>>> #elif defined(CONFIG_MTD_YOURFLASHTYPE)
>>> /* etc */
>>> #endif
>>> if(!mtd)
>>> {
>>> /* Do something */
>>> }
>>> #ifdefined(CONFIG_FS_LITTLEFS)
>>> /* Mount the LittleFS file system */
>>> ret = register_mtddriver("/dev/flash", mtd, 0755, NULL);
>>> if(ret < 0)
>>> {
>>> /* Do something */
>>> }
>>> ret = nx_mount("/dev/flash", "/mnt/flash", "littlefs", 0, "autoformat");
>>> if(ret < 0)
>>> {
>>> /* Do something */
>>> }
>>> 
>>> That was a copy/paste/edit or my own code so please forgive any typo errors!
>>> 
>>> On 28/12/2023 11:19, Janardhan Silwal wrote:
>>>> Hi community,
>>>> 
>>>> I am trying to get littlefs running on a NOR flash memory using the MTD 
>>>> driver, on a STM32F4 chip.
>>>> 
>>>> I had some bottlenecks in the implementation as I am an out-and-out novice 
>>>> when it comes to Nuttx.
>>>> I have written a custom driver for the flash, which is working with MTD, 
>>>> as  I couldn't find the exact driver for the flash installed on my system.
>>>> 
>>>> Now I need some guidance on where to start for linking LittleFS to MTD and 
>>>> the rest..
>>>> 
>>>> Best Regards,
>>>> Janardhan Silwal
>>>> 

Re: LittleFS Implementation using MTD for NOR flash

[Tim Hardisty]

Code size?


> On 28 Dec 2023, at 17:11, Bernd Walter  wrote:
> 
> On Thu, Dec 28, 2023 at 04:46:08PM +, Janardhan Silwal wrote:
>> Oh!!
>> So that is the one you used.
>> I did see that on the menu config, but wasn't sure if it was the one. and I 
>> was halfway through completing the driver when I noticed that option in menu 
>> config anyway, so I went ahead and completed the driver.
>> Anyway it is working, so no worries there.
>> Thanks though.
> 
> I really wonder why the are so many *25 NOR-flash drivers to begin with.
> Aren't they supposed to be similar and autoprobing?
> 
>> 
>> From: Tim Hardisty 
>> Sent: Thursday, December 28, 2023 20:18
>> To: dev@nuttx.apache.org 
>> Subject: Re: LittleFS Implementation using MTD for NOR flash
>> 
>> Device Drivers -> Memory Technology Device (MTD) Support -> SPI-based
>> M25P/MT25Q
>> 
>>> On 28/12/2023 14:28, Janardhan Silwal wrote:
>>> which driver did you use?
>>> I didn't see MT25QL SPI flash in menu config so I went ahead and wrote one!
>>> 
>>> Best regards,
>>> Janardhan
>>> 
>>> From: Tim Hardisty
>>> Sent: Thursday, December 28, 2023 19:15
>>> To:dev@nuttx.apache.org  
>>> Subject: Re: LittleFS Implementation using MTD for NOR flash
>>> 
>>> I have only ever used NuttX "directly" with my apps running over it
>>> rather than any other middleware or anything, so I can't answer that.
>>> 
>>> My board has been fitted with a MT25QL01GBBB8ESF, and has worked fine,
>>> so your flash is most likely supported already?
>>> 
>>> On 28/12/2023 12:12, Janardhan Silwal wrote:
>>>> Hi,
>>>> 
>>>> I am using MT25QL, 1Gbit series flash memory.
>>>> 
>>>> Thanks for the template.
>>>> Would running in this format over the middleware running over nuttx also 
>>>> follow the same approach?
>>>> 
>>>> Best Regards,
>>>> Janardhan
>>>> 
>>>> From: Tim Hardisty
>>>> Sent: Thursday, December 28, 2023 17:31
>>>> To:dev@nuttx.apache.org   
>>>> Subject: Re: LittleFS Implementation using MTD for NOR flash
>>>> 
>>>> Hi,
>>>> 
>>>> What flash are you using out of interest?
>>>> 
>>>> But, the basic approach (in or called from your board bringup for
>>>> example) is:
>>>> 
>>>> 
>>>> spi_flash= sam_spibus_initialize(PORT); /* this call is arch dependent */
>>>> if(!spi_flash)
>>>> {
>>>> /* Do something */
>>>> }
>>>> #ifdefined(CONFIG_MTD_M25P)
>>>> mtd = m25p_initialize(spi_flash, MINOR);
>>>> #elifdefined(CONFIG_MTD_GD25)
>>>> mtd = gd25_initialize(spi_flash, MINOR);
>>>> #elif defined(CONFIG_MTD_YOURFLASHTYPE)
>>>> /* etc */
>>>> #endif
>>>> if(!mtd)
>>>> {
>>>> /* Do something */
>>>> }
>>>> #ifdefined(CONFIG_FS_LITTLEFS)
>>>> /* Mount the LittleFS file system */
>>>> ret = register_mtddriver("/dev/flash", mtd, 0755, NULL);
>>>> if(ret < 0)
>>>> {
>>>> /* Do something */
>>>> }
>>>> ret = nx_mount("/dev/flash", "/mnt/flash", "littlefs", 0, "autoformat");
>>>> if(ret < 0)
>>>> {
>>>> /* Do something */
>>>> }
>>>> 
>>>> That was a copy/paste/edit or my own code so please forgive any typo 
>>>> errors!
>>>> 
>>>> On 28/12/2023 11:19, Janardhan Silwal wrote:
>>>>> Hi community,
>>>>> 
>>>>> I am trying to get littlefs running on a NOR flash memory using the MTD 
>>>>> driver, on a STM32F4 chip.
>>>>> 
>>>>> I had some bottlenecks in the implementation as I am an out-and-out 
>>>>> novice when it comes to Nuttx.
>>>>> I have written a custom driver for the flash, which is working with MTD, 
>>>>> as  I couldn't find the exact driver for the flash installed on my system.
>>>>> 
>>>>> Now I need some guidance on where to start for linking LittleFS to MTD 
>>>>> and the rest..
>>>>> 
>>>>> Best Regards,
>>>>> Janardhan Silwal
>>>>> 
> 
> --
> B.Walter  https://www.bwct.de
> Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.

Re: LittleFS Implementation using MTD for NOR flash

[Tim Hardisty]

FYI - if you type the / character in menuconfig it will allow you to 
search for things (e.g. /MT25 will show two entries relating to MT25 
memory - the MTD settings and the actual flash ID of the device you're 
using (which will need to exist in the relevant driver code of course - 
so with your code editor search all files in the project for MT25Q 
related data and you'll find the data in m25px.c I think)


On 28/12/2023 14:28, Janardhan Silwal wrote:

which driver did you use?
I didn't see MT25QL SPI flash in menu config so I went ahead and wrote one!

Best regards,
Janardhan
____
From: Tim Hardisty
Sent: Thursday, December 28, 2023 19:15
To:dev@nuttx.apache.org  
Subject: Re: LittleFS Implementation using MTD for NOR flash

I have only ever used NuttX "directly" with my apps running over it
rather than any other middleware or anything, so I can't answer that.

My board has been fitted with a MT25QL01GBBB8ESF, and has worked fine,
so your flash is most likely supported already?

On 28/12/2023 12:12, Janardhan Silwal wrote:

Hi,

I am using MT25QL, 1Gbit series flash memory.

Thanks for the template.
Would running in this format over the middleware running over nuttx also follow 
the same approach?

Best Regards,
Janardhan
________
From: Tim Hardisty
Sent: Thursday, December 28, 2023 17:31
To:dev@nuttx.apache.org   
Subject: Re: LittleFS Implementation using MTD for NOR flash

Hi,

What flash are you using out of interest?

But, the basic approach (in or called from your board bringup for
example) is:


spi_flash= sam_spibus_initialize(PORT); /* this call is arch dependent */
if(!spi_flash)
{
/* Do something */
}
#ifdefined(CONFIG_MTD_M25P)
mtd = m25p_initialize(spi_flash, MINOR);
#elifdefined(CONFIG_MTD_GD25)
mtd = gd25_initialize(spi_flash, MINOR);
#elif defined(CONFIG_MTD_YOURFLASHTYPE)
/* etc */
#endif
if(!mtd)
{
/* Do something */
}
#ifdefined(CONFIG_FS_LITTLEFS)
/* Mount the LittleFS file system */
ret = register_mtddriver("/dev/flash", mtd, 0755, NULL);
if(ret < 0)
{
/* Do something */
}
ret = nx_mount("/dev/flash", "/mnt/flash", "littlefs", 0, "autoformat");
if(ret < 0)
{
/* Do something */
}

That was a copy/paste/edit or my own code so please forgive any typo errors!

On 28/12/2023 11:19, Janardhan Silwal wrote:

Hi community,

I am trying to get littlefs running on a NOR flash memory using the MTD driver, 
on a STM32F4 chip.

I had some bottlenecks in the implementation as I am an out-and-out novice when 
it comes to Nuttx.
I have written a custom driver for the flash, which is working with MTD, as  I 
couldn't find the exact driver for the flash installed on my system.

Now I need some guidance on where to start for linking LittleFS to MTD and the 
rest..

Best Regards,
Janardhan Silwal

Re: LittleFS Implementation using MTD for NOR flash

[Tim Hardisty]

Device Drivers -> Memory Technology Device (MTD) Support -> SPI-based 
M25P/MT25Q


On 28/12/2023 14:28, Janardhan Silwal wrote:

which driver did you use?
I didn't see MT25QL SPI flash in menu config so I went ahead and wrote one!

Best regards,
Janardhan
____
From: Tim Hardisty
Sent: Thursday, December 28, 2023 19:15
To:dev@nuttx.apache.org  
Subject: Re: LittleFS Implementation using MTD for NOR flash

I have only ever used NuttX "directly" with my apps running over it
rather than any other middleware or anything, so I can't answer that.

My board has been fitted with a MT25QL01GBBB8ESF, and has worked fine,
so your flash is most likely supported already?

On 28/12/2023 12:12, Janardhan Silwal wrote:

Hi,

I am using MT25QL, 1Gbit series flash memory.

Thanks for the template.
Would running in this format over the middleware running over nuttx also follow 
the same approach?

Best Regards,
Janardhan
________
From: Tim Hardisty
Sent: Thursday, December 28, 2023 17:31
To:dev@nuttx.apache.org   
Subject: Re: LittleFS Implementation using MTD for NOR flash

Hi,

What flash are you using out of interest?

But, the basic approach (in or called from your board bringup for
example) is:


spi_flash= sam_spibus_initialize(PORT); /* this call is arch dependent */
if(!spi_flash)
{
/* Do something */
}
#ifdefined(CONFIG_MTD_M25P)
mtd = m25p_initialize(spi_flash, MINOR);
#elifdefined(CONFIG_MTD_GD25)
mtd = gd25_initialize(spi_flash, MINOR);
#elif defined(CONFIG_MTD_YOURFLASHTYPE)
/* etc */
#endif
if(!mtd)
{
/* Do something */
}
#ifdefined(CONFIG_FS_LITTLEFS)
/* Mount the LittleFS file system */
ret = register_mtddriver("/dev/flash", mtd, 0755, NULL);
if(ret < 0)
{
/* Do something */
}
ret = nx_mount("/dev/flash", "/mnt/flash", "littlefs", 0, "autoformat");
if(ret < 0)
{
/* Do something */
}

That was a copy/paste/edit or my own code so please forgive any typo errors!

On 28/12/2023 11:19, Janardhan Silwal wrote:

Hi community,

I am trying to get littlefs running on a NOR flash memory using the MTD driver, 
on a STM32F4 chip.

I had some bottlenecks in the implementation as I am an out-and-out novice when 
it comes to Nuttx.
I have written a custom driver for the flash, which is working with MTD, as  I 
couldn't find the exact driver for the flash installed on my system.

Now I need some guidance on where to start for linking LittleFS to MTD and the 
rest..

Best Regards,
Janardhan Silwal

Re: LittleFS Implementation using MTD for NOR flash

[Tim Hardisty]

I have only ever used NuttX "directly" with my apps running over it 
rather than any other middleware or anything, so I can't answer that.


My board has been fitted with a MT25QL01GBBB8ESF, and has worked fine, 
so your flash is most likely supported already?


On 28/12/2023 12:12, Janardhan Silwal wrote:

Hi,

I am using MT25QL, 1Gbit series flash memory.

Thanks for the template.
Would running in this format over the middleware running over nuttx also follow 
the same approach?

Best Regards,
Janardhan
____
From: Tim Hardisty
Sent: Thursday, December 28, 2023 17:31
To:dev@nuttx.apache.org  
Subject: Re: LittleFS Implementation using MTD for NOR flash

Hi,

What flash are you using out of interest?

But, the basic approach (in or called from your board bringup for
example) is:


spi_flash= sam_spibus_initialize(PORT); /* this call is arch dependent */
if(!spi_flash)
{
/* Do something */
}
#ifdefined(CONFIG_MTD_M25P)
mtd = m25p_initialize(spi_flash, MINOR);
#elifdefined(CONFIG_MTD_GD25)
mtd = gd25_initialize(spi_flash, MINOR);
#elif defined(CONFIG_MTD_YOURFLASHTYPE)
/* etc */
#endif
if(!mtd)
{
/* Do something */
}
#ifdefined(CONFIG_FS_LITTLEFS)
/* Mount the LittleFS file system */
ret = register_mtddriver("/dev/flash", mtd, 0755, NULL);
if(ret < 0)
{
/* Do something */
}
ret = nx_mount("/dev/flash", "/mnt/flash", "littlefs", 0, "autoformat");
if(ret < 0)
{
/* Do something */
}

That was a copy/paste/edit or my own code so please forgive any typo errors!

On 28/12/2023 11:19, Janardhan Silwal wrote:

Hi community,

I am trying to get littlefs running on a NOR flash memory using the MTD driver, 
on a STM32F4 chip.

I had some bottlenecks in the implementation as I am an out-and-out novice when 
it comes to Nuttx.
I have written a custom driver for the flash, which is working with MTD, as  I 
couldn't find the exact driver for the flash installed on my system.

Now I need some guidance on where to start for linking LittleFS to MTD and the 
rest..

Best Regards,
Janardhan Silwal

Re: LittleFS Implementation using MTD for NOR flash

[Tim Hardisty]

Hi,

What flash are you using out of interest?

But, the basic approach (in or called from your board bringup for 
example) is:



spi_flash= sam_spibus_initialize(PORT); /* this call is arch dependent */
if(!spi_flash)
{
/* Do something */
}
#ifdefined(CONFIG_MTD_M25P)
mtd = m25p_initialize(spi_flash, MINOR);
#elifdefined(CONFIG_MTD_GD25)
mtd = gd25_initialize(spi_flash, MINOR);
#elif defined(CONFIG_MTD_YOURFLASHTYPE)
/* etc */
#endif
if(!mtd)
{
/* Do something */
}
#ifdefined(CONFIG_FS_LITTLEFS)
/* Mount the LittleFS file system */
ret = register_mtddriver("/dev/flash", mtd, 0755, NULL);
if(ret < 0)
{
/* Do something */
}
ret = nx_mount("/dev/flash", "/mnt/flash", "littlefs", 0, "autoformat");
if(ret < 0)
{
/* Do something */
}

That was a copy/paste/edit or my own code so please forgive any typo errors!

On 28/12/2023 11:19, Janardhan Silwal wrote:

Hi community,

I am trying to get littlefs running on a NOR flash memory using the MTD driver, 
on a STM32F4 chip.

I had some bottlenecks in the implementation as I am an out-and-out novice when 
it comes to Nuttx.
I have written a custom driver for the flash, which is working with MTD, as  I 
couldn't find the exact driver for the flash installed on my system.

Now I need some guidance on where to start for linking LittleFS to MTD and the 
rest..

Best Regards,
Janardhan Silwal

Re: SPI EEPROM, losetup, LittleFS

[Tim Hardisty]

I will look at lomtd, thanks. But if littlefs is not suitable (a quick 
look and it seemed it might be a reasonably choice for a 16KiB EEPROM?) 
is there an FS in NuttX that is suitable? "Out there" I find NASA's EEFS 
and one or two others I could try (and submit to NuttX; depending on 
licensing of course) but quicker to try/use something we already have of 
course.


On 16/12/2023 04:10, Xiang Xiao wrote:

On Fri, Dec 15, 2023 at 5:17 PM Sebastien Lorquet
wrote:


Hi,

I dont think you can use losetup to create a mtd device. loop devices
are regular block devices.


You can use lomtd to setup a mtd device loop:
https://github.com/apache/nuttx-apps/blob/master/nshlib/nsh_fscmds.c#L1144-L1306





This will only work if littlefs can mount a
block device (no idea if thats possible)



Yes, littlefs can work with block devices directly, the difference between
mtd and block is hidden by littlefs wrapper.
Of course, littlefs isn't an efficient solution for block devices since
the wear leveling built inside littlefs is useless and
harms the performance a lot.



what you need is an adaptation layer that will implement a mtd device on
an eeprom.

You can duplicate a spi flash driver, and change its read/erase/write
routines (and initialization) by copying code from a spi eeprom driver.

Sebastien.

Le 14/12/2023 à 19:13, Tim Hardisty a écrit :

Question first, then explanation.

How do I use losetup (which is what I think I need) with a character
memory device and mount an FS on it? SPI EEPROM and LittleFS
specifically.

Yes, it's a bad idea, probably, but I just want to have a play and
lack of NuttX/POSIX/Linux knowledge has bitten my behind again. This
is perhaps the 3rd time over the years I've asked but even checking
the dev emails archive and I can't find what I need.

SPI EEPROM is correctly registered as /dev/at25 and I can
read/write/etc to it as a character device. NB: it does not initialize
in the same way as an I2C EEPROM so you can't directly initialise it
as an mtd. It is for storage of settings, and some of the values may
change 10,000's time over the life of the product, hence EEPROM with
1,000,000+ write cycles.

But there is then no wear levelling or anything like that as just a
character device, so I thought I'd have a play, and LittleFS has a
small minimum sector size and *might* work. A quick Google turns up
the same Linux-related losetup examples that don't seem relevant; my
Googling skills are probably as bad as those of my software
engineering .

Any pointers/suggestions please?

SPI EEPROM, losetup, LittleFS

[Tim Hardisty]

Question first, then explanation.

How do I use losetup (which is what I think I need) with a character 
memory device and mount an FS on it? SPI EEPROM and LittleFS specifically.


Yes, it's a bad idea, probably, but I just want to have a play and lack 
of NuttX/POSIX/Linux knowledge has bitten my behind again. This is 
perhaps the 3rd time over the years I've asked but even checking the dev 
emails archive and I can't find what I need.


SPI EEPROM is correctly registered as /dev/at25 and I can read/write/etc 
to it as a character device. NB: it does not initialize in the same way 
as an I2C EEPROM so you can't directly initialise it as an mtd. It is 
for storage of settings, and some of the values may change 10,000's time 
over the life of the product, hence EEPROM with 1,000,000+ write cycles.


But there is then no wear levelling or anything like that as just a 
character device, so I thought I'd have a play, and LittleFS has a small 
minimum sector size and *might* work. A quick Google turns up the same 
Linux-related losetup examples that don't seem relevant; my Googling 
skills are probably as bad as those of my software engineering 
.


Any pointers/suggestions please?

debugassert vs assert in apps

[Tim Hardisty]

Hi,

I'm wondering if there is an "approved" usage of assert vs debugassert 
for files/apps in the nuttx-apps repo?


My thinking is:

 * use debugassert if a function in apps would only fail if the calling
   code, probably (or possibly only) if other functions within apps,
   rather than an unknown higher level app,  have done something dumb
   that should be picked up during nuttx-apps development and so should
   not make it through to final code; but if they do, that's the fault
   of the developer for not turning on debug asserts!!
 * use assert if the error would cause the obviously unknown
   higher-level calling app someone's writing to fail if the error was
   allowed to pass unchecked, so the developer of that higher level app
   can deal with it programmatically.

That might almost suggest that debugassert() is for private functions 
and assert() is for public ones?


Probably over-thinking it as usual, but I'm never afraid to ask :)

Thanks!

TimJTi.

Dumb question re: "full path", out of tree board

[Tim Hardisty]

Hi,

I have an out-of-tree custom board (which lives resides in my main NuttX 
folder as  ./../CustomBoards/boardname). I use checkpatch.sh even on my 
board software in that locations as I like to be consistent, but it 
complains that the path (line 2 of the header comment) must begin with 
the root directory as it's a relative path other than "nuttx".


Fair enough, but I can't work out what path makes checkpatch.sh happy!

For CustomApps I use a symbolic link within the apps folder to "MyApps" 
and have line 2 of my source files as apps/MyApps/appname/file.c and 
it's happy with that but I just can't figure out what the custom board 
header file path should be stated as.


I tried the symbolic link trick for this, too, but it didn't seem to 
work, with the same error reported no matter what I put in line 2: and, 
anyway, they are a pain since my link in apps gets trashed if I do a new 
branch based on master (unless I'm missing a trick there?).


Thanks!

Re: Code donation

[Tim Hardisty]

Thanks!

Question for someone: not sure whether to put this in (e.g.) 
apps/system/settings (which is where i2ctool, nxplayer etc live, for 
example) or add a new folder apps/utils/settings. What might be "best"?


On 30/10/2023 10:49, Fotis Panagiotopoulos wrote:

I just pushed the latest changes.

Functionality is identical.

Only minor improvements and bug fixes are included in the latest commit.

On Mon, Oct 30, 2023 at 12:06 PM Fotis Panagiotopoulos 
wrote:


Hello Tim!

Thank you for your interest in this.

(I am replying in the list for the moment, in case anyone else is
interested...)

As far as I know, no effort has been taken on this.
I will be glad to help you porting the settings storage to NuttX.

The published repo is not maintained, so I will update it later today with
all the latest
changes/fixes in this specific app you are interested in.

---

License-wise, this is 100% original work by me, so I guess there is
nothing to concert us.

It can be committed directly to the apps repo under Apache license.

---

Regarding the parsers.

Currently it supports two parsers ("storages" as they are refered in
code): binary and text.

The binary storage, directly dumps the RAM contents in a file.
This is speed-efficient, but may waste a bit of space, and it is not very
portable.

For example, a save made in a little-endian machine may not work in a
big-endian one.
Similarly, the read and write implementations need to have the exact same
cofniguration (e.g. key size).

I typically use this to store settings directly in the MCU's Flash memory.
So, none of the above limitations matter.


The text storage solves all of the above and makes the data
human-readable, in expense of some
more CPU time.

I typically use the text storage in an SD card file.


More specifically, I usually use **both** storages at the same time.
The text one is human-readable and easy to update (e.g. get the SD on your
computer, and change anything you want),
while the binary one is there for speed and reliability (SD card
failed/removed, the app can still access the settings).

The settings library can reliably syncrhonize multiple storages together,
and make them act as one.

---

My intention was to also add XML and JSON (and I have provided two parser
implementations), but I never found the time.
I guess adding YAML will be fairly trivial.

I am willing to help add any new parsers that may be needed.

---

So, shall we create an issue in apps repo, to cooperate development?

On Mon, Oct 30, 2023 at 10:10 AM alin.jerpe...@sony.com <
alin.jerpe...@sony.com> wrote:


Hi Tim,

I am sorry but it slipped by agenda.
Thanks for looking at this topic. Please take your time and submit when
you are ready.

Best regards
Alin


From: Tim Hardisty 
Sent: den 28 oktober 2023 12:10
To: dev@nuttx.apache.org
Subject: Re: Code donation

Hi, Did anyone else make any progress with porting your settings code to
NuttX Apps? It's taken a while but I am at long last looking to add a
settings function to my new app and this still looks like it'll fit the
bill nicely. If not, I will
ZjQcmQRYFpfptBannerStart
This message is from an unknown sender
You have not previously corresponded with this sender and they are
external to Sony
ZjQcmQRYFpfptBannerEnd

Hi,



Did anyone else make any progress with porting your settings code to

NuttX Apps? It's taken a while but I am at long last looking to add a

settings function to my new app and this still looks like it'll fit the

bill nicely.



If not, I will set it up as an app, make sure it works, and submit it

for review hopefully in the next few weeks. I won't add YAML as yet,

just binary - my current think is to use a YAML parser between the user

and this function rather than storing YAML directly, but not 100%

decided yet.



On 05/12/2022 11:22, Fotis Panagiotopoulos wrote:


Hello!
Thank you for your interest in this!
As requested, I created a temporal repository and uploaded all the code
there.
https://github.com/fjpanag/code_for_nuttx<

https://github.com/fjpanag/code_for_nuttx>


I have added a NOTICE file in each subdir, with some basic information.
Please contact me before starting any work, to provide you with help and
coordinate the effort.
Better yet, you may open a Github issue for the piece of software that

you


would like to help porting.
Alan,
I would love to cooperate with you in this effort.
Pick your target!
Alin,
I would really like to see my MQTT broker become part of NuttX.
Alternatively, you can have a look at the XML or JSON parsers, which

are of


general usefulness,
and the porting effort would be very very minimal.
Tim,
Thank you for your interest in the settings storage.
It is a very useful and versatile piece of software. In fact, I have

used


it in all my projects over the last 5-6 years.
I also thought about YAML before, but never got to actually implementing
this.
I suggest you first add a YAML parser to N

Re: Code donation

[Tim Hardisty]

Hi,

Did anyone else make any progress with porting your settings code to 
NuttX Apps? It's taken a while but I am at long last looking to add a 
settings function to my new app and this still looks like it'll fit the 
bill nicely.


If not, I will set it up as an app, make sure it works, and submit it 
for review hopefully in the next few weeks. I won't add YAML as yet, 
just binary - my current think is to use a YAML parser between the user 
and this function rather than storing YAML directly, but not 100% 
decided yet.


On 05/12/2022 11:22, Fotis Panagiotopoulos wrote:

Hello!

Thank you for your interest in this!

As requested, I created a temporal repository and uploaded all the code
there.

https://github.com/fjpanag/code_for_nuttx

I have added a NOTICE file in each subdir, with some basic information.
Please contact me before starting any work, to provide you with help and
coordinate the effort.
Better yet, you may open a Github issue for the piece of software that you
would like to help porting.


Alan,
I would love to cooperate with you in this effort.
Pick your target!


Alin,
I would really like to see my MQTT broker become part of NuttX.

Alternatively, you can have a look at the XML or JSON parsers, which are of
general usefulness,
and the porting effort would be very very minimal.


Tim,
Thank you for your interest in the settings storage.
It is a very useful and versatile piece of software. In fact, I have used
it in all my projects over the last 5-6 years.

I also thought about YAML before, but never got to actually implementing
this.

I suggest you first add a YAML parser to NuttX (maybe similarly to JSON and
XML, if they get accepted),
and then use it in the settings storage. It would be best not to couple
these two softwares so someone
may use one without the other. But, nevertheless, it is your call...

If you provide me with a YAML parser, I believe that I can develop for you
a new settings storage that uses this parser.

Fotis

On Mon, Dec 5, 2022 at 12:12 AM Tim Hardisty
wrote:


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

Re: Queues

[Tim Hardisty]

And FIFO rather than deterministic 


> On 19 Oct 2023, at 20:49, Petro Karashchenko  
> wrote:
> 
> Hi,
> 
> I do not fully understand if you are looking from Application or Kernel
> perspective?
> Also I do not know if the CAN driver is capable of providing you with
> information when the message is actually transmitted on the bus. I mean
> that for example CAN peripheral may have multiple TX buffers and you can
> put your message into one of those, but it can loose internal TX
> arbitration if CAN peripheral picks a buffer holding the lowest CAN-ID
> first, so the mechanism how do you want to ensure that messages are
> transmitted with the chronological order is not clear to me, unless you use
> a special version of the peripheral driver that uses a single TX buffer.
> 
> Best regards,
> Petro
> 
> чт, 19 жовт. 2023 р. о 22:35 Tim Hardisty  пише:
> 
>> Hello helpful people. I am not sure if this is a POSIX or NuttX
>> question, so apologies it it's something I "should" know.
>> 
>> I am looking for a methodology - ideally portable (POSIX) - perhaps a
>> queue, to hold a list of messages (CANbus) that need to be transmitted
>> in the correct chronological order. I have been using linked lists for
>> other things and just about have that sussed (but they do my head in to
>> be honest!) but it doesn't seem quite right for this. I am thinking the
>> set of "dq_" functions are possibly a good solution but I can't find
>> much information/documentation on this and am not sure if its just a
>> NuttX-specific thing, although I see it used heavily for audio playback?
>> 
>> Am I on the right track, or should I be looking at something else?
>> 
>> In essence I want to add (queue?) entries (pointers to message structs)
>> that need to be sent (on a POSIX timer, which I have setup and working
>> well) and once each is transmitted it'll be removed until added again if
>> needed. I want it to be as generic as possible.
>> 
>> Thanks!
>> 
>> TimH (aka TimJTi...new email account)
>> 

Re: Queues

[Tim Hardisty]

Application level. Lets assume the CAN driver deals with everything else (Big 
assumption actually but let’s go with it)


> On 19 Oct 2023, at 20:49, Petro Karashchenko  
> wrote:
> 
> Hi,
> 
> I do not fully understand if you are looking from Application or Kernel
> perspective?
> Also I do not know if the CAN driver is capable of providing you with
> information when the message is actually transmitted on the bus. I mean
> that for example CAN peripheral may have multiple TX buffers and you can
> put your message into one of those, but it can loose internal TX
> arbitration if CAN peripheral picks a buffer holding the lowest CAN-ID
> first, so the mechanism how do you want to ensure that messages are
> transmitted with the chronological order is not clear to me, unless you use
> a special version of the peripheral driver that uses a single TX buffer.
> 
> Best regards,
> Petro
> 
> чт, 19 жовт. 2023 р. о 22:35 Tim Hardisty  пише:
> 
>> Hello helpful people. I am not sure if this is a POSIX or NuttX
>> question, so apologies it it's something I "should" know.
>> 
>> I am looking for a methodology - ideally portable (POSIX) - perhaps a
>> queue, to hold a list of messages (CANbus) that need to be transmitted
>> in the correct chronological order. I have been using linked lists for
>> other things and just about have that sussed (but they do my head in to
>> be honest!) but it doesn't seem quite right for this. I am thinking the
>> set of "dq_" functions are possibly a good solution but I can't find
>> much information/documentation on this and am not sure if its just a
>> NuttX-specific thing, although I see it used heavily for audio playback?
>> 
>> Am I on the right track, or should I be looking at something else?
>> 
>> In essence I want to add (queue?) entries (pointers to message structs)
>> that need to be sent (on a POSIX timer, which I have setup and working
>> well) and once each is transmitted it'll be removed until added again if
>> needed. I want it to be as generic as possible.
>> 
>> Thanks!
>> 
>> TimH (aka TimJTi...new email account)
>> 

Queues

[Tim Hardisty]

Hello helpful people. I am not sure if this is a POSIX or NuttX 
question, so apologies it it's something I "should" know.


I am looking for a methodology - ideally portable (POSIX) - perhaps a 
queue, to hold a list of messages (CANbus) that need to be transmitted 
in the correct chronological order. I have been using linked lists for 
other things and just about have that sussed (but they do my head in to 
be honest!) but it doesn't seem quite right for this. I am thinking the 
set of "dq_" functions are possibly a good solution but I can't find 
much information/documentation on this and am not sure if its just a 
NuttX-specific thing, although I see it used heavily for audio playback?


Am I on the right track, or should I be looking at something else?

In essence I want to add (queue?) entries (pointers to message structs) 
that need to be sent (on a POSIX timer, which I have setup and working 
well) and once each is transmitted it'll be removed until added again if 
needed. I want it to be as generic as possible.


Thanks!

TimH (aka TimJTi...new email account)

Video playback

[Tim Hardisty]

One of my many, no-doubt, dumb/inexperienced questions

NuttX has nxplayer for audio, with support for .wav files etc. But...

...is there a native/built-in way of playing video files (.mp4 for 
example)? I know I can write a video file frame by frame, but hopefully 
I don't need to? Can't find anything as yet.

Re: write method for audio driver?

[Tim Hardisty]

On 27/08/2023 23:53, Gregory Nutt wrote:


On 8/27/2023 4:22 PM, Tim Hardisty wrote:
The classD driver DOES register itself as /dev/audio/pcm0, and works 
correctly as such with nx_player.


You are mistaken.  The Class D driver does not register itself as a 
character driver.  grep -r register_driver arch/arm/src/sama5/ proves 
that is true.


The logic that registers /dev/audio/pcm0 is in audio/audio.c.

audio/Kconfig defines the directory.  Nothing is the code base except 
files in audio/ knows about that directory or is capable of registering 
a driver there.


    config AUDIO_DEV_PATH
         string "Base path for Audio devices"
         default "/dev/audio"

    audio/audio.c:

    audio/audio.c:  FAR const char *devname = CONFIG_AUDIO_DEV_PATH;

Most certainly the class D lower half cannot be register as a driver. 
That is totally impossible.  It is not a character driver; it is only 
the lower half of a driver.  It contains no usable driver logic; only 
the low level hardware interface.


You must be using audio_register() in your board start up logic. That is 
part of the configuration of the audio chain.  It does NOT produce a PCM 
driver.  The driver is the audio chain that starts in audio/audio.c. 
Class D is the terminus of the audio chain and cannot be accessed using 
/dev/audio/pcm0.  It has that name only because that is the name that 
you gave it when you called audio_register.  The entire audio chain 
supports PCM, but the driver is the audio.c driver.



he conversions are wav (or mp3 etc) to pcm.

Don’t if we’re talking cross purposes or the classd driver works in a 
way it shouldn’t!!!


In the previous email I listed the only place in the code base where a 
driver is registered at /dev/audio/pcm0 for any SAMA5 board.  The only 
cases in the code base do PCM to WAV conversion. That is done by 
audio/pcm_decode.c.  You may have some other audio logic that uses the 
Class D to handle PCM directly, I don't know. If so, it is not in the 
source tree.  Certainly that driver is not sam_classd.c.


sam_classd.c is not a driver in the POSIX sense.  It is only a hardware 
lower half.  It could never possibly be registered as a driver.  It 
doesn't support the standard driver calls.  In the terminology of the 
audio subsystem, it is called an audio driver. It is the sink at the end 
of the audio chain managed by the logic in audio/.



I am indeed mistaken. Guilty as charged! I tend to think in 
"generalisations" and "know" that the lower half ClassD "driver" allows 
for /dev/audio/pcm0 to be registered just did't (bother to) think about 
the exact details of it. I apologise.


So:

1) A basic character write to /dev/audio/pcm0 is not supported by any 
existing lower half driver so it is not good for me to add this to 
ClassD for any reason.
2) The upper-half driver only deals with audio buffers, sent to the 
lower half driver via buffer enqueuing.
3) So I either add a function to my code to create sinewaves on the fly 
and write to a buffer and send these to /dev/audio/pcm0 correctly; or I 
extend/modify/make-use-of/base-new-code-on existing NuttX apps to do the 
same.


Have I got it now? I don't want to use romfs .wav files as that is not 
flexible enough (as I can't predict all the tones I *might* want).

Re: write method for audio driver?

[Tim Hardisty]

On 27/08/2023 23:56, Gregory Nutt wrote:


On 8/27/2023 4:24 PM, Tim Hardisty wrote:

SAMA5D2 specific, I should add.


There is no support for the Class D driver for any SAMA5D2 board in the 
source tree.



Indeed - it's a custom/proprietary board which is why I added and 
contributed the missing ClassD support and now need to make full use of it.

Re: write method for audio driver?

[Tim Hardisty]

On 28/08/2023 02:49, Nathan Hartman wrote:

On Sun, Aug 27, 2023 at 6:24 PM Tim Hardisty  wrote:


SAMA5D2 specific, I should add.



On 27 Aug 2023, at 23:23, Tim Hardisty  wrote:

The classD driver DOES register itself as /dev/audio/pcm0, and works

correctly as such with nx_player.


The conversions are wav (or mp3 etc) to pcm.

Don’t if we’re talking cross purposes or the classd driver works in a

way it shouldn’t!!!




I don't know whether you've had a chance to read [1] yet, but if not, it
might help visualize the two-part structure of device drivers in NuttX. (If
you've already read it, then never mind, and apologies for the noise. :-)

[1]
https://nuttx.apache.org/docs/latest/components/drivers/index.html

Cheers,
Nathan

Thanks Nathan - I have read it but not recently enough I fear! It's good 
noise!

Re: write method for audio driver?

[Tim Hardisty]

SAMA5D2 specific, I should add.


> On 27 Aug 2023, at 23:23, Tim Hardisty  wrote:
> 
> The classD driver DOES register itself as /dev/audio/pcm0, and works 
> correctly as such with nx_player.
> 
> The conversions are wav (or mp3 etc) to pcm.
> 
> Don’t if we’re talking cross purposes or the classd driver works in a way it 
> shouldn’t!!!
> 
>> On 27 Aug 2023, at 23:00, Gregory Nutt  wrote:
>> 
>> Also, I don't think the /dev/audio/pcm0 device you are talking about is 
>> what you think it is.  It is a character driver but not the Class D lower 
>> half.  So, yes it can be opened.
>> 
>> /Caveat:  It has been ages since I worked with the audio subsystem so I 
>> might be completely wrong./
>> 
>> /dev/audio/pcm0  is the audio subsystem interface device.  The "pcm" 
>> indicates that it used the PCM software decoder (that will convert PCM file 
>> data to WAV).  It gets set up like:
>> 
>>  boards/arm/sama5/sama5d4-ek/src/sam_wm8904.c:
>> 
>> pcm = pcm_decode_initialize(wm8904);
>> snprintf(devname, 12, "pcm%d",  minor);
>> ret = audio_register(devname, pcm);
>> 
>> And a character driver is registered by the audio subsystem in audio/audio.c:
>> 
>>  int audio_register(FAR const char *name, FAR struct
>>  audio_lowerhalf_s *dev)
>>  {
>>  ...
>> 
>> audinfo("Registering %s\n", path);
>> return register_driver(path, &g_audioops, 0666, upper);
>>  }
>> 
>> Where g_audioops is the character driver operations structure:
>> 
>>  static const struct file_operations g_audioops =
>>  {
>> audio_open,  /* open */
>> audio_close, /* close */
>> audio_read,  /* read */
>> audio_write, /* write */
>> NULL,/* seek */
>> audio_ioctl, /* ioctl */
>>  };
>> 
>> So the registered pcm0 is the standard audio buffer chain configured for PCM 
>> file to WAV conversion and terminating with a wm8904 DAC.
>> 
>> I don't believe that there is any way to get the Class D audio_ops_s as a 
>> driver under /dev.  Nothing like that is supported.
>> 

Re: write method for audio driver?

[Tim Hardisty]

The classD driver DOES register itself as /dev/audio/pcm0, and works correctly 
as such with nx_player.

The conversions are wav (or mp3 etc) to pcm.

Don’t if we’re talking cross purposes or the classd driver works in a way it 
shouldn’t!!!

> On 27 Aug 2023, at 23:00, Gregory Nutt  wrote:
> 
> Also, I don't think the /dev/audio/pcm0 device you are talking about is what 
> you think it is.  It is a character driver but not the Class D lower half.  
> So, yes it can be opened.
> 
> /Caveat:  It has been ages since I worked with the audio subsystem so I might 
> be completely wrong./
> 
> /dev/audio/pcm0  is the audio subsystem interface device.  The "pcm" 
> indicates that it used the PCM software decoder (that will convert PCM file 
> data to WAV).  It gets set up like:
> 
>   boards/arm/sama5/sama5d4-ek/src/sam_wm8904.c:
> 
>  pcm = pcm_decode_initialize(wm8904);
>  snprintf(devname, 12, "pcm%d",  minor);
>  ret = audio_register(devname, pcm);
> 
> And a character driver is registered by the audio subsystem in audio/audio.c:
> 
>   int audio_register(FAR const char *name, FAR struct
>   audio_lowerhalf_s *dev)
>   {
>   ...
> 
>  audinfo("Registering %s\n", path);
>  return register_driver(path, &g_audioops, 0666, upper);
>   }
> 
> Where g_audioops is the character driver operations structure:
> 
>   static const struct file_operations g_audioops =
>   {
>  audio_open,  /* open */
>  audio_close, /* close */
>  audio_read,  /* read */
>  audio_write, /* write */
>  NULL,/* seek */
>  audio_ioctl, /* ioctl */
>   };
> 
> So the registered pcm0 is the standard audio buffer chain configured for PCM 
> file to WAV conversion and terminating with a wm8904 DAC.
> 
> I don't believe that there is any way to get the Class D audio_ops_s as a 
> driver under /dev.  Nothing like that is supported.
> 

Re: write method for audio driver?

[Tim Hardisty]

Or am I completely missing the point and I just need to use the nxaudio 
system!!??

On 27/08/2023 12:25, Tim Hardisty wrote:

Looking a little more at the write function of audio_ops_s it is not used by 
any existing driver and is documented to be for device-specific 
information...so it is not portable in terms of playing tones by simply writing 
PCM data word by word. I get that now.

So I'm thinking the right way is possibly either:

1) Complete the "tone" support of nxplayer - it exists as a command parameter 
but has no underlying code/functions

2) create a tone player as a standalone (example) app that opens 
/dev/audio/pcm%d and makes use of the audio_ops_s functions and ioctls to set 
up a NuttX sound system compliant device and play tones. That is then portable 
and can be used with any supported audio device without having to use nxplayer 
in its entirety. e.g you could run, from nsh something like: "pcmtone  
  " so "pcm_tone /dev/pcm0 48 1000 500" to play a 
1kHz tone using 48 sampling for 500ms. Looks like there are similar functions 
"out there" I could reference.

Is that more along the right lines perhaps?

On 27/08/2023 11:17, Tim Hardisty wrote:

Thanks Gregory. The existing ClassD driver is registered as /dev/audio/pcm0 and 
is a PCM device not PWM. It has the "usual" audio ops to configure it, 
start/stop/pause/enqueue etc. It is exposed via ioctls so does have a user 
interface; that is how buffers of audio are passed to it. Is that an 
OS-function only, hence your comments that it should not be exposed to the user 
and I'm muddling things up?

The declaration of the audio_ops_s struct also includes a read and write 
function that are typically defined as NULL in these audio drivers. That's what 
I was thinking of adding, but perhaps I'm am not understanding that 
/dev/audio/pcm0 can't (shouldn't) actually be opened as a character driver?

Sorry for the dumb questions!

On 26/08/2023 23:10, Gregory Nutt wrote:

On 8/26/2023 12:18 PM, Tim Hardisty wrote:
This is, I'm sure, more a generic POSIX question than NuttX-specific but I am 
still not that familiar with either!

When I wrote the SAMA5D2 ClassD audio driver I followed the methods appropriate 
for using "apb" so it works well with nxplayer (for example).

But I want to play simple audio tones, from a sine look-up table, and filling a 
buffer and enqueuing it seems over the top.

Is there any reason - from a "correctness" point of view - I couldn't add a 
basic file write function to the driver that allows you to simply fwrite to the 
opened device and have it dump data that way?

A simple piece of code that simply writes to the processor audio sample buffer, 
word at a time, and polls the "ready" bit works 100% fine but this is not 
portable! So if such an interface is not "right" I won't add it :)

I don't think it makes sense to add a write method to the audio driver 
interface.  That is not driver is not POSIX and cannot be exposed as a user 
interface.

I suggest thinking about this in a different way.  How about an audio source 
driver that exposes two interfaces:  (1) The audio interface that is (ONLY) 
used inside of the OS and certain audio applications (which it really 
shouldn't).  An audio driver can be a source of audio data, a sink of audio 
data, or can intercept and modify audio data in the audio chain.  And (2) a 
standard character driver that accepts audio input from application space. The 
character driver is POSIX and does support the write method. So any data 
written via the character driver interface would be treated as audio source 
data.

Re: write method for audio driver?

[Tim Hardisty]

Looking a little more at the write function of audio_ops_s it is not used by 
any existing driver and is documented to be for device-specific 
information...so it is not portable in terms of playing tones by simply writing 
PCM data word by word. I get that now.

So I'm thinking the right way is possibly either:

1) Complete the "tone" support of nxplayer - it exists as a command parameter 
but has no underlying code/functions

2) create a tone player as a standalone (example) app that opens 
/dev/audio/pcm%d and makes use of the audio_ops_s functions and ioctls to set 
up a NuttX sound system compliant device and play tones. That is then portable 
and can be used with any supported audio device without having to use nxplayer 
in its entirety. e.g you could run, from nsh something like: "pcmtone  
  " so "pcm_tone /dev/pcm0 48 1000 500" to play a 
1kHz tone using 48 sampling for 500ms. Looks like there are similar functions 
"out there" I could reference.

Is that more along the right lines perhaps?

On 27/08/2023 11:17, Tim Hardisty wrote:

Thanks Gregory. The existing ClassD driver is registered as /dev/audio/pcm0 and 
is a PCM device not PWM. It has the "usual" audio ops to configure it, 
start/stop/pause/enqueue etc. It is exposed via ioctls so does have a user 
interface; that is how buffers of audio are passed to it. Is that an 
OS-function only, hence your comments that it should not be exposed to the user 
and I'm muddling things up?

The declaration of the audio_ops_s struct also includes a read and write 
function that are typically defined as NULL in these audio drivers. That's what 
I was thinking of adding, but perhaps I'm am not understanding that 
/dev/audio/pcm0 can't (shouldn't) actually be opened as a character driver?

Sorry for the dumb questions!

On 26/08/2023 23:10, Gregory Nutt wrote:

On 8/26/2023 12:18 PM, Tim Hardisty wrote:
This is, I'm sure, more a generic POSIX question than NuttX-specific but I am 
still not that familiar with either!

When I wrote the SAMA5D2 ClassD audio driver I followed the methods appropriate 
for using "apb" so it works well with nxplayer (for example).

But I want to play simple audio tones, from a sine look-up table, and filling a 
buffer and enqueuing it seems over the top.

Is there any reason - from a "correctness" point of view - I couldn't add a 
basic file write function to the driver that allows you to simply fwrite to the 
opened device and have it dump data that way?

A simple piece of code that simply writes to the processor audio sample buffer, 
word at a time, and polls the "ready" bit works 100% fine but this is not 
portable! So if such an interface is not "right" I won't add it :)

I don't think it makes sense to add a write method to the audio driver 
interface.  That is not driver is not POSIX and cannot be exposed as a user 
interface.

I suggest thinking about this in a different way.  How about an audio source 
driver that exposes two interfaces:  (1) The audio interface that is (ONLY) 
used inside of the OS and certain audio applications (which it really 
shouldn't).  An audio driver can be a source of audio data, a sink of audio 
data, or can intercept and modify audio data in the audio chain.  And (2) a 
standard character driver that accepts audio input from application space. The 
character driver is POSIX and does support the write method. So any data 
written via the character driver interface would be treated as audio source 
data.

Re: write method for audio driver?

[Tim Hardisty]

Thanks Gregory. The existing ClassD driver is registered as /dev/audio/pcm0 and 
is a PCM device not PWM. It has the "usual" audio ops to configure it, 
start/stop/pause/enqueue etc. It is exposed via ioctls so does have a user 
interface; that is how buffers of audio are passed to it. Is that an 
OS-function only, hence your comments that it should not be exposed to the user 
and I'm muddling things up?

The declaration of the audio_ops_s struct also includes a read and write 
function that are typically defined as NULL in these audio drivers. That's what 
I was thinking of adding, but perhaps I'm am not understanding that 
/dev/audio/pcm0 can't (shouldn't) actually be opened as a character driver?

Sorry for the dumb questions!

On 26/08/2023 23:10, Gregory Nutt wrote:

On 8/26/2023 12:18 PM, Tim Hardisty wrote:
This is, I'm sure, more a generic POSIX question than NuttX-specific but I am 
still not that familiar with either!

When I wrote the SAMA5D2 ClassD audio driver I followed the methods appropriate 
for using "apb" so it works well with nxplayer (for example).

But I want to play simple audio tones, from a sine look-up table, and filling a 
buffer and enqueuing it seems over the top.

Is there any reason - from a "correctness" point of view - I couldn't add a 
basic file write function to the driver that allows you to simply fwrite to the 
opened device and have it dump data that way?

A simple piece of code that simply writes to the processor audio sample buffer, 
word at a time, and polls the "ready" bit works 100% fine but this is not 
portable! So if such an interface is not "right" I won't add it :)

I don't think it makes sense to add a write method to the audio driver 
interface.  That is not driver is not POSIX and cannot be exposed as a user 
interface.

I suggest thinking about this in a different way.  How about an audio source 
driver that exposes two interfaces:  (1) The audio interface that is (ONLY) 
used inside of the OS and certain audio applications (which it really 
shouldn't).  An audio driver can be a source of audio data, a sink of audio 
data, or can intercept and modify audio data in the audio chain.  And (2) a 
standard character driver that accepts audio input from application space. The 
character driver is POSIX and does support the write method. So any data 
written via the character driver interface would be treated as audio source 
data.

Re: write method for audio driver?

[Tim Hardisty]

Sort of perhaps. The SAMA5D@ needs lots of setting up and the existing driver 
does that with all the usual audio device ioctls and enqueue methods: it works 
just fine using nxplayer and can playback .wav files etc.

But it it is based on creating buffers of audio - the assumption being that you 
are playing back long(ish) streams of audio, so the buffer/queue methods make 
sense.

To play a brief tone it just seems like a lot of hassle to generate a 0.5s 
(say) buffer of sinewave pcm date when it is really only necessary to write it 
sample by sample to the (already configured) ClassD device at /dev/audio/pcm0 
and have the driver manage the buffer and ready flags etc.

I will add other notes in an answer to Gregory's reply to this.

On 27/08/2023 05:59, Tomek CEDRO wrote:

On Sat, Aug 26, 2023, 20:18 Tim Hardisty  wrote:



This is, I'm sure, more a generic POSIX question than NuttX-specific but I
am still not that familiar with either!

When I wrote the SAMA5D2 ClassD audio driver I followed the methods
appropriate for using "apb" so it works well with nxplayer (for example).

But I want to play simple audio tones, from a sine look-up table, and
filling a buffer and enqueuing it seems over the top.

Is there any reason - from a "correctness" point of view - I couldn't add
a basic file write function to the driver that allows you to simply fwrite
to the opened device and have it dump data that way?

A simple piece of code that simply writes to the processor audio sample
buffer, word at a time, and polls the "ready" bit works 100% fine but this
is not portable! So if such an interface is not "right" I won't add it :)




you mean /dev/dsp ?

https://man.freebsd.org/cgi/man.cgi?query=sound&apropos=0&manpath=FreeBSD+13.2-RELEASE+and+Ports

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: write method for audio driver?

[Tim Hardisty]

Thanks Gregory. I looked at that but it produces tones using PWM. The 
ClassD of the SAMA5D2 is a PCM device, so not an immediately obvious match?

On 26/08/2023 23:17, Gregory Nutt wrote:
>
>>> But I want to play simple audio tones, from a sine look-up table, 
>>> and filling a buffer and enqueuing it seems over the top.
>
> If you just want to plane simple audio tones, maybe something 
> drivers/audio/tone.c is what you need?  That is a character driver 
> with a custom tone interface.
>

write method for audio driver?

[Tim Hardisty]

This is, I'm sure, more a generic POSIX question than NuttX-specific but I am 
still not that familiar with either!

When I wrote the SAMA5D2 ClassD audio driver I followed the methods appropriate 
for using "apb" so it works well with nxplayer (for example).

But I want to play simple audio tones, from a sine look-up table, and filling a 
buffer and enqueuing it seems over the top.

Is there any reason - from a "correctness" point of view - I couldn't add a 
basic file write function to the driver that allows you to simply fwrite to the 
opened device and have it dump data that way?

A simple piece of code that simply writes to the processor audio sample buffer, 
word at a time, and polls the "ready" bit works 100% fine but this is not 
portable! So if such an interface is not "right" I won't add it :)

Re: CDC/ACM console data to NuttX corrupted.

[Tim Hardisty]

Thanks Greg, this helps me understand better how it all hangs together.

Regards,

Tim.

> On 17 Aug 2023, at 21:33, Gregory Nutt  wrote:
> 
> 
>> On 8/17/2023 10:34 AM, Tim Hardisty wrote:
>> I have concluded that CDC/ACM will NOT play alongside SYSLOG - most likely 
>> on the SAMA5D2 device, or possibly just on my board for some reason.
>> 
>> Whatever I choose as the SYSLOG output (/dev/ttyS0, ttyS1, ttyFC0 and ttyFC1 
>> all of which are working fine, or even /dev/null) it just ends up garbling 
>> received data from the USB.
>> 
>> I have left CONFIG_CDCACM_NRDREQ=1, disabled SYSLOG and can move forward as 
>> this is only needed for the board test jig, so I don't need a TTL->USB 
>> converter cable to see output.
>> 
>> Can return to it if anyone has any ideas but, if not, will log both as 
>> issues for someone to pick up at some point in the future, maybe.
>> 
>>> On 17/08/2023 16:06, Tim Hardisty wrote:
>>> OK...progress.
>>> 
>>> CDC/ACM console behaves like this if CONFIG_CDCACM_NRDREQS is left at the 
>>> default 4. It needs a given keyboard key to be pressed 4 times to work, 
>>> and/or garbles the text sent. I also found that usbserial example app 
>>> misbehaves in the same way - I thought it was working since random 
>>> characters were being pressed by me to test it...and received as garbled 
>>> random characters and I didn't notice.
>>> 
>>> If set to 1 it works. I do not know why this is.
>>> 
>>> If this is a bug not some configuration error/mismatch I've not spotted 
>>> then I will raise it as an issue.
>>> 
>>> But it doesn't play nicely with syslog...I'm investigating that now.
>>> 
> Certainly you cannot use the console device for syslog because it there is no 
> console device when you use USB for the console output.  Non-console TTYs are 
> not available at power up.  Only the console serial device (if there is one) 
> is initialized in that case.  They do become available later, but after 
> syslog is already been initialized.  So there may be some initialization 
> issue in the way you use it.
> 
> I think there is an option to force late syslog initialization, but I can't 
> remember now (and this has probably been redesigned since I wrote it anyway).
> 
> When I use a USB console, I normally output syslog to a circular buffer (I 
> forget all of the Kconfig options, but they should not be to hard to find).  
> Then I enable the  NSH dmesg command.  That will dump the output of the 
> syslog data from the circular buffer to the USB console, clearing the buffer. 
>  Since buffering is available immediately after power up, no boot-up data is 
> lost. You just have to remember to enter the dmesg NSH command periodically.  
> You can do that with an NSH script running in the background.
> 
> 

Re: CDC/ACM console data to NuttX corrupted.

[Tim Hardisty]

I have concluded that CDC/ACM will NOT play alongside SYSLOG - most 
likely on the SAMA5D2 device, or possibly just on my board for some reason.


Whatever I choose as the SYSLOG output (/dev/ttyS0, ttyS1, ttyFC0 and 
ttyFC1 all of which are working fine, or even /dev/null) it just ends up 
garbling received data from the USB.


I have left CONFIG_CDCACM_NRDREQ=1, disabled SYSLOG and can move forward 
as this is only needed for the board test jig, so I don't need a 
TTL->USB converter cable to see output.


Can return to it if anyone has any ideas but, if not, will log both as 
issues for someone to pick up at some point in the future, maybe.


On 17/08/2023 16:06, Tim Hardisty wrote:

OK...progress.

CDC/ACM console behaves like this if CONFIG_CDCACM_NRDREQS is left at 
the default 4. It needs a given keyboard key to be pressed 4 times to 
work, and/or garbles the text sent. I also found that usbserial 
example app misbehaves in the same way - I thought it was working 
since random characters were being pressed by me to test it...and 
received as garbled random characters and I didn't notice.


If set to 1 it works. I do not know why this is.

If this is a bug not some configuration error/mismatch I've not 
spotted then I will raise it as an issue.


But it doesn't play nicely with syslog...I'm investigating that now.

On 17/08/2023 10:20, Tim Hardisty wrote:


Hi Adam,

You are right - wasn't at my dev PC and was going from memory. The 
FUSB302 does of course only manage PD and CC pullup/pulldowns - I 
know I got confused at some point when I was doing the driver and had 
a resurgence of that confusion last night! D+/D- go straight to the 
processor so do rely on the peripheral's data pull-up/downs .


The changes I did to the underlying SAMA5 USB code were to allow 
RHPORT1 (i.e. usb port A) to be used as either host or device under 
FUSB driver or app control.


BUT...looking back on this I see I also messed with the pullup logic 
so that might well be related to the issue I see. As I may well not 
be ensuring a "proper" device detect and setup, electrically and/or 
driver wise.


I will check this and work on a PR if necessary. To do this I will 
essentially "roll back" to not using "my" FUSB302 support and just 
the native SAMA5D2 device setup via Kconfig. Then move to splitting 
console and syslog to different devices and only then roll back in 
the FUSB302 stuff.


Hopefully I'll get there!

Tim.

On 16/08/2023 23:21, Adam Feuer wrote:

Tim,

I may be misunderstanding what you are saying– but it may be that 
you are confusing USB C Power Delivery host or device functionality 
with USB 2.0 / USB 3.0 data host or device functionality.


See this StackExchange question and answer 
<https://electronics.stackexchange.com/questions/554203/which-usb-spec-actually-defines-support-for-dual-role-device-type-c-or-usb-3-1>. 
Note that applies to USB 3.0, not USB 2.0. My understanding from 
reading the FUSB302 data sheet 
<https://www.onsemi.com/pdf/datasheet/fusb302b-d.pdf> is that it 
only implements USB C Power Delivery, and all USB 2.0/3.0 data 
transport connections must pass by the FUSB302 chip. See Figure 1 
and the pinout in Figure 4, there are no D+/D- (USB 2.0) or 
TX1/TX2/RX1/RX2 connections to the FUSB302. So the FUSB302 cannot be 
the problem.


When you switch the FUSB302 to host or device, it's only the USB C 
Power Delivery mode that switches.
The USB2.0 OTG host or device modes are handled 100% in the SAMA5D2 
drivers and only handle the data transport, not the Power Delivery 
mode.


Ok, I'll give the CDC/ACM console thing a try and let you know.

-adam


On Wed, Aug 16, 2023 at 2:22 PM Tim Hardisty  wrote:

    Just FUSB302. It uses the toggle mode to work out a device or
    host attach and the driver (yes, I authored/submitted that)
    handles the necessary reconfiguration of the pull ups/downs and
    then signals, via a poll, to the application layer (or, in my
    case, board-level driver code) what has occurred to allow host
    power switching. To make it all work,  I also added (and
    submitted/have had merged) changes to the SAMA5 usb code to allow
    a single physical port (A) to act as host or device switched in
    real time. It works! Essentially OTG/dual-role functionality on a
    processor that doesn't natively support it.

    Because CDC/ACM fundamentally works on my board, I think the
    FUSB302 stuff is not to blame. Knowing you had it working as a
    console is good to know, so its probably a mis-configuration
    somewhere, or a side-effect of the changes I made (but, yes, had
    submitted so are now part of NuttX so *could* raise as an issue:
    but I'd be the one to fix it lol).

    If you have a config that has console on CDC/ACM working to send
    me that would be a great reference but only if it's not too much
    trouble to (re)create.

 

Re: CDC/ACM console data to NuttX corrupted.

[Tim Hardisty]

OK...progress.

CDC/ACM console behaves like this if CONFIG_CDCACM_NRDREQS is left at 
the default 4. It needs a given keyboard key to be pressed 4 times to 
work, and/or garbles the text sent. I also found that usbserial example 
app misbehaves in the same way - I thought it was working since random 
characters were being pressed by me to test it...and received as garbled 
random characters and I didn't notice.


If set to 1 it works. I do not know why this is.

If this is a bug not some configuration error/mismatch I've not spotted 
then I will raise it as an issue.


But it doesn't play nicely with syslog...I'm investigating that now.

On 17/08/2023 10:20, Tim Hardisty wrote:


Hi Adam,

You are right - wasn't at my dev PC and was going from memory. The 
FUSB302 does of course only manage PD and CC pullup/pulldowns - I know 
I got confused at some point when I was doing the driver and had a 
resurgence of that confusion last night! D+/D- go straight to the 
processor so do rely on the peripheral's data pull-up/downs .


The changes I did to the underlying SAMA5 USB code were to allow 
RHPORT1 (i.e. usb port A) to be used as either host or device under 
FUSB driver or app control.


BUT...looking back on this I see I also messed with the pullup logic 
so that might well be related to the issue I see. As I may well not be 
ensuring a "proper" device detect and setup, electrically and/or 
driver wise.


I will check this and work on a PR if necessary. To do this I will 
essentially "roll back" to not using "my" FUSB302 support and just the 
native SAMA5D2 device setup via Kconfig. Then move to splitting 
console and syslog to different devices and only then roll back in the 
FUSB302 stuff.


Hopefully I'll get there!

Tim.

On 16/08/2023 23:21, Adam Feuer wrote:

Tim,

I may be misunderstanding what you are saying– but it may be that you 
are confusing USB C Power Delivery host or device functionality with 
USB 2.0 / USB 3.0 data host or device functionality.


See this StackExchange question and answer 
<https://electronics.stackexchange.com/questions/554203/which-usb-spec-actually-defines-support-for-dual-role-device-type-c-or-usb-3-1>. 
Note that applies to USB 3.0, not USB 2.0. My understanding from 
reading the FUSB302 data sheet 
<https://www.onsemi.com/pdf/datasheet/fusb302b-d.pdf> is that it only 
implements USB C Power Delivery, and all USB 2.0/3.0 data transport 
connections must pass by the FUSB302 chip. See Figure 1 and the 
pinout in Figure 4, there are no D+/D- (USB 2.0) or TX1/TX2/RX1/RX2 
connections to the FUSB302. So the FUSB302 cannot be the problem.


When you switch the FUSB302 to host or device, it's only the USB C 
Power Delivery mode that switches.
The USB2.0 OTG host or device modes are handled 100% in the SAMA5D2 
drivers and only handle the data transport, not the Power Delivery mode.


Ok, I'll give the CDC/ACM console thing a try and let you know.

-adam


On Wed, Aug 16, 2023 at 2:22 PM Tim Hardisty  wrote:

Just FUSB302. It uses the toggle mode to work out a device or
host attach and the driver (yes, I authored/submitted that)
handles the necessary reconfiguration of the pull ups/downs and
then signals, via a poll, to the application layer (or, in my
case, board-level driver code) what has occurred to allow host
power switching. To make it all work,  I also added (and
submitted/have had merged) changes to the SAMA5 usb code to allow
a single physical port (A) to act as host or device switched in
real time. It works! Essentially OTG/dual-role functionality on a
processor that doesn't natively support it.

Because CDC/ACM fundamentally works on my board, I think the
FUSB302 stuff is not to blame. Knowing you had it working as a
console is good to know, so its probably a mis-configuration
somewhere, or a side-effect of the changes I made (but, yes, had
submitted so are now part of NuttX so *could* raise as an issue:
but I'd be the one to fix it lol).

If you have a config that has console on CDC/ACM working to send
me that would be a great reference but only if it's not too much
trouble to (re)create.

Once (if) I am sure it is not as simple as a config error I will
raise is as an issue but, for now, I'm inclined to think it's
down to me.

If I get nowhere tomorrow morning, I'll email you my config: a
second opinion would be much appreciated!

On 16/08/2023 21:36, Adam Feuer wrote:

Are you using an FUSB302 with an FUSB340 (USB Switch)? My
understanding is that the FUSB302 only provides USB C power
delivery along with a USB2.0/USB 3.0 connection. That chip
doesn't do anything to allow host and device on the same port.
As far as I know that's a function of the SAMA5D27 and the NuttX
drivers. I actually don't know if the S

Re: CDC/ACM console data to NuttX corrupted.

[Tim Hardisty]

Hi Adam,

You are right - wasn't at my dev PC and was going from memory. The 
FUSB302 does of course only manage PD and CC pullup/pulldowns - I know I 
got confused at some point when I was doing the driver and had a 
resurgence of that confusion last night! D+/D- go straight to the 
processor so do rely on the peripheral's data pull-up/downs .


The changes I did to the underlying SAMA5 USB code were to allow RHPORT1 
(i.e. usb port A) to be used as either host or device under FUSB driver 
or app control.


BUT...looking back on this I see I also messed with the pullup logic so 
that might well be related to the issue I see. As I may well not be 
ensuring a "proper" device detect and setup, electrically and/or driver 
wise.


I will check this and work on a PR if necessary. To do this I will 
essentially "roll back" to not using "my" FUSB302 support and just the 
native SAMA5D2 device setup via Kconfig. Then move to splitting console 
and syslog to different devices and only then roll back in the FUSB302 
stuff.


Hopefully I'll get there!

Tim.

On 16/08/2023 23:21, Adam Feuer wrote:

Tim,

I may be misunderstanding what you are saying– but it may be that you 
are confusing USB C Power Delivery host or device functionality with 
USB 2.0 / USB 3.0 data host or device functionality.


See this StackExchange question and answer 
<https://electronics.stackexchange.com/questions/554203/which-usb-spec-actually-defines-support-for-dual-role-device-type-c-or-usb-3-1>. 
Note that applies to USB 3.0, not USB 2.0. My understanding from 
reading the FUSB302 data sheet 
<https://www.onsemi.com/pdf/datasheet/fusb302b-d.pdf> is that it only 
implements USB C Power Delivery, and all USB 2.0/3.0 data transport 
connections must pass by the FUSB302 chip. See Figure 1 and the pinout 
in Figure 4, there are no D+/D- (USB 2.0) or TX1/TX2/RX1/RX2 
connections to the FUSB302. So the FUSB302 cannot be the problem.


When you switch the FUSB302 to host or device, it's only the USB C 
Power Delivery mode that switches.
The USB2.0 OTG host or device modes are handled 100% in the SAMA5D2 
drivers and only handle the data transport, not the Power Delivery mode.


Ok, I'll give the CDC/ACM console thing a try and let you know.

-adam


On Wed, Aug 16, 2023 at 2:22 PM Tim Hardisty  wrote:

Just FUSB302. It uses the toggle mode to work out a device or host
attach and the driver (yes, I authored/submitted that) handles the
necessary reconfiguration of the pull ups/downs and then signals,
via a poll, to the application layer (or, in my case, board-level
driver code) what has occurred to allow host power switching. To
make it all work,  I also added (and submitted/have had merged)
changes to the SAMA5 usb code to allow a single physical port (A)
to act as host or device switched in real time. It works!
Essentially OTG/dual-role functionality on a processor that
doesn't natively support it.

Because CDC/ACM fundamentally works on my board, I think the
FUSB302 stuff is not to blame. Knowing you had it working as a
console is good to know, so its probably a mis-configuration
somewhere, or a side-effect of the changes I made (but, yes, had
submitted so are now part of NuttX so *could* raise as an issue:
but I'd be the one to fix it lol).

If you have a config that has console on CDC/ACM working to send
me that would be a great reference but only if it's not too much
trouble to (re)create.

Once (if) I am sure it is not as simple as a config error I will
raise is as an issue but, for now, I'm inclined to think it's down
to me.

If I get nowhere tomorrow morning, I'll email you my config: a
second opinion would be much appreciated!

On 16/08/2023 21:36, Adam Feuer wrote:

Are you using an FUSB302 with an FUSB340 (USB Switch)? My
understanding is that the FUSB302 only provides USB C power
delivery along with a USB2.0/USB 3.0 connection. That chip
doesn't do anything to allow host and device on the same port. As
far as I know that's a function of the SAMA5D27 and the NuttX
drivers. I actually don't know if the SAMA5D2 UDPHS and UHPHS can
function simultaneously, or whether NuttX supports that. Did you
get that working? Or is that the problem you are trying to solve?

So what's the problem with filing a bug? And didn't you add
support for the FUSB302 into NuttX?

Anyway... we can talk on email for now. Do you have one that
doesn't work? I'd love it if you can send it to me.

What I got working was CDC/ACM console and CDC/ECM ethernet over
USB on the same USB connection. Is that relevant to what you're
looking for? If so I can come up with a config that will do that.

-adam

On Wed, Aug 16, 2023 at 12:47 PM Tim Hardisty 
wrote:

Hi A

Re: CDC/ACM console data to NuttX corrupted.

[Tim Hardisty]

Just FUSB302. It uses the toggle mode to work out a device or host 
attach and the driver (yes, I authored/submitted that) handles the 
necessary reconfiguration of the pull ups/downs and then signals, via a 
poll, to the application layer (or, in my case, board-level driver code) 
what has occurred to allow host power switching. To make it all work,  I 
also added (and submitted/have had merged) changes to the SAMA5 usb code 
to allow a single physical port (A) to act as host or device switched in 
real time. It works! Essentially OTG/dual-role functionality on a 
processor that doesn't natively support it.


Because CDC/ACM fundamentally works on my board, I think the FUSB302 
stuff is not to blame. Knowing you had it working as a console is good 
to know, so its probably a mis-configuration somewhere, or a side-effect 
of the changes I made (but, yes, had submitted so are now part of NuttX 
so *could* raise as an issue: but I'd be the one to fix it lol).


If you have a config that has console on CDC/ACM working to send me that 
would be a great reference but only if it's not too much trouble to 
(re)create.


Once (if) I am sure it is not as simple as a config error I will raise 
is as an issue but, for now, I'm inclined to think it's down to me.


If I get nowhere tomorrow morning, I'll email you my config: a second 
opinion would be much appreciated!


On 16/08/2023 21:36, Adam Feuer wrote:
Are you using an FUSB302 with an FUSB340 (USB Switch)? My 
understanding is that the FUSB302 only provides USB C power delivery 
along with a USB2.0/USB 3.0 connection. That chip doesn't do anything 
to allow host and device on the same port. As far as I know that's a 
function of the SAMA5D27 and the NuttX drivers. I actually don't know 
if the SAMA5D2 UDPHS and UHPHS can function simultaneously, or whether 
NuttX supports that. Did you get that working? Or is that the problem 
you are trying to solve?


So what's the problem with filing a bug? And didn't you add support 
for the FUSB302 into NuttX?


Anyway... we can talk on email for now. Do you have one that doesn't 
work? I'd love it if you can send it to me.


What I got working was CDC/ACM console and CDC/ECM ethernet over USB 
on the same USB connection. Is that relevant to what you're looking 
for? If so I can come up with a config that will do that.


-adam

On Wed, Aug 16, 2023 at 12:47 PM Tim Hardisty  wrote:

Hi Adam,


My board is pushing many boundaries as it allows usb host and
device to coexist on a single physical port using an FUSB302
controller. It means it can never be as clear cut as it being a
bug to report!

If you happen to have a config that works for this it would be
useful for sure, but I will plug away at it more tomorrow as the
syslog port not behaving is probably a big clue.

Regards,

Tim.
On 16/08/2023 20:13, Adam Feuer wrote:

Hi Tim and Alan,

I tested CDC/ACM when I was doing the CDC/ECM performance increases about
18 months ago. It seemed like everything worked fine on the Jupiter Nano,
the SAMA5D2-XULT. I can put together a config for this again and test it...
or send me yours, and I will adapt to Jupiter Nano. If we have a config
that repros the problem, it should be possible to fix.

Will you file a bug report so we can communicate there in public, and tag
us or send the url by email?

And then post your config there. I'll try it out and try to repro!

-adam

On Wed, Aug 16, 2023 at 10:56 AM Alan C. Assis  
<mailto:acas...@gmail.com>  wrote:


Hi Tim,

On 8/16/23, Tim Hardisty  
<mailto:t...@jti.uk.com.invalid>  wrote:

I am trying to get CDC/ACM working on my custom board so I can have a
USB console. I have finally worked out the arcane set of CONFIG options
needed, found the to-be-expected bugs/inconstencies with some of the
SAMA5 code, that I have worked around for now (most are covered by
disabling debug assertions for now)...and...finally get an NSH prompt on
a Minicom terminal.

Yay!

But data transmission TO the board from Minicom is behaving very

strangely.

If I want to send '?' - to see what built-in apps I have, I need to type
the '?' four times followed by 4 ENTERs, then I get the expected
response. Eh?

Tried Minicom on Windows/WSL or Ubuntu, and PuTTY. Minicom has been my
console of choice, via serial, for ages.

This seems very odd - it's 100% OK to the PC but 100% not OK from PC to
board.

In case it's related...SYSLOG to the original /dev/ttyS1 no longer
works, and playing with SYSLOG configuration, seems to interfere with
the CDC/ACM usb functionality as well by stopping it working if I dare
to try to log to /dev/console!

Anyone got any suggestions before I scream even louder!!!???


I never saw this beha

Re: CDC/ACM console data to NuttX corrupted.

[Tim Hardisty]

Hi Adam,


My board is pushing many boundaries as it allows usb host and device to 
coexist on a single physical port using an FUSB302 controller. It means 
it can never be as clear cut as it being a bug to report!


If you happen to have a config that works for this it would be useful 
for sure, but I will plug away at it more tomorrow as the syslog port 
not behaving is probably a big clue.


Regards,

Tim.
On 16/08/2023 20:13, Adam Feuer wrote:

Hi Tim and Alan,

I tested CDC/ACM when I was doing the CDC/ECM performance increases about
18 months ago. It seemed like everything worked fine on the Jupiter Nano,
the SAMA5D2-XULT. I can put together a config for this again and test it...
or send me yours, and I will adapt to Jupiter Nano. If we have a config
that repros the problem, it should be possible to fix.

Will you file a bug report so we can communicate there in public, and tag
us or send the url by email?

And then post your config there. I'll try it out and try to repro!

-adam

On Wed, Aug 16, 2023 at 10:56 AM Alan C. Assis  wrote:


Hi Tim,

On 8/16/23, Tim Hardisty  wrote:

I am trying to get CDC/ACM working on my custom board so I can have a
USB console. I have finally worked out the arcane set of CONFIG options
needed, found the to-be-expected bugs/inconstencies with some of the
SAMA5 code, that I have worked around for now (most are covered by
disabling debug assertions for now)...and...finally get an NSH prompt on
a Minicom terminal.

Yay!

But data transmission TO the board from Minicom is behaving very

strangely.

If I want to send '?' - to see what built-in apps I have, I need to type
the '?' four times followed by 4 ENTERs, then I get the expected
response. Eh?

Tried Minicom on Windows/WSL or Ubuntu, and PuTTY. Minicom has been my
console of choice, via serial, for ages.

This seems very odd - it's 100% OK to the PC but 100% not OK from PC to
board.

In case it's related...SYSLOG to the original /dev/ttyS1 no longer
works, and playing with SYSLOG configuration, seems to interfere with
the CDC/ACM usb functionality as well by stopping it working if I dare
to try to log to /dev/console!

Anyone got any suggestions before I scream even louder!!!???


I never saw this behavior before!

Since you also tested on Windows, it is not something in the computer
messing with /dev/ttyACM0.

The first thing I noticed is that none board has usbnsh inside
boards/arm/sama5/x/configs/ so probably you are the first one to
test this feature.

So, start looking what the boards from other arch enable to get USB
CDC/ACM working as console.
And because there is no usbnsh board config for this chip, maybe it
needs more investigation.

I'm CC Adam, maybe he already tested it on Jupiter Nano board.

BR,

Alan




--

Regards,

Tim Hardisty


A picture containing text, clipart Description automatically generated



+44 (0) 1305 534535



<http://www.jti.uk.com/>



JTi.uk.com <https://www.jti.uk.com/>



<https://www.facebook.com/JTinnovations/>



\JTinnovations <https://www.facebook.com/JTinnovations/>

JT Innovations Ltd.

Registered office: 36 East St, Weymouth, Dorset, DT3 4DT, UK.

Company number 7619086

VAT Registration GB 111 7906 35

Re: CDC/ACM console data to NuttX corrupted.

[Tim Hardisty]

Thanks for replying Adam.

Did you try CDC/ACM for console, or just CDC/ACM itself? CDC/ACM does 
work fine using the usbserial example app, it's just using it as a 
console that's tripping me up.


I was drafting a different email before this topic, and may have missed 
some relevant information as a result. Here's what I'd drafted:


---

I am trying to set my custom SAMA5D2 board up to use a USB console 
rather than UART1. UART1 is the default for all other boards in the 
repo, with no SAMA5 boards using a serial console that I can find.


This is what I've tried so far.

1) Add CDC/ACM as a USB device.

When I run the example "usbserial" app, the cdc/acm device is registered 
as /dev/ttyACM0 as expected, and I can connect to it from my PC where 
the (USB) COM port is correctly instantiated, and characters are exchanged.


Good!

I note that /dev/ttyACM0 is not present in the /dev list however, as 
usbserial registers it.


2) So I added a call to cdcecm_initialize(0, NULL) to my board bringup. 
That makes sure that /dev/ttyACM0 is there at start up, but the 
usbserial example app is no longer happy as it wants to register the 
device itself. OK, no problem, but at least both these show that the 
fundamental USB + CDC/ACM stuff works.


Now to move console to CDC/ACM. I first removed the board_bringup call 
to register and init the cdc/acm device as that will conflict.


3) Leave UART1 as a console, check the option to select 
CONFIG_CDCACM_CONSOLE. This fails (via a DEBUGASSERT) because the 
attempt to register the usb device as /dev/console. Error 16 - Device or 
Resource Busy. Probably because UART1 has already claimed /dev/console. 
Fair enough!


4) Select the option CONFIG_NO_SERIAL_CONSOLE instead. That's consistent 
with a few search hits on how to do this (thanks Alan C. Cassis as ever 
for your videos!)


This trips up because of a #error in sam_lowput.c since no UART or USART 
is defined for console (i.e. it really is expecting there to be a serial 
console). It's in lowput.c  and I've fixed that by comparing to samv7 
and, for now, disabling debug assertions.


--

Stopped that email draft at this point and switched tack as I'd found I 
could get it to work but with the problem now reported.



On 16/08/2023 20:13, Adam Feuer wrote:

Hi Tim and Alan,

I tested CDC/ACM when I was doing the CDC/ECM performance increases about
18 months ago. It seemed like everything worked fine on the Jupiter Nano,
the SAMA5D2-XULT. I can put together a config for this again and test it...
or send me yours, and I will adapt to Jupiter Nano. If we have a config
that repros the problem, it should be possible to fix.

Will you file a bug report so we can communicate there in public, and tag
us or send the url by email?

And then post your config there. I'll try it out and try to repro!

-adam

On Wed, Aug 16, 2023 at 10:56 AM Alan C. Assis  wrote:


Hi Tim,

On 8/16/23, Tim Hardisty  wrote:

I am trying to get CDC/ACM working on my custom board so I can have a
USB console. I have finally worked out the arcane set of CONFIG options
needed, found the to-be-expected bugs/inconstencies with some of the
SAMA5 code, that I have worked around for now (most are covered by
disabling debug assertions for now)...and...finally get an NSH prompt on
a Minicom terminal.

Yay!

But data transmission TO the board from Minicom is behaving very

strangely.

If I want to send '?' - to see what built-in apps I have, I need to type
the '?' four times followed by 4 ENTERs, then I get the expected
response. Eh?

Tried Minicom on Windows/WSL or Ubuntu, and PuTTY. Minicom has been my
console of choice, via serial, for ages.

This seems very odd - it's 100% OK to the PC but 100% not OK from PC to
board.

In case it's related...SYSLOG to the original /dev/ttyS1 no longer
works, and playing with SYSLOG configuration, seems to interfere with
the CDC/ACM usb functionality as well by stopping it working if I dare
to try to log to /dev/console!

Anyone got any suggestions before I scream even louder!!!???


I never saw this behavior before!

Since you also tested on Windows, it is not something in the computer
messing with /dev/ttyACM0.

The first thing I noticed is that none board has usbnsh inside
boards/arm/sama5/x/configs/ so probably you are the first one to
test this feature.

So, start looking what the boards from other arch enable to get USB
CDC/ACM working as console.
And because there is no usbnsh board config for this chip, maybe it
needs more investigation.

I'm CC Adam, maybe he already tested it on Jupiter Nano board.

BR,

Alan




--

Regards,

Tim Hardisty


A picture containing text, clipart Description automatically generated



+44 (0) 1305 534535



<http://www.jti.uk.com/>



JTi.uk.com <https://www.jti.uk.com/>



<https://www.facebook.com/JTinnovations/>

  

CDC/ACM console data to NuttX corrupted.

[Tim Hardisty]

I am trying to get CDC/ACM working on my custom board so I can have a 
USB console. I have finally worked out the arcane set of CONFIG options 
needed, found the to-be-expected bugs/inconstencies with some of the 
SAMA5 code, that I have worked around for now (most are covered by 
disabling debug assertions for now)...and...finally get an NSH prompt on 
a Minicom terminal.


Yay!

But data transmission TO the board from Minicom is behaving very strangely.

If I want to send '?' - to see what built-in apps I have, I need to type 
the '?' four times followed by 4 ENTERs, then I get the expected 
response. Eh?


Tried Minicom on Windows/WSL or Ubuntu, and PuTTY. Minicom has been my 
console of choice, via serial, for ages.


This seems very odd - it's 100% OK to the PC but 100% not OK from PC to 
board.


In case it's related...SYSLOG to the original /dev/ttyS1 no longer 
works, and playing with SYSLOG configuration, seems to interfere with 
the CDC/ACM usb functionality as well by stopping it working if I dare 
to try to log to /dev/console!


Anyone got any suggestions before I scream even louder!!!???

Re: CAN TX fail handling

[Tim Hardisty]

Thanks David - whilst I perhaps could of searched for that, it is why I 
asked here as I was sure someone else was likely to have seen this.


I like your idea of IOCTLs - I will be revisiting this issue in the next 
few weeks and will look to see what's involved in implementing this as 
it "feels" right.


On 10/08/2023 09:04, David Sidrane wrote:

Tim,

Seehttps://github.com/apache/nuttx/issues/3927

David

-Original Message-
From: Alan C. Assis
Sent: Wednesday, August 9, 2023 3:47 PM
To:dev@nuttx.apache.org
Cc: Pavel Pisa
Subject: Re: CAN TX fail handling

Hi Tim,

Agree! This behavior could be implemented in the driver, for example using
some elapsed time. But again, it needs to be analyzed careful to avoid
introduce sometime too specific for a user needs.

Currently the can_close() try to wait for the TX complete that could never
happen because this issue.

If you implement the idea of resetting the CAN controller in the
can_close() you need to guarantee that it will be reinitialized correctly,
because in can_open() it expects the CAN controller in working state.

BR,

Alan

On 8/9/23, Tim Hardisty  wrote:

Thanks Alan,

I can see that a timeout/retry in detail would be hardware dependent.
But in the absence of "something," code can send a message, but have
no idea that it hasn't actually been sent, then try and close the "file"
and the thread will hang indefinitely. I think we need something that
reports the fail so some kind of recovery/reset can be attempted?

Perhaps the "close" could be wrapped with something to deal with this?
Or the open mode needs to be different somehow?

POSIX/Linux type programming is new to me, after decades of bare-metal
type software dev where I'm in total control albeit unique to a
given/chosen processor, so any suggestions would be very welcome.

On 09/08/2023 19:56, Alan C. Assis wrote:

Hi Tim,

I think that the default behavior of CAN Controller is trying to send
indefinitely a message, some HW can define some retry limit.

Please take a look:
https://forum.pjrc.com/threads/67435-FlexCAN-Infinite-Endless-TX-Retr
ies

So, I'm not sure if it will make sense to implement a CAN TX timeout
on NuttX side, since this behavior could be HW dependent.

BR,

Alan

On 8/9/23, Tim Hardisty   wrote:

I am now cracking on with the app for my custom board, and in
parallel writing a production board-test app.

In trying to cover potential board faults, I have found that if
there's something that prevents a CAN message reaching an
endpoint/destination, the CAN transmitter (of course, as I
understand it) is continuously retrying the message send, meaning
the test app hangs when you try and close the file once the test has
been deemed to fail. That is "by design" in the higher (i.e.
non-arch specific) can code as it waits for the TX FIFO/queue to empty
until the close is allowed.

What is the correct POSIX way to handle this error condition?

Might it be better to use Socket CAN, for example, assuming it has
better error handling by design, or is the NuttX CAN "system"
fundamentally missing something to handle this (or, more likely,
I've just missed it )?



--

Regards,

Tim Hardisty


A picture containing text, clipart Description automatically generated



+44 (0) 1305 534535



<http://www.jti.uk.com/>



JTi.uk.com<https://www.jti.uk.com/>



<https://www.facebook.com/JTinnovations/>



\JTinnovations<https://www.facebook.com/JTinnovations/>

JT Innovations Ltd.

Registered office: 36 East St, Weymouth, Dorset, DT3 4DT, UK.

Company number 7619086

VAT Registration GB 111 7906 35


--

Regards,

Tim Hardisty


A picture containing text, clipart Description automatically generated



+44 (0) 1305 534535



<http://www.jti.uk.com/>



JTi.uk.com <https://www.jti.uk.com/>



<https://www.facebook.com/JTinnovations/>



\JTinnovations <https://www.facebook.com/JTinnovations/>

JT Innovations Ltd.

Registered office: 36 East St, Weymouth, Dorset, DT3 4DT, UK.

Company number 7619086

VAT Registration GB 111 7906 35

Re: CAN TX fail handling

[Tim Hardisty]

Thanks Alan,

I can see that a timeout/retry in detail would be hardware dependent. 
But in the absence of "something," code can send a message, but have no 
idea that it hasn't actually been sent, then try and close the "file" 
and the thread will hang indefinitely. I think we need something that 
reports the fail so some kind of recovery/reset can be attempted?


Perhaps the "close" could be wrapped with something to deal with this? 
Or the open mode needs to be different somehow?


POSIX/Linux type programming is new to me, after decades of bare-metal 
type software dev where I'm in total control albeit unique to a 
given/chosen processor, so any suggestions would be very welcome.


On 09/08/2023 19:56, Alan C. Assis wrote:

Hi Tim,

I think that the default behavior of CAN Controller is trying to send
indefinitely a message, some HW can define some retry limit.

Please take a look:
https://forum.pjrc.com/threads/67435-FlexCAN-Infinite-Endless-TX-Retries

So, I'm not sure if it will make sense to implement a CAN TX timeout
on NuttX side, since this behavior could be HW dependent.

BR,

Alan

On 8/9/23, Tim Hardisty  wrote:

I am now cracking on with the app for my custom board, and in parallel
writing a production board-test app.

In trying to cover potential board faults, I have found that if there's
something that prevents a CAN message reaching an endpoint/destination,
the CAN transmitter (of course, as I understand it) is continuously
retrying the message send, meaning the test app hangs when you try and
close the file once the test has been deemed to fail. That is "by
design" in the higher (i.e. non-arch specific) can code as it waits for
the TX FIFO/queue to empty until the close is allowed.

What is the correct POSIX way to handle this error condition?

Might it be better to use Socket CAN, for example, assuming it has
better error handling by design, or is the NuttX CAN "system"
fundamentally missing something to handle this (or, more likely, I've
just missed it )?



--

Regards,

Tim Hardisty


A picture containing text, clipart Description automatically generated



+44 (0) 1305 534535



<http://www.jti.uk.com/>



JTi.uk.com <https://www.jti.uk.com/>



<https://www.facebook.com/JTinnovations/>



\JTinnovations <https://www.facebook.com/JTinnovations/>

JT Innovations Ltd.

Registered office: 36 East St, Weymouth, Dorset, DT3 4DT, UK.

Company number 7619086

VAT Registration GB 111 7906 35

CAN TX fail handling

[Tim Hardisty]

I am now cracking on with the app for my custom board, and in parallel 
writing a production board-test app.


In trying to cover potential board faults, I have found that if there's 
something that prevents a CAN message reaching an endpoint/destination, 
the CAN transmitter (of course, as I understand it) is continuously 
retrying the message send, meaning the test app hangs when you try and 
close the file once the test has been deemed to fail. That is "by 
design" in the higher (i.e. non-arch specific) can code as it waits for 
the TX FIFO/queue to empty until the close is allowed.


What is the correct POSIX way to handle this error condition?

Might it be better to use Socket CAN, for example, assuming it has 
better error handling by design, or is the NuttX CAN "system" 
fundamentally missing something to handle this (or, more likely, I've 
just missed it )?

Re: SPI api example...

[Tim Hardisty]

On 11/07/2023 18:28, Ed Sutter wrote:
Hi,
Are there any examples of application code accessing a SPI device on Nuttx?
Thanks,
Ed



Plenty - MAX31855 K-type thermocouple interface for example. Look at the 
examples in the  Applications setup within menuconfig.

SPI devices will be accessed via character drivers (for example/dev/ktytpe0).

Re: Bootloaders other than u-boot?

[Tim Hardisty]

Having got u-boot to work and, now, also got lvgldemo to run 
automatically at startup, I have taken some rough timings of the boot 
time on my sama5d27 board and thought others might be interested.

power->at91bootstrap->uboot (autoboot with 0s timeout)->nuttx->graphics 
on the screen: 6 seconds

If I use the bootstrap program to boot NuttX directly however:

power->at91bootstrap->nuttx->graphics on the screen: 2 seconds

It seems uboot is not really a very good choice as a bootloader for an 
embedded system, where boot time is important (I was looking for <3s).

 From this discussion (thank you everyone) I believe I will be OK using 
USB/dfu/RNDIS tools/utilities directly from NuttX in my main app, to 
load and check new binaries to a secondary flash area without needing 
u-boot or MCUboot. I will try mcuboot if it does prove necessary to have 
an intermediate bootloader, or use a simple designed-for-purpose program.

On 01/07/2023 10:56, Tim Hardisty wrote:
> Not directly related to NuttX but I hope you don't mind me asking here.
>
> Bottom line: has anyone used any bootloader other than u-boot to allow usb 
> dfu or RNDIS-type firmware updates, and that easily boot NuttX?
>
> My board uses the usual SAMA5 methodology of AT91 bootstrap->u-boot->NuttX. 
> It all works as expected, as far as running code is concerned, but I simply 
> cannot get u-boot to enable the USB port for DFU or RNDIS functions and I 
> need the product to have user-friendly in-field updates, ideally without me 
> having to write any PC update software.
>
> U-boot has defeated me for over 2 weeks now, and simply refuses to even 
> "activate" the USB (i.e. a PC never even sees the connect let alone any 
> functionality: yes, the USB port does work for NuttX and sam-ba code 
> flashing); device trees are the invention of the devil; and an unholy 
> apparent mish mash of driver model and "legacy" modes; no SAM boards in the 
> u-boot trees appearing to have relevant config options I can copy. Add to 
> that: using latest u-boot rather than the 2020 version I currently have 
> "working"means it won't even find a console serial port any more, the lack of 
> response on the relevant AT91 u-boot github to questions, and I am just about 
> ready to give up :(
>
> But I need a bootloader!
>

Re: App crashes if entrypoint but not from nsh

[Tim Hardisty]

Argument is correctly passed and prints as expected.

I just found that for some reason in the new config I created for this 
work that somehow CONFIG_BOARD_LATE_INITIALIZE was not set, so my board 
bringup code was not initialised, so there was no /dev/fb0 for lvgl to use.


Doh!

On 05/07/2023 20:01, Petro Karashchenko wrote:

I'm asking about parameters because if I recall correctly the arguments
were stored on program stack, so I thought of maybe some stack alignment
issue or something similar.
Maybe you can modify lvgldemo_main and place print some message to console
+ sleep(1); in a loop just after it is entered? Not sure if that will give
us much, but worth of trying to get some information.

Best regards,
Petro

On Wed, Jul 5, 2023, 9:30 PM Tim Hardisty  wrote:


Yes (or "music") - so called by
nsh: lvgldemo music

It's a memory-type problem of some sort rather than errors with vars, I
believe.

On 05/07/2023 19:24, Petro Karashchenko wrote:

Just to clarify, when you run lvgldemo from nsh, do you also pass "widgets"
as argument, right?

On Wed, Jul 5, 2023, 8:54 PM Tim Hardisty  wrote:



Sure. I think attachements get stripped out so I have pasted the
contents (I've "xxx"d references to the board name)

#
# This file is autogenerated: PLEASE DO NOT EDIT IT.
#
# You can use "make menuconfig" to make any modifications to the
installed .config file.
# You can then do "make savedefconfig" to generate a new defconfig file
that includes your
# modifications.
#
# CONFIG_ACT8945A_LDO1_PULLDOWN is not set
# CONFIG_ACT8945A_LDO2_BOOT_ON is not set
# CONFIG_DEV_RANDOM is not set
# CONFIG_DISABLE_OS_API is not set
# CONFIG_FS_ANONMAP is not set
# CONFIG_NSH_CMDOPT_HEXDUMP is not set
# CONFIG_SAMA5_RXLP is not set
# CONFIG_SAMA5_UART0 is not set
# CONFIG_SIG_SIGSTOP_ACTION is not set
CONFIG_ACT8945A_DCDC1_NAME="VDD_IODDR"
CONFIG_ACT8945A_DCDC2_NAME="VDD_CORE"
CONFIG_ACT8945A_DCDC3_NAME="VDD_3V3"
CONFIG_ACT8945A_LDO1_NAME="VDD_FUSE"
CONFIG_ACT8945A_LDO2_NAME="VDD_3V3_LP"
CONFIG_ACT8945A_LDO3_APPLY_UV=y
CONFIG_ACT8945A_LDO3_BOOT_ON=y
CONFIG_ACT8945A_LDO3_MAX_UV=3300
CONFIG_ACT8945A_LDO3_MIN_UV=3300
CONFIG_ACT8945A_LDO3_NAME="VDD_LED"
CONFIG_ACT8945A_LDO4_NAME="VDD_GPS_ANTENNA"
CONFIG_ADC_FIFOSIZE=40
CONFIG_ARCH="arm"
CONFIG_ARCH_BOARD_CUSTOM=y
CONFIG_ARCH_BOARD_CUSTOM_DIR="../CustomBoards/x"
CONFIG_ARCH_BOARD_CUSTOM_DIR_RELPATH=y
CONFIG_ARCH_BOARD_CUSTOM_NAME="x"
CONFIG_ARCH_CHIP="sama5"
CONFIG_ARCH_CHIP_ATSAMA5D27=y
CONFIG_ARCH_CHIP_SAMA5=y
CONFIG_ARCH_CHIP_SAMA5D2=y
CONFIG_ARCH_INTERRUPTSTACK=2048
CONFIG_ARCH_LOWVECTORS=y
CONFIG_ARM_FPU_ABI_SOFT=y
CONFIG_AT25_SPIFREQUENCY=500
CONFIG_AUDIO=y
CONFIG_BOARDCTL_FINALINIT=y
CONFIG_BOARDCTL_UNIQUEID=y
CONFIG_BOARDCTL_UNIQUEID_SIZE=8
CONFIG_BOARD_LOOPSPERMSEC=65775
CONFIG_BOOT_RUNFROMSDRAM=y
CONFIG_BUILTIN=y
CONFIG_CUSTOM_APPS_AT25TEST=y
CONFIG_CUSTOM_APPS_T2_FILEGEN=y
CONFIG_DEBUG_ERROR=y
CONFIG_DEBUG_FEATURES=y
CONFIG_DEBUG_SYMBOLS=y
CONFIG_DEBUG_TCBINFO=y
CONFIG_DEBUG_WARN=y
CONFIG_DEFAULT_TASK_STACKSIZE=4096
CONFIG_DEV_GPIO=y
CONFIG_DEV_ZERO=y
CONFIG_DRIVERS_AUDIO=y
CONFIG_DRIVERS_VIDEO=y
CONFIG_EE25XX_FREQUENCY=500
CONFIG_EEPROM=y
CONFIG_EXAMPLES_FB=y
CONFIG_EXAMPLES_LVGLDEMO=y
CONFIG_EXAMPLES_LVGLDEMO_STACKSIZE=65535
CONFIG_EXAMPLES_TOUCHSCREEN=y
CONFIG_FS_FAT=y
CONFIG_FS_LITTLEFS=y
CONFIG_FS_PROCFS=y
CONFIG_FS_PROCFS_REGISTER=y
CONFIG_GD25_SPIFREQUENCY=10400
CONFIG_GRAPHICS_LVGL=y
CONFIG_HAVE_CXX=y
CONFIG_HAVE_CXXINITIALIZE=y
CONFIG_INIT_ARGS="\"widgets\""
CONFIG_INIT_ENTRYNAME="lvgldemo"
CONFIG_INIT_ENTRYPOINT="lvgldemo_main"
CONFIG_INIT_STACKSIZE=65535
CONFIG_LCD=y
CONFIG_LIBC_NUMBERED_ARGS=y
CONFIG_LP503X=y
CONFIG_LV_ATTRIBUTE_FAST_MEM_USE_IRAM=y
CONFIG_LV_COLOR_DEPTH_32=y
CONFIG_LV_COLOR_MIX_ROUND_OFS=128
CONFIG_LV_COLOR_SCREEN_TRANSP=y
CONFIG_LV_DISP_DEF_REFR_PERIOD=50
CONFIG_LV_DPI_DEF=188
CONFIG_LV_FONT_MONTSERRAT_12=y
CONFIG_LV_FONT_MONTSERRAT_16=y
CONFIG_LV_FONT_MONTSERRAT_18=y
CONFIG_LV_FONT_MONTSERRAT_22=y
CONFIG_LV_FONT_MONTSERRAT_24=y
CONFIG_LV_FONT_MONTSERRAT_32=y
CONFIG_LV_MEM_CUSTOM=y
CONFIG_LV_PORT_TOUCHPAD_CURSOR_SIZE=10
CONFIG_LV_PORT_USE_FBDEV=y
CONFIG_LV_PORT_USE_TOUCHPAD=y
CONFIG_LV_TICK_CUSTOM=y
CONFIG_LV_TICK_CUSTOM_INCLUDE="port/lv_port_tick.h"
CONFIG_LV_USE_ASSERT_MEM_INTEGRITY=y
CONFIG_LV_USE_ASSERT_OBJ=y
CONFIG_LV_USE_ASSERT_STYLE=y
CONFIG_LV_USE_DEMO_MUSIC=y
CONFIG_LV_USE_DEMO_WIDGETS=y
CONFIG_LV_USE_PERF_MONITOR=y
CONFIG_M25P_SPIFREQUENCY=9000
CONFIG_MM_BACKTRACE=4
CONFIG_MM_BACKTRACE_DEFAULT=y
CONFIG_MQ_MAXMSGSIZE=64
CONFIG_MTD=y
CONFIG_MTD_AT25=y
CONFIG_MTD_GD25=y
CONFIG_MTD_M25P=y
CONFIG_NSH_ARCHINIT=y
CONFIG_NSH_BUILTIN_APPS=y
CONFIG_NSH_CMDOPT_DD_STATS=y
CONFIG_NSH_FILEIOSIZE=512
CONFIG_NSH_READLINE=y
CONFIG_NXFONTS_DISABLE_16BPP=y
CONFIG_NXFONTS_DISABLE_1BPP=y
CONFIG_NXF

Re: App crashes if entrypoint but not from nsh

[Tim Hardisty]

(and will do what you suggest, tomorrow, just in case)
On 05/07/2023 20:01, Petro Karashchenko wrote:

I'm asking about parameters because if I recall correctly the arguments
were stored on program stack, so I thought of maybe some stack alignment
issue or something similar.
Maybe you can modify lvgldemo_main and place print some message to console
+ sleep(1); in a loop just after it is entered? Not sure if that will give
us much, but worth of trying to get some information.

Best regards,
Petro

On Wed, Jul 5, 2023, 9:30 PM Tim Hardisty 
<mailto:t...@hardisty.co.uk> wrote:



Yes (or "music") - so called by
nsh: lvgldemo music

It's a memory-type problem of some sort rather than errors with vars, I
believe.

On 05/07/2023 19:24, Petro Karashchenko wrote:

Just to clarify, when you run lvgldemo from nsh, do you also pass "widgets"
as argument, right?

On Wed, Jul 5, 2023, 8:54 PM Tim Hardisty 
<mailto:t...@hardisty.co.uk><mailto:t...@hardisty.co.uk> wrote:



Sure. I think attachements get stripped out so I have pasted the
contents (I've "xxx"d references to the board name)

#
# This file is autogenerated: PLEASE DO NOT EDIT IT.
#
# You can use "make menuconfig" to make any modifications to the
installed .config file.
# You can then do "make savedefconfig" to generate a new defconfig file
that includes your
# modifications.
#
# CONFIG_ACT8945A_LDO1_PULLDOWN is not set
# CONFIG_ACT8945A_LDO2_BOOT_ON is not set
# CONFIG_DEV_RANDOM is not set
# CONFIG_DISABLE_OS_API is not set
# CONFIG_FS_ANONMAP is not set
# CONFIG_NSH_CMDOPT_HEXDUMP is not set
# CONFIG_SAMA5_RXLP is not set
# CONFIG_SAMA5_UART0 is not set
# CONFIG_SIG_SIGSTOP_ACTION is not set
CONFIG_ACT8945A_DCDC1_NAME="VDD_IODDR"
CONFIG_ACT8945A_DCDC2_NAME="VDD_CORE"
CONFIG_ACT8945A_DCDC3_NAME="VDD_3V3"
CONFIG_ACT8945A_LDO1_NAME="VDD_FUSE"
CONFIG_ACT8945A_LDO2_NAME="VDD_3V3_LP"
CONFIG_ACT8945A_LDO3_APPLY_UV=y
CONFIG_ACT8945A_LDO3_BOOT_ON=y
CONFIG_ACT8945A_LDO3_MAX_UV=3300
CONFIG_ACT8945A_LDO3_MIN_UV=3300
CONFIG_ACT8945A_LDO3_NAME="VDD_LED"
CONFIG_ACT8945A_LDO4_NAME="VDD_GPS_ANTENNA"
CONFIG_ADC_FIFOSIZE=40
CONFIG_ARCH="arm"
CONFIG_ARCH_BOARD_CUSTOM=y
CONFIG_ARCH_BOARD_CUSTOM_DIR="../CustomBoards/x"
CONFIG_ARCH_BOARD_CUSTOM_DIR_RELPATH=y
CONFIG_ARCH_BOARD_CUSTOM_NAME="x"
CONFIG_ARCH_CHIP="sama5"
CONFIG_ARCH_CHIP_ATSAMA5D27=y
CONFIG_ARCH_CHIP_SAMA5=y
CONFIG_ARCH_CHIP_SAMA5D2=y
CONFIG_ARCH_INTERRUPTSTACK=2048
CONFIG_ARCH_LOWVECTORS=y
CONFIG_ARM_FPU_ABI_SOFT=y
CONFIG_AT25_SPIFREQUENCY=500
CONFIG_AUDIO=y
CONFIG_BOARDCTL_FINALINIT=y
CONFIG_BOARDCTL_UNIQUEID=y
CONFIG_BOARDCTL_UNIQUEID_SIZE=8
CONFIG_BOARD_LOOPSPERMSEC=65775
CONFIG_BOOT_RUNFROMSDRAM=y
CONFIG_BUILTIN=y
CONFIG_CUSTOM_APPS_AT25TEST=y
CONFIG_CUSTOM_APPS_T2_FILEGEN=y
CONFIG_DEBUG_ERROR=y
CONFIG_DEBUG_FEATURES=y
CONFIG_DEBUG_SYMBOLS=y
CONFIG_DEBUG_TCBINFO=y
CONFIG_DEBUG_WARN=y
CONFIG_DEFAULT_TASK_STACKSIZE=4096
CONFIG_DEV_GPIO=y
CONFIG_DEV_ZERO=y
CONFIG_DRIVERS_AUDIO=y
CONFIG_DRIVERS_VIDEO=y
CONFIG_EE25XX_FREQUENCY=500
CONFIG_EEPROM=y
CONFIG_EXAMPLES_FB=y
CONFIG_EXAMPLES_LVGLDEMO=y
CONFIG_EXAMPLES_LVGLDEMO_STACKSIZE=65535
CONFIG_EXAMPLES_TOUCHSCREEN=y
CONFIG_FS_FAT=y
CONFIG_FS_LITTLEFS=y
CONFIG_FS_PROCFS=y
CONFIG_FS_PROCFS_REGISTER=y
CONFIG_GD25_SPIFREQUENCY=10400
CONFIG_GRAPHICS_LVGL=y
CONFIG_HAVE_CXX=y
CONFIG_HAVE_CXXINITIALIZE=y
CONFIG_INIT_ARGS="\"widgets\""
CONFIG_INIT_ENTRYNAME="lvgldemo"
CONFIG_INIT_ENTRYPOINT="lvgldemo_main"
CONFIG_INIT_STACKSIZE=65535
CONFIG_LCD=y
CONFIG_LIBC_NUMBERED_ARGS=y
CONFIG_LP503X=y
CONFIG_LV_ATTRIBUTE_FAST_MEM_USE_IRAM=y
CONFIG_LV_COLOR_DEPTH_32=y
CONFIG_LV_COLOR_MIX_ROUND_OFS=128
CONFIG_LV_COLOR_SCREEN_TRANSP=y
CONFIG_LV_DISP_DEF_REFR_PERIOD=50
CONFIG_LV_DPI_DEF=188
CONFIG_LV_FONT_MONTSERRAT_12=y
CONFIG_LV_FONT_MONTSERRAT_16=y
CONFIG_LV_FONT_MONTSERRAT_18=y
CONFIG_LV_FONT_MONTSERRAT_22=y
CONFIG_LV_FONT_MONTSERRAT_24=y
CONFIG_LV_FONT_MONTSERRAT_32=y
CONFIG_LV_MEM_CUSTOM=y
CONFIG_LV_PORT_TOUCHPAD_CURSOR_SIZE=10
CONFIG_LV_PORT_USE_FBDEV=y
CONFIG_LV_PORT_USE_TOUCHPAD=y
CONFIG_LV_TICK_CUSTOM=y
CONFIG_LV_TICK_CUSTOM_INCLUDE="port/lv_port_tick.h"
CONFIG_LV_USE_ASSERT_MEM_INTEGRITY=y
CONFIG_LV_USE_ASSERT_OBJ=y
CONFIG_LV_USE_ASSERT_STYLE=y
CONFIG_LV_USE_DEMO_MUSIC=y
CONFIG_LV_USE_DEMO_WIDGETS=y
CONFIG_LV_USE_PERF_MONITOR=y
CONFIG_M25P_SPIFREQUENCY=9000
CONFIG_MM_BACKTRACE=4
CONFIG_MM_BACKTRACE_DEFAULT=y
CONFIG_MQ_MAXMSGSIZE=64
CONFIG_MTD=y
CONFIG_MTD_AT25=y
CONFIG_MTD_GD25=y
CONFIG_MTD_M25P=y
CONFIG_NSH_ARCHINIT=y
CONFIG_NSH_BUILTIN_APPS=y
CONFIG_NSH_CMDOPT_DD_STATS=y
CONFIG_NSH_FILEIOSIZE=512
CONFIG_NSH_READLINE=y
CONFIG_NXFONTS_DISABLE_16BPP=y
CONFIG_NXFONTS_DISABLE_1BPP=y
CONFIG_NXFONTS_DISABLE_24BPP=y
CONFIG_NXFONTS_DISABLE_2BPP=y
CONFIG_NXFONTS_DISABLE_32BPP=y
CONFIG_NXFONTS_DISABLE_4BPP=y
CONFIG_NXFONTS_D

Re: App crashes if entrypoint but not from nsh

[Tim Hardisty]

Yes (or "music") - so called by
nsh: lvgldemo music

It's a memory-type problem of some sort rather than errors with vars, I believe.

On 05/07/2023 19:24, Petro Karashchenko wrote:

Just to clarify, when you run lvgldemo from nsh, do you also pass "widgets"
as argument, right?

On Wed, Jul 5, 2023, 8:54 PM Tim Hardisty 
<mailto:t...@hardisty.co.uk> wrote:



Sure. I think attachements get stripped out so I have pasted the
contents (I've "xxx"d references to the board name)

#
# This file is autogenerated: PLEASE DO NOT EDIT IT.
#
# You can use "make menuconfig" to make any modifications to the
installed .config file.
# You can then do "make savedefconfig" to generate a new defconfig file
that includes your
# modifications.
#
# CONFIG_ACT8945A_LDO1_PULLDOWN is not set
# CONFIG_ACT8945A_LDO2_BOOT_ON is not set
# CONFIG_DEV_RANDOM is not set
# CONFIG_DISABLE_OS_API is not set
# CONFIG_FS_ANONMAP is not set
# CONFIG_NSH_CMDOPT_HEXDUMP is not set
# CONFIG_SAMA5_RXLP is not set
# CONFIG_SAMA5_UART0 is not set
# CONFIG_SIG_SIGSTOP_ACTION is not set
CONFIG_ACT8945A_DCDC1_NAME="VDD_IODDR"
CONFIG_ACT8945A_DCDC2_NAME="VDD_CORE"
CONFIG_ACT8945A_DCDC3_NAME="VDD_3V3"
CONFIG_ACT8945A_LDO1_NAME="VDD_FUSE"
CONFIG_ACT8945A_LDO2_NAME="VDD_3V3_LP"
CONFIG_ACT8945A_LDO3_APPLY_UV=y
CONFIG_ACT8945A_LDO3_BOOT_ON=y
CONFIG_ACT8945A_LDO3_MAX_UV=3300
CONFIG_ACT8945A_LDO3_MIN_UV=3300
CONFIG_ACT8945A_LDO3_NAME="VDD_LED"
CONFIG_ACT8945A_LDO4_NAME="VDD_GPS_ANTENNA"
CONFIG_ADC_FIFOSIZE=40
CONFIG_ARCH="arm"
CONFIG_ARCH_BOARD_CUSTOM=y
CONFIG_ARCH_BOARD_CUSTOM_DIR="../CustomBoards/x"
CONFIG_ARCH_BOARD_CUSTOM_DIR_RELPATH=y
CONFIG_ARCH_BOARD_CUSTOM_NAME="x"
CONFIG_ARCH_CHIP="sama5"
CONFIG_ARCH_CHIP_ATSAMA5D27=y
CONFIG_ARCH_CHIP_SAMA5=y
CONFIG_ARCH_CHIP_SAMA5D2=y
CONFIG_ARCH_INTERRUPTSTACK=2048
CONFIG_ARCH_LOWVECTORS=y
CONFIG_ARM_FPU_ABI_SOFT=y
CONFIG_AT25_SPIFREQUENCY=500
CONFIG_AUDIO=y
CONFIG_BOARDCTL_FINALINIT=y
CONFIG_BOARDCTL_UNIQUEID=y
CONFIG_BOARDCTL_UNIQUEID_SIZE=8
CONFIG_BOARD_LOOPSPERMSEC=65775
CONFIG_BOOT_RUNFROMSDRAM=y
CONFIG_BUILTIN=y
CONFIG_CUSTOM_APPS_AT25TEST=y
CONFIG_CUSTOM_APPS_T2_FILEGEN=y
CONFIG_DEBUG_ERROR=y
CONFIG_DEBUG_FEATURES=y
CONFIG_DEBUG_SYMBOLS=y
CONFIG_DEBUG_TCBINFO=y
CONFIG_DEBUG_WARN=y
CONFIG_DEFAULT_TASK_STACKSIZE=4096
CONFIG_DEV_GPIO=y
CONFIG_DEV_ZERO=y
CONFIG_DRIVERS_AUDIO=y
CONFIG_DRIVERS_VIDEO=y
CONFIG_EE25XX_FREQUENCY=500
CONFIG_EEPROM=y
CONFIG_EXAMPLES_FB=y
CONFIG_EXAMPLES_LVGLDEMO=y
CONFIG_EXAMPLES_LVGLDEMO_STACKSIZE=65535
CONFIG_EXAMPLES_TOUCHSCREEN=y
CONFIG_FS_FAT=y
CONFIG_FS_LITTLEFS=y
CONFIG_FS_PROCFS=y
CONFIG_FS_PROCFS_REGISTER=y
CONFIG_GD25_SPIFREQUENCY=10400
CONFIG_GRAPHICS_LVGL=y
CONFIG_HAVE_CXX=y
CONFIG_HAVE_CXXINITIALIZE=y
CONFIG_INIT_ARGS="\"widgets\""
CONFIG_INIT_ENTRYNAME="lvgldemo"
CONFIG_INIT_ENTRYPOINT="lvgldemo_main"
CONFIG_INIT_STACKSIZE=65535
CONFIG_LCD=y
CONFIG_LIBC_NUMBERED_ARGS=y
CONFIG_LP503X=y
CONFIG_LV_ATTRIBUTE_FAST_MEM_USE_IRAM=y
CONFIG_LV_COLOR_DEPTH_32=y
CONFIG_LV_COLOR_MIX_ROUND_OFS=128
CONFIG_LV_COLOR_SCREEN_TRANSP=y
CONFIG_LV_DISP_DEF_REFR_PERIOD=50
CONFIG_LV_DPI_DEF=188
CONFIG_LV_FONT_MONTSERRAT_12=y
CONFIG_LV_FONT_MONTSERRAT_16=y
CONFIG_LV_FONT_MONTSERRAT_18=y
CONFIG_LV_FONT_MONTSERRAT_22=y
CONFIG_LV_FONT_MONTSERRAT_24=y
CONFIG_LV_FONT_MONTSERRAT_32=y
CONFIG_LV_MEM_CUSTOM=y
CONFIG_LV_PORT_TOUCHPAD_CURSOR_SIZE=10
CONFIG_LV_PORT_USE_FBDEV=y
CONFIG_LV_PORT_USE_TOUCHPAD=y
CONFIG_LV_TICK_CUSTOM=y
CONFIG_LV_TICK_CUSTOM_INCLUDE="port/lv_port_tick.h"
CONFIG_LV_USE_ASSERT_MEM_INTEGRITY=y
CONFIG_LV_USE_ASSERT_OBJ=y
CONFIG_LV_USE_ASSERT_STYLE=y
CONFIG_LV_USE_DEMO_MUSIC=y
CONFIG_LV_USE_DEMO_WIDGETS=y
CONFIG_LV_USE_PERF_MONITOR=y
CONFIG_M25P_SPIFREQUENCY=9000
CONFIG_MM_BACKTRACE=4
CONFIG_MM_BACKTRACE_DEFAULT=y
CONFIG_MQ_MAXMSGSIZE=64
CONFIG_MTD=y
CONFIG_MTD_AT25=y
CONFIG_MTD_GD25=y
CONFIG_MTD_M25P=y
CONFIG_NSH_ARCHINIT=y
CONFIG_NSH_BUILTIN_APPS=y
CONFIG_NSH_CMDOPT_DD_STATS=y
CONFIG_NSH_FILEIOSIZE=512
CONFIG_NSH_READLINE=y
CONFIG_NXFONTS_DISABLE_16BPP=y
CONFIG_NXFONTS_DISABLE_1BPP=y
CONFIG_NXFONTS_DISABLE_24BPP=y
CONFIG_NXFONTS_DISABLE_2BPP=y
CONFIG_NXFONTS_DISABLE_32BPP=y
CONFIG_NXFONTS_DISABLE_4BPP=y
CONFIG_NXFONTS_DISABLE_8BPP=y
CONFIG_PREALLOC_TIMERS=4
CONFIG_PRIORITY_INHERITANCE=y
CONFIG_PTHREAD_MUTEX_TYPES=y
CONFIG_PTHREAD_STACK_DEFAULT=2048
CONFIG_PWM=y
CONFIG_RAMLOG=y
CONFIG_RAM_SIZE=536870912
CONFIG_RAM_START=0x2000
CONFIG_RAM_VSTART=0x2000
CONFIG_RAW_BINARY=y
CONFIG_READLINE_CMD_HISTORY=y
CONFIG_READLINE_TABCOMPLETION=y
CONFIG_REGULATOR=y
CONFIG_REGULATOR_ACT8945A=y
CONFIG_RR_INTERVAL=200
CONFIG_SAMA5D27__492MHZ=y
CONFIG_SAMA5_ADC=y
CONFIG_SAMA5_ADC_CHAN4=y
CONFIG_SAMA5_ADC_CHAN5=y
CONFIG_SAMA5_ADC_CHAN6=y
CONFIG_SAMA5_ADC_CHAN7=y
CONFIG_SAMA5_BOOT_SDRAM=y
CONFIG_SAMA5_DDRCS_HEAP_END=0x3fe0
CONFIG_SAMA5

Re: App crashes if entrypoint but not from nsh

[Tim Hardisty]

A5_SPI0=y
CONFIG_SAMA5_TRNG=y
CONFIG_SAMA5_TSD=y
CONFIG_SAMA5_TWI0=y
CONFIG_SAMA5_TWI1=y
CONFIG_SAMA5_UART1=y
CONFIG_SAMA5_UART3=y
CONFIG_SAMA5_UDPHS=y
CONFIG_SAMA5_XDMAC0=y
CONFIG_SAMA5_XDMAC1=y
CONFIG_SAMA_TSD_RXP=900
CONFIG_SCHED_HAVE_PARENT=y
CONFIG_SCHED_HPWORK=y
CONFIG_SCHED_HPWORKPRIORITY=192
CONFIG_SCHED_HPWORKSTACKSIZE=2048
CONFIG_SCHED_WAITPID=y
CONFIG_SENDFILE_BUFSIZE=256
CONFIG_SENSORS=y
CONFIG_SENSORS_MAX31855=y
CONFIG_SERIAL_TERMIOS=y
CONFIG_SIG_DEFAULT=y
CONFIG_SPI_DELAY_CONTROL=y
CONFIG_SPI_EE_25XX=y
CONFIG_START_YEAR=2021
CONFIG_SYMTAB_ORDEREDBYNAME=y
CONFIG_SYSLOG_CONSOLE=y
CONFIG_SYSLOG_TIMESTAMP=y
CONFIG_SYSLOG_TIMESTAMP_REALTIME=y
CONFIG_SYSTEM_CLE=y
CONFIG_SYSTEM_CLE_CMD_HISTORY=y
CONFIG_SYSTEM_COLOR_CLE=y
CONFIG_SYSTEM_NSH=y
CONFIG_SYSTEM_NSH_STACKSIZE=2048
CONFIG_SYSTEM_UNIQUEID=y
CONFIG_TTY_SIGINT=y
CONFIG_UART1_SERIAL_CONSOLE=y
CONFIG_USART2_BAUD=38400
CONFIG_USART3_BAUD=10
CONFIG_VIDEO_FB=y
CONFIG_WATCHDOG=y
CONFIG_WQUEUE_NOTIFIER=y


On 05/07/2023 18:45, Petro Karashchenko wrote:
> Maybe you can share the defconfig for faulty case, so that can be inspected?
>
> On Wed, Jul 5, 2023, 8:29 PM Tim Hardisty  wrote:
>
>> Yes - both that and the lvgldemo stack size (up to 65535 each).
>>
>> On 05/07/2023 18:21, Xiang Xiao wrote:
>>
>> Do you try CONFIG_INIT_STACKSIZE instead?
>>
>> On Thu, Jul 6, 2023 at 1:01 AM Tim Hardisty > t...@hardisty.co.uk> wrote:
>>
>>
>>
>> Having got u-boot to actually do something, I now have a board that
>> powers up autonomously and runs nsh with no intervention from me. Quite
>> relieved!
>>
>> As a step towards it booting my own (barely started) app I thought I'd
>> play around with booting other example apps, and went for lvgldemo.
>>
>> This works just fine called from the nsh, but crashes very early on if
>> set as the startup program.
>>
>> - I have traced it a little way through so know it is calling the
>> lvgldemo main function. If I don't specify which demo to run in
>> INIT_ARGS it correctly prompts me that it needs this argument. With it
>> set to "music" or "widgets" (which both usually work just fine) it fails.
>>
>> - I have looked at Alan's (?) video (#047) but nothing I've missed
>> according to that.
>>
>> - I changed the lvgldemo stack size from the default 4096 to 65535 and
>> same behaviour. And done a distclean etc.
>>
>> - I tried another (much simpler) program (uniqueid) and that runs fine.
>>
>> Anyone seen anything similar? This is a good time for me to learn any
>> must-know stuff when it comes to running graphics apps at startup!
>>
>>
>>
>>
>>
>>
>>
>>

Re: App crashes if entrypoint but not from nsh

[Tim Hardisty]

Yes - both that and the lvgldemo stack size (up to 65535 each).

On 05/07/2023 18:21, Xiang Xiao wrote:

Do you try CONFIG_INIT_STACKSIZE instead?

On Thu, Jul 6, 2023 at 1:01 AM Tim Hardisty 
<mailto:t...@hardisty.co.uk> wrote:



Having got u-boot to actually do something, I now have a board that
powers up autonomously and runs nsh with no intervention from me. Quite
relieved!

As a step towards it booting my own (barely started) app I thought I'd
play around with booting other example apps, and went for lvgldemo.

This works just fine called from the nsh, but crashes very early on if
set as the startup program.

- I have traced it a little way through so know it is calling the
lvgldemo main function. If I don't specify which demo to run in
INIT_ARGS it correctly prompts me that it needs this argument. With it
set to "music" or "widgets" (which both usually work just fine) it fails.

- I have looked at Alan's (?) video (#047) but nothing I've missed
according to that.

- I changed the lvgldemo stack size from the default 4096 to 65535 and
same behaviour. And done a distclean etc.

- I tried another (much simpler) program (uniqueid) and that runs fine.

Anyone seen anything similar? This is a good time for me to learn any
must-know stuff when it comes to running graphics apps at startup!

App crashes if entrypoint but not from nsh

[Tim Hardisty]

Having got u-boot to actually do something, I now have a board that 
powers up autonomously and runs nsh with no intervention from me. Quite 
relieved!

As a step towards it booting my own (barely started) app I thought I'd 
play around with booting other example apps, and went for lvgldemo.

This works just fine called from the nsh, but crashes very early on if 
set as the startup program.

- I have traced it a little way through so know it is calling the 
lvgldemo main function. If I don't specify which demo to run in 
INIT_ARGS it correctly prompts me that it needs this argument. With it 
set to "music" or "widgets" (which both usually work just fine) it fails.

- I have looked at Alan's (?) video (#047) but nothing I've missed 
according to that.

- I changed the lvgldemo stack size from the default 4096 to 65535 and 
same behaviour. And done a distclean etc.

- I tried another (much simpler) program (uniqueid) and that runs fine.

Anyone seen anything similar? This is a good time for me to learn any 
must-know stuff when it comes to running graphics apps at startup!

Re: Bootloaders other than u-boot?

[Tim Hardisty]

Yes, I've done similar on another product and it worked well. I have 
allowed myself to get blinkered by the plethora of supposedly easy/good 
that options u-boot offered.


Note to self: KISS ;-)

On 01/07/2023 18:05, Gregory Nutt wrote:


What I am trying to cater for is the inevitable occasion where a 
customer does a firmware update that goes wrong and seems to "brick" 
the device, as the "app" nor-flash is corrupted and an in-app updater 
can't be run.


Back in the day when I was doing set-top boxes we would support 
updating many thousands of boxes via cable overnight.  Of course, many 
of the updates would fail for some reason or another.


So we kept two copies of the FLASH image in the filesystem:  The 
newest download and the last known good.  On reset, the bootloader 
would load the newest download first if is is present; otherwise it 
would load the last known good.  If the newest download failed to 
boot, it was removed (and be updated again the next night).  If it 
booted successfully, it would mark itself as the "last known good."


That logic is pretty simple and worked well.  Lots of other people in 
this list have dealt with this and perhaps have developed some better 
solutions.





--

Regards,

Tim Hardisty


A picture containing text, clipart Description automatically generated



+44 (0) 1305 534535



<http://www.jti.uk.com/>



JTi.uk.com <https://www.jti.uk.com/>



<https://www.facebook.com/JTinnovations/>



\JTinnovations <https://www.facebook.com/JTinnovations/>

JT Innovations Ltd.

Registered office: 36 East St, Weymouth, Dorset, DT3 4DT, UK.

Company number 7619086

VAT Registration GB 111 7906 35

Re: Bootloaders other than u-boot?

[Tim Hardisty]

I usually only ever find very deep water...

u-boot does all the clever/arch stuff well but I think (for the 
not-so-popular Cortex A5) has buggy and undocumented "clever" stuff such 
as RNDIS/DFU/etc.


One possibility that occurs to me is to use an additional boot stage, as 
an alternative boot, from u-boot to a NuttX "updater app" rather than 
the "main" app, that handles this after the normal boot sequence is 
interrupted by some method. The "method" is working with u-boot just not 
the subsequent firmware download methods.


What I am trying to cater for is the inevitable occasion where a 
customer does a firmware update that goes wrong and seems to "brick" the 
device, as the "app" nor-flash is corrupted and an in-app updater can't 
be run. Current product (AT91SAM9261 based) suffers that as it doesn't 
have enough ram to download a complete image before doing the 
erase/program function. I expect to be left with MUCH more memory on 
this one so can hopefully rely on dfu to RAM before the flash is ever 
touched. And enough flash to store 2 images as well.


Plenty of options that mean I don't have to write a PC app and go 
through all the signing malarkey etc.


On 01/07/2023 17:41, Gregory Nutt wrote:

On 7/1/2023 10:27 AM, Tim Hardisty wrote:
Lots of work to do a full u-boot replacement, yes. But a basic one 
using existing NuttX stuff such as RNDIS, dfu, mtd etc. - for MY 
board at least - would not be much work. He said...naively!


You often can't know how deep the water is until you get a little wet.

One thing I would mention.  A bootloader is an app alright.  But it 
may need to use some of internal OS interfaces to control things like 
interrupts, MMU, caches, etc. it may need to reset the CPU or other 
actions that normal applications would not do.  That raises a few 
architectural issues (and explains why those primitive loaders are in 
the board src/ directory and not in apps/).


Ideally it would run in supervisor mode with a FLAT memory model.



--

Regards,

Tim Hardisty


A picture containing text, clipart Description automatically generated



+44 (0) 1305 534535



<http://www.jti.uk.com/>



JTi.uk.com <https://www.jti.uk.com/>



<https://www.facebook.com/JTinnovations/>



\JTinnovations <https://www.facebook.com/JTinnovations/>

JT Innovations Ltd.

Registered office: 36 East St, Weymouth, Dorset, DT3 4DT, UK.

Company number 7619086

VAT Registration GB 111 7906 35

Re: Bootloaders other than u-boot?

[Tim Hardisty]

Lots of work to do a full u-boot replacement, yes. But a basic one using 
existing NuttX stuff such as RNDIS, dfu, mtd etc. - for MY board at 
least - would not be much work. He said...naively!


On 01/07/2023 17:14, Tomek CEDRO wrote:

On Sat, Jul 1, 2023 at 5:38 PM Xiang Xiao wrote:

Why not develop a nuttx based bootloader?
We have produced more than ten million devices, all run nuttx with
different configurations in the different phases(bootloader, ota, gui app),
cores(sensor hub, audio dsp), even security mode(tee).
The benefit of this approach include:

1. You just need write driver once and reuse in all possible scenario
2. Don't need learn and switch the development environment

When looking at Lup's work on porting NuttX to StarFive JH7110 SoC
(STAR64 and VisionFive2 boards) we were laughing that the whole NuttX
would be probably smaller than the UBoot itself :-)

Its a really nice idea but probably really lots of work :-)

--
CeDeROM, SQ7MHZ,http://www.tomek.cedro.info



--

Regards,

Tim Hardisty


A picture containing text, clipart Description automatically generated



+44 (0) 1305 534535



<http://www.jti.uk.com/>



JTi.uk.com <https://www.jti.uk.com/>



<https://www.facebook.com/JTinnovations/>



\JTinnovations <https://www.facebook.com/JTinnovations/>

JT Innovations Ltd.

Registered office: 36 East St, Weymouth, Dorset, DT3 4DT, UK.

Company number 7619086

VAT Registration GB 111 7906 35

Re: Bootloaders other than u-boot?

[Tim Hardisty]

That is what I am beginning to think.

I now have the 2022 version of u-boot actually running with a console I 
can get to. That's a major step forward and was only done by starting 
again as I could not see the difference in the device tree or code no 
matter how long I stared at it!


I can even attempt a dfu, in as much as it recognises the command and 
starts to do "something"...then crashes out big time. Not found how to 
debug u-boot (VS Code/J-link) and really don't fancy prodding around the 
Internet to see if I hit lucky.


The code that Gregory pointed out is, indeed, basic, but will allow the 
board to boot my app without u-boot as an intermediatary. DFU and RNDIS 
(etc) exist already so are easy to incorporporate,  so this has a great 
appeal. Although it does feel a little like re-inventing the wheel so I 
will take a long hard look at MCUboot too.


I am going to give up on u-boot now as I have to get on with the actual 
app as this has been a BIG and unwanted distraction.


On 01/07/2023 16:38, Xiang Xiao wrote:

Why not develop a nuttx based bootloader?
We have produced more than ten million devices, all run nuttx with
different configurations in the different phases(bootloader, ota, gui app),
cores(sensor hub, audio dsp), even security mode(tee).
The benefit of this approach include:

1. You just need write driver once and reuse in all possible scenario
2. Don't need learn and switch the development environment


On Sat, Jul 1, 2023 at 5:56 PM Tim Hardisty  wrote:


Not directly related to NuttX but I hope you don't mind me asking here.

Bottom line: has anyone used any bootloader other than u-boot to allow usb
dfu or RNDIS-type firmware updates, and that easily boot NuttX?

My board uses the usual SAMA5 methodology of AT91
bootstrap->u-boot->NuttX. It all works as expected, as far as running code
is concerned, but I simply cannot get u-boot to enable the USB port for DFU
or RNDIS functions and I need the product to have user-friendly in-field
updates, ideally without me having to write any PC update software.

U-boot has defeated me for over 2 weeks now, and simply refuses to even
"activate" the USB (i.e. a PC never even sees the connect let alone any
functionality: yes, the USB port does work for NuttX and sam-ba code
flashing); device trees are the invention of the devil; and an unholy
apparent mish mash of driver model and "legacy" modes; no SAM boards in the
u-boot trees appearing to have relevant config options I can copy. Add to
that: using latest u-boot rather than the 2020 version I currently have
"working"means it won't even find a console serial port any more, the lack
of response on the relevant AT91 u-boot github to questions, and I am just
about ready to give up :(

But I need a bootloader!

Re: Bootloaders other than u-boot?

[Tim Hardisty]

Thanks Alan - I am spending just a few more hours on u-boot, and then I 
think Tomek's suggestion of MCUboot looks most promising :)

On 01/07/2023 13:43, Alan C. Assis wrote:
> Hi Tim,
>
> I think everybody already cited all main bootloader used with embedded 
> systems.
>
> Maybe the only other suggestion is uMon (http://www.umonfw.com) an old
> bootloader that still active, but I didn't find port to SAMA5D.
>
> It was used mainly with Coldfire MCUs, but was ported to ARM too.
>
> BR,
>
> Alan
>
> On 7/1/23, Tim Hardisty  wrote:
>> Not directly related to NuttX but I hope you don't mind me asking here.
>>
>> Bottom line: has anyone used any bootloader other than u-boot to allow usb
>> dfu or RNDIS-type firmware updates, and that easily boot NuttX?
>>
>> My board uses the usual SAMA5 methodology of AT91 bootstrap->u-boot->NuttX.
>> It all works as expected, as far as running code is concerned, but I simply
>> cannot get u-boot to enable the USB port for DFU or RNDIS functions and I
>> need the product to have user-friendly in-field updates, ideally without me
>> having to write any PC update software.
>>
>> U-boot has defeated me for over 2 weeks now, and simply refuses to even
>> "activate" the USB (i.e. a PC never even sees the connect let alone any
>> functionality: yes, the USB port does work for NuttX and sam-ba code
>> flashing); device trees are the invention of the devil; and an unholy
>> apparent mish mash of driver model and "legacy" modes; no SAM boards in the
>> u-boot trees appearing to have relevant config options I can copy. Add to
>> that: using latest u-boot rather than the 2020 version I currently have
>> "working"means it won't even find a console serial port any more, the lack
>> of response on the relevant AT91 u-boot github to questions, and I am just
>> about ready to give up :(
>>
>> But I need a bootloader!
>>
>>

Bootloaders other than u-boot?

[Tim Hardisty]

Not directly related to NuttX but I hope you don't mind me asking here.

Bottom line: has anyone used any bootloader other than u-boot to allow usb dfu 
or RNDIS-type firmware updates, and that easily boot NuttX?

My board uses the usual SAMA5 methodology of AT91 bootstrap->u-boot->NuttX. It 
all works as expected, as far as running code is concerned, but I simply cannot 
get u-boot to enable the USB port for DFU or RNDIS functions and I need the 
product to have user-friendly in-field updates, ideally without me having to 
write any PC update software.

U-boot has defeated me for over 2 weeks now, and simply refuses to even 
"activate" the USB (i.e. a PC never even sees the connect let alone any 
functionality: yes, the USB port does work for NuttX and sam-ba code flashing); 
device trees are the invention of the devil; and an unholy apparent mish mash 
of driver model and "legacy" modes; no SAM boards in the u-boot trees appearing 
to have relevant config options I can copy. Add to that: using latest u-boot 
rather than the 2020 version I currently have "working"means it won't even find 
a console serial port any more, the lack of response on the relevant AT91 
u-boot github to questions, and I am just about ready to give up :(

But I need a bootloader!

Re: STM32 and GDB - How do I generate the ELF file?

[Tim Hardisty]

Where should that be in the (current) documentation? I’ll go and add it as I 
didn’t know this.

From: Gregory Nutt 
Reply to: "dev@nuttx.apache.org" 
Date: Sunday, 11 June 2023 at 18:16
To: "dev@nuttx.apache.org" 
Subject: Re: STM32 and GDB - How do I generate the ELF file?

On 6/11/2023 11:07 AM, Mark Stevens wrote:
Is there any reason for not having the extension?

To me the extension adds information about the file.

The name is actually BIN = nuttx$(EXEEXT) but EXEEXT is not normally
defined.

Different toolchains generate executable images in different formats and
that format is not known at that level.  If you want nuttx.elf just
define EXEEXT to be .elf in your Make.defs file.

Re: Thank you!

[Tim Hardisty]

I have been tinkering with a blog/AboutMe thingy, also using it as a way to 
learn markdown. Although I've not updated it for a short while, I decided to 
add it to my GitHub profile if anyone is at all interested:

https://github.com/TimJTi

Audio Tone to /dev/audio driver, or via NXPlayer

[Tim Hardisty]

NXPlayer has an audio tone option to play tones, but no underlaying code hooks 
for it.

Prompted by someone else's question today, I was thinking of looking at the 
Audio Tone Generator in "Device Drivers | Audio Device Support" to see if it 
could be adapted to output to a /dev/audio/pcm driver, and/or hooked into 
NXPlayer.

Unless I'm missing something and this is already available somewhere/somehow?

Thank you!

[Tim Hardisty]

My NuttX journey started in earnest about a year ago, after an enforced pause 
for personal reasons. The processor on my board is ATSAMA5D2. In the last year 
I have submitted (nearly all) merged PRs for this processor:

- mcan 
- flexcom SPI
- ClassD audio
- SPI DMA
- flexcom USART
- efuse support
- fixed usb problems, related to RNDIS
- added dual role port/OTG capability
- ADC fixes
- TSD fixes
- SPI performance enhancements

Also added drivers for:

- apds9922 proximity/light sensor
- LP503x RGB multi-LED driver
- FUSB302 USB-C controller
- act8945A PMIC power control

And other stuff along the way and things I have already forgotten.

I have learned a lot, my coding is more consistent, and I am WAY more 
comfortable with not just NuttX but POSIX in general, and can mostly use GitHub 
with only a small amount of swearing!

All this has resulted in me finally being in a position to actually start 
writing the application I need for the niche automotive product we'll hopefully 
release this autumn.

So: I would like to thank everyone who has replied to my usually dumb 
questions, reviewed my PRs, and, generally, have just been so very supportive 
and helpful.

I couldn't have done it without you. Once the final product is ready I will 
post much more information, pictures, videos, whatever.

Until then: please keep helping as you have so far :)

THANK YOU EVERYONE!!!

Re: SPI EEPROM

[Tim Hardisty]

Thanks for replies.

 

Alan – your video (which I had watched!) is for AT24 I2C EEPROM and it can’t be 
done in the same way for SPI EEPROM with no device ID to read back We had this 
same conversation a year or 2 ago when I was very new to NuttX, and I even 
found an archived email saying I’d sorted it, but no record of how I sorted it. 
My lack of thoroughness :(

 

Sebastien. Of course, it’s a character driver…der. I have been so bogged down 
in choosing a filesystem for the big NOR flash I lost the plot!

 

Gregory. Loop device – that’s what I used a couple of years ago! Not for real, 
but just to prove the device could be written to etc without having to do 
anything clever (i.e. just from an nsh prompt).

 

This device will be used to store a settings struct, so a character driver will 
work fine – I will probably use a FAT-formatted ram drive as an intermediary 
storage area to allow access via USB from PCs etc., probably using YAML 
formatting. Still thinking this all through.

 

From: Tim Hardisty 
Reply to: 
Date: Thursday, 25 May 2023 at 17:35
To: "dev@nuttx.apache.org" 
Subject: SPI EEPROM

 

Could have sworn I had this working a year or 2 ago but it's stumped me today...

 

I have an SPI EEPROM device on my board, and use "ee25xx_initialize" to 
register it as /dev/at25. That works fine.

 

But I can't do anything with it.

 

Unlike at25_initialize, the ee25xx_initialize doesn't return mtd_dev_s, just a 
success/fail, so I can't then use an FTL etc to allow me to mount it in anyway.

 

How can I get this device mounted with some form of FS on it so I can 
read/write config data to it?

 

Perhaps FTL isn't the way to go; if so, I've forgotten what is!

 

SPI EEPROM

[Tim Hardisty]

Could have sworn I had this working a year or 2 ago but it's stumped me today...

I have an SPI EEPROM device on my board, and use "ee25xx_initialize" to 
register it as /dev/at25. That works fine.

But I can't do anything with it.

Unlike at25_initialize, the ee25xx_initialize doesn't return mtd_dev_s, just a 
success/fail, so I can't then use an FTL etc to allow me to mount it in anyway.

How can I get this device mounted with some form of FS on it so I can 
read/write config data to it?

Perhaps FTL isn't the way to go; if so, I've forgotten what is!

Re: Touchscreen scaling/LVGL

[Tim Hardisty]

Thanks Greg – I’ll take a look at those links, and take on board what you’re 
saying.

From: Gregory Nutt 
Reply to: "dev@nuttx.apache.org" 
Date: Tuesday, 23 May 2023 at 19:52
To: "dev@nuttx.apache.org" 
Subject: Re: Touchscreen scaling/LVGL


On 5/23/2023 12:11 PM, Tim Hardisty wrote:
Hi,

This is perhaps more a POSIX/general programming question than NuttX but you 
are all, so often, so very helpful :)

A touchscreen peripheral (SAMA5D2 as it happens) delivers X and Y coordinates 
scaled 0-4095.

LVGL wants them scaled to the actual size of the display (800x480 in my case).

I'm not 100% sure that the chip’s TSD driver is the place to scale it?

The TSD driver creates a generic /dev/input0 character driver, which is what 
LVGL (set via Kconfig) opens. Scaling within the LVGL code isn’t right either, 
I don’t think?

I can only think of either:

1) creating a new character driver that does a translation – registered as 
/dev/input1 (or whatever) that LVGL uses, and this driver reads input0 when 
required and returns translated values.

2) Enhance the chip's TSD driver after all, using a Kconfig setting to enable 
X/Y scaling to the display's size (set in board-specific files already).

Both seem a little messy though so perhaps I’m missing something obvious? Can't 
be the first to need to do this?

Thanks,

TimH

Many touchscreens require calibration by the application via a
calibration screen.  Hence, only the application knows the scale factors
to use and so scaling is done by the application.

Scaling could also be done by the driver using calibration information
provided via an IOCTL.  All resistive touchscreens require calibration.
If your touchscreen does not require calibration, then I suppose it
could even be provided by a configuration setting.

Raw, unscaled input is also needed by the application, however (in order
to do calibration, for one).

Scaling in the driver could also be inefficient since the driver does
not know if the sample will be used or not.  It might be better to to
scale in the application even if calibration is not necessary.

A quick Google provides some references for touchscreen calibration with
LVGL:

  * https://forum.lvgl.io/t/calibrate-a-touchscreen-with-tpcal-h/244
  * https://github.com/jakpaul/lvgl_touch_calibration

The are other calibration displays under nutts-apps/ (not for LVGL)

Touchscreen scaling/LVGL

[Tim Hardisty]

Hi,

This is perhaps more a POSIX/general programming question than NuttX but you 
are all, so often, so very helpful :)

A touchscreen peripheral (SAMA5D2 as it happens) delivers X and Y coordinates 
scaled 0-4095.

LVGL wants them scaled to the actual size of the display (800x480 in my case).

I'm not 100% sure that the chip’s TSD driver is the place to scale it?

The TSD driver creates a generic /dev/input0 character driver, which is what 
LVGL (set via Kconfig) opens. Scaling within the LVGL code isn’t right either, 
I don’t think?

I can only think of either:

1) creating a new character driver that does a translation – registered as 
/dev/input1 (or whatever) that LVGL uses, and this driver reads input0 when 
required and returns translated values.

2) Enhance the chip's TSD driver after all, using a Kconfig setting to enable 
X/Y scaling to the display's size (set in board-specific files already).

Both seem a little messy though so perhaps I’m missing something obvious? Can't 
be the first to need to do this?

Thanks,

TimH

Re: esp32 custom board gpio and ws2812 problem

[Tim Hardisty]

Maybe OTG is superseded? USB C dual role port is the way to go, but needs a 25c 
 chip and software support to make it work. FUSB30x FTW :)

From: "Alan C. Assis" 
Reply to: "dev@nuttx.apache.org" 
Date: Saturday, 20 May 2023 at 20:10
To: "dev@nuttx.apache.org" 
Subject: Re: esp32 custom board gpio and ws2812 problem

Hi Tomek,

On 5/20/23, Tomek CEDRO mailto:to...@cedro.info>> wrote:
Well all ESP32-C3 boards that I have (DevKit, M5) have UART-to-USB
converter so no JTAG so far.. I will order Beetle ESP32-C3 this one
should have direct USB/UART/JTAG pins on the USB-C connector :-)

I have ordered ESP32-S2 as it has USB OTG. I really miss RISC-V MCU
with USB Device/OTG.. ESP32-C6 would be perfect if it only had this
(it has WiFi + BLE + Mesh already) :-)

Is there any chance that Espressif releases ESP32-C6 + USB OTG anytime soon?
:-)

C6 is like C3, only USB Serial/JTAG, not real USB OTG support:

https://www.espressif.com/sites/default/files/documentation/esp32-c6_technical_reference_manual_en.pdf

BR,

Alan

RE: Odd DMA issue

[Tim Hardisty]

I have compared the SAMv7 SPI XDMAC to SAMA5, and checked the PR and dcache 
suggestions from Simon Filgis and only found one discrepancy::

SAMA5 had DMACH_FLAG_MEMBURST_4 compared to SAMv7 which had 
DMACH_FLAG_MEMBURST_1.

I won't profess to understand the detailed significance, but DMA does now work 
having changed it, but I see the fairly recently added DMA support for SAMA5 
flexcom has DMACH_FLAG_MEMBURST_4 as well, so I will try and understand this 
better for sure.

I am now added spi_setdelay functionality to the SAMA5 SPI driver since it was 
missing, and the default delays are horrendous, and I will do a PR for all of 
this soon.

I will also do a separate PR for the GD25 driver to allow the various delays to 
be set via Kconfig and passed to the lower level drivers using SET_DELAY, 
otherwise the delays will never be set in the driver.

I currently have read DMA at around 600KB/s (using dd to read from GD25 to 
/dev/null) and write at 79KB/s (dd from FAT formatted ramdrv to GD25 memory 
clocked at 103MHz). I think it should go faster, and I will probably keep 
plugging away at it, but 20x faster than it was last week.


>-Original Message-
>From: Tim Hardisty 
>Sent: Wednesday, May 17, 2023 7:31 PM
>To: dev@nuttx.apache.org
>Subject: Re: Odd DMA issue
>
>Good suggestion – thanks!
>
>From: Petro Karashchenko  Reply to:
>"dev@nuttx.apache.org" 
>Date: Wednesday, 17 May 2023 at 19:28
>To: "dev@nuttx.apache.org" 
>Subject: Re: Odd DMA issue
>
>I think you can try to compare versus SAMv7 SPI+DMA driver that is
>working well and see if there are obvious differences.
>
>BR,
>Petro
>
>On Wed, May 17, 2023, 9:18 PM Simon Filgis filgis.de<mailto:si...@ingenieurbuero-filgis.de>>
>wrote:
>
>D-Cache flush?
>
>--
>Ingenieurbüro-Filgis
>USt-IdNr.: DE305343278
>--
>sent by mobile phone
>
>Tim Hardisty mailto:t...@hardisty.co.uk>> schrieb am
>Mi., 17. Mai 2023, 20:05:
>
>> I am working on getting DMA working on the SPI peripheral of the
>SAMA5D2.
>>
>> DMA reads now work well, but the writes take absolutely forever…unless
>> I have dma debug info enabled, when write transactions (to a GD25Q
>> flash)
>do
>> then work.
>>
>> I’m working through it, as it sounds like a race condition or other
>> timing/sequence problem but if anyone by any chance has encountered
>> anything similar, clues or suggestions would be most welcome!
>>
>> Thx,
>>
>> Tim
>>
>

Re: Odd DMA issue

[Tim Hardisty]

Good suggestion – thanks!

From: Petro Karashchenko 
Reply to: "dev@nuttx.apache.org" 
Date: Wednesday, 17 May 2023 at 19:28
To: "dev@nuttx.apache.org" 
Subject: Re: Odd DMA issue

I think you can try to compare versus SAMv7 SPI+DMA driver that is working
well and see if there are obvious differences.

BR,
Petro

On Wed, May 17, 2023, 9:18 PM Simon Filgis 
mailto:si...@ingenieurbuero-filgis.de>>
wrote:

D-Cache flush?

--
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278
--
sent by mobile phone

Tim Hardisty mailto:t...@hardisty.co.uk>> schrieb am Mi., 
17. Mai 2023, 20:05:

> I am working on getting DMA working on the SPI peripheral of the SAMA5D2.
>
> DMA reads now work well, but the writes take absolutely forever…unless I
> have dma debug info enabled, when write transactions (to a GD25Q flash)
do
> then work.
>
> I’m working through it, as it sounds like a race condition or other
> timing/sequence problem but if anyone by any chance has encountered
> anything similar, clues or suggestions would be most welcome!
>
> Thx,
>
> Tim
>

Re: Odd DMA issue

[Tim Hardisty]

In what way?

I am concerned by a comment in the sama5 xdmac code which says:

“Calls to sam_dmatxsetup() and sam_dmarxsetup() must not be intermixed on the 
same transfer, however.”

They are sort of intermixed as part of the SPI exchange function – which is 
near enough identical to most arm processors, though.

From: Simon Filgis 

D-Cache flush?

--
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278
--
sent by mobile phone

Tim Hardisty mailto:t...@hardisty.co.uk>> schrieb am Mi., 
17. Mai 2023, 20:05:

I am working on getting DMA working on the SPI peripheral of the SAMA5D2.

DMA reads now work well, but the writes take absolutely forever…unless I
have dma debug info enabled, when write transactions (to a GD25Q flash) do
then work.

I’m working through it, as it sounds like a race condition or other
timing/sequence problem but if anyone by any chance has encountered
anything similar, clues or suggestions would be most welcome!

Thx,

Tim

Odd DMA issue

[Tim Hardisty]

I am working on getting DMA working on the SPI peripheral of the SAMA5D2.

DMA reads now work well, but the writes take absolutely forever…unless I have 
dma debug info enabled, when write transactions (to a GD25Q flash) do then work.

I’m working through it, as it sounds like a race condition or other 
timing/sequence problem but if anyone by any chance has encountered anything 
similar, clues or suggestions would be most welcome!

Thx,

Tim

critical_section vs mutex

[Tim Hardisty]

I am making use of the efuse driver code to create a driver for the sama5 
secure fuse peripheral. There are not many drivers I can use as examplars but 
there is code that follows this for the esp32 family of processors.

Those drivers protect fuse writes by encapsulating the entire write procedure 
(including validity checking, and code that works out which actual efuses need 
to be written to etc) as a critical section.

That seems unnecessary to me?

I’m thinking that only the actual stage of blowing the fuses needs to be 
protected - and that a mutex is more appropriate and that the read of an efuse 
should be similarly protected, in case a write is being done at the time a read 
is requested?

Or is there a reason I don’t “get” meaning a critical section wrapper is more 
appropriate?

RE: SAMA5 secure fuse controller driver

[Tim Hardisty]

I am trying to make use of the template/skeleton in include/nuttx/efuse.h

It defines:

struct efuse_param
{
  FAR const efuse_desc_t **field;
  size_t  size;
  FAR uint8_t *data;
};

With the explanation:

/* The efuse_param is used by the application to inform which field(s)
 * will be passed to the ioctl() operation.
 *   - 'efuse_desc_t *field[]': contains one or more field and it
 * it terminated by a NULL to indicate there is no more fields.
 * NOTE: normally the application don't need to create these fields
 *   they are mapped inside an arch efuse table and referenced
 *   in a header file inside include/nuttx/efuse/ directory.
 *   - size: how many bits the field(s) use
 *   - data: an application side allocated buffer where the read operation
 *   will store the efuse bits, so the number of allocated bytes
 *   need to be enough to store all bits. For write operation, this
 *   pointer contains the bits to be written.
 */

There are no implementations that use this. Perhaps it's because it's the end 
of a long week, but I can't get my head around what I'm supposed to do with 
this.

Can some kind person explain how it is to be used, please?

Perhaps use the example of the SAMA5D2 that has 32 bit fuses (SFC_DR0 through 
SFC_DR23)? What should the "arch efuse table" look like, where would it be, and 
how is it to be referenced in a (new) header file?

Also, data is a uint8_t, but this arch has 32 bit "fields". Should I just stick 
with 8 bit "fields" and have 4 times as many? Or have I missed the point of 
"fields"?

Thank you!

>-Original Message-
>From: Tim Hardisty 
>Sent: Tuesday, April 25, 2023 7:33 PM
>To: dev@nuttx.apache.org
>Subject: SAMA5 secure fuse controller driver
>
>The SAMA5 support has no driver for the secure fuse peripheral. Kconfig
>allows you to “enable” it but there’s no underlying code.
>
>Before I go ahead and create a character driver for this, is the omission
>for a “good” reason?
>
>The driver would handle the relatively straightforward management of
>programming the fuses, as well as obviously allowing you to read values.
>If another arch has anything similar please point me in its direction so
>I can create one that’s similar.
>
>Thanks,
>
>TimJTi.