This lab walks you through building three Zephyr applications for Sparrow:

• Example 1: UART Shell app with standard commands + a custom I2C scan command
• Example 2: UART Shell app + LittleFS mounted from internal flash (ESP32‑C6)
• Example 3: Wi‑Fi webserver that reads BME680 sensor data and serves it to a browser

Open a terminal in your Zephyr workspace and run:

west --version
west boards | grep esp32c6

If the board is listed and west works, continue.

Tip: If you switch branches or update modules often, use:

> west update

Each lab uses the same basic structure:

<APP_ROOT>/
  CMakeLists.txt
  prj.conf
  src/
    main.c
  boards/
    esp32c6_devkitc_esp32c6_hpcore.overlay
  (optional) Kconfig

Build command used in all labs:

west build -b esp32c6_devkitc/esp32c6/hpcore -p auto .

Flash:

west flash -d build --runner esp32

Monitor serial output:

screen <your_port_name> 115200

Build a UART shell application that includes standard Zephyr shell commands and adds a custom command:

• i2c_scan — scans the I2C bus for responding device addresses

• A booting application with a serial shell prompt like:
  • sparrow$
• Shell commands available (examples):
  • help, kernel, device, log, etc.
• Custom command:
  • i2c_scan

Create a new folder, e.g. sparrow_shell_i2c_scan and add the standard layout:

sparrow_shell_i2c_scan/
  CMakeLists.txt
  prj.conf
  src/main.c
  boards/esp32c6_devkitc_esp32c6_hpcore.overlay

Use a prj.conf that enables:

• UART console
• Shell backend over serial
• I2C subsystem

Put your known-good configuration here:

<PASTE YOUR WORKING Lab 1 prj.conf HERE>

Checklist (ensure these are enabled in some form):

• CONFIG_SERIAL=y
• CONFIG_CONSOLE=y
• CONFIG_UART_CONSOLE=y
• CONFIG_SHELL=y
• CONFIG_SHELL_BACKEND_SERIAL=y
• CONFIG_I2C=y

Your overlay must:

• Set console/shell UART device (if required on your Sparrow setup)
• Configure I2C pins (SDA/SCL) to match Sparrow wiring

Place your working overlay:

<PASTE YOUR WORKING Lab 1 overlay HERE>

Your src/main.c should:

• Initialize shell (often automatic if autostart is enabled)
• Register the custom command handler that scans I2C
• Print results (found addresses, errors, etc.)

Place your working code:

<PASTE YOUR WORKING Lab 1 main.c HERE>

Build:

west build -b esp32c6_devkitc/esp32c6/hpcore -p auto .

Flash:

west flash

Open the serial console and test:

• help
• i2c_scan

Expected: you see a list of detected I2C addresses or “no devices found”.

• If no devices are found:
  • verify SDA/SCL pins match your wiring
  • confirm pull-ups are present (internal/external)
  • verify bus speed matches device capabilities
• If shell doesn’t appear:
  • verify console device selection in overlay (chosen nodes)
  • ensure shell backend is serial and autostarted

Build a shell app that provides a “Linux-like” file navigation experience (as much as Zephyr supports), using:

• LittleFS
• mounted on an internal flash partition
• with fs shell commands enabled

Typical workflow in shell:

• fs mount (or auto-mount at boot)
• ls /lfs
• cd /lfs
• pwd
• create/read files (depending on enabled commands)

Copy Lab 1 project to a new folder, e.g. sparrow_shell_lfs.

Enable:

• file system support
• LittleFS
• flash map support
• fs shell commands

Place your known-good configuration:

<PASTE YOUR WORKING Lab 2 prj.conf HERE>

Checklist (ensure these are enabled in some form):

• CONFIG_FILE_SYSTEM=y
• CONFIG_FILE_SYSTEM_LITTLEFS=y
• CONFIG_FLASH=y
• CONFIG_FLASH_MAP=y
• CONFIG_FLASH_PAGE_LAYOUT=y (often required)
• CONFIG_FS_SHELL=y (or equivalent in your tree)

If your Zephyr tree provides a separate Kconfig symbol for file system shell, keep it enabled as in your working setup.

Your overlay must define a partition in flash. Example concept:

• storage_partition label
• label = “storage”
• a safe region that does not overlap existing partitions

Important: The partition address/size depends on the board’s flash layout.

Place your working overlay:

<PASTE YOUR WORKING Lab 2 overlay HERE>

Your main.c should:

• Create/declare an fs_mount_t with:
  • mount point (example: /lfs)
  • storage dev pointing to flash area ID for storage
• call fs_mount()
• print whether mount succeeded

Place your working code:

<PASTE YOUR WORKING Lab 2 main.c HERE>

Build:

west build -b esp32c6_devkitc/esp32c6/hpcore -p auto .

Flash:

west flash

Test in shell:

• fs (to see available fs commands)
• ls /
• ls /lfs (if mounted at boot)
• cd /lfs
• pwd

Expected: you can navigate the mount point and list directory contents.

• Devicetree error about duplicate partition labels:
  • ensure you only define one storage_partition label
  • don’t copy/paste partition blocks twice
• Mount fails:
  • verify the storage partition exists in build/zephyr/zephyr.dts
  • ensure partition does not overlap other partitions
  • confirm the flash driver and flash map are enabled
• Shell missing fs commands:
  • verify CONFIG_FS_SHELL (and any related symbols) are enabled

Build a webserver that:

• connects to Wi‑Fi (WPA2‑PSK)
• obtains an IPv4 address via DHCP
• reads BME680 sensor data periodically
• serves the latest sensor values to any browser that connects to:
  • http:<device-ip>:<port>/ ==== Important performance note (ESP32 Wi‑Fi memory) ==== Wi‑Fi + TLS stacks can be memory hungry. For a simple HTTP server: * keep responses small * avoid allocating large buffers repeatedly * limit concurrent connections (1 client at a time is fine for a lab) ==== Step 1: Create the project ==== Create a new folder, e.g. sparrow_web_bme680 using the standard layout. ==== Step 2: Kconfig settings (prj.conf) ==== Enable: * networking core * sockets * DHCPv4 * Wi‑Fi mgmt * logging * sensor subsystem + BME680 driver Place your working configuration: <code> <PASTE YOUR WORKING Lab 3 prj.conf HERE> </code> Checklist (ensure these are enabled in some form): * CONFIG_NETWORKING=y * CONFIG_NET_IPV4=y * CONFIG_NET_DHCPV4=y * CONFIG_NET_SOCKETS=y * CONFIG_NET_TCP=y * CONFIG_WIFI=y * CONFIG_NET_L2_WIFI_MGMT=y * CONFIG_SENSOR=y * CONFIG_BME680=y * CONFIG_I2C=y ==== Step 3: Wi‑Fi credentials configuration ==== If your app uses custom Kconfig symbols for SSID/password, include your working Kconfig file and the prj.conf entries. Place your working Kconfig: <code> <PASTE YOUR WORKING Lab 3 Kconfig HERE> </code> In prj.conf, you will typically have: <code> <PASTE YOUR WORKING SSID/PASSWORD Kconfig assignments HERE> </code> > Security tip: Avoid committing real credentials to version control. ==== Step 4: Devicetree overlay (I2C + BME680) ==== Your overlay must: * configure I2C pins for Sparrow * define the BME680 node with the proper I2C address (commonly 0x76 or 0x77) Place your working overlay: <code> <PASTE YOUR WORKING Lab 3 overlay HERE> </code> ==== Step 5: main.c (Wi‑Fi + DHCP + HTTP + sensor sampling) ==== Your application should: * register Wi‑Fi and IPv4 events (optional but very helpful) * trigger scan/connect * start DHCP when Wi‑Fi link is up * poll BME680 and store last sample in a global struct * run a simple HTTP server thread: * accept connection * respond with a plain text or JSON payload Place your working code: <code> <PASTE YOUR WORKING Lab 3 main.c HERE> </code> ==== Step 6: Build, flash, test ==== Build: <code bash> west build -b esp32c6_devkitc/esp32c6/hpcore -p auto . </code> Flash: <code bash> west flash </code> Open serial output and note the printed IP address. From a machine on the same LAN, open: * http:<device-ip>:<port>/

Expected:

• browser receives a response containing the latest sensor values

• No Wi‑Fi logs:
  • raise log level (e.g. default level or module-specific)
  • ensure Wi‑Fi mgmt is enabled
• No IP address:
  • verify DHCP is enabled
  • ensure DHCP is started after link is up
• “memory allocation failed” from Wi‑Fi adapter:
  • reduce concurrent HTTP clients
  • reduce buffer sizes (HTTP response buffer)
  • avoid repeated dynamic allocations in the HTTP thread
  • consider increasing heap pool size only if you have flash/RAM headroom
• Browser connects but gets no response:
  • verify socket calls are using Zephyr’s socket headers
  • verify server binds to INADDR_ANY on the chosen port
  • ensure response includes valid HTTP headers and CRLF

For each lab, record:

• the commit hash or archive name of your working project
• the build command used
• screenshots or logs showing:
  • Lab 1: i2c_scan output
  • Lab 2: ls /lfs and pwd
  • Lab 3: printed IP address + browser response output

Optional: include a short README in each project with:

• wiring notes (SDA/SCL pins, BME address)
• shell prompt and commands
• filesystem mount point
• HTTP port and example URL

rm -rf build
west build -b esp32c6_devkitc/esp32c6/hpcore -p auto .

After build:

• build/zephyr/zephyr.dts

Search for:

• flash0
• partitions
• your storage partition
• your I2C and BME680 nodes

After build:

• build/zephyr/.config

Search for:

• CONFIG_SHELL
• CONFIG_FILE_SYSTEM
• CONFIG_WIFI
• CONFIG_NET_SOCKETS