Ben bezig met een project om via TCP seriële data te versturen van de ene ESP (server) naar 1 of meerdere andere ESP's (cliënts). Als ik voor de afhandeling van de seriële data naar TCP onderstaande stukje script gebruik dan werkt de dataoverdracht over en weer prima als ik alle ESP-modules op een "USB naar serieel converter" plaats. Alleen als ik onderstaand stukje script in mijn project gebruik dan krijg ik de dataoverdracht niet goed. //check UART for data while ((bytesAvail = Serial.available()) > 0) { bytesIn = Serial.readBytes(buf, min(sizeof(buf), bytesAvail)); if (bytesIn > 0) { //push UART data to all connected telnet clients
for (i = 0; i < MAX_SRV_CLIENTS; i++) {* if (client && client*.connected()) {* client.write((uint8_t*)buf, bytesIn);[/td] [/tr] [/table] Gebruikt ik onderstaand stukje script in mijn project dan is de dataoverdracht perfect als ik 1 cliënt op de server aanmeld en kan ik data over en weer sturen. Op het moment dat ik een tweede cliënt aanmeld dan kan ik wel vanaf deze cliënt data naar de server sturen maar als ik vanaf de server data naar de cliënts stuur dan is de data naar de eerst aangemelde cliënt goed en bij de tweede (laatst) aangemelde cliënt verschijnt er voor elke hexadecimale byte FF. *Dus als de server 12 34 56 78 90 verstuurt komt dit op de 2de laatst aangemelde cliënt binnen als FF FF FF FF FF. * // Read data from serial-port and send it to the connected client while(Serial.available()>0){ //push UART data to all connected telnet clients * for (i = 0; i < MAX_SRV_CLIENTS; i++) { if (client _&& client.connected()) { client.write(Serial.read());[/td] [/tr] [/table]* Wie kan mij vertellen waar het probleem in zit? Ik ben geen expert maar het lijkt net alsof de server de data naar de eerste cliënt verstuurd waardoor een buffer leegraakt en de server vervolgens een lege buffer naar de 2de cliënt stuurt._
Jouw vermoeden klopt vast wel.
De FF betekent inderdaad leeg.
Maar wat je doet in die code snippets, is per client data doorsturen die je uit de seriële verbinding leest voordat je m verzendt.
Maar eenmaal gelezen, zit die data dus niet meer in die seriële verbinding, of zoals jij heel terecht zegt, diens buffer.
De oplossing is dus dat je eerst de data uit de buffer haalt en in je eigen buffer zet, waarna je m zo vaak kunt doorsturen als je zelf wil.
Kan je wel een berg geheugen kosten, maar een andere manier kan ik ook niet bedenken.
Aangezien je in je eerste snippet kijkt hoeveel er in de buffer zit, kun je dat ook gebruiken om je eigen buffer te definiëren.
Dus eerst de buffer leegtrekken en in je eigen buffer zetten, en daarna pas doorsturen in plaats van on the fly wat je nu doet.
Zoals ik al aangaf ben ik geen expert (eigenlijk een beginner) maar ik ben naar aanleiding van jouw reactie nu iets wijzer geworden m.b.t. de aparte buffer.
Dus eerste stukje script doet dit:
Seriële data => aparte buffer => standaard buffer => TCP
En tweede stukje script doet dit:
Seriële data => standaard buffer => TCP
Dus in het eerste stukje script wordt de data in een aparte buffer geschreven en op het moment dat je deze data verzend wordt deze data voor het aantal keren naar gelang van het aantal aangemelde clients in de standaard buffer gezet waaruit het verzonden word?
Programma ziet hoeveel clients er aangemeld zijn en weet dat als de data voor elke client vanuit de aparte buffer naar de standaard buffer is gestuurd de aparte buffer leeggemaakt moet worden voor de volgende ronde?
Dan zou ik het eerste stukje script moeten gaan gebruiken en moet ik gaan kijken wat mijn probleem veroorzaakt.
Ik geloof dat als ik het eerste stukje script gebruikte dat er aan het einde van de data er 2 FF'jes achter stonden waardoor alles in de soep liep.
Ook kreeg ik met mijn delay van het voorgaand stukje script (TCP => serieel) de loopback niet weggeregeld.
Maak gebruik van 1 I/O-lijn waardoor de RX en de TX van de ESP-module met elkaar verbonden zitten dus gebruik ik een aanpassing in het script om de onnodige data in de RX buffer eerst te wissen zodat daarna alleen de benodigde data erin zit.
Inderdaad, het 1e stukje haalt eerst de seriële data op en zet die in bytesIn.
Vervolgens word bytesIn dus doorgestuurd naar de clients.
Houd er rekening mee dat tellen niet bij 1, maar bij nul begint.
Dus als buf == 7, dan komen er 8 waardes van 0 tot en met 7 aan.
En kijk ook of jouw client een nul als laatste teken nodig heeft, want dat is vaak het geval.
Dan kan het in dit voorbeeld dus zijn dat er 8 bytes verstuurd moeten worden plus een nul byte.
Maar ik heb geen idee of dat hier van toepassing is, en bovendien is dat juist ook bij seriële communicatie al zo.
De client moet altijd verbinding maken met de server.
Anders draai je de rollen van de client en de server om.
Je zou daarvoor wel kunnen kijken of je iets kunt vinden over push berichten waar er gewoon data gestuurd word.
Maar je zegt ook dat je dat eigenlijk niet wil.
Als je data gericht aan specifieke clients wil sturen en niet alles naar alle clients, dan moet je de clients gaan aanspreken.
Dat noem je adresseren.
Dat betekent dan ook weer dat elke client een eigen adres moet krijgen, en dat de client moet kijken of de data die er zometeen aan komt, wel aan die client geadresseerd is.
Zo niet, moet ie de data dus links laten liggen.