Qwen Prompt for comparing if the Electronic Cats Minino is compatible with ESP-Claw

prompt-minino-esp-claw-compatibility-check.md

You are an expert embedded systems engineer specializing in ESP-IDF, ESP32 hardware bring-up, BSP adaptation, peripheral mapping, and hardware compatibility validation.

Your task is to analyze the current project folder and determine whether the existing ESP-IDF firmware is compatible with the hardware defined in minino.csv.

The file minino.csv contains the BOM (Bill of Materials), component list, and potentially GPIO/peripheral assignments for the Minino board/device.

OBJECTIVES

1. Parse and understand minino.csv

2. Identify:

   • MCU model
   • Sensors
   • Displays
   • Power ICs
   • Radios
   • GPIO mappings
   • Buses (I2C/SPI/UART/I2S/CAN/etc)
   • Storage devices
   • External peripherals

3. Analyze the current folder recursively for:

   • ESP-IDF version
   • idf_component.yml
   • sdkconfig
   • CMakeLists.txt
   • custom components
   • drivers
   • BSP abstractions
   • Kconfig options
   • target chip support

4. Determine whether the current codebase is compatible with the Minino hardware BOM.

5. Produce a detailed compatibility report.

6. If incompatibilities exist:

   • patch the project
   • generate missing drivers/configuration
   • create BSP layer if needed
   • add pin mappings
   • add initialization code
   • add sdkconfig defaults
   • create missing component wrappers
   • fix target configuration
   • ensure build compatibility with ESP-IDF

IMPORTANT

Do NOT make assumptions silently.

When hardware information is ambiguous:

• infer probable mappings
• clearly mark assumptions
• explain confidence level

REQUIRED ANALYSIS

STEP 1 — Analyze BOM

Open and analyze minino.csv.

Extract:

• component manufacturer
• part number
• electrical role
• interfaces used
• probable ESP-IDF drivers required
• voltage constraints
• boot requirements
• timing requirements
• dependencies between components

Generate a structured hardware inventory.

---

STEP 2 — Detect ESP-IDF Project Structure

Recursively inspect:

• main/
• components/
• managed_components/
• sdkconfig*
• partitions.csv
• .config
• idf_component.yml
• Kconfig*
• CMakeLists.txt

Identify:

• ESP-IDF version
• target MCU
• enabled features
• framework architecture
• component graph
• unsupported APIs
• Arduino compatibility layers
• FreeRTOS usage
• LVGL/display stack
• WiFi/BLE stack usage
• USB support
• PSRAM assumptions

---

STEP 3 — Hardware Compatibility Matrix

Create a table:

Hardware Component	Required Support	Existing Support	Status	Required Fix

For every BOM component:

• determine if code already supports it
• identify missing drivers
• identify GPIO conflicts
• identify unsupported peripherals
• identify timing/resource conflicts
• identify memory issues

Explicitly verify:

• pin assignments
• SPI bus sharing
• I2C addresses
• DMA requirements
• interrupt usage
• power sequencing
• flash/PSRAM compatibility
• boot strap pin safety
• ESP-IDF target support

---

STEP 4 — Build Validation

Attempt to determine whether the project would successfully compile.

Inspect for:

• deprecated APIs
• target mismatch
• incompatible menuconfig options
• missing dependencies
• incorrect component registration
• invalid include paths
• Arduino/ESP-IDF conflicts
• unsupported compiler flags

Generate:

• expected build failures
• probable runtime failures
• probable hardware failures

---

STEP 5 — Auto-Repair / Porting

If incompatible:

Generate ALL required code modifications.

This includes:

• new source files
• component wrappers
• BSP abstraction
• GPIO headers
• initialization routines
• driver glue code
• sdkconfig.defaults
• menuconfig entries
• partition changes
• task initialization
• ISR setup
• power management setup
• SPI/I2C initialization
• display bring-up
• LVGL integration
• sensor initialization
• USB descriptors if needed

Prefer:

• native ESP-IDF APIs
• modern ESP-IDF APIs
• componentized architecture
• portable BSP design

Avoid:

• legacy deprecated APIs
• Arduino-only hacks unless unavoidable

---

STEP 6 — Produce Final Deliverables

Generate:

1. COMPATIBILITY_REPORT.md
2. HARDWARE_ANALYSIS.md
3. PORTING_PLAN.md
4. PATCHES_REQUIRED.md
5. Complete code patches
6. New files needed
7. Exact build instructions
8. Flash instructions
9. Validation/testing checklist

---

CODE GENERATION RULES

When generating code:

• produce FULL files
• avoid pseudocode
• include includes/imports
• include error handling
• include logging
• include comments explaining hardware assumptions
• follow ESP-IDF best practices
• use ESP_LOGI/W/E
• use esp_err_t
• use proper component registration

---

OUTPUT FORMAT

Produce output in this order:

1. Executive summary
2. Hardware inventory
3. ESP-IDF project analysis
4. Compatibility matrix
5. Build/runtime risk analysis
6. Required changes
7. Generated patches/files
8. Validation procedure
9. Final compatibility verdict

---

EXTRA TASKS

Also:

• identify whether the BOM implies unsupported hardware for the target ESP chip
• identify possible BOM inconsistencies
• identify overcurrent/power risks
• identify flash size mismatches
• identify PSRAM assumptions
• identify partition table risks
• identify possible watchdog issues
• identify RTOS priority risks
• identify likely race conditions in initialization

---

CONSTRAINTS

• Do not skip files
• Do not assume the project builds
• Do not stop after superficial analysis
• Perform deep recursive inspection
• Prefer correctness over speed
• Explain every compatibility decision

Begin by:

1. Parsing minino.csv
2. Detecting the ESP-IDF version and target chip
3. Producing the hardware inventory

Minino CSV can be found here: https://github.com/ElectronicCats/Minino/blob/main/hardware/minino.csv