Il buon giorno inizia dal mattino... Arduino 1.0 RTM

Consiglio spassionato: se devi iniziare ora prendi a occhi chiusi la Uno. E' molto più semplice, trovi un sacco di librerie ed esempi ed è la più conosciuta.

La due, oltre a costare molto di più della uno (penso che il prezzo sarà intorno a quello della mega2560 se non più alto) sarà molto più complicata. La due monterà un microcontrollore di tutto rispetto con tanto di 1200 pagine di datasheet, contro le 450 del mega2560 (che è il top di gamma della famiglia AVR).

Arduino DUE sará un Arduino a 32 Bit percui una nuova scheda. Ciao Uwe

Vabbè, è quantomeno riduttivo dire che la due ha come unica novità un processore 32bit.

E andiamo di arduino UNO allora :) grazie ragazzi :grin:

Si si, per iniziare vai con la Uno a occhi chiusi.

Salve a tutti, io sono un neofita di arduino e soprattutto dell'elettronica in generale. Programmo in python e del C++ non so nemmeno come e fatto. Ora vi farò probabilmente una domanda stupida ma abbiate pazienza. Io ho una board 2009 ed ho scaricato il nuovo idle. Avrò problemi nella programmazione?

astrobeed: ~~~ core.a(HardwareSerial.cpp.o): In function __vector_19': arduino-1.0\hardware\arduino\cores\arduino/HardwareSerial.cpp:192: multiple definition of__vector_19' ~~~

Ho scoperto il motivo dell'errore, è il linker a rilevarlo e non il compilatore, è dovuto al fatto che MultiWii definisce un suo vettore di interrupt, è il vector_19 dell'errore, per gestire la trasmissione UART (seriale hardware). Nella libreria HardwareSerial del core delle precedenti versioni l'interrupt sulla trasmissione UART non era utilizzato, mentre nella 1.0 viene usato e definito all'interno della libreria, questo crea un conflitto tra le due definizioni che si traduce nell'errore fornito dal linker. Adesso devo scoprire se esiste un modo per ridefinire l'interrupt UART senza modificare forzatamente il core, se non c'è questa si che è una grave carenza del nuovo ambiente di lavoro 1.0.

Non cambia niente rispetto al mio problema. Per farti l'analogia, all'interno della libreria modbus-slave utilizzava la Serial.print(xxxx, BYTE) ed ho dovuto modificarla sostituendo la print con la write. Nel tuo caso modifichi la libreria multiwii cambiando il nome del vettore.

Janos: Per farti l'analogia, all'interno della libreria modbus-slave utilizzava la Serial.print(xxxx, BYTE) ed ho dovuto modificarla sostituendo la print con la write.

Questo è un problema che riguarda chi ha scritto quella libreria, che non è tra quelle ufficiali di Arduino, sarà compito suo modificarla come serve, nel frattempo non la usi con l'IDE 1.0 :)

Nel tuo caso modifichi la libreria multiwii cambiando il nome del vettore.

Il vettore 19 è una cosa predeterminata ad hardware, non puoi modificarlo a tuo piacimento, la ISR per l' UART deve per forza fare riferimento a quel vettore, non puoi semplicemente rinominarlo, la tabella di riferimento è la 11.2 del data sheet.

pls, sistema i quote... ;)

Ho capito, in pratica sono definiti due vettori dello stesso interrupt... E' normale che il linker si arrabbi...

Ma prima come funzionava? La ricezione di un dato non era gestita a livello di interrupt?

Ok, forse era troppo stupida la mia domanda… :~

Janos: Ma prima come funzionava? La ricezione di un dato non era gestita a livello di interrupt?

Nella precedente versione della libreria, e parliamo di quelle del core non di quelle del compilatore e delle avrlibc, non vengono definiti gli interrupt per l'UART, probabilmente viene fatto da qualche altra parte previo controllo se non sono già stati definiti all'interno dello sketch. Nella libreria della 1.0, è quasi il doppio come dimensioni rispetto a quella della 0022, gli interrupt UART sono definiti all'interno di questa apparentemente senza nessun controllo. Devo investigare meglio su questa cosa perché per il momento ho dato solo uno sguardo veloce per verificare se il problema è effettivamente li, infatti commentando le relative righe il programma viene compilato senza problemi, devo capire se tramite delle define nello sketch posso bypassare gli interrupt UART definiti dal core.

blog post di oggi: http://arduino.cc/blog/2011/11/30/arduino-1-0-now-available/

nel quale c'è un link ad un post di parecchio precedente che descrive tutte le differenze della 1.0: http://arduino.cc/blog/2011/10/04/arduino-1-0/

Le informazioni non sono poi così nascoste.

Ed ecco la risposta al problema in cui sono incappato:

Serial transmission is now asynchronous – that is, calls to Serial.print(), etc. add data to an outgoing buffer which is transmitted in the background.

Infatti con la vecchia versione del core solo la ricezione da UART era tramite interrupt, ora lo è anche la trasmissione, ovvero se inviate una stringa di caratteri con la serial.print lo sketch non rimane fermo fino alla fine dell'operazione, continua a girare mentre i caratteri vengono inviati tramite ISR. Dato che MultiWii usa lo stesso sistema per la telemetria tramite una apposita ISR, che più o meno fa la stessa cosa di quella del core, ecco che si viene a creare il conflitto perché non possono esserci due ISR collegate allo stesso vettore. Purtroppo non è possibile eliminare semplicemente la ISR definita da MultiWii, anche se così facendo il tutto viene compilato senza errori poi la telemetria, ma anche l'uso della GUI di configurazione, non funziona perché un flag non viene più modificato all'interno della ISR per il Tx UART.

Ma se ora la print è gestita a livello di interrupt non potresti utilizzare, all’interno del multiwii, la print invece che andare a lavorare sul vettore di interrupt?

Janos:
Ma se ora la print è gestita a livello di interrupt non potresti utilizzare, all’interno del multiwii, la print invece che andare a lavorare sul vettore di interrupt?

In teoria si, in pratica no perché la ISR di MultiWii è questa:

ISR_UART
 {
   UDR0 = s[tx_ptr++];               /* Transmit next byte */
   if ( tx_ptr == point ) {            /* Check if all data is transmitted */
   UCSR0B &= ~(1<<UDRIE0);     /* Disable transmitter UDRE interrupt */
   tx_busy = 0;
  }

Molto semplice ed efficace, c’è di mezzo quel “tx_busy” che è un flag utilizzato per segnalare quando è possibile inviare nuovi caratteri sulla seriale, flag che ovviamente non è presente nella libreria del core e se rimane sempre a 1 dopo il primo pacchetto di dati inviati non arriva più nulla.
Ho già provato ad inserire il flag nella libreria del core e adesso il programma si compila e funziona senza problemi, però è una soluzione che non mi piace, con calma ne troverò una migliore modificando come serve tutto lo parte che gestisce le comunicazioni seriali.
Diciamo che il test di compilazione su MultiWii è stato un ottimo banco di prova per trovare eventuali incompatibilità, e infatti una è venuta fuori subito :slight_smile:

Quel flag ti serve per attivare un pin per abilitare il trasmettitore di un bus half-duplex, tipo una 485? Se si dai un'occhiata a questo link: https://sites.google.com/site/jpmzometa/arduino-mbrt/arduino-modbus-slave e guarda la funzione ModbusSlave::send_reply. Fa esattamente quello. Altrimenti se mi dici a cosa ti serve se mi viene a mente qualcosa te lo dico.

Quel flag è per il software, lo usano tutte le funzioni, non poche, che scrivono sulla UART per la telemetria e la GUI di configurazione per sapere se il buffer di trasmissione è pronto per il nuovo pacchetto dati e per bloccarlo una volta caricato. Magari era solo un flag di DIR per la 485 o qualcosa di simile, l'avevo già risolto :) In tutti i casi la "colpa" è dell'autore del software che ha usato un metodo macchinoso per gestire il buffer TX, io avrei semplicemente controllato il puntatore al buffer, quando arriva a 0 è vuoto.