On 30/04/2025 16:36, Karel Kočí wrote:
There are actually two ways. One for just application, but you probably know
that (`openlog("", LOG_PERROR, LOG_USER)`)
openlog is not supported in NuttX it seems. Sigh.
On 30/04/2025 16:36, Karel Kočí wrote:
On Wed 30 Apr 2025 03:45:36 PM , Tim Hardisty wrote:
I think that this system already exists and is the syslog.
I cannot find anywhere to configure NuttX syslog to send output to
stdout or stderr
...configure system itself to send syslog output
See inline.
On 30/04/2025 14:26, Karel Kočí wrote:
Hi,
On Wed 30 Apr 2025 12:19:02 PM , Tim Hardisty wrote:
5. One issue I have with NXboot is lack of printf-type error/info
messages
I think that this system already exists and is the syslog.
I cannot find
Thanks Karel.
See below, inline.
On 30/04/2025 11:06, Karel Kočí wrote:
4. MCUboot - for example - does the copy to RAM itself so, as has been
suggested, it would be good if NXboot gains this too. It will need
the destination RAM address for this which could:
* either be via
c setting. Need to make sure it
is backwards compatible though.
On 29/04/2025 22:17, Tim Hardisty wrote:
I believe I am over-thinking this and genuinely appreciate your input.
I will sleep on this and think again tomorrow. Thanks!
On 29 Apr 2025, at 21:23, Karel Kočí wrote:
On Tue 29 Apr 2025 08:
I believe I am over-thinking this and genuinely appreciate your input.
I will sleep on this and think again tomorrow. Thanks!
> On 29 Apr 2025, at 21:23, Karel Kočí wrote:
>
> On Tue 29 Apr 2025 08:45:11 PM , Tim Hardisty wrote:
>>
>> The structures are available in t
etter thing. But I don't know how generic that could be, across
many many architectures. I'll have to ponder that - took me a while to
get the right assembly code for my arch (SAMA5D2). I may need to think
laterally here!
On 29/04/2025 20:24, Michal Lenc wrote:
Hi Tim,
If I remembe
I am adding enhancements to my custom image booting software (that
copies the image from flash to internal SDRAM).
As part of that I would like, via PR, to expose /struct
nxboot_img_header/ and it's associated /struct nxboot_hdr_version/ and
/struct nxboot_img_version/ via a public header file
Out of interest, I took a 800x480 png (that I currently use as a
splashscreen):
* png size: 56KiB
* C file, using LVGL image converter: 5.4MiB
Eek!
On 28/03/2025 13:06, Nathan Hartman wrote:
Replying inline below:
On Thu, Mar 27, 2025 at 5:15 PM Tim Hardisty
wrote:
Hi Nathan,
Thanks
that bottoms out.
Thank you,
Tim.
On 27/03/2025 19:12, Tim Hardisty wrote:
Thanks for joining in the conversation Pavel.
I currently have my INIT_ENTRYPOINT set to the (new) fbcon
example app, so any stdout and stderr output appear on the
framebuffer LCD, and that then calls NXboot to load my app
en enabled (if
wanted)
WDYT ;-)
On 27/03/2025 18:43, Nathan Hartman wrote:
On Thu, Mar 27, 2025 at 9:18 AM Alan C. Assis wrote:
Hi Tim,
Yes, maybe it could be an option inside your fbcon app.
My initial thought was that having a nxlogo inside the kernel (like Linux)
could make it avail
way is another point I make. I could copy
nxboot_main and create my own version (as you suggest) but
that makes it non-std, hence suggesting modifying the
current NXboot to have the option to call a user error
task/app.
On 27/03/2025 18:11, Pavel Pisa wrote:
Hello Tim and Alan,
I think that spl
n my
"main" custom app.
On balance, I'm thinking FBCON.
Also:i f we wanted to do something "fancy" on multi-cpu architectures,
what are the relevant system calls to get the number of cores?
On 24/03/2025 19:38, Alan C. Assis wrote:
Hi Tim,
Yes, these suggestions mak
I think I’ll leave that for someone with more experience… and time! This could
be raised as a specific issue on GitHub if someone could take the time to do
that and capture the details?
I can do quick win fixes as they benefit me and hopefully others too :-)
Regards,
Tim.
> On 25 Mar 2
I am just starting to use NXboot (having migrated from Uboot, then to
MCUboot, and finally settled on NXboot) and I'm wondering whether it
would benefit from some changes and/or enhancements now I've used all three.
Thoughts, observations, suggestions welcomed.
In no particular order:
1. Uboo
Thanks Greg. I have allowed myself to get carried away I think.
* I wanted stdout and stderr to render on a FB to display basic
messages during bootloading (MCUboot)
* There were FBtext examples but not quite what I wanted
* There is LVGLterm - again, not quite what I wanted but food for th
ll look into it.
For now, the remaining issue I have to solved is the decoding of the
VT100_CURSORL(n) and once I have that cracked I will submit a PR and we
can discuss it there too.
On 12/03/2025 13:14, Alan C. Assis wrote:
Hi Tim,
About your progress with fbcon, just realized you c
full blown console...much like nxterm but without the need of the nx
server etc.
On 08/03/2025 16:50, Alan C. Assis wrote:
Hi Tim,
Could you please try to run: "ls -l | hexdump"
It could show if the '\n' is received correctly.
BR,
Alan
On Fri, Mar 7, 2025 at 3:47
I am writing a Framebuffer console app that takes stdout and stderr and
renders the text to a framebuffer device. Based on existing NXGL code
and example apps.
It spawns NSH, and I get the NSH prompt on my LCD - and it basically
works. I have also added functions to decode the handful of VT100
S unclear how to vote. Reply to any reply? With different formatting
and (mis)quotes? So i will not quote and you can sort it out I hope!!
TimH: +1 to all - on the basis that if this doesn't work out quite right
it will be reviewed and changed. Best to try something like this than
not - it
Hi,
Voting again (my previous e-mail was discarded in the voting process):
1. Contributing Guidelines with hints for Reviewers.
> We are adding additional section for Reviewers to Contributing
> Guidelines in order to provide checklist and complementary set of
> rules that should filter out break
I was only skim reading the discussions on LTS, so probably missed
detailed descriptions/conclusion of the LTS proposal. It seems a great
idea but @raiden00pl makes a valid point I think?
This is a vote for 13.0.0 which is an LTS candidate I would imagine.
Once out in the wild, any fixes (not
ut only mode when no input is required
> :-) Input would require serial port like transport, keyboard, or
> on-screen keyboard that makes things a bit more complicated :-)
> Tomek
>
>> On Mon, Feb 17, 2025 at 8:11 PM Tim Hardisty wrote:
>>
>> Just thinking out
Assis wrote:
Hi Tim,
I think there is not a framebuffer text in place for NuttX, but you can use
the code to handle text fonts from nx graphics to render the text directly
in the framebuffer.
For Linux some years ago I used fbtext
https://sourceforge.net/projects/fbtext/ to print a message from init
Thanks Alan - I'll see if I can find nx graphics code to repurpose and,
if not immediately obviously, I'm sure there's code out there, such the
fbtext tool you linked to.
On 16/02/2025 10:45, Alan C. Assis wrote:
Hi Tim,
I think there is not a framebuffer text in place for Nut
What is efficient solution to just do text though?
> On 15 Feb 2025, at 13:42, Alan C. Assis wrote:
>
> Hi Tim,
>
> You can create a NuttX application with LVGL and display your message or
> image.
>
> Actually you don't need to use a graphic library if yo
Hello NuttX Colleagues!
During MCUboot I want to display text messages on the framebuffer LCD
driver (/dev/fb). This could either be via a FB console (useful for
other reasons) or a FB terminal, or something else.
I also quite like the idea of my main graphics app - LVGL based - having
a con
old sensors it's not possible to create portable applications.
The
new
sensor
framework solves this problem. Its main disadvantage currently is
operating
on float data,
in the future fixed-point math should be also supported for MCU
without
FPU.
czw., 13 lut 2025 o 16:46 Tim Hardisty
napisał
gt; Good question Tim,
>
> Ideally all sensors should have char device and uorb support, but I don't
> think we have this rule.
>
> Recently a driver was converted from char device to uorb, so for driver
> that are uorb only, you have to use uORB sensortest application.
>
&
point!
On 13/02/2025 00:12, Lwazi Dube wrote:
On Wed, 12 Feb 2025 at 13:10, Tim Hardisty wrote:
Thanks Lwazi and Peter. By examining the data in the NuttX binary I have
tentatively concluded that the binary, as stored as an MCUboot signed
bootable image:
* Has the 32 byte MCUboot header.
Ah - so something you choose to use or not? But still we'll have
"traditional" drivers for new sensors as they're added?
On 12/02/2025 19:29, Alan C. Assis wrote:
Hi Tim,
It came from PX4 and how it is used for our sensors.
BR,
Alan
On Wed, Feb 12, 2025 at 4:21 PM Tim H
Is uORB really just a PX4 thing? Not NuttX? Or did NuttX adopt uORB too
and I missed it?
Just curious :-)
On 12/02/2025 18:51, Alan C. Assis wrote:
Hi Yashvi,
BMI270 uses uORB, you need to use sensortest (CONFIG_SYSTEM_SENSORTEST)
Just verify if the sensor was created correctly at /dev/uorb/
e also been in dialogue with Microchip tech support who are
helpful and willing, but I've not got the definitive from them as yet. I
will update them with my current thinking and see what they say!
On 11/02/2025 23:58, Peter Barada wrote:
Tim,
Common across bulk of ARM processors, the vector
Hello all.
I'm trying to understand the "header" bytes of a NuttX .bin file (ELF?),
so I can try and locate and use the ARM Cortex A (SAMA5D2) reset and
stack pointer vectors in an MCUboot image.
It seems that there are 32 bytes (after the MCUboot header) of a
repeating pattern (0xe59ff018)
I have:
* SAMA5D2 (Arm Cortex-A) Xplained EV board
* SAMA5D27-SOM1 EV board
* Custom board with SAMA5D27C-1G (128Mybte SDRAM) with TFT+TS, NOR
flash, SPI peripherals, I2C peripherals, USB, GPIO. All using NuttX
drivers.
I need to finish the project I'm on (which is still a few months' w
7;m sure I can get there!
On 31/01/2025 22:44, Petro Karashchenko wrote:
Hi Tim,
I need to look into MCUboot loading strategies since in my case I was
executing from an internal flash drive, so there was no copying of the
image to RAM.
In general MCUboot expects an image to have a proper header
that myself.
It is really geared to Linux and not my cup of tea!!
On 31/01/2025 15:14, Petro Karashchenko wrote:
Hello Tim,
Some time ago I was adding MCUboot support for SAMv7 family that should be
pretty similar to your system. If you can give some more description of
your use case: RAM and RO
A5D2 reference boards (that I have a couple of) in the
repo so the information is captured for posterity!
The "why" is that Uboot has little if anything in the way of easy-to-use
A/B image swapping with reversion so I would have to code that myself.
It is really geared to Linux and no
uot;...until now lol.
Thanks,
TimH.
On 29/01/2025 02:46, Lwazi Dube wrote:
On Tue, 28 Jan 2025 at 13:30, Tim Hardisty wrote:
Hi all,
I am trying to get MCUboot to work on my custom board with a SAMA5D2
(Arm V7A) and after a lot of battles am nearly there.
I can boot into MCUboot stored in f
Hi all,
I am trying to get MCUboot to work on my custom board with a SAMA5D2
(Arm V7A) and after a lot of battles am nearly there.
I can boot into MCUboot stored in flash, and I can also download/debug it.
MCUboot is happy enough with my firmware images to call my board's
"board_boot-image"
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, 20
lable 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.
ote:
>
> 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 pl
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.
>>
>>
>>
t 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!
>
> Mayb
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 a
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:
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:
-)
>
> 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
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
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 InS
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 (he
han 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,
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
:
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 wi
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
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
tX (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 he
ll 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 check
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
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 f
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
+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?
Th
er 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 Grego
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
I need a "custom" lvgl fb interface of some sorts instead? Any
examples?
Thoughts and suggestions would be much appreciated!
Thanks,
Tim
+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,
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 whe
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
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 app
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!
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 s
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 t
n 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
gin 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
>
ards,
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 an
______
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 answe
2: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, De
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_f
e 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 devic
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 m
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 unkn
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 r
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
tively, 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
> 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 р.
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
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 or
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 fin
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
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
contribute
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
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 talki
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:
>
> A
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
Hz 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 de
nking 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 generi
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
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 enqueuin
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,
1 - 100 of 313 matches
Mail list logo
