GPT sumlja na problem sa Message i daje sledeći predlog da se proba!? : )
Ima smisla šta piše ...
BTW: Ako to ne radi, probao bi sa porukama samo sa jednim karakterom, dužina=1, jedan karakter, "o"=ON, "f"=OFF, tako bi se delimično izbegli problemi sa porukama, može da se čita karakter po karakter bez delay kod prijemnika, ako detektuje jedna od ta dva karaktera radi akciju i ne ostaje ništa u bufferima, izbaciti serial-usb debug-print kod prijemnika da ne usporava loop i tako mora da reaguje na svaki karakter odmah
BTW2: Kod poruka sa više karaktera koje se prenose asinhronim seriskim vezama ODUVEK postoji problem sa početkom i krajem poruke i tu je NEOPHODAN mehanizam sa označavanja početka i kraja poruke ali unikatni karakteri koji ne smeju da se pojavljuju u telu poruke koje se prenosi jer bi nastao konflikt.
Konretno recimo izabere se karakter "#" za početak poruka (SOF-Start Of Frame) pa se sa njim prate pointeri i brojanje dužine dok ne stigne recimo do ";" karaktera (EOF-End Of Frame) koji daje tačan kraj i on je triger za dalje akcije
BTW3: Za povećanje ROBUSTNOSTI tog kanala za komunikaciju takodje je neophodno da se uvede CRC mekanizam, "checksum poruke" koji se dodaje i prijemnik proverava da bi bio siguran da je uhvatio tačno celu jednu poruku jer kod bežičnog prenosa može svašta da se desi i da zbog slabog signala/smetnji primi pogrešne segmente početak od jedne poruke pa nastao prekid pa stigo kraj od druge poruke i to bi CRC trebao da detektuje kao neispravna poruka.
![[Image: attachment.php?aid=45393]](https://forum.yu3ma.net/attachment.php?aid=45393)
Ima smisla šta piše ...
BTW: Ako to ne radi, probao bi sa porukama samo sa jednim karakterom, dužina=1, jedan karakter, "o"=ON, "f"=OFF, tako bi se delimično izbegli problemi sa porukama, može da se čita karakter po karakter bez delay kod prijemnika, ako detektuje jedna od ta dva karaktera radi akciju i ne ostaje ništa u bufferima, izbaciti serial-usb debug-print kod prijemnika da ne usporava loop i tako mora da reaguje na svaki karakter odmah
BTW2: Kod poruka sa više karaktera koje se prenose asinhronim seriskim vezama ODUVEK postoji problem sa početkom i krajem poruke i tu je NEOPHODAN mehanizam sa označavanja početka i kraja poruke ali unikatni karakteri koji ne smeju da se pojavljuju u telu poruke koje se prenosi jer bi nastao konflikt.
Konretno recimo izabere se karakter "#" za početak poruka (SOF-Start Of Frame) pa se sa njim prate pointeri i brojanje dužine dok ne stigne recimo do ";" karaktera (EOF-End Of Frame) koji daje tačan kraj i on je triger za dalje akcije
BTW3: Za povećanje ROBUSTNOSTI tog kanala za komunikaciju takodje je neophodno da se uvede CRC mekanizam, "checksum poruke" koji se dodaje i prijemnik proverava da bi bio siguran da je uhvatio tačno celu jednu poruku jer kod bežičnog prenosa može svašta da se desi i da zbog slabog signala/smetnji primi pogrešne segmente početak od jedne poruke pa nastao prekid pa stigo kraj od druge poruke i to bi CRC trebao da detektuje kao neispravna poruka.