Re:varie riguardo PIC

[Dimitree]

ci avevo pensato, ma non è meglio fare tutto con un interrupt?
o dici che a polling è efficente lo stesso?

[davidefender]

la risposta è: dipende!

cosa altro deve fare il PIC oltre che ricevere MIDI? perchè se la risposta è: nulla! o poco più, allora è semplice la routine di polling! Ma ora mi sorge un dubbio.. sei sicuro che l'inserimento del byte ricevuto nel buffer sia "automatico"? credo che ci sia bisogno dell'interrupt che ricevuto un byte sulla UART lo inserisca nella coda che poi tu, con una seguenza di polling, dovrai controllare.. dovresti vedere un attimo che funzioni hai a disposizione! cerca online, qui ci sono qualche esempio di funzioni con PIC e UART, dagli un'occhiata! e fammi sapere 

http://www.microchipc.com/sourcecode/index.php#serial

ciao! 

[Dimitree]

praticamente quando è stato ricevuto il byte, il bit flag RCIF viene messo a 1, quindi quando ce ne accorgiamo (o via interrupt, o andandolo a controllare noi) possiamo andare a prendere il dato nel registro del ricevitore, che si chiama RCREG.. Poi il flag RCIF viene azzerato automaticamente via hardware quando viene letto e azzerato il registro RCREG.. Ora non capisco solo una cosa..la macchina capisce che abbiamo letto RCREG? oppure l'azzeramento di RCREG va fatto da noi dopo aver letto il suo dato? a questo sul datasheet e su vari documenti non ho trovato risposta..
Secondo voi com'è, intuitivamente?

comunque il PIC deve solo ricevere MIDI e gestire i dati che riceve, ma roba semplice..

[davidefender]

guarda, probabilmente per azzerare il flag basterà leggere il registro.. cmq ti consiglio di provare questa SEMPLICISSIMA applicazione, te la scrivo in pseudocodice:

while (true) {
  if (RCIF == 1) {
    pinLed = HIGH;
    read(RCREG);
    delay(20ms);
  } else {
    pinLed = LOW;
  }
}

molto semplice! ma con questo capisci se le tue supposizioni sono giuste oppure no. La situazione è la seguente:
Colleghi il PIC alla porta MIDI, e pinLed è un pin che scegli tu come output per far accendere e spegnere un led; all'inizio il led deve essere spento, a questo punto mandi un byte tramite MIDI: se tutto funziona dovresti vedere accendersi il led per 20ms e poi spegnersi.

Se invece il LED non si spegne significa che il flag bit RCIF è rimasto a 1, se così fosse prova ad aggiungere una istruzione che scrive 0 nel registro RCREG e rilancia l'applicazione. Alla fine dovresti dedurre quale sia la seguenza corretta delle istruzioni da eseguire! 

guarda cmq questo modus operandi è (almeno per me) tipico, ovvero non sempre è possibile scrivere TUTTO su un manuale o un datasheet, a volte la miglior cosa da fare è proprio inventarsi dei semplici sistemi per testare le nostre conoscenze! ok?

[Dimitree]

si si spegne da solo  ti adoro Davide!!
quando mando troppi messaggi midi di seguito non si accende più, evidentemente il buffer si riempie e quindi la ricezione si blocca (come da datasheet)
ora torno a gestire l'errore!

[davidefender]

ti adoro Davide!!

 

per il fatto che non si accenda potrebbe dipendere anche dal fatto che c'è un notevole spreco di tempo nel tuo programma: per ben 20ms hai bloccato la CPU!  quindi si è vero che intasano il buffer ma sopratutto perchè sprechi tempo invece di leggerli! 
Ovviamente questa era una semplice funzioncina di test, sarà molto più interessante vederlo all'opera! 

[Dimitree]

si mi sa hai proprio ragione
infatti ho abbassato il delay e reagisce meglio
poi ho portato il delay al minimo e reagisce quasi sempre ottimamente.. tranne quando lo intaso tutto con 10 messaggi midi al secondo 

[Dimitree]

però ora che ci penso, se fosse così, perchè allora dopo che non si accende quando lo riempio, non si riaccende più fino a che non "riavvio" il pic?
cioè lo intaso e quindi non si accende più..poi aspetto un po, mando 1 solo messaggio ma non si accende..
Evidentemente si blocca in qualche parte dell' esecuzione

[Dimitree]

ho un dubbio atroce
alcuni messaggi midi prevedono soltanto 2 byte.. quindi, in fase di "accumulo" dei byte, appena vediamo che lo status byte prevede 1 solo data byte, ci fermiamo a quest'ultimo, oppure "prendiamo" un terzo byte che sarà 00000000 ?
dico questo perchè magari attendendo un terzo byte, il pic prende il primo byte del messaggio successivo, quindi un altro status, e si verifica l'errore.. Oppure il terzo byte di 00000000 viene mandato effettivamente (siccome ci sono i bit di stop e end) e viene quindi inteso dall'usart come un vero byte..?

[Dimitree]

bene ho risolto il dubbio semplicemente chiedendo un terzo byte soltanto se lo status byte dice che ci vogliono altri 2 byte..
Ora mi rimane un dubbio, secondo voi quale tipo conviene usare per il byte?
per ora sto usando un int..in modo da poter confrontare tra loro i byte e vedere se sono Status byte o Data byte..e per vedere che tipo di messaggio midi specificano.. Ma c'è un miglior modo per far questo?
per esempio, se l'int è < 01111111 allora so che è uno Status Byte.. e così via..
però sarebbe più comodo confrontare e convertire in esadecimale..
c'è un modo semplice senza complicare troppo l'algoritmo e senza aggiungere troppe istruzioni (ho paura che il pic stia troppo tempo a lavorare e nel frattempo arrivano altri byte che mi riempiono il buffer, forse sono un po paranoico visto che a 4Mhz posso fare un bel pò di istruzioni prima che arrivi un byte) 

[Dimitree]

ed ecco infatti che alla prima prova si blocca il programma..

allora, dichiaro:

Codice: Seleziona tutto

int byte;
int program_change = 11001111;
int data_byte = 1111111;    // massimo valore per un DataByte

poi, faccio questo:

Codice: Seleziona tutto

byte = *registro dell'usart*;

if (byte > data_byte) 
{  
   if (byte == program_change)  accendi led1;
   else accendi led2;
}

il programma supera il primo test (faccio accendere un led subito dopo il primo confronto), quindi si accorge che arriva uno Status Byte, poi però accende sempre il led2, qualsiasi messaggio mando e su qualsiasi canale..mentre invece dovrebbe accendersi il led1 nel caso in cui mando un program change sul canale 16, quindi un 11001111.
dove sta l'inghippo secondo voi?
ho provato anche con altri tipi di messaggi, ma va sempre a finire nell'else..quindi accende led2
sbaglio a fare confronti tra int? se si, perchè allora mi supera il confronto (byte > data_byte)?

ps. chiaramente questa è solo una parte semplificata di tutto il programma

[davidefender]

Ciao Dimitree,

perdonami, ma il fatto che la codifica binaria la scrivi senza b è solo una questione di semplificazione per portarlo sul forum?
cioè, mi spiego meglio: se scrivi data_byte = 1 111 111; vuol dire che data_byte vale "un milione cento undici mila cento undici", perchè le costanti in binario in C non possono essere espresse... diciamo che dovresti scrivere:

int program_change = 0xCF
int data_byte = 0x7F

spero sia stato solo una leggerezza nella trascrizione, confermami prima di tutto questo ok? 

[Dimitree]

si davide in realtà nel programma ho scritto

unsigned int data_byte = 0b01111111;
ecc..



ma se scrivessi in esadecimale (con la notazione che hai usato tu) va bene lo stesso? sarebbe più comodo
fatto sta che sballa i confronti  :'(

[davidefender]

ahhhh ok ok! 

cmq scriverlo in esadecimale o binario, o ottale, o decimale è la stessa identica cosa: è il compilatore che tradurrà quelle costanti in maniera opportuna! La conversione non viene fatta a tempo di esecuzione, ma di compilazione, quindi stai tranquillissimo.

Sul problema, cercherò di ragionarci un poco, se mi viene in mente qualcosa te lo dico subito! 

[Dimitree]

grazie mille Davide.. se vuoi posto il codice effettivo e non quella specie di pseudo codice che ho scritto prima  :'(

ora faccio qualche altra prova..

ma il byte che arriva dall'usart io lo "interpreto" in unsigned int nel momento in cui faccio:

unsigned int byte;

byte = RCREG (il registro dove sta il byte completo a fine ricezione);

faccio bene?
oppure dovrei metterlo in una variabile char?