Newsgroup: it.hobby.elettronica.digitale
Titolo: efficienza C

Ciao a tutti!
Sono alle prime armi con il C :-) mi viene un dubbio, venendo dal PicBasic 
dove ovviamente le variabile erano solo globali, ora con il C capisco cosa 
siano quelle di tipo locali, ora usando in C noto che le variabili locali 
permettono secondo me la portabilita' del codice infatti basta prendere una 
funzione con tutte le sue varibili locali ed usarla in qualche altro 
programma, addirittura senza toccare nulla si puo' usare su altre 
piattaforme.
Ora quello che chiedo, dal punto di vista dell' efficienza cioe' dalla 
velocita' di esecuzione del programma e dall'occupazione di codice e' piu' 
efficiente usare variabili locali o globali, faccio anche questa domanda 
perche' mi sembra dai studi che sto facendo che quando si usano le variabili 
locali e si deve passare un valore ad un' altra funzione vengono create 
delle copie della stessa, quindi ci vogliono piu' risorse? 

 delle copie della stessa, quindi ci vogliono piu' risorse? 
Quando si chiama una funzione c'è sempre un passaggio dei dati 
dell'interfaccia (i parametri).
Non so argomentare ma ricordo che dal punto di vista delle prestazioni 
le variabili globali erano sconsigliate, se dovessi azzardare un motivo 
direi che è legato all'allocazione in area heap rispetto che in area 
stack delle variabili globali.

 stack delle variabili globali.
Esatto. Per le globali occorre un indirizzo assoluto, che generalmente č
piů lungo dell'indirizzo relativo (allo stack pointer) delle locali.

 più lungo dell'indirizzo relativo (allo stack pointer) delle locali.
Non è certo quello il problema. Nell'heap le variabili globali ci 
rimangono fino alla fine dell'esecuzione del programma, l'heap non 
contiene garbage e una volta definita la sua allocazione rimane 
quella (tranne durante l'utilizzo di allocazioni di memoria 
dinamiche). Quindi definire troppe variabili (e costanti) globali  
porta ad un uso della memoria eccessivo e soprattutto statico (senza 
possibilità di riprendersi lo spazio di allocazione fino alla fine 
del programma). La dimensione dello stack è invece continuamente 
variabile, si aggiungono e si tolgono cose. Definendo variabili 
locali esse usano la memoria necessaria SOLO quando vengono 
effettivamente utilizzate e vengono eliminate (riprendendo spazio 
nello stack) quando cessa la loro validità di esecuzione. Inoltre 
l'uso di variabili globali distrugge un po' il senso di costruzione a
black box modulari delle funzioni, limita la portabilità e rende più 
difficile il debugging (e più facile la possibilità di incappare in 
bug difficili da scovare).
-- 
"E=Mc^5...nahhh...E=Mc^4...nahh...E=Mc^3...ah, the hell with it."
News 2002 [v 2.3] / StopDialer / PopDuster - 
http://www.socket2000.com
Akapulce portal: 
http://www.akapulce.net

 Non è certo quello il problema.
L'OP scrive: "Sono alle prime armi con il C" e poi chiede "Ora quello che
chiedo, dal punto di vista dell' efficienza cioe' dalla velocita' di
esecuzione del programma e dall'occupazione di codice e' piu' 
efficiente usare variabili locali o globali".
Due di Picche, che sa cosa sono i CISC e ne parla a proposito come parla di
diserbanti ed anticrittogamici (è di questo che tui vuoi vendicare, l'aver
dimostrato di non sapere la differenza tra fanerogame e crittogame, cosa
che dovresti aver imparato a scuola?), parte con una supercazzola che non
potrà che confondere l'OP, tesa solo a dimostrare quanto ce l'ha lungo.
Ma la vuoi smettere una buona volta?

 delle copie della stessa, quindi ci vogliono piu' risorse?
Nel caso particolare dei PIC, questi non hanno un normale
stack come il 90% delle cpu, e perciò il compilatore deve
in qualche modo "simulare" lo stack via software.
Per questo motivo le variabili globali e il passaggio dei parametri
a mezzo di puntatori sono in ogni caso più efficienti.
Con altre CPU più idonee al C invece le differenze possono
essere irrilevanti.

Ringrazio tutti per le risposte, pero' i dubbi rimangono, capirete che 
venendo dal Basic per me e' immediato dichiarare variabili globali, quindi 
volevo capire se valeva la pena sforzarsi per usare quelle locali, da 
incompetente quale sono, ho notato come dicevo nel messaggio originale, che 
definendo funzioni con le proprie variabili, quindi locali ho notato che 
creo una struttura che se vogliamo e' autonoma che posso copiare ed 
incollare in un altro programma, sicuro che fara' la stessa cosa che acnhe 
nell' altro programma faceva, quindi da qui ho capito che e' ottimo per la 
portabilita', ma tutto finisce qui? 

 efficiente usare variabili locali o globali".
Allora facci ridere. Spiega la definizione di: "Per le globali 
occorre un indirizzo assoluto, che generalmente è più lungo 
dell'indirizzo relativo" ma soprattutto spiega perchè mai lo stack 
dovrebbe stare in un indirizzo relativo e l'heap no. Poi spiega come 
sono gestiti l'heap e lo stack in un microcontrollore...
-- 
People who deal with bits should expect to get bitten.  - Jon Bentley


 sono gestiti l'heap e lo stack in un microcontrollore...
In un microcontrollore? Quale? Sai, ne ho usati parecchi.
Tu, piuttosto, mi spieghi cosa vuoi da me?
E' vero, prima dell'attacco sull'ingegnere non ti avevo mai notato. Mi ero
dimenticato delle tue spiegazioni sugli OGM basate sul fatto che gli
anticrittogamici sono erbicidi, con tanto di buffissima spiegazione.
E' vero, nonostante ogni tanto te ne uscissi con una nuova minchiata, non
ti ho notato per mesi e continuerei a non notarti, se non fosse per questo
tuo ossessivo attaccarti al mio culo.
Non so dirti perché, forse perché sei una persona banale. Non so che dirti.
Tra l'altro, scusa se te lo chiedo, ma cosa ci stai a fare in questi NG?
Per chiedere aiuto no di certo, visto che sai già tutto.
Per darne nemmeno, visto che non leggi le domande di chi chede aiuto.
E' solo perché preferisci essere trattato come una pezza da piedi che
essere ignorato? In effetti questo giustificherebbe le tue sbruffonate.
 Meglio coprirsi di ridicolo sparandole grosse che essere ignorato, eh?

 Tu, piuttosto, mi spieghi cosa vuoi da me?
Sei in un gruppo pubblico, se spari minchiate ci sarà qualcuno che te
le farà notare.
-- 
My sister opened a computer store in Hawaii. She sells C shells by the seashore.


diego ha scritto:

ti propondo 2 frammenti uno che usa le variabile locali e l'altro che 
usa una variabile globale :
void a() {
int i;
   for(i=0;i<3;i++) {
     putchar('c');
   }
}
void b() {
int i;
   for(i=0;i<3;i++) {
     a();
   }
}
il secondo frammento
int i;
void a() {
   for(i=0;i<3;i++) {
     putchar('c');
   }
}
void b() {
   for(i=0;i<3;i++) {
     a();
   }
}
apparentemente sono MOLTO simili
b() chiama a() tre volte e b() stampa tre colta il carattere 'c'
ma .....
il primo funziona , il secondo no ;-) ( il perche' sta a te scoprirlo )
nel primo la funzione a() e' autonoma, non dipende infatti da alcun 
contesto, a() non "occupa" risorse ( la variabile globale i del secondo 
esempio )
le variabili locali aiutano molto nel processo di "isolare" le singole 
funzioni , cioe' nel fare in modo che siano autonome.


Il secondo usa la varibile i che e' globale ed e'  comune alle due funzioni 
pertanto non funziona, comunque nel post iniziale chiedevo altro tu sembra 
voglia spiegarmi cosa e' una varibile locale da un globale, e' vero che ho 
scritto da qualche parte che non sono esperto ma................

scritto da qualche parte che non sono esperto ma................
Il discorso delle variabili globali è complesso, se parli con un programmatore
ti dirà sempre che sono da evitare, come anche l'uso del Goto per esempio
La mia opinione è che si debbono usaro solo quando è indispensabile, ma se ci
vogliono meglio metterle piuttosto che fare artifici strani per evitarle.
Riguardo alle risorse impiegate, le varibili locali (quelle passate alla
funzione come parametri, non come l'esempio precedente) usano le locazioni di
memoria nello stack, quindi vengono recuperate dal sistema quando esci dalla
funzione stessa.
Se le variabili sono globali le dovrai inizializzare una volta sola al reset e
saranno indirizzate direttamente dalla funzione che le usa.
Questo porterà ad una diminuzione della memoria disponibile al programma, dal
punto della velocità le cose sono simili, perchè un PUSH e un POP in genere
equivalgono ad un LD e ad un ST.
In conclusione, se pensi che una variabile ti serva in diverse parti del
programma usala pure, ma non chiamarla Pippo o i, il trucco è usare un nome che
possa essere univoco per le variabili globali, ed è bene anche dichiararle nello
stesso posto.
Ad esempio in VB io uso fare un modulo chiamato Global.bas che serve
esclusivamente per dichiarare le variavili e gli array globali, e non ho mai
avuto problemi con le GLOBAL.
--
ciao
  Stefano

 le farà notare.
Al momento mi pare si notino solo le tue.

 Due di Picche:

Vedo che continui a non rispondere. E' semplice, hai fatto una 
affermazione:
"....Per le globali occorre un indirizzo assoluto, che generalmente è
più lungo dell'indirizzo relativo (allo stack pointer) delle 
locali..."
Ora sviluppa il concetto a noi *profani* ignoranti...
-- 
Honey, I Formatted the Kid!


 equivalgono ad un LD e ad un ST.
Esatto, infatti non cambia tanto l'efficienza di un programma (come 
qualcuno pensa) ma la filosofia di utilizzo della memoria e lo stile 
di programmazione. Da notare che nel caso di utilizzo sui 
microcontrollori (che solitamente non dispongono di una gestione 
avanzata dello stack e dell'heap) la differenza tra variabile globale
e locale assume invece una connotazione più netta ed importante. Nel 
caso di microcontrollore con a bordo una porzione limitata di RAM 
cosa succede? Succede che le variabili globali DEVONO occupare delle 
ben precise locazioni di tale RAM e se sono troppe non è possibile 
neppure riuscire a compilare il listato. Le locali, invece, essendo 
valide solo all'interno della loro area, possono occupare gli stessi 
spazi di RAM di altre variabili locali (di altre funzioni) senza 
portare all'out of memory.
-- 
To iterate is human; to recurse, divine.  - Robert Heller



Quindi se si programmano microcontrollori sarebbe meglio usare quelle locali 
che alla fine della funzione vengono distrutte e quindi lo spazio in ram 
viene rilasciato per altre varibili? se invece la variabile e' locale e di 
tipo static vale lo stesso discorso delle globali? 

 tipo static vale lo stesso discorso delle globali? 
Si, le variabili static devono mantenere il loro valore anche quando 
è cessata la funzione che le contiene, quindi non possono venir 
distrutte.
-- 
If a program is useless, it must be documented.


 Ora sviluppa il concetto a noi *profani* ignoranti...
Ma come? Vabbé sbruffone, ma addirittura il plurale majestatis?

 avuto problemi con le GLOBAL.
Mumble. Avevo capito che trafficasse con dei microcontoller...

 Ma come? Vabbé sbruffone, ma addirittura il plurale majestatis?
E non rispondi... Guarda che la tecnica dello svicolamento è 
vecchia...
-- 
Never trust a computer you can't throw out the window.  - S. Hunt


Mumble. Avevo capito che trafficasse con dei microcontoller...
Si, ho scritto un esempio in VB perchè li so che si usa spesso il Global.bas, se
avessi proposto un Global.h magari mi attiravo gli strali di qualche talebano
del C.
--
ciao
  Stefano

 Robe del genere sono più da stupidi che da talebani.
Beh, dipende dal contesto.
Avere un accessor, (la GetTemper) può far comodo per evitare di dare 
l'accesso in scrittura o per garantire che vengano fatte delle 
operazioni prima/dopo la lettura. E se l'accessor lo implementi con 
una macro o una funzione inline non hai nemmeno overhead. Io li uso 
spesso. Inoltre, se come dici la temperatura veniva letta sotto irq, 
avere l'accessor è quasi d'obbligo per incapsulare la lettura in un 
blocco a interrupt disabilitati ed evitare race conditions.
Più che a non usare le variabili globali a priori io sono contrario a 
usarle come mezzo di comunicazione implicito tra parti diverse di codice.
A meno di casi speciali (vedi irq che spesso non possono prendere 
parametri), avere un passaggio implicito di dati da una parte 
all'altra del codice, se il progetto è un minimo complesso, rende 
tutto molto, molto, molto complicato da gestire e capire via via che 
il firmware cresce.
-- 
  _|/ Francesco Sacchi - Develer S.r.l., R&D dept.
   |\ 
http://www.develer.com/
 - 
http://www.bertos.org

 
d'accordissimo. Ora che i microcontrollori che utilizzo mi consentono di 
lavorare in questo modo è veramente una pacchia in termini di pulizia 
del codice e di conseguenza di gestione.

 all'altra del codice,
Il passaggio, però, è implicito fino ad un certo punto: dovrai pur scrivere
nel codice il nome della variabile, pari pari come scrivi il nome
dell'accessor. La differenza sono un tot di inutili push e pop. O sbaglio?
Quanto alle race conditions, non ho escluso i semafori dal novero dei
costrutti minimi necessari.

 vecchia...
A chi dovrei rispondere? Al maestrino ignorante e cagacazzi?

 del C.
Beh, un .h che alloca memoria è davvero una cosa brutta brutta brutta...

 A chi dovrei rispondere? Al maestrino ignorante e cagacazzi?
Per amore tuo, dopo la stron%ata delle variabili globali e locali, 
sarebbe stato meglio farlo...
Ti schernivi dicendo che di elettronica capivi poco perchè eri 
informatico e si scopre che manco l'informatica conosci... Mah...
-- 
Try not to let implementation details sneak into design documents.


 Per amore tuo,
Lo so che mi pensi sempre, lo hai già scritto, ma non solo non sono
omosessuale, non sono neppure interessato alle personi banali e meschine.

 omosessuale, non sono neppure interessato alle personi banali e meschine.
Sei solo interessato alle fregnacce vedo...
-- 
..Do mimes listen to blank tapes? 


 Sei solo interessato alle fregnacce vedo...
Non le definirei "acce". Anzi, ultimamente sono ottime, oltreché
abbondanti. E tu, a uomini, come sei messo? Hai trovato qualcuno che
corrisponda i tuoi sentimenti, dopo la delusione che hai avuto con me? A
leggerti parrebbe di no...

blocco a interrupt disabilitati ed evitare race conditions.
Si trattava della lettura di un dato elaborato da una mia routine (in asm)
linkata da un mio collaboratore che vuole usare il C, il dato è accompagnato da
un bit in un byte di stato per la validità.
Mi è sembrato una cosa abbastanza inutile, ma quando gliel'ho chiesto lui mi ha
risposto circa come te, in ogni caso rispetto il vostro parere e pazienza se
spreca un pò di tempo su e giù per lo stack a chiamare una funzione invece che
leggere un dato.
--
ciao
  Stefano

Beh, un .h che alloca memoria è davvero una cosa brutta brutta brutta...
Non ti rispondo per la n+1 volte che cosa trovo io brutto, comunque lo sapevo e
proprio per quello non ho parlato di Global.h
--
ciao
  Stefano

 leggerti parrebbe di no...
BertolaCCi mio... Ma perchè ti ostini a parlare d'altro? Resta 
nell'ambito al quale è destinato il gruppo e soprattutto il thread...
Rendici edotti su 'ste benedette variabili, esimio...
-- 
Mommy!  The cursor's winking at me!


 
ma tu ad un certo punto hai chiesto : "volevo capire se valeva la pena 
sforzarsi per usare quelle locali"
il mio post cercava di farti arrivare alla risposta che cercavi
lungi da me cercare di spiegare le basi o di fare battaglie contro 
questo o quel costrutto
guarda che l'esempio che ti ho fatto nascondeva un fatto importante:
puoi sempre usare variabli globali, purche' abbiano un nome sempre 
diverso tra loro o sei SICURO che non vengano usate in sovrapposizione
l'uso delle variabili locali garantisce quanto sopra, l'uso delle 
variabili globali ti costringe a fare a manina quel controllo

 comunque lo sapevo e proprio per quello non ho parlato di Global.h
Io le globali le metto, semplicemente, all'inizio del file <nomeprogetto>.c
A meno non servano solo a comunicare con gli interrupt handler. In tal caso
le metto, chessò, in serial.c , che contiene sia le routine per accodare i
messaggi da inviare, sia quelle per leggerli dalla coda in ingresso, sia
gli handler degli interrupt della seriale.

 Della serie "io ce l'ho più lungo"... Stai cadendo in basso. 
Non attribuire a me le tue nevrosi.


Come scritto nel post precedente io uso funzioni inline e/o macro per 
gli accessor. In questo modo il dato rimane in sola lettura ma senza 
nessuno spreco di tempo e risorse, ottenendo quindi i vantaggi di 
entrambi i metodi.
-- 
  _|/ Francesco Sacchi - Develer S.r.l., R&D dept.
   |\ 
http://www.develer.com/
 - 
http://www.bertos.org/

 costrutti minimi necessari.
Ok, ma perché ripetere ogni volta il codice di lock/unlock del semaforo 
quando puoi incapsulare tutto in un accessor risparmiando spazio? 
Nuovamente, su progetti grossi, questo evita che qualcuno se ne dimentichi.
-- 
  _|/ Francesco Sacchi - Develer S.r.l., R&D dept.
   |\ 
http://www.develer.com/
 - 
http://www.bertos.org/

 Due di Picche:

Ho capito... La  risposta *informatica* non l'avremo mai...
-- 
Life is too short, eat dessert first. 



 Hai capito bene, ormai l'hai sputtanato in tutti i modi, na sa niente di 
niente si spara le pose con chi e' agli inizi, come si dice dalle mie parti 
fa il gallo sulla munnezza.
Hai notatao che da quando l'hai ridimensinato facendo notare le stronzate 
che scrive, rompe di meno? hai letto quella sua bellisima frase "insegnava 
il C" poveri studenti, ma cosa insegnava? 

 quando puoi incapsulare tutto in un accessor risparmiando spazio? 
Io per semaforo intendo una variabile che può essere acceduta da un solo
thread per volta. Va da sè che quindi non possa essere solo una variabile,
ma debba includere anche il codice per disabilitare gli interrupt e
quant'altro eventualmente necessario (timeout, interlock eccetera).
Anche se, in effetti, con certi processori dotati di istruzioni RMW
atomiche potrebbe essere una semplice variabile.

 Vero, ma con gli accessor come puoi evitare questi comportamenti?
Mi sembra che tu pensi agli accessors come a meri sostituti della 
scrittura/lettura di una variabile globale. L'accessor per come lo 
intendo io sta invece un layer sopra. Di fatto astrae dal fatto che ci 
sia uno stato "globale" dietro e fornisce un'interfaccia di più alto 
livello che dice qualcosa in più rispetto ai dati grezzi.
Faccio un esempio stupido.
Devo generare un PWM per controllare un alimentatore. Il PWM può 
variare in duty cycle per regolare la tensione di uscita. Ho una 
periferica PWM nel micro ma i valori del duty ammessi sono solo in un 
certo range, altrimenti l'alimentatore esplode. Inoltre prima di 
modificare il registro devo attivare dei pin per selezionare la giusta 
tensione da un trasformatore, attendere 1 secondo e modificare il 
registro PWM modo atomico.
Tu cosa faresti, lasceresti il registro PWM e lo stato dei pin globali 
in ogni parte del codice e copia-incolleresti tutta la trafila sopra 
riportata ogni volta che serve?
Io invece terrei l'attuale valore del PWM come stato interno (insieme 
allo stato dei pin e magari altre cose) e incapsulerei tutto in una 
funzione setVoltage() che prende come parametro solo la tensione che 
voglio generare.
Il registro del PWM e lo stato dei pin sono legati in modo forte, non 
ha senso consentire un accesso diretto e indipendente.
Il codice che gestisce questa cosa è autocontenuto, se la logica per 
selezionare la tensione dal trasformatore cambia, cambio il codice in 
un solo punto. Se c'è bisogno di accendere un led ogni volta che 
cambio tensione basta modificare il codice in un solo punto. A un mio 
collega che non conosce a fondo il progetto non verrà mai in mente di 
scrivere nel registro PWM  direttamente, perché non può proprio farlo.
Chiamando una funzione sola il codice è più facile da capire e spreca 
meno spazio in flash.
Infine, se ho bisogno in un altro progetto di generare lo stesso PWM 
con la stessa logica, il file è ben separato e lo posso riusare 
velocemente.
Sono tutti vantaggi che ottieni quando *mantieni* il progetto. Dalla 
mia esperienza i progetti non durano un giorno e quindi l'importanza 
del *non* usare le globali cresce con la dimensione e durata dello stesso.


 del *non* usare le globali cresce con la dimensione e durata dello stesso.
Quanto sostieni ha senso (ed anche parecchio) quando si hanno programmi
"grossi" che trattano dati complessi ed articolati. Visto che stavamo
parlando di PIC, direi che l'incapsulamento dei dati serve, nel 99% dei
casi, solo a complicare il programma e sprecar risorse.

 casi, solo a complicare il programma e sprecar risorse.
Grossi quanto?
Se parli di firmware che si fanno in qualche giorno e che *non* devono 
essere mantenuti sono d'accordo.
Sarò io che lavoro in un settore strano, ma normalmente il lavoro 
firmware richiede anche più dell'80% del tempo totale di sviluppo.
Quindi, dal mio punto di vista, il progetto medio è "grosso" per la 
tua definizione di "grosso". E mi sembra che i miei colleghi di altre 
aziende lavorino con progetti di dimensioni simili.
Non conta se siamo su PIC o altro, il mio voleva essere un punto di 
vista generale.
E' ovvio che ci sono casi e casi e che si deve valutare bene. Non ho 
detto che le variabili globali non vanno usate mai.
Come ho già detto altre volte, di solito noi elettronici tendiamo a 
sottovalutare i rischi e i problemi legati al firmware nel lungo periodo.
Io voglio solo rimarcare che bisogna essere invece ben consapevoli che 
quello che sembra inutile oggi, magari ci salverà la vita tra due 
anni. E siccome mi sembra che la dimensione media dei progetti 
richiederebbe questa consapevolezza, sono intervenuto.
Tutto questo a livello generale, poi si valuta caso per caso e 
bisogna, come sempre, fare compromessi.


 detto che le variabili globali non vanno usate mai.
Ti contraddici in due frasi consecutive? ;-)

 
io utilizzo PIC della serie 24
sviluppiamo molti progetti simili tra loro, di dimensioni medio grandi 
(qualche migliaio di linee di codice).
Il riutilizzo del codice, per i tipi di lavori che affronto, è fondamentale.
Preferisco per il mio tipo di lavoro il tipo di approccio suggerito da 
Francesco, anche perchè probabilmente sono in un contesto simile.
Riguardo al discorso "Grossi quanto?" è giusto dire tali da stare dentro 
il pic; io uso pic da 64/128 e in futuro 256k.
E' ovvio che si sprecano un po' di risorse e un po' di efficienza, ma la 
mia esperienza mi dice che lavorando in questo modo mettere insieme 
moduli ben definiti con un'interfaccia chiara è una cosa quasi 
piacevole, anzi, senza quasi (per inciso, lavorare in questo modo con i 
pic18 è improponibile per la carenza di risorse; il tradeoff tra 
efficienza e usabilità non ci consentiva certe cose).
Per dire una cazzata, grazie a questo approccio in un paio di giorni il 
mio collega ha reso multilingua e su eeprom o memory card (a scelta...) 
un menu monolingua che risiedeva in rom.
Io invece sono passato da un bootloader che caricava il fw da seriale ad 
uno usb in un paio d'ore tra sviluppo, debug e test, tutto perchè avevo 
la mia brava BootGetByte().
Una cosa su cui ti do ragione è che il debug diventa più difficile, ad 
esempio perchè il watch delle variabili non è sempre così facile come 
con una globale.
Così durante la prima stesura del bootloader ho creato un buffer 
circolare globale dove potevo guardare tutti i byte ricevuti e 
debuggare. Quando ho finito l'ho rimosso e non ce n'è più stato bisogno.
Poi comunque sono discorsi relativi, in cui la migliore soluzione 
dipende dal contesto e dalle esigenze. Nel mio caso questa è certamente 
la soluzione migliore.
Ciao
  Marco
ps il 1680x1050 è una pacchia ;-)

 Ti contraddici in due frasi consecutive? ;-)
Finito gli argomenti :-P?


 ps il 1680x1050 è una pacchia ;-)
L'unica cosa buona che ha quel cesso di Vista è la possibilità di usarne
contemporaneamente due, di cui uno in "portrait" (ma può essere solo il
primario) per leggere meglio i listati ed uno in "landscape", migliore per
i circuiti stampati.

 Finito gli argomenti :-P?
Eh, oh, si fa quel che si puň. :-)
Grazie!

 
un (bel) po' di real time lo faccio...lavoro soprattutto nell'ambito 
dell'illuminotecnica, quindi dmx, pilotaggio led, motori passo passo, 
ricezione segnali telecomandi ir,rf,ecc.
piů o meno uso gli stessi mezzi: pin non utilizzato, breakpoint 
condizionali, se devo fare qualche comunicazione collego due emulatori 
allo stesso pc e vado in debug su entrambi; e ora che ho piů ram a 
disposizione, anche parecchi buffer
per i pic24, non sono male, per niente, se non si parla delle errata 
paurose di alcuni che mi hanno fatto perdere settimane (un paio di 
errata nuove le ho trovate io). Che cazzo, mi tocca fare da betatester, 
veramente una seccatura.
Detto questo, c'č stato un bel salto dai pic16 ai 18 ma ancora di piu 
dai 18 ai 24, e paradossalmente stavolta abbiamo sofferto molto meno 
nella transizione, grazie al c che č molto piů generale: basta togliere 
di mezzo gli arzigogolamenti richiesti dal pic18 e va quasi tutto subito.

 dell'illuminotecnica
Mumble... Potresti, per favore, scrivermi una mail?