Von Neumann vs Harvard

I microcontrollori dall'esterno sono tutti uguali all'interno sono molto diversi. Una differenza sostanziale era quella dell'architettura hardware dei micro che si suddividono sostanzialmente in due tipi

• Von Neumann
• Harvard

L'architettura Von Neumann ha un unico spazio di memoria dove viene condivisa l'area dati da quella del codice.

Nell'architettura Harvard le due memorie sono separate.

Dalla figura soprastante viene evidenziato il collo di bottiglia della architettura von Neumann. L'architettura Harvard riesce a parallelizzare l'esecuzione delle istruzioni con l'accesso alla memoria incrementando l'efficienza della computazione.

La prima applicazione PID

Siamo intorno la primavera del 1994 qualcuno ci disse che eravamo riusciti a poter fare dei test funzionali veri in una preserie di lavatrici. Imparai presto cosa significava catena di montaggio. Così il nostro piccolo laboratorio doveva accellerare per risolvere gli ultimi problemini nel controllo di velocità.

Una delle caratteristiche del controllo motore era l'implementazione di un PID per la necessaria stabilizzazione della velocità.

Il mercato ci imponeva di sviluppare con PIC16C57. 

Microcontroller molto aggressivi ma con con solo 2K rom. Beh, sì, non sono 2K byte perché l'istruzione del microship è lunga 12 bit ma comunque. Sempre 2K erano

In questo video un'interessante lezione sul PID

In quest'altro video alcune caratteristiche meccaniche del motore

uKernel per PIC16C67

Il progetto più complesso sviluppato è stato senza dubbio il controllo motore con anti-sblinaciamento. Questo è stato anche il primo progetto serio per una grande azienda italiana di elettrodomestici, San Giorgio. 

https://www.sangiorgioelettrodomestici.it/it/

Anche in questo caso l'intero progetto era stato sviluppato in codice Assembly su un microcontrollore della società che avrebbe presto esaurito l'intero mercato mondiale a 8 bit. 

https://www.microchip.com/design-centers/8-bit

Il micro era il mitico PIC16C57 ma anche in questo caso avevamo pensato di sviluppare da noi stessi un kernel per gestire i processi interni.

SCHEDULER CLRWDT ; clear wdog ;------------------------------------ ; GESTIONE TIMER DI SISTEMA E TASK GEST_RTCC MOVFW RTCC XORWF RTCC_COPY,W BTFSC STATUS,Z GOTO P_TASK INCF RTCC_COPY,Same ; avanza di un passo il mio orologio C_TASK_0 ; controllo task 0 TASK set 0 BTFSC RET_ADD+TASK,7 ; testa se evento o tempo DECF COND+TASK,SAME

C_TASK_1 TASK set 1 BTFSC RET_ADD+TASK,7 ; testa se evento o tempo DECF COND+TASK,SAME

C_TASK_2 ; controllo task 2 TASK set 2 BTFSC RET_ADD+TASK,7 DECF COND+TASK,SAME

uKernel per 8051

Molti anni fa il codice nel sistema embedded era praticamente scritto in Assembly (e non in Assembler). L'assembly è la lingua dei microprocessori. Il codici sviluppati in quel periodo erano molto densi con molte funzionalità. 

In questo caso, la nostra applicazione doveva consentire un comportamento fluido e uniforme per tutti i cursori che potevano essere spostati simultaneamente. Abbiamo progettato un kernel con uno scambio di contesti semplice ma molto efficace e creato molte attività necessarie per gestire i comportamenti paralleli.

Event e Semaphore erano parte fondamentale di questo kernel 8051

;================================== ; WAIT_SEMAPHORE ; COMMENT : PROCEDURA DI ATTESA SEMAFORO ; ; ON ENTRY : ( INDICE_TABELLA ) INDICE ; ON EXIT : NONE ;==================================== WAIT_SEMAPHORE: ;---------- SALVA CONTESTO TASK CHIAMANTE POP SAVEPCH POP SAVEPCL CALL SAVE_CONTEXT MOV EVERGREEN,hashtag#GREEN ;---------- PASSAGGIO A TASK SUCCESSIVA NEXT_TASK: INC TSK_CNT MOV A,TSK_CNT DEC A CLR C SUBB A,TSK_MAX JC OK_TASK_NUMBER MOV TSK_CNT,#1 OK_TASK_NUMBER:

MIDI ed embedded

Questo era il futuristico emulatore Metalink che abbiamo usato per i sistemi embedded con il microprocessore 80MC522 di Philips. Uno dei tanti derivati dell'80C51. 

https://www.nxp.com/docs/en/data-sheet/80C552_83C552.pdf?


Il microcontrollore era un derivato del microprocessore 8088 utilizzato per le schede su PC. Le prestazioni anche se ridimensionate ad 8 bit erano di primissimo rilievo tanto che si potevano fare dei veri e propri PC industriali.


L'insolito apparato è stato progettato per testare i parametri del Midi una caratteristica utile per le applicazioni musicali professionali. Il protocollo MIDI è la base delle strumentazioni musicali digitali.

https://docs.isy.liu.se/pub/VanHeden/DataSheets/The_MIDI_Specification.pdf

Ogni canale era stato configurato con uno dei parametri e testato con SoundGenerator. Non mi sono mai annoiato di fronte a 2 altoparlanti da 2 Kilowatt.

Il primo micro

Il micro utilizzato nella scheda era un Motoral 68HC118 che apparteneva alla famiglia 68HC11. Era un finestrato shrinkato per ottimizzare gli spazi nel circuito stampato.

https://it.wikipedia.org/wiki/68HC11

Nessun emulatore ma un solo programmatore del micro ed una lampada germicida illuminare il piccolo slice di slicio e cancellarne la memoria. 

I test venivano fatti tutti con la tecnica prega monta e prova. Una volta preso dimestichezza con il micro si buttava giù il programma definitivo. Si provavano le singole parti funzionali ed infine si il test di tutto il sistema completo.  

https://www.clear.rice.edu/elec201/Book/6811_asm.html

Pannelli Sylvia

La bozza di software ebbe successo e di li a poco entrai nel team per una commessa appena appaltata per una azienda italiana a cui avevano appaltato il traffico autostradale italiano. Si doveva mettere in piedi la rete di segnaletica alfanumerica autostradale. Avete presenti i pannelli che per anni hanno visualizzato la scritta "Moderare la velocità"?

Quella che vedete nell'immagine era la configurazione progettuale iniziale e che evidentemente è rimasta come implementazione funzionale. Era composta da un grande pannello centrale alfanumerico ed uno laterale con uno o più pittogrammi di grande visibiltà. I pannelli erano tutti di origine francese e ad ogni "dot" corrispondeva una fibra ottica che veniva accesa o spenta attraverso un oscuratore controllato dalla scheda. La scheda di controllo dove dovevo sviluppare il firmware riceveva i comandi da un centro operativo e visualizzava le stringe inviate con un protocollo ASCII dedicato.

Flow Chart ma non solo...

Dopo un primo colloquio preliminare, la prima applicazione scritta e presentata ad una azienda per essere valutata è stata una bozza di editor grafico previsto per la progettare e disegnare flow chart. Era l'estate dell'anno 1986. I flow chart erano e sono la base grafica per la programmazione e la progettazione.

Ricordo che alla presentazione non avevo fatto i conti con i driver del mouse. Il mio software era stato testato e provato con un mouse nel mio PC che aveva driver diversi da quelli installati nel PC dove stavo eseguendo la prova. A quei tempi il Personal Computer erano un mondo in piena evoluzione e per quanto fossero efficenti nel migliorare alcune funzionalità gestionali o progettuali vitali per le realtà industriali dell'epoca, per configurare un PC e renderlo pronto c'era bisogno di configurarlo e per questa operazione era necessario tempo e tecnici validi.

Una volta verificato che il mio programma non riusciva a collegarsi con il mouse ho installato il software grafico che avevo in possesso e che aveva anche i driver necessari per controllare il mouse.

Il programma era scritto in Turbo Pascal ma di li a poco avrei continuato con il C.

Da qualche parte bisogna iniziare

In questo blog parleremo in gran parte di archeologia embedded. Parleremo degli albori per me  e per quello che ho scoperto era una novità industriale in quell'epoca la programmazione di sistemi embedded. Questa nuova disciplina, la progettazione di sistemi elettronici ha investito il mondo industriale che insialmente ha cercato poi dopo quando la domanda è saturata a triturato softwaristi come fossero pomodori in esubero.

L'inizio al modo informtico per me è stato quando alla terza Itis sezione Informatica nel lontano 1985 lo zio Kim mi regalò alcuni libri di applicativi software che stava dismettendo.

Io ho imparato il linguaggio C in questa pubblicazione. Letto e studiato in modo metodico ho scritto compilato tutti gli esempi citati nel libro debuggato e verificato tutte le funzionalità possibili del C. Nel link seguente una delle edizioni successive.

http://www.uml.org.cn/c%2B%2B/pdf/C%2B%2BComplete%20Reference%20(3rd%20Ed.).pdf

A quel tempo non sapevo cosa significasse il termine oggetto che sarebbe venuto di li a poco con l'avvento del C++. Quello che nessuno immaginava e che i sistemi embedded nel 2019 avrebbero continuato senza alcun dubbio ad essere programmati in C.

Il mio primo PC lo acquistai a Firenze dalla prima sede della Computer Discount. Era un clone IBM che proveniva da Taiwan. La scheda era basata su un NEC V20 un clone dell'8088 della intel. Il monitor era a fosfori verdi ad alta persistenza che facevano davero tanto Matrix.  

Avevo due floppy uno da 51/4 pollici e uno da 31/2 nessun HD. A quel tempo tutta la memoria del DOS il sistema operativo doveva risiedere nei 640 Kbyte indirizzabili dal 8088. A quel tempo il buon Bill Gates pensava che quella memoria fosse sovrabbondante. Non si rese conto dell'incubo che di li a poco avrebbe creato ai softwareisti quando le applicazioni su PC incomiciavano a mangiare la memoria rendendo quei 640 K un terribile collo di bottiglia da superare. 

https://www.xtof.info/blog/?p=985


In tutti i casi ebbi il mio piccolo momento di celebrità quando mi accorsi che avevo in casa un PC due volte più veloce di quelli che usavo a scuola nei laboratori di informatica e con ancora più soddisfazione lo avevo pagato 5 volte meno. 

In quel momento ho capito il termine paraculo.


Gli altri libri che lo zio mi aveva lasciato erano i manuali per alcuni software in gran voga a quel tempo.

Il lotus 123 il primo spreadsheet 



https://it.wikipedia.org/wiki/Lotus_1-2-3

E uno di dBase IV il primo Dabase Relazionale dell'epoca.

https://it.wikipedia.org/wiki/DBase



Ricordo che in quegli anni mi chiamarono diverse aziende della zona. Una era la SKF

https://www.skf.com/it/index.html 

Ricordo che abbiamo avuto più di un colloquio con il CED interno per un posto di lavoro all'interno del CED. La cosa curiosa è stata al secondo colloquio quando il responsabile mi ha prospettato il lavoro informatico svelandomi la sala informatica dove erano contenuti tutti i dati aziendali di produzione. Il CED era una stanza fate conto di un centinaio di metri quadrati con tanti armadi disposti in fila e dentro anzichè avere computer avevano faldoni cartacei. 
Il lavoro era quello di copiare i faldoni cartacei in file di testo sopra un PC con un floppy esterno da 8 pollici.
Gli ho fatto vedere un applicativo che avevo sviluppato per delle agenzie immobiliari e che permetteva di caricare dati in modo sicuramente più agevole con delle semplici maschere. Quando vide il mio programma prendere il controllo del suo PC si spaventò allo stesso modo di come quando Atahualpa vide il cavallo la prima volta. Mi disse che non era questo il lavoro informatico al quale erano interessati e così finì li.

Gli Albori

Le prime esperienze nascono da qui con una console avanzata che mi consentiva di sperimentare i primi software sviluppati con l'interprete Basic incluso nel pacchetto.

La console era quella dell'ATARI 800 XL e così mio malgrado mi schierai nella guerra delle console che in quel tempo imperversava il mercato. Infatti i primi maker informatici si suddividevano fra Ataristi e Commodoristi.

In entrambi i casi la base Hardaware delle due console era la solita. Il micro che era un po' il cuore dei due sistemi era il mitico 6805 della Motorola. In questo link il datashhet

https://www.nxp.com/docs/en/data-sheet/MC68HC05X16.pdf

Benvenuti

Benvenuti in questo blog personale. Parleremo di tanti argomenti legati alle esperienze legate prevalentemente al mondo embedded che io e altri compagni di avventura abbiamo avuto in questi anni. 

A chi interessa e vuole, tutti possono partecipare condividendo le vostre avventure e perchè no anche i vostri disastri.

un abbraccio LK