Show Posts
Pages: [1]
1  International / Generale / Re: [Consiglio]Oscilloscopio on: April 20, 2013, 06:59:54 am
Si, dicevo la seriale, ma in generale volevo avere la possibilità di analizzare trasferimento di dati anche su SPI, I2C o altri protocolli..Quindi con un normale oscilloscopio non si può fare, giusto?

Grazie per le informazioni  smiley
2  International / Generale / Re: [Consiglio]Oscilloscopio on: April 20, 2013, 05:47:31 am
Riesumo questo topic per farvi una domanda dato che anche io sto valutando l'idea di mettere le mani su un oscilloscopio.
Le poche volte che ho usato questi strumenti è stato per vedere segnali per lo più periodici..è possibile però visualizzare anche segnali di trasmissione dati molto estesi nel tempo? Per esempio, sarebbe possibile vedere il comportamento di una Serial.print("Hello World!")?

In pratica, per come so usare io un oscilloscopio credo di sapere come visualizzare la trasmissione del primo o (forse) dell'ultimo carattere, ma non ho idea di come e se si possa vedere l'intera stringa..immagino di sì, magari con la connessione ad un computer..cosa mi dite?
3  International / Software / Re: invertire l'angolo [matematica] on: April 16, 2013, 09:54:26 am
Se ho capito quello che ti serve, potresti tenere la tua formula (180-direzione) è aggiungere un if tipo:
Code:
x=180-direzione;
if (x<0) x=360-x;

Però, anche se non ho idea di quanto dovresti cambiare il resto del codice, credo ti sarebbe infinitamente più comodo cosiderare come "diritto" l'angolo 0° e avere a destra da -1° a -180° e a sinistra da +1° a +180°..


EDIT:
oppure te la cavi con x=(540-direzione)%360, credo..
4  International / Software / Re: Definizione Interrupt Service Routine on: April 04, 2013, 11:56:24 am
Si, non ho fatto nessun controllo di errori..è ancora nello stato di bozza  smiley-roll-sweat

Per quanto riguarda la stringa/buffer di ingresso sto cercando di capire cosa sia meglio, ad esempio se usare due buffer per i dati in uscita e in ingresso o uno solo. Il motivo per cui l'avevo scritta così (oltre al fatto che è la prima cosa che mi è venuta in mente  smiley-mr-green) è che si hanno i dati in ingresso direttamente disponibili senza dover fare la copia di una stringa dall'apposito buffer. Però, oltre al problema che dici tu, si perde anche la stringa inviata.

Credo che poi la scelta sia da fare in base all'applicazione che ci si vuole costruire sopra... io ad esempio dovrei attaccarmi a dei modulini wireless che trasmettono (fino) a 2Mbps e hanno un buffer interno con solo 3 "spazi", quindi non vorrei perdere tempo tra le letture per evitare di perdermi dati. Non sono comunque affatto sicuro che quello che ho scritto possa funzionare per quello ^^
5  International / Software / Re: Definizione Interrupt Service Routine on: April 04, 2013, 08:17:02 am
Alla fine sono riuscito a scrivere qualcosa: per quanto riguarda l'interrupt handler la sintassi è quella che ha detto leo, ISR(SPI_STC_vect){...}.

Ho provato a buttare giù una funzione che invii una sequenza di byte che sia non bloccante. Credo che funzioni ma per ora ho fatto un testing mooolto parziale. Per farlo ho semplicemente aggiunto nella libreria SPI questo:
Code:
volatile int SPI_len;
char *SPI_str;

void SPIClass::sendString(char* string, byte length)
{
//make sure that the SPI interrupt is enabled
SPI.attachInterrupt();
//save length and str pointer in global variable
SPI_len = length;
SPI_str = string;
//move first char in the SPDR register
SPDR = *string;
}

int SPIClass::isBusy(){
return(SPI_len);
}

ISR(SPI_STC_vect){
*SPI_str = SPDR;
SPI_str++;
if (--SPI_len) SPDR = *SPI_str;
}

La funzione SPI.isBusy() si può chiamare per evitare di scrivere mentre il precedente trasferimento è ancora in corso.

Grazie ancora a tutti per l'aiuto smiley
Ciao!
6  International / Software / Re: Definizione Interrupt Service Routine on: April 03, 2013, 02:46:32 am
Posso fare una domanda? Ma hai un problema oppure questo thread è una specie di esternazione delle tue idee?  smiley-lol
Avevi iniziato la discussione facendo intendere che ti serviva capire come si scriveva una ISR e ti avevo dato alcune dritte, però adesso sembra che tu ne sappia più di quel lasciavi intendere e che stia ragionando fra te e te di come risolvere le cose  smiley-wink smiley-grin

 smiley-yell
In realtà i problemi che avevo credo che tu e PaoloP li abbiate risolti. Tuttavia non ho ancora avuto tempo per mettermi al lavoro e verificare se effettivamente riesco a scrivere la ISR come mi hai indicato (anche se non vedo come potrebbe non funzionare).

Il resto del topic è nato dalla domanda di lesto e ho riletto varie volte il datasheet da quando ho postato a oggi^^

E intanto sto anche ragionando di come risolvermi le cose..ma questa è un'altra esternazione di quello che penso  smiley-razz
7  International / Software / Re: Definizione Interrupt Service Routine on: April 02, 2013, 05:27:11 pm
In realtà non credo che il codice si blocchi, ma questa non è una mancanza della libreria quanto una debolezza intrinseca del protocollo: l'ATmega manderà comunque tutto il dato fuori e setterà la flag di interrupt alla fine sia che ci siano disturbi sulla linea sia che dall'altra parte venga disattivato lo slave. Io non apprezzo il fatto che durante la comnicazione il micro resti fermo ad aspettare, ma comunque prima o poi ritornerà a lavorare: se vuoi controlli sulla vitalità dello slave o controlli sulla correttezza dei dati trasmessi devi implementarli a livello più alto per forza di cose per come è pensato l'SPI.

Almeno questo è quello di cui sono convinto  smiley-roll-blue
8  International / Software / Re: Definizione Interrupt Service Routine on: April 02, 2013, 12:37:35 pm
Il periferico SPI è non bloccante: ti basta caricare il byte da passare nel registro SPDR (SPI Data Register) e lui lo trasmette alla velocità impostata. Alla fine lancia un interrupt se abilitato e setta il bit SPIF (SPI Interrupt Flag).

Tuttavia, per come è implementato il trasferimento nella libreria SPI.h credo che se usi l'apposita funzione sia da considerare bloccante perchè aspetta che il trasferimento sia finito per ritornare. Il vantaggio è che non devi definire alcun ISR per gestire la comunicazione.
Code:
byte SPIClass::transfer(byte _data) {
  SPDR = _data;
  while (!(SPSR & _BV(SPIF)))
    ;
  return SPDR;
}
Per quanto riguarda i buffer in uscita non ne hai, hai solo il registro SPDR. In ingresso invece hai un "buffer" a due byte: mentre ricevi un byte hai tempo per copiare il precendente, ma appena anche il secondo viene ricevuto del tutto, il primo va perso.

Per quanto riguarda le funzioni attach e detachInterrupt() esistono sia quelle generiche del core (relative agli interrupt esterni) sia quelle della classe SPI che si "limitano" ad abilitare o disabilitare l'handler (che però non passi come argomento). Tutto questo inizia ad avere senso alla luce di quello che ha scritto leo, ma sto ancora cercando di capire bene come funziona  smiley-mr-green 

Dimenticavo: la gestione degli errori.
Hai un bit che ti segnala se scrivi nel registro SPDR mentre il trasfetimento corrente è ancora in atto, ma non hai niente relativo a timer o cose del genere. Del resto non credo che abbia senso/ che ce ne sia bisogno per come è fatto il protocollo: se vuoi implementare ack o altro devi agire a livello più alto.
9  International / Software / Re: Definizione Interrupt Service Routine on: March 31, 2013, 05:44:53 pm
In quello che viene chiamato CORE di Arduino, nelle sottocartelle dell'IDE.
 --> \\arduino-1.0.x\hardware\arduino\cores\arduino
Grazie Paolo...domani, per digerire la grigliata, mi metto a leggere  smiley-razz

In certe funzioni deve disattivare eventuali interrupts perché quello che fa la funzione é molto criticca a livello di tempo. Se per esempio la libreria SPI deve mandare dei dati con una frequenza vicina a quella del Clock (8 o 4MHz) non possono esserci interuzini dati da un'interrupt.
Ok uwe, però, se ho capito bene quello che ho letto sul datasheet, l'SPI lavora "in parallelo" alle altre operazioni del micro, nel senso che una volta caricato il byte da trasmettere nell'apposito registro, la trasmissione avviene in automatico mentre altre operazioni continuano a essere eseguite. Sbaglio?
E dato che in ricezione, quando il secondo byte viene completamente ricevuto, il primo viene perso. Quindi senza l'utilizzo degli interrupt difficilmente riesco a "garantire" una latenza adeguata (soprattutto se lavoro a frequenze alte)..no?
10  International / Software / Definizione Interrupt Service Routine on: March 31, 2013, 12:17:44 pm
Carissimi, oggi mentre cercavo di digerire la colomba mi sono messo a cercare di capire come funziona la libreria SPI.h.
Pessima idea.  smiley-confuse

Con l'aiuto del datasheet del 328P in realtà credo di aver capito come si comporta, ma mi è venuto un grosso dubbio riguardo alle ISR.
Le funzioni attachInterrupt() e detachInterrupt() della libreria infatti, si limitano ad attivare o disattivare l'interrupt relativo all'SPI (se non vado errato).

La domanda che mi sorge spontanea è allora: come faccio a definire un'ISR?
Ho visto sul datasheet che il il vettore degli handler ha un apposito spazio che dovrebbe contenere (immagino) l'indirizzo della mia funzione:
VectorNoProgram AddressSourceInterrupt Definition
180x0022SPI, STCSPI Serial Transfer Complete
Come faccio però in pratica?

Ho pensato di risolvere il problema leggendo il codice della attachInterrupt() generica, quella relativa agli interrupt esterni, che tra gli altri argomenti prevede anche il passaggio della funzione che faccia da handler. Però qui arriva la seconda domanda: dove lo trovo il codice di questa funzione, così come quello di tutte le altre funzioni "di base", non appartenenti ad alcuna libreria?

Grazie e Buona Pasqua Buona Pasquetta (a questo punto  smiley )
11  International / Megatopic / Re: Arduino Uno Basic Connections on: March 28, 2013, 07:27:58 am
Innanzitutto, complimenti anche da me pighixxx per tutte queste schede^^

Nella 12 hai scritto "Connect via 12C [...]" mentre credo volessi scrivere I2C..

Ciao!
12  International / Generale / Re: [OT]Lavorare con Sistema embedded come? on: March 07, 2013, 09:51:51 am
Io (tra l'altro, "Piacere, Stefano"  smiley-grin ) sono laureato in Ing. Informatica al Politecnico di Torino e ora sto studiando per la specialistica in Embedded Systems.
Per il tirocinio della fine della triennale sono andato in Magneti Marelli (a Venaria) dove fanno parecchi sistemi embedded, dalle centraline ai sistemi di infotainment per il settore automotive.

Ciao a tutti!
Pages: [1]