Elenco problemi arduino UNO

Oggi mi son capitate tra le mani 2 board UNO...

che dire ci son rimasto male.

  1. La comunicazione seriale è inservibile, anche inviare una lettera al secondo, se non apri subito il serial monitor(che non sempre si apre dicendo che la ACM0 non esiste, nonostante abia appena uppato il codice), si impalla. Persino il reset, se non usato subito, non ha più effetto e non rimane che de-alimentare la board. A quanto pare la soluzione è uppare il firmware dell'8u2! se avete qualche guida fatta bene postatela, grazie. (ho cercato qualcosa sul forum ma mi pare che sia molta confusione, in oltre mi pare di capire che la IDE 0022 contenga già l'hex con la fix) testato l'aggiornamento del firmware dell'8u2: http://arduino.cc/forum/index.php/topic,75668.new.html Problemi riscontrati (su linux): l'autoreset NON funziona(ma forse è l'optifix?), per il resto tutto ok

  2. "perde" il codice. anche quì avevo letto qualcosa al riguardo, tipo che non perde veramente il codice, so solo che Il led L lampeggia per i cavoli suoi e buonanotte. Problema risolvibile con optifix

  3. (specifica per linux e forse mac) RXTX non è stata pensata per rilevare la ttyACM come seriale, quindi o si usa la libreria modificata contenuta in arduino o si crea un link simbolico.Non è un problema della scheda, ma delle librerie. Comunque da risolvere a mano

Ho letto anche da qualche parte che ci sono problemi con gli sketch troppo grossi, confermate? Confermo con sketch >30kB, Problema risolvibile con optifix

Ciao, mi dispiace......!
Ma prima di caricare lo sketch il programma che carica lo sketch dal pc al arduino fa il test della memoria flash, dunque dovrebbe sengnalarlo che va in overflow come segnala anche gli errori di comunicazione, e se è come nei dispositivi hardware standard dovrebbe segnalare l'inizio e la fine del trasferimento dati e gli errori riscontrati, in caso di errore non dovrebbe apparire DONE ma gli errori!
Se ci sono problemi di comunicazione non si può utilizzare il connettore ICSP anche per caricare gli sketch come si fa con il bootloader o utilizzare i collegamenti del micro TX e RX?
Altrimenti dovrai dissaldare e saldare un altro chip FTDI, auguri componente smd =(

@lesto:
vediamo se posso aiutarti:

  1. per la questione del firmware dell'8U2 io avevo sentito dire che era per altre cose, e poi è troppo problematico flasharlo. Per evitare che la UNO "collassi" uso mettere sempre un delay(3000) nel setup prima di aprire la seriale, per permettermi di farlo materialmente. E' l'unico modo semplice e funzionante.

  2. questo capita se usi il bootloader 2009 sulla UNO. Hai per caso armeggiato con i micro, cambiandoli con altri che avevi in casa o flashando dei bootloader?

  3. io uso RXTX non di Arduino ed a me il link /dev/ttyACMx viene creato in automatico. Casomai ricordati che per poterlo fare devi assegnare il tuo utente ai gruppi tty e uucp (sudo gpasswd -a utente tty,uucp)

  4. il problema degli sketch >30kB esiste e dipende dall'Optiboot. Difatti io sono stato uno dei primi ad adottare l'Optifix che corregge questo bug come quello che lo sketch ArduinoISP non funziona se non usi un condensatore anti-autoreset

facciamo chiarezza, con quello che ho scoperto oggi.
Devo ammettere che se non frequentassi da un pò il forum non ne sarei venuto certamente a capo, sopratutto se non avessi saputo dell'optiboot modificato, che si trova quì: Arduino Forum

allora:

risposta alla 4)

optiboot has problems uploading sketches bigger than about 30 KB

e fin quì ci siamo, diciamo che con un 328P è molto difficile raggiungere i 30KB (il limite sono 32KB)

risposta alla 2)

questo capita se usi il bootloader 2009 sulla UNO. Hai per caso armeggiato con i micro, cambiandoli con altri che avevi in casa o flashando dei bootloader?

non trovo la discussione, ma è legato sempre al fix

optiboot can start sketchs with inconsistent regster configuration side-effects

in pratica (un registro, una varibile? bho, la definirò variabile) R0 viene usata per spegnere il watchdog. Purtroppo questa variabile non è inizializzata all'avvio del boot-loader (cosa che invece era fatta nella versione pre-optiboot), e di conseguenza in rari casi porta al reset infinito del micro.
Questo si può notare dal fatto che il led L continua a lampeggiare. Se invece non lampeggiasse, allora ci si trova di fronte al più raro caso in cui sia l'8u2 da fleshare (non sò perchè).

risposta alla 3)

non ho detto che ttyACM0 NON viene creata, ma che la libreria TXRX (tranne quella inclusa in arduino patchata ad hoc) NON rileva ttyACM0 come seriale, e la scarta a priori; quindi tutti i software basati su questa libreria (processing & java in primis) NON funzionano, salvo utilizzare la libreria inclusa in arduino e non quella scaricabile dal sito (non ho controllato il change-log della versione beta, ma il ticket con la soluzione non risulta processato, quindi da considerare ancora una "ferita" aperta). Posso confermare ciò in virtù del fatto che sostituendo le librerie ora funziona tutto "alla perfezione" (o meglio a baud di 9600 e con 1 secondo tra una trasmissione e l'altra)

risposta alla 1)

effettivamente la procedura che ho trovato è difficoltosa e non abbastanza documentata, ma dal punto di vista HW basta mettere 2 cavi da GND a 2 pin non popolati della board per ottenere di entrare in modalità boot-loader dell'8u2. A questo punto su può uppare lo sketch per il chip, CREDO che l'hex contenuto nell'IDE sia già patchato, ma non ne sono certo.
Nel caso in cui si renda necessario compilarselo, basta un programma aggiuntivo e modificare qualche riga di configurazione.
Questo perchè il firmware dell'8u2, se non erro, è scritto da un altro sito, lo stesso che rende disponibili gli sketch per far rilevare l'8u2 (e di conseguenza l'arduino) come una qualsiasi altra periferica, usando direttamente i driver generici invece di creare un ponte lato macchina tra seriale e periferica virtuale.

CREDO che una discussione come questa fosse da intavolare prima, sinceramente non pensavo che l'UNO fosse così tanto inutilizzabile (basta una Serial.print(), anche ogni 10 secondi, per impallare tutto!), e anzi ora ti supporto pienamente quando dicevi che bisognava mettere il nuovo boot-loader appena questi problemi base erano stati risolti. In oltre anche la pagina "getting started" dovrebbe come minimo menzionare il fatto.

anche il fatto che

Optiboot does not support ArduinoasISP programmer

non aiuta per niente... meno male che affermi:

lo sketch ArduinoISP non funziona se non usi un condensatore anti-autoreset

ciò vuole comuque dire che se non hai un FTDI o un programmatore, puoi cavartela con un secondo arduino (anche UNO)

ahah sarà felice ora menniti che tocca a me andare a chiedere aiuto a lui (o meglio che la sua megaguida mi torni utile :))

scusate il papiro ma voglio essere molto chiaro sull'argomento, che è già incasinato di per sé

edit: per completezza metto pure il link alla guida di menniti, per gli sciagurati che troveranno questa discussione utile: http://arduino.cc/forum/index.php/topic,60789.0.html

leo72:
@lesto:
vediamo se posso aiutarti:

  1. questo capita se usi il bootloader 2009 sulla UNO. Hai per caso armeggiato con i micro, cambiandoli con altri che avevi in casa o flashando dei bootloader?

In realtà è esattamente l'opposto, ne stiamo riparlando su un paio di Topic; Optiboot è scritto per lavorare espressamente sulla UNO, se lo metti su una 2009 o in stand-alone potrebbe dare problemi; il condizionale è d'obbligo, come detto più volte io ho fatto prove incrociate sulle board e non ho mai avuto problemi; invece il problema ce l'ho su uno stand-alone; quando si verifica, basta inviare un qualsiasi carattere sulla seriale ed il micro riparte, quindi nessuna perdita di meoria, ma solo un reset "infinito".

Non ci capisco più una maz... ehm... niente.
Ormai mi si è fuso quel poco di cervello che avevo... facciamo finta che non abbia detto nulla..

ciao

Il problema dell'ACM non è di Arduino ma di rxtx che è fermo a qualche anno fa.. i device acm sono standard per tutti i tipi di modem usb da un bel po'. Noi abbiamo dovuto fornire la nostra versione perchè mettere daccordo tutte le distribuzioni di linux è sfibrante..
Nonostante l'amore che provo per linux è un casino far funzionare le cose perchè ognuno ha la sua configurazione e spesso le versioni di gcc sono bacate.

L'optiboot aveva un paio di bachetti e la sparizione dell'autore non ha aiutato... l'ultima versione funziona bene e si può riparare con optiloader. c'è un tutorial di Federico Vanzati su scuola.arduino.cc su come aggiornarlo.(anche in italiano)

c'è gente che usa la uno come analizzatore di stati logici e hanno la posta seriale che va a velocità elevatissime senza problema...forse i problemi che stai incontrando sono dovuti a qualche software che usi.

ce sono in giro oltre 100.000 se fossero così conciate avremmo avuto molti più report.

m

Il problema dell'ACM non è di Arduino ma di rxtx che è fermo a qualche anno fa.. i device acm sono standard per tutti i tipi di modem usb da un bel po'. Noi abbiamo dovuto fornire la nostra versione perchè mettere daccordo tutte le distribuzioni di linux è sfibrante..

hai ragione, però parlando di una board "per imparare" anche queste cose bisogna tenerle da conto.

L'optiboot aveva un paio di bachetti e la sparizione dell'autore non ha aiutato... l'ultima versione funziona bene e si può riparare con optiloader. c'è un tutorial di Federico Vanzati su scuola.arduino.cc su come aggiornarlo.(anche in italiano)

in effetti ho caricato l'optiboot fixato con l'optiloader e il problema lo ho ancora... però la cpsa strana è che con l'FTDI questo problema non si presenta assolutamente. Cosa strana è che se premo reset, TX non si spegne subito ma impiega un bel pò di tempo, come se ci fosse un buffer da qualche parte.

ce sono in giro oltre 100.000 se fossero così conciate avremmo avuto molti più report.

in effetti... forse diversi sistemi operativi? oppure attivano subito il serial monito o comunque l'apparato "lettore" lato PC, perché così anche a me non da problemi. Il problema è quando arduino scrive e "nessuno lo ascolta"

per ora ho messo una pezza con i delay per darmi il tempo di lanciare tutto l'accrocchio, però la soluzione non mi ispira molto

Scusa Massimo ma fino ad Xubuntu 11.04 a me funzionava tutto correttamente.
Poi ho aggiornato a Xubuntu 11.10 ed ha smesso di funzionare, così come su un altro PC nuovo su cui ho messo da circa 1 settimana Arch Linux.

Guarda caso entrambe usano la stessa versione di rxtx però il kernel 3.0 rispetto alle vecchie distribuzioni. Ora, se 1+1 fa 2, significa che c'è qualcosa nel nuovo kernel. Siccome però questo kernel verrà adottato pian piano da tutte le distribuzioni, questo significa che il problema pian piano renderà inutilizzabili le UNO, se le cose stanno come dici tu. A me non pare che sia un problema da sottovalutare e che si possa risolvere semplicemente dicendo "è colpa degli sviluppatori di rxtx, è colpa di quello o di quell'altro".

La mia UNO fino a 1 settimana fa funzionava benissimo, ora che ho aggiornato tutti i sistemi di casa non la posso più usare per uploadare sketch su micro standalone, nonostante l'Optifix 4.4 che, in questo caso, non risolve assolutamente il problema.

Ho segnalato il bug ma nessuno mi ha risposto o ha preso in considerazione la cosa.
http://arduino.cc/forum/index.php/topic,76138.0.html

lo stesso problema l'ho avuto con una macchina con kernel precedente al 3.

Quale, il mio o quello di Bud? Perché sono 2 problemi leggermente differenti, difatti riguardando bene i codici restituite da avrdude sono diversi.

Io non credo di essere un tipo incapace di configurare Linux, bene o male lo uso da 10 anni, eppure a me non riesce di far andare la UNO con le ultime versioni delle 2 distro che uso in casa. Sarà un caso...

leo72:
Quale, il mio o quello di Bud? Perché sono 2 problemi leggermente differenti, difatti riguardando bene i codici restituite da avrdude sono diversi.

Io non credo di essere un tipo incapace di configurare Linux, bene o male lo uso da 10 anni, eppure a me non riesce di far andare la UNO con le ultime versioni delle 2 distro che uso in casa. Sarà un caso...

Che c'entra Bud ora?

C'era questo in ballo.

oggi leo mi ha installato l'optifix:

il problema

  1. "perde" il codice. anche quì avevo letto qualcosa al riguardo, tipo che non perde veramente il codice, so solo che Il led L lampeggia per i cavoli suoi e buonanotte.

che era provocato da un'autoreset causa bug del boot-loader è stato risolto, e anche:

Ho letto anche da qualche parte che ci sono problemi con gli sketch troppo grossi, confermate?

confermo che c'è il problema con >30kb con boot-loader NON optifix

Grazie al PC di lesto ho anche avuto la conferma che Arduino non è compatibile al 100% con il kernel 3.0, ossia che finché si tratta di uploadare gli sketch sull'arduino non ci sono problemi ma quando si tratta di usare lo sketch ArduinoISP per trasformare l'Arduino in un programmatore ISP questo non funziona.
Il suo netbook aveva Linux Mint con kernel 2.6.38 e funzionava perfettamente, sul mio portatile con Arch e kernel 3.0 no!
La riprova è venuta anche dalla Luigino che mi ha portato astrobeed, che non ha funzionato neanche lei come ISP....

Ora sono molto più triste, perché ho aspetto un miracolo, cioè che qualcuno provveda ad aggiornare driver o kernel (se è come il bug di binutils-avr che è da gennaio che è in attesa di una correzione sto fresco....) oppure devo mettere una distro meno recente con il vecchio kernel.

acc ti ricordi pure la versione di kernel?

ho aggiornato il primo messaggio con le soluzioni i problemi, quella dell'ISP non la metto perchè in comune con il vecchio boot-loader (come dovrebbe confermare la luigino, se non erro)

I numeri non ho problemi a ricordarmeli, a differenza dei nomi per cui sono negatissimo... se devo dirvi come vi chiamate, a distanza di qualche ora, posso dirvi che non ne ricordo nemmeno uno. :sweat_smile:

ora voglio elaborare un metodo per collegare il reset dell'arduino anche all'8u2, o almeno capire se uppando il firmware dell'8u2 si sistemano i problemi