Problema velocità SPI PIC32MX

[deltax]

Ciao a tutti, ho un problema con la velocità dell'SPI in un PIC32MX795F512. RIspetto alle altre domande che ho fatto qualche tempo fa, non ci sono di mezzo simulatori, adesso ho una board fisica con tanto di ICD; inoltre è 3 giorni che sono bloccato e mi sono ampiamente documentato quindi spero di dare un ampia visione di quello che succede per farmi dare qualche idea su questo problema che reputo davvero molto strano. Per iniziare, allego due documenti fondamentali, a cui mi riferirò nel corso del messaggio: il data sheet e la documentazione SPI.
Il mio problema è abbastanza semplice: non riesco a raggiungere la velocità massima dell'SPI scrivendo su una SDHC. Scriverò qui tutti i calcoli e le considerazioni che ho fatto per escludere i vari problemi. Inanzitutto la SDHC ha una velocità sufficientemente alta, mentre il valore minimo è dato dal uC, che è 25 Mb/s. Questo è scritto nella prima pagina del data sheet, ma anche nelle specifiche elettriche di pagina 384, dove il minimo periodo del clock SPI è 40 ns, quindi appunto 25 MHz, e ci si ritrova col dato precedente.
Il clock del SPI è dato da una serie di divisori: tramite un primo registro divisore, SPIxBRG, il clock SPI è ottenuto a partire dal PBCLK, che è il clock del bus delle periferiche. A sua volta questo clock è ottenuto da un dvisore a partire dal SYSCLK, cioè il clock di sistema. Tutte queste cose le dico non per tediarvi ma perché ho effettutato accuratamete i debug per vedere se i valori di questi parametri sono corretti. Io ho impostato (e verificato) che PBCLK=SYSCLK e che SPICLK=PBCLK/8 (attenzione, questo non vuol dire che SPIxBRG è 8, perché c'è una formula di mezzo, presente a pagina 29 del reference SPI). Quindi, facciamo due calcoli per vedere effettivamente a quanto devo andare: con un SYSCLK di 80 MHz, ho un SPICLK di 10 MHz, ovvero 10 Mbps, cioè 1,25 MBps. Questo è la velocità che avrei dovuto ottenere con le impostazioni che ho settato e, ripeto, verificato col debug.
Ho misurato la velocità di scrittura dei dati e mi risulta pari a 155 kB/s. C'è un fattore 8 di mezzo, come potete vedere. Questa velocità l'ho testata con varie dimensioni di pacchetti, ed è sempre uguale. A questo punto passo a descrivere come ho misurato la velocità, non avendo un oscilloscopio per visualizzare il clock dell'SPI. Ho usato semplicemente un timer, che prende i valori all'inizio e ala fine delle operazioni, e poi fa la differenza e i calcoli del caso. A questo punto vi state chiedendo: essendo che il timer usa lo stesso PBCLK, cosa ti dice che anche il timer ha valori sballati? Ovviamente è ciò che ho pensato subito anch'io, e mi sono messo a fare delle verifiche. Ho creato un cronometro, usando il timer1, che accende un primo LED alla partenza e un secondo LED dopo 5 secondi. Con l'aiuto visivo di questo LED ho cronometrato il tempo tra i due con il cronometro del mio smarthpone, ed è esattamente 5 secondi. Quindi il PBCLK è settato correttamente e il TMR1 da informazioni assolutamente reali sul tempo.
Per velocizzare le operazioni, uso la scrittura direttamente su settori. Il programma funziona benissimo, è solo un problema di tempistiche che non mi ritrovo. Si noti che il tempo è preso solamente per la scrittura dei settori, e non anche per la creazione degli swap file, quindi è proprio un tempo netto di scrittura.
Aggiungo che come compilatore uso mikroC. Sebbene questo abbia delle funzioni di "alto livello", magari lasciando all'oscuro l'utente di ciò che si fa, io ho verificato col debug i singoli registri, quindi non credo ci siano dubbi su questo. Aggiungo inoltre, ma non so quanto possa aiutare, che sto usando una board prodotta dalla mikroC che si chiama EasyPIC Fusion v7.

Io ho finito proprio le idee e le verifiche, magari vi viene in mente qualcosa a voi. Chiedo scusa per il post lungo ma credo che dare più informazioni sia di grande aiuto per chi vuole aiutarmi. Ovviamente se volete maggiori info o avete qualche idea su ulteriori prove da fare, lo faccio al volo. Il mistero sarà risolto
Grazie a tutti!

[bobina]

lungo si ma mancano dei dettagli, ad esempio qual è la frequenza del quarzo a cui il PIC32MX è collegato? Per raggiungere gli 80MHz bisogna usare il PLL e fare una certa configurazione che non hai spiegato.
Potresti postare la parte di codice dove fai l'inizializzazione dei registri e la config del PIC?
Cercherò di fare dei test stasera se sei ancora interessato e ti posto i risultati, non ho quella board ma ho quel PIC su un'altra board.
Non ho mai provato a scrivere una SDHC, ma con PWM e SPI raggiungevo senza problemi il massimo della velocità, misurato con un logic analyzer, che ti consiglio di acquistare se vuoi evitare di perdere tempo a fare misure. Su dangerous prototype ne trovi uno abbastanza buono per uso hobby e forse anche qualcosa di più.

[deltax]

CIao grazie per la risposta. Ovviamente nel frattempo le mie ricerche non si sono fermate e, anche grazie a degli utenti disponibilissimi sul forum della microchip, sono riuscito a capire l'origine del problema che mi ha tenuto per 3 giorni incollato al PC almeno 10 ore al giorno.
Il quarzo è esterno, 8 MHz, mentre il PLL è impostato su moltiplicatore 20x e divisore 10x, ottenendo cosi una frequenza di 80 MHz di SYSCLK. Il digital analyzer non mi serve granchè, perché con il metodo del timer che ho descritto riesco a fare misure accurate, per quello che mi è servito finora. Però se vuoi linkamelo (anche in MP se qui non si può) non si sa mai che mi servisse (in realtà ne avevo visti ma abbastanza costosi). Comunque, con il solito metodo del timer ho contato il tempo di un singolo trasferimento di un byte e la velocità è risultata coerente con quella impostata.
Il problema in realtà non è la velocità dell'SPI (e quindi il titolo è ingannevole, non volutamente) ma la velocità di scrittura su memory card. Diversi utenti hanno fatto dei benchmark indipendenti dal compilatore, dalla SD e dal PIC, e la velocità è intorno a 150-170 kB/s, usando i convezionali metodi di scrittura a singolo settore da 512 byte. Perciò mi hanno consigliato di implementare la libreria fatFS, una libreria spettacolare che ingloba funzioni della memory card con un file system leggero ideato per i sistemi embedded ma compatibile con i normali sistemi FAT12,16 e 32.
Tale libreria è fatta in maniera veramente intelligente, in modo tale che sia indipendente dal microcontrollore e si possa adattare a diversi micro modificando solo qualche riga di codice. L'autore ha messo a disposizione degli esempi con vari micro, tra cui il PIC24, anche se comunque non si faticano a trovare in rete anche diverse applicazioni con PIC32.
Il mio problema attuale è che, mentre questi esempi sono scritti per MPLAB, io uso mikroC. Non ho avuto ovviamente alcuna difficoltà a modificare le poche righe di codice di adattamento (relative a impostazione SPI e chip select della MMC), ma non riesco a compilare il progetto perché mi da alcuni errori insipegabili in file header che non ho nemmeno modificato. Quindi suppongo ci sia qualche conflitto interno con mikroC, sebbene io abbia disabilitato TUTTE le librerie di mikroC come tentativo di eliminare tali possibili conflitti.

Per chi mi sapesse/volesse aiutare, descrivo bene il problema: scarico l'ultima versione della libreria (link precedente, in basso), la R011, uscita circa un mese fa. La metto nella cartella del mio programma, e modifico opportunamente il file diskio.c, dove metto tutte le funzioni di SPI e chip select del mio sistema. Nel file main includo i file ff.h e diskio.h, che automaticamente andranno a richiamare i relativi .c file. Tutto questi file, sorgenti e header, li inserisco anche nel project manager di mikroC.
In fase di compilazione, mi dice che non trova windows.h ne tchar.h, richiamati nel file integer.h. Questo è abbastanza strano perché questi 2 sono richiamati attraverso un ifdef che normalmente non dovrebbe essere richiamato, ma lo fa. Comunque, ho risolto togliendoli, perché servivano solo alla versione windows del programma e non a quella embedded. A questo punto compilando senza questi due ho una serie di errori, il primo dei quali in questa riga codice all'interno di ff.h:

Codice: Seleziona tutto

typedef struct {
   BYTE   fs_type;      /* FAT sub-type (0:Not mounted) */
   BYTE   drv;         /* Physical drive number */
   BYTE   csize;         /* Sectors per cluster (1,2,4...128) */
   BYTE   n_fats;         /* Number of FAT copies (1 or 2) */
   BYTE   wflag;         /* win[] flag (b0:dirty) */
   BYTE   fsi_flag;      /* FSINFO flags (b7:disabled, b0:dirty) */
   WORD   id;            /* File system mount ID */
   WORD   n_rootdir;      /* Number of root directory entries (FAT12/16) */
#if _MAX_SS != _MIN_SS
   WORD   ssize;         /* Bytes per sector (512, 1024, 2048 or 4096) */
#endif
#if _FS_REENTRANT
   _SYNC_t   sobj;         /* Identifier of sync object */
#endif
#if !_FS_READONLY
   DWORD   last_clust;      /* Last allocated cluster */
   DWORD   free_clust;      /* Number of free clusters */
#endif
#if _FS_RPATH
   DWORD   cdir;         /* Current directory start cluster (0:root) */
#endif
   DWORD   n_fatent;      /* Number of FAT entries, = number of clusters + 2 */
   DWORD   fsize;         /* Sectors per FAT */
   DWORD   volbase;      /* Volume start sector */
   DWORD   fatbase;      /* FAT start sector */
   DWORD   dirbase;      /* Root directory start sector (FAT32:Cluster#) */
   DWORD   database;      /* Data start sector */
   DWORD   winsect;      /* Current sector appearing in the win[] */
   BYTE   win[_MAX_SS];   /* Disk access window for Directory, FAT (and file data at tiny cfg) */
} FATFS;

dove il compilatore mi da l'errore:

';' expected but 'fs_type' found

Allego il mio progetto in mikroC, dove potete vedere tutti i file, e in più un progetto trovato su internet dove usa sempre un pic32 in MPLAB. Potete vedere che le differenze tra i due risiedono solo nelle definizioni di basso livello dell'SPI e del chip select, e i file in più sono solo i file di configurazione di MPLAB che nel caso di mikroC sono automatici

[bobina]

Il logic analyzer di cui parlo io è questo http://dangerousprototypes.com/open-logic-sniffer/ poi dovrai trovare un negozio dove comprarlo, loro sono cinesi e quindi mettono il link ad un loro shop, ma si trovano anche in negozi europei a prezzi accettabili.
Io lo preso perché quando hai un problema e devi scrivere del codice per verificare qual è la natura del problema, non sai mai se c'è un problema in quello che hai scritto per analizzarlo. :)
Per quanto riguarda il problema del MikroC credo che non venga definito BYTE come tipo di dati, potresti provare a mettere un typedef nel file include

Codice: Seleziona tutto

typedef unsigned char BYTE;
typedef unsigned short int WORD;
typedef unsigned int DWORD;


Magari nel frattempo ci provo anch'io

EDIT
Ho invertito la definizioni dei typedef ogni volta li scrivo al contrario. Comunque ho visto che sono già presenti nell'include integer.h, mancano delle define che sto cercando

EDIT2
per il diskio.h dovrai usare quello dei sample, prendendo quello dentro PIC24 il numero degli errori diminuisce, ma ci sono ancora degli errori di compilazione, che sto risolvendo pian piano, ma bisognerà provare se il codice è ancora funzionante. Ora mi mancano 4 errori di compilazione.

[deltax]

grazie mille, è raro trovare persone su internet che si mettono a compilare il codice che si posta
Comunque anche tu hai mikroC come compilatore?
Mi sono dimenticato di dire che io per creare il mio progetto ho preso proprio i file dentro la cartella pic24 dell'esempio, ho eliminato tutti i file inutili al mio scopo (quelli di config che servivano a MPLAB), e ho solo modificato il file mmc_pic24.c nel mio diskioPIC32.c; dopodichè ho sovrascritto i file della nuova versione R011.
Dico questo perché, siccome ho postat anche l'altro progetto trovato su internet del PIC32, si potrebbe pensare che sono partito da quello. Invece sono proprio partito dall'esempio dell'autore col PIC24, ma comunque il mio arriva ad una struttura praticamente identica anche all'altro progetto PIC32 trovato su internet.
Comunque mi sembra strano che cambiando diskio.h gli errori diminuiscano; ho controllato ora le differenze tra i due, e a parte i define che hanno dei numeri diversi (e non mi spiego perché) nella versione nuova gli header delle funzioni sono uguali (c'è ne uno in meno).

[bobina]

Il tuo progetto dovrebbe essere quello dentro prova PIC32 fatFS.rar perché li vedo il file mcp32 di MikroC, se vedi in quel rar nel file diskio.h c'è definito CTRL_POWER ma non CTRL_POWER_OFF che serve a diskioPIC32.c
MikroC non mi piace perché pone dei limiti e nasconde il sorgente delle librerie, con Microchip ci sono i sorgenti delle librerie e l'unico limite sono le ottimizzazioni.

[deltax]

si ha ragione quella è una limitazione molto grande di mikroC. Infatti io con mikroC non ho avuto problemi finché non ho dovuto fare delle ottimizzazioni per applicazioni con richieste più stringenti...appena si è verificata una cosa del genere mi sono accorto dell'enorme limitazione di non poter guardare dentro le funzioni. Però devo ammettere che per chi non ha grosse pretese permette di fare cose abbastanza velocemente senza grossi problemi.

Comunque si, il mio progetto è PIC32 fatFS.rar.

Adesso in caso provo ad usare tutto il progetto della cartella pic24 sovrascrivendo solo diskio.c col mio pIC32diskio, chissà che funzioni.

[bobina]

In allegato il tuo progetto con le modifiche che ho fatto io per farlo compilare, se vedi sono modifiche stupide per risolvere delle limitazioni di un compilatore, ora l'unico errore che c'è è il demo limit.
Ho un dubbio per poter fare delle operazione matematiche sui puntatori ho dovuto fare il cast a WORD, ora non ricordo se sui PIC32 la dimensione di una variabile puntatore è 16 o 32 bit, nel caso di 32 basta mettere DWORD dove vedi un cast a WORD della variabile dir.

EDIT
più che limitazione direi che ci sono dei bug in quel compilatore, almeno io sto provando la versione demo 3.5.0 del mikroC PRO.
un istruzione così:

Codice: Seleziona tutto

dir = dp->dir;


messa come prima istruzione all'interno di un if

Codice: Seleziona tutto

if (pippo) {
dir = dp->dir; 
}


va in errore, se diventa la seconda no. Lo trovo assurdo.

[deltax]

grazie mille, ora compila. C'è un avviso: "ossible stack overflow : recursion or cross-calling detected. diskioPIC32.c" riferito alla riga 252 del file diskioPIC32.c.
Comunque provo a fare una scrittura su SD e ti dico.

EDIT: prima della prova dovrei un attimo capire come funziona f_mount, in particolare il logical drive number, che nelle versioni precedenti non c'era.
E devo anche capire come interpretare le uscite delle funzioni (FR_OK), cioè come leggerle, ma non credo che questo sia molto difficile

[bobina]

A leggere la documentazione di f_mount dovrai passare una struct FATFS per registrare il filesystem e NULL se vuoi deregistrarlo, quindi dovrai modificare il tuo provafatFS.c in

Codice: Seleziona tutto

f_mount(&FATFS_Obj,"",1);


mi domando come faceva a non andare in errore la compilazione.