Microcontrollori

[crovax]

Io ho iniziato(e ancora sono alle prime armi) con il Pierin del buon TardoFreak. Programmo in C e uso microcontrollori PIC, la versatilità è incredibile, e secondo me si impara molto più che con arduino!

ma ovviamente mi considero ancora più che un neofita in quest'ambito, quindi è solo la mia personalissima esperienza

[TardoFreak]

Il micro del Pierin è un bel micro, come tanti altri in verità.
Il fatto è che un conto è lavorare con un compilatore VERO, utilizzato anche per fare cose serie lavorando sul micro direttamente ed imparare ad usarne le periferiche.
E' un esercizio che dà come risultato della conoscenza vera che può sicuramente tornare utile in campo lavorativo.

Un altro conto è giocare con un compilatore FINTO, che prende decisioni autonome, che non visualizza gli errori ed utilizzare le librerie. In tal caso non s' impara nulla di utile, men che meno per il lavoro e si prendono vizi brutti e difficilmente eliminabili.

Provate a chiedere a qualcuno che programma micro per lavoro se accetterebbe di lavorare con un compilatore che prende decisioni autonome e non visualizza errori e warnigs. Vi chiederà se siete pazzi.
Non lavorerebbe mai e poi mai con un sistema del genere, neanche se minacciato con una pistola alla tempia.

Poi, per carità, non l' ha detto il dottore che si debbano usare in micro nel modo corretto eh!
Si può anche voler solo giocare. Allora arducoso va benissimo, il compilatore è pure gentile e bene educato. Ti dice sempre di si, ti da ragione e fa le cose per te, ti vuole bene, non ti offende, non è stronxo e non ti dice che hai sbagliato. Ne potrebbe anche scaturire un' amicizia sincera.
E non è un problema se poi il programma funziona "più o meno", tanto è solo un gioco.

[centurioneagrippa]

E' una buona idea utilizzare l'elettrovalvola solo che non sono molto pratico con l'elettronica perché girando in rete ho visto che utilizzano per far funzionare l'elettrovalvola un diodo,relay e varie resistenze e onestamente sta roba non so a che serve

[VRI]

Con entrambi i metodi, elettrovalvola o servomotore, dovrai passare prima da un relè o, da un "driver" di potenza elettronico...
Probabilmente, l'elettrovalvola è la soluzione più facile da implementare a livello meccanico.

[Shockwaver]

Vi chiederà se siete pazzi.
Non lavorerebbe mai e poi mai con un sistema del genere, neanche se minacciato con una pistola alla tempia.

Poi, per carità, non l' ha detto il dottore che si debbano usare in micro nel modo corretto eh!
Si può anche voler solo giocare. Allora arducoso va benissimo, il compilatore è pure gentile e bene educato. Ti dice sempre di si, ti da ragione e fa le cose per te, ti vuole bene, non ti offende, non è stronxo e non ti dice che hai sbagliato. Ne potrebbe anche scaturire un' amicizia sincera.

Ahahahahahahahaahahaha
Azz scusate l'ot ma sono ancora piegato in due!
E questo è TardoFreak.. un mostro di sapienza sui micro che poi ti fa sganasciare ahahaha azz mi scappa di pisciare

[obiuan]

Io insisto e vado contro corrente: sconsiglio caldamente l'utilizzo dei PIC, sia per applicazioni industriali che per imparare i micro.

Queste le mie motivazioni:
- la microchip emette un errata del silicio ogni due settimane, e spessissimo sono gravissimi. poi ti capita che non funziona un'accidente e devi passare ore a cercare fra gli errata se è un baco documentato..e poi scopri cose tipo "metti due nop dopo il primo org altrimenti rischi che carichi male 'istruzione successiva".
- hanno un assembler decisamente diverso da quello degli altri (chiaro, se li programmi in C non lo vedi) e hanno un'organizzazione della RAM/ROM diversa dagli altri, quindi imparando i PIC non ti rivendi poi le competenze acquisite
- non hanno debugger hardware: quando debugghi (che orribile inglesismo) rovini il flusso del codice. Gli altri micro (TUTTI) hanno un debugger hardware dentro, puoi mettere break point veri, leggere registri, ed il codice continua a girare come se il debugger non ci fosse
- hanno un interrupt solo...sono gli unici, se inizi con quelli poi ti abitui a buttare tutto nello stesso caldierone
- hanno un buco nell'uscita dal low power mode: se un interrupt da pin (e quindi asincrono) arriva fra il fetch e l'execute dell'istruzione di ingresso low power mode, il core non esce e resta piantato lì indefinitamente.
- c'è anche un baco nella lettura dei PIN subito dopo la commutazione uscita/ingresso...ma non ricordo più come lo si triggera

dal mio punto di vista, l'unico vero vantaggio dei PIC è il fatto che ancora li distribuiscono in DIP, e quindi sono facili da saldare. Per quanto riguarda i costi...una volta era vero, oggi con 10$ comperi la freeDom board della freescale e programmi su Coretex M0+...è un arm, 32 bit, e costa metà del PIC. E free hai anche un sistema operativo (MQX Lite).

[Shockwaver]

Scusami mi permetto di dissentire e con un po' di pazienza argomentare:

- la microchip emette un errata del silicio ogni due settimane, e spessissimo sono gravissimi. poi ti capita che non funziona un'accidente e devi passare ore a cercare fra gli errata se è un baco documentato..e poi scopri cose tipo "metti due nop dopo il primo org altrimenti rischi che carichi male 'istruzione successiva".

Se vai sul sito della MCHP e vai sulle MCU serie (DSP e 32bit) vedi poche versioni di DS e pochissime errata, perché prestano particolare attenzione alle unità di fascia medio alta. In più, se per le tue applicazioni opti per delle unità già abbastanza rodate, le soprese tendono a 0.

- hanno un assembler decisamente diverso da quello degli altri (chiaro, se li programmi in C non lo vedi) e hanno un'organizzazione della RAM/ROM diversa dagli altri, quindi imparando i PIC non ti rivendi poi le competenze acquisite

Non conosco nessuno che per del firmware serio (centinaia di K di codice) si metta a programmarli in asm linea per linea... snippet sì, inserzioni per un miglior controllo di una situazione (in genere intorno alle irq) ma mai vai a saturare una flash di una MCU da 256K in asm.

hanno un interrupt solo...sono gli unici, se inizi con quelli poi ti abitui a buttare tutto nello stesso caldierone

Non capisco cosa vuoi dire... i 32 bit li configuri facilmente multivectored e hai decine di diverse sorgenti di interrupt gestibili da altrettante ISR....

- hanno un buco nell'uscita dal low power mode: se un interrupt da pin (e quindi asincrono) arriva fra il fetch e l'execute dell'istruzione di ingresso low power mode, il core non esce e resta piantato lì indefinitamente.

Vero, ma con una rapida googlata trovi parecchi workaround (e.g. è sempre cosa buona e giusta disabilitare TUTTI gli interrupt che non servono al risveglio della CPU, prima dello sleep. Tra l'altro questo dobrebbe essere un must per TUTTI i micro che si utilizzano). Tra l'altro non vorrei dire una cavolata, ma m sembra che questa sia una cosa che hanno risolto già qualche anno fa, ripeto prendetela con tutto il beneficio del dubbio possibile.

- c'è anche un baco nella lettura dei PIN subito dopo la commutazione uscita/ingresso...ma non ricordo più come lo si triggera

Non ho ben chiaro a cosa ti riferisci, ma se è quello che penso io nei 32 bit hanno integrato sia le porte che i latch con i registri xxxSET xxxCLR e xxxINV per le operazioni monoatomiche sui GPIO risolvendo tra l'altro un baco, che onestamente però non ricordo bene, forse quello al quale ti riferivi?

l'unico vero vantaggio dei PIC è il fatto che ancora li distribuiscono in DIP, e quindi sono facili da saldare. Per quanto riguarda i costi...una volta era vero, oggi con 10$ comperi la freeDom board della freescale e programmi su Coretex M0+...è un arm, 32 bit, e costa metà del PIC

La MCHP non è l'unica a fornirli ancora anche dual inline, in più io compro 32 bit ad 80MHz a circa 3.50€ direttamente dalla MicrochipDirect (già programmati se voglio, con una spesa aggiuntiva di 0.30€) dove invece per MCU comparabili di altre case avrei dovuto spendere 6.00+€

Io insisto e vado contro corrente: sconsiglio caldamente l'utilizzo dei PIC, sia per applicazioni industriali che per imparare i micro.

I sono partito da 0 qualche anno fa, e con i PIC ora mi ci guadagno da vivere e non ho avuto grossissime lamentele o sorprese da sti pezzi di semiconduttore..

E free hai anche un sistema operativo (MQX Lite).

Non ti seccare ma FreeRTOS a me piace.. e poi MPLABX a parte qualche buggettino qua e là che comunque è continamente supportata è una IDE con i fiocchi.

[obiuan]

Se vai sul sito della MCHP e vai sulle MCU serie (DSP e 32bit) vedi poche versioni di DS e pochissime errata, perché prestano particolare attenzione alle unità di fascia medio alta. In più, se per le tue applicazioni opti per delle unità già abbastanza rodate, le soprese tendono a 0.

qui trovi 6 pagine di errata emessi tutti negli ultimi mesi, solo sui DSPic.

Non conosco nessuno che per del firmware serio (centinaia di K di codice) si metta a programmarli in asm linea per linea... snippet sì, inserzioni per un miglior controllo di una situazione (in genere intorno alle irq) ma mai vai a saturare una flash di una MCU da 256K in asm.

Discutibile la serietà o meno del firmware in ASM, diciamo che dipende dal livello di spremitura che vuoi ottenere dal micro. comunque, l'OP domandava con che micro partire, non con che micro realizzare un FW da centinaia di K...

hanno un interrupt solo...sono gli unici, se inizi con quelli poi ti abitui a buttare tutto nello stesso caldierone

Non capisco cosa vuoi dire... i 32 bit li configuri facilmente multivectored e hai decine di diverse sorgenti di interrupt gestibili da altrettante ISR....

mi riferivo ai PIC16 e 18 che mi sembra fossero l'intenzione di utilizzo dell'OP.

Vero, ma con una rapida googlata trovi parecchi workaround (e.g. è sempre cosa buona e giusta disabilitare TUTTI gli interrupt che non servono al risveglio della CPU, prima dello sleep. Tra l'altro questo dobrebbe essere un must per TUTTI i micro che si utilizzano). Tra l'altro non vorrei dire una cavolata, ma m sembra che questa sia una cosa che hanno risolto già qualche anno fa, ripeto prendetela con tutto il beneficio del dubbio possibile.

Ovvio, il problema si presenta proprio quando l'unico interrupt di risveglio dal low power mode è proprio quello asincrono da pin. Work around dici? certo, ne discussi diverse volte e a lungo direttamente con loro quando un nostro prodotto si piantava inesorabilmente in low power mode. Sai che mi hanno risposto? "metti un timer che risvegli comunque la CPU ogni tot e valuta il pin in polling". Io allora ho risposto loro "siete buoni solo per progettare le sorprese degli ovetti kinder" :)

Non ho ben chiaro a cosa ti riferisci, ma se è quello che penso io nei 32 bit hanno integrato sia le porte che i latch con i registri xxxSET xxxCLR e xxxINV per le operazioni monoatomiche sui GPIO risolvendo tra l'altro un baco, che onestamente però non ricordo bene, forse quello al quale ti riferivi?

Sì esatto, è un baco di progetto nell'architettura dei PIC16 e 18. L'OP non credo intendesse fare uso di dsPIC, o almeno così mi era parso di capire.

La MCHP non è l'unica a fornirli ancora anche dual inline, in più io compro 32 bit ad 80MHz a circa 3.50€ direttamente dalla MicrochipDirect (già programmati se voglio, con una spesa aggiuntiva di 0.30€) dove invece per MCU comparabili di altre case avrei dovuto spendere 6.00+€

qui vedi un bellissimo Coretex M3 a 100Mhz a 4€...e stiamo parlando di un ARM, mica di broccolini. Inoltre...suppongo che anche i dsPIC abbiano la divisione per 4 del clock giusto? quindi con 80Mhz vai a 20 in realtà, quindi sono paragonabili alla famiblia M0+, che trovi qui a partire da 1.1€ a comprarne uno.

I sono partito da 0 qualche anno fa, e con i PIC ora mi ci guadagno da vivere e non ho avuto grossissime lamentele o sorprese da sti pezzi di semiconduttore..

e ti auguro che mai ti succeda. A noi invece ne sono successe di tutti i colori, e mica solo coi PIC..la MicroChip ci mette del suo su tutto il digitale. Sono bravi sull'analogico dove hanno alcuni ottimi componenti...ma non è merito loro, hanno comprato un'azienda produttrice qualche anno fa (non ricordo il nome, ma erano bravi).

Non ti seccare ma FreeRTOS a me piace.. e poi MPLABX a parte qualche buggettino qua e là che comunque è continuamente supportata è una IDE con i fiocchi.

FreeRTOS in effetti non è male, ma su quali PIC gira? Su MPLABX..la versione nuova non l'ho usata a sufficienza, quindi non so dire. La precedente però era terribile :)

[Shockwaver]

qui trovi 6 pagine di errata emessi tutti negli ultimi mesi, solo sui DSPic.

Ma che c'entra parlare di tutti TUTTI i dsPIC? Ovvio che se tiri fuori una caterba di unità, fai un errore sulla famiglia la lista si pompa.
Ovviamente, invece, è da considerare SOLO quante errata per ogni singolo PIC visto che in genere non si lavora su TUTTI i dsPIC assieme ;)
Se vuoi ci spulciamo tutte le pagine e mettiamo su un grafico quante errata per ogni singolo PIC
Ad ogni modo in quel calderone ci sono anche i "Data Sheet Clarification" che non sono dei silicon errata...

Discutibile la serietà o meno del firmware in ASM, diciamo che dipende dal livello di spremitura che vuoi ottenere dal micro. comunque, l'OP domandava con che micro partire, non con che micro realizzare un FW da centinaia di K...

A parte fw con pochi K di codice non ho mai visto nessuno, né consiglierei mai a nessuno, programmare un micro solo in asm, come ad esempio, sempre restando su discorsi concreti, all'OP non direi mai "guarda per cominciare vai tutto di assembly, ti conviene!"... significherebbe volergli male... Quindi visto che molto tipicamente partirà col C il tuo discorso della differenza nel codice assembly lasciava un po' il tempo che trovava.

hanno un interrupt solo...sono gli unici, se inizi con quelli poi ti abitui a buttare tutto nello stesso caldierone

Non capisco cosa vuoi dire... i 32 bit li configuri facilmente multivectored e hai decine di diverse sorgenti di interrupt gestibili da altrettante ISR....

mi riferivo ai PIC16 e 18 che mi sembra fossero l'intenzione di utilizzo dell'OP.

Il tuo post evidenziava una critica sui PIC in generale e non in un qualche specifico. In più l'op ad ora non ha espresso alcuna intenzione su quali PIC utilizzare. Per cui, i PIC32 hanno la vectors table.

Ovvio, il problema si presenta proprio quando l'unico interrupt di risveglio dal low power mode è proprio quello asincrono da pin. Work around dici? certo, ne discussi diverse volte e a lungo direttamente con loro quando un nostro prodotto si piantava inesorabilmente in low power mode. Sai che mi hanno risposto? "metti un timer che risvegli comunque la CPU ogni tot e valuta il pin in polling". Io allora ho risposto loro "siete buoni solo per progettare le sorprese degli ovetti kinder" :)

Riesci a dirmi su quali PIC ti capitava e se ancora non hanno risolto? Perché sinceramente pur essendo a conoscenza del problema, con un po' di accorgimenti (non quello del timer... ) non mi è MAI capitato.

Sì esatto, è un baco di progetto nell'architettura dei PIC16 e 18. L'OP non credo intendesse fare uso di dsPIC, o almeno così mi era parso di capire.

Ripeto, non si è ancora espresso. Inoltre non credo che un glitch scarsamente triggerabile sulle porte possa dar troppo fastidio ad uno che, come me, per cominciare farà accendere e lampeggiare qualche led per poi starselo a guardare mezz'ora con un sorrisetto sul volto (sìsì non riuscivo assolutamente a compiacermi abbastanza per il risultato ottenuto ). Poi se oltre al gioco subentra anche la passione, sugli 8 bit non ci rimarrà più di due settimane, quindi il problema non si pone.

qui vedi un bellissimo Coretex M3 a 100Mhz a 4€...e stiamo parlando di un ARM, mica di broccolini.

Scusami se te lo dico, ma Questo Cortex M3 LPC1751FBD80 (da 4,44€) a cui sicuramente ti riferivi, visto cha a quel link era quello che costava meno con 100MHz, non potrai mai paragonarlo a Questo PIC32MX564F128H (da 3.68€), con core da 80 MHz/105 DMIPS MIPS32 M4K, mica broccolini!!!
I motivi?
LPC1751FBD80 vs PIC32M564F128H
Flash: 32 KB vs (128 + 12) KB
RAM: 8 KB vs 32 KB
ADC in: 6 vs 16
Timers: 4 vs 5
SPI: 1 vs 3
I2C: 2 vs 4
UART: 4 vs 6
Prezzo : 4,44€ vs 3.68€ con possibilità di preprogrammazione (gli schiaffi dentro il bootloader e ti dimentichi dell'interfaccia per il programmatore). Su 100 unità risparmi quasi 80€
E non voglio scendere nei dettagli tecnici.

Scusa ma per 20MHz non vengono giustificate le differenze, senza contare che avrei di meno in un package più grande...

suppongo che anche i dsPIC abbiano la divisione per 4 del clock giusto? quindi con 80Mhz vai a 20 in realtà, quindi sono paragonabili alla famiblia M0+, che trovi qui a partire da 1.1€ a comprarne uno.

Sbagliato. Nei PIC24 e quindi nei dsPIC viaggio a 40 MIPS. Nei PIC32 (quindi anche in quello di cui sopra) viaggio a 80MIPS puri... a 3.68€... e con la roba là sopra che supera il tuo Cortex M3 a 4.44€...

e ti auguro che mai ti succeda. A noi invece ne sono successe di tutti i colori, e mica solo coi PIC

Ti ringrazio. Mi dispiace per voi però che ci siete andati sfortunati!

FreeRTOS in effetti non è male, ma su quali PIC gira? Su MPLABX..la versione nuova non l'ho usata a sufficienza, quindi non so dire. La precedente però era terribile :)

Sui 32 bit, va veramente forte per tutta una serie di motivi tecnici incentrati sullo scarico della CPU da operzioni per le quali altri rtos la caricano maggiormente.
MPLAB 8 non era terribile.. bisognava solo saperci.. convivere
La generazione X della IDE e dei compilatori ne sa parecchio... Mi ci trovo benissimo... Sono solo in contatto col supporto MCHP perché mi stanno risolvendo un problemino sulla IDE per Mac, me per il resto sono soddisfattissimissimo

[Shockwaver]

Ah, comunque dimenticavo di dire una cosa... Adoro gli ARM. I fascia alta danno tanta di quella m...a ai PIC che non riescono più a uscirne fuori.
L'unica cosa che cercavo di evidenziare con questi post è che invece, a parità di fascia e quindi di prezzo, sempre IMHO visto quello che ho scritto in precedenza, i PIC ne sanno di più...