|
Digitando, digitando... n. 01/2024 del 11.06.2024
#AmighinoRPi
O, come scrivevo sulla mia pagina FB, in uno dei tanti post dedicati al giocattolino in questione: “Se puoi sognarlo, puoi farlo”. Dovrebbe essere un aforisma di Walt Disney in persona, ispiratore peraltro di tantissimi, entusiasmanti, sogni per molti.
Fine??? Pubblicato solo come curiosità simpatica (per i pochi, come me, che non l’avevano mai visto prima) non avrei mai immaginato che sarebbe stata la scintilla in grado di (ri)accendermi più di un interesse. Tanti conti in sospeso, parcheggiati in qualche cassetto della testa, che aspettavano solo il momento giusto per saltare nel mio mondo reale. Tanto per essere chiari, fino a poche settimane fa non avevo mai programmato, né toccato con mano, un Raspberry. Durante lo stop-covid avevo giocherellato con Arduino e già sapevo che “prima o poi” avrei messo il naso anche nel suo fratello maggiore. Per non parlare del fatto che la stampa 3D, che pure mi incuriosiva da sempre, l’avevo vista solo in qualche tutorial di YT, relegando anche questa al capitolo “sì, poi, dopo”. Ritenevo quest’ultima, peraltro, ancora più irraggiungibile visto che non mi sarei mai limitato a stampare oggetti 3D altrui e quindi mi toccava esplorare preventivamente anche il mondo della modellazione 3D, aggiungendo al tutto un ulteriore (e oscuro) livello di complessità. E infatti, inizialmente, questo secondo aspetto l’ho ricacciato nel cassetto mentale dal quale era arbitrariamente schizzato fuori, ma lo sentivo scalpitare ancor più di prima. Avete presente Jumanji? 🤣
Raspberry Pi: sì, ma quale?
Primo dubbio, tanto per ribadire quanto fossi a digiuno
della doppia (ancora non tripla) materia: l’aspetto
hardware, come al solito in funzione del software. Di
RPi completi ne esiste più d’uno,
Tornando brevemente alla questione bollori, sempre da poco esperto al riguardo, cautelativamente avevo preso anche un box in alluminio tutto aletta, risultato poi essere del tutto inutile… almeno nell’uso con l’emulatore Amiga. Parliamo di un computer di 40 anni fa che, dentro un Raspberry 3, a mio avviso ci “gira” impegnando una minima parte della potenza disponibile. “E ho detto tutto!” (altra cit.)
L’emulatore, questo sconosciuto…
Passiamo all’emulatore da utilizzare, altro terreno impervio (almeno per me). Ribadisco che stavo esplorando campi nuovi, ma la cosa in sé non rappresentava un problema, anzi era lo spunto per studiare le varie soluzioni, cominciando dal fatto che effettivamente ce n’era più d’una.
Dettagli organizzativi a parte, la soluzione pappa pronta della distribuzione Linux, come facilmente immaginabile, non mi ha convinto. Non so di preciso il motivo, ma il fatto stesso di perdere una parte del controllo totale mi dava fastidio. Oltre al fatto che non funziona, comunque, al primo colpo e c’è da combatterci un po’ per riuscire a farlo ragionare. Alla fine ho deciso di fare di testa mia: distribuzione Linux standard (del Raspberry, scaricata sempre da Melopero.com) sulla quale ho semplicemente installato Amiberry, che mi risulta essere - ripeto, ne sapevo e continuo a saperne poco! - uno degli emulatori più diffusi.
Linux, questo sconosciuto…
Già, perché anche di Linux non ne so moltissimo, non avendolo mai utilizzato per davvero, che in altre parole equivale a dire che non mi ero mai scontrato con lo stesso per risolvere problemi… che subito si sono palesati nella mia prima esperienza RPi. Per cominciare: come caxxarola si fa per lanciare all’avvio automaticamente un’app? Chiedo a Nonno Google che le sa tutte? Nì, perché se è vero che la soluzione (ovviamente) c’è, è altrettanto vero che non è unica e dipende da un sacco di fattori, a cominciare dalla distribuzione Linux utilizzata e dalle infinite possibilità che ognuna mette a disposizione. Parlo in generale, non solo in merito all’app da lanciare all’avvio. Così la prima dritta ricevuta riguardava il fatto di mettere il comando all’interno del file rc.local ma questo purtroppo non è sempre sufficiente se, come nel mio caso in una versione successiva dell’interfaccia utente, che parallelamente stavo buttando giù in Python, doveva partire prima la GUI X cosa che tramite il file in questione a quanto pare non avveniva. Per farla breve, alla fine la soluzione definitiva mi è stata suggerita nei commenti della mia pagina FB da chi, prima di me, s’era scontrato con il non-problema. C’è un’apposita cartella autostart in quella nascosta .config, nella propria cartella utente di home, nella quale inserire file con estensione .desktop che, per semplificare, lancia l’eseguibile dediderato (python interfaccina.py). Se l’utenza è denominata pi e la cartella di lavoro amy, il file da salvare come interfaccina.desktop nella cartella autostart prima citata è il seguente:
[Desktop Entry] Type=Application Name=interfaccina Exec=/usr/bin/python /home/pi/amy/interfaccina.py Name[it_IT]=interfaccina
Gli altri «pezzettini»
Finora, lato hardware, ho citato solo il Raspberry, come detto segliendo il modello 3+, a mio avviso sufficiente per le emulazioni Amiga. Almeno quelle fin qui esplorate da me. Già perché Amiberry, come immagino altri emulatori, permette di confezionare la macchina da emulare come ci pare, con il processore che vogliamo, tutta la memoria (chip e fast) di cui abbiamo bisogno e anche tanti altri add-on che un tempo, spesso, potevamo solo sognare. Nel nostro caso, ovviamente, ce la caviamo con qualche click nelle tante pagine di configurazione previste. Approfondirò anche questo a tempo debito (se non mi stufo prima!).
Il modulo LCD che ho trovato, nelle dimensioni che mi interessavano, ha per certi versi lo svantaggio di essere in formato 16:9 (cosa che naturalmente l’Amiga non era) e se per alcuni è apparso come un errore di progetto, nell’uso risulta più indicato di un display 4:3 per quei giochi o quelle applicazioni, e non sono poche, che utilizzano il formato per l’NTSC, come noto, da 320x200px anziché 320x256px di quello per il PAL. Tradotto: in molti casi il formato 16:9 viene sfruttato se non al 100% almeno al 95% visualizzando realmente la schermata a pieno formato su quel display, mentre su un 4:3 (come molti ricorderanno) creava una corposa banda nera in basso, totalmente inutilizzata. In altre parole, non sono pentito affatto della scelta… che posso nemmeno ritenere tale (un display 4:3 DSI, da pochi pollici, non sono riuscito a trovarlo nemmeno su Aliexpress, per esser chiari!).
Per semplificare il progetto non ho previsto l’audio stereo, pertanto (pur essendo stereo tanto il Raspberry, quanto l’amplificatore e l’emulatore, oltre che l’Amiga originario) ho usato un solo canale. Anzi, la somma di entrambi su un’unica uscita, altra impostazione prevista da Amiberry.
Qui però sì è palesato un secondo problema (dopo quello
dell’avvio automatico dell’interfaccina utente), più di
natura hardware, per di più analogica, che software.
Collegando sia il Raspberry che l’amplificatorino alla
medesima alimentazione si creava, come spesso avviene,
un loop di massa con pesante - quanto inaccettabile -
ronzio. Al solito ho chiesto aiuto sulla pagina FB e la
soluzione è arrivata nel consueto millisecondo.
È bastato - si fa presto a dirlo! - interporre un minuscolo trasformatore di isolamento (in foto qui sotto) tra l’uscita audio del Raspberry e l’ingresso del piccolo ampli, per sentir sparire ogni disturbo e tirare un profondo sospiro di sollievo. Stavo per buttare tutto all’aria, per fortuna sono stato fermato in tempo! Per l’alimentazione, visti anche i problemi riscontrati con quella esterna, ho optato per un powerbank di potenza sufficiente. Per questi è meno complicato di quanto possa sembrare, in quanto basta sceglierne uno recente in grado di caricare in scioltezza i moderni smartphone, anch’essi piuttosto esigenti in corrente, a meno di non aspettare tempi biblici per la ricarica.
Ne ho scelto uno di dimensioni tutto sommato ridotte con
integrato un display che indica la carica residua e
soprattutto un pulsante di alimentazione per pilotare da
questo l’accensione del tutto. Per lo spegnimento, no,
meglio procedere da Linux con il più salubre e solito
Chiudi sessione e poi Arresta.
Il primo mockup…
… faceva pena, non fatico ad ammetterlo. Era in cartoncino, pensando poi di riprodurlo in materiale plastico da incollare (avevo già acquistato in un negozio di modellismo un foglio di stirene) e non era altro che una serie di facce appena sagomate per inglobare un po’ tutto. Ma ancora ero distante da una soluzione accettabile. Mi è stato suggerito, sempre dalla mia pagina FB e sempre poche settimane fa, di pensare alla stampa 3D per realizzare qualcosa di meglio e che potesse in qualche modo richiamare la sua natura Amiga, caratteristica totalmente assente nel primo mockup, come ben testimonia la foto qui sopra. Il problema, al solito, che di stampa 3D ne sapevo poco… ma Jumanji non dà tregua e i minacciosi colpi di tamburo si facevano sempre più insistenti! Così, incoraggiato da alcuni, mi sono lanciato anche in questa avventura nell’avventura provando a capirne qualcosa di più, in primis, della modellazione 3D. Purtroppo (o per fortuna…) non potevo né volevo utilizzare un progettino già disponibile, avendo necessità troppo specifiche: l’unica parte, diciamo, standard di tutto il progetto era il Raspberry, tutto il resto era troppo personalizzato e quindi difficilmente avrei trovato - ma ripeto, non ho nemmeno provato a cercarlo - qualcosa già bell’e fatto!
Arriviamo alla modellazione 3D
Ho scelto di utilizzare Onshape che, inaspettatamente, è
un software che - adoooooorooo - si utilizza interamente
online, senza installare nulla sul proprio PC/Tablet/smartphone.
La sua struttura è perfino
responsive quindi entro certi
limiti può essere utilizzato dappertutto tramite
browser. Viene solo fatto un check su quest’ultimo ma,
naturalmente, i vari Chrome, Edge, Safari, ecc. sono
tutti pienamente compatibili. Onshape non è un
giocattolino, tutt’altro! Vi dico solo che per
l’utilizzo professionale è previsto un canone di 1500
dollari l’anno e
Bene, ma come si modella un oggetto 3D con gli
applicativi di questo tipo? Per semplificare, anche
troppo, si parte sempre da un disegno 2D (ad esempio
Con un click o poco più si trasforma la figura 2D appena tracciata in un solido pieno e successivamente, con meccanismi analoghi, prima si vuota l’interno (indicando la faccia coinvolta da cui scavare e lo spessore da lasciare, nel mio caso 1,5 mm).
Naturalmente non siamo che all’1-2 per cento del percorso, la sto semplificando tanto altrimenti staremmo qui giorni e giorni, io a scrivere, voi a leggere, per illustrare in dettaglio tutti i passaggi… ma i meccanismi utilizzati sono praticamente tutti dello stesso tipo. Anche per costruire l’alloggiamento del powerbank, le griglie laterali (più che altro estetiche) e quella superiore che include i meccanismi di aggancio per l’altoparlante utilizzato, che dispone di un suo volume proprio: in pratica è una cassa acustica in miniatura.
Capito, più o meno, come guidare un CAD 3D (cosa che,
ripeto, non avevo mai fatto prima di questa esperienza)
poteva diventare realtà anche la stampa 3D, materia che
altrettanto ignoravo totalmente, se non per sentito
dire. Ad esempio una delle prime cose che avevo
sottovalutato è che la progettazione 3D stessa, se il
pezzo deve essere stampato con una macchina FDM (Fused
Deposition Modeling, a filamento) va pensato nel giusto
modo perché bisogna tenere conto dei vincoli specifici
di tale tecnica. Non solo: anche il posizionamento del
pezzo sul piano di stampa può incidere sul risultato,
oltre al fatto che variano di conseguenza anche i
supporti aggiunti
Abbiamo finito?
Macché! L’ultima fatica ha riguardato la finitura esterna: stuccatura, rasatura, trattamento con primer e verniciatura (spray).
L’interfaccina utente
Siamo quasi arrivati alla fine, dobbiamo solo dare uno sguardo all’ aspetto software (nel quale, tutto sommato, mi sono compiaciuto). Ovviamente anche questa non è interamente farina del mio sacco, in quanto anche con Python ero alle prime armi - a differenza del resto comunque non totalmente a digiuno! - ma soprattutto conoscevo poco le librerie utilizzate, principalmente tkinter per l’interfaccia vera e propria, e pygame che ho utilizzato solo per la musichetta di sottofondo, naturalmente disattivabile da apposito pulsante! In breve, ho creato quattro pagine, tra loro linkate, ognuna con sei pulsanti per altrettante funzioni collegate, oltre a quelli di navigazione (ripetuti in tutte le pagine). Una roba che in HTML/PHP/ecc. avrei impiegato pochi millisecondi per buttarla giù, ma con Python condito di OOP è risultato essere un pelino più complicato del previsto. Ma sono stato aiutato anche in questo, come dichiarato anche nella pagina di ringraziamento che ho inserito nel codice. In pratica su Amiberry ho creato tante configurazioni quante sono le icone presenti, ognuna corrispondente a un file nella cartella conf predisposta dall’emulatore. Per semplicità ho chiamato nello stesso modo il file di configurazione (ad esempio FS.uae) e la corrispondente icona (FS.png) nel caso del Flight Simulator (FS, appunto). Come immaginabile posso rilasciare solo il codice in forma basica & testuale, chi volesse realizzare un #AmighinoRPi, anche vagamente simile a questo, dovrà completarlo secondo le proprie necessità.
Concludendo…
Cosa altro aggiungere, se non ribadire ancora una volta (come già fatto sulla mia pagina FB) che si è trattato di un’esperienza entusiasmante, ben oltre le più… catastrofiche aspettative. Già, non pensavo affatto di riuscirci, per quante erano le incognite e, soprattutto, le mie lacune di cui ero ben conscio. Ci tengo a sottolineare ancora una volta che si è trattato di un lavoro di squadra: non credo infatti che sarei riuscito a portarlo a termine, senza l’aiuto di molti di voi.
GRAZIE!
:-)
|
