next topic »

[Reply #15 on:]

non si dice palliativo ?  

cmq la libreria e' la standard dell'IDE arduino

[Reply #16 on:]

uff precisino 

la libreria è bloccante, quindi in teoria nessun problema da quella parte... uhmmm molto strano

[Reply #17 on:]

stavo pensando pero', che al primo invio io ricevo sti 200byte, li metto in ram, e quindi in ram sono occupati 200byte, quando invio per la seconda volta i 200Byte prima devono essere ricevuti, e poi vanno a sostituire i 200 vecchi giusto ?

Code:

dato = stringadaseriale

ora quando ricevo i nuovi 200byte, nell'istante prima che vengono copiati in "dato" la ram e' occupata sia dalla stringa vecchia che dalla nuova secondo voi ? a questo punto occuperei 400Byte per un tot di tempo

[Reply #18 on:]

che poi, scusate se rompo troppo, ma voi potete fare una prova in tal senso ? quindi un programmino che invia 500 caratteri via seriale ad arduino. se anche voi avete problemi e' interessante.

[Reply #19 on:]

allora esiste un piccolo buffer HW, una specie di micro ram dedicata alla seriale (credo forse un paio di registri, ma non ho mai letto nulla al riguardo). quando arriva un byte seriale, viene parcheggiato in questo buffer e viene lanciato un inerrupt. l'interrupt prende questo  byte e lo "sposta" nel buffer seriale.

Il buffer seriale è creato dal setup, ed è fisso, quindi dal memnto in cui chiami setup hai X byte di RAM in meno ma non cambiano più.

[Reply #20 on:]

credo ti riferisci a quello che ha gia' spiegato leo la pagina precedente.

cmq non mi sono spiegato, intendo dire questo:
0) i dati dall'esterno entrano in questo buffer hw che non ha modo di perderli, se ho capito, cioe' il rpoblema non e' qui
1) i dati passano nel buffer ring da 256byte (l'ho modificato io, originariamente era 64, grazie a leo)
2) pianpiano questo viene svuotato e i caratteri passano nella ram di arduino (li' restano, li visualizzo su lcd ma non li metto in nessun altro posto)
3) la ram tiene in questo momento i 200char, quando invio i nuovi 200char questi fanno la stessa strada dei primi, pero' non so come si comporta la fase finale, cioe' i 200 nuovi sovrascrivono i 200 vecchi ? un carattere alla volta ? oppure ci saranno due spazi di ram occupati, quelli vecchi e quelli nuovi ? cioe' in un determinato istante servono 400Byte di spazio utile per fare la copia ?

[Reply #21 on:]

allora esiste un piccolo buffer HW, una specie di micro ram dedicata alla seriale (credo forse un paio di registri, ma non ho mai letto nulla al riguardo). quando arriva un byte seriale, viene parcheggiato in questo buffer e viene lanciato un inerrupt. l'interrupt prende questo  byte e lo "sposta" nel buffer seriale.

Il buffer seriale è creato dal setup, ed è fisso, quindi dal memnto in cui chiami setup hai X byte di RAM in meno ma non cambiano più.

Non si legge più quello che scrivono gli amici? 

I buffer di cui si parla sono solo quelli SW, cioè gli array creati e gestiti da HardwareSerial.cpp e .h.
Come buffer hardware l'Atmega328 ha 2 registri e basta. Il primo è un registro a scorrimento in cui viene composto il dato man mano che arrivano i suoi bit. Una volta che è stata completata la ricezione il dato viene copiato in un altro registro, da cui il codice può leggerlo. Quando viene copiato in questo secondo registro, viene attivato un interrupt di ricezione terminata e dato pronto. E' a questo punto che scatta la ISR, che preleva il byte e lo copia nel buffer SW di cui stiamo parlando.

[Reply #22 on:]

2) pianpiano questo viene svuotato e i caratteri passano nella ram di arduino (li' restano, li visualizzo su lcd ma non li metto in nessun altro posto)

no, nel momento in cui estrai un byte dal buffer e lo invii all'LCD, se non sei tu a salvarlo viene perso. Quindi nessun consumo aggiuntivo di ram.

[Reply #23 on:]

?

spetta io ho scritto che metto in una variabile la stringa ricevuta

Code:

dati=chardaseriale

in questo momento i dati sono in Ram e li' restano, anche se faccio il print su lcd.

Solo col secondo invio la variabile dati riceve la nuova stringa e poi la si riprinta su lcd.
ma nella ram come vedi c'e' sempre la stringa, mentre il buffer seriale, quello da 64byte si svuota.

non e' cosi' ?

proprio credendo che sia cosi' mi chiedevo l'istante prima in cui "dati" contiene stringa1 e vuole ricevere stringa2 la ram deve avere 200Byte liberi ? (200 gia' 0ccupati da stringa 1, e 200 per la nuova stringa ?)

[Reply #24 on:]

Ho fatto un test con lo sketch standard serial event, e riesco a ricevere e trasmettere 1,7KB  
x leo, quel .reserve che hanno messo non mi apporta nessun vantaggio, anche se lo tolgo ricevo sempre 1700char

sulmio progetto invece riceve solo una decina di caratteri, aggiungendo il famoso delay di 1ms ritorna tutto come prima, cioe' una sessantina di caratteri con 'lide arduino non modificato

puo' essere colpa dell' I2C ? (uso un lcd i2c, quello che ho in firma, la libreria che io sappia e' derivata da quella originale)

[Reply #25 on:]

Posto i risultati di tutti i miei test:

delayMicroseconds
0ms   : ricevo 10 caratteri
10   ---   10
25  ---   30
50   ---  60
100   ---  130
200   ---  80
100+reserve128 180
100+reserve256 190
100+reserve350 180
delay100 0 reserve + modificando hardwareserial.cpp buffer a 256 = 220

Ho scoperto che abbassando il delay di cui parlavamo a 100microsecondi, riesco ad alzare a 130char senza toccare i buffer. aggiuggendoci un piccolo Reserve da 128Byte, arrivo a 180, e' poco utile aumentare questo valore.

Come vedete la situazione migliore resta quella di modificare il buffer in hardwareserial.cpp, che mi fa arrivare a 220.

Per voi e' facile capire di preciso cosa fa questo comando ? va a modificare i buffer e quindi "perdo" 256byte, oppure non tocca i buffer e "perdo" solo 128byte ?

Code:

CharDaSeriale.reserve(128);