TRISE bit 4

stainless
Autore della discussione
Premium Utente

Di più

6 Anni 6 Mesi fa #1 da stainless

TRISE bit 4 è stato creato da stainless

Ciao a tutti, ogni tanto mi ricordo che una volta mi piaceva smanettare con i PIC e cerco di riprendere questa vecchia passione...ma nel frattempo tutto si è aggiornato!!!
Ho installato MPLABX v.5.05 e il compilatore XC8 v.1.45 e ho provato a compilare (senza errori) questo semplice programmino:

Code:

#include <xc.h>

#include "config.h"

#define _XTAL_FREQ 20000000

int main (void){
    
    
    
    TRISA=0xFF;
    PORTA=0x00;
    TRISB=0XFF;
    PORTB=0x00;
    TRISC=0xFF;
    PORTC=0x00;
    TRISD=0x00; 
    PORTD=0x00;
    TRISE=0xFF;
    PORTE=0x00;
    
    ADCON0bits.ADON=0;
    
    
    while(1) {
        
        PORTD=0xFF;
        __delay_ms(1000);
        PORTD=0x00;
        __delay_ms(1000);
        
    }
}

caricato il firmware su un pic16F877A dormiente ormai da anni sulla FreedomII, ovviamente non funziona.
Dopo aver ragionato un pò lato software (codice, configurazione dei fuses, impostazione dell'IDE ecc.) ho pensato anche a un problema hardware, così ho cambiato scheda di sviluppo (autocostruita) montando un altro pic16F877A nuovo. Anche qui nulla da fare ma su questa scheda ho la possibilità di collegare le stesse periferiche su porte diverse, quindi sostituisco nel firmware PORTD con PORTB, e stavolta funziona.
Aprendo il datasheet del pic mi accorgo che PORTD ha anche funzione di "Parallel Slave Port" settabile tramite il bit 4 del registro TRISE.
Decido di provare a impostare a 0 questo bit nonostante non l'abbia mai fatto in passato e non ho mai avuto problemi di questo tipo, inoltre il datasheet specifica che tale bit all'avvio non è implementato e viene letto come 0.
Il nuovo codice:

Code:

#include <xc.h>

#include "config.h"

#define _XTAL_FREQ 20000000

int main (void){
    
    
    
    TRISA=0xFF;
    PORTA=0x00;
    TRISB=0XFF;
    PORTB=0x00;
    TRISC=0xFF;
    PORTC=0x00;
    TRISD=0x00; 
    PORTD=0x00;
    TRISE=0xFF;
    PORTE=0x00;
    
    ADCON0bits.ADON=0;
    
    TRISEbits.PSPMODE=0;
    
    while(1) {
        
        PORTD=0xFF;
        __delay_ms(1000);
        PORTD=0x00;
        __delay_ms(1000);
        
    }
}

Con l'aggiunta dell'istruzione TRISEbits.PSPMODE=0; entrambi i pic provati ora funzionano.
Qualcun'altro ha mai avuto lo stesso problema? Può essere legato agli aggiornamenti dell'IDE o del compilatore?

int main void{
while(1){
eat();
drink();
have_fun();
ride();
}
}

Si prega Accesso o Crea un account a partecipare alla conversazione.

Mauro Laurenti
Moderatore

Di più

6 Anni 6 Mesi fa #2 da Mauro Laurenti

Risposta da Mauro Laurenti al topic TRISE bit 4

La ragione è legata all'inizializzazione che fai della PORTE.

PORTE non ha tutti i bit e TRISE oltre alla direzione dei bit ha le funzioni speciali.

Nella tua inizializzazione hai scritto TRISE=0xFF; per cui hai impostato indirettamente PSPMODE a 1.

Per questo le cose funzionano solo impostando nuovamente PSPMODE a 0.

La tua inizializzazione dovrebbe essere:

TRISE=0x07;

e puoi togliere

TRISEbits.PSPMODE=0;

Il tutto dovrebbe funzionare.

Saluti,

Mauro

I seguenti utenti hanno detto grazie : stainless

Si prega Accesso o Crea un account a partecipare alla conversazione.

stainless
Autore della discussione
Premium Utente

Di più

6 Anni 6 Mesi fa #3 da stainless

Risposta da stainless al topic TRISE bit 4

Ottimo Mauro, avevo la soluzione sotto gli occhi, devo proprio rimettermi a studiare

int main void{
while(1){
eat();
drink();
have_fun();
ride();
}
}

Si prega Accesso o Crea un account a partecipare alla conversazione.

Mauro Laurenti
Moderatore

Di più

6 Anni 6 Mesi fa #4 da Mauro Laurenti

Risposta da Mauro Laurenti al topic TRISE bit 4

Sei riuscito a capire che necessitavi TRISEbits.PSPMODE=0; ma purtroppo la zappa sui piedi mettendo PSPMODE a 1 te la eri data da solo.

...alcune volte quando si cerca un errore del codice per troppo tempo, è meglio staccare.
...pensare ad altro e poi riguardare il codice.

In ogni modo per il PIC18F46K22 mi è capitato un bit che doveva avere un valore di reset pari a 0 ma ci ho trovato 1.

Alcune volte il valore di reset non è realmente "hard coded" ma viene impostato dal firmware che viene spesso eseguito dal microcontrollore prima di arrivare al reset vector, per cui ci possono essere di queste apparenti stranezze.

Saluti,

Mauro

Si prega Accesso o Crea un account a partecipare alla conversazione.