lvgl
littlefs
Our great sponsors
lvgl | littlefs | |
---|---|---|
63 | 29 | |
14,890 | 4,764 | |
3.0% | 3.4% | |
9.9 | 8.2 | |
7 days ago | 8 days ago | |
C | C | |
MIT License | BSD 3-clause "New" or "Revised" License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
lvgl
-
Ask HN: Nobody interested an open hardware iPod Nano?
So here is the thing: The iPod Nano 7g is from 2012. I've seen many people designing custom PCBs and releasing Kickstarter projects for custom audio players[5] or game handhelds[6]. I know Rockbox (which is great, but its lacks support for Wifi and Bluetooth AFAIK and just does not compete with the UX of iPod's audio book features in my opinion) and iPod Linux. 10 years ago someone even reverse engineered the iPod Nano 6g display[3].
Although I'm not skilled enough in PCB-Design, after some research I found the Lilygo T-Display S3 Pro[4] based on ESP32 S3, which would be the size, but lacks audio and OS. There is also the Mango PI CyberPad[7], which looked interesting, but maybe is already too clunky.
Programming wise, LVGL[8] may be a good framework to develop a modern and efficient UI - at least it looks promising.
So, why is nobody interested in recreating an iPod nano like device? It should be doable with modern tech, but Phones have completely taken over the marked...
1: https://www.reddit.com/r/audiobooks/comments/14ue4un/comment/ks1sj99/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button
2: https://github.com/advplyr/audiobookshelf-app/issues/847
3: https://www.youtube.com/watch?v=7TedIzmguP0
4: https://www.lilygo.cc/products/t-display-s3-pro
5: https://www.youtube.com/watch?v=1C597AkhGtw
6: https://www.funkey-project.com/
7: https://mangopi.org/cp1m
8: https://lvgl.io/
-
LVGL 9.0 Released
LVGL is a graphics library used mostly for embedded UI's. Main website: https://lvgl.io/
-
imgui VS lvgl - a user suggested alternative
2 projects | 3 Nov 2023
Popular embedded UI library
- LVGL: Light and Versatile Graphics Library
-
Show HN: Slint - A Declarative UI Toolkit Written in Rust for Embedded & Desktop
If you need something written in C and very tiny, I recommend LVGL https://lvgl.io/
- Open-source graphics library to create UIs for any microcontroller
- How to write display drivers?
-
Lilygo T-Display-S3 AMOLED
The factory code uses the Lvgl graphic library. https://github.com/lvgl/lvgl
- Is anyone still offering 1.4ghz mod services?
-
Interfacing SPI LCD with Zynq 7020
I'm trying to interface SPI LCD (ILI943) with Zynq 7020 (PYNQ-Z2 board) and LVGL embedded UI libary. And considering between two approaches:
littlefs
- LittleFS Design (CObW) – Combining advantages of COW and log-structures
- LittleFS Design
-
Littlefs – a little fail-safe filesystem designed for microcontrollers
Pointers correctly round-trip through unrelated pointer types, provided the alignment for both types is compatible.
At least one bit does look a bit questionable: lfs_mlist is treated as the common initial sequence of lfs_dir and lfs_file, even though it isn't, and common initial sequences only apply to union fields anyway. Example cast of struct dir * to struct lfs_mlist * (probably valid of itself, assuming the alignment is compatible): https://github.com/littlefs-project/littlefs/blob/c733d9ec57... then use struct dir as if it were actually a struct lfs_mlist: https://github.com/littlefs-project/littlefs/blob/c733d9ec57...
(There's other occurrences of the same kind of thing.)
Strictly speaking, I think this might be unfixable without a bunch of work, but so much stuff does this kind of operation that any compiler that doesn't do what you expect will have been fixed by now. (Assuming you're not one of those people who is going to pop up and tell us with a straight face that what we should expect is for the compiler to do absolutely anything - except, perhaps, for having it generate correct code, which would be defective behaviour that should be eliminated.) Maybe improve the odds by using lfs_mlist as the common initial sequence of both structs, and fingers crossed that the compiler considers the union rules to apply to this case too. Or compile with -fno-strict-aliasing.
-
I made a tachometer/hour meter for my outboard engine using the PIO
Also, it looks like you're writing to the flash every second the engine is running. Do you have an idea of what the endurance of that might be? I'm not too familiar with this but supposedly the flash on the Pico is good for at least 100K program/erase cycles and Micropython uses LittleFS on RP2040 which does wear leveling. I looked for more official info and the rp2 port code backs that up with a note: "the flash requires the programming size to be aligned to 256 bytes". And the littlefs readme does say it does wear leveling and other good stuff.
- GitHub - littlefs-project/littlefs: A little fail-safe filesystem designed for microcontrollers
-
nRF Connect SDK file writes gives -22 error after many files
Maybe first go and localize which assumption has been voided, i.e. what of the many places in littlefs that raise this error actually raise it? And... erm... what littlefs are you talking about? https://github.com/littlefs-project/littlefs doesn't seem to have a fs_close() function...
- SPI Flash file system vs writing my own fifo?
-
Small MicroSD module for project
Rather easy to add LittleFS for file storage onto the NOR flash. https://github.com/littlefs-project/littlefs
- CircuitPython – The easiest way to program microcontrollers
What are some alternatives?
TFT_eSPI - Arduino and PlatformIO IDE compatible TFT library optimised for the Raspberry Pi Pico (RP2040), STM32, ESP8266 and ESP32 that supports different driver chips
spiffs - Wear-leveled SPI flash file system for embedded devices
LovyanGFX - SPI LCD graphics library for ESP32 (ESP-IDF/ArduinoESP32) / ESP8266 (ArduinoESP8266) / SAMD51(Seeed ArduinoSAMD51)
zephyr - Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
imgui - Dear ImGui: Bloat-free Graphical User interface for C++ with minimal dependencies
lwext4 - ext2/ext3/ext4 filesystem library for microcontrollers
GuiLite - ✔️The smallest header-only GUI library(4 KLOC) for all platforms
uf2 - UF2 file format specification
micropython-micro-gui - A lightweight MicroPython GUI library for display drivers based on framebuf, allows input via pushbuttons.
STORfs - Open source file system for small embedded systems
slint - Slint is a declarative GUI toolkit to build native user interfaces for Rust, C++, or JavaScript apps.
btrfs - Haskell bindings to the btrfs API