KiCad 10: quando il PCB diventa arte

Se avete mai progettato un PCB abbastanza complesso saprete certamente che arriva un momento nel quale il mouse smette di essere lo strumento più intelligente a disposizione. Posizionare a mano dieci componenti va benissimo, posizionarne cento secondo una geometria precisa comincia già ad essere un altro mestiere, mentre matrici di LED, anelli concentrici, antenne RF, strutture ripetitive oppure statori per motori brushless sono esattamente il tipo di progetto nel quale continuare a trascinare footprint uno alla volta significa chiedere ad un essere umano di fare ciò che una formula sa fare molto meglio. KiCad 10, rilasciato nel marzo 2026 ed ormai arrivato ad una maturità che rende quasi riduttivo chiamarlo semplicemente software di disegno elettronico, permette di affrontare il problema in un altro modo: una parte del PCB può diventare CODICE, realizzando di fatto un concetto ormai dominio degli strumenti altamente professionali, ovvero il PCB come oggetto programmabile. In KiCad 10 esiste ancora la console Python integrata nel PCB Editor e, importando il modulo pcbnew, possiamo ottenere un riferimento alla scheda attualmente aperta con pcbnew.GetBoard(), cercare footprint per reference, modificarne posizione ed orientamento e poi aggiornare l'interfaccia. È, per così dire, una vista programmabile della struttura interna della board: invece di dire al mouse dove mettere D7 possiamo dire al software quale relazione geometrica deve esistere fra D1, D2, D3 e tutti gli altri componenti, lasciando che siano trigonometria ed algoritmi a produrre le coordinate.

Qui però c'è una precisazione importante, perché proprio con le versioni recenti KiCad sta cambiando pelle anche sul fronte dell'automazione. Il modulo pcbnew utilizzato dagli script storici è basato sulle binding SWIG ed è DEPRECATO da KiCad 9, anche se in KiCad 10 continua ad essere presente e perfettamente utilizzabile; il progetto ha già indicato KiCad 11 come punto di rimozione, mentre per i nuovi plugin la direzione consigliata è la IPC API, accessibile da più linguaggi, con kicad-python come binding Python ufficiale. Quindi l'esempio qui sotto ha senso ed oggi funziona proprio sulla serie 10, ma se state iniziando adesso un sistema destinato a vivere per anni conviene già conoscere la nuova API. Immaginate ad esempio di avere dodici LED con reference da D1 a D12 e di volerli disporre su una circonferenza perfetta da 20 millimetri di raggio, centrata alle coordinate 100,100 mm. A mano si può fare, naturalmente, ma il punto è che NON HA MOLTO SENSO farlo a mano quando la geometria è già una formula. Dalla console Python del PCB Editor possiamo scrivere:

BLOCCO0

Il risultato non è soltanto che abbiamo risparmiato qualche minuto. La differenza vera è che la disposizione è diventata RIPRODUCIBILE. Se domani il raggio deve passare da 20 a 27,5 millimetri non spostiamo dodici LED, cambiamo un numero; se diventano 24 cambiamo num_leds, se dobbiamo ruotare l'intero anello aggiungiamo un offset angolare, se vogliamo creare due corone concentriche trasformiamo quello che prima era un lavoro grafico ripetitivo in un problema parametrico. È questo il punto interessante dell'automazione dentro un EDA: non serve soltanto a fare più velocemente la stessa cosa, permette di DESCRIVERE LA REGOLA che genera il layout.

Lo stesso ragionamento si presta benissimo alle matrici, alle disposizioni polari, ai componenti distribuiti lungo una curva, ai pattern ripetitivi oppure ai footprint che devono mantenere distanze e rotazioni matematicamente coerenti. Ovviamente non significa che Python possa sostituire il progettista PCB, perché una formula non decide da sola ritorni di corrente, integrità del segnale, accoppiamenti, dissipazione oppure vincoli RF; significa invece togliere al progettista la parte meccanica e ripetitiva lasciandogli quella nella quale serve davvero giudizio.

kicad-cli: quando KiCad esce dall'interfaccia grafica

L'altro pezzo molto interessante è kicad-cli, ovvero l'interfaccia a riga di comando ufficiale. Qui non stiamo più automatizzando soltanto il posizionamento dentro una sessione grafica, stiamo trasformando KiCad in un componente di una pipeline. Da terminale possiamo lanciare il DRC, esportare Gerber, file di foratura, PDF ed altri formati di fabbricazione, generare output 3D ed eseguire operazioni senza aprire manualmente il progetto nel PCB Editor.

Per chi usa GitHub, GitLab oppure un proprio server CI il salto è notevole perché il progetto elettronico può cominciare ad essere trattato molto più come trattiamo da anni il software. Ad ogni push oppure commit significativo una pipeline può aprire i file di progetto, lanciare automaticamente il DRC, fermarsi se compaiono violazioni ed alla fine produrre gli artefatti destinati alla fabbrica. Invece di avere sul desktop una cartella chiamata gerber_finale_vero_ultimo2, possiamo fare in modo che i file di produzione nascano SEMPRE dalla revisione esatta che ha superato i controlli.

Ed è qui che secondo me KiCad diventa particolarmente interessante anche per piccoli laboratori e maker evoluti, perché CI/CD (Continuous Integration/Continuous Delivery) applicata all'elettronica non significa trasformare un circuito stampato in software, significa applicare allo sviluppo hardware una disciplina che nel software ha già dimostrato di funzionare: sorgenti versionati, controlli ripetibili, output generati automaticamente e meno spazio possibile per l'errore umano dell'ultimo minuto.

Se avete già decine di script pcbnew non c'è nessun motivo per buttarli domani mattina, KiCad 10 li supporta ancora. Ma per un nuovo progetto conviene capire la IPC API perché risolve proprio uno dei limiti storici delle binding SWIG: invece di essere una traduzione molto diretta delle classi C++ interne, l'IPC espone un'interfaccia più stabile attraverso la quale un processo esterno può parlare con una sessione KiCad in esecuzione. Il progetto ufficiale kicad-python fornisce poi un'interfaccia Python più adatta allo sviluppo moderno.

Questo passaggio è importante anche concettualmente. Se voglio costruire un plugin che genera array geometrici, un sistema che dialoga con un configuratore di prodotto oppure un tool esterno che modifica la board sulla base di dati provenienti da un altro software, non devo più ragionare necessariamente come se il mio script fosse infilato dentro agli oggetti C++ dell'editor. Posso trattare KiCad come un'applicazione dotata di una vera interfaccia di automazione, mantenendo più separati il programma che decide e quello che modifica il progetto.

Poi c'è l'ultimo livello, quello che difficilmente troviamo in molti EDA professionali: KiCad è open source ed il suo codice sorgente è disponibile. Il progetto è scritto prevalentemente in C++, utilizza wxWidgets per una parte fondamentale dell'interfaccia grafica ed usa CMake per la configurazione della build, quindi chi abbia davvero necessità particolari può arrivare a compilarsi una propria versione, modificare comportamenti non esposti dalle API, sperimentare funzioni a basso livello oppure disabilitare in fase di build ciò che non serve ad una determinata macchina o distribuzione.

Naturalmente compilare KiCad non è la scorciatoia per evitare di scrivere un plugin, anzi è la strada più costosa da mantenere perché ogni modifica locale deve poi convivere con l'evoluzione del progetto ufficiale. Ma il fatto stesso di POTERLO FARE cambia parecchio il rapporto con lo strumento: prima lavoriamo a mano, poi automatizziamo con script, saliamo ancora alla CLI ed alla CI, passiamo alle API ufficiali e soltanto quando tutto questo non basta possiamo arrivare fino al sorgente.

Ed è forse questa la parte più interessante di KiCad 10. Non siamo più obbligati a pensare al PCB come ad un disegno nel quale il progettista muove oggetti con il mouse, possiamo trattarlo come un modello che viene letto, trasformato, verificato e prodotto attraverso codice, mantenendo l'intervento umano dove serve davvero e LASCIANDO ALLA MACCHINA TUTTO CIÒ CHE È SOLTANTO GEOMETRIA RIPETITIVA!