First up, this example has a lot of LLM input, so me guiding, reviewing, and writing some code. The documentation is mainly written by the LLM. Stating this up front because I know some people have strong feelings about LLMs. So over to the example. This runs under FreeRTOS which does not understand the split between the two modes. The code makes up two parts M-mode and U-mode code. The idea is to split the firmware into a trusted codebase and an untrusted application. Memory is split between the two side, M-mode code has full access to system resources. U-mode code has restricted access to memory and resources. The example demonstrates how a U-mode application can call functions in the M-mode code via a syscall interface. There are 8 U-mode threads that are not pinned. The code has been tested on the M5Stack Tab5 (ESP-P4 chip version 1.3) and in esp-emu https://github.com/espressif/esp-emulator emulator using chip revision 1.3 and also revision 3. Sample code is here: https://github.com/NevynUK/ESP32-P4-Pro ... ode-Sample I have also written about using the emulator here: https://blog.mark-stevens.co.uk/2026/09 ... -emulator/ . Hoping that this proves useful and feedback is welcome. Regards, Mark
Forum Index of /ext/espressif/stupidbots
esp32.com/ext/espressif/stupidbots ↗Forum phpBB in inglese.
- Discussioni al giorno
- 4
- Discussioni raccolte
- 109
- Messaggi al giorno
- 8
- Sezioni
- 0
- Fonti seguite
- 1
- Motore
- phpBB
Ultime discussioni
Raccolte ogni 4 ore dal feed pubblico del forum. Riproduciamo solo il titolo, il link e l'inizio del messaggio; ogni link rimanda alla fonte.
If your goal is to listen to FM radio, you can use the TEA5767 instead of the RDA5807. With just this module, you can listen to the radio through a speaker.
I finally gave up and returned the pcm1808
I have very little knowledge on this specific topic (close to none), but apparently the MMU on the ESP32 is very simple, it's more like a cache manager . I guess that is the reason (or at least one of them) that some sort of memory protection between cores/threads was never implemented in the ESP-IDF. I've heard the S3 has a more functional MMU and the S31 is the first with a "real" MMU, including real virtual to physical translation (otherwise it couldn't have run Linux...).
ESP-Hosted 2.x will continue to be supported through the release/v2.x branch. As you can see, multiple 2.x releases have been published even after the introduction of 3.x, so 2.x remains a supported release line. For any issues with ESP-Hosted 2.x (or 3.x), please raise them in the ESP-Hosted GitHub issue tracker . This allows us to track and respond to issues more quickly. 2.x support timeline Code: | Calendar timeline | Relative to 3.x | 2.x phase ||-------------------|-----------------|------------------------------------|| Jul-26 – Jan-27 | 0–6 months | Active development & maintenance** || Jan-27 – Jul-27 | 6–12 months | Maintenance || Jul-27 – Jul-28 | 12–24 months | Critical maintenance || Jul-28 onward | 24+ months | EOL | 0–6 months : Bug fixes, compatibility fixes, customer issues, selected development/backports 6–12 months : Maintenance and compatibility fixes; no new features 12–24 months : Critical/customer-blocking issues, security and essential compatibility fixes 24 months : EOL Note: For new developments prefer latest registry component release :
硬件:ESP32-C3 + MAX98357A I2S功放 开发环境:Arduino IDE,esp32板包版本3.3.10(底层ESP-IDF5.x新版I2S通道API) 引脚:BCLK=4,LRC=5,DIN=6 现象: 1. 按键触发playTrack,I2S播放音频,声音正常; 2. 定时任务调用playTrack;串口完整打印:▶ 定时时段,触发自动播放 → ▶ 开始播放 → ■播放结束;但是喇叭无声。 3.定时任务放到按键扫描程序(按键扫描程序和定时播放完全平行,只是在同一个keyscan里),按键按下后,定时任务执行并有声音。 已做排查: 1. 串口日志确认isPlaying标志、音频指针正常赋值; 2. 在playTrack开头增加delay(200ms),问题依旧; 3. 硬件接线确认,功放供电正常,按键播放证明硬件没问题; 最小复现代码: ```cpp //I2S程序 #include "audio_player.h" #include "audio_res.h" I2SClass I2S; volatile bool isPlaying = false; const int16_t* playBuf = nullptr; size_t playTotalLen = 0; size_t playPtr = 0; void i2s_task(void* arg) { int16_t* dmaBuf = new int16_t[DMA_BUF_LEN]; for(;;) { size_t fillSamples = DMA_BUF_LEN; memset(dmaBuf,0, fillSamples*sizeof(int16_t)); if(isPlaying && playBuf != nullptr) { size_t copyLen = fillSamples; if(playPtr + copyLen > playTotalLen){ copyLen = playTotalLen - playPtr; } memcpy(dmaBuf, playBuf + playPtr, copyLen*sizeof(int16_t)); playPtr += copyLen; if(playPtr >= playTotalLen){ isPlaying = false; playBuf = nullptr; playTotalLen = 0; playPtr = 0; Serial.println("■ 播放结束"); } } I2S.write((uint8_t*)dmaBuf, DMA_BUF_LEN*sizeof(int16_t)); } delete[] dmaBuf; } void i2s_init_hw(void) { I2S.setPins(I2S_BCLK_PIN, I2S_LRC_PIN, I2S_DIN_PIN, -1, -1); I2S.begin(I2S_MODE_STD, SAMPLE_RATE, I2S_DATA_BIT_WIDTH_16BIT, I2S_SLOT_MODE_MONO); xTaskCreate(i2s_task, "i2s_task", 4096, nullptr,5, nullptr); } void playTrack(int idx) { if(idx = AUDIO_TOTAL_CNT) return; // =====删掉下面两行===== // while(isPlaying){
Worth flagging that this old thread links to a bit-banged driver (feelfreelinux/ds18b20), which is exactly the approach that runs into trouble on the ESP32 family now. On newer chips - the C-series RISC-V parts (C3, C5, C6) in particular - toggling GPIOs directly from a loop with ets_delay_us-style waits is unreliable, because GPIO-matrix and critical-section overhead eats into the microsecond budget 1-Wire needs for its reset/read/write time slots. The original poster's problem (DallasTemperature/OneWire not compiling on ESP32) has essentially recurred one level down, in native IDF code rather than Arduino. Since this is pure ESP-IDF (no Arduino), the fix doesn't need a UART workaround or third-party bit-banging code at all: Espressif publish an official onewire_bus component (onewire_bus.h / onewire_bus_impl_rmt.h, available via the IDF component registry) that generates the reset/read/write timing entirely in hardware using the RMT peripheral. It takes a single GPIO, runs the standard Maxim/Dallas ROM search (AN187) and reset/read-bit/write-bit primitives on top of it, and is maintained alongside the rest of IDF, so it tracks new chip support (C5/C6 etc.) rather than depending on whatever GPIO-register access happened to work on the original ESP32. I ended up building on exactly this component for a related ESP32-C5/C6 project (Arduino-based, but the underlying driver is the same IDF code): a thin bus wrapper providing ROM search/diagnostics, with a separate DS18B20 layer
这是配置饱和度的方法,要用 ISP video device: isp_fd = open(ESP_VIDEO_ISP1_DEVICE_NAME, O_RDWR); controls.ctrl_class = V4L2_CID_USER_CLASS; controls.count = 1; controls.controls = control; control[0].id = V4L2_CID_SATURATION; control[0].value = saturation; if (ioctl(isp_fd, VIDIOC_S_EXT_CTRLS, &controls) != 0) { ESP_LOGE(TAG, "failed to set saturation"); } 除此之外 IPA 算法会动态更新饱和度,所以要在配置文件里面把相关的配置去掉,以 sc2336_default_p4_eco5.json 为例: "saturation": [ { "color_temp": 0, "value": 128 }, { "color_temp": 4500, "value": 130 } ],
Hi lova666, 190–200 Mbps 这个测速结果是正常的。我们在内部环境下做 TCP TX 测试,通常也就 ~140 Mbps 左右。 导致这样的测试结果的说明: 以太网 MAC 硬件本身性能是够的,目前的瓶颈主要出在 CPU 处理 IP 协议栈(尤其是 TCP 协议)时的计算开销。如果绕过 IP 协议栈,直接通过 L2 TAP 进行数据帧收发,硬件实际是可以跑到近千兆速率的(除去标准的以太网包头开销)。
Hello everyone, I am working on a classic ESP32 (DevKit V1) and writing a small didactic OS from scratch. I am having some issues with the internal SRAM2 DMMU and PID-based mappings. My goal is to have two processes (PID 2 and PID 3) using the same virtual address space (`0x3FFC0000 - 0x3FFCFFFF`), but backed by different physical pages. With 8 KB pages, I am trying to configure: ```text PID 2: physical pages 0-7 -> virtual pages 0-7 PID 3: physical pages 8-15 -> virtual pages 0-7 ``` For example: ```text DMMU_TABLE0 = 0x20 # PID 2, VA page 0, physical page 0 DMMU_TABLE8 = 0x30 # PID 3, VA page 0, physical page 8 ``` The problem is that PID 2 can access VA page 0 correctly when only `DMMU_TABLE0` is configured. As soon as I configure `DMMU_TABLE8` with the same virtual page but a different PID, PID 2 can no longer access that address. I also tried different PID combinations, with the same result: reusing an already mapped virtual page for another physical page breaks the existing mapping. The TRM says: > "For PID 2 to 7, however, every virtual page can be reconfigured, on a per-PID basis, to map to a different physical page." So I would expect this to be possible: ```text PID 2 + VA page 0 -> physical page 0 PID 3 + VA page 0 -> physical page 8 ``` Is this actually supported by the classic ESP32 DMMU? If yes, is there some additional configuration or restriction required for multiple PIDs to use the same virtual page? Thanks!
# 02 · 模型量化与 KMCU 格式 > English version: **[en/02-quantization-and-kmcu-format.md](en/02-quantization-and-kmcu-format.md)** > **本篇对应源码**:[`tools/convert_minueza.py`]( https://github.com/m13253246268-ship-it ... minueza.py ) · [`main/kmcu.h`]( https://github.com/m13253246268-ship-it ... ain/kmcu.h ) · [`tools/ref_forward.py`]( https://github.com/m13253246268-ship-it ... forward.py ) > 目标:把一个 HuggingFace 的 Mistral 家族小模型转成 MCU 能直接读的量化权重文件, > 并理解这个自定义二进制格式(KMCU v1)的每一个字节。 ## 1. 模型选型 ``` Felladrin/Minueza-32M-Base (Mistral 家族) layers=10, dim=312, heads=12, kv_heads=4, head_dim=26, ffn=1092, vocab=32002 ``` 原始 `config.json` 关键字段(转换脚本据此生成 KMCU 头): ```json { "architectures": ["MistralForCausalLM"], "model_type": "mistral", "hidden_size": 312, "num_hidden_layers": 10, "num_attention_heads": 12, "num_key_value_heads": 4, "intermediate_size": 1092, "vocab_size": 32002, "max_position_embeddings": 2048, "hidden_act": "silu", "rms_norm_eps": 1e-6, "rope_theta": 10000.0, "bos_token_id": 1, "eos_token_id": 32000, "tie_word_embeddings": false, "torch_dtype": "float32" } ``` 架构特性(决定了推理内核要支持什么): - **RMSNorm**(非 LayerNorm,`rms_norm_eps=1e-6`) - **RoPE** 旋转位置编码(`rope_theta=10000`) - **GQA**(12 个 q head 共享 4 个 kv head,`kv_rep = 3`) - **SwiGLU** 激活(`hidden_act=silu`) - **权重共享**:原模型 `tie_word_embeddings=false`(带独立 `lm_head`,共 **32.79M** 参数)。 转换脚本**默认尊重配置**(保留 `lm_head` → 镜像 **18.07 MB**,**装不进 16 MB Flash 的 `model` 分区**)。 本系列全程使用的是 `--force-tie`:**强制 `lm_head` 复用 `tok_embed`**,省下 32002×312 的输出头 → **22
> English version: **[en/01-environment-and-build.md](en/01-environment-and-build.md)** > **本篇对应源码**:[`sdkconfig.defaults`]( https://github.com/m13253246268-ship-it ... g.defaults ) · [`partitions.csv`]( https://github.com/m13253246268-ship-it ... itions.csv ) · [`main/main.c`]( https://github.com/m13253246268-ship-it ... ain/main.c ) · [`CMakeLists.txt`]( https://github.com/m13253246268-ship-it ... eLists.txt ) > 目标:在一台 Windows 机器上,把 ESP32-P4 的 ESP-IDF v6.0.2 开发环境搭起来, > 能编译、烧录并监视 `kestrel_mcu` 项目。**这一篇是复现路上最容易卡住的部分,请完整读完。** ## 1. 硬件与接线 | 项 | 说明 | |---|---| | 开发板 | Waveshare ESP32-P4-WIFI6-DEV-KIT(SKU 32054) | | SoC | ESP32-P4(RISC-V 32 位双核 HP 400 MHz + 单核 LP 40 MHz) | | 内存 | 768 KB L2 + **32 MB PSRAM**(hex 模式 @200 MHz)+ 16 MB NOR Flash | | 连接 | Type-C 接电脑,枚举出 USB 串口(本例为 `COM5`) | 确认串口: ```powershell [System.IO.Ports.SerialPort]::GetPortNames() ``` ## 2. 安装 ESP-IDF(Windows) ### 2.1 拉取源码(用 Gitee 镜像,GitHub 直连常失败) ```powershell git clone https://gitee.com/EspressifSystems/esp-idf.git E:\esp-idf cd E:\esp-idf git checkout v6.0.2 ``` > 关键:工具链下载也要走国内镜像,设环境变量 > `IDF_GITHUB_ASSETS="dl.espressif.com/github_assets"`,否则 GitHub 资源下不动。 ### 2.2 安装工具链与 Python venv ```powershell cd E:\esp-idf .\install.ps1 esp32p4 # 会自动装 riscv32-esp-elf 工具链 + Python 3.12 venv ``` 装完后工具链落在 `C:\Users\ \.espressif\tools\riscv32-esp-elf\...`。 本项目实际版本(实测): ``` 工具链 riscv32-esp-elf 15.2.0 路径 %USERPROFILE%\.espressif\tools\riscv32-esp-elf\esp-15.2.0_20251204\riscv32-esp-elf\ 编译器 ...\bin\riscv32-esp-elf-gcc.exe 反汇编 .
109 discussioni raccolte dal 1 settembre 2026. Segui questo forum con una parola chiave →