Personalizzare il firmware della scheda terminale ANSI / VT-100

Scritto il 12 maggio 2018 da

La scheda terminale ANSI / VT-100 per il computer RC2014 utilizza il firmware open source disponibile su GitHub ed è pertanto liberamente modificabile da chiunque. Tuttavia, essendo scritto nel linguaggio Spin proprio dei microcontrollori Parallax Propeller, potrebbe essere difficile, anche per chi è esperto di programmazione di microcontrollori, capirne il funzionamento, cercherò quindi di spiegare il più semplicemente possibile come effettuare alcune piccole modifiche per rendere il firmware un po’ più personale.

Prosegui la lettura…

Assemblare la piattaforma target con Eclipse 4.6

Scritto il 2 luglio 2016 da

Pochi giorni fa è stata rilasciata la nuova versione 4.6 “Neon” di Eclipse e come tutte le volte che viene rilasciato un aggiornamento ho iniziato ad assemblare la piattaforma target per lo sviluppo delle applicazioni rich client (RCP). L’amara sopresa è stata quella di non trovare più il file delta pack contenente i plugin e i launchers binari per tutti i sistemi operativi supportati tra i file disponibili per il download. Già qualche anno fa uno dei pacchetti che facilitavano la creazione dei target, il platform sdk, è stato eliminato dai downloads. Non un grosso problema, lo si può ricavare dal pacchetto Eclipse SDK standard eliminando le feature e i plugin non necessari con un po’ di lavoro in più, aggiungendo poi il delta pack per avere le opzioni di esportazione multi piattaforma. Ora, senza il delta pack, anche questo non è più possibile.

Prosegui la lettura…

Codice Overlay con il Parallax Propeller e GCC

Scritto il 7 aprile 2016 da

I programmi che utilizzano codice overlay erano molto popolari nell’era dei primi home computer quando la memoria a disposizione non era molta e la possibilità di caricare porzioni di codice solo quando necessario permetteva di realizzare programmi molto più grandi della memoria disponibile.

Con i microcontrollori siamo in una situazione simile con programmi a volte molto complessi e una memoria piuttosto limitata, basti pensare ad esempio alle librerie per la gestione del file system di una SD card o per l’accesso ad internet che posso esaurire o limitare fortemente la memoria a disposizione per il programma vero e proprio, specialmente se devono essere utilizzate contemporaneamente.

Il Parallax Propeller è un microcontrollore dotato di 32K di memoria RAM interna e utilizza una EEPROM esterna per caricare il programma da eseguire al momento dell’accensione. Poichè solo i primi 32K della EEPROM vengono utilizzati per il programma è possibile dedicare l’eccedenza delle memorie più ampie alla memorizzazione dei dati. Fortunatamente con il compilatore GCC e gli strumenti standard messi a disposizione è possibile anche memorizzare porzioni di programma da caricare nella ram principale quando necessario.

Prosegui la lettura…

Propeller Game Console

Scritto il 25 febbraio 2016 da

Sono felice di presentarvi il mio primo progetto hardware, una console per videogiochi dotata di cartucce intercambiabili in stile retro, basata sul microcontroller Parallax Propeller P8X32A. Per chi non conoscesse questo chip, si tratta di un microcontroller a 32bit con 32k di RAM e 8 core funzionanti in parallelo a 80MHz, il codice e i dati vengono letti da una EEPROM esterna e possiede 32 pin di input/output completamente programmabili. La console utilizza due di questi chip per migliorare le prestazioni e consentire la realizzazione di giochi più complessi di quanto sarebbe possibile con uno solo. Un chip è dedicato alla grafica e all’uscita video, l’altro chip è dedicato all’uscita audio e alla logica del gioco.

P8X Game System

P8X Game System

Caratteristiche Tecniche:

GPU:

  • Parallax Propeller P8X32A
  • 32k RAM (interna)
  • Uscita video VGA a 320×240 pixels e 64 colori

CPU:

  • Parallax Propeller P8X32A
  • 32k RAM (interna)
  • 128k RAM (esterna)
  • Audio Stereo
  • Supporto per due controller a 8 pulsanti

I due chip sono connessi tramite due linee seriali ad alta velocità per comunicazioni bidirezionali e due linee dati generiche, una delle quali è utilizzata dalla GPU per segnalare la sincronizzazione video verticale. Il programma e i dati dei giochi sono memorizzati su due EEPROM, una per la GPU e una per la CPU, saldate sulla scheda della cartuccia.

Ho realizzato i primi prototipi funzionanti e anche se l’SDK non è ancora pronto, ho convertito con successo il gioco open source Abbaye des Morts che utilizza una grafica piuttosto complessa e richiede parecchia memoria, un ottimo test per l’hardware.

Collegamenti:

Esperimenti con GIT e Subversion

Scritto il 18 ottobre 2011 da

Nelle scorse settimane ho fatto qualche esperimento con un nuovo flusso di lavoro basato su GIT e Subversion. Tutti i nostri progetti utilizzano Subversion come sistema di controllo dei sorgenti, pensiamo che in questo momento un sistema centralizzato risponda meglio alle nostre esigenze, tuttavia alcune feature di GIT potrebbero essere molto interessanti per gli sviluppatori, così ho iniziato ad investigare su come prendere il meglio dei due mondi e integrare GIT nel nostro flusso di lavoro basato su Subversion.

GIT è un sistema di controllo distribuito, questo significa che ogni sviluppatore riceve una copia completa di tutta la storia del progetto, quindi la prima cosa da fare è creare un clone del nostro progetto con GIT. Cercando con Google ho trovato che si tratta di un’operazione veramente molto semplice:

[marco@bridge git] git svn init -s <svn.repository.url>
[marco@bridge git] git svn fetch

Il primo comando crea un repository GIT locale nella directory corrente and lo collega al repository Subversion remoto. Il secondo comando clona il repository Subversion nel repository GIT locale. Potrebbe impiegare da pochi minuti a diverse ore in relazione alla dimensione del repository remoto, ma alla fine si ha una copia completa di branch e tags memorizzata nel repository GIT locale:

[marco@bridge git] git branch -a
* master
  remotes/rel_1_00
  remotes/refactorings
  remotes/tags/pre_rel_1_00
  remotes/trunk

Il branch master è quello collegato alla directory trunk remota di Subversion. Ogni commit eseguito sul branch master verrà inviato a Subversion con:

[marco@bridge git] git svn dcommit

Di tanto in tanto si dovranno ricevere gli aggiornamenti dal repository Subversion e aggiornare il repository GIT locale. Ancora una volta si tratta di un’operazione veramente molto semplice:

[marco@bridge git] git svn rebase

Assicuratevi di essere sul branch master e che non ci siano modifiche non committate, altrimenti il rebase non funzionerà. Il comando git stash diventa molto utile in questo caso, poichè permette di rimuovere temporaneamente tutte le modifiche senza creare un nuovo commit.

Lavorare sul branch master non è diverso dal lavorare direttamente con Subversion, con la differenza che si ha un passo in più da eseguire (dcommit) prima che le nostre modifiche vengano inviate al repository centrale. Questo è comunque un vantaggio poichè ci permette di rivedere i nostri commit e usare qualche trucco offerto da GIT, come il rebase interattivo e l’amending, per ripulire la storia del codice.

Il vantaggio principale di usare GIT è tuttavia poter creare branch locali, quindi ho cambiato il mio workflow in modo da creare un nuovo branch locale dal branch master ogni volta che inizio a lavorare ad una nuova feature, committare le modifiche quando necessario per tenere traccia dei progressi, testare il codice, committare gli aggiustamenti, ecc. Quando sono soddisfatto del risultato effettuo un merge verso il branch master e invio le modifiche al repository Subversion con dcommit. E’ con le operazioni di merge che GIT mostra tutta la sua utilità. Un semplice merge replica tutti i commit dal branch locale al master e di conseguenza verso Subversion, sporcando l’history remota con i commit locali, tuttavia un merge squash replica tutte le modifiche dal branch locale ma non effettua i commit, permettendoci di eseguire un controllo finale delle modifiche, correggere eventuali problemi dovuti al merge con un versione del codice più recente e committare tutto con un singolo commit. L’history remota non conterrà quindi i commit locali ma un singolo changeset con tutte le modifiche effettuate sul branch locale.

La procedura quindi è:

  1. Creare un branch locale
  2. Lavorare sul branch locale committando quando necessario
  3. Tornare al branch master, aggiornare dal repository remoto ed effettuare un merge squash dal branch locale
  4. Controllo finale del codice, commit e invio a Subversion

Fino ad ora questa procedura con GIT e Subversion ha funzionato abbastanza bene. Gli strumenti di sviluppo che supportano GIT purtroppo non supportano l’integrazione con Subversion e si è quindi costretti il più delle volte ad utilizzare la linea di comando. EGit, l’integrazione di GIT per Eclipse, è molto utile per gestire i repository GIT locali ma è ancora piuttosto immaturo e non offre tutte le opzioni disponibili dal programma a linea di comando. Speriamo che in futuro venga offerta una migliore integrazione.

Collegamenti:

 

Test JUnit con Eclipse Databinding

Scritto il 14 luglio 2011 da

Quando abbiamo iniziato ad usare il Databinding framework di Eclipse abbiamo affrontato il problema di come testare le classi che utilizzano il databinding con JUnit. Il framework Databinding richiede un Realm predefinito e tutte le classi devono essere eseguite all’interno di questo Realm. Il framework Eclipse inizializza automaticamente un Realm predefinito all’avvio dell’applicazione con un codice simile a questo (da Workbench.createAndRunWorkbench):

    Realm.runWithDefault(SWTObservables.getRealm(display), new Runnable() {
        public void run() {
            ULocale.setDefault(new ULocale(Platform.getNL()
                    + Platform.getNLExtensions()));
            // create the workbench instance
            Workbench workbench = new Workbench(display, advisor);
            // run the workbench event loop
            returnCode[0] = workbench.runUI();
        }
    });

 

JUnit permette di ridefinire il metodo utilizzato per eseguire tutti i test definiti in una classe permettendoci di aggiungere un codice simile a quello riportato sopra per inizializzare il Realm di default. Di seguito le due classi che utilizziamo per eseguire i test delle classi che usano il databinding con JUnit.

 

JUnit 3

Abbiamo scritto una classe DatabindingTestCase derivata dall’originale TestCase e ridefinito il metodo run aggiungendo il codice per inizializzare il Realm predefinito. Le classi contenenti i test saranno quindi derivate da DatabindingTestCase anzichè TestCase.

import junit.framework.TestCase;
import junit.framework.TestResult;

import org.eclipse.core.databinding.observable.Realm;
import org.eclipse.jface.databinding.swt.SWTObservables;
import org.eclipse.swt.widgets.Display;

public class DatabindingTestCase extends TestCase {

    public DatabindingTestCase() {
    }

    public DatabindingTestCase(String name) {
        super(name);
    }

    @Override
    public void run(final TestResult result) {
        Display display = Display.getDefault();
        Realm.runWithDefault(SWTObservables.getRealm(display), new Runnable() {

            @Override
            public void run() {
                DatabindingTestCase.super.run(result);
            }
        });
    }

    public void testEmpty() throws Exception {
        // To keep JUnit happy
    }
}

 

JUnit 4

Leggermente più complicato poichè utilizza le annotazioni e le cassi non derivano da una classe base. In questo caso abbiamo scritto una class runner di rimpiazzo DatabindingClassRunner derivata da BlockJUnit4ClassRunner e ridefinito il metodo run, come abbiamo fatto per JUnit 3. Le classi contenenti i test saranno quindi annotate con @RunWith(DatabindingClassRunner.class).

import org.eclipse.core.databinding.observable.Realm;
import org.eclipse.jface.databinding.swt.SWTObservables;
import org.eclipse.swt.widgets.Display;
import org.junit.runner.notification.RunNotifier;
import org.junit.runners.BlockJUnit4ClassRunner;
import org.junit.runners.model.InitializationError;

public class DatabindingClassRunner extends BlockJUnit4ClassRunner {

    public DatabindingClassRunner(Class<?> klass) throws InitializationError {
        super(klass);
    }

    @Override
    public void run(final RunNotifier notifier) {
        Display display = Display.getDefault();
        Realm.runWithDefault(SWTObservables.getRealm(display), new Runnable() {

            @Override
            public void run() {
                DatabindingClassRunner.super.run(notifier);
            }
        });
    }
}

 

 

Collegamenti:

http://wiki.eclipse.org/index.php/JFace_Data_Binding

http://www.junit.org/

 

Eclipse 3.7 Indigo rilasciato oggi

Scritto il 22 giugno 2011 da

La versione 3.7 Indigo dei progetti Eclipse è ora disponibile. Quest’anno 62 progetti fanno parte del treno di rilasci annuale, ben 23 progetti in più rispetto alla versione Helios dello scorso anno.

Qui sono in evidenza alcune delle nuove funzionalità che si trovano in questa versione:

  • Jubula fornisce test funzionali automatizzati per l’interfaccia utente per Java e HTML
  • WindowBuilder, un popolare strumento per la costruzione di interfacce grafiche per gli sviluppatori Eclipse, ora è open source e parte di Indigo
  • EGit 1.0 fornisce una stretta integrazione con il sistema di controllo di versione Git
  • Migliore integrazione con Maven, tra cui l’avvio e la manutenzione dei file pom

Siamo molto entusiasti di questa release e siamo pronti a sviluppare prodotti basati sul nuovo SDK.

Maggiori informazioni e download:

www.eclipse.org

 

Benvenuti sul nostro nuovo blog

Scritto il 13 giugno 2011 da

Siamo lieti di darvi il benvenuto sul nostro nuovo blog.

Lo scopo di questo blog è quello di pubblicare articoli riguardanti le nostre attività e le tecnologie che utilizziamo per sviluppare i nostri prodotti, trucchi e suggerimenti per utilizzare al meglio i linguaggi di programmazione, i framework, gli strumenti di lavoro, e altre cose.

Divertitevi.