
Come programmare Arduino in modalità wireless. Il sistema Arduino offre un metodo open source per la programmazione dei microcontrollori.
Normalmente questo significa utilizzare un cavo seriale o USB collegato direttamente al microcontrollore.
Ma se il progetto galleggia in una sonda atmosferica? Sarebbe bene poter caricare le modifiche del codice in modalità wireless. L'articolo presenta come costruire una soluzione wireless per fare upload del codice ad un microcontrollore Arduino remoto utilizzando una coppia di XBee, e, una funzione utile per la realizzazione dei reset wireless.
Di cosa avremo bisogno
- - due alimentatori 5-15VDC
- - due moduli Two XBee OEM RF saldati
- - una installazione per collegare un XBee (o USB) sul vostro computer
- - una scheda arduino
- - un regolatore 3.3V
- - un transistor 2N2222A
- - LEDs
- - vari cavi
Utilizzando una connessione seriale, programmare i due moduli XBee per dialogare tra loro a 19.200 baud. Si può utilizzare HyperTerm o ZTerm. Per Mac OS X si può utilizzare il programma screen in una finestra terminal. (Il comando dovrebbe essere qualcosa del tipo: screen /dev/tty.Keyserial1 9600).
Questo esempio utilizza il default PAN ID di 3332, ma si dovrebbe scegliere uno diverso in modo che le altre radiotrasmittenti XBee nella zona non interferiscano con la comunicazione. Per la prima XBee, usare la sequenza +++ per entrare in modalità comando. Si dovrebbe ricevere un messaggio di OK. Poi questo comando:
ATID3332,DH0,DL1,MY0,BD4,WR,CN
Collegare la seconda XBee e utilizzare di nuovo la sequenza +++ per entrare in modalità comando. Poi questo comando:
ATID3332,DH0,DL0,MY1,BD4,WR,CN
L'unica differenza è che per la seconda XBee, si imposta l'indirizzo di destinazione a 0 e l'indirizzo locale a 1. Le due XBees sono ora configurate per dialogare tra loro.
Collegate il regolatore da 3.3 Volt per alimentare la XBee. Il modulo XBee è alimentato con 3.3 Volts e connesso ai pin RX e TX e 0 e 1 di Arduino. Un LED è connesso al pin 13, e la base di un transistor è collegata al pin 12. Il collettore del transistor è collegato al pin di reset e l'emettitore è collegato a massa
Caricate il seguente codice:
/* Programming Arduino Wirelessly * ------------ * This program waits for a *reset serial message from a remote computer, * then resets the Arduino chip after a delay to allow the microcontroller to * accept an upload of new code from a remote device. * Robert Faludi * [email protected] */ int ledPin = 13; // LED connected to digital pin int transistorPin = 12; void setup() { pinMode(ledPin, OUTPUT); // sets the digital pin as output pinMode(transistorPin, OUTPUT); blinkLED(ledPin, 2, 500); // startup blink delay(1000); Serial.begin(19200); // start serial at 19200 baud, same as programmer speed } void loop() { blinkLED(ledPin, 1, 250); if ( Serial.available() > 0) { // if there are bytes waiting on the serial port char inByte = Serial.read(); // read a byte if (inByte == '*') { // if that byte is the desired character int len = 5; // expected string is 6 bytes long char inString[len]; // declare string variable for (int i = 0; i < len; i++) { inString[i] = Serial.read(); } if ( strstr(inString, "reset") != NULL ) // check to see if the respose is "reset" resetChip(5000); // reset the chip after waiting for the specified # of milliseconds } } } void resetChip(int delayTime) { /* if the project does not typically receive data, and accidental chip resets are tolerable, * this is a simple method that should work just fine. Otherwise it is recommended that the * reset request string be part of a call-response sequence, be transmitted with a * reserved byte or byte string, or be transmitted in some way out of band, so that it is not * accidentally received. */ Serial.print("\nArduino will reset in "); Serial.print(delayTime/1000, DEC); Serial.print(" seconds...\n\r"); blinkLED(ledPin, delayTime/100, 100); // wait for the specified amount of time, doing nothing Serial.print("\nResetting NOW.\n\r"); digitalWrite(transistorPin, HIGH); // switch on a transistor that pulls the chip's reset pin to ground }
void blinkLED(int targetPin, int numBlinks, int blinkRate) { // this function blinks the an LED light as many times as requested for (int i=0; i<numBlinks; i++) { digitalWrite(targetPin, HIGH); // sets the LED on delay(blinkRate); // waits for a second digitalWrite(targetPin, LOW); // sets the LED off delay(blinkRate); } }
Collegate una XBee al vostro pc per poter comunicare con esso dal programma terminale seriale ed anche dal programma di arduino.
Leggi anche: Open Source PSP Kit by Arduino

Quanto sopra è sicuramemte fattibile con un microcontrollore ma, data la tipologia del progetto, mi discosterei da un approccio hobbistico.
Ogni caratteristica che richiedi andrebbe approfondita singolarmente e poi analizzata all’interno di un progetto globale, valutando da subito anche una metodologia di collaudo.
Anche se è stato protagonista di applicazioni satellitari, ci penserei bene ad affidare la sopravvivenza di un sommozzatore ad Arduino, se non a fronte di particolari accortezze che, come detto, esulano dall’approccio hobbistico.
http://it.emcelettronica.com/arduino-ha-vinto-cerchiamo-di-non-perdere-noi-ora
Se invece ti riferisci unicamente “allo scarico dati” post immersione, allora è soltanto una questione di interfaccia e protocollo.
E personalmente il fatto di programmare a distanza Arduino o qualsiasi microcontrollori,
La reputo un’operazione molto azzardosa.
il fatto è che non potendo garantire la connessione wireless di buona qualità e senza errori e per di più con un flusso continuo, punirebbe il problema di una programmazione errata e per di più perfino la perdita della bootloder che renderebbe civile nel processo di riprogrammazione remoto e necessiterebbe di riprogrammatolo al livello più basso compreso il programma del bootloder.
@rebreather
Personalmente penso che Emanuele ha ragione,
Semplicemente perché alcuni di questi punti non potrebbero essere svolti direttamente da un microcontrollori errori motivi ad esempio il crash del programma parlo ad esempio calcolo dei valori di soglia per gli allarmi che dovrebbe essere gestito puramente al livello analogico con componenti molto più affidabili, anche se ormai microcontrollori sono molto affidabili