Problema con comando AT+CIPSTART dell'ESP8266

[gotthard]

Salve a tutti!

Sto lavorando con una Evaluation Board della Texas Instruments (Tiva C Series TM4C123GXL su cui è montato il microcontrollore TM4C123GH6PM) e con il modulo Wi-Fi ESP8266.

Le connessioni sono queste:

- il modulo UART0 del uC TM4C123GH6PM è connesso alla porta USB del computer;

- il modulo UART2 del uC TM4C123GH6PM è connesso all'ESP8266.

Ho fatto un programma semplice semplice che tutto quello che trova nella UART2 lo mette nella UART0, e viceversa.

Così facendo, utilizzando il programma PuTTY:

- riesco ad impartire, direttamente dalla sua interfaccia, digitandoli, i comandi AT all'ESP8266;
- riesco a vedere le risposte inviate, dal modulo ESP8266, direttamente sul PuTTY.

Ora che ho descritto la situazione, vado al sodo, e solo chi ha utilizzato il suddetto modulo Wi-Fi credo possa darmi una mano..

Ho utilizzato parecchi comandi, ma ho riscontrato un particolarità con il comando AT+CIPSTART, cioè quello usato per instaurare una connessione (di tipo UDP o TCP) verso un certo IP e verso una certa porta.

In particolare:
mi sembra di aver capito che questo modulo Wi-Fi, una volta aperta una connessione (UDP nel mio caso), verso un certo ip e porta, deve per forza essere il primo ad inviare qualcosa, altrimenti non riceve niente

Questa cosa mi è sembrata un po' strana, e quindi volevo chiedere a qualcuno di voi che l'ha utilizzato se l'ha riscontrata.

In pratica:

Impartisco questo comando al modulo Wi-Fi:

Codice: Seleziona tutto

AT+CIPSTART="UDP","indirizzo ip del mio computer",porta

così facendo, ho effettivamente aperto una connessione UDP verso un certo indirizzo IP e verso una certa porta.

Vado ad aprire una connessione di tipo UDP, inizialmente in ascolto (verso la stessa porta utilizzata nel comando di prima impartito all'ESP8266) tramite il famoso netcat, con questa riga (senza i simboli < e >):

Codice: Seleziona tutto

nc -u -l -p <porta>

Avendolo aperto inizialmente in ascolto, il netcat non può essere il primo ad inviare, ma deve prima ricevere qualcosa.
Poi, allora, sarà pure in grado di rispedire qualcosa al mittente.

Ora, impartendo all'ESP8266 il comando AT+CIPSEND (digitandolo direttamente sull'interfaccia del PuTTY) riesco ad inviare ciò che voglio (supponiamo la scritta "CIAO") dal modulo Wi-Fi al netcat che gira sul computer, e, una volta che la scritta "CIAO" sarà giunta al netcat, possiamo inviare qualcosa, tipo la scritta "HELLO", dal netcat al modulo Wi-Fi.
E questa, giunta all'ESP8266, la visualizzo sull'interfaccia del PuTTY.

Fino a qui tutto OK!, perché è stato il modulo Wi-Fi il primo ad inviare

Ora, supponiamo un' altra situazione:

Impartisco lo stesso comando di prima all'ESP8266:

Codice: Seleziona tutto

AT+CIPSTART="UDP","indirizzo ip del mio computer",porta

Ora, apro sul netcat una connessione sempre di tipo UDP, ma NON IN ASCOLTO, con questa riga (senza i simboli < e >):

Codice: Seleziona tutto

nc -u <indirizzo ip dell'ESP8266> <porta>

Ora, se provo ad inviare, qualcosa scrivendola sull'interfaccia del netcat (tipo "CIAO" e premendo INVIO), al modulo Wi-Fi non ci riesco, visto che sull'interfaccia del PuTTY non mi arriva nulla.

È come se il comando AT+CIPSTART="UDP","indirizzo ip",porta dell'ESP8266 funzioni come il comando del netcat
nc -u <indirizzo ip> <porta>, cioè che apre una connessione dove deve essere per forza lui ad inviare per primo!

Chi ha questo modulo ha riscontrato questa cosa, o può fare una prova per verificarla?

PS: Il punto è che a me serve, visto che devo integrare questo modulo in un progetto già esistente, che il modulo ESP8266 sia il primo a ricevere i dati e non ad inviarli. È possibile farlo con questo modulo?


Un grazie in anticipo!

[filippo125]

Anche io sono in procinto di utilizzare il modulo ESP8266 in un modo molto simile, ma sono in attesa dei PCB di test. Parlo, quindi, senza esperienza diretta (e potrei dire molte sciocchezze).
Nella mia testa pensavo di iniziare una connessione UDP così:
AT+CIPSTART="UDP",0.0.0.0,0,<local port>,2
Poi al primo pacchetto ricevuto dallo status ricavo l'indirizzo ip del mittente
Filippo