Re: SPI EEPROM, losetup, LittleFS
I will look at lomtd, thanks. But if littlefs is not suitable (a quick look and it seemed it might be a reasonably choice for a 16KiB EEPROM?) is there an FS in NuttX that is suitable? "Out there" I find NASA's EEFS and one or two others I could try (and submit to NuttX; depending on licensing of course) but quicker to try/use something we already have of course. On 16/12/2023 04:10, Xiang Xiao wrote: On Fri, Dec 15, 2023 at 5:17 PM Sebastien Lorquet wrote: Hi, I dont think you can use losetup to create a mtd device. loop devices are regular block devices. You can use lomtd to setup a mtd device loop: https://github.com/apache/nuttx-apps/blob/master/nshlib/nsh_fscmds.c#L1144-L1306 This will only work if littlefs can mount a block device (no idea if thats possible) Yes, littlefs can work with block devices directly, the difference between mtd and block is hidden by littlefs wrapper. Of course, littlefs isn't an efficient solution for block devices since the wear leveling built inside littlefs is useless and harms the performance a lot. what you need is an adaptation layer that will implement a mtd device on an eeprom. You can duplicate 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 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 my behind again. This is perhaps the 3rd time over the years I've asked but even checking the dev emails archive and I can't find what I need. SPI EEPROM is correctly registered as /dev/at25 and I can read/write/etc to it as a character device. NB: it does not initialize in the same way as an I2C EEPROM so you can't directly initialise it as an mtd. It is for storage of settings, and some of the values may change 10,000's time over the life of the product, hence EEPROM with 1,000,000+ write cycles. But there is then no wear levelling or anything like that as just a character device, so I thought I'd have a play, and LittleFS has a small minimum sector size and *might* work. A quick Google turns up the same Linux-related losetup examples that don't seem relevant; my Googling skills are probably as bad as those of my software engineering . Any pointers/suggestions please?
[Article] NuttX on Ox64 BL808 RISC-V SBC: Bare Metal Experiments
Pine64 Ox64 BL808 (64-bit RISC-V SBC) is now supported in NuttX Mainline! (Many thanks to my reviewers) Ox64 BL808 is an affordable $8 SBC with: - 3 x RISC-V Cores (T-Head 64-bit / 32-bit) - Networking: Ethernet, WiFi, Bluetooth LE, Zigbee - Peripheral Interfaces: UART (Serial), I2C, SPI, USB, MIPI CSI - Interrupt Controller: CLINT and PLIC - Memory Management: Sv39 MMU - OpenSBI Supervisor Binary Interface and U-Boot Bootloader - Bootable microSD: Boot NuttX and Linux But there's a catch: - Limited RAM (64 MB): It's not for gaming and servers - Flash Memory is Empty: Needs a One-Time Flashing (via a USB Serial Adapter) - Barebones Form Factor: Fits on a Breadboard, Ethernet is optional In this article we walk through the steps to: (1) Flash into Ox64 the U-Boot Bootloader and OpenSBI (2) Boot Linux on a microSD Card (3) Do the same to boot NuttX RTOS (4) Run some Bare Metal Experiments inside the NuttX Kernel Check out the article here: https://www.hackster.io/lupyuen/8-risc-v-sbc-on-a-real-time-operating-system-ox64-nuttx-474358 Lup
Re: [Article] NuttX on Ox64 BL808 RISC-V SBC: Bare Metal Experiments
Congratulations Lup!! :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: [Article] NuttX on Ox64 BL808 RISC-V SBC: Bare Metal Experiments
The Zigbee support is interesting. NuttX does not have a Zigbee stack, but does have IEEE 802.15.4 which works with the same physical radio. The IEEE 802.15.4 logic is quite an accomplishment. The original development was done by Anthony Merlino and Sebasiten Lorquet. I see that there have been many recent commits for Xiaomi folks too. When Anthony used the xbee which is a native Zigbee radio, he had to re-flash the part for use with IEEE 802.14.5 I also ported/re-implemented 6LoWPAN for use with IEEE 802.14.5. That is a very powerful solution. I had intended to support 6LoWPAN with Bluetooth radios too, but never got around to it. On 12/16/2023 5:03 PM, Lee, Lup Yuen wrote: Pine64 Ox64 BL808 (64-bit RISC-V SBC) is now supported in NuttX Mainline! (Many thanks to my reviewers) Ox64 BL808 is an affordable $8 SBC with: - 3 x RISC-V Cores (T-Head 64-bit / 32-bit) - Networking: Ethernet, WiFi, Bluetooth LE, Zigbee - Peripheral Interfaces: UART (Serial), I2C, SPI, USB, MIPI CSI - Interrupt Controller: CLINT and PLIC - Memory Management: Sv39 MMU - OpenSBI Supervisor Binary Interface and U-Boot Bootloader - Bootable microSD: Boot NuttX and Linux But there's a catch: - Limited RAM (64 MB): It's not for gaming and servers - Flash Memory is Empty: Needs a One-Time Flashing (via a USB Serial Adapter) - Barebones Form Factor: Fits on a Breadboard, Ethernet is optional In this article we walk through the steps to: (1) Flash into Ox64 the U-Boot Bootloader and OpenSBI (2) Boot Linux on a microSD Card (3) Do the same to boot NuttX RTOS (4) Run some Bare Metal Experiments inside the NuttX Kernel Check out the article here: https://www.hackster.io/lupyuen/8-risc-v-sbc-on-a-real-time-operating-system-ox64-nuttx-474358 Lup
Re: debugassert vs assert in apps
While we’re on this topic I would also like to encourage authors to put only one condition in their asserts instead of multiple. So, DEBUGASSERT(cond1) ; DEBUGASSERT (cond2); (…) Instead of DEBUGASSERT(cond1 && cond2 &&..). When an assertion happens and there’s multiple conditions then I don’t know which one triggered it. Best, Daniel *Daniel Appiagyei | Embedded Software Engineer *Email: daniel.appiag...@braincorp.com *Brain* * Corp™ *10182 Telesis Ct, Suite 100 San Diego, CA 92121 (858)-689-7600 www.braincorp.com On Fri, Dec 15, 2023 at 3:40 AM Alan C. Assis wrote: > I think debugassert() is for finding BUGs during the development/testing > phase. > > In the other hand assert() should be put in case where something really > catastrofic is going to happen and cannot be avoid anyway. > > My personal opinion is that release code shouldn't have (or should have the > minimum as possible) assert() and PANIC(). You don't wasn't want your code > to fail in a critical moment, do you? > > So assert() code could be used during an inicial validation phase in the > field. But of course, if it is a HW issue, there is nothing your code can > do except showing a BSOD. > > BR, > > Alan > > On Thu, Dec 14, 2023 at 11:50 AM Tim Hardisty > wrote: > > > 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 unknown higher level app, have done something dumb > > that should be picked up during nuttx-apps development and so should > > not make it through to final code; but if they do, that's the fault > > of the developer for not turning on debug asserts!! > > * use assert if the error would cause the obviously unknown > > higher-level calling app someone's writing to fail if the error was > > allowed to pass unchecked, so the developer of that higher level app > > can deal with it programmatically. > > > > That might almost suggest that debugassert() is for private functions > > and assert() is for public ones? > > > > Probably over-thinking it as usual, but I'm never afraid to ask :) > > > > Thanks! > > > > TimJTi. > > >
