[OT] PIC, 8051, MCU e CPU varie

Testato, prova a industriarti sui PIC e ti si aprirà un Mondo fatato! :smiley:

Di librerie ne esistono a pacchi, molto più performanti di quelle arduinesche perchè spesso accompagnano il software dei Compilatori.

Microchip fornisce MPLAB, IDE gratuito (con qualche limitazione) che uno come te se lo beve in due giorni. Inoltre è accompagnato da innumerevoli librerie.

Se vuoi fare un passaggio meno traumatico, c'è l'IDE di Mikroelektronika, che ha tutte le librerie che ha Arduino ed anche più, utilizzabili liberamente in progetti commerciali SENZA LICENZE! :smiley:
Con questa IDE, la serial di un PIC a 32 BIT (ed anche altre, tipo TFT, GLCD, SPI, I2C) la inizializzi con righe anche più corte di quelle di Arduino...
Il C poi è più o meno lo stesso.

L'unica cosa è masticare un pò la configurazione dei registri, ma nulla di particolarmente complesso.

L'Infineon, per i propri 32 bit (n'altra reincarnazione del core ARM Cortex), ha sviluppato un IDE allucinante: prendi il disegnino della seriale, il blocchetto, e lo configuri senza scrivere una riga di codice. Lo fa lui per te, e questo per ogni modulo che vuoi implementare.

In 10 minuti fai un controller motore PID, con l'apposito blocchetto, senza scrivere una riga di codice. Oramai la strada per la programmazione è quella.

BaBBuino:
In 10 minuti fai un controller motore PID, con l'apposito blocchetto, senza scrivere una riga di codice. Oramai la strada per la programmazione è quella.

E poi scoppiano i razzi in volo :stuck_out_tongue_closed_eyes:

Comunque è vero che di librerie pic se ne trovano tante in giro però sono molto spesso piuttosto spartane e bisogna modificarle ogni volta per ogni dispositivo. Bisogna sapere cosa si sta facendo (e qui si rimpiangono gli oggetti).

leo72:

BaBBuino:
In 10 minuti fai un controller motore PID, con l'apposito blocchetto, senza scrivere una riga di codice. Oramai la strada per la programmazione è quella.

E poi scoppiano i razzi in volo :stuck_out_tongue_closed_eyes:

Già ... come QUESTO ... grazie ad un blocchetto float invece che double ... ma che vuoi, un blocchetto è come un altro, sempre un blocchetto è ... ]:smiley:

... maledetti programmatori LabVIEW™ XD XD XD

Guglielmo

(P.S. ... so esattamente ciò di cui parlo :grin: :grin: :grin: )

Grazie Babbuino, alla prossima idea realizzativa veramente metto mano ad un pic :slight_smile:

Guglielmo questo e' quello di cui mi raccontasti ? bella storia :stuck_out_tongue_closed_eyes:

@Guglielmo:
ti stavo pensando, mentre scrivevo. Mi tornava a mente questa storia che ci raccontasti a Bassano a colazione :stuck_out_tongue_closed_eyes:

Testato:
Guglielmo questo e' quello di cui mi raccontasti ? bella storia :stuck_out_tongue_closed_eyes:

leo72:
ti stavo pensando, mentre scrivevo. Mi tornava a mente questa storia che ci raccontasti a Bassano a colazione :stuck_out_tongue_closed_eyes:

Esatto ... è quella bella storia ... quella di un OTTIMO programmatore LabVIEW™ :grin: :grin: :grin:

... del resto, che cavolo, in fin dei conti che differenza volete che ci sia tra un blocchetto di un colore e quello di un altro ... sempre uno stupido blocchetto colorato che contiene una variabile è ... :wink:

Guglielmo

Ma i blocchietti di LabView hanno i dentini sopra, come i mattoncini Lego?? :stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes:

Il problema dei blocchetti LabView è che bisogna avere un buon Ottico. (chi l'ha capita vince un Led bruciato!)

leo72:
Ma i blocchietti di LabView hanno i dentini sopra, come i mattoncini Lego?? :stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes:

No, ma ti assicuro che se sei un cane di programmatore, C o LabVIEW™ ... sempre cagate fai (... mi si scusi il termine) ... indipendentemente dallo strumento di sviluppo ...

In allegato il peggio del peggio di un programma LabVIEW™ XD XD XD XD

Guglielmo

P.S. : @BaBBuino ... appunto ... :grin: :smiley: :grin:

Conosco quel Progetto. Il Progettista si è suicidato appena lo ha terminato... :grin:

Tornando in tema PIC, le librerie di cui parlo, ovviamente, sono quelle fornite dal produttore del Compilatore, e non fornite da terzi e/o appassionati, se no si torna indietro al concetto di Arduino-hobbistico.

Credo che i PIC siano la naturale evoluzione di un Arduinista, anche migliore, come Via, del passaggio ad AVR e AvrStudio.

Ragazzi, sul SAM3 di Atmel non trova quasi nulla, sui PIC a 32 bit, ma anche i potentissimi dsPIC, si trova qualunque tipo di progetto, come per Arduino.

Mi domando come mai i PIC siano un po' snobbati dal mondo professionale, che si rivolge ad altro. Eppure ci sono chip TQFP a 100pin da 80MHz e 105MIPS che costano 6 euro, meno di un ATMega644 da 40pin e miseri 16MIPS.

Dovreste vedere con che differenza di velocità gira la demo grafica su lcd tft UTFT su un PIC32, non solo rispetto alla Arduino MEGA, ma anche alla DUE!

Non sono snobbati, solo che fino a poco tempo fa non esisteva un compilatore C libero per i PIC. E quindi o pagavi o ti rivolgevi ad altro (vedi Atmel).

Mah... non mi convince! Nel professionale l'ultimo dei problemi è il costo del Compilatore. Core ARM, Renesas, Freescale e soci usano strumenti come IAR, KEIL ed altri che non sono propriamente economici.

Ah, se si parla di professionale (non avevo letto bene, scusa) allora è un altro paio di maniche e Microchip batte Atmel senza discussioni.

lock:
E sono arrivati anche core 8051 a 100MIPS su 100Mhz di clock, sempre ad 8 bit, ma hanno riprogettato il core con tecniche e trucchetti RISC e filano come razzi.
Notare che il primo 8051 con 10Mhz di clock tirava fuori esattamente 1MIPS =D

Ammazza che schifo! 1MIPS con 10MHz! :smiley:

Chissà come mai campa ancora così tanto il core 8051. Il fatto che sia uno standard industriale radicato non può essere la sola ragione. Mah...

Cmq, se non c'è l'esigenza di intallare veri sistemi operativi, quando hai 100 MIPS e un piccolo RTOS, ci fai di tutto. Se poi campioni dei segnali allora ti rivolgi ad un DSP, che arrivano anche a 1GHz, ma senza andare a cercare conversioni per i Radar, quando hai 200 MIPS con blocco hardware per divisione e istruzioni MAC (moltiplicatore+addizione) in un singolo ciclo di clock, ci fai qualsiasi cosa in ambito industriale non specifico.

Cmq ribadisco: l'evoluzione successiva dell' Homo Arduinicum sono i PIC, partendo almeno dai PIC18.

BaBBuino:
Ammazza che schifo! 1MIPS con 10MHz! :smiley:

"ammazza che schifo"?!? :sweat_smile:
Stai parlando di una MPU nata 33 anni fa! :wink:

Cmq ribadisco: l'evoluzione successiva dell' Homo Arduinicum sono i PIC, partendo almeno dai PIC18.

I dsPIC33 mi intrigano parecchio. Sono a 16 bit ed in formato DIP...

Join the DarkSide, we have 16bit. :grin: :grin: :grin:

Il "Light Side" non ce l'ha...

Leo e pensa che la gestione del dspic33 è completamente trasparente. Pensavo ci fossero complesse istruzioni Assembly per sfruttare la potenza matematica del Core, ed invece è di una semplicità disarmante perché provvede a tutto il Compilatore.

Se vuoi fare, chessò, una funzione sinusoidale in PWM, con una tabella di seno, la fai allo stesso modo di una normale MCU, solo che viene eseguita 10 volte più velocemente!

Almeno per applicazioni amatoriali, un ds può essere usato con profitto, senza troppe complicazioni. Per esempio lo vedo bene nella gestione di librerie grafiche per display GLCD e/o TFT, visto che tutte le funzioni grafiche di disegno fanno uso di routine matematiche.

BaBBuino:
Leo e pensa che la gestione del dspic33 è completamente trasparente. Pensavo ci fossero complesse istruzioni Assembly per sfruttare la potenza matematica del Core, ed invece è di una semplicità disarmante perché provvede a tutto il Compilatore.

Che compilatore usi, tu?
So che Microchip distribuisce un compilatore free che ha come unico limite la non ottimizzazione spinta del codice. Il che, per un hobbista, è una mancanza assolutamente non avvertita.