Newsgroup: it.hobby.elettronica.digitale
Titolo: quando svolge l'if ...e anche l'else

Ciao
 
un semplice programma con codewarrior mi segue questo flusso a causa di 
qualche errore,o ottimizzazione,che non è però richiesta.
 
Schematizzo con macro varie e funzioni
 
if(CALDO)
{
  LED_ROSSO_ON;
  BEEPER_ON;
 
}
else  //cioè se fa freddo
{
  LED_ROSSO_OFF;
 
  BEEPER_OFF;
}
 
Altre_cose();
 
avviene che facendo caldo accende led rosso,accende beeper e invece di 
chiamare Altre_cose() mi va a BEEPER_OFF saltando LED_ROSSO_OFF
 
di cosa è indice questo comportamento?
Qualcosa tocca il program counter?
 
Grazie
 
 
 


Imho l'errore e' fuori da queste istruzioni (cosa fa prima di questo, inizializzazioni, ciclo). Spiego: tu credi che lui segua il ramo "else", invece non lo fa. Tu vedi quell'effetto perche' quelle istruzioni le hai anche da un'altra parte (ad esempio in una routine di inizializzazione metti a off beeper e led)- Non so se mi spiego.
Per convincerti, nel ramo ELSE togli quelle istruzioni e metti qualcos'altro. Uno STOP, ad esempio. Cosi' ti rendi conto che quel ramo, se e' caldo, non lo fa.

Il 15/09/2015 19:00, Tom Pinara ha scritto:
 > Il giorno martedì 15 settembre 2015 16:41:41 UTC+2, blisca ha scritto:
 >> Ciao
 >>
 >> un semplice programma con codewarrior mi segue questo flusso a causa di
 >> qualche errore,o ottimizzazione,che non è però richiesta.
 >>
 
 >>
 >> avviene che facendo caldo accende led rosso,accende beeper e invece di
 >> chiamare Altre_cose() mi va a BEEPER_OFF saltando LED_ROSSO_OFF
 >>
 >> di cosa è indice questo comportamento?
 >> Qualcosa tocca il program counter?
 >>
 >
 
ciao e grazie per prima cosa
 
 > Imho l'errore e' fuori da queste istruzioni (cosa fa prima di questo, 
inizializzazioni, ciclo). Spiego: tu credi che lui segua il ramo "else", 
invece non lo fa. Tu vedi quell'effetto perche' quelle istruzioni le hai 
anche da un'altra parte (ad esempio in una routine di inizializzazione 
metti a off beeper e led)- Non so se mi spiego.
 > Per convincerti, nel ramo ELSE togli quelle istruzioni e metti 
qualcos'altro. Uno STOP, ad esempio. Cosi' ti rendi conto che quel ramo, 
se e' caldo, non lo fa.
 >
 
nono,non è che lo credo,civa,lo segue,lo vedo in debug che ci va,e se 
guardo il disassembly c'è un'istruzione di branch che salta proprio lì.
Ed è probabilmente una ottimizzazione,che in verità ho esplicitamente 
disabilitato
 
In realtà ora che ho visto questa istruzione mi rendo conto che
dovrei schematizzare il codice in modo un pò più dettagliato.
 
Quello che mi fa saltare lì è un if() interno.
In pratica io valuto varie condizioni.A seconda svolgo delle azioni e in 
tutti i casi poi vado a dormire.
 
if(CALDO)
{
LED_ROSSO_ON;
BEEPER_ON;
 
if(FINESTRA_APERTA)
{
Accendi_antizanzare();//lo spengo al risveglio
Vai_a_dormire();//caso 1
}
else
{
Vai_a_dormire();//caso 2
 
}
}
else //cioè se fa freddo
{
LED_ROSSO_OFF;
 
BEEPER_OFF;
 
Vai_a_dormire();//caso 3
}
 
Altre_cose();
 
Ecco,sembra che semplicemente che in caso di finestra aperta,dopo avere 
acceso anti zanzare(scusate l'esempio strambo),salti a 
Vai_a_dormire();//caso 3
 
Potrebbe anche avere senso,ma il fatto è che in debug se metto un 
breakpoint su Vai_a_dormire();//caso 3 vedo che il mio codice passa di 
lì,per cui penso che faccia freddo.
 
se c'è un'ottimizzazione allora posso capirlo,di solito fa sempre la 
cosa giusta,e magari ero io che non mi accorgevo che diverse condizioni 
riconducevano alla stessa azione,aveva ragione il compilatore.
Ma se non la metto voglio che il mio codice segua il flusso che mi aspetto.
 

 Qualcosa tocca il program counter?
 
Non credo... ma  come ho detto un problema di timing e di "tempo
 fisiologico" necessario per commutare un'uscita...
 
Una soluzione possibile, senza scomodare timers ma solo una variabile:
 
if (Ritardo) // se Ritardo > 0
 {
   Ritardo = Ritardo -1 //   Decrementa Ritardo
 }
       // esegue questa parte SOLO se ritardo e' a 0, quindi il
 else  // valore iniziale di Ritardo determina ogni quanti cicli
       // il controllo viene eseguito
 {
  Ritardo = 50  //  quindi, controllerà ogni 50 cicli



 
grazie anche a te per l'interessamento e i suggerimenti
 
veramente non mi spiego mai per quel che serve,pensando che la mia 
descrizione sia sufficiente,mi scuso;
 
non credo che la tua spiegaziano sia quella che risolve questo caso:
 
la valutazione di X viene eseguita non in un loop velocissimo,ma 
addirittura una sola volta al secondo dopo ogni riveglio da uno stop 
mode così profondo che al risveglio periodico il uC parte come se fosse 
un reset
 
ho tutto il tempo di svolgere le azioni,non è uno di quei casi in cui 
lancio una periferica,es un tx su seriale,che ci mette di + del loop che 
controlla se ha finito
 


inoltre l'assembly parla chiaro.
Il flusso del codice è diverso da quello che mi aspetto ,come se una 
ottimizzazione si fosse presa la briga di modificarlo

 ottimizzazione si fosse presa la briga di modificarlo
 
Ma se (benappunto) il flusso risultante è diverso da quello che
la logica detta, ci deve essere una causa esterna al flusso stesso;
hai provato, tanto per sfizio, a vedere se questo standby di cui fai
menzione può essere concausa ? es:
 
All'uscita dello standby:
 
Attendi X uS;
Esegui il codice;
Attendi X uS;
Torna in StandBy;

 Torna in StandBy;
 
no,non ancora
grazie 
 
 
 
---
Questa e-mail e stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus
 
 

 chiamare Altre_cose() mi va a BEEPER_OFF saltando LED_ROSSO_OFF
 
Metti i due spezzoni di codice in due funzioni separate e chiamale dentro
l'if. Questo di solito fixa le eventuali magagne dell'ottimizzatore.
 
-- 
Fletto i muscoli e sono nel vuoto.

  fisiologico" necessario per commutare un'uscita...
 
E perchè mai? L'istruzione per commutare un'uscita, una volta 
eseguita, VIENE ESEGUITA! Punto. Non devi mettere nessun timing per 
ottenere la commutazione della porta, è immediata.
 
 
 
-- 
 

Megazone ha pensato forte :

Forse sono vecchio io, forse le cose sono cambiate tantotantotanto;
ma alcune istruzioni richiedono  1 solo ciclo macchina, altre ne
richiedono 2 o piu, e se si usa un macro linguaggio pseudo o
multitasking c'e' una trappola pronta a scattare se 2 istruzioni
ravvicinate invocano /settano le stesse risorse ma tali risorse
richiedono piu cicli macchina....

 multitasking c'e' una trappola pronta a scattare se 2 istruzioni
 
Ma il flusso di esecuzione in C dovrebbe rimanere quello indicato dal 
codice, a meno che le chiamate non siano dichiaratamente asincrone, no?
 
Il discorso del multitasking avrebbe senso se ci fosse più processi o 
thread che fanno girare lo stesso codice ma a quanto ho capito qui c'è 
solo quell'istruzione if e non mi pare abbia molto senso che la 
condizione venga valutata più o meno frequentemente di quanto i rami 
vengano eseguiti, o sbaglio?
 
-- 
Andrea
 

 guardo il disassembly c'č un'istruzione di branch che salta proprio lě.
 
Come esegui il debug?
Puoi mostrare un esempio di codice che riproduca l'errore, magari con 
simulatore?
 
Lo chiedo perché mi interessa capire come si esegue il debug su 
dispositivi embedded (immagino che l'uso di Codewarrior sia finalizzato 
a qualche piattaforma embedded).
 
-- 
Andrea
 

Andrea D'Amore ci ha detto :

Scegli a piacere la risposta:
 
[SI]
[NO]
[Non sa, non risponde]
[1942]
[Albuquerque]
 
:)
 
Anche il programma scritto da Blisca "dovrebbe", ma evidentemente
non fa come "dovrebbe", all'oscuro  delle circostanze ho ragionato
nel cercare una possibile causa, scavando nei cassetti della mia
memoria mi sono ricordato della trappola del non tenere conto dei
cicli macchina nel progettare, in assembly, delle routine "ad alta
frequenza"; ora _ribadisco_ che potrei aver scritto (nel contesto
moderno) una boiata terribile dato che sono passati tanti anni da
quando l'obbligatorietà di tenere in considerazione il N. di cicli
macchina necessari a compiere una determinata operazione era all'ABC
della programmazione, ma, sarà per abitudine, sarà obsoleto nel
contesto attuale, ma continuo a considerare buona pratica evitare
di pirlare* dei controlli/registri in rapida successione.
 
*mi si passi il tecnicismo

 ha scritto nel messaggio 
news:10mdtxsbkee9l$.hg3mraazolew$.dlg@40tude.net...

molte grazie 


 richiedono piu cicli macchina....
 
E secondo te un processore "mischia" le istruzioni perchè sono 
ravvicinate?
Ogni riga C viene convertita in ASM, ovvero diverse istruzioni che 
vengono poi eseguite una alla volta. A meno che non ci sia di mezzo 
un interrupt (ma non sembra questo il caso) il flusso è lineare e 
sequenziale. L'errore è da qualche altra parte.
 
-- 
 

 ravvicinate?
 
Secondo box, dall'alto: "189. Che significa 'ciclo-macchina'?"
 
http://www.edscuola.it/archivio/software/bit/bitfaq73.html
 
 
Se non ti è chiaro chiedi pure.

 Se non ti è chiaro chiedi pure.
 
Il ciclo macchina è composto (ma dipende dal tipo di processore) da 1
o più cicli di clock. 
Prendendo come spunto il pic citato ogni istruzione prevede 4 cicli 
di clock (a parte i branch condizionati che ne richiedono di più). 
Alla fine del ciclo macchina il processore ha eseguito l'istruzione 
macchina. Ogni istruzione, quindi è composta da cicli diversi del 
clock ma, e qui ripeto, NON C'E' alcuna possibilità che si possano 
mischiare tra loro istruzioni diverse, in caso contrario avremmo 
creato anzichè un processore sequenziale, un accrocchio 
impredicibile. Il ciclo di ogni istruzione, quindi, è prevedibile, 
certo e lineare. 
 
Durante una istruzione di set di una uscita il processore, dopo aver 
interpretato l'istruzione, abilita l'uscita relativa e ciò avviene 
immediatamente. Nel flusso oggetto del thread il problema sembrerebbe
essere nel ciclo IF che non viene eseguito correttamente, a 
prescinere dallo stato delle uscite. Quindi o il debugger sta 
sbagliando qualche cosa ingannando così chi lo usa o chi ha iniziato 
il thread ci sta "nascondendo" qualche cosa d'altro essenziale per 
venire a capo del problema.
 
Piuttosto tu cosa hai capito di quella paginetta?
 
-- 
 

 quanto insidioso problema...
 
Questa mi era sfuggita nel thread... Adesso capisco. Hai un concetto 
sbagliato di "esecuzione di un flusso di istruzioni" e "ciclo 
macchina". Sono due cose INDIPENDENTI tra loro se non per il mero 
fatto che il ciclo macchina influenza la velocità con la quale viene 
eseguito il flusso di istruzioni. Ogni istruzione (che richieda 1, 2,
3 o 100 cicli macchina) viene esguita "IN SOLITARIA" ovvero DA SOLA 
ed indipendentemente da quelle che la precedono o la seguono. Il tuo 
errore è pensare che le istruzioni contenute nell'IF debbano venir 
eseguite "all'interno" del ciclo macchina dell'IF stesso, ma così non
è. Se si fa a vedere l'ASM generato da tale serie di istruzioni C si 
vedrà che l'IF altro non è che una istruzione di comparazione seguita
da un salto condizionato ad una parte (il contenuto dell'IF) o ad 
un'altra (il contenuto dell'else). il tempo impiegato dall'IF durante
la comparazione ed il salto condizionato, non ha nulla a che vedere e
non influenza la durata di ciò che verrà eseguito successivamente in 
risposta alla comparazione.
 
-- 
 

 multitasking 
 
Il multitasking su un microcontroler a singolo core viene realizzato 
mediante il time slice, ovvero ogni processo viene eseguito per un 
certo periodo di tempo per poi passare al successivo. Un time slice 
sufficientemente veloce fa sembrare che i precessi stiano funzionando
tutti insieme ma cosě non č. E' lo stesso trucco adottato dal 
cinematografo...
 
-- 
 

 E' lo stesso trucco adottato dal cinematografo...
 
Immaginavo che ci fosse del marcio.
 
Ora, se riprendi il concetto di time slice e ti applichi forse ci
capiamo, cavati dalla testa l'impressione (sbagliata) che io abbia
affermato in qualsivoglia modo che le istruzioni nel processore vengano
mischiate o cazzate simili, RIPARTI DA
 
"Ora, se considerando che "Se X" viene eseguito ad ogni ciclo macchina
ma qualsiasi tra A,B,M,N richiede 2 cicli macchina, c'e' un potenziale
quanto insidioso problema..."
 
e
 
"c'e' una trappola pronta a scattare se 2 istruzioni
ravvicinate invocano /settano le stesse risorse ma tali risorse
richiedono piu cicli macchina...."
 
e forse ci arrivi.

 vedrà che 
 
...'spetta che mi tengo la pancia...
 
E una:
"l'IF altro non è che una istruzione di comparazione "
 
E due:
"seguita da un salto condizionato ad una parte (il contenuto dell'IF)"
 
E tre:
"o ad un'altra (il contenuto dell'else). "
 
E qui dico basta, non ho avuto cuore di leggere oltre.

 Il cic [cut]
 
basta diocan basta !

 basta diocan basta !
 
Ecco bravo, cosě ci fai piů bella figura.
 
-- 
 

 E qui dico basta, non ho avuto cuore di leggere oltre.
 
LOL. Tu proprio di processori non capisci una emerita mazza allora. 
Dall'alto delle tue (rotfl) conoscenze spiega a noi ignoranti in cosa
consiste ed in cosa viene tradotto un IF in linguaggio macchina... 
Attendo con impazienza la tua dotta disquisizione. 
 
 
 
 
-- 
 

 e forse ci arrivi.
 
Ma davvero ci sei i ci fai? Quindi due istruzioni di seguito in cui 
una azzera un'uscita e l'altra la setta vanno in conflitto? E cosa 
succede? Scoppia il processore? Si surriscalda? L'uscita assume un 
valore indefinito? Va in threestate? Si spezzano i piedini? Brucia 
l'alimentatore? Il micro si resetta? Il watchDOG si mette ad 
abbaiare?
 
 
-- 
 

 Immaginavo che ci fosse del marcio.
 
Ho cercato di farti capire il multitasking senza usare espressioni 
complicate, usando semplici aneddoti e semplici comparazioni che 
tutti possono capire, anche i non addetti...
 
-- 
 

Il 20/09/2015, Megazone ha detto :

Traduco:
 
"Io che il del multitasking ne ho letto sugli incarti dei baci
  perugina, non c'ho capito un cazzo e l'ho riportato di merda
  perchè non ci ho capito un cazzo, ora uso la scusa che il mio
  era un esempio semplificato perchè altrimenti si capisce che non
  ci capisco un cazzo".

 ..skip di risposte insensate
 
Ecco, questa e' l'unica cosa che avrei dovuto fare IO, leggendoti.

 abbaiare?
 
MA CHE CAZZO STAI DICENDO ?
 
Ma capisci quello che leggi, imbecille ?
 
Ti do un'ULTIMA opportunità:
 
- L'OP a denunciato un comportamento anomalo, assurdo.
- IO ho ventilato la possibilità che il comportamento anomalo potesse
  essere dovuto a una situazione di lettura precoce dello status; "stai
  cercando di prendere la penna mentre il fottuto cassetto si sta 
ancora
  aprendo! dagli un cazzo di respiro prima di dargli il comando afferra
  la penna !"
- TU, intervieni A CAZZO con puttanate che neanche da un programmatore
  di lingo mi sarei aspettato di leggere:
        "E perchè mai? L'istruzioneper commutare un'uscita, una
         volta eseguita, VIENE ESEGUITA! Punto. Non devi mettere
         nessun timing per ottenere la commutazione della porta, è
         immediata."
  Il tutto a dimostrazione che NON HAI CAPITO UN CAZZO di quello che
  ho scritto, ho ancora i brividi.
 
- IO con pazienza che m'ero scordato di avere, ti spiego che TRA il
  momento in cui viene dato un comando e il momento che tale comando
  SIA EFFICACE su un'uscita/controllo/registro possono servire N cicli
  macchina prima di poterne "godere" (il fottuto cassetto si sta
  ancora aprendo!).
 
- TU rispondi minchionando e accendi un flame quando leggendo il link
  che ti ho passato "capisci" (il virgolettato e' sarcasmo) cosa sia
  il concetto di "cicli macchina" e spari puttanate ancora piu grosse
  nel (patetico) tentativo di nascondere il FATTO che nemmeno sapevi
  cosa fossero prima di leggere il link che ti ho passato.
 
Ti rendi conto ora dei tuoi limiti ? la pazienza è finita, il re (delle
cazzate) è nudo, copriti, fai una certa imressione.

 cazzate) è nudo, copriti, fai una certa imressione.
 
Hahahaha, coglione hai perso una buona occasione per startene zitto. 
Come dice il detto: "A volte è meglio tacere e sembrare stupidi che 
aprir bocca e togliere ogni dubbio."
 
E fatti spiegare da un grande cosa sia il ciclo macchina e che 
rapporto ha con l'istruzione.
 
 
-- 
 

   ci capisco un cazzo".
 
Si si... Hahaha, mò aspettiamo te che ce lo spieghi, con tanto di 
grafico dei cicli macchina. Ahaha...
 
Toh, leggiti la definzione di pc-facile, ovvero il pc per i lamerozzi
come te:
 
http://www.pc-facile.com/glossario/time_slicing/
 
 
-- 
 

 Ecco, questa e' l'unica cosa che avrei dovuto fare IO, leggendoti.
 
Rispondi alla domanda invece di glissare, fessacchiotto: come si 
traduce in ASM una istruzione IF ?
 
-- 
 

 di pirlare* dei controlli/registri in rapida successione.
 
Non è mai stato un problema il "ciclo macchina" a meno di dover 
realizzare routine molto particolari per le quali era necessario 
sapere con precisione la durata. Un esempio è un ciclo interrupt. 
Lascio a te l'onere di informarti del perchè visto che qui nel gruppo
non credi a quello che ti dicono.
 
Però adesso spiega a noi poveri ignoranti come fai a calcolare i 
cicli macchina di un codice generato da un linguaggio ad alto livello
come il C se manco sai come verrà tradotto in ASM dal compilatore. 
Senza contare che ogni compilatore compila alla sua maniera, senza 
contare che compila in  maniera diversa a seconda degli switch di 
compilazione (velocità, risparmio memoria, ottimizzazione) Su, 
rendici partecipi delle tue conoscenze.
 
 
 
-- 
 

 
http://www.pc-facile.com/glossario/time_slicing/
 
 
Che in argomento PIC c'azzecca come il cavolo a merenda, il prossimo
link da dove lo prendi ? da "
informaticauntotalkilo.com
" ?
 
Vai vai, io chiudo qua.

 Ti sto prendendo per il culo, manco questo hai capito? 
 
Disse.

Scriveva Megazone domenica, 20/09/2015:

Con lo zingarelli.


Scusate se mi intrometto in questa interessante disputa
accademica, ma finche' non si vede il sorgente originale
e il listato assembly prodotto dal compilatore, temo che
non si arrivera' mai a una conclusione definitiva.
A volte basta un punto e virgola in piu' o in meno
a cambiare completamente la logica di un programma.
 
 

 a cambiare completamente la logica di un programma.
 
Il presente caso non e' l'oggetto del contendere, ma l'affermazione
 
    ...c'e' una trappola pronta a scattare se 2 istruzioni
    ravvicinate invocano /settano le stesse risorse ma tali
    risorse richiedono piu cicli macchina....
 
che il minus habens non è in grado di afferrare.

 che il minus habens non č in grado di afferrare.
 
Ciao coglione. Siamo in trepidante attesa che tu, sommo conoscitore 
del ciclo macchina, dia una spiegazione logica a questa alla tua 
affermazione da idiota. Siamo sempre in trepidante attesa che tu ci 
mostri come un compilatore risolva in linguaggio assembler una 
sezione if...else
 
Fin'ora hai solo sparato cazzate, ora č il momento di diventare 
grande e dimostrare le proprie stronzate, se ne sei in grado, 
altrimenti stai zitto che confondi solo le idee a chi sta cercando 
una soluzione.
 
-- 
 

 link da dove lo prendi ? da "
informaticauntotalkilo.com
" ?
 
L'ho fatto per te, che non capisci un cazzo. E lo dimostri con questa
tua affermazione, perchè il time slicing è una metodologia generale 
che si applica a tutto il mondo dei microporcessori mica solo al PC. 
Toh cretino, ciucciati questo e poi però sparisci, asinaccio 
recalcitrante:
 
http://www.microchipc.com/Hi-Tech_C_multitask/
 
 
-- 
 

 Ciao coglione. Siamo in trepidante attesa che
 
Stai diventando patetico...

 
http://www.microchipc.com/Hi-Tech_C_multitask/
 
 
E lo sapevo che ad aspettare ti saresti dato la zappa sui piedi !
 
hai.appena.linkato.la.prova.che.non.capisci.un.cazzo.di.quello.che.leggi
 
(a meno che non ti sia limitato ai titoli, visto che già a leggere un
 incarto di cioccolatino ci metti 2 anni, figuriamoci capirlo...)
 
Sezione user feedback:  q4 e q5, se non capisci l'inglese chiedi
(a qualcun 'altro) che io ne ho le palle piene di farti da babysitter.

Franz_aRTiglio ha detto:

Dunque, facciamo il punto delle tue peripezie elettroniche...
 
In primis salti su dicendo che esiste un "insidioso problema" che 
affliggerebbe tutti i micro quando si tenta di utilizzare le stesse 
risorse con "istruzioni ravvicinate" senza però spiegare bene di cosa
esattamente si dovrebbe trattare. Già basta questa incredibile 
ca%%ata per squalificarti. 
 
Ti si è risposto garbatamente che ciò non può essere, l'unica 
possibilità è quando ci sono di mezzo degli interrupt ma non era 
questo il caso. Te l'abbiamo ribadito in due. 
 
Purtroppo non è servito e hai perseverato nel tuo errato ed ostinato 
convincimento degno di un mulo, tirando in ballo fantomatici cicli 
macchina, misteriosi multitasking, etc...
Non sei ancora peraltro riuscito a farci capire come venga assemblato
il famoso if else, anzi hai riso delle corrette spiegazioni che ti 
sono state date. Il che fa capire a che stadio di "conoscenza" tu 
sia. "nebulosa" è un eufemismo. Tratti i micro come "scatole magiche"
con i quali è quasi meglio non averci a che fare, aggiungendo un 
mistico timore reverenziale.
 
Poi sei riuscito con questo post a ritirare in ballo i "conflitti" 
PROPRIO laddove si parla di "interrupt", ma a sproposito perchè non 
parla di conflitti di risorse bensì di overtiming della routine di 
interrupt. Già, perchè le risposte alle domande che citi dicono una 
cosa BEN DIVERSA dalla tua immane boiata, sicchè tu prendi come prova
delle tue asserzioni delle affermazioni che provano TUTT'ALTRO. 
Qualche problemino con l'inglese spiegherebbe agevolemente sia la 
mancata comprensione dei micro che quella delle risposte citate. 
 
Cosa dice infatti l'articolo? Dice che SE UNA ROUTINE DI INTERRUPT 
dura di più del tempo che intercorre tra un interrupt e l'altro si 
corre il rischio di non riuscire a far eseguire null'altro al micro 
se non l'interrupt stesso. Ovvio. Come si procede? Si controlla se il
flag TMR1IF è stato settato ALLA FINE della routine di interrupt. Se 
così fosse significa che la routine dura troppo perchè è intercorso 
un altro interrupt (flag settato) quindi si dovrà procedere via 
software ad allungarne il periodo. una soluzione non banale ma 
neppure difficile da capire, se uno ce la fa ovviamente.
 
Morale? Nessuna stranezza, nessun conflitto di porte/risorse/ca%%ate 
varie. Hai preso un bel granchio anzi due e hai per l'ennesima volta 
dimostrato di non capirci un ca%%o. Piantale lì per il tuo bene.
 
 
 
-- 
 

 Dunque, facciamo [cut]
 
Che hai rotto le palle.

Franz_aRTiglio ha detto:

Pensa che rientri perfettamente in questo studio:
http://www.psy.cmu.edu/~siegler/RozKeil02.pdf
 
 
Incompetente. Potresti tenere dei simposi del genere "il 
microprocessore, questo sconosciuto".
 
 
--