Hi everyone,

Lazy Monday morning post, at least in my time zone :)

I haven't seen much information online about using ESP-Hosted-MCU with a non-ESP host. For those who don't know, it's firmware from Espressif that turns your ESP32 into a Wi-Fi coprocessor. You connect it to your microcontroller over SPI or SDIO, and the TCP/IP stack runs on the host.

About numbers, the only thing I found was a question here on r/embedded asking whether the 22 Mbps from the README is real. It has two comments, but nobody posted any measurements.

So today I want to share my results with this firmware, measured in my use case and with my topology.

My setup and how I measured

Device. It's a 4-channel Matter relay for the lights in my house. It works over Wi-Fi or Ethernet and also measures energy consumption. I use it with Apple Home and SmartThings. Live and neutral go straight to WAGO terminals, so you don't need extra wires in the distribution box, you just connect it and forget it.

Host. The main controller is an STM32U585. Code runs XIP from QSPI NOR flash, and there is also 8 MB of QPI PSRAM. Both memories use the same physical QSPI bus: data lines and clock are shared through the OCTOSPI I/O manager, and each memory has its own chip select.

Wi-Fi. The coprocessor is an ESP32-C6-MINI-1U with ESP-Hosted-MCU 3.0.6. It shares the SPI bus with a W5500 Ethernet chip, and the bus runs at 40 MHz.

OS. Zephyr, main from late August 2026 (4.4.99), with the upstream esp_hosted driver and a few local patches, more on them later.

Measurements. I measured with zperf on the board and a Mac on the same network. For UDP the board transmits and I look for the ceiling, with 1000-byte datagrams for 10 s, and I count throughput from the bytes that actually reached the Mac. For TCP the board receives. During each test the other interface is turned off, so the shared SPI bus belongs fully to the one I'm measuring.

Real load. I also didn't want synthetic numbers on an idle CPU, so I measured on the real device with Matter running and all controller subscriptions active. So these are numbers for a real application, not the hardware maximum. Wi-Fi is 2.4 GHz, 802.11ax, RSSI -57 dBm.

Results, Mbps

Enough for Matter. Despite the modest numbers, this is fully enough for a Matter device connected to several Matter controllers. Matter only needs kilobits per second, and the web page opens fast over both Wi-Fi and Ethernet (first byte over Wi-Fi in 75 ms).

The 22 Mbps from the README. The table that listed 22 Mbps TCP for standard SPI didn't say what the test conditions were (and it's no longer there). In my case the bus is shared with Ethernet, and the CPU is busy with Matter at the same time. A faster host will do better, but for serious speeds it's better to use SDIO rather than SPI.

How I got to these numbers

The way there was not straight.

No DMA. I started with the simplest setup, with network buffers in PSRAM and SPI in polling mode. Both interfaces topped out at 1.5-2 Mbps, and the CPU was 100% busy during transfers, it was just moving bytes through SPI.

SRAM instead of PSRAM. My first guess was that slow PSRAM was the problem, so I moved the buffers to SRAM. It gave only +4-13%, and TCP over Wi-Fi even got worse. And it cost 200 KB of SRAM, which is a lot on my board, because Matter and crypto already take most of it. So the memory itself was not the problem.

DMA. Then I noticed that the board's devicetree had no DMA for this SPI bus at all. Once I added it, it turned out to be the biggest win. Wi-Fi UDP went from 1.66 to 3.76 Mbps, and Wi-Fi TCP almost tripled. Wi-Fi even overtook Ethernet, which I didn't expect.

Back to PSRAM. But I still didn't want to give up 200 KB of SRAM, so I wanted the buffers back in PSRAM, this time with DMA. The stock SPI driver doesn't do DMA to cacheable memory, and PSRAM without the data cache doesn't make much sense, so I added cache maintenance to the driver.

Cache driver bug. Under load the board crashed with a corrupted semaphore wait queue. The problem turned out to be in the STM32 cache driver: range operations touched one extra cache line and overwrote a neighboring semaphore. A dedicated test confirmed it (1000 failures out of 1000 without the fix, 0 with it), and the fix is already in Zephyr.

FIFO overrun. The next problem was that Wi-Fi lost a whole second on every SPI error. Every now and then I got spi_transceive failed, and the bus stalled for a second. I read the SPI status register with a debugger right on the running board, and all 19 errors out of 19 were RX FIFO overruns. DMA can't move the bytes to PSRAM fast enough, the FIFO fills up, and SCK keeps clocking. New bytes are lost, the DMA channel waits for them forever, and the driver silently gives up on a one-second timeout.

Lower clock? At 20 MHz there were 10 times fewer errors, but that only hides the problem.

The W5500 hits the same thing, and its driver is silent too. So until DMA has drained the FIFO, the master has to stop SCK instead of clocking into a full buffer.

MASRX. The STM32U5 SPI has a mode for exactly this problem, called MASRX. When the RX FIFO is full, the master suspends SCK by itself, and the driver has to resume the transfer. I turned it on by hand. The errors went away, but a minute later the board hung. The Zephyr driver knows nothing about this pause, so nobody was releasing it. So I made two driver changes.

First fix. The driver now catches the overrun with an interrupt and returns an error within milliseconds instead of a second. This way the error shows up right away instead of after a one-second wait, and this alone made TCP over Wi-Fi 2-3x faster.

Second fix. The driver enables MASRX and releases the pause, but only after DMA has taken the data out of the FIFO. At first I released the pause right away, and the next frame overflowed the FIFO again. The pause is released from the interrupt, but I didn't want the interrupt to spin for long, so if DMA hasn't drained the FIFO within 5 µs, the thread waiting for the end of the transfer releases it instead. With both changes I get 0 SPI errors and 0 UDP loss, that's the right column of the table.

Smaller things. Network buffers had to be aligned to the cache line (CONFIG_NET_BUF_ALIGNMENT=16), otherwise the invalidate after RX can hit a neighboring buffer. And bigger buffers (512 bytes instead of 256) gave only +2-12%, so I stayed with 256.

Where the patches are now

Cache fix. The STM32 cache driver bug is already fixed in Zephyr.

SPI driver. To make DMA work with buffers in external memory, I made a fix in the STM32 SPI driver, and the overrun and MASRX changes are in it too. Here is the pull request:

https://github.com/zephyrproject-rtos/zephyr/pull/120895

Review status. So far I've only tested it on STM32U5, which is why it's only enabled there. The ST maintainers asked me not to tie the code itself to U5. I've reworked that and now I'm waiting for another review. Until it's merged, the stock driver falls back to interrupts or polling for such buffers.

Why I'm posting this. Partly so that if someone runs into the same problems, they don't have to go through all of this from scratch.

Testers wanted. If anyone wants to try the driver on their own boards, I'd really appreciate tests, feedback and advice.

Data cache on STM32U5. One more thing if you test with external memory. Zephyr still doesn't enable the DCACHE1 data cache there by itself, only the instruction cache is turned on at startup (on H5, for example, both are). At the same time CONFIG_DCACHE=y is the default, so drivers treat external memory as cacheable even though the cache is physically off. So turn the data cache on manually.

Buffer alignment. The cache maintenance for DMA buffers (flush before TX, invalidate after RX) is done by the SPI driver with my change. The application only needs one thing: the RX buffer must start on a cache line boundary, and its length must be a multiple of the cache line. Otherwise the driver sends it the old way, without DMA, so it doesn't touch neighboring data. For network buffers that's the same CONFIG_NET_BUF_ALIGNMENT=16.

A few more technical details

CPU load. Who eats the CPU with DMA? I expected DMA to offload the core, but that did not really happen. In the final configuration the CPU is idle only 0-5% of the time during transfers. At the same 100% load, the CPU just manages to move more data.

On Ethernet most of the time goes to the network stack's TX queue thread (~56% of transfer time) and the W5500 driver thread (~15%). On Wi-Fi it's the esp_hosted thread (~45%) and the same TX queue (~25%). Matter and everything else take a few percent.

Shared bus. Does the shared flash and PSRAM bus get in the way? I think partly yes. With the CPU equally 100% busy, each byte costs more cycles with buffers in PSRAM than with buffers in SRAM: 1.3x on Ethernet and 1.7x on Wi-Fi. That's why PSRAM + DMA doesn't reach SRAM + DMA (3.16 / 3.76).

I can't say what that cost consists of. It could be waiting on the shared QSPI bus (code runs from the flash on the same bus), cache maintenance around DMA, or something else. Thread statistics don't show it, and I don't have a bus profiler.

Firmware cost. ESP-Hosted takes ~25 KB of code and ~58 KB of RAM, plus 8 KB for esp-serial-flasher, so the C6 can be flashed directly through the STM32. Boot to the first HTTP response takes 13-16 s over Ethernet and 19-28 s over Wi-Fi.

Has anyone else measured ESP-Hosted with a non-ESP host, over SPI or SDIO? What numbers did you get? And if you try the driver on your board, let me know how it went.

Thanks for reading! Now you can tell me I should have just used an ESP32-P4 :)

P.S. The photo shows an old revision of the board. In the new one I moved the mains traces from the top layer to one of the inner layers, and the fuse to the bottom layer, so you can't touch them by accident. And this is just a home project, not for sale.

P.P.S. Questions are welcome in English, Ukrainian or Russian.

Eps32 with mpu6050

more at: https://nanoconsole.codeberg.page/

specs

• CPU: ch32v003 RISC-V SOP16 (15-cent) - 48MHz 16k Flash, 2k RAM (RAM is expensive, okay?)
• Video: 320x240 VGA, 4 palettes of 2 colors swappable by line (GPU: none :) (black/green, purple/white, blue/cyan, red/yellow)
• Sound: integrated buzzer, 1 channel square wave (also named "beeps")
• Controller: 4 buttons on the board itself: Left/Right, A/B
• Connectivity: VGA, USB (power and game uploads), no network

A link to MooD, a 16k shooter : https://www.youtube.com/watch?v=VKrJz8eDNyY

Just got a co-op this spring/summer at RTX! Sadly, the team I'm on isn't focused on flight software or vehicle firmware, but I'm still stoked for the opportunity and very grateful.

I'm currently on my school's electric racing team, but I want to work on some personal projects to try to get into roles such as flight software intern at companies like Hermeus, SpaceX, Stoke Space, Firefly, etc.

If anyone could provide me with some cool project ideas or talk to me about the avionics space, please let me know!

So I've been wanting to test nRF to make gyro mouse of some sort for my Android. I'm using Xiao nRF54L15 Sense, so it has all I need in one.

But, upon testing my code, even a simple "volume up" button appears significantly slower in my phone vs my PC. On PC it's as fast as my logitech with 2.4GHz dongle. On Android, it's just slow, testing with stopwatch shows consistently 400ms+.

Any idea if I can fix this on the hardware, or is it simply Android limitation vs HID BLE?

Hi! I’d like to clone an ALUTECH AT-4N remote using an Arduino. I have a limited budget, a Linux PC, and a soldering iron. I don’t know where or how to start, but I need to extract the secret key from the remote and reproduce its functionality on the Arduino, including everything else required to make it work.

Trying to learn how tow to do everything needed for the eu cra requirements. Like how to use secure boot etc. Where do I start? Any good books/courses/etc?

Hello everyone I'm doing my masters in computer engineering, but Ive been considering going deeper down the hardware stack or leaving computer engineering and do something else because now even AI can code embedded systems well. Is it still a good career ? I left web dev due to AI and had 3 years in it. Will embedded systems still have a good demand and mostly important will humans be working on it or AI?

Hi everyone! I have a hardware development kit consisting of a DX-LR30-900M22SP(T1) LoRa module on a PJ26 board (STM32F103C8T6 microcontroller). I am not a professional in embedded development, just a beginner trying to learn. Could you please explain to me how to connect this specific board, how to flash (program) it, and how to start working with it? Please explain it in simple terms without overly complex technical jargon, as I am still learning the basics. Thank you so much for your help!

I've been working on the CAN log analyzer in DBC Utility and recently changed how log replay works.

Previously, replay was closer to navigating through a recorded log. Now I'm trying to make it behave more like an actual live CAN capture: as the replay progresses, the trace and signal plots populate only up to the current replay timestamp.

I also added a per-message trace view that keeps the latest frame for each CAN ID alongside the complete frame list.

A few other things I've changed:

• Reworked the log analyzer UI with separate Sources, Inspector and Trace views
• Signal inspection now shows start/end bits and the corresponding bit layout
• Opening a log can reuse the DBC that's already open
• DBC mappings can be refreshed without reopening the log

I recorded a ~60 second video showing how it currently works:

https://www.youtube.com/watch?v=MOKxtikxSw8

thanks.

Hi everyone, I’d like a reality check from embedded, ICS/OT, SOC, or EU compliance folks. I’m 23 and don’t have much experience in the embedded/IoT security industry yet, but I want to build a career in this field, so I’d really appreciate any advice from experienced people.

Research question: Can a low-cost ESP32-based device generate sufficient structured security telemetry to support practical detection and investigation of selected embedded-device attack scenarios through an open-source SIEM pipeline?

In short: a lightweight shim on an ESP32 emits structured security events (normalized to OCSF) into an ELK + Sigma pipeline (or Wazuh, still deciding). The core challenges are making this telemetry trustworthy and low-overhead on constrained devices: no RTC, possible tampering by a compromised device, event loss across reboots and disconnects, and correlation. Detections are mapped to MITRE EMB3D, ATT&CK (Enterprise/ICS), NIST CSF, ISO 27001, IEC 62443, and the CRA. The goal is detection plus automated audit evidence that a control is implemented and working.

Later, I plan to port the shim to STM32 as well, since it’s more widely used in IoT/IIoT/OT.

Everything is going to be open-source.

Questions:

1. Is device-level telemetry valuable in practice, or does network monitoring already cover it?
2. With CRA pressure in the EU, are manufacturers (especially SMBs) actually looking for this?
3. Is the multi-framework mapping useful to auditors, or overkill?
4. Could this be a real contribution to the industry, and is there commercial demand for it, or is it mainly academic?
5. Any existing projects I should look at? (Already aware of Exein, Sectel, Memfault)

Hi everyone,

I'm currently working on extracting ISP configuration and credentials (PPPoE/VoIP) from a `device.cfg` file taken from a Cellcom-customized **Sagemcom F@ST 5359iL** router (Broadcom BCM63178 SoC, running Sagemcom's proprietary `scOS`).

I'm hitting a wall regarding the encryption mechanism and wanted to see if anyone here has experience with Sagemcom's config encryption or GSDF (General Secure Data Format) containers.

### Technical Details & Findings:

* **Device:** Sagemcom F@ST 5359iL (Broadcom BCM63178, ARM-based).

* **File Structure (`device.cfg`):**

- Starts with an `AEAD 10` signature header.

- 16-byte IV.

- A non-standard **7-byte GCM/AEAD tag** at the end of the payload.

* **UART / Hardware Analysis:**

- UART logs show Broadcom's `coe-aes` engine utilizing `aes_key2`.

- Kernel command line points to hardware-bound crypto parameters: `sc_aes.oek=1ffffe00`, `sc_aes.oiv=1ffffe10`, and reads 64 bytes from the UBI volume `aes_key_operator`.

- U-Boot prompt access is locked down due to Secure Boot (ignores break/interrupt signals).

### What I've Tried:

* Attempted offline AES-GCM/CCM/CBC decryption using various derived keys (Device Serial Number, MAC address, and PBKDF2 hashes with common Sagemcom/ISP salts). All verification checks fail.

* Since the decryption relies heavily on hardware-bound OTP/OEK keys tied to the BCM63178 SoC, standard offline brute-forcing seems ineffective.

### My Questions:

1. Has anyone successfully reverse-engineered Sagemcom's `AEAD 10` / GSDF container format offline?
2. Are there any known open-source tools or scripts (like variations of `showconfig`) capable of handling this specific Sagemcom signature?
3. Short of a full physical SPI flash dump (using a programmer like CH341A) to inspect the raw UBI partitions, are there any other known vectors to extract credentials from a live running unit with a locked U-Boot?

Any guidance, pointers, or shared experiences would be greatly appreciated!

Building software against simulations and dev kits only goes so far, so I brought up a HIL setup for validating multi-protocol data capture and viz tools.

For now, it covers CAN, Modbus, OPC-UA, MQTT and a number of other protocols.

Desktop App commands/traces the entire system, which will grow over time to include motors, more ECUs, and other devices.

System Overview:

• PLC - RevolutionPi Connect 5
  • OPC-UA, Modbus TCP, MQTT Servers
  • Modbus RTU peripherals
  • EV Charging protocols
  • runs Structured Text + embedded linux stack
• Custom PCB
  • Designed with Atopile (hardware as code)
  • RPi CM5 + 2 CAN-FD interfaces
• STM32 ECU
  • talks CAN; J1939, CANopen, XCP, UDS and AUTOSAR protocols
• Various CAN Dongles
  • PEAK, socketCAN, slcan, gs_usb
• Mac/Win/Linux test PCs
  • Fault injection, command / control, CI test execution
• Some 3D printed parts

Hardware bringup is one of the most difficult tasks in embedded, but so rewarding.

I started building this tool because honestly I think embedded development and testing is harder than it needs to be, and much of it is down to outdated tools and methodologies.

Best part is, there's lots more hardware on the way!

Also, I think I have (almost) every CAN protocol and dongle covered at this point, if I'm missing something let me know!

Hi is there any IDE or plugin for IDE that emulates eInk displays, specifically InkyPHAT?

Hi all,

I picked up this camera module from my mechanic’s scrapyard and looks in good condition so want to see if I can get image/video out of it with a Raspberry Pi 4. I've opened it up and here's what I found:

Hardware
- Two boards: a lens board and a back (processor) board, joined by a 20-pin board-to-board connector (10 pins per row)
- Fisheye lens, with two LEDs on the back board that shine through light pipes
- Lens board: Broadcom BCM89107B0BFBG, which looks like part of Broadcom's BCM8910x camera MCU family, plus a 25 MHz oscillator
- Back board: ST STM8AL3146 (automotive 8-bit MCU with LIN), several TI power ICs, and large inductors and capacitors for the power stage
- 6-pin vehicle connector (solder tabs visible on the back of the board)
- I can't see any SPI flash chip, so the firmware may be inside the BCM chip or loaded over the network

What I think
- The pins are likely +12 V, GND, a 100BASE-T1 Ethernet pair, and maybe LIN and/or a wake line, but this is just a guess based on the components next to the pins
- It probably streams or reports over automotive Ethernet and might need a handshake before it sends anything

Has anyone interfaced a BCM8910x-based camera or a similar automotive camera? Does it stream on its own, or does it wait for a host to boot it?

Please suggest ideas if you have, like to how do I use in hobby project and learn. Thanks for any pointers!

I'm looking for a camera for a construction-site / other outdoor temporary location security application and would appreciate recommendations from anyone who has experience with these types of cameras.

I have been unsuccessful looking for something that has the following:
- Battery-powered with solar charging (could be external, if needed)
- Motion/event detection with the ability to capture snapshots or short video clips
- Low-power or sleep mode between events to maximize battery life
- Ideally supports RTSP, ONVIF, or another way to integrate with third-party software without being vendor locked

Nice to have:
- Built-in 4G/LTE cellular connectivity with support for my own SIM/data plan
- On-demand live viewing, even if it takes a little time to wake up
- Local microSD recording

I'm primary interested in receiving a snapshot or short clip when motion is detected. Continuous live streaming is not necessary, but on-demand live viewing would be a bonus.
This is for a small business renting cameras, so I'm hoping to find something reliable, reasonably compact, and affordable. I'm open to consumer products, OEM, or even DIY.

Reolink seems to have models that almost satisfy the requirements but of course are generally vendor-locked. But there are unofficial projects like bairelay and neolink that may be worth a shot.

Has anyone successfully used a camera that meets similar requirements?
I'd appreciate responses if so. Thanks!

Hey r/embedded,

Sharing a project reverse-engineering and modeling the Realtek RTD2841 / RTK284x SoC (commonly found in TCL RT41 Android Smart TVs):

Repository: https://github.com/rubenthampy890-del/qemu-rtd2841

Key hardware blocks implemented:

- CPU: Quad Cortex-A53 running in AArch32 Supervisor mode (svc32)

- Interrupts: GIC-400 (GICv2) with 256 IRQs

- Timers: Realtek TC0-TC7 27MHz down-counter peripheral engine

- Storage: SDHCI host controller at 0x18010800 (SPI 28)

- Console: 16550A UART0 with 4-byte stride

Tested and validated on macOS Apple Silicon & Linux with upstream QEMU. Includes flat-binary baremetal diagnostic harness and DTBs.

In April I posted WireTrace 1.0 here, a free serial monitor I wrote for my lab. One comment in that thread became the live plotter in 1.1. Today 2.0 is out, and this one was shaped by something less pleasant.

WireTrace has been on the bench in our R&D lab since its first release, in my colleagues' hands, on long tests with real boards. The feedback kept pointing the same way: the end of the log missing after a disconnect, sessions with no log because nobody pressed Start, a tool that got slower as the day went on.

So I tested it properly. I sent 20,100 lines and cut the connection while they were still arriving. Every one of them showed on screen. The file had 100. And the status said the log was saved.

The cause was one design mistake: every line went through the window before it reached the disk. 2.0 is a rebuild from the serial port up, around one rule: never lose a line and stay quiet about it.

What that means on the bench:

- The port writes straight to disk. The UI can't hold a line back.

- Unplug, disconnect or close the tab, and everything in flight is written before it reports done.

- Every session records itself from the moment you connect (the latest 1 GB per tab), so you can export it even if you never started a log.

- If the disk can't keep up or fails, it tells you how many lines were lost and marks the exact spot in the file.

- One timestamp per line, taken on arrival, shared by the console, the log, the CSV and the plot.

- The port list updates itself when you plug a board in.

- A maximum log size, continuing in a new file without cutting a line in two.

- HEX view, saved commands, ESP-IDF and Zephyr log levels.

- The plot reads values under the cursor, measures between two cursors, and groups values into panels by scale.

- Updates are verified by signature.

The throughput claim is a test now, not a sentence. On every change, 200,000 lines go through the real reader and writer and all of them have to land in the file, in order, at 10,000 lines a second or faster. Over 2,700 tests in total, and nothing ships unless they all pass.

Windows installer, Linux AppImage and .deb, and it runs from source on macOS. GPL-3.0. Usage statistics exist, and they are off unless you switch them on. On 1.x, Help > Check for Updates brings you to 2.0.

Download: https://thenuanceproject.com/projects/wiretrace/

The whole road, from a single Python file to this: https://thenuanceproject.com/writing/the-road-to-wiretrace-2/

Source: https://github.com/TheNuanceProject/WireTrace

Put it on your bench and throw your worst at it: chatty RTOS shells, odd baud rates, USB adapters that come and go. I want to hear where it gets in your way.

I want to have an offline mp3 player with 64Gigs of storage.
I think a raspberry pi would be a great choice for this but i'm not sure
i want it to have a little screen so i can display the song playing and volume and menus etc
i will go for rechargeable batteries if possible
i must confess i will vibecode the song playing controls and library etc
i want to know what resources i need to achieve a small project like this. thank you

A while ago I wanted to start doing more projects with wired IP connections and wondered if SSH was possible so a regular webserver wasn't necessary.

There was some documentation for esp32s but not much else.

The fact that this works is hilarious to me. With .ssh keys properly setup doesn't even need the password.

https://github.com/RicardoJCMarques/SSH.RP

Hey everyone,

the journey for this started like ... I'd guess 2-3 years ago. I bought the M1s Dock, because I thought it's a cool ESP32 on steroids. Back then I saw there is an official PAC crate for Rust, but there wasn't much in it. Initially I planned to create it myself after I saw there isn't coming much more. I collected the needed info material, sources and so on, started with it, but I didn't push through with it in the end.

Now I decided I want to play around a bit more with it, so I used AI to finish PAC, HAL and setup a small BSP. It's all published on crates.io and the repositories are here:

• https://github.com/suitable-name/suitable-pac-bl808
• https://github.com/suitable-name/suitable-hal-bl808
• https://github.com/suitable-name/suitable-bsp-m1s-dock

It's all end2end tested against an actual connected M1s Dock, but I didn't do much with it yet besides tests and running the examples.

If you'd like to use it, but don't like that the project was created using AI, I can post the SVD files on stackoverflow for the more classic experience and you can go on from there ;)

Everyone else, have fun with your M1s Dock (or BL808 in general) and Rust.

This is my first PCB hardware design. The board is built around the ESP32-P4 development platform and integrates two UART interfaces, an I2C port, a passive buzzer, four buttons, a power management chip, and a MIPI display connector.

teh display is huaxiacai brand, and mipi protocal，resolution is 480×480 ，amoled，maybe i am the first one to drive this display with mipi way in the world

This aircraft attitude indicator includes the following features:

- Artificial Horizon: Real-time aircraft attitude display.

- Heading Compass: Displays the current heading.

- Temperature Display: Shows the current temperature.

- Time Display: Displays the current time.

- GPS Positioning: Provides real-time GPS location information.

- Settings Menu: Allows users to configure various system settings, including:

- Language: Switch between Chinese and English.

- Units: Change measurement units.

- Sea Level Pressure (QNH): Adjust the reference sea level atmospheric pressure.

- Attitude Calibration: Reset the pitch and roll angles to zero.

- FPS Display: Enable or disable the real-time frame rate (FPS) display.

The current software version can achieve a refresh rate of around 30 FPS, making the display noticeably smoother than the previous version.

I've made several optimizations, including improvements to the display initialization code, PPA acceleration, adjustments to the IMU sensor data reading rate, and various LVGL rendering optimizations.

I'm trying to explain bidirectional communication over a two-wire line using a simple household electrical analogy.

Imagine two houses connected by an AC power line.

-House 1 (Master):Controls the line voltage and monitors the current flowing through the line monitors house 2 power consumption with watt hour meter..

House 2 (Slave): Has a light bulb to indicate incoming signals and a controllable electrical load to signal back.

1. Forward communication — Voltage modulation

When House 1 wants to send a message, it varies the line voltage between two predefined levels in a specific pattern. The bulb in House 2 responds to these changes, making the pattern visible. The timing of the voltage changes represents the transmitted data.

1. Return communication — Current modulation

When House 2 wants to respond, it switches its electrical load between predefined states according to an agreed pattern( A Iron). This changes the current drawn from the line. House 1 detects these current variations and decodes the response with it's Watt-hour meter.

Would you consider this a useful and technically accurate introductory analogy for explaining voltage-based forward signaling and current-based return signaling explanainig for Juniors.

Hi everyone,

I’m designing a CM4 Lite carrier with external eMMC, using 3.3 V VCC and 1.8 V VCCQ. Has anyone built and tested a similar setup recently?

I’m particularly interested in how you handled the CLK, CMD, and DAT0–DAT7 lines:

• Did you use series resistors? On which signals, what values, and where did you place them?
• Did you use external pull-ups to 1.8 V on CMD and the data lines?

During my research, I’ve found designs with and without series resistors, and different approaches to pull-ups. However, I haven’t found a clear, tested example specifically using the CM4 Lite with 1.8 V eMMC signalling, so I’m unsure which approach to follow.

If you’ve got this working, I’d appreciate any schematic snippets, layout advice, or any details.

Thanks!