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
r correctly, these structures are public now, you should
be able to include from your application.
Best regards,
Michal
On 4/29/25 19:48, Tim Hardisty wrote:
I am adding enhancements to my custom image booting software (that
copies the image from flash to internal SDRAM).
As part of that I w
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
display the logo unless it's going
to be visible for at least 0.5 seconds. If nxboot starts, finds firmware,
and then branches to firmware, and if that entire process takes < 0.5
seconds, maybe nxboot should only blank the display.
WDYT?
But since using your fbcon with the NSH terminal o
the NuttX Logo in similar way was Linux users do.
BR,
Alan
On Thu, Mar 27, 2025 at 9:38 AM Tim Hardisty
wrote:
I am still unsure about where a framebuffer splashscreen best "lives".
* If a framebuffer device is used for a given board, this would be
registered in a boar
d some time ago, I'm
not sure how complex it will be to reintroduce them.
BR,
Alan
On Mon, Mar 24, 2025 at 4:12 PM Tim Hardisty
wrote:
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 bene
ystem configuration
>> #
>> CONFIG_DISABLE_MOUNTPOINT=y
>>
>> Disabling MOUNTPOINT will disable VFS support, it was necessary to be able
>> to use less than 16KB Flash, but disabling it we lose the option to create
>> device files at /dev.
>>
>> Sin
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
could work for your purpose, but it will increase the
final firmware size (in case of NXBoot usage).
BR,
Alan
On Wed, Mar 12, 2025 at 7:12 AM Tim Hardisty
wrote:
Thanks Greg. I have allowed myself to get carried away I think.
* I wanted stdout and stderr to render on a FB to display basi
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
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
rd to
let user know a secret key the decript the disk.
Alternatively if you want to print images in the screen you can use
something like fbprint ( https://github.com/Weinsen/fbprint ).
BR,
Alan
On Saturday, February 15, 2025, Tim Hardisty
wrote:
What is efficient solution to just do text t
u want to print images in the screen you can use
something like fbprint ( https://github.com/Weinsen/fbprint ).
BR,
Alan
On Saturday, February 15, 2025, Tim Hardisty
wrote:
What is efficient solution to just do text though?
On 15 Feb 2025, at 13:42, Alan C. Assis wrote:
Hi Tim,
You can
u just want to write
> in the framebuffer, you can convert image to display directly in the
> /dev/fb0
>
> BR,
>
> Alan
>
>> On Sat, Feb 15, 2025 at 7:45 AM Tim Hardisty
>> wrote:
>>
>> Hello NuttX Colleagues!
>>
>> During MCUboot I want to
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; BR,
>
> Alan
>
>> On Thu, Feb 13, 2025 at 7:48 AM Tim Hardisty
>> wrote:
>>
>> Bu all sensors should have character drivers though, not just uORB? I
>> have only briefly searched about uORB but it's a messaging system not a
>> driver as su
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/
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. This contains the address in RAM
that the entire image in the flash slot, minus the 32 byte header
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
ay be a bit non-intuitive, but as soon as
you complete it things will start moving smoother.
Hope that brings some light to your use case.
BR,
Petro
пт, 31 січ. 2025 р. о 18:30 Tim Hardisty пише:
[resend as I managed to mangle the Subject!]
Hi Petro - thanks for replying. Here're the
M config, does it have internal flash or external,
where the program is executed from, etc. maybe I will be able to help you.
Br,
Petro
On Wed, Jan 29, 2025, 11:59 AM Tim Hardisty wrote:
Thanks for taking the time to reply, Lwazi.
As best as I know, the Nuttx build (with my, or any app, set as
al,
where the program is executed from, etc. maybe I will be able to help you.
Br,
Petro
On Wed, Jan 29, 2025, 11:59 AM Tim Hardisty wrote:
Thanks for taking the time to reply, Lwazi.
As best as I know, the Nuttx build (with my, or any app, set as the
start app) is running from RAM. Uboot certa
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
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
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 depre
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 worki
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
ro.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
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 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 i
+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!
ubsystem:
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
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
opic. 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 bu
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 st
> 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,
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
>>
1 - 100 of 259 matches
Mail list logo
