Problema velocità SPI PIC32MX

[deltax]

infatti era quello che intendevo quando ho detto che dovevo capire bene f_mount...sapevo che satavo sbagliando qualcosa comunque ho capito il perché della tua correzione e sono d'accordo.

Adesso provo una scrittura e vediamo cosa ottengo

EDIT: inoltre ho tolto disk_initialize perché nella documentazione c'è scritto che l'applicazione non deve richiamarla

EDIT2: una cosa mi rende perlplesso. Nel file integer.h, ho la seguente dichiarazione:

Codice: Seleziona tutto

/* These types MUST be 16 bit */
typedef short                        SHORT;
typedef unsigned short        WORD;
typedef unsigned short        WCHAR;


nel commento dice che quei tipi devono essere a 16 bit. Ma short e unsigned short sono a 8 bit. Devo modificarlo?

[deltax]

ho provato, ma non funziona. Si sblocca in qualche punto, perché non raggiunge la fine del programma. Prima di procedere al debug ho guardato un po' il codice e probabilmente necssita di un interrupt tramite timer, nella funzione disk_initialize, come si può vedere dalla riga 564 di diskioPIC32.c. Anche se poi guardando nel disk_initialize dove questo interrupt sarebbe usato, si evince che anche se l'interrupt non c'è dovrebbe funzionare ugualmente

bobina che modifiche hai apportato al codice?

Allora, dal debug emerge che la funzione in cui si blocca è f_open. Se non ho travisato, f_mount dovrebbe funzionare perché mi restituisce 0, che dovrebbe essere il corrispondente di OK. Invece si blocca all'interno di f_open. Nel debug, se faccio uno step into, vedo che si pianta alla riga 2422 del ff.c, dove c'è il codice:

Codice: Seleziona tutto

fp->fs = 0;                        /* Clear file object */

Che è lo stesso che hai riportato tu prima. Non credo sia un caso, ma sento che siamo vicini alla soluzione

[deltax]

Allora, se uso il comando:

Codice: Seleziona tutto

res=f_mount(0, "",&FatFs);

ottengo l'errore 12, ovvero che il volume non ha un area di lavoro. Se invece uso il comando

Codice: Seleziona tutto

res=f_mount(&FatFs, "",0);

che tra l'altro è indicato negli esempi della funzione f_open, ottengo l'errore 13, ovvero che non esiste un volume FAT valido.

Tra l'altro ho letto sulle discussioni nella pagina della libreria che il fatto che f_mount restituisca 1 non è molto indicativo, perché potrebbe ritornare 0 (OK) anche se le cose non sono andate bene.

EDIT: e infatti, mettendo 1 al posto di 0 , cioè montando effettivamente il FAT, ottengo l'errore 13 anche in f_mount.
Inoltre se tento di richiamare la funzione f_mkfs, mi viene restituito un errore di compilazione

[deltax]

chiedo scusa dei post consecutivi ma non si possono editare i messaggi (non capisco perché). Riguardo il mio ultimo post, lasciate stare tutto quello scrito prima di "Tra l'altro...", avevo sbagliato a capire quel comando.

Comunque, dopo aver modificato come mi avevi detto da WORD a DWORD i puntatori, e all'interno di integer.h aver messo gli int al posto degli short dove imponeva i 16 bit, adesso anche la funzione f_open funziona a dovere e mi restituisce 0. Adesso la funzione f_read non mi funziona, e si blocca (verificato col debug) alla riga 2555 di ff.c :

Codice: Seleziona tutto

*br = 0;        /* Clear read byte counter */

[deltax]

allego il nuovo progetto

[bobina]

bene! quindi le modifiche hanno un senso se fopen riesce a creare un file.
Per quanto riguarda mount conviene mettere giustamente 1 almeno vai avanti se non ci sono errori.
le modifiche che ho fatto io riguardano cast di puntatori in caso di operazioni matematiche per modificare l'indirizzo, mikroc non é in grado di farle se non sono interi.
L'altra modifica riguarda l'assegnazione di un indirizzo al puntatore quando questa é la prima operazione di un blocco, come ho spiegato prima.
L'istruzione che hai indicato non é stata toccata.
Gli do un occhiata per vedere se mi viene in mente qualcosa.

[deltax]

Ok ti ringrazio mi hai dato un aiuto veramente grande non avrei mai capito che il problema erano i cast di nikroC....questo perché non sono molto esperto di programmazione non essendo propriamente il mio campo.
comunque avevo capito che la funzione in cui mi da errore non era stata toccata, per questo è molto strano

[bobina]

Penso che il tuo problema sia il fatto che il puntatore che gli passi non è inizializzato. Gli devi passare l'indirizzo di una variabile che può ricevere il numero di byte scritti così:

Codice: Seleziona tutto

UINT scrtti;

int main()
{
....
res=f_read(&fil, carstringa,4,&scritti); // read
}


Il fatto che ti si blocchi, è perché il microcontrollore accede ad un indirizzo di memoria non valido e va in eccezione.

[deltax]

è successa una cosa troppo strana...secondo me mikroC è buggato all'inverosimile...

In pratica il mio programma funziona cosi: scrive su UART start, poi l'errore del f_mount, poi l'errore del f_open e infine i caratteri scritti (se f_read funziona). Ora, il progetto che ti avevo mandato prima scriveva "start 0 0" e infatti si bloccava dentro f_open. Stamattina apro il PC e faccio la prova che mi hai suggerito: la prima volta funziona e infatti mi scrive "Start 0 0 ciao", io tutto felice stavo venendo qui a farti una statua d'oro...poi riprovo e mi compare solo "start", quindi si blocca dentro f_mount. Provo e riprovo riavviadno board programma ecc ma niente. Se torno alla versione precedente (dichiarazione UNIT* scritti e dentro la funzione uso "scritti") mi stampa "start 0 0" quindi lo stesso problema di prima.
E' una cosa assurda, se quella modifica non va a toccare affatto f_mount, come fa a funzionare se poi la tolgo? E perché la prima volta aveva funzionato?
Ho provato anche a inserire funzioni tipo f_close e a smontare il file system utilizzando f_mount(0,"",0) ma nulla.

EDIT: in debug funziona...
EDIT2: in pratica succede questo. Qualsiasi versione faccio, modificata anche di pochissimo (tipo aggiungendo UART constanti che non modificano nulla nel fatFS) il programma non funziona a primo avvio. Se però faccio un'esecuzione in debug, funziona, e comincia a funzionare anche senza debug

[bobina]

Io sarei già passato ad un altro compilatore.
Bisognerebbe guardare l'asm che viene generato per capire dov'è il problema.
Oppure ci potrebbe essere un problema di inizializzazione della SD, se non avessi una board saldata ti avrei consigliato di guardare i collegamenti ed i condensatori di accopiamento.
Il fatto che funzioni in debug puoi significare che il codice essendo più lento perché non ottimizzato riesce ad inizializzare la SD senza problemi. Quando metti una nuova versione del firmware l'alimentazione viene tolta completamente?
Tra una versione e l'altra io lascerei scaricare i condensatori ed assicurarmi che la SD perde completamente l'alimentazione. Se è così quando metti un firmware versione release non dovrebbe funzionare.
Hai provato anche altre SD? Magari la frequenza di clock è oltre le specifiche della SD. Mi sembra (vado a memoria) che le SD prevedono 2 clock per l'inizializzazione una prima lenta e poi una più veloce.