Documentazione MCU e CPU

[IsidoroKZ]

Questa e` una curiosita` nata da una osservazione che ho fatto en passant, dicendo che l'integrato con tutto dentro (BCM2835) non e` documentato pubblicamente. Per usarlo e quindi averne il data sheet bisogna firmare un NDA.

Mi e` stato risposto che questa situazione e` comune praticamente a tutti i microcontrollori e microprocessori sul mercato, sono tutti "chiusi" e non documentati.

A me la cosa risulta nuova: ho sempre immaginato che se uno vuole usare un microcontrollore anche di quelli complicati, ha la documentazione per progettare lo hardware e scriversi il software a partire da zero. Che poi convenga farlo e` un altro paio di maniche .

Com'e` la situazione? Come sono documentati i microcontrollori sul mercato? E i microprocessori, anche quelli di fascia alta tipo i 64bit?

E per le unita` o le schede video com'e` la situazione? TardoFreak, xyz e altri, che mi dite?

[TardoFreak]

Se l' integrato è un custom o semicustom o comunque un micro programmato in un certo modo (e quindi si comporta come un' altra cosa diversa da un micro vergine) è possibile.
I micro, le logiche programmabili e quant' altro hanno documentazione completa anche perché è interesse dei produttori fare in modo che vengano adottati ed utilizzati (e quindi comprati).
Ma se io realizzo un controllore di un qualsiasi cosa con un CPLD allora la documentazione ed i termini di utilizzo li decido io.

[posta10100]

Per quanto ne so la documentazione è solo parziale, copre solo la descrizione funzionale dell'IC.
Tutte le informazioni su come fare per accedere a "registri di configurazione nascosti" o alle procedure di test non sono scritte nei DS.
All'utente "normale" queste informazioni non servono, si limita ad usarlo.
Diverso è il discorso di chi acquista milioni di pezzi e vuole sapere esattamente come sono fatti.
In questo caso un NDA mi sembra il minimo.

Questo è un aspetto che non ho mai approfondito e le informazioni (poche peraltro) che ho non mi permettono di essere più preciso.

[IsidoroKZ]

Per quanto ne so la documentazione è solo parziale, copre solo la descrizione funzionale dell'IC.

Di quali processori stai parlando? Se e` il BCM2835, questo lo so, l'avevo scritto. Mi interessava la situazione per i microcontrollori "general purpose" e per i microprocessori ad esempio i5...

[posta10100]

Di quali processori stai parlando?

Io mi riferivo agli IC in generale. Che sia un processore, un modem o qualsiasi altra cosa.

Mi interessava la situazione per i microcontrollori "general purpose" e per i microprocessori

Prendi il datasheet di uno qualsiasi dei microcontrollori o microprocessori: hai mai visto le procedure per il test?

[giurom88]

Allora non era la Freescale a fare datasheet "orribili"...
Mi spiego meglio:
Ho avuto a che fare con una evaluation board Freescale (in particolare il kit M5234BCC) che montava a bordo un micro V2 Coldfire MCF5234 a 32 bit.
Tale microcontrollore è strapieno di periferiche interne, registri e roba varia, ma il datasheet ha si e no una 70ina di pagine molto blande (un semplice PIC16F628, che ha si e no un T/C ed una UART ne ha già 170), senza nemmeno fornire il set di istruzioni o eventuali info per programmarlo in C.
Morale della favola: programmarlo da 0 era impossibile...

[IsidoroKZ]

Prendi il datasheet di uno qualsiasi dei microcontrollori o microprocessori: hai mai visto le procedure per il test?

Adesso ho capito, grazie per le informazioni!

[TardoFreak]

... ma il datasheet ha si e no una 70ina di pagine molto blande (un semplice PIC16F628, che ha si e no un T/C ed una UART ne ha già 170), senza nemmeno fornire il set di istruzioni o eventuali info per programmarlo in C ...

non conosco freescale ma mi sembra molto strano anche se non nuovo.
Dico questo perché uso gli STM32 ed ho trovato una situazione analoga: datasheet specifico del micro incompleto.
Ho poi scoperto che dovevo fare anche riferimento anche al "Family Data Sheet", al datasheet del Cortex-M3 (il core), al manuale di programmazione del Cortex-M3 e forse anche a qualcosa d' altro.
Tutti questi documenti insieme non fanno la Treccani ... ma poco ci manca.

[xyz]

La documentazione per me è fondamentale quindi il chip deve essere per forza documentato altrimenti non lo prendo in considerazione, io aggiungo anche un ulteriore vincolo, devo avere i toolchain e i programmatori hardware funzionati sotto Linux anche se non ufficialmente rilasciati dal fabbricante. Le ditte che non sono Linux friendly vengono da me ignorate e boicottate

Il compilatore di riferimento per me è il GCC, permette il cross compiler, supporta praticamente tutte le CPU ancora sviluppate e alcune MCU. Come interfaccia per i programmatori hardware esiste un ottimo progetto open source OpenOCD per interfacciarsi al JTAG, sia per programmarlo che per fare il debug via GDB.

http://gcc.gnu.org
http://openocd.sourceforge.net

Come microcontrollori conosco molto bene gli Atmel AVR, ho diversi chip sotto mano, sono tutti ben documentati con documentazione e application note aggiornati. Supporto del GCC è ottimo, esiste una buona libreria C, diversi programmatori hardware, ottimi forum (non italiani) dove si trova di tutto. La casa madre supporta i tool sotto Linux, quindi per me Atmel viene promossa a pieni voti.

Ho tra le mani dei MSP430 della Texas Instruments, non ho mai avuto tempo di fare qualcosa di serio con questi chip, ho il programmatore e il compilatore GCC compilato apposta, se trovo qualcosa di adatto ci farò sicuramente qualcosa. Anche qui tutto ben documentato, al Texas Instruments ha un supporto minimo per Linux, non come Atmel ma c'è.

Gli ARM famiglia Cortex-M, architettura Harvard (tipica delle MCU) con set d'istruzione Thumb-2 a 16 bit, registri a 32 bit. Qui si divide in due la documentazione, la casa madre del ARM documenta molto bene la parte del set d'istruzione poi i vari fabbricanti come STM e Texas Instruments integrano con la propria. Molto spesso si trovano dei datasheet liberamente rilasciati che sfiorano il migliaio di pagine, se si conosce ARM i 2/3 della documentazione si può tralasciare concentrandosi sulle porte di I/O e device interni, questi devono per forza essere documentate. Il GCC supporta molto bene ARM, ultimante anche un altro compilatore molto particolare LLVM ha il supporto per ARM. Le varie case madri hanno un occhio di riguardo per gli utenti Windows ma ci sono una sei di appassionati che adattano i vari tool come OpenOCD al programmatore hardware. Ho tra le mani il LaunchPad Texas Instruments con ARM Cortex-M4 con il floating-point hardware, un vero lusso per chi proviene dalle MCU a 8 bit, il tool di sviluppo ufficiale esiste per Linux ma bisogna installare più dir 3 GB di programmi, i tool alternativi non ufficiali occupano molto di meno

Intel, qui si parla di CPU, i microntrollori come 8051 non gli ho mai usati anche se ho un compilatore SDCC che gli supporta. Le CPU vengono ben documentati ma Intel è famosa per le istruzioni non documentate, ad esempio per il 286/386 per farlo entrare in protected mode velocemente c'è l'istruzione LOADALL:

http://en.wikipedia.org/wiki/LOADALL

se uno disassemblava un vecchio driver per MSDOS della Microsoft HIMEM.SYS se la provava quindi, l'Intel alle ditte amiche forniva la documentazione seria, agli altri venivano omesse le istruzione avanzate, anche se poi in qualche modo trapelavano le informazioni. Le CPU Intel dopo il famoso baco della divisione in floating-point hanno un microcodice aggiornabile esternamente, questo microcodice non è documentato ma è possibile scaricarlo dal sito ufficiale Intel e aggiornare la propria CPU. Di solito viene fatto dal BIOS ma se non viene più aggiornato è possibile farlo se il kernel lo permette. Ad esempio se uno al boot legge una cosa del genere:

Atom PSE erratum detected, BIOS microcode update recommended

si informa e scarica il microcodice il quale non viene memorizzato permanentemente nella CPU ma viene caricato ogni volta al boot e aggiornato, ad esempio:

microcode: CPU0 sig=0x106c2, pf=0x4, revision=0x208
microcode: CPU0 updated to revision 0x218, date = 2009-04-10

solo i dipendenti Intel sanno cosa c'è nel microcodice e come programmarlo.

Gli ARM Cortex-A8/A9/A15 sono delle proprie vere CPU con architettura Von Neumann, set d'istruzioni a 32 e 16 bit, registri a 32 bit, istruzioni SIMD chiamate NEON. Anche qui come per i Cortex-M la documentazione è buona, tranne per la parte per il supporto Java (quello della Sun ora Orache) chiamato nelle ultime versioni Jazelle. Queste CPU sono usate in quasi tutti i cellulari con Android, la parte Jazelle se presente non viene usata, ormai in molti chip non è più presente visto che i cellulari Android si programmano in Java ma hanno una propria JVM e JIT molto diversa rispetto a quella ufficiale Oracle.

Le GPU, qui si entra nel modo della totale mancanza di documentazione, molti telefonini sono formati da un CPU e GPU in un unico chip, come le varie versioni del Tegra del nVidia, la CPU è un ARM ben documentata, la GPU non c'è nulla di pubblico, al massimo esistono i driver del fabbricante e una libreria di programmazione per le OpenGL-ES con al documentazione presente nel sito ufficiale:

http://www.khronos.org/opengles/

la programmazione della parte 2D e 3D ricalca quelle delle OpenGL classiche ma non si ha una pipe-line fissa come quella presente nelle prime versioni delle OpenGL. Le OpenGL-ES hanno un compilatore interno per i vertex shader e fragment shader per programmare tutti gli effetti che si vedono nei vari giochi di ultima generazione presenti nei cellulari e Tablet.

Quel chip della Broadcom BCM2835 è formata da una vecchia versione del ARM e una GPU, è la GPU non documentata come quella dei concorrenti, c'è una grossa competizione tra i fabbricanti per sviluppare la migliore GPU con basso consumo e alte prestazioni, se si riesce nell'obbiettivo i potenziali guadagni sono enormi visto il numero di telefonini e tablet venduti nel mondo. Il chip viene usato dalla Raspberry PI:

http://www.raspberrypi.org/

per quel chip stanno lavorando per migliorare le prestazioni sotto Wayland (un potenziale sostituto del X11) sotto Linux:

http://www.raspberrypi.org/archives/4053

per poter sfruttare il più possibile la GPU per tutta la parte grafica liberando ARM da alcuni compiti gravosi.

[posta10100]

Complimenti xyz, ottimo riassunto.

Come interfaccia per i programmatori hardware esiste un ottimo progetto open source OpenOCD per interfacciarsi al JTAG, sia per programmarlo che per fare il debug via GDB.

Permettimi di aggiungere che il JTAG presente su molti chip high-pin-count permette di utilizzare la boundary scan e di accedere alle parti più intime dei IC.
Da quella porta è possibile mettere il chip in TestMode per il testing su ATE (macchine per il test dei IC) caricando poi i pattern ATPG oppure lanciare un BIST.

Però si torna sempre al punto di partenza: le informazioni per utilizzarli? Solo chi produce tali chip e pochi altri eletti le hanno!
Prendiamo ad esempio il Reference Manual della famiglia PIC32, nelle tabelle 33.2 e successive ci sono le istruzioni che possono essere caricate nell'IR della TAP; tra queste ce ne sono alcune "Not Used" e altre "Reserved".
L'utente standard non avrà mai accesso a queste informazioni che chissà cosa possono andare a programmare, abilitare o disabilitare nel'IC.