[OT] PIC, 8051, MCU e CPU varie

Es anche una panoramica relativa agli strumenti di sviluppo (piattaforme sulle quali girano, professionalità/livello hobbistico,facilità dei programmatori e loro reperibilità).

Testato:
Anche con 32u4 è possibile giusto ?

Certo che si, è fatto apposta per evitare il FTDI232. Ha il supporto per un Transceiver USB Full Speed, quindi anche bello veloce.

leo72:
Andrebbe fatto la distinzione fra gli oggetti in formato DIP (quindi usabili dagli hobbisti) e non.

Ma scherzi? Aspè che ti posto una cosa...

L'Hobbista può farsi tranquillamente queste cose:

La prima è una scheda di sviluppo per PIC a 8bit (PIC18F)
La seconda è per PIC a 16bit (PIC24 e dsPIC3x)
La terza è per PIC a 32bit (PIC32MX)

A destra puoi vedere degli adapter per TQFP a 64 pin e TQFP a 100 pin saldati a mano (!)




BaBBuino:
A destra puoi vedere degli adapter per TQFP a 64 pin e TQFP a 100 pin saldati a mano (!)

Dubito che un hobbista alle prime armi possa fare una cosa del genere. Sarebbe meglio fare la distinzione così il principiante sa dove dirigersi come prima scelta.

yoshi93:
Dubito che un hobbista alle prime armi possa fare una cosa del genere. Sarebbe meglio fare la distinzione così il principiante sa dove dirigersi come prima scelta.

Esatto.
Un hobbista come me gli SMD non li salda :sweat_smile:
O compra DIP oppure chip già saldati su breakout board.

Yoshi davo per scontato che si parlasse di Hobbisti "advanced".

Non credo che un principiante "niubbo" abbia necessità di usare DSP a 32bit e 100 MHz di clock per fare il suo Hello World, accendendo un led!

Diciamo che questo è il passaggio per chi si è stufato di Arduino perchè lo ha sondato in lungo ed in largo, e adesso ha la sensazione di girare in tondo. Per l' Hobbista principiante Arduino basta e avanza.

PS:
sono meravigliato dal datasheet del PIC.... è spiegato il Program Counter, come viene gestito lo stack, le modalità di indirizzamento della memoria.... incredibile. Nei d/s Atmel 'ste cose non le ho mai viste!

leo72:

yoshi93:
Dubito che un hobbista alle prime armi possa fare una cosa del genere. Sarebbe meglio fare la distinzione così il principiante sa dove dirigersi come prima scelta.

Esatto.
Un hobbista come me gli SMD non li salda :sweat_smile:
O compra DIP oppure chip già saldati su breakout board.

Non ci credo! Oramai non sei più un Hobbista alle prime armi, non fare il furbo! :smiley:

leo72:
PS:
sono meravigliato dal datasheet del PIC.... è spiegato il Program Counter, come viene gestito lo stack, le modalità di indirizzamento della memoria.... incredibile. Nei d/s Atmel 'ste cose non le ho mai viste!

Hai capito perchè i PIC sono simpatici?! :grin:

@Babbuino:
tu dici sempre che io mi sento a mio agio con Linux e non vedo il problema ad usare le schede embedded. Può essere vero :wink:
Io ora dico che tu sei troppo a tuo agio con la parte elettronica per cui un hobbista programmatore potrebbe voler usare un chip SMD ma potrebbe non essere in grado di saldarlo. :wink:

Un hobbista può scegliere qualsiasi cosa e i 32 bit funzionano bene anche per fare hello world! Comunque arduino per un hobbista elettronico non va bene perchè è altamente diseducativo (librerie già fatte e troppo astratte). Arduino nasce per gli artisti o per la prototipazione rapida ma va usato con parsimonia dall'elettronico interessato alla materia.

Sì, i pic sono un'altro mondo in quanto a professionalità.

@leo72:
Volendo c'è anche la pinguino della olimex che offre la possibilità di doppio ide (mplab x con strumenti di sviluppo microchip e ide arduinico).

Si, a poco soldo ci sono le schede OLIMEX, e qualche altra cosa di simile.

Per chi non vuole rimanere traumatizzato può partire con una scheda Pinguino, ma ancora meglio con una DIGILENT ChipKIT, che hanno lostesso IDE, le stesse librerie, e lo stesso C easy di Arduino.

Però insomma, già che ci siamo andiamo oltre l'IDE Arduinesco superfacile.

Aspè che posto altre foto di esperimenti passati...

BaBBuino:
Però insomma, già che ci siamo andiamo oltre l'IDE Arduinesco superfacile.

Concordo in pieno :).

Quà c'è l'ultimo anno di R&D che ho fatto:

PIC18, PIC24. dsPIC, PIC32MX, chipKit, Pinguino, Sanguino, Raspberry (bleah...), STM32, Stellaris, MSP430. E manca ancora qualcosa...

Ma... invece di lavorare, mi pare tu faccia i "balocchi" con le schedine, eh XD XD
Scherzo :wink:

Per i PIC32 (32 bit con core Mips) il compilatore XC32 è C++ a differenza degli altri compilatori che sono C ANSI.

Sono venuto a conoscenza del fatto che il compilatore XC32 è in realtà GCC, però ancora non ho avuto modo di studiare come sia possibile applicare a tale compilatore più licenze di cui una in cambio di una maggiore ottimizzazione del codice prodotto dal compilatore.

Posso provare ad immaginare, e visto che gcc è composto da programmi separati microchip può sviluppare closed source un modulo di GCC, chessò "cc1", partendo da zero o qualunque altro modulo come g++, o il frontend gcc stesso senza cadere in violazione della licenza di uso GPL. E questo mi sta benissimo, quello che mi da fastidio e che si eviti di menzionarlo nelle pagine principali del sito microchip e che per scoprirlo si è costretti a fare uso di google evoluto, e si perchè se cerchi gcc pic, non salta niente fuori ma se cerchi "GCC 4.5.1 released by Microchip" viene fuori questo MPLAB C Compiler for PIC32 v2.01, Release Notes

Sarò esagerato ma mi sembra il far west, dove ognuno fa quello che gli pare e lo sceriffo è un cagasotto.

Sarà anche un caso che il link al download di avr-gcc di Atmel sia venuto fuori da fonte non uffciale e che questo quasi dicesse non spargete la voce, ma quando anche il link a pic32-gcc si trova con difficoltà e lo stesso avviene per altri port di gcc mi sembra quasi che non vogliano farlo sapere in giro. Mah... sarà una mia impressione.

Ciao.

Quella pagina non è così nascosta :wink:
Se vai qui:
http://www.microchip.com/xcdemo/xcpluspromo.aspx
e poi clicchi in alto a destra la voce "read me" sotto a XC32 vieni ricondotto proprio a lei, anzi ad una versione più aggiornata.

Direi di concentrarci su un elemento per volta e poi riassumiamo.

Partendo dai PIC abbiamo la serie a 8bit, molto semplice da usare. Tralasciando i low-end PIC16, c'è la serie PIC18F, dove F sta per memoria Flash.

Un PIC18 di media classe, dispone di diverse periferiche standard, più o meno come un ATmega, e poi altre più particolari, come un Transceiver USB e perfino un Transceiver Ethernet (lo stack sotto forma di libreria viene fornito gratuitamente da MIcrochip), o configurazioni particolari. Per esempio ho utilizzato, su un macchinario a PLC, un PIC18F a 40 pin con ben 28 ingressi Analogici, tutti funzionanti.

Come strumenti di sviluppo principali ne esistono due: il già accennato MPLAB di Microchip, nella sua versione più vecchia (perfettamente efficiente) oppure nella sua reincarnazione con struttura sottostante in Netbeans, la versione X IDE (molto più ricca di ammenicoli, tanti anche inutili).
Ma questi sono solo IDE, il compilatore si installa a parte, anche se poi viene richiamato dall'IDE attraverso un path di riconoscimento.
I compilatori sono 2, anzi 3, il C18, quello che viene istallato con l'ambiente di lavoro e di una terza parte: l'HI-TECH C, e l'ultimo arrivato,
l'XC8, nato dalla fusione del C18 e dall'acquisizione del (migliore) Compilatore C della HI-TECH.

Ad un livello di astrazione più facile c'è l'ambiente di Mikroelektronika "MikroC PRO for PIC" che contiene già al suo interno delle librerie (chiuse, non modificabili) per quasi tutto quello che ci si può immaginare e di più (con il C18 le librerie bisogna andarsele a cercare in giro, un pò come con Arduino, ma genericamente si trova di tutto).

Direi che come intro può bastare. Bisogna procurarsi un PIC18F (suggerisco un 40 pin: PIC18F4550) il Compilatore e cominciare a scrivere qualcosa.

Diciamo che la parte più "diversa" da Arduino è il dover inizializzare le periferiche attraverso dei registri, per cui un'occhiata al Datasheet, almeno relativamente alla periferica che stiamo usando, bisogna darglielo.

Un esempio banale: di default (appena acceso o dopo un Reset) gli ingressi del PIC sono "lanciati" come analogici, quindi se non si fa uso dell'A/D, bisogna imporre una configuarzione dei pin come digitali, con una istruzione che richiama il registro dell'A/D.

Con queste istruzioni si tiene spenta la periferica A/D e i relativi pin multiplexabili, vengono settati come digitali.

ADCON0 = 0x00;
ADCON1 = 0x0F;

Ovviamente, ad un primo impatto, sono valori criptici ma basta prendere la tabella relativa a questi registri che tutto appare molto chiaro.

Un'ultima nota:
Le periferiche (UART, I2C, Timer, A/D etc.) possono essere utilizzate in due modi:

Pura (per i puristi, ma anche che sanno cosa fare nel dettaglio) cioè configurare, passo per passo, e manualmente, tutti i registri relativi ad una periferica (i registri possono essere uno, ma anche 5 o 6!), oppure affidarsi ad una libreria di funzioni.

Quindi per fare una acquisizione di un segnale analogico si può scrivere una sequenza di righe in successione logica per preparare l'A/D, definire il pin, i tempi di conversione, di sample, di attesa, di Interrupt, di fine conversione etc.

settare singolarmente tutti questi registri:
? ADDRESH
? ADDRESL
? ADCON0
? ADCON1
? ADCON2

// Abilito A0-A1 come ingressi analogico
// VREF sono impostate a massa e VCC
ADCON1 = 0b00001101;
// Seleziono AN1 come ingresso
ADCON0 = 0b00000100;
// Imposto i tempi di conversione e giustificazione a destra
// TAD : FOSC/4
// TACQ: 16 TAD
ADCON2 = 0b10110100;
// Abilito l' ADC
ADCON0 |= 0b00000001;

oppure scrivere semplicemente:

unsigned ADC_Read(unsigned short channel);

ovvero:

int val;
val = ADC_Read(2); //Leggo il valore dal canale 2 e lo assegno a val. Ovviamente devo #include la libreria relativa all'ADC.

Quest'ultima modalità vi sembra difficile, non vi ricorda "qualcosa"?

Beh, le cose d'uso comune conviene metterle in librerie, d'altronde le lib sono nate apposta per facilitare il riutilizzo del codice. E' snervante tutte le volte mettersi lì con il datasheet a vedere come configurare i registri per una certa cosa. La si fa, questa cosa, una volta per tutte e la si richiama secondo necessità.

Anzi, il fatto di dividere le cose in piccole lib (quella per l'ADC, per l'I2C ecc...) mi pare più efficiente rispetto ad un macro-core che contiene tutto, anche quello che non serve.