Re: UART based peripheral driver

Well, to contradict myself, there is a driver that works in the way you were thinking: nuttx/drivers/wireless/bluetooth/bt_uart.c  This is a bluetooth driver built on an RS-232 bluetooth module and uses the lower half UART interface directly. But this driver was much despised because of this (

Re: Problems with STM32F7 and STM32H7 boards

Thanks Michal changing the arm-gcc version can probably change the size of the generated code. I'll check it Bye Roberto On 10/1/24 10:36 AM, michal.lyszc...@bofc.pl wrote: On 2024-10-01 09:38:56, Roberto Bucher wrote: By launching "main" I have this error: nsh> main ERROR: Failed to wd

Re: UART based peripheral driver

Perfect, thank you so much for the pointers! When there is a draft ready hopefully we'll be able to get more valuable feedback on the implementation! Our goal is to implement things the NuttX way and be consistent, so we appreciate all the information so we can get it as close to right the first ti

Re: UART based peripheral driver

Thank you for the help everyone! I have some follow-up questions: > You should use the struct file instance to access the driver, not the raw > driver interface. Greg, can you clarify what you mean? My understanding is that it would be preferred that I use `file_open()` to get the struct file

Re: Problems with STM32F7 and STM32H7 boards

You're right, if the problem is only related to stack.I checked some weeks ago the same blockdiagram with the previous version of arm-none-eabi-gcc without problems, including network, and the officicial last RC1 NuttX version. I'll retry this version with the new compiler and see what happens.

Re: Problems with STM32F7 and STM32H7 boards

On 2024-10-01 10:52:18, Roberto Bucher wrote: > Thanks Michal > > changing the arm-gcc version can probably change the size of the generated > code. No, stack size is per thread, and has nothing to do with code size. Stack size refers to automatic storage variables like int main(void) { int

Re: GSoC Final Report on mnemofs

Hello, The following NAND flash chips have been ordered today: MT29F2G01ABAGDWB-IT:G MT29F1G01ABAFDWB-IT:F MT29F4G01ABAFDWB-IT:F I have selected these references because, they are bg and potentially useful, and the 2Gbit chip seems to have a different memory layout. I will not be able t

Re: Problems with STM32F7 and STM32H7 boards

On Tue, Oct 1, 2024 at 1:09 PM Tomek CEDRO wrote: > (..) > RC is the Release Candidate and is not the official release.. and yes > WE ARE MISSING THE nuttx-12.6.0 RELEASE TAG ON GITHUB!! :-) Okay the nuttx-12.6.0 tag is now present, documentation updated, but it is equivalent to 12.6.0-RC1 from w

Re: Questions about STM32 support/programming

Thank you everyone for the responses, lots to consider. I'll have some of our members look into reading the STM32 datasheets to check for information about whether or not the particular chip(s) we're interested will ship with DFU support or not. We're trying to make the use of this board as easy

Problems with STM32F7 and STM32H7 boards

Hi I have some troubles with the 3 boards, with pysimCoder: GCC version: arm-none-eabi-gcc version 13.3.1 under Debian trixie *NUCLEO-F746ZG*: generated code works, but network is not reachable (TCP and UDP). "ping" works, but sending data via LAN not! *NUCLEO-H745ZI-Q:* *Code generation:*

Re: Problems with STM32F7 and STM32H7 boards

On Tue, Oct 1, 2024 at 11:57 AM roberto.bucher.2812 wrote: > You're right, if the problem is only related to stack.I checked some weeks > ago the same blockdiagram with the previous version of arm-none-eabi-gcc > without problems, including network, and the officicial last RC1 NuttX > version.

Re: UART based peripheral driver

The driver structure is contained in the struct file (filep->struct file->inode->u.file_operations.  The operation of many file systems, drivers, etc.  depend on the additional in these other structures. The driver interface is given by file_operations.  Notice that each method requires an ins

Re: GSoC Final Report on mnemofs

On Tue, Oct 1, 2024 at 10:28 AM Sebastien Lorquet wrote: > (..) > I will not be able to write new code. Specifically if it's now AI reviewed. Sebastien the code is not reviewed by the AI it only provides initial feedback on the PR and commit descriptions something we are constantly repeating and

Re: Problems with STM32F7 and STM32H7 boards

On 2024-10-01 09:38:56, Roberto Bucher wrote: > By launching "main" I have this error: > > nsh> main > ERROR: Failed to wdump_assert_info: Current Version: NuttX 12.6.0-RC1 > d4968905c5 Oct  1 2024 08:53:59 arm > dump_assert_info: Assertion failed panic: at file: :0 task: 0x8000361 > up_dump_regis