Problema: in un circuito stampato, quando si sbrogliano le piste di alimentazione, capita spesso di non poterne definire una larghezza univoca: in presenza di vincoli sul surriscaldamento o sulla caduta di tensione si deve imporre una ben precisa larghezza minima. Tali vincoli si scontrano quando la pista risulta troppo larga per determinati componenti (soprattutto qualche ostico SMD!)
Un primo metodo consiste nella gestione manuale: laddove si ha bisogno di percorsi a resistività inferiore si imposta una larghezza più elevata. Chiaramente la net class sarà qui ininfluente e settata ai valori minimi. Il DRC (Design Rule Check) quindi non ha modo svolgere alcuna verifica, visto che la scelta adeguata ricade tutta sull’umano alla progettazione. Chiaramente questo metodo non è pratico quando le dimensioni della PCB crescono, soprattutto se si vuol avere una doppia conferma dei vincoli rispettati.
L’unico modo per poter impostare regole diverse ad un segnale è quello di suddividerlo in segmenti con diverse label, giuntate assieme attraverso dei jumper o net-ties.
Alimentazione “power” e “regular” unite con net tie
A livello di layout, a ciascun jumper si va ad associare una footprint net-tie. CvPCB mette a disposizione un set di impronte preconfezionate che implementano banalmente dei cortocircuiti ed evitano conflitti a livello di DRC (e, come si diceva inizialmente, rendono più agevole il collegamento).
Questo particolare flusso permette anche di controllare con maggiore accortezza le diramazioni delle linee di potenza. Le alimentazioni non andrebbero piazzate a casaccio, pena la perdita di performance di un circuito o il cattivo funzionamento dei suoi componenti. Consideriamo l’esempio di un circuito con due aree: una “maggiormente esosa” in termini di risorse energetiche, l’altra più parsimoniosa e che possibilmente desidererebbe una alimentazione pulita e stabile. Il giunto dovrebbe situarsi il più a monte possibile, così da “isolare” il più possibile le due aree.
Prelievo di tensione a monte, nei pressi di un regolatore di tensione
Si ripropongono gli incontri di elettronica ed open hardware pensati per Marzo e annullati in accordo alle misure di contenimento sanitario.
Visti i recenti sviluppi nell’attività di elettronica e open hardware portata avanti presso il GOLEM negli ultimi tempi, e grazie alla messa in funzione della fresa elettronica e della disponibilità della stampante 3D, è stato pianificato il seguente ciclo di serate a tema.
Scopo delle serate è analizzare il ciclo completo per la produzione di un circuito elettronico, facendo uso solo di strumenti opensource.
16 giugno: Introduzione a KiCAD – prima parte. Si tratta di un software opensource di Electronic Design Automation, ossia di progettazione assistita al computer per circuiti elettronici. KiCAD permette di progettare ogni fase della realizzazione del circuito, dalla sua prima bozza, alla scelta e al posizionamento dei componenti, allo sbroglio delle piste, alla produzione dei file per lo stampaggio vero e proprio. In questo primo incontro si vedrà perché e come disegnare uno schema elettronico al computer, come importare i componenti, come associare i simboli grafici agli oggetti fisici.
30 giugno: Introduzione a KiCAD – seconda parte. Disegnato lo schema sarà necessario realizzare il layout, la controparte digitale del circuito stampato. Al termine della serata, il prodotto potrà essere mandato in stampa presso aziende specializzate tramite processi industriali, oppure potrà essere utilizzato la serata seguente. Saranno approfondite alcune funzioni supplementari di KiCAD, come la gestione della lista componenti e delle librerie.
7 luglio: Introduzione a FlatCAM. Flatcam è un software che, a partire da file gerber o gcode, permette di passare all’incisione e all’intaglio vero e proprio del circuito tramite una macchina a controllo numerico. Al termine della serata, il prodotto potrà essere inciso tramite una CNC, come quella che abbiamo in officina, come vedremo nella serata successiva.
14 luglio: Uso della fresa CNC del GOLEM. Il modo più veloce, economico e pulito per prototipizzare un circuito stampato, oggi, è tramite l’uso di una macchina a controllo numerico, che, partendo da delle basette completamente ricoperte di rame, le intaglia in maniera tale da ottenere le piste per il circuito stampato. La fresa, comandata dal sistema operativo a bassa latenza LinuxCNC, al termine della serata, produrrà il circuito stampato, sul quale sarà possibile saldare tutti i componenti, e potrà finalmente essere utilizzato. L’utilizzo della fresa sarà consentito solo al personale qualificato, che eventualmente provvederà a organizzare un corso per gli interessati.
Vi aspettiamo numerosi! Le serate saranno trasmesse sul server meet il martedì sera dalle 21.30! Potrà fare eccezione la serata d’uso della CNC che richiederà lo svolgimento in loco, seguiranno maggiori informazioni.
Per qualunque informazione, siamo raggiungibili per mezzo dei nostri numerosi canali.
Stanco delle prestazioni da bradipo dell’emulatore di Android e della (ahimé talvolta necessaria) macchina virtuale con Windows, che grattano di continuo sul disco meccanico della mia home directory, ho deciso che era giunto il momento di intervenire, per evitare di trovarsi catapultati negli anni 90 ogni due minuti.
Per risolvere il problema prestazionale esiste una soluzione molto semplice: comprare un nuovo disco a stato solido, abbastanza capiente. Questa soluzione però non è sicuramente delle più economiche.
La soluzione arzigogolata e nerd invece è: usare un piccolo disco SSD d’avanzo come cache per il disco meccanico.
Configurazione iniziale
Qualche mese fa mi è capitata una rocambolesca avventura per cui ho rischiato di perdere tutti i miei dati per colpa di un programmatore di firmware distratto. Certo, avevo un backup, ma non è la stessa cosa.
Quel giorno comprai dei dischi nuovi e mi feci un bel RAID1, come in figura.
Configurazione attuale, lenta
Questa configurazione avrebbe dovuto aiutarmi a prevenire perdite di dati, e anche a migliorare le performance in lettura dei dischi. Tuttavia, come ben presto si è rivelato, le cose non stavano affatto così, almeno quando i dischi venivano (ab)usati dalle sopraccitate applicazioni, particolarmente avide di random IO.
Il sistema operativo risiede comunque su un disco SSD a parte.
Nuova configurazione
Avendo un disco SSD d’avanzo, che avevo usato per rinsavire il computer portatile che mi ha accompagnato per numerosi viaggi in treno avanti e indietro per l’Università, ho quindi deciso di modificare la mia configurazione nel seguente modo.
Nuova configurazione desiderata
In questo modo, ogni volta che viene effettuato un accesso ad un file sul mio filesystem, LVM si preoccupa di controllare se, per caso, tale accesso può essere fatto anche per mezzo di una copia che si trova sul disco SSD.
Sì, LVM probabilmente potrebbe gestire direttamente anche il RAID, ma per il momento ho preferito riutilizzare le conoscenze già acquisite e continuare a sfruttare il RAID con mdadm.
La torre di Hanoi
Mi sono fatto prestare un disco meccanico di capienza identica ai miei dall’Officina Informatica del GOLEM.
Copiare tutto su quel disco e ricopiare di nuovo sul RAID? No, ho già trovato un disco col firmware buggato, e non desidero trovarne altri. Figuriamoci usare un disco usato di recupero!
Fare una specie di torre di Hanoi e rischiare comunque di perdere i dati per qualche errore umano (da me commesso)? Sì, facciamolo.
Mi sono quindi portato nella seguente situazione, installando il disco meccanico di passaggio, nominato sdd.
Vecchia e nuova configurazione (parziale) a confronto. A sinistra l’array md0, a destra md1.
Poiché è molto facile fare confusione con i nomi, e poiché LVM permette di usare nomi mnemonici, ho assegnato i seguenti nomi autoesplicativi ai vari componenti del mio spazio di archiviazione.
picostorage: il gruppo virtuale;
slowdino: il volume sul vecchio lento dinosauro meccanico (il RAID1);
fastrabbit: il volume sul nuovo veloce disco SSD;
metaguy: il volume per i metadati;
Ho impostato la nuova configurazione, ma con un disco mancante (in rosso in figura).
A questo punto, la cache è attiva. Non rimane che colmare il buco dell’array con uno dei dischi del vecchio array: simulo un guasto a uno dei dischi, lo rimuovo dall’array originale, cancello i metadati, e lo inserisco nel nuovo array.
Mi trovo quindi in questa condizione, e attendo pazientemente che l’array su sdb venga ricostruito, controllandolo con mdstat.
Una volta ricostruito l’array correttamente su sdb e su sdd, ripeto l’operazione, simulando stavolta il fallimento di sdd, e inserendo nell’array sda. Al termine dell’operazione, mi trovo con i miei due dischi sda e sdb nella nuova configurazione, e posso restituire sdd al GOLEM.
In nessun momento di tutta questa procedura i miei dati sono stati su un disco soltanto, perciò si può dire che la procedura sia a prova di guasti hardware.
Non sono però sicuro che sia a prova di guasti umani, perciò non fatelo a casa. 🙂
Benchmark
Per verificare se davvero questa cache serve a qualcosa, faccio un veloce test.
A fronte di circa 400 IOPS ottenute prima di installare la cache, adesso ne vengono fatte oltre 4000! 😮 Un risultato più che soddisfacente.
Anche durante l’uso delle applicazioni più avide, adesso la macchina risulta molto più fluida.
Il monitor di sistema mostra chiaramente i miglioramenti in lettura/scrittura dalla cache (in verde chiaro e fucsia), comparati con la lettura/scrittura dai dischi meccanici (in verde e rosso)
Manutenzione
Ogni tanto è bene controllare lo stato della cache e del RAID, e per questo ci vengono in aiuto i seguenti comandi:
Visto che per un po’ non sarà possibile riunirsi fisicamente in Officina Informatica, il Martedì sera saremo raggiungibili in Officina Virtuale al seguente indirizzo:
Pianificheremo le serate sul calendario pubblico, qui a lato (o in fondo alla pagina, da smartphone).
(Anche se non ci sono appuntamenti in programma, è probabile comunque di trovare qualcuno a fare due chiacchiere)
❗️ Alcune semplici regole: tenere il microfono disattivato se non per porre domande o partecipare alla discussione. Evitare di attivare la webcam per non sovraccaricare la rete.
📝 Poiché il sistema di videoconferenza non è ancora definitivo, si ricorda di seguire sempre il link evidenziato, che rimanderà automaticamente al server giusto anche qualora quest’ultimo dovesse essere cambiato.
Era la fine del 2005, quando dopo vari pellegrinaggi di distro in distro approdai ad Arch Linux. Si trattava di una distribuzione relativamente giovane, sviluppata da un programmatore canadese di nome Judd Vinet, il cui primo rilascio ufficiale risale all’11 marzo 2002. All’epoca si inspirava all’elegante semplicità di Slackware, Crux e dei BSD ed il suo motto era l’acronimo KISS: “Keep It Simple, Stupid”.
Aveva tutto quello che cercavo da una distribuzione Linux: – AIF (Arch Installation Framework), installer testuale leggero ed intuitivo basato su menù ncurses come quelli di Debian, Slackware o FreeBSD – pacman, un gestore di pacchetti che installa ed aggiorna software direttamente dalla rete (stile apt) – boot rapidissimo stile Slackware-BSD – rc.conf, un file di configurazione unico, come nei BSD con cui gestire tutto il sistema – abs, l’equivalente dell’albero dei ports dei BSD con cui poter ricompilare e personalizzare il sistema
Verso la fine del 2007 Judd Vinet si ritira dal progetto che passa nelle mani del programmatore statunitense Aaron Griffin e pian piano, nel corso degli anni finisce per perdere tutte le sue caratteristiche originali:
Nel 2012 il passaggio a systemd deprecò l’utilizzo del file di configurazione rc.conf (rete, pacchetti, moduli del kernel).
Tale importante modifica rese inutilizzabile anche il vecchio installer, sarebbe stata necessaria una sua quasi completa riscrittura, cosa che ad oggi non è ancora avvenuta.
Infine, nel 2017, anche “abs” e tutto il sistema di sincronizzazione ed aggiornamento da sorgenti viene dismesso.
Per i nostalgici o per chi non ha idea di cosa stia parlando, questo è un esempio di rc.conf
Stufo e sdegnato per la deriva di questa ottima distribuzione ho cercato conforto altrove. Il primo pensiero era ricaduto su Slackware, ma per quanto sia affezionato a questo dinosauro mi sono dovuto scontrare con la dura realtà dei fatti: conciliare il vetusto installer di Slack col mio desiderio di organizzare il sistema con partizioni gpt e subvolumi btrfs si è rivelata un’impresa sconcertante.
Scettico, ma spinto dalla curiosità e dalla noia dell’isolamento domestico da COVID-19 ho quindi deciso di dedicarmi allo studio di NixOS. Si tratta di una distribuzione Linux completamente rivoluzionaria, basata sull’innovativo gestore di pacchetti Nix.
L’approccio di Nix è unico nel suo genere, permette di installare, aggiornare e rimuovere software senza che ci si debba preoccupare delle dipendenze. Il path d’installazione di ogni pacchetto corrisponde al suo hash così da permettere la contemporanea convivenza anche di più versioni dello stesso programma. Gli aggiornamenti sono “atomici”, non vengono scaricati interi pacchetti deb, rpm o tgz, ma solo i file necessari. È inoltre possibile tornare indietro alla configurazione precedente all’installazione di un dato software in maniera semplice ed automatica.
L’aspetto che più entusiasma di questa distribuzione è la possibilità di tornare a gestire in maniera centralizzata tutti gli aspetti attraverso un unico file di configurazione (/etc/nixos/configuration.nix). Diventa semplicissimo replicare un’installazione su più macchine, fare cache dei pacchetti, gestire installazioni su sistemi virtualizzati o creare un supporto d’installazione personalizzato. Si ha la sensazione di trovarsi di fronte ad un vero e proprio sistema operativo più che ad un assembramento di software, lo scotto da pagare per sfruttare tale potenza è il dover familiarizzare col suo linguaggio. Su NixOS le cose NON si fanno come sugli altri sistemi Linux.
