etcheda

• A closed vocabulary. What circuit! cannot say cannot be written. A model gets a grammar and a compiler, not a language to wander in.
• Typed units. A resistor takes 330 ohm. There is no way to hand it 100 nF.
• Parts are types. A board can only name a part with a pin table and a footprint. A pin the part does not have is a compile error with a line number.
• Every problem has a code. The compiler stops at the token that is wrong: an unknown pin, an output on a rail, a role a pin cannot take. The validator reports the rest, a net with one pin among them, each with a code and a line, and etch explain says what to do.
• Parts come later. The program names what the circuit needs: a 330 Ω 0603 resistor, a red LED. etch resolve binds each to something orderable and records it in etch.lock, like a package manager.
• Firmware reads the same file. A role on an MCU pin, gpio_out @ 1 Hz, is firmware intent. etch export hands every pin, net and role to whatever writes the firmware, so the board module comes from the schematic, not from memory.

circuit! {
    name "blinky";

    rails {
        V3V3: power 3.3 V;
        GND: ground;
    }

    parts {
        u1: Esp32Wroom32;               // U1
        r_led: resistor 330 ohm, 0603;  // R1
        r_en: resistor 10 kohm, 0603;   // R2, EN pull-up
        d1: led red, 0603;              // D1
        j1: PinHeader1x6;               // J1, power and flashing
        c_en: capacitor 100 nF, 0603;   // C1, EN delay
    }

    nets {
        V3V3: u1.VDD3P3, j1.1, r_en.2;
        GND: u1.GND, j1.2, c_en.2, d1.K;
        EN: u1.EN, r_en.1, c_en.1, j1.3;
        LED_DRV: u1.GPIO2 as gpio_out @ 1 Hz, r_led.1;
        LED_K: r_led.2, d1.A;
    }
}