Re: No error return in fprintf().
Thanks Fotis, I haven't had a chance to look at the code for stream_putc (i'm away from my computer and on my phone) but based on your description, it sounds like stream_putc should check and propagate errors. Even if the write to disk won't happen until later, any errors that are caught shouldn't be discarded. Nathan On Thu, Jul 20, 2023 at 3:56 PM Fotis Panagiotopoulos wrote: > Hello Nathan, > > Indeed, I should have mentioned that I have selected > CONFIG_STDIO_DISABLE_BUFFERING. > So, at least in my case, no buffering is taking place. > > But in the case of buffered output, I think that I agree that fprintf() may > return success for buffered (but not written) data. > > On Thu, Jul 20, 2023 at 10:16 PM Nathan Hartman > wrote: > > > On Thu, Jul 20, 2023 at 3:02 PM Fotis Panagiotopoulos < > f.j.pa...@gmail.com > > > > > wrote: > > > > > Hello, > > > > > > I am using fprintf() to output some data to a file. This file is > located > > on > > > an SD card. > > > > > > As I realised, fprintf() never returns an error. > > > > > > I tried to completely remove the SD card from the system, and fprintf > > > happily succeeds, > > > returning the number of bytes that it would have written, if the write > > was > > > successful. > > > > > > By checking the call trace, I see that the problem lies within > > > vsprintf_internal(). > > > It calls stream_putc() but no error checking is done there. > > > > > > Shouldn't this be considered a bug? > > > > > > > I haven't studied the code, so I may be off here, but... > > > > If fprintf() return code indicates success to my application, my > > expectation is that the data has been written. However it might be a > little > > more complicated than that: what if fprintf() successfully *buffered* the > > data and the fs layer is waiting for an opportunity to write it? In this > > scenario fprintf would return to the application before writing > completes. > > Then, it would be sensible for fprintf to indicate success (of the > > buffering) even though data wasn't actually stored on flash yet. Maybe a > > separate call to sync the fs is needed? > > > > Having said all that, stream_putc should probably do error checking and > > propagate errors. > > > > Cheers > > Nathan > > >
Re: No error return in fprintf().
Hello Nathan, Indeed, I should have mentioned that I have selected CONFIG_STDIO_DISABLE_BUFFERING. So, at least in my case, no buffering is taking place. But in the case of buffered output, I think that I agree that fprintf() may return success for buffered (but not written) data. On Thu, Jul 20, 2023 at 10:16 PM Nathan Hartman wrote: > On Thu, Jul 20, 2023 at 3:02 PM Fotis Panagiotopoulos > > wrote: > > > Hello, > > > > I am using fprintf() to output some data to a file. This file is located > on > > an SD card. > > > > As I realised, fprintf() never returns an error. > > > > I tried to completely remove the SD card from the system, and fprintf > > happily succeeds, > > returning the number of bytes that it would have written, if the write > was > > successful. > > > > By checking the call trace, I see that the problem lies within > > vsprintf_internal(). > > It calls stream_putc() but no error checking is done there. > > > > Shouldn't this be considered a bug? > > > > I haven't studied the code, so I may be off here, but... > > If fprintf() return code indicates success to my application, my > expectation is that the data has been written. However it might be a little > more complicated than that: what if fprintf() successfully *buffered* the > data and the fs layer is waiting for an opportunity to write it? In this > scenario fprintf would return to the application before writing completes. > Then, it would be sensible for fprintf to indicate success (of the > buffering) even though data wasn't actually stored on flash yet. Maybe a > separate call to sync the fs is needed? > > Having said all that, stream_putc should probably do error checking and > propagate errors. > > Cheers > Nathan >
Re: Unable to get nsh working on Adafruit Feather rp2040
On Thu, Jul 20, 2023 at 3:28 PM Richard Fox wrote: > Hi, > > I'm new to NuttX and to the pico-sdk, (and RTOSs in general). I have an > Adafruit Feather RP2040 that I was using to experiment with NuttX and I > haven't been able to get either the nsh or usbnsh apps to work, (and I > haven't really tried anything else). > > I have the Feather RP2040 connected to my Mac using an Adafruit #954 USB > to TTL serial cable (pre 2014). I have the device wired so that the > serial cable is connected to GND, Green TX to rp2040:GPIO1, white RX to > rp2040:GPIO0. > > Using this configuration, I have successfully built installed, and > tested the pico-sdk "pico-examples/build/uart/hello_uart" example that > prints a string via the serial cable to a terminal emulator on the Mac. > This was operating at 115200 baud. > > I've also successfully built and installed the bi-directional example > from the Arduino distribution: Arduino:Built-in Examples:4. > Communications:SerialPassThrough and am able to send to and receive from > the Feather RP2040 through the serial cable and through the > cu.usbmodem101 device that gets created when the controller is attached > to my Mac with a USB cable. Communications were at 9600 baud. > > I have the following environment variables set in my build terminal. > export PICO_SDK_PATH=/opt/pico/pico-sdk > export HOST_PLATFORM=mac > > I can start the build process and it seems to succeed: > > make distclean > ./tools/configure.sh -m adafruit-feather-rp2040:nsh > make -j4 > ... > LN: platform/board to > > /Users/rfox/Documents/Computers/rtos/apache-nuttx/nuttxspace/apps/platform/dummy > Register: hello > Register: nsh > Register: getprime > Register: sh > Register: ostest > CPP: > /Users/rfox/Documents/Computers/rtos/apache-nuttx/nuttxspace/nuttx/boards/arm/rp2040/adafruit-feather-rp2040/scripts/adafruit-feather-rp2040-flash.ld-> > > /Users/rfox/Documents/Computers/rtos/apacheLD: nuttx > > > Generating: nuttx.uf2 > tools/rp2040/elf2uf2 nuttx nuttx.uf2; > Done. > > Then I copy the uf2 binary over to the mounted controller volume using > the handy BOOTSEL feature. > After the volume is disconnected and my Mac has harped at me for doing > it wrong, I open a screen to the device: I'm not familiar with this board or BOOTSEL so this might be a dumb question, but is it supposed to be the nuttx.uf2 file? (Note: It is possible to produce several different types of binary images. On my boards, I use "nuttx" -- no extension.) More ideas below... screen /dev/cu.usbserial-110 115200 > > Hit return a few times and get no response. > By chance do you have sn oscilloscope or logic analyzer to look at the serial signals and see if anything is being transmitted, and at what baud rate? Have you tried running "make menuconfig" (after configure.sh and before make) to verify that the serial driver is in fact enabled and that the console is configured to use it? (Maybe the output is going elsewhere.) Does the board have software-controlled LEDs and if so do they light up, blink, or stay off? l Do you have ability to try single step debugging, at least for the first part of bootup, to see if anything is running? Maybe others will have other ideas. Especially, input from someone familiar with this board will be helpful!! Hope this helps, Nathan
Unable to get nsh working on Adafruit Feather rp2040
Hi, I'm new to NuttX and to the pico-sdk, (and RTOSs in general). I have an Adafruit Feather RP2040 that I was using to experiment with NuttX and I haven't been able to get either the nsh or usbnsh apps to work, (and I haven't really tried anything else). I have the Feather RP2040 connected to my Mac using an Adafruit #954 USB to TTL serial cable (pre 2014). I have the device wired so that the serial cable is connected to GND, Green TX to rp2040:GPIO1, white RX to rp2040:GPIO0. Using this configuration, I have successfully built installed, and tested the pico-sdk "pico-examples/build/uart/hello_uart" example that prints a string via the serial cable to a terminal emulator on the Mac. This was operating at 115200 baud. I've also successfully built and installed the bi-directional example from the Arduino distribution: Arduino:Built-in Examples:4. Communications:SerialPassThrough and am able to send to and receive from the Feather RP2040 through the serial cable and through the cu.usbmodem101 device that gets created when the controller is attached to my Mac with a USB cable. Communications were at 9600 baud. I have the following environment variables set in my build terminal. export PICO_SDK_PATH=/opt/pico/pico-sdk export HOST_PLATFORM=mac I can start the build process and it seems to succeed: make distclean ./tools/configure.sh -m adafruit-feather-rp2040:nsh make -j4 ... LN: platform/board to /Users/rfox/Documents/Computers/rtos/apache-nuttx/nuttxspace/apps/platform/dummy Register: hello Register: nsh Register: getprime Register: sh Register: ostest CPP: /Users/rfox/Documents/Computers/rtos/apache-nuttx/nuttxspace/nuttx/boards/arm/rp2040/adafruit-feather-rp2040/scripts/adafruit-feather-rp2040-flash.ld-> /Users/rfox/Documents/Computers/rtos/apacheLD: nuttx Generating: nuttx.uf2 tools/rp2040/elf2uf2 nuttx nuttx.uf2; Done. Then I copy the uf2 binary over to the mounted controller volume using the handy BOOTSEL feature. After the volume is disconnected and my Mac has harped at me for doing it wrong, I open a screen to the device: screen /dev/cu.usbserial-110 115200 Hit return a few times and get no response. I've tried rebooting the controller, disconnecting and reconnecting the serial cable, doing both. Nothing seems to make any difference. I've tried swapping the RX/TX connections just in case there was a pin assignment setting different than the pico-sdk and arduino setups but it didn't make any difference. I've tried also using the usbnsh code but there is never a second device created in /dev/ to connect to. That is, /dev/cu.usbserial* device is present from the serial cable connection but the "modem" device that gets created by using the arduino passthrough, for example, /dev/cu.usbmodem101 does not exist when the usbnsh configured RP2040 is connected to a USB port. I figure that I'm missing some step, perhaps something I need to set using the optional mkconfig step that I'm skipping over but the solution eludes me. Thanks for any advice, Rich.
Re: No error return in fprintf().
On Thu, Jul 20, 2023 at 3:02 PM Fotis Panagiotopoulos wrote: > Hello, > > I am using fprintf() to output some data to a file. This file is located on > an SD card. > > As I realised, fprintf() never returns an error. > > I tried to completely remove the SD card from the system, and fprintf > happily succeeds, > returning the number of bytes that it would have written, if the write was > successful. > > By checking the call trace, I see that the problem lies within > vsprintf_internal(). > It calls stream_putc() but no error checking is done there. > > Shouldn't this be considered a bug? > I haven't studied the code, so I may be off here, but... If fprintf() return code indicates success to my application, my expectation is that the data has been written. However it might be a little more complicated than that: what if fprintf() successfully *buffered* the data and the fs layer is waiting for an opportunity to write it? In this scenario fprintf would return to the application before writing completes. Then, it would be sensible for fprintf to indicate success (of the buffering) even though data wasn't actually stored on flash yet. Maybe a separate call to sync the fs is needed? Having said all that, stream_putc should probably do error checking and propagate errors. Cheers Nathan
No error return in fprintf().
Hello, I am using fprintf() to output some data to a file. This file is located on an SD card. As I realised, fprintf() never returns an error. I tried to completely remove the SD card from the system, and fprintf happily succeeds, returning the number of bytes that it would have written, if the write was successful. By checking the call trace, I see that the problem lies within vsprintf_internal(). It calls stream_putc() but no error checking is done there. Shouldn't this be considered a bug?
