[OT ITA] Lo spamm bar (Part 1)

Intendi le FPGA?

Si, ma non solo, ce ne dovrebbero essere varie tipologie... PLA (Programmable Logic Array), PAL (Programmable Array Logic) simili alle precedenti ma con alcune differenze che ne cambiano alcuni vincoli, ROM (queste le conosco :wink: ). CPLD (Complex Programmable Logic Device) e FPGA (Field Programmable Gate Array) almeno, ho solo iniziato ad esplorare la punta dell'iceberg e ancora ne so praticamente zero.

maubarzi:
Mi piacerebbe approfondire un pelo per capire se potrebbero tornarmi utili o se sono troppo complessi per un uso hobbistico.

NON li ho mai ritenuti utili per uso hobbistico, sono cose da usare dove è richiesta altissima velocità e dove quello che si deve fare è descrivibile con una rete di porte logiche.

Con l'attuale panorama delle MCU e con la loro velocità (ci sono MCU che lavorano a centinaia di MHz), l'utilizzo di FPGA è veramente ristretto a specifiche applicazioni (es. interfaccie hardware, elaborazione di segnali, elaborazione di immagini, ...).

Inoltre VHDL ... non è il massimo della semplicità :smiley: :smiley: :smiley:

Guglielmo

Dovrebbero dare un pelo di flessibilità e compattezza in più all'hardware condensando in un unico cip cose che normalmente stanno su cip differenti.
Non ho controllato se in questo modo puoi aumentare la velocità globale, ma a quanto dici parrebbe di si, come ulteriore vantaggio.

gpb01:
sono cose da usare dove ... quello che si deve fare è descrivibile con una rete di porte logiche.

Di fatto si, ROM a parte che sono più lato software, le altre questo dovrebbero fare.

La domanda è nata da una discussione fatta con una persona che lavora in un'azienda che progetta schede di automazione, parlando della mia cronica incapacità di reperire i cip, mi ha chiesto perchè non usavo queste che con un unico cip mi configuro varie porte logiche o dispositivi logici.
Ora, per loro sarà il pane quotidiano, anche perchè magari si possono configurare schemi inusuali, vista la flessibilità, ma per uso hobbistico? forse è una inutile complicazione...

gpb01:
Inoltre VHDL ... non è il massimo della semplicità :smiley: :smiley: :smiley:

Presumo ci sia tutto un ambiente di sviluppo che consenta di simulare o quantomeno di tenere sotto controllo il risultato finale, oltre a "programmare" effettivamente il cip.
E poi mi domando come si sposi questa cosa con la produzione in serie...
Devi passarti i cip uno ad uno per programmarli, prima di montarli.
Magari ci sono dei dispositivi che lo fanno, sempre in automatico prima o durante il montaggio.
Perchè è vero che magari velocizzi la prototipazione, ma aggiungere un passaggio in più rallenta poi la produzione.
Dite che le aziende specializzate nella produzione PCB e montaggio a livello industriale siano attrezzate anche per questo? A naso mi verrebbe da dire di si.

maubarzi:
Ora, per loro sarà il pane quotidiano, anche perchè magari si possono configurare schemi inusuali, vista la flessibilità, ma per uso hobbistico? forse è una inutile complicazione...

... totalmente inutile !!!

Vuoi divertirti ed imparare ? ? ? ...

... Microchip "Curiosity", QUESTA, basata su PIC16F1619, MPLAB X, XC8, MCC ... e, oltre ad imparare a programmare in un ambiente diverso, impari ad usare le CIP (Core Independent Peripherals) tra le quali trovi anche delle CLC (porte logiche configurabili).

Se vuoi andare su cose più spinte, allora prendi la "Curiosity HPC", QUESTA,, prendi a parte un PIC18LF46K42 e ... vedrai che potrai fare belle cose :wink:

Puoi acquistare tutto sullo store Microchip (QUI) e ti arriva a casa in pochi giorni.

Guglielmo

A quanto detto da Guglielmo ci aggiungo un link su (CIP)

Comunque c'è tanto da studiare, sia che rimani su AVR (che hanno molto da dare) che con questi nuovi microcontroller con CIP.

Le logiche programmabili dalla loro hanno il vantaggio di potere eseguire dei processi in parallelo sincronizzandoli, ma parliamo di un altro mondo, altro modo di ragionare sempre ché si voglia realizzare un processo che ancora non è stato sintetizzato da altri.

Se scegli (e paghi) un ambiente completo hai anche una bella collezione di processi sintetizzati che usi un po come blocchetti (simili alle librerie), se il blocchetto non c'è te lo devi fare e non sempre basta un oscilloscopio.

Un esempio che con logiche programmabili e sicuramente con MCU con CIP sarebbe venuto meglio è il seguente brevemente descritto:

Io mi sono chiesto se potevo scrivere codice per avr che potesse replicare ciò che fa uno stepper driver, quindi full step, half step e microstep, bene ci sono riuscito usando le due uscite PWM connesse agli Enable dei due ponti H contenuti nel L298.
Posso accendere i bit nello stesso istante (se appartengono alla stessa porta es PORTD) ma non posso variare il PWM nello stesso istante in cui accendo i bit, o lo faccio prima o dopo e questo fa la differenza specie in microstepping.

Quindi se i circa quattro cicli CPU richiesti da quando si presenta l'evento a quando viene eseguita la ISR sono un problema, le logiche programmabili lo risolvono, ma in ogni cosa c'è il rovescio della medaglia. Questo è solo un esempio e si potrebbe dire che con ARM gli eventi sono gestiti senza ritardi ed è vero, ma anche li c'è il rovescio della medaglia, come c'è con i CIP, devi studiarti tutte le periferiche nei dettaglia e riuscire ad usarle con la stessa semplicità con cui blik un led su arduino.
Almeno da mio punto di vista, anche un attiny se studiato per bene porta risultati ed il mal di testa è assicurato e questo per ora mi basta.

... totalmente inutile !!!

Si e no allo stesso tempo, dipende da cosa ti porta in fibrillazione. Ma nel senso che hai chiesto tu sono solo rogne e zero produttività e tempi di apprendimento biblici.

Se cerchi rogne come me gli AVR sono più che sufficienti. :smiley:

Sti CIP mi stuzzicano, anche perché qualcosa di simile la ho desiderata in più occasioni.
Ciao.

Maurotec:
... Sti CIP mi stuzzicano, anche perché qualcosa di simile la ho desiderata in più occasioni.

Sempre senza voler fare pubblicità (... ma me tocca visto che le ho scritte io :smiley: :smiley: :smiley:), sui numeri 230, 231, 232, 233, 234 e 235 di Elettronica In sono già uscite 6 puntate del mio corso sulle CIP e sulla loro programmazione via MCC (proprio usando il PIC16F1619) e sul numero 236 (e forse 237, dipende se lo dividono in due) uscirà la 7 ed ultima puntata che usa il PIC18LF46K42 :wink:

Guglielmo

Guglielmo

Io questo me lo ricordo ma non avevo la trifase, probabilmente esisteva anche per la monofase.
Forse ne ho uno da qualche parte nella sua scatola!

zoomx:
Io questo me lo ricordo ma non avevo la trifase, probabilmente esisteva anche per la monofase.

Certamente, anche io ai bei tempi avevo questo:


Guglielmo

Si! E' lui! Il 1631!

gpb01:
Se vuoi andare su cose più spinte, allora prendi la "Curiosity HPC", QUESTA,, prendi a parte un PIC18LF46K42 e ... vedrai che potrai fare belle cose :wink:

Ho fatto un sopralluogo, interessante, per ora studio e poi nel caso compro.
Devo fare sempre i conti con la mia smisurata curiosità e la mia incapacità di starci effettivamente dietro :wink:

Maurotec:
A quanto detto da Guglielmo ci aggiungo un link su (CIP)

Grazie, essendo a zero su queste cose, un po' di roba da studiare me la piglio con piacere.
In alcuni casi ho già sentito l'esigenza, ma per ora ho cercato di risolvere con buffer giocando sul momento in cui dedicare il micro a certi compiti.
Tipicamente sulle comunicazioni che impegnano per lunghi periodi e sono difficilmente spezzettabili.
Su altre cose basta rateizzare i compiti :wink:

Maurotec:
Le logiche programmabili dalla loro hanno il vantaggio di potere eseguire dei processi in parallelo sincronizzandoli, ma parliamo di un altro mondo, altro modo di ragionare sempre ché si voglia realizzare un processo che ancora non è stato sintetizzato da altri.

Indubbiamente alla fine si può fare mooolto di più rispetto a quello per cui mi sono state "consigliate".
Il caso da cui era partito tutto era un semaforo quadruplo che avevo gestito, sulla carta, con due soli pin di Arduino e alcune porte AND e NOT per calcolare le accensioni in mutua esclusione alternate.
Di fatto usavo un pin per rosso e verde e uno per giallo. Per tutti e 4 i semafori a incrocio ad x, quindi pilotati uguali a 2 a 2 e opposti tra le coppie.
Quindi dovevano "risolvermi" il problema dei cip con le varie porte logiche, e quindi sarebbe stato un uso un po' becero rispetto alle effettive potenzialità :stuck_out_tongue:

Maurotec:
Un esempio che con logiche programmabili e sicuramente con MCU con CIP sarebbe venuto meglio è il seguente brevemente descritto:
...

Interessante come esempio, per passare un pelo oltre alla mera replica di porte logiche elementari.
Ovviamente qui si deve ragionare in logica booleana calandola poi nella pratica tenendo sotto controllo i ritardi di propagazione e la sincronizzazione.
Quindi non ragioni più in ternime di istruzioni ma di cicli di clock e fronti di salita/discesa e ritardi.
Una cosa che mi è sempre piaciuta ma che richiede un sacco di tempo per starci dietro.

Mi sono fatto una prima idea, grazie ad entrambi e k+.
Mi avete fatto da bussola :wink:

Ovviamente qui si deve ragionare in logica booleana calandola poi nella pratica tenendo sotto controllo i ritardi di propagazione e la sincronizzazione.
Quindi non ragioni più in ternime di istruzioni ma di cicli di clock e fronti di salita/discesa e ritardi.
Una cosa che mi è sempre piaciuta ma che richiede un sacco di tempo per starci dietro.

Per certi tipi di applicazione indipendentemente dal dispositivo che vuoi programmare sei costretto a rispettare
dei vincoli temporali per potere dire che l'applicazione non fallisce, alle volte basta usare una MCU più prestante, in altri casi e per altri motivi una MCU non è la soluzione adatta e non rimane altro che le logiche programmabili di cui alcuni chip mischiano CPU e logiche assieme.

PS: Esiste anche VHDL Analog di cui so che viene usato per creare dei modelli compatibili con alcuni simulatori
ad esempio Qucs.

vhdl analog

Devo fare sempre i conti con la mia smisurata curiosità e la mia incapacità di starci effettivamente dietro :wink:

Come ti capisco, per questo alle volte ho una infarinatura di questo e di quello che è meglio di niente e preferisco tornare ad approfondire gli AVR ed in genere le MCU. Poi per come sono fatto io che dopo sei mesi senza programmare rileggo miei programmi e mi meraviglio di ciò che ho scritto e fatico pure a capire e mi chiedo ma come ci sono arrivato. Quindi avrò un garbage collector nel mio cervello che non riesco a controllare. :smiley:

Ciao.

Io sento "odore" di PSoC. Solo che poi ti ritrovi la casa piena di sistemi di sviluppo! :smiley: :grinning:

Maurotec:
Come ti capisco, per questo alle volte ho una infarinatura di questo e di quello che è meglio di niente e preferisco tornare ad approfondire gli AVR ed in genere le MCU. Poi per come sono fatto io che dopo sei mesi senza programmare rileggo miei programmi e mi meraviglio di ciò che ho scritto e fatico pure a capire e mi chiedo ma come ci sono arrivato. Quindi avrò un garbage collector nel mio cervello che non riesco a controllare. :smiley:

Sei la mia fotocopia :wink:
A me piace infarinarmi su tutto, ma poi si aprono mondi sterminati se vuoi fare il passo successivo, quindi anche io per il momento resto sull'ATmega della UNO, quindi addirittura un sottoinsieme degli AVR, ma intanto spingo la mente oltre.
Per quanto riguarda il rileggere il proprio codice dopo mesi e non capirlo, io risolvo scrivendo più commenti che codice :stuck_out_tongue:
La mia memoria a breve termine è moooolto a breve termine, nella sala della memoria a lungo termine, invece, c'è l'eco :wink:

maubarzi:
Per quanto riguarda il rileggere il proprio codice dopo mesi e non capirlo, io risolvo scrivendo più commenti che codice

... posso suggerire a tutti l'utilizzo di "doxygen"?

E' il prodotto più usato ed è ormai uno standard di fatto. Se ben utilizzato, alla fine, vi genera pure il reference manual della vostra applicazione :wink:

Guglielmo

P.S.: Ad esempio tutti i codici generati da MCC (MPLAB Code Configurator) sono proprio commentati con l'utilizzo di "doxygen" :slight_smile:

maubarzi:
Sei la mia fotocopia :wink:

Per quanto riguarda il rileggere il proprio codice dopo mesi e non capirlo, io risolvo scrivendo più commenti che codice :stuck_out_tongue:

All'ora ci hanno fatti con lo stampino, dato che le vostre descrizioni si possono applicare anche a me, intendo a parte la mia superiore bellezza...

per quanto riguarda il commentare il codice, ricordo di aver letto qui sul forum, forse prima di iscrivermi quando era ancora un arduinista anonimo bustocco, che il buon programmatore in 'C' mette più righe vuote che righe scritte

Standardoil:
All'ora ci hanno fatti con lo stampino ... a parte la mia superiore bellezza

Fortunello ad essere stato stampato per primo a stampo ancora liscio e pulito :wink:

Fortuni si nasce
e modestamente.... io nacqui....

Io sapevo:
c'è chi può e chi non può... io può!