relativamente al programma di esempio, mi è sorto un dubbio. La variabile TimerLed non dovrebbe essere qualificata volatile, essendo usata dalla routine di gestione degli interrupt? Anche se con la versione Lite del compilatore Hi-Tech non dovrebbe esserci molta differenza, essendo adoperato un basso livello di ottimizzazione del codice sorgente.

Ciao.

hai idea del perchè quando faccio il build del main il compilatore mi dice

Error [499] ; 0. undefined symbol:
_settaggi1(ledcicalino.obj)

eppure il main è identico al tuo!

già ti sono grato per quello che hai fatto e continui a fare, se chiarissi il dubbio ti osanno.

ciao.

Una domanda: ho notato che hai messo “void interrupt ISR (void)” dopo la funzione main, ma l’interrupt non è da considerare una funzione a sè stante? Se si, non doveva essere dichiarata prima del main???

void main(void)
{
//Char è un tipo di dato a 8 bit, quindi può arrivare a contenere valori fino a 255, a noi serve massimo 250, quindi va bene

OSCCON=0×70; // x111 0000 – 8 Mhz internal clock

// Tutte le porte come output
TRISA=0xfe;
TRISB=0;
TRISC=0xfe;
// TRISD=0;
//TRISE=0;

// Impostazione del registro OPTION (pag.55 del datasheet)
OPTION=0b11000100;
// bit 0 -> Prescaler Rate Select bit 0
// bit 1 -> Prescaler Rate Select bit 0
// bit 2 -> Prescaler Rate Select bit 0 (1:32)
// bit 3 -> Prescaler assegnato al Timer0
// bit 4 -> Non importa
// bit 5 -> Clock per Timer0 derivato da ciclo di clock interno
// bit 6 -> Non importa
// bit 7 -> Resistenze di pull-up su porta B disattivate

// Impostazione Interrupt
INTCON=0b10100000;
// bit 0 -> RBIF – Flag interrupt su porte B
// bit 1 -> INTF – Flag interrupt su RB0/INT
// bit 2 -> T0IF – Flag interrupt su Timer0
// bit 3 -> RBIE, Interrupt su porte B disattivato
// bit 4 -> INTE, Interrupt su porta RB0/INT disattivato
// bit 5 -> TMR0IE, Interrupt su Timer0 attivato
// bit 6 -> PEIE, Interrupt di periferica disattivato
// bit 7 -> GIE, Gestione Interrupt attiva

TMR0=240; // Imposto Timer0 a 240

while(1) // eseguo un ciclo finito
{
/*
L’unica cosa che eseguo durante questo ciclo infinito, è l’inversione
dello stato del cicalino ogni 200microsecondi, in maniera tale da generare
un’onda quadra di 2,5KHz che, applicata al cicalino, appunto,
mi permette di farlo suonare facendogli emettere una nota a tale frequenza
*/
__delay_ms(1000);
CICALINO=0;
__delay_ms(1000);
CICALINO=1;

}// Fine ciclo continuo

} // Fine main

/*
Questa routine, avendo l’attributo “interrupt” prima del nome della routine stessa, viene chiamata in automatico
ogni qualvolta si verifica un interrupt. Essendo le sorgenti di interrupt di vari tipi, in questa routine dobbiamo
capire quale elemento ha generato l’interrupt. Con le impostazioni utilizzate, Timer0 genererà un interrupt ogni
millisecondo.
*/
void interrupt ISR (void)
{
if (T0IF) // L’interrupt è stato causato da un overflow del timer0 ?
{
TMR0 = 240; // Reimposto Timer0
TimerLed++; // Incremento il Timer per il lampeggio del led
if (TimerLed >= TEMPOLED) // Se il tempo è passato
{
LED=LED^1;
// Inverto lo stato del led per farlo lampeggiare
TimerLed=0; // Ricarico il timer del led per ricominciare daccapo
}
T0IF=0; // Resetto il flag interrupt su timer 0,
} // fine che interrupt verificatosi su timer0
} // fine interrupt service ro

Primo: la versione free dell’Hitec-C manca di alcune ottimizzazioni ma di certo non fa durare un ritardo piu del tempo dovuto, può avere qualche problema di certo, ma se il problema sta sulla versione free, sta anche su quella a pagamento, come si è dimostrato di recente con la versione 9.81.

Secondo: Dai a me l’ICD3 e io ti do il pickit. Non capisco cosa puo voler dire “inviare schifezze”. Mettiamo che l’ICD3, un prodotto molto costoso e professionale, invii delle schifezze (che ora qui posso intendere come bit non desiderati). Allora la verifica del programma deve fallire per forza perchè compara l’hex sul pc con quello appena caricato/letto dal picmicro. La verifica ti fallisce? Non credo proprio.

La microchip dovrebbe chiudere i battenti in entrambi i casi: uno perchè avrebbe fatto un programmatore inutile, che costa una cifra, due perchè ha acquistato l’hitech che farebbe un compilatore idiota.

Quei delay come hai già letto sono sballati, ho fatto delle verifiche a suo tempo con l’oscilloscopio ma non ho avuto tutta questa discrepanza: nel peggiore dei casi il ritardo introdotto era del doppio, ma ho provato fino ad 8MHz, posso immaginare che salendo di frequenza l’errore aumenti sempre più. Quella routine difatti è molto vecchia ed oltre al fatto di non essere ottimizzata, era creata per girare a 2MHz come disse l’autore. Ma comunque pure a 2MHz sballa.

Le soluzioni alternative sono varie: usa gli interrupt sui timer. Se ti servono semplici ritardi fissi, non variabili, puoi usare le routine di delay già presenti nell’hitech-C __delay_ms(costante) e __delay_us(costante) però devi definire la macro _XTAL_FREQ. Fai attenzione agli underscore. Ripeto: queste funzioni le puoi usare solo con una costante nell’argomento, non puoi usare una variabile. Altrimenti usi le routine enhanced precision che ho messo tra le librerie.

Vorrei sapere cosa ne pensi
Grazie di TUTTO (che è veramente tanto)
Fausto

saluti a tutti

unsigned char TimerLed=0;

? Sto dichiarando una variabile di tipo unsigned char (valori da 0 a 255) che ho chiamato TimerLed e l’ho inizializzata con 0 come valore. Cos’è una variabile? Una porzione di memoria ram che uso per fare dei calcoli o per ricordami dei numeri. A cosa serve in questo programma? A mantenere il conteggio per far lampeggiare il led.
All’inizio del corso io però l’ho detto di andarsi a leggere il Tricky C.

complimenti di nuovo per questo capolavoro

PIC 16F876A – 20000000 Hz Clock- Prescaler su 1. 0.2 uS ad incremento, ogni 50 Us ho un Overflow su TIMER0 facendo partire il TIMER0 da 8.
Ogni 400 Overflow ho un tempo esatto di 20 mS. Tra 1 e 31 Nover (numero di overflow) attivo la semionda positiva. 1500 uS, 1,5 Ms

void interrupt ISR (void)
{
if (T0IF) // L’interrupt è stato causato da un overflow del timer0 ?
{
Nover++; //incremento di uno il contatore del Numero degli Overflow
if(Nover==1) //Inizio dell’onda positiva
RB4=1;
if(Nover==Dir) //Dir determina quando deve terminare l’onda positiva. E’ una variabile che modifico per controllare il movimento
{
RB4=0;
}
if(Nover==399)
{
RB4=0;
Nover=0; }
TMR0=8; // RICARICO Timer0
T0IF=0; // FLAG INTERRUPT SU 0, che si setta automaticamente su 1 ad ogni overflow
} // fine che interrupt verificatosi su timer0

} // fine interrupt

QUESTA VERSIONE DEL CODICE MI FUNZIONAVA MALE:…
Però portando questa porzione di codice al main.

if(Nover==1)
RB4=1;
if(Nover==Dir)
{
RB4=0;
}
if(Nover==399)
{
RB4=0;
Nover=0; }

FUNZIONAVA COME UN OROLOGIO SVIZZERO, SE VUOI MANDO PER MAIL TUTTO IL CODICE, NEL CASO VOLESSI METTERLO A DISPOSIZIONE SUL SITO.
Saluti. Davide.

Volevo chiedere una precisazione, dato che l’ISR deve essere più corta possibile, non potresti eseguire una buona parte di questa funzione nel main??
Io l’ISR lo utilizzo solo per far aumentare i contatori, che poi nel main vengono “analizzati in base al loro valore” Ad Es.[ if (contavalori==350) RB1=1; ] e così via… per poi azzerarli quando arrivano al valore limite che ho impostato.. Però sono tutte cose che faccio fare nel main.. non nell’ISR. Sbaglio a fare così?

Non ne trarrebbe giovamento il programma se questa parte di codice venisse portata nel main??

if (TimerLed >= TEMPOLED) // Se il tempo è passato
{
LED=LED^1; // Inverto lo stato del led per farlo lampeggiare
TimerLed=0; // Ricarico il timer del led per ricominciare daccapo

void interrupt isr(void){

if (T0IF){

if(conteggio_timer_led = 60){
LED = LED^1;
conteggio_timer_led = 0;
}
else
conteggio_timer_led++;
// qui vanno le istruzioni da eseguire se l’interrupt è stato causato dal Timer0
T0IF = 0; // devo resettare il flag altrimenti non mi sarà più possibile reintercettare tale interrupt
}
}

ma purtroppo ancora non funziona. Ho provato a mettere un breakpoit nel main, nel quale ci sono solo due NOP(), ma l’eseguzione del programma non si ferma, è come se non eseguisse nemmeno il main.

Metti che l’interrupt sul timer0 ti scatta ogni millisecondo, se tu nella funzione dell’interrupt ci metti un ritardo di 100millisecondi, cosa accade: quando il Delay sta conteggiando i millisecondi, dopo il primo millisecondo conteggiato (anche prima), ecco che la routine di interrupt viene richiamata di nuovo, con la conseguenza che il delay si interrompe al primo millisecondo e tutto quello che viene dopo non verrà mai eseguito. Per tale motivo è altamente consigliato non richiamare routine esterne dall’interrupt: l’interrupt deve essere il piu snello possibile: ci devono stare poche istruzioni, il minimo indispensabile da riuscire ad essere eseguito tra un interrupt e il successivo altrimenti la routine non verrà mai eseguita completamente. E poi mettere addirittura una routine di ritardo nell’interrupt è una cosa assurda anche per il motivo che un interrupt serve proprio ad evitare di utilizzare i ritardi!