Non ha senso, lo ripeto.
L' interrupt è generata da un evento ed ha una ruotine di gestione.
Fammi un esempio pratico di un' interrupt (ad esempio quella di un timer) che può avere due routine di gestione. Nell' esempio descrivi anche:
- perché questa unica interrupt dovrebbe avere più di una ruotine di gestione
- con quale criterio il sistema decide quale delle ruotine deve essere attivata
- quale risultato si otterrebbe
- quali vantaggi si avrebbero ad avere più routines di gestione.
Eseguire programmi da MicroSD su ATmega
Moderatore:
Paolino
43 messaggi
• Pagina 3 di 5 • 1, 2, 3, 4, 5
1
voti
"La follia sta nel fare sempre la stessa cosa aspettandosi risultati diversi".
"Parla soltanto quando sei sicuro che quello che dirai è più bello del silenzio".
Rispondere è cortesia, ma lasciare l'ultima parola ai cretini è arte.
"Parla soltanto quando sei sicuro che quello che dirai è più bello del silenzio".
Rispondere è cortesia, ma lasciare l'ultima parola ai cretini è arte.
-

TardoFreak
73,9k 8 12 13 - -EY Legend-

- Messaggi: 15754
- Iscritto il: 16 dic 2009, 11:10
- Località: Torino - 3° pianeta del Sistema Solare
0
voti
Si, in effetti, non ha senso.
Ma allora, io non posso avere più di una routine di gestione. Però, se vengono caricati due task che hanno entrambi una routine di gestione per lo stesso interrupt, viene fuori un macello. Come posso evitare questo?
Secondo te vale la pena di far fornire delle informazioni all'eseguibile riguardo agli interrupt da esso gestiti, in modo che l'interprete segnali errore quando trova una routine doppia, o semplicemente quest'accortezza dovrebbe spettare all'utente che carica i programmi?
Ma allora, io non posso avere più di una routine di gestione. Però, se vengono caricati due task che hanno entrambi una routine di gestione per lo stesso interrupt, viene fuori un macello. Come posso evitare questo?
Secondo te vale la pena di far fornire delle informazioni all'eseguibile riguardo agli interrupt da esso gestiti, in modo che l'interprete segnali errore quando trova una routine doppia, o semplicemente quest'accortezza dovrebbe spettare all'utente che carica i programmi?
0
voti
Non sono i task ad avere "una ruotine di gestione dell' interrupt"
Sono gli eventi che generano le interrupt che hanno la loro specifica ruotine di gestione.
Ti faccio un esempio.
Supponiamo di avere un timer che genera un' interrupt ogni millisecondo. Lo scopo è quello di creare dei timer software che si decrementano fino ad arrivare a 0 ogni ms.
Il timer genera l' interrupt che chiama la ruotine di gestione che, se il valore del timer X è diverso da zero lo decrementa.
Supponiamo adesso che un task abbia bisogno di uno di questi timer. Bene, egli userà uno degli N timers software contemporaneamente ad altri task che useranno ognuno il loro timer software.
Come vedi la ruotine di gestione dell' interrupt non c' entra niente con i task.
Sono gli eventi che generano le interrupt che hanno la loro specifica ruotine di gestione.
Ti faccio un esempio.
Supponiamo di avere un timer che genera un' interrupt ogni millisecondo. Lo scopo è quello di creare dei timer software che si decrementano fino ad arrivare a 0 ogni ms.
Il timer genera l' interrupt che chiama la ruotine di gestione che, se il valore del timer X è diverso da zero lo decrementa.
Supponiamo adesso che un task abbia bisogno di uno di questi timer. Bene, egli userà uno degli N timers software contemporaneamente ad altri task che useranno ognuno il loro timer software.
Come vedi la ruotine di gestione dell' interrupt non c' entra niente con i task.
"La follia sta nel fare sempre la stessa cosa aspettandosi risultati diversi".
"Parla soltanto quando sei sicuro che quello che dirai è più bello del silenzio".
Rispondere è cortesia, ma lasciare l'ultima parola ai cretini è arte.
"Parla soltanto quando sei sicuro che quello che dirai è più bello del silenzio".
Rispondere è cortesia, ma lasciare l'ultima parola ai cretini è arte.
-

TardoFreak
73,9k 8 12 13 - -EY Legend-

- Messaggi: 15754
- Iscritto il: 16 dic 2009, 11:10
- Località: Torino - 3° pianeta del Sistema Solare
0
voti
Scusa allora mi sono espresso male... forse non ho proprio le idee chiare su come procedere 
Gli interrupt io finora gli ho usati con i timer e con i segnali esterni. Io avevo in mente di mandare il program counter a un label del programma quando viene chiamato un'interrupt. Per esempio, il timer 0 va in overflow, il programma va alla label 30. C'è un segnale esterno sul pin dell'INT0, il programma va alla label 31.
Il mio problema era capire quale programma di quelli in esecuzione deve andare alla label 30, 31 o altra che sia. Ed evitare che ci siano più programmi che eseguano delle operazioni quando accade uno stesso interrupt.
Io avevo in mente questa implementazione.
Se tu hai un'idea migliore e riuscissi a spiegarla in modo dettagliato in modo che io possa capire sarebbe ottimo.
Gli interrupt io finora gli ho usati con i timer e con i segnali esterni. Io avevo in mente di mandare il program counter a un label del programma quando viene chiamato un'interrupt. Per esempio, il timer 0 va in overflow, il programma va alla label 30. C'è un segnale esterno sul pin dell'INT0, il programma va alla label 31.
Il mio problema era capire quale programma di quelli in esecuzione deve andare alla label 30, 31 o altra che sia. Ed evitare che ci siano più programmi che eseguano delle operazioni quando accade uno stesso interrupt.
Io avevo in mente questa implementazione.
Se tu hai un'idea migliore e riuscissi a spiegarla in modo dettagliato in modo che io possa capire sarebbe ottimo.
0
voti
Con tutto il rispetto ma che tu non abbia le idee chiare è evidente.
Ma non è un problema.
Mettiamola così, supponiamo di avere un programma normale, canonico, con un main, le funzioni ed una ruotine che gestisce un interrupt da un pin. Ora rispondi a queste domande:
- In quale caso il programma principale si accorge che dall' esterno è arrivata un interrupt?
- Cosa succede quando, durante l' esecuzione del programma principale, il micro riceve un interrupt?
- Il programma principale sa in quale momento è arrivata l' interrupt? E se si, in quale modo?
Sono tre domande. Pensaci bene (ho detto bene bene bene), dammi tre risposte e poi andiamo avanti.
Ma non è un problema.
Mettiamola così, supponiamo di avere un programma normale, canonico, con un main, le funzioni ed una ruotine che gestisce un interrupt da un pin. Ora rispondi a queste domande:
- In quale caso il programma principale si accorge che dall' esterno è arrivata un interrupt?
- Cosa succede quando, durante l' esecuzione del programma principale, il micro riceve un interrupt?
- Il programma principale sa in quale momento è arrivata l' interrupt? E se si, in quale modo?
Sono tre domande. Pensaci bene (ho detto bene bene bene), dammi tre risposte e poi andiamo avanti.
"La follia sta nel fare sempre la stessa cosa aspettandosi risultati diversi".
"Parla soltanto quando sei sicuro che quello che dirai è più bello del silenzio".
Rispondere è cortesia, ma lasciare l'ultima parola ai cretini è arte.
"Parla soltanto quando sei sicuro che quello che dirai è più bello del silenzio".
Rispondere è cortesia, ma lasciare l'ultima parola ai cretini è arte.
-

TardoFreak
73,9k 8 12 13 - -EY Legend-

- Messaggi: 15754
- Iscritto il: 16 dic 2009, 11:10
- Località: Torino - 3° pianeta del Sistema Solare
0
voti
Ok aspetta aspetta aspetta...
Con programma normale e programma principale, intendi il programma che gira sull'ATmega, cioè l'interprete, oppure il programma che viene eseguito dall'interprete?
Scusa se ci sto capendo poco e ti ringrazio della tua enorme pazienza
Con programma normale e programma principale, intendi il programma che gira sull'ATmega, cioè l'interprete, oppure il programma che viene eseguito dall'interprete?
Scusa se ci sto capendo poco e ti ringrazio della tua enorme pazienza
0
voti
Per programma "normale" intendo un programma qualsiasi, scritto in assembly o in C che ha un main (o una routine principale), delle funzioni (o subroutines) e delle funzioni (o routines) di gestione di un interrupt esterna.
Normale, assemblato o compilato.
Canonico.
Niente di speciale.
Normale, assemblato o compilato.
Canonico.
Niente di speciale.
"La follia sta nel fare sempre la stessa cosa aspettandosi risultati diversi".
"Parla soltanto quando sei sicuro che quello che dirai è più bello del silenzio".
Rispondere è cortesia, ma lasciare l'ultima parola ai cretini è arte.
"Parla soltanto quando sei sicuro che quello che dirai è più bello del silenzio".
Rispondere è cortesia, ma lasciare l'ultima parola ai cretini è arte.
-

TardoFreak
73,9k 8 12 13 - -EY Legend-

- Messaggi: 15754
- Iscritto il: 16 dic 2009, 11:10
- Località: Torino - 3° pianeta del Sistema Solare
0
voti
Ok ma cosa intendi con programma principale?
Per esempio nella domanda:
Intendi quando l'interprete si accorge che è arrivata un'interrupt o quando il programma interpretato si accorge che è arrivata?
Per esempio:
- L'interrupt su INT0 è abilitato.
- Il programma interpretato sta funzionando, mettiamo stia facendo lampeggiare un led. Quindi è in un loop senza fine.
- Arriva un segnale che fa scattare l'interrupt di INT0. Il programma del microcontrollore, l'interprete, se ne accorge e posiziona il program counter nell'indirizzo della label 34.
- Il programma interpretato va alla label 34 ed esegue le istruzioni finché non trova un 'ret' (return).
- Il programma interpretato riprende il suo loop di lampeggio.
Questo è quello che ho in mente... non capisco esattamente cosa vorresti sapere con quelle domande...
Per esempio nella domanda:
In quale caso il programma principale si accorge che dall' esterno è arrivata un interrupt?
Intendi quando l'interprete si accorge che è arrivata un'interrupt o quando il programma interpretato si accorge che è arrivata?
Per esempio:
- L'interrupt su INT0 è abilitato.
- Il programma interpretato sta funzionando, mettiamo stia facendo lampeggiare un led. Quindi è in un loop senza fine.
- Arriva un segnale che fa scattare l'interrupt di INT0. Il programma del microcontrollore, l'interprete, se ne accorge e posiziona il program counter nell'indirizzo della label 34.
- Il programma interpretato va alla label 34 ed esegue le istruzioni finché non trova un 'ret' (return).
- Il programma interpretato riprende il suo loop di lampeggio.
Questo è quello che ho in mente... non capisco esattamente cosa vorresti sapere con quelle domande...
0
voti
giacky98 ha scritto:... non capisco esattamente cosa vorresti sapere con quelle domande...
Fa parte di un percorso, di un ragionamento.
Per adesso hai risposto alla domanda: "Cosa succede quando, durante l' esecuzione del programma principale, il micro riceve un interrupt?"
Hai risposto ragionando sul tuo interprete ma non era necessario perché questo succede in qualsiasi programma scritto in qualsiasi linguaggio.
Non serve pensare all' interprete, basta pensare ad un programma normale (anzi è più facile per trovare le risposte).
Ora rispondi alle altre due domande.
"La follia sta nel fare sempre la stessa cosa aspettandosi risultati diversi".
"Parla soltanto quando sei sicuro che quello che dirai è più bello del silenzio".
Rispondere è cortesia, ma lasciare l'ultima parola ai cretini è arte.
"Parla soltanto quando sei sicuro che quello che dirai è più bello del silenzio".
Rispondere è cortesia, ma lasciare l'ultima parola ai cretini è arte.
-

TardoFreak
73,9k 8 12 13 - -EY Legend-

- Messaggi: 15754
- Iscritto il: 16 dic 2009, 11:10
- Località: Torino - 3° pianeta del Sistema Solare
0
voti
- Il programma si accorge che è arrivata un‘interrupt perché viene chiamata la funzione relativa all‘interrupt (es. SIG in C o una label nel mio linguaggio)
- Non credo che si possa risalire a “quando“, si potrebbe controllare in che posizione è il program counter per capire a che istruzione è scattato l‘interrupt
- Non credo che si possa risalire a “quando“, si potrebbe controllare in che posizione è il program counter per capire a che istruzione è scattato l‘interrupt
43 messaggi
• Pagina 3 di 5 • 1, 2, 3, 4, 5
Torna a Firmware e programmazione
Chi c’è in linea
Visitano il forum: Nessuno e 12 ospiti

Elettrotecnica e non solo (admin)
Un gatto tra gli elettroni (IsidoroKZ)
Esperienza e simulazioni (g.schgor)
Moleskine di un idraulico (RenzoDF)
Il Blog di ElectroYou (webmaster)
Idee microcontrollate (TardoFreak)
PICcoli grandi PICMicro (Paolino)
Il blog elettrico di carloc (carloc)
DirtEYblooog (dirtydeeds)
Di tutto... un po' (jordan20)
AK47 (lillo)
Esperienze elettroniche (marco438)
Telecomunicazioni musicali (clavicordo)
Automazione ed Elettronica (gustavo)
Direttive per la sicurezza (ErnestoCappelletti)
EYnfo dall'Alaska (mir)
Apriamo il quadro! (attilio)
H7-25 (asdf)
Passione Elettrica (massimob)
Elettroni a spasso (guidob)
Bloguerra (guerra)
