Primi passi

[mariot91]

Ciao a tutti,sono uno studente di ingegneria elettrica e sto facendo una tesi sulla programmazione di microcontrollori. Non ho mai affrontato durante gli studi esami in merito quindi la mia conoscenza al livello elettronico è molto bassa.Di C ho delle basi ma sono sicuro di avere molto da imparare per la programmazione embedding(per me sconosciuta fino ad oggi).Per ora dovrei concentrarmi sulle modulazioni PWM.Ho provato ad iniziare con il control stick piccolo F28069 ma sto incontrando molte difficoltà sia nella comprensione dell'hardware sia al livello di programmazione.Potete consigliarmi la via migliore per avvicinarmi al programmazione embedding?quale prendere in alternativa al piccolo?(o va bene quello?)dove posso reperire materiale adatto a neofiti come me?(il materiale della ti mi sembra piuttosto avanzato e adatto a chi già ha familiarità con i microcontrollori).In conclusione quello che cerco sono delle buone dritte per iniziare,grazie a tutti per l'aiuto=)

[simo85]

Ciao, se vuoi cominciare a programmare un po' gli AVR (che non pone restrizioni con i compilatori, usa avr-gcc e le avr-binutils e avr-gdb, il tutto si può compilare tranquillamente con Linux) ti linko questo sito:

http://www.electronics.cat/en/

Potresti provare qualche schedina di facile implementazione e lavoreresti con un sistema opeativo Linux.

[mariot91]

Grazie mille per l'aiuto,tuttavia vorrei prendere qualcosa che piu' si avvicina al piccolo poiché in futuro dovro' usarlo.Ho letto dei vari PIC,arduino ecc ma non sapendo nulla al riguardo ho bisogno di qualche dritta sul modello da scegliere e sul materiale da consultare.

[obiuan]

Grazie mille per l'aiuto,tuttavia vorrei prendere qualcosa che piu' si avvicina al piccolo poiché in futuro dovro' usarlo.Ho letto dei vari PIC,arduino ecc ma non sapendo nulla al riguardo ho bisogno di qualche dritta sul modello da scegliere e sul materiale da consultare.

un attimo...PIC è una cosa, Arduino è un'altra...i PIC sono una famiglia di microcontrollori della Microchip molto usati a livello hobbistico, poco usati a livello professionale (perché sono una vera schifezza, a mio parere). L'arduino è una scheda a microcontrollore open source destinata allo sviluppo, il cui "core" è un processore della famiglia AVR della Atmel, che è quella che ti ha consigliato simo85 nel messaggio precedente, o della famiglia coreTex, basata su core ARM.

AVR e PIC sono due prodotti completamente differenti, perché alla Atmel le cose le sanno fare, alla microchip no. Se ti studi gli AVR, poi hai una buona base di partenza per tutti i microcontrollori di fascia professionale, se studi il PIC perdi più tempo a capire i work around per aggirare i suoi bachi che a studiare sul serio la programmadione embedded.

Gli ARM poi sono un'altra cosa ancora: 32 bit al posto di 8, e un core che ti apre un mondo di possibilità. Personalmente ti consiglierei di lasciar stare da subito il mondo Microchip per quanto riguarda i microcontrollori e il "digitale" in generale, e di andare con Atmel o coreTex che almeno usi da subito qualcosa che rischi ti torni utile poi nel mondo del lavoro.

la mia impressione, da quando è uscita la famiglia coreTex M0+, è che i processori a 8 e 16 bit piccoli siano destinati a finire molto presto, siano essi scadenti come i PIC, siano essi buoni come gli Atmel o ottimi come i Texax (famiglia MSP430, la migliore fino ad oggi secondo me). Quindi, visto che devi partire da zero, forso l'utilizzo dell'Arduino versione basata su coretex M3 (Arduino Due, con processore AT91SAM3X8E) potrebbe essere la scelta migliore.

[Paolino]

...i PIC sono una famiglia di microcontrollori della Microchip molto usati a livello hobbistico, poco usati a livello professionale (perché sono una vera schifezza, a mio parere).

Mi sento di contraddirti sull'impiego poco professionale dei PICMicro: vengono ampiamente usati! Sul fatto che siano delle "schifezze", anche qui potrei portare esempi contrari. Ogni microcontrollore (o famiglia di micro o Casa produttrice) ha i propri pregi e i propri difetti. Personalmente mi sono trovato davverobene con Microchip, male con ATMEL, bene con Zilog, male con Samsung, benino con Fujitsu...

Ciao.

Paolo.

[obiuan]

Mi sento di contraddirti sull'impiego poco professionale dei PICMicro: vengono ampiamente usati! Sul fatto che siano delle "schifezze", anche qui potrei portare esempi contrari. Ogni microcontrollore (o famiglia di micro o Casa produttrice) ha i propri pregi e i propri difetti. Personalmente mi sono trovato davverobene con Microchip, male con ATMEL, bene con Zilog, male con Samsung, benino con Fujitsu...
Ciao.
Paolo.

I core PIC hanno per come sono fatti un buco nel detect degli interrupt da pin nel momento in cui entri nel low power mode spinto (se ricordo bene, sono passati anni). Questo vale fino alla famiglia 18, dopo l'ultima cantonata non li ho più guardati quindi magari oggi c'è una famiglia migliore. Un buco del genere è più che sufficiente per bollare come inutilizzabile un microcontrollore in ambito industriale a basso consumo, visto che ti tocca andare in polling.

Altro buco: se un interrupt arriva fra il fetch e l'execute di un bit clear GIE, l'ISR viene lanciata e se alla fine ha un RETFIE il PIC stramaledetto esce dalla precedente BCF con GIE a 1, e quindi con interrupt abilitati quando non dovrebbero (e questo mi è costato, anni fa, vari giorni di sofferenze, 4 scomuniche e vari inviti a club internazionale della bestemmia, come socio onorario). Questa la ricordo con esattezza perché ho stampato la fine della discussione sul loro forum come monito per il futuro, e ce l'ho appesa al muro vicino alla scrivania).

Per quanto riguarda la professionalità microhip, ti invito a leggere le loro errata corridge.

Esempi:
PIC18F1220/1320 Rev. D0 Silicon/Data Sheet Errata
http://ww1.microchip.com/downloads/en/DeviceDoc/80175e.pdf

3. Module: Reset
It has been observed that in certain Reset conditions, including power-up, the first GOTO instruction
at address 0x0000 may not be executed. This
occurrence is rare and affects very few applications.
To determine if your system is affected, test a
statistically significant number of applications across
the operating temperature, voltage and frequency
ranges of the application. Affected systems will
repeatably fail normal testing. Systems not affected
will continue to not be affected over time.

Tradotto: abbiamo cappellato il circuito di reset, e non c'è work around. Se vuoi essere sicuro piglia tutti i tuoi prodotti e fagli un bell'ALT, quelli che partono sempre allora partono per sempre. MA STIAMO SCHERZANDO!?!?

E questa, poi, è stata l'ultima che gli abbiamo concesso:
PIC18F1220/1320 Rev. D0 Silicon/Data Sheet Errata
http://ww1.microchip.com/downloads/en/DeviceDoc/80244d.pdf

1. Module: Core
Certain combinations of code sequence, code
placement, VDD, FOSC and temperature may cause
the corruption of fetched instructions. A corrupted
instruction fetch will cause the part to execute an
incorrect instruction with unpredictable results.
Microchip cannot predict which combinations of
these conditions will cause this failure.
If this failure mechanism exists in your system, it
should become evident during statistically significant
preproduction testing using your particular code
sequence and placement (the minimum suggested
sample size is 100 units). Preproduction testing
should exercise all the functions of your application
across system variables. Any changes to code
should be tested in the same manner prior to being
implemented.
This issue has not been observed for FOSC up to
4 MHz with VDD up to 5.25V. If failures occur while
meeting both of these conditions, then the failures
are likely not related to this failure mechanism.

"it should become evident"....ok, all'ente approvante vado a dire che il mio sensore di CO "should give an alarm", PIC permettendo...LI ODIO! ...si nota?

...secondo me/noi, vanno bene per hobbisti o per prodotti industriali come i cagnolini di pezza con gli occhi che lampeggiano, che se anche si piantano non frega niente a nessuno

Aggiungo:

Ogni microcontrollore (o famiglia di micro o Casa produttrice) ha i propri pregi e i propri difetti.

Sono assolutamente d'accordo, ci mancherebbe, ma nella mia esperienza pochissime volte mi sono trovato ad aver a che fare con una combinazione di incompetenza e superficialità paragonabile a quella della Microchip. Secondo me, la Freescale per esempio ha ottimi prodotti, ma un'assistenza che per la mia esperienza è completamente assente, un po' meglio la Renesas ma con prodotti per me meno interessanti, ottima invece sotto molti aspetti la Texas. Ma sono tutte aziende serie, quando si parla di quelle si paragonano realtà allo stesso livello, Microchip secondo è proprio uno scalino sotto (nel digitale).

[Paolino]

Non voglio contestare quanto affermi (e dichiarato da Microchip stessa) circa il circuito di reset e quant'altro. Evidentemente sei (siete) stato(i) bravo(i) a mettere in crisi i dispositivi da voi impiegati con applicazioni dove quei prodotti non sono adatti. I PIC che hai citato non li ho utilizzati per applicazioni industriali (altri PIC18F e PIC24 invece sì) e cercherò di starci alla larga

Ribadisco invece che esperienze di altro genere, chiaramente non spinte come le quelle da te sviluppate, non mi hanno dato problematiche così serie.

Sulla competenza e professionalità del loro servizio al cliente (sia commerciale sia post-vendita, compresi i FAE) credo tu sia influenzato dal tuo dente avvelenato

Ciao.

Paolo.

[obiuan]

Sulla competenza e professionalità del loro servizio al cliente (sia commerciale sia post-vendita, compresi i FAE) credo tu sia influenzato dal tuo dente avvelenato

Con loro sono sicuramente poco obiettivo, su questo non ci piove...comunque non ho mai avuto a che fare con il loro servizio vendite di cui quindi non posso dire né bene né male.

Sul PIC24...

dai un'occhiata a questo:

PIC24F04KA201 Family
Silicon Errata and Data Sheet Clarification
http://ww1.microchip.com/downloads/en/DeviceDoc/80474b.pdf

Soprattutto a pagina 3, dove affermano:

2. Module: Core (Deep Sleep)
Deep Sleep wake-up sources may be ignored if
they occur just prior to entry into Deep Sleep
mode. As a result, the device may enter Deep
Sleep mode when it should not.
Work around
If possible, configure external Deep Sleep
wake-up sources to repeat themselves once. If
the device does enter Deep Sleep, the second
occurrence of the wake-up source will wake the
device.
Alternatively, synchronize the entry into Deep
Sleep with

come vedi, anche nei 24 c'è lo stesso problema...quando entri nel deep sleep puoi non uscirne, e non c'è work around (usa una sorgente di wake up che si ripeta non è a tutti gli effetti un work around). E' quello che dicevo sui PIC18...spero per te che non stia usando quell'integrato, ma sono intimamente convinto che ci siano gli stessi problemi su tutti, perché è una questione di design del core. Per esempio, nella famiglia MSP430 il deep sleep entra in realtà non all'istruzione che setta il bit LMP4 (low power mode 4), ma alla successiva, eliminando il problema. Qua si parla di un micro che ha una condizione di rise tale per cui può perdere completamente un interrupt...e se il "riarmo" dell'irq lo devi mettere per forza nella ISR? ti trovi col prodotto piantato e non ci puoi fare niente.

[Paolino]

Hai ragione! E sottolineo quanto affermato in precedenza: per taluni prodotti questi dispositivi non vanno bene. Per altro, sì. Per applicazioni a bassissimo consumo ho impiegato Samsung e NEC, in passato. Il deep sleep è una condizione che non mi è mai capitato di affrontare con i PIC e terrò in forte considerazione quanto hai scritto, nel caso in cui debba realizzare un'applicazione a batteria (con PIC).

Ciao.

Paolo.

P.S. Anche il PIC24F che hai citato non l'ho mai usato.

[GuidoB]

Potete consigliarmi la via migliore per avvicinarmi al programmazione embedding?

Ti consiglio questo corso introduttivo dell'Università del Texas. L'iscrizione è gratuita e tuttora aperta (credo non la chiuderanno mai). Ne avevamo parlato qui.
Potresti selezionare solo le parti che ti interessano, o meglio seguirlo tutto.