Re: Help on understanding Nuttx
There is an ongoing series regarding porting to the STM32F401RC on YouTube, maybe that can help: https://www.youtube.com/@nuttxchannel/streams Regards, Mark — Mark Stevens mark.stev...@wildernesslabs.co > On 22 May 2024, at 11:04, Janardhan Silwal > wrote: > > Hi, > > So I need to understand the basics of STM32 operations using NuttX, and the > addition of perpherals. > So far, feeling around the dark and copy-pasting, I have been able to get my > board running STM32F427AIH6, get booted up, and have also been able to write > out some custom applications, Hello World and the sorts. > I have also tried to operate a SPI-based Magnetometer, LIS3MDL using the > inbuilt driver, which has been somewhat successful but not to the extent I > would have liked it to be. > So, now copy-pasting and doing some changes I believe I can get SPI devices > working, but now I am stuck with internal peripherals, ADC in this case, and > also timers, interrupts, and other whole lot. > > I like NuttX. And I know this RTOS is the one to run my board. But so far > there hasn't been much progress in development, and the thing is I am stuck > getting basic operations running, as I want it to. Even looking at the > examples, it is difficult for me to get an exact picture of how things are > interconnected, how configurations are set, and all. > > That being the case, I would like to ask, what is the best method to get all > the basics down, for someone just starting NuttX, or even RTOS'es, easily? > Some kind of detailed documentation that explains what is happening and how > it happening would be a lifesaver, considering the reader knows the chip, but > nothing, nothing-at-all about the RTOS. Is there something like that > somewhere? > > Thank you. > > Janardhan
Re: Missing bytes on serial port
Greg,
Thanks for the advice, I’ll have a look at use file_open etc.
Regards,
Mark
—
Mark Stevens
mark.stev...@wildernesslabs.co
> On 10 May 2024, at 15:55, Gregory Nutt wrote:
>
> On 5/9/2024 11:02 PM, Mark Stevens wrote:
>>> Hmmm... the UART device will closed when the kernel thread is killed,
>>> right? When the device is closed, it is also flushed I believe. If those
>>> two things are true, then data loss would be expected, right?
>> Yes, the UART is closed just before we perform a thread_delete(0).
> That would be when the all data is flushed from FIFOs and input buffers and
> lost.
>> Data loss is accounted for in the protocol. We send a known packet to the
>> ESP and it then responds to the request. This happens several times (we try
>> 40 times). The logic analyser is showing the traffic between the chips and
>> I have manually checked the packets and the data looks good.
> I don't know the details of these UART drivers, but typically when the driver
> is closed all data is lost and the receivers are disabled so that nothing
> more can be received.
>>> Note that for a UART console, stdin is inherited so that the UART is not
>>> closed when the kernel thread exits.
>> The UART is opened at the start of the thread not prior to the thread being
>> started.
>>
>> We are doing the following:
>>
>> int start_uart_thread()
>> {
>> // Configure the thread properties
>> handle = kthread_create(… monitor_thread …);
>> }
>>
>> void monitor_thread(…)
>> {
>> int uart = open(….);
>>
>> // Setup signalling.
>>
>> while (!shutting_down) { read and process data }
>> close(uart);
>>kthread_delete(0);
>> }
>
> Hmmm... I see that you are using file descriptors within the OS. That is not
> normally done because it is unsafe; it depends on the context in which the
> code using the file descriptor operates. If you code operates on a file
> descriptor within the OS it could clobber the file descriptors of a different
> task/kthread. These standard I/O function should be used only by user space
> code and never within the OS.
>
> That is one thing that should be fixed: Use file_open(), file_read() and
> file_close() instead. This will correctly avoid use of file descriptors.
>
>>
>> In this case is does the inheritance go both ways? As in if I open the
>> UART in the kthread does the parent thread keep it open?
>
> You are using a kernel thread above. Kernel threads and user pthreads work
> differently:
>
> * The kthreads work just like tasks and the parent kernel thread knows
> nothing about the drivers opened by the child kernel thread. The
> opened driver will persist until it is explicitly closed (as above)
> or until the kthread exists. It will not be kept open for use by
> the parent.
> * With user pthreads, all file descriptors are shared. If a pthread
> exits, any file descriptors opened by the pthread persist until they
> are explicitly closed or until the task main thread exits.
>
> The driver may not be closed when the main thread exits either. Reference
> counting is used. When the driver is closed the reference count is
> decremented. The UART will not actually be disabled until the reference
> count finally decrements to zero.
>
> So if you want the open file to persist for the parent of the kthread you
> would need to (1) open the driver on the parent (reference count == 1). (2)
> Start the child kthread, and (3) open the driver on the child kthread
> (reference count == 2). When the child kthread exits (reference count == 1)
>
> This happens normally through file descriptor inheritance in user tasks, but
> file descriptors are not used within the kernel.
Re: Missing bytes on serial port
> Hmmm... the UART device will closed when the kernel thread is killed, right?
> When the device is closed, it is also flushed I believe. If those two
> things are true, then data loss would be expected, right?
Yes, the UART is closed just before we perform a thread_delete(0).
Data loss is accounted for in the protocol. We send a known packet to the ESP
and it then responds to the request. This happens several times (we try 40
times). The logic analyser is showing the traffic between the chips and I have
manually checked the packets and the data looks good.
> Note that for a UART console, stdin is inherited so that the UART is not
> closed when the kernel thread exits.
The UART is opened at the start of the thread not prior to the thread being
started.
We are doing the following:
int start_uart_thread()
{
// Configure the thread properties
handle = kthread_create(… monitor_thread …);
}
void monitor_thread(…)
{
int uart = open(….);
// Setup signalling.
while (!shutting_down) { read and process data }
close(uart);
kthread_delete(0);
}
In this case is does the inheritance go both ways? As in if I open the UART
in the kthread does the parent thread keep it open?
Regards,
Mark
—
Mark Stevens
mark.stev...@wildernesslabs.co
> On 10 May 2024, at 05:38, Gregory Nutt wrote:
>
>
> On 5/9/2024 10:23 PM, Mark Stevens wrote:
>> The issue arises if I try to kill the kernel thread reading from the UART
>> and then try to start a user thread reading from the same UART.
>
> Hmmm... the UART device will closed when the kernel thread is killed, right?
> When the device is closed, it is also flushed I believe. If those two
> things are true, then data loss would be expected, right?
>
> Note that for a UART console, stdin is inherited so that the UART is not
> closed when the kernel thread exits.
>
>> Also, the issue can be reproduced within the first 15 seconds after board
>> reset so I am confident that the issue will not be related to long term
>> drift.
>
> From what I have read, any kind of slow drift is not possible due to the
> start and stop bits. Those transitions are necessary to synchronize on each
> byte. I also read that in the event of bad start bit, several bytes could be
> lost while the UART recovers.
>
> But that does not seem to be these issue here.
Re: Missing bytes on serial port
Greg, Both pieces of code work fine if they are executed on their own so I am confident that UART connection is good. The issue arises if I try to kill the kernel thread reading from the UART and then try to start a user thread reading from the same UART. Also, the issue can be reproduced within the first 15 seconds after board reset so I am confident that the issue will not be related to long term drift. Regards, Mark — Mark Stevens mark.stev...@wildernesslabs.co > On 9 May 2024, at 22:51, Gregory Nutt wrote: > > This problem is reported for a lot a platforms and seems to be a hardware > issue, usually associated with FIFOs and buffers. > > If you rule everything else out, then you can also consider some of the more > unusual causes. On some hardware, small differences in BAUD can result in > the kind of data loss you describe. Other hardware is more resilient. > > Since you are using two different MCUs, there is a high probability that the > BAUD rates are not exactly identical and you may be relying on marginally > sized start and stop bits to keep in synchronization. The half bit times > typically used in the start and stop bits normally account for this. > > Here is a long discussion of some hardware behaviors: > https://www.eevblog.com/forum/beginners/uart-question/ Searching for "uart > data loss due to small baud differences" finds several others. > > On 5/9/2024 3:20 PM, Mark Stevens wrote: >> I’m not writing to the UART - I am reading. >> >> Regards, >> Mark >> --- >> Mark Stevens >> Blog: blog.mark-stevens.co.uk >> >> >>> On 9 May 2024, at 17:40, Mark Stevens >>> wrote: >>> >>> This is a direct connection between the two chips on a PCB. >>> >>> Regards, >>> Mark >>> — >>> Mark Stevens >>> mark.stev...@wildernesslabs.co >>> >>> >>> >>> >>> >>> >>>> On 9 May 2024, at 17:38, Bill Rees wrote: >>>> >>>> >>>> I've seen this problem before which revolved around flow control; >>>> essentially soft versus hard flow control (xmit off/ xmit on) >>>> >>>> Are you using a null modem cable? If not that may give you the accuracy >>>> you're looking for, else hardware flow control is the only other >>>> possibility if it is flow control. >>>> >>>> Bill >>>> >>>> On 5/9/2024 9:24 AM, Tomek CEDRO wrote: >>>>> On Thu, May 9, 2024 at 6:15 PM Mark Stevens >>>>> wrote: >>>>>> Yes, I am sure both side are configured correctly. >>>>>> If I run the kernel code only then all works as expected. >>>>>> If I run user space code alone all works as expected. >>>>>> The problems happen when I transition from kernel use of the UART to >>>>>> user space use of the UART. >>>>>> I have also connected a logic analyser to the system and all looks good. >>>>>> Also, my current problem is NuttX reading data not sending it. Sending >>>>>> may also be a problem but I have not got that far at the moment. >>>>> Which UART do you use? What happens when you use different UART? Are >>>>> you sure it does not interfere with console? >>>>> >>>>> -- >>>>> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >>
Re: Missing bytes on serial port
I’m not writing to the UART - I am reading. Regards, Mark --- Mark Stevens Blog: blog.mark-stevens.co.uk > On 9 May 2024, at 17:40, Mark Stevens > wrote: > > This is a direct connection between the two chips on a PCB. > > Regards, > Mark > — > Mark Stevens > mark.stev...@wildernesslabs.co > > > > > > >> On 9 May 2024, at 17:38, Bill Rees wrote: >> >> >> I've seen this problem before which revolved around flow control; >> essentially soft versus hard flow control (xmit off/ xmit on) >> >> Are you using a null modem cable? If not that may give you the accuracy >> you're looking for, else hardware flow control is the only other possibility >> if it is flow control. >> >> Bill >> >> On 5/9/2024 9:24 AM, Tomek CEDRO wrote: >>> On Thu, May 9, 2024 at 6:15 PM Mark Stevens >>> wrote: >>>> Yes, I am sure both side are configured correctly. >>>> If I run the kernel code only then all works as expected. >>>> If I run user space code alone all works as expected. >>>> The problems happen when I transition from kernel use of the UART to user >>>> space use of the UART. >>>> I have also connected a logic analyser to the system and all looks good. >>>> Also, my current problem is NuttX reading data not sending it. Sending >>>> may also be a problem but I have not got that far at the moment. >>> Which UART do you use? What happens when you use different UART? Are >>> you sure it does not interfere with console? >>> >>> -- >>> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >> >
Re: Missing bytes on serial port
This is a direct connection between the two chips on a PCB. Regards, Mark — Mark Stevens mark.stev...@wildernesslabs.co > On 9 May 2024, at 17:38, Bill Rees wrote: > > > I've seen this problem before which revolved around flow control; essentially > soft versus hard flow control (xmit off/ xmit on) > > Are you using a null modem cable? If not that may give you the accuracy > you're looking for, else hardware flow control is the only other possibility > if it is flow control. > > Bill > > On 5/9/2024 9:24 AM, Tomek CEDRO wrote: >> On Thu, May 9, 2024 at 6:15 PM Mark Stevens >> wrote: >>> Yes, I am sure both side are configured correctly. >>> If I run the kernel code only then all works as expected. >>> If I run user space code alone all works as expected. >>> The problems happen when I transition from kernel use of the UART to user >>> space use of the UART. >>> I have also connected a logic analyser to the system and all looks good. >>> Also, my current problem is NuttX reading data not sending it. Sending may >>> also be a problem but I have not got that far at the moment. >> Which UART do you use? What happens when you use different UART? Are >> you sure it does not interfere with console? >> >> -- >> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >
Re: Missing bytes on serial port
I can’t use a different UART, this is a direct connection between the two chips on the PCB. Regards, Mark — Mark Stevens mark.stev...@wildernesslabs.co > On 9 May 2024, at 17:24, Tomek CEDRO wrote: > > On Thu, May 9, 2024 at 6:15 PM Mark Stevens > wrote: >> Yes, I am sure both side are configured correctly. >> If I run the kernel code only then all works as expected. >> If I run user space code alone all works as expected. >> The problems happen when I transition from kernel use of the UART to user >> space use of the UART. >> I have also connected a logic analyser to the system and all looks good. >> Also, my current problem is NuttX reading data not sending it. Sending may >> also be a problem but I have not got that far at the moment. > > Which UART do you use? What happens when you use different UART? Are > you sure it does not interfere with console? > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: Missing bytes on serial port
One extra piece of information that has occurred to me, I am using a `SIGINT` kill signal to tell the kernel thread that it should close the connection. Regards, Mark --- Mark Stevens Blog: blog.mark-stevens.co.uk > On 9 May 2024, at 17:11, Tomek CEDRO wrote: > > On Thu, May 9, 2024 at 5:40 PM Mark Stevens > wrote: >> For example, I am seeing on the logic analyser the ESP sending the >> following hex bytes: >> c0 01 08 04 00 07 12 20 55 00 00 00 00 c0 >> NuttX is seeing: >> c0 01 04 20 55 00 00 c0 > > Can you add small delay between each byte transmitted? > > Can you divide transmitted data into chunks with a small delay between them? > > By adjusting delay between bytes and adjusting chunk size and delay > between chunks you may identify timing and/or configuration problems. > > Are you sure port have exactly the same configuration on both sides > (i.e. 115200-8-N-1)? > > Do you use cable for transmission? If so wow long is the cable between > devices? > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: Missing bytes on serial port
Yes, I am sure both side are configured correctly. If I run the kernel code only then all works as expected. If I run user space code alone all works as expected. The problems happen when I transition from kernel use of the UART to user space use of the UART. I have also connected a logic analyser to the system and all looks good. Also, my current problem is NuttX reading data not sending it. Sending may also be a problem but I have not got that far at the moment. Regards, Mark — Mark Stevens mark.stev...@wildernesslabs.co > On 9 May 2024, at 17:11, Tomek CEDRO wrote: > > On Thu, May 9, 2024 at 5:40 PM Mark Stevens > wrote: >> For example, I am seeing on the logic analyser the ESP sending the >> following hex bytes: >> c0 01 08 04 00 07 12 20 55 00 00 00 00 c0 >> NuttX is seeing: >> c0 01 04 20 55 00 00 c0 > > Can you add small delay between each byte transmitted? > > Can you divide transmitted data into chunks with a small delay between them? > > By adjusting delay between bytes and adjusting chunk size and delay > between chunks you may identify timing and/or configuration problems. > > Are you sure port have exactly the same configuration on both sides > (i.e. 115200-8-N-1)? > > Do you use cable for transmission? If so wow long is the cable between > devices? > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: Missing bytes on serial port
It is random. So in a 50-ish byte packet I will see sequences of missing bytes which can be 1, 2 or event 3 bytes long missing. For example, I am seeing on the logic analyser the ESP sending the following hex bytes: c0 01 08 04 00 07 12 20 55 00 00 00 00 c0 NuttX is seeing: c0 01 04 20 55 00 00 c0 Regards, Mark — Mark Stevens mark.stev...@wildernesslabs.co > On 9 May 2024, at 14:56, Nathan Hartman wrote: > > On Thu, May 9, 2024 at 3:31 AM Mark Stevens > wrote: > >> So we have a two chip board: >> >> * STM32 running NuttX (v7.5 I believe) >> * ESP32 acting as a coprocessor running custom firmware >> >> The STM32 runs the show and the ESP32 provides services to the STM32 code. >> >> In normal run mode, NuttX has a kernel thread that reads data from the >> ESP32 over UART (/dev/ttyS2) and then processes the data. This is working >> fine as is. >> >> The UART is configured to use a 512 byte buffer. >> >> Every now and then we want to upload new firmware to the ESP32. This is >> done by a user mode thread and it goes through the following steps: >> >> * Signals to the kernel thread that it should close the UART and exit. >> * Opens the serial port >> * Starts the programming sequence >> >> If we try to do this then the user mode thread misses bytes in the byte >> stream. >> >> Kernel mode thread only: >> When the system starts then this thread works fine, no bytes are lost. >> >> User mode thread only: >> If we do not start the kernel mode thread then the programming works fine, >> no bytes are lost. >> >> Both threads: >> Starting the kernel works fine, we do not miss any bytes. The kernel >> thread can be stopped, the UART is closed correctly. >> >> The user thread can open the serial port correctly after the kernel thread >> has stopped but now it misses bytes. >> >> So we know the individual threads work as expected when used on their own >> but not together. >> >> How anyone seen this or have any advice on how we can resolve the issue? >> >> Regards, >> Mark >> __ >> mark.stev...@wildernesslabs.co >> >> >> >> > > Which bytes are missing? Are they the ones at the beginning of the message, > or the end? > > Nathan
Missing bytes on serial port
So we have a two chip board: * STM32 running NuttX (v7.5 I believe) * ESP32 acting as a coprocessor running custom firmware The STM32 runs the show and the ESP32 provides services to the STM32 code. In normal run mode, NuttX has a kernel thread that reads data from the ESP32 over UART (/dev/ttyS2) and then processes the data. This is working fine as is. The UART is configured to use a 512 byte buffer. Every now and then we want to upload new firmware to the ESP32. This is done by a user mode thread and it goes through the following steps: * Signals to the kernel thread that it should close the UART and exit. * Opens the serial port * Starts the programming sequence If we try to do this then the user mode thread misses bytes in the byte stream. Kernel mode thread only: When the system starts then this thread works fine, no bytes are lost. User mode thread only: If we do not start the kernel mode thread then the programming works fine, no bytes are lost. Both threads: Starting the kernel works fine, we do not miss any bytes. The kernel thread can be stopped, the UART is closed correctly. The user thread can open the serial port correctly after the kernel thread has stopped but now it misses bytes. So we know the individual threads work as expected when used on their own but not together. How anyone seen this or have any advice on how we can resolve the issue? Regards, Mark __ mark.stev...@wildernesslabs.co
Re: Trouble adding a new board
Robert, There was a YouTube video posted a few weeks ago and the 2+ hour session which covered porting to a new STM32F4 board. Maybe that can help. https://www.youtube.com/watch?v=TeBkVJLATcw=7s Regards, Mark __ mark.stev...@wildernesslabs.co > On 6 Nov 2023, at 00:18, Robert Middleton wrote: > > I'm working on adding NuttX support to the SparkFun STM32 board, but > I'm having trouble adding the support to an in-tree build. > Specifically I have done the following: > > * Copied the OmnibusF4 directory to a new directory to use as a base > * Updated the defconfig to use STM32_THING_PLUS instead of OMNIBUSF4 > * Updated the boards/Kconfig file to add in the new baord > > The config does show up when I check with the tools/configure.sh script: > robert@debian:~/nuttx$ ./tools/configure.sh -L | grep thing-plus > stm32-thing-plus:nsh > But once I try to use it, menuconfig doesn't work because the .config > file that is generated thinks that it's a custom board, even though > the ARCH_BOARD and ARCH_BOARD_STM32_THING_PLUS are set in the > defconfig: > > robert@debian:~/nuttx$ grep ARCH_BOARD .config > # CONFIG_ARCH_BOARD_DEBUG_H is not set > # CONFIG_ARCH_BOARD_STM32_CUSTOM_CLOCKCONFIG is not set > # CONFIG_ARCH_BOARD_OLIMEX_STM32H405 is not set > # CONFIG_ARCH_BOARD_OMNIBUSF4 is not set > CONFIG_ARCH_BOARD_CUSTOM=y > CONFIG_ARCH_BOARD_CUSTOM_NAME="" > CONFIG_ARCH_BOARD_CUSTOM_DIR="" > CONFIG_ARCH_BOARD_CUSTOM_DIR_RELPATH=y > # CONFIG_ARCH_BOARD_COMMON is not set > > So clearly I've missed something here, but what? I've done everything > that should be done according to the porting guide on > Confluence(cwiki), but I'm not sure if that's up to date. What might > I be missing? > > -Robert Middleton
Re: gcc-arm-none-eabi on M1 MacOs
I have recently setup a Mac M1 for STM32 development and I installed the arm-gcc-bin@10 package using brew. The only thing I have found does not work is arm-none-eabi-gdb-py as it is looking for Python 2.7 with a fixed path and it does not exist on the system. I have tried peen but this offers Python 2.7 up as a different location. Regards, Mark _ Blog: blog.thepcsite.co.uk Twitter: @nevynuk > On 18 Oct 2023, at 09:22, Christian Catchpole wrote: > > Thanks Petro! > > I took this as an opportunity to set up NuttX on my Air which doesn't have > anything NuttX related on it, > > I was able to get it working with *pip3*. Im not sure if "*ensurepip*" was > required, I tried that when regular *pip* failed, then I realised it was > going to be *pip3* > > I used: > > > > > *brew install pythonpython3 -m ensurepip --upgradepip3 install kconfiglib* > But I'll see if I can reconfirm the exact requirements and create a PR. > > > On Wed, 18 Oct 2023 at 16:03, Petro Karashchenko < > petro.karashche...@gmail.com> wrote: > >> I think the latest code rely on kconfiglib, so theoretically things should >> work without kconfig-frontends. But I haven't tested case when >> kconfig-frontends is not installed (current I have installed both). >> >> Best regards, >> Petro >> >> On Wed, Oct 18, 2023, 1:35 AM Christian Catchpole >> >> wrote: >> >>> Thanks I'll try *--install-prefix* when setting up my Air and probably >>> raise a PR for that. >>> >>> I'll also look into better options for *kconfig-frontends*. >>> >>> As for Blender, I had been using Autodesk for modeling / 3D printing and >>> then for some reason, I can't even recall, I downloaded Blender, and >> then I >>> started going down the rabbit hole of 3D rendering. I'm not into games, >> but >>> I am interested in short films and cinema,. Last week I picked up a Dell >>> Visor and was able to get a Raspberry Pi to generate the required >> 2880x1440 >>> resolution and played with some stereo renders. Blender has some VR >> support >>> but only on Windows. Iv mainly learned Blender by adding my own robot >>> designs to the example scenes and experimenting with python scripting. If >>> the robot's never exist in reality, they can at least exist in my mind.. >>> >>> https://catchpole.net/img/catchpole-wall1200.jpg >>> >>> CC >>> >>> On Wed, 18 Oct 2023 at 08:05, Tomek CEDRO wrote: >>> On Tue, Oct 17, 2023 at 1:18 AM Christian Catchpole wrote: > Nice, I went the full Studio Ultra, mainly because Im doing a lot of stuff > in Blender at the moment. I loved Blender until they removed BGE (Blender Game Engine) and changed that program into kind of 3D Photoshop. But I still use it sometimes. Do you use Blender with external game engine like Godot or Armory? With BGE it was possible to use Python exchanging data online with real world hardware (or offline data acquired by hardware) in order to control 3D environment. I did a simple flight simulator that way using custom aerodynamics model. Do you know is again possible without BGE nowadays? > I also noticed that the KConfig build required a *sudo* on *make >>> install *to > be able to write to */usr/local/bin/kconfig *- im not sure if there's >>> an > alternative I cannot see kconfig-frontends in the brew search. In a perfect world we would want to have it ported. I did a port for FreeBSD but never did a HomeBrew port. Have you ever tried that? Maybe we should ask on their mailing lists? Using ~/.local/ --install-prefix and then adding ~/.local/bin to the PATH in ~/.profile seems more elegant solution than system wide modification :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >>> >>
GPIO and interrupts
I am trying to figure out GPIO and interrupts. So the situation is I have four switches connected to GPIOs on my board. My ideal scenario is to attach a different interrupt to each switch and have that fired when the appropriate button is pressed. So I have spent some time looking at the gpis_main.c file and I have changed the code that sets the event to: notify.sigev_notify = SIGEV_THREAD; notify.sigev_notify_function = sigev_notify_function; And I am getting the interrupt for one button as expected. Too many interrupts in fact - I have debounced the input in hardware using a 555 so the signal should be good. I am struggling to work out how to do this for the remaining buttons without spinning up multiple threads all effectively running the same code but with different devices. I came across the buttons example but this appears to be disabled for this board. Any advice would be gratefully received. Regards, Mark _ Blog: blog.thepcsite.co.uk Twitter: @nevynuk
Re: RP2040 Pico SDK
So is there a simple way of attaching and ISR to a GPIO from user code? I can see how to do it in rp2040_gpio.c in the board files but I’m hoping not to have to change the board files. Regards, Mark _ Blog: blog.thepcsite.co.uk Twitter: @nevynuk > On 12 Aug 2023, at 20:08, Brennan Ashton wrote: > > I would not recommend doing that. You _could_ but it will break for non > flat builds and you are explicitly violating the the OS application > interface boundary. You may also break assumptions of the OS and make it > unstable by changing important registers in interrupt controller. > > So nothing is stopping you, but you should also not expect the OS to > function correctly. > > --Brennan > > On Sat, Aug 12, 2023, 11:54 AM Mark Stevens wrote: > >> Is there anyway of using the Pico SDK from within NuttX? >> >> What I am trying to do is attach a generic ISR to some GPIO pins. I’m not >> a great fan of having to modify the OS source in order to set up simple >> things like ISRs to handle button presses. I’d like to be able to do this >> from the user application rather than the board files which from what I >> have read seems to be the way to do it. >> >> My requirement is: >> >> Configure a GPIO to be input, interrupt driven and pull ups enabled >> Attach and interrupt to the GPIO (this could be one of all input GPIOs if >> I get a parameter telling me which button or one per GPIO) >> Driven from the user application >> >> From what I have read in the source (and I may be wrong) I seem to have to >> modify the board files and use a signal handler for the interrupts. >> >> I’d rather not modify the board files. >> >> Now I know you can achieve what I want in a few calls to the Pico SDK and >> I was wondering if calling the SDK is possible. >> >> Has anyone doe this? >> >> Alternatively, has anyone configured NuttX to do this from user space? >> >> Regards, >> Mark >> _ >> Blog: blog.thepcsite.co.uk >> Twitter: @nevynuk >> >> >> >> >> >>
RP2040 Pico SDK
Is there anyway of using the Pico SDK from within NuttX? What I am trying to do is attach a generic ISR to some GPIO pins. I’m not a great fan of having to modify the OS source in order to set up simple things like ISRs to handle button presses. I’d like to be able to do this from the user application rather than the board files which from what I have read seems to be the way to do it. My requirement is: Configure a GPIO to be input, interrupt driven and pull ups enabled Attach and interrupt to the GPIO (this could be one of all input GPIOs if I get a parameter telling me which button or one per GPIO) Driven from the user application From what I have read in the source (and I may be wrong) I seem to have to modify the board files and use a signal handler for the interrupts. I’d rather not modify the board files. Now I know you can achieve what I want in a few calls to the Pico SDK and I was wondering if calling the SDK is possible. Has anyone doe this? Alternatively, has anyone configured NuttX to do this from user space? Regards, Mark _ Blog: blog.thepcsite.co.uk Twitter: @nevynuk
Re: Serial LCD example
Yes, that is the code I’m referring to.
I’m also going to be looking at adding one or two more PCF GPIO expanders to
the system, not LCD, but they will certainly need to live with the LCD backpack.
I’ll have a look at a PR.
Regards,
Mark
_
Blog: blog.thepcsite.co.uk
Twitter: @nevynuk
> On 23 Jul 2023, at 20:40, Gregory Nutt wrote:
>
>
>> Ideally, I’d have configured this from the user application. As they are
>> embedded within the board startup I’d have thought they would have been
>> configurable through kconfig.
>
> I assume you are referring to the following in
> boards/arm/rp2040/common/src/rp2040_common_bringup.c:
>
> #ifdef CONFIG_LCD_BACKPACK
> /* slcd:0, i2c:0, rows=2, cols=16 */
>
> ret = board_lcd_backpack_init(0, 0, 2, 16);
> if (ret < 0)
>{
> syslog(LOG_ERR, "Failed to initialize PCF8574 LCD, error
> %d\n", ret);
> return ret;
> return ret;
>}
> #endif
>
> You would want configurable parameters if you:
>
> 1. Had more than one backpack,
> 2. Had a backpack connected to a different I2C, or
> 3. Had a backpack with a different LCD size.
>
> Since the backpack is an add-on and not a part of the base pico-w board, I
> would think those should be configurable... or at least well-documented. You
> should submit a PR. As long as the defaults are {0,0,2,16} then no existing
> configurations would be impacted.
Re: Serial LCD example
This is not so much about a board configuration, it is about a driver
configuration.
So the PCF driver is just a GPIO expander which in this case is driving a LCD.
My question really is about the integration of very specific configuration
information into the OS.
From a high level view, the driver allows communication with the hardware and
if there are variations then the driver should be configurable from the user
application. In this case there are four configurable items:
- I2C interface being used
- Address of the I2C peripheral
- Number of columns
- Number of rows
None of these are configurable from the user application and they are not
configurable from kconfig, they are all hardwired.
Ideally, I’d have configured this from the user application. As they are
embedded within the board startup I’d have thought they would have been
configurable through kconfig.
Regards,
Mark
_
Blog: blog.thepcsite.co.uk
Twitter: @nevynuk
> On 23 Jul 2023, at 20:00, Alan C. Assis wrote:
>
> Hi Mark,
>
> In fact some examples are ("incorrectly") hard-code to some I2C Bus or
> uses #ifdef to compile only if that I2C Bus is enabled in the
> menuconfig.
>
> There are pros and cons of using this approach:
>
> PROS:
>
> - 'Guarantee' that such config works (dev tested it);
> - Developer doesn't need to test all different setup combinations.
>
> CONS:
>
> - User will lost much time figuring out which configuration to use
> (case there is not Documentation in the README.txt explaining about
> how to use it)
>
> - Some #ifdefs inside board are very dangerous to end user, because it
> is silent, users don't know that content of C file wasn't compiled.
>
> A better approach could be creating some device configuration inside
> boards/xxx/xxx/xxx/Kconfig to let user to define what bus number to
> use.
>
> These are things that we need to improve to make NuttX more user
> friendly. But, of course, it could bring more challenges as well, case
> a board doesn't have support to some I2C or SPI Bus and the user
> enabled it in the menuconfig.
>
> BR,
>
> Alan
>
> On 7/23/23, Mark Stevens wrote:
>> Had some fun and games today working with the SLCD example on the Pico W.
>>
>> It appears that the example has hard wired parameters for
>>
>> I2C bus
>> Number of characters
>> Number of rows
>>
>> Is it supposed to work like this or should these parameters be
>> configurable?
>>
>> Regards,
>> Mark
>> __
>> mark.stev...@wildernesslabs.co
>>
>>
>>
>>
>>
Serial LCD example
Had some fun and games today working with the SLCD example on the Pico W. It appears that the example has hard wired parameters for I2C bus Number of characters Number of rows Is it supposed to work like this or should these parameters be configurable? Regards, Mark __ mark.stev...@wildernesslabs.co
Build error 12.2.0
So had a play with 12.2 and came across an error when building.
make -j V=2 generates the following expanded output for the error:
grep -v "CONFIG_BASE_DEFCONFIG"
"/Users/markstevens/GitHub/NuttXAndPicoW/nuttx/.config" >
"/Users/markstevens/GitHub/NuttXAndPicoW/nuttx/.config.tmp"
echo "Create version.h"
if ! cmp -s "/Users/markstevens/GitHub/NuttXAndPicoW/nuttx/.config.tmp"
"/Users/markstevens/GitHub/NuttXAndPicoW/nuttx/.config.orig" ; then \
sed -i.bak "/CONFIG_BASE_DEFCONFIG/ { /-dirty/! s/\"$/-dirty\"/
}" "/Users/markstevens/GitHub/NuttXAndPicoW/nuttx/.config"; \
else \
sed -i.bak "s/-dirty//g"
"/Users/markstevens/GitHub/NuttXAndPicoW/nuttx/.config"; \
fi
mkdir -p staging
Create version.h
sed: 1: "/CONFIG_BASE_DEFCONFIG/ ...": bad flag in substitute command: '}'
make: *** [include/nuttx/config.h] Error 1
make: *** Waiting for unfinished jobs….
Steps to reproduce:
git checkout releases/12.2
git clean -dfx
git reset —hard
./tools/configure.sh -l raspberrypi-pico-w:nsh
make menuconfig
— Change one setting, I disabled the hello example application and save the
settings.
make -j
OS: MacOS
Note that if you don not make a change using menuconfig then the system builds
OK.
I have tried with the build system configured as Mac and Linux.
Regards,
Mark
__
mark.stev...@wildernesslabs.co
> On 5 Jul 2023, at 08:06, Alin Jerpelea wrote:
>
> The Apache NuttX project team is proud to announce
> Apache NuttX 12.2.0 has been released.
>
> The release artifacts and Release Notes can be found
> at:https://nuttx.apache.org/download/https://nuttx.apache.org/releases/12.2.0/
>
> Thanks,
> Alin Jerpelea
> on behalf of Apache NuttX PPMC
Re: Prebuilt SmartFS file system (Pico)
Responded Sebastien by direct mail. Regards, Mark _ Blog: blog.thepcsite.co.uk Twitter: @nevynuk > On 3 Jul 2023, at 11:09, Sebastien Lorquet wrote: > > Sebastien
Re: Prebuilt SmartFS file system (Pico)
I’m just after a read-only file system. I am basically trying to add some preconfigured files to the system and then give the user the ability to select a file from a list. Long term I’m thinking about uploading of files but not at the moment. Regards, Mark _ Blog: blog.thepcsite.co.uk Twitter: @nevynuk > On 2 Jul 2023, at 20:25, Kenneth Pettit wrote: > > Hi Mark, > > Do you need the FS to be writeable? If not, then a ROMFS is probably a > better choice. If you need a writable FS, then adding a SmartFS to the > compiled image would be difficult ... the SMART and MTD layers need to erase > on page boundries, and I think it would be challenging (though possibly not > impossible) to guarantee the image falls on erase page boundries within the > compiled image. > > But it would be possible to create a pre-build SmartFS image using the FUSE > filesystem under Linux, and then include that image as a binary blob into > your application ... you would just have to ensure all the MTD access and > alignment are taken care of. > > Ken > > On 7/2/23 12:03 PM, Mark Stevens wrote: >> I am looking at adding a small file system to my application and I would >> like to add a number of files to the image as part of the build. >> >> I have configured the build using the raspberrypi-pico-w:nsh-flash >> configuration and I think I have figured out how t add files by editing the >> rp2040_flash_initialize.S file and I have added simple entries to this file. >> >> What I would like to do is add several files, all less than 1K to the file >> system. >> >> I was hoping this could be done outside of the main NuttX tree (prefereably >> in my application directory). >> >> Is this achievable? >> >> Regards, >> Mark >> _ >> Blog: blog.thepcsite.co.uk >> Twitter: @nevynuk >> >> >> >> >> >> >
Prebuilt SmartFS file system (Pico)
I am looking at adding a small file system to my application and I would like to add a number of files to the image as part of the build. I have configured the build using the raspberrypi-pico-w:nsh-flash configuration and I think I have figured out how t add files by editing the rp2040_flash_initialize.S file and I have added simple entries to this file. What I would like to do is add several files, all less than 1K to the file system. I was hoping this could be done outside of the main NuttX tree (prefereably in my application directory). Is this achievable? Regards, Mark _ Blog: blog.thepcsite.co.uk Twitter: @nevynuk
Re: C++ Support
My mistake on the version. The patch builds OK. Back to working on the project later today. Thank you. Regards, Mark _ Blog: blog.thepcsite.co.uk Twitter: @nevynuk > On 25 Jun 2023, at 08:50, Mark Stevens wrote: > > So a little more progress on this one. > > Turning on C++ Exception support for the PicoW:nsh build configuration > generates errors: > > CC: pthread/pthread_testcancel.c machine/arm/gnu_unwind_find_exidx.c:32:8: > error: unknown type name '__EIT_entry' > 32 | static __EIT_entry *__exidx_start_elf; > |^~~ > > Configuration is: > > - C++ enabled > - uCLib++ library > - GNU low level support > - Exceptions enabled. > > Turning exceptions off gives me missing symbols, guess that is going to be a > missing library in the link phase. > > Regards, > Mark > _ > Blog: blog.thepcsite.co.uk > Twitter: @nevynuk > > > > > >> On 24 Jun 2023, at 18:59, Mark Stevens wrote: >> >> I’m currently working on a home project with NuttX and my preferred language >> is really C++ for what I am doing. I can work in C if necessary but I’d >> like to use some C++ features. >> >> So far I have managed to get the framework of what is needed configured and >> the next step is to start some application implementation. So I’m thinking >> core logic unit tested using the simulator and basic C++ application on the >> laptop. >> >> So I have started a fairly basic test scenario and hit a problem with the >> C++ support in NuttX. >> >> My application is going to be using some of the STL, at the moment I’m >> hitting issues with string and vector, two fairly basic and simple classes. >> I’m not getting any application to compile successfully. I have tried: >> >> - Basic C++ support >> - LLVM with both the LLVM and GNU low level libraries >> - uCLib++ with both LLVM and GNU libraries >> >> I have tried this with both the sim:nsh and the raspberrypi-pico-w:nsh >> configurations. >> >> The classes I am using are fairly basic so I could implement them myself, I >> would prefer to use a library version though. >> >> Has anyone managed to use the C++ libraries with NuttX ? >> >> Regards, >> Mark >> _ >> Blog: blog.thepcsite.co.uk >> Twitter: @nevynuk >> >> >> >> >> >
Re: C++ Support
With the patch I am seeing the application exit, it is not excepting my main program loop. Also, version is now listed as 10.4 not 12.1. Re comment about LLVm - I’m just looking for something that works and at the moment uCLib++ and LLVm do not work in 12.1. Regards, Mark _ Blog: blog.thepcsite.co.uk Twitter: @nevynuk > On 25 Jun 2023, at 08:50, Mark Stevens wrote: > > So a little more progress on this one. > > Turning on C++ Exception support for the PicoW:nsh build configuration > generates errors: > > CC: pthread/pthread_testcancel.c machine/arm/gnu_unwind_find_exidx.c:32:8: > error: unknown type name '__EIT_entry' > 32 | static __EIT_entry *__exidx_start_elf; > |^~~ > > Configuration is: > > - C++ enabled > - uCLib++ library > - GNU low level support > - Exceptions enabled. > > Turning exceptions off gives me missing symbols, guess that is going to be a > missing library in the link phase. > > Regards, > Mark > _ > Blog: blog.thepcsite.co.uk > Twitter: @nevynuk > > > > > >> On 24 Jun 2023, at 18:59, Mark Stevens wrote: >> >> I’m currently working on a home project with NuttX and my preferred language >> is really C++ for what I am doing. I can work in C if necessary but I’d >> like to use some C++ features. >> >> So far I have managed to get the framework of what is needed configured and >> the next step is to start some application implementation. So I’m thinking >> core logic unit tested using the simulator and basic C++ application on the >> laptop. >> >> So I have started a fairly basic test scenario and hit a problem with the >> C++ support in NuttX. >> >> My application is going to be using some of the STL, at the moment I’m >> hitting issues with string and vector, two fairly basic and simple classes. >> I’m not getting any application to compile successfully. I have tried: >> >> - Basic C++ support >> - LLVM with both the LLVM and GNU low level libraries >> - uCLib++ with both LLVM and GNU libraries >> >> I have tried this with both the sim:nsh and the raspberrypi-pico-w:nsh >> configurations. >> >> The classes I am using are fairly basic so I could implement them myself, I >> would prefer to use a library version though. >> >> Has anyone managed to use the C++ libraries with NuttX ? >> >> Regards, >> Mark >> _ >> Blog: blog.thepcsite.co.uk >> Twitter: @nevynuk >> >> >> >> >> >
Re: C++ Support
So figured out what the problem was with the patch - it compiles. Just testing execution at the moment. Regards, Mark __ mark.stev...@wildernesslabs.co > On 25 Jun 2023, at 17:53, Mark Stevens wrote: > > So here is what I have run: > > git checkout master > git clean -dfx > git reset —hard > gh pr checkout 9610 > make distclean > ./tools/configure.sh -l raspberrypi-pico-w:nsh > make -j > > So should just be a base configuration and this compiles OK. > > I then reconfigured to system to add > > C++ > uCLib++ > hellowxx > Removed some applications and tests that I’m not interested in and add my > application. > > make -j clean && make -j > > And this results in: > > Create version.h > sed: 1: "/CONFIG_BASE_DEFCONFIG/ ...": bad flag in substitute command: '}' > make: *** [include/nuttx/config.h] Error 1 > make: *** Waiting for unfinished jobs > > Regards, > Mark > __ > mark.stev...@wildernesslabs.co > > > > >> On 25 Jun 2023, at 11:39, Xiang Xiao wrote: >> >> Mark, could you try this patch: >> https://github.com/apache/nuttx/pull/9610 >> >> On Sun, Jun 25, 2023 at 3:50 PM Mark Stevens wrote: >> >>> So a little more progress on this one. >>> >>> Turning on C++ Exception support for the PicoW:nsh build configuration >>> generates errors: >>> >>> CC: pthread/pthread_testcancel.c >>> machine/arm/gnu_unwind_find_exidx.c:32:8: error: unknown type name >>> '__EIT_entry' >>> 32 | static __EIT_entry *__exidx_start_elf; >>> |^~~ >>> >>> Configuration is: >>> >>> - C++ enabled >>> - uCLib++ library >>> - GNU low level support >>> - Exceptions enabled. >>> >>> Turning exceptions off gives me missing symbols, guess that is going to be >>> a missing library in the link phase. >>> >>> Regards, >>> Mark >>> _ >>> Blog: blog.thepcsite.co.uk >>> Twitter: @nevynuk >>> >>> >>> >>> >>> >>>> On 24 Jun 2023, at 18:59, Mark Stevens wrote: >>>> >>>> I’m currently working on a home project with NuttX and my preferred >>> language is really C++ for what I am doing. I can work in C if necessary >>> but I’d like to use some C++ features. >>>> >>>> So far I have managed to get the framework of what is needed configured >>> and the next step is to start some application implementation. So I’m >>> thinking core logic unit tested using the simulator and basic C++ >>> application on the laptop. >>>> >>>> So I have started a fairly basic test scenario and hit a problem with >>> the C++ support in NuttX. >>>> >>>> My application is going to be using some of the STL, at the moment I’m >>> hitting issues with string and vector, two fairly basic and simple >>> classes. I’m not getting any application to compile successfully. I have >>> tried: >>>> >>>> - Basic C++ support >>>> - LLVM with both the LLVM and GNU low level libraries >>>> - uCLib++ with both LLVM and GNU libraries >>>> >>>> I have tried this with both the sim:nsh and the raspberrypi-pico-w:nsh >>> configurations. >>>> >>>> The classes I am using are fairly basic so I could implement them >>> myself, I would prefer to use a library version though. >>>> >>>> Has anyone managed to use the C++ libraries with NuttX ? >>>> >>>> Regards, >>>> Mark >>>> _ >>>> Blog: blog.thepcsite.co.uk >>>> Twitter: @nevynuk >>>> >>>> >>>> >>>> >>>> >>> >>> >
Re: C++ Support
So here is what I have run: git checkout master git clean -dfx git reset —hard gh pr checkout 9610 make distclean ./tools/configure.sh -l raspberrypi-pico-w:nsh make -j So should just be a base configuration and this compiles OK. I then reconfigured to system to add C++ uCLib++ hellowxx Removed some applications and tests that I’m not interested in and add my application. make -j clean && make -j And this results in: Create version.h sed: 1: "/CONFIG_BASE_DEFCONFIG/ ...": bad flag in substitute command: '}' make: *** [include/nuttx/config.h] Error 1 make: *** Waiting for unfinished jobs Regards, Mark __ mark.stev...@wildernesslabs.co > On 25 Jun 2023, at 11:39, Xiang Xiao wrote: > > Mark, could you try this patch: > https://github.com/apache/nuttx/pull/9610 > > On Sun, Jun 25, 2023 at 3:50 PM Mark Stevens wrote: > >> So a little more progress on this one. >> >> Turning on C++ Exception support for the PicoW:nsh build configuration >> generates errors: >> >> CC: pthread/pthread_testcancel.c >> machine/arm/gnu_unwind_find_exidx.c:32:8: error: unknown type name >> '__EIT_entry' >> 32 | static __EIT_entry *__exidx_start_elf; >> |^~~ >> >> Configuration is: >> >> - C++ enabled >> - uCLib++ library >> - GNU low level support >> - Exceptions enabled. >> >> Turning exceptions off gives me missing symbols, guess that is going to be >> a missing library in the link phase. >> >> Regards, >> Mark >> _ >> Blog: blog.thepcsite.co.uk >> Twitter: @nevynuk >> >> >> >> >> >>> On 24 Jun 2023, at 18:59, Mark Stevens wrote: >>> >>> I’m currently working on a home project with NuttX and my preferred >> language is really C++ for what I am doing. I can work in C if necessary >> but I’d like to use some C++ features. >>> >>> So far I have managed to get the framework of what is needed configured >> and the next step is to start some application implementation. So I’m >> thinking core logic unit tested using the simulator and basic C++ >> application on the laptop. >>> >>> So I have started a fairly basic test scenario and hit a problem with >> the C++ support in NuttX. >>> >>> My application is going to be using some of the STL, at the moment I’m >> hitting issues with string and vector, two fairly basic and simple >> classes. I’m not getting any application to compile successfully. I have >> tried: >>> >>> - Basic C++ support >>> - LLVM with both the LLVM and GNU low level libraries >>> - uCLib++ with both LLVM and GNU libraries >>> >>> I have tried this with both the sim:nsh and the raspberrypi-pico-w:nsh >> configurations. >>> >>> The classes I am using are fairly basic so I could implement them >> myself, I would prefer to use a library version though. >>> >>> Has anyone managed to use the C++ libraries with NuttX ? >>> >>> Regards, >>> Mark >>> _ >>> Blog: blog.thepcsite.co.uk >>> Twitter: @nevynuk >>> >>> >>> >>> >>> >> >>
Re: C++ Support
So a little more progress on this one. Turning on C++ Exception support for the PicoW:nsh build configuration generates errors: CC: pthread/pthread_testcancel.c machine/arm/gnu_unwind_find_exidx.c:32:8: error: unknown type name '__EIT_entry' 32 | static __EIT_entry *__exidx_start_elf; |^~~ Configuration is: - C++ enabled - uCLib++ library - GNU low level support - Exceptions enabled. Turning exceptions off gives me missing symbols, guess that is going to be a missing library in the link phase. Regards, Mark _ Blog: blog.thepcsite.co.uk Twitter: @nevynuk > On 24 Jun 2023, at 18:59, Mark Stevens wrote: > > I’m currently working on a home project with NuttX and my preferred language > is really C++ for what I am doing. I can work in C if necessary but I’d like > to use some C++ features. > > So far I have managed to get the framework of what is needed configured and > the next step is to start some application implementation. So I’m thinking > core logic unit tested using the simulator and basic C++ application on the > laptop. > > So I have started a fairly basic test scenario and hit a problem with the C++ > support in NuttX. > > My application is going to be using some of the STL, at the moment I’m > hitting issues with string and vector, two fairly basic and simple classes. > I’m not getting any application to compile successfully. I have tried: > > - Basic C++ support > - LLVM with both the LLVM and GNU low level libraries > - uCLib++ with both LLVM and GNU libraries > > I have tried this with both the sim:nsh and the raspberrypi-pico-w:nsh > configurations. > > The classes I am using are fairly basic so I could implement them myself, I > would prefer to use a library version though. > > Has anyone managed to use the C++ libraries with NuttX ? > > Regards, > Mark > _ > Blog: blog.thepcsite.co.uk > Twitter: @nevynuk > > > > >
C++ Support
I’m currently working on a home project with NuttX and my preferred language is really C++ for what I am doing. I can work in C if necessary but I’d like to use some C++ features. So far I have managed to get the framework of what is needed configured and the next step is to start some application implementation. So I’m thinking core logic unit tested using the simulator and basic C++ application on the laptop. So I have started a fairly basic test scenario and hit a problem with the C++ support in NuttX. My application is going to be using some of the STL, at the moment I’m hitting issues with string and vector, two fairly basic and simple classes. I’m not getting any application to compile successfully. I have tried: - Basic C++ support - LLVM with both the LLVM and GNU low level libraries - uCLib++ with both LLVM and GNU libraries I have tried this with both the sim:nsh and the raspberrypi-pico-w:nsh configurations. The classes I am using are fairly basic so I could implement them myself, I would prefer to use a library version though. Has anyone managed to use the C++ libraries with NuttX ? Regards, Mark _ Blog: blog.thepcsite.co.uk Twitter: @nevynuk
Raspberry Pi Pico W now has Bluetooth support
Announced today: https://www.raspberrypi.com/news/new-functionality-bluetooth-for-pico-w/ Regards, Mark _ Blog: blog.thepcsite.co.uk Twitter: @nevynuk
Re: STM32 and GDB - How do I generate the ELF file?
Is there any reason for not having the extension? To me the extension adds information about the file. Regards, Mark _ Blog: blog.thepcsite.co.uk Twitter: @nevynuk > On 11 Jun 2023, at 17:19, Petro Karashchenko > wrote: > > The nuttx file is actually an ELF file, but without .elf extension. > > BR, > Petro > > On Sun, Jun 11, 2023, 10:39 AM Mark Stevens wrote: > >> I think the missing piece of information is that the nuttx file contains >> the debug symbols. >> >> Thanks for your time and help. >> >> Regards, >> Mark >> _ >> Blog: blog.thepcsite.co.uk >> Twitter: @nevynuk >> >> >> >> >> >>> On 10 Jun 2023, at 22:10, Alan C. Assis wrote: >>> >>> Hi Mark, >>> >>> Could you please try these magical steps: >>> >>> $ make distclean >>> >>> $ ./tools/configure.sh stm32f777zit6-meadow:nsh >>> >>> $ make menuconfig >>> >>> Build Setup ---> >>> Debug Options ---> >>> [*] Generate Debug Symbols >>> >>> $ make -j >>> >>> Flash nuttx.bin >>> >>> Connect to the board using OpenOCD + STLink-V2: >>> >>> $ sudo openocd -f interface/stlink-v2.cfg -f target/stm32f7x.cfg >>> >>> In another terminal: >>> >>> $ gdb nuttx >>> (gdb) target remote localhost: >>> (gdb) monitor reset >>> (gdb) load nuttx >>> (gdb) b nx_start >>> (gdb) c >>> >>> BR, >>> >>> Alan >>> >>> On 6/10/23, Mark Stevens wrote: >>>> So I’m admitting defeat on this problem and I need some help please. >>>> >>>> I’m trying to work out the magic incantations I need to weave to create >> a >>>> NuttX ELF file that I can use with GDB. To be clear this is the OS ELF >> file >>>> that I can use on the host computer. >>>> >>>> I am currently targeting the Pico boards but I have also had this >> problem >>>> with the STM32F767 Discovery board as well. I have opened connect to >> the >>>> boards in both cases and I am now trying to debug the OS on the board. >>>> >>>> Can anyone point me in the right direction - I’m sure it is going to be >>>> simple, I just need pointing in the right direction. >>>> >>>> Thanks in advance, >>>> Mark >>>> _ >>>> Blog: blog.thepcsite.co.uk >>>> Twitter: @nevynuk >>>> >>>> >>>> >>>> >>>> >>>> >> >>
Re: NuttX Internation Workshop Call for Paper is open!
Are you allowing remote presentations ? Regards, Mark _ Blog: blog.thepcsite.co.uk Twitter: @nevynuk > On 11 Jun 2023, at 14:52, Alan C. Assis wrote: > > Please submit your proposal: > > https://events.nuttx.apache.org
Re: STM32 and GDB - How do I generate the ELF file?
Personally I think debug symbols should be off by default. The default position for any OS should always be small, fast and most importantly, secure. Different modes are a great way of solving this. Visual Studio has had this for as long as I have been using it. Regards, Mark _ Blog: blog.thepcsite.co.uk Twitter: @nevynuk > On 11 Jun 2023, at 14:49, Alan C. Assis wrote: > > You are welcome Mark! > > There is a PR proposing to enabling it by default: > https://github.com/apache/nuttx/pull/9499 > > To be honest I don't know if it will be a good idea. > > Probably some company will forget to disable it and will ship the > firmware with debug symbols enabled. > > Sometime ago a company released their firmware with nsh and the memory > read/write tools enabled and then came his complaining that it was a > security fail (a user used the memory tool to dump their proprietary > firmware) and forced us to disable that memory tool features by > default. > > Some building systems solve like that of Android solve it creating > different compilation modes: Debug, Release, etc. > > BR, > > Alan > > On 6/11/23, Mark Stevens wrote: >> I think the missing piece of information is that the nuttx file contains the >> debug symbols. >> >> Thanks for your time and help. >> >> Regards, >> Mark >> _ >> Blog: blog.thepcsite.co.uk >> Twitter: @nevynuk >> >> >> >> >> >>> On 10 Jun 2023, at 22:10, Alan C. Assis wrote: >>> >>> Hi Mark, >>> >>> Could you please try these magical steps: >>> >>> $ make distclean >>> >>> $ ./tools/configure.sh stm32f777zit6-meadow:nsh >>> >>> $ make menuconfig >>> >>> Build Setup ---> >>> Debug Options ---> >>> [*] Generate Debug Symbols >>> >>> $ make -j >>> >>> Flash nuttx.bin >>> >>> Connect to the board using OpenOCD + STLink-V2: >>> >>> $ sudo openocd -f interface/stlink-v2.cfg -f target/stm32f7x.cfg >>> >>> In another terminal: >>> >>> $ gdb nuttx >>> (gdb) target remote localhost: >>> (gdb) monitor reset >>> (gdb) load nuttx >>> (gdb) b nx_start >>> (gdb) c >>> >>> BR, >>> >>> Alan >>> >>> On 6/10/23, Mark Stevens wrote: >>>> So I’m admitting defeat on this problem and I need some help please. >>>> >>>> I’m trying to work out the magic incantations I need to weave to create >>>> a >>>> NuttX ELF file that I can use with GDB. To be clear this is the OS ELF >>>> file >>>> that I can use on the host computer. >>>> >>>> I am currently targeting the Pico boards but I have also had this >>>> problem >>>> with the STM32F767 Discovery board as well. I have opened connect to >>>> the >>>> boards in both cases and I am now trying to debug the OS on the board. >>>> >>>> Can anyone point me in the right direction - I’m sure it is going to be >>>> simple, I just need pointing in the right direction. >>>> >>>> Thanks in advance, >>>> Mark >>>> _ >>>> Blog: blog.thepcsite.co.uk >>>> Twitter: @nevynuk >>>> >>>> >>>> >>>> >>>> >>>> >> >>
Re: STM32 and GDB - How do I generate the ELF file?
I think the missing piece of information is that the nuttx file contains the debug symbols. Thanks for your time and help. Regards, Mark _ Blog: blog.thepcsite.co.uk Twitter: @nevynuk > On 10 Jun 2023, at 22:10, Alan C. Assis wrote: > > Hi Mark, > > Could you please try these magical steps: > > $ make distclean > > $ ./tools/configure.sh stm32f777zit6-meadow:nsh > > $ make menuconfig > > Build Setup ---> >Debug Options ---> >[*] Generate Debug Symbols > > $ make -j > > Flash nuttx.bin > > Connect to the board using OpenOCD + STLink-V2: > > $ sudo openocd -f interface/stlink-v2.cfg -f target/stm32f7x.cfg > > In another terminal: > > $ gdb nuttx > (gdb) target remote localhost: > (gdb) monitor reset > (gdb) load nuttx > (gdb) b nx_start > (gdb) c > > BR, > > Alan > > On 6/10/23, Mark Stevens wrote: >> So I’m admitting defeat on this problem and I need some help please. >> >> I’m trying to work out the magic incantations I need to weave to create a >> NuttX ELF file that I can use with GDB. To be clear this is the OS ELF file >> that I can use on the host computer. >> >> I am currently targeting the Pico boards but I have also had this problem >> with the STM32F767 Discovery board as well. I have opened connect to the >> boards in both cases and I am now trying to debug the OS on the board. >> >> Can anyone point me in the right direction - I’m sure it is going to be >> simple, I just need pointing in the right direction. >> >> Thanks in advance, >> Mark >> _ >> Blog: blog.thepcsite.co.uk >> Twitter: @nevynuk >> >> >> >> >> >>
STM32 and GDB - How do I generate the ELF file?
So I’m admitting defeat on this problem and I need some help please. I’m trying to work out the magic incantations I need to weave to create a NuttX ELF file that I can use with GDB. To be clear this is the OS ELF file that I can use on the host computer. I am currently targeting the Pico boards but I have also had this problem with the STM32F767 Discovery board as well. I have opened connect to the boards in both cases and I am now trying to debug the OS on the board. Can anyone point me in the right direction - I’m sure it is going to be simple, I just need pointing in the right direction. Thanks in advance, Mark _ Blog: blog.thepcsite.co.uk Twitter: @nevynuk
Re: Intertask communication in NuttX
Options I would consider would be Message queues Pipes For the project I am involved in we use both of these but mainly use message queues. Message queues should only be used for small messages, I think the limit is about 22 bytes. I get around this by creating the large message and passing the pointer to the message through the message queue interface. Regards, Mark __ mark.stev...@wildernesslabs.co > On 17 Dec 2022, at 06:52, Roberto Bucher wrote: > > Hi > > after successfully reached to recompile the microROS environment, I'd like to > build an intertask communication between a microROS node and a pysimCoder > generated code. > > I think that I can't use a shared memory with my embedded system > (nucleo-144), because I can't see the CONFIG_BUILD_KERNEL=y in my .config > file. > > Are there other IPC mechanism that I can use to communicate between the 2 > tasks? > > Thanks in advance > > Roberto >
Re: malloc, free, strdup and kernel builds
Thanks you for taking the time to respond. I think I will look at providing kmm_strdup and submit a PR with the fix. It will probably be safer to do this and reduce the possibly of disturbing existing code with changes to the definition of free. Regards, Mark _ Blog: blog.thepcsite.co.uk Twitter: @nevynuk > On 21 Sep 2022, at 17:24, Gregory Nutt wrote: > > This does not seem like a technical issue but rather awkward usage/naming > that is prone to misuse. > > Yes, free() should be called to release the memory allocated by strdup. But > applications cannot use the kernel heap and, for reasons of protection, the > kernel should not store anything in the user-accessible application heap in > Protected mode. In Kernel mode, the application heap may not even be > available to OS without switching the address environment. > > So I think that a clean solution would be to fix the naming, either: (1) > rename the stdup used by the OS to kmm_strdup() with allocated memory freed > by kmm_free(), or (2) conditionally redefine free() to be kmm_free() in the > kernel portion of the build. > > kmm_free() is already defined as free() in the FLAT build in > include/nuttx/kmalloc.h > > On 9/21/2022 9:59 AM, Mark Stevens wrote: >> So this post has been triggered by an issue I have just had using strdup in >> the OS components of a protected mode build. >> >> For clarity I will be using the term OS for the kernel part of the build and >> application/app for the user part of the build. >> >> The TLDR; is this design question: >> >> Do we expect malloc and free to work with the relevant heaps? So for the OS >> should they be working with the kernel heap and for apps they should be >> using the user heap? >> >> I am trying to work out if the problem is with strdup or with malloc & free. >> >> >> Investigation / background >> >> My understanding of strdup is that any string generated should have its >> memory released using free, at least that is the way I have been using it >> for years. >> >> The system under development uses a protected/kernel build with a memory >> protection unit. We also have two heaps, one for the OS and one for the app. >> >> At some point in the OS lifecycle we have the need to generate copies of >> strings. These were generated using strdup. At some point in the future >> these strings were released using free. At a point further in the future >> the system crashed. >> >> After some tracking it turns out that strdup was allocating memory using the >> kernel heap (the strings were duplicated in the OS) and then freed in the OS >> but the memory was being released to the user (Application) heap. When this >> was then later allocated and used in user space the system would crash with >> a memory fault. >> >> Investigation points to the fact that strdup uses lib_malloc which will call >> kmm_malloc in OS builds and malloc in app builds. >> >> It also appears that malloc and free always work with the user heap. >> >> I know that our build is a little old but looking at the sources this seems >> to be the case with the current release. I am struggling to get the >> protected build working on a F767 board to verify if the problem is still >> present. >> >> Regards, >> Mark >> _ >> Blog: blog.thepcsite.co.uk >> Twitter: @nevynuk >> >> >> >> >> >
malloc, free, strdup and kernel builds
So this post has been triggered by an issue I have just had using strdup in the OS components of a protected mode build. For clarity I will be using the term OS for the kernel part of the build and application/app for the user part of the build. The TLDR; is this design question: Do we expect malloc and free to work with the relevant heaps? So for the OS should they be working with the kernel heap and for apps they should be using the user heap? I am trying to work out if the problem is with strdup or with malloc & free. Investigation / background My understanding of strdup is that any string generated should have its memory released using free, at least that is the way I have been using it for years. The system under development uses a protected/kernel build with a memory protection unit. We also have two heaps, one for the OS and one for the app. At some point in the OS lifecycle we have the need to generate copies of strings. These were generated using strdup. At some point in the future these strings were released using free. At a point further in the future the system crashed. After some tracking it turns out that strdup was allocating memory using the kernel heap (the strings were duplicated in the OS) and then freed in the OS but the memory was being released to the user (Application) heap. When this was then later allocated and used in user space the system would crash with a memory fault. Investigation points to the fact that strdup uses lib_malloc which will call kmm_malloc in OS builds and malloc in app builds. It also appears that malloc and free always work with the user heap. I know that our build is a little old but looking at the sources this seems to be the case with the current release. I am struggling to get the protected build working on a F767 board to verify if the problem is still present. Regards, Mark _ Blog: blog.thepcsite.co.uk Twitter: @nevynuk
