07-06-2023, 06:12
Nic nie wysyła, a przynajmniej niewiele. Write zapisuje 1 bajt, float ma 4. To w ogóle Ci działa? W bibliotece UART do Arduino nie chce zrobić write floata, bo widzi, że to lipa. Dostajesz mimo wszystko sensowne wyniki, niby ucięte do liczby całkowitej, ale tylko dlatego że mieszczą się w pierwszym bajcie, jakbyś wysłał 2343.234 to już zobaczysz głupoty.
W zwykłej bibliotece wystarczy napisać sensors.setWaitForConversion(0); to jest ten tryb asynchroniczny wspomniany powyżej, tylko potem trzeba samemu pilnować kiedy zlecasz pomiar i kiedy go odczytujesz. Ale ponieważ zarządzanie czasem i mierzenie jego upływu to podstawowa umiejętność niezbędna do napisania jakiejkolwiek użytecznej aplikacji, to nie jest to problem, czy nadmiarowa praca, to i tak trzeba ogarnąć.
Wtedy masz to samo co w tej nonBlockingDallas, ona też jest blocking, bo nie da się inaczej, zmiany bitów są za szybkie by to miało sens, jak nie zablokuje na te 15ms loop to zablokuje przerwaniami wszystko. Znaczy da się inaczej, jak jest wolny UART to nim można przełączać się między dwoma prędkościami i nadawać bity 1-WIRE jako bajty UART. Wtedy zestaw danych do wysłania trafia do bufora i uC jest zajmowany na us by uzupełnić bufor kolejnym bajtem. Na pewno jest biblioteka w C ogólnie dostępna, ale w Arduino na razie nie widziałem.
Zacznij od napisu.
Masz przykład tu na forum, poszukaj Serial ewent. Zresztą, masz tu: https://forum.arduinopolska.pl/watek-uar...ino?page=2
Przejrzyj jak to wygląda, generalnie w punkcie RS485.available() (czy tam serial, zasada taka sama) warunek jest spełniony, gdy w buforze czeka do odczytania BAJT, jeden, no przynajmniej jeden.
Poza tym ile trwa taki blok programu, to są co najwyżej us. wysłanie/odbiór jednego bitu to 1/9600, więc program może 1000x zajrzeć tu i nic nie widzieć, choć transmisja trwa w najlepsze, bit po bicie, bajt za bajtem, a Ty sobie wszedłeś, odebrałeś ten jeden gotowy bajt i go dawno wysłałeś dalej, nie czekając na resztę.
Nawet jeśli sobie ustawisz to 115200, co dla soft serialu nie jest raczej dobrym pomysłem, to i tak będziesz miał kilkanaście pustych odczytów między bajtami, a jak program się rozrośnie to z softserialem nie zdążysz i się to posypie.
Transmisję można zrealizować wysyłając NAPIS, wtedy odczytujesz ciąg bajtów/liter, aż odczytasz cały napis o czym świadczy znak '\n', potem z niego konwertujesz na floata.
Zaraz obok były posty gdy kolega tu na forum walczył z floatami z falownika solarnego. On z kolei odbierał napisy z przecinkami, przecinek sobie zamieniał na kropki i konwertował gotową funkcją na floata. Skorzytaj.
Więc na początek napis, a jak bardzo chcesz te floaty, co ma sens, transmisja napisów to dużo więcej bajtów dla przesłania tej samej informacji, to musisz trochę dłużej powalczyć.
Nie robiłem tego, ale jak bym miał to wymyślić to czas jest tu kluczowy.
Na początek upewnij się że wysyłasz 4 bajty, tyle ma float, 4 bajty musisz też odebrać. Jak wysłać 4 bajty z floata writem, np. można znaleźć w Internetach by zrobić unie floata i tablicy 4 bajtów. Można zrobić wskaźnik na byte, wpisać mu wartość adresu zmiennej float, potem wysłać na serial write *byte, *(byte+1), +2 i +3. Jak z literkami one przylatują co jakiś czas. Trzeba wyznaczyć sobie jakiś okres czasu, gdzie nic nie leci, a jak przyleci, to wiesz, że to jest pierwszy bajt. Ale jak sprawdzić, czy odebrany ciąg bajtów ma jakiś sens bez CRC, przy napisie masz chociaż znak końca linii.
Reset pomiaru czasu i czekanie na kolejny bajt, jak nie przyleci w czasie spodziewanym dla prędkości transmisji to masz problem do obsłużenia. Jak przyleci 5 bajtów to kolejny, problem.
W sumie to możesz być zajęty innymi rzeczami, więc pomiar czasu jest średnim pomysłem na dłuższą drogę, biblioteka w tle może napełnić bufor programowy kilkoma bajtami, gdy Ty będziesz migał ledem.
Pomysł zadziała w takim programie jak pokazujesz, ale generalnie bez sensu.
No to oznaczenie początku ramki, wysyłasz w pierwszych bajtach napis "kopytko". Jak odbierzesz taki to wiesz, że to Twoja ramka, potem 4 bajty floata i 2 CRC dla kontroli, wszystko upchane w strukturę.
Nie ma sensu się z tym bawić na tym etapie, różnica między tekstem, a danymi binarnymi nie ma znaczenia przy przesyłaniu do kilkudziesięciu znaków.
Na razie nie ma sensu tracić czasu na napis "kopytko".
W zwykłej bibliotece wystarczy napisać sensors.setWaitForConversion(0); to jest ten tryb asynchroniczny wspomniany powyżej, tylko potem trzeba samemu pilnować kiedy zlecasz pomiar i kiedy go odczytujesz. Ale ponieważ zarządzanie czasem i mierzenie jego upływu to podstawowa umiejętność niezbędna do napisania jakiejkolwiek użytecznej aplikacji, to nie jest to problem, czy nadmiarowa praca, to i tak trzeba ogarnąć.
Wtedy masz to samo co w tej nonBlockingDallas, ona też jest blocking, bo nie da się inaczej, zmiany bitów są za szybkie by to miało sens, jak nie zablokuje na te 15ms loop to zablokuje przerwaniami wszystko. Znaczy da się inaczej, jak jest wolny UART to nim można przełączać się między dwoma prędkościami i nadawać bity 1-WIRE jako bajty UART. Wtedy zestaw danych do wysłania trafia do bufora i uC jest zajmowany na us by uzupełnić bufor kolejnym bajtem. Na pewno jest biblioteka w C ogólnie dostępna, ale w Arduino na razie nie widziałem.
Zacznij od napisu.
Masz przykład tu na forum, poszukaj Serial ewent. Zresztą, masz tu: https://forum.arduinopolska.pl/watek-uar...ino?page=2
Przejrzyj jak to wygląda, generalnie w punkcie RS485.available() (czy tam serial, zasada taka sama) warunek jest spełniony, gdy w buforze czeka do odczytania BAJT, jeden, no przynajmniej jeden.
Poza tym ile trwa taki blok programu, to są co najwyżej us. wysłanie/odbiór jednego bitu to 1/9600, więc program może 1000x zajrzeć tu i nic nie widzieć, choć transmisja trwa w najlepsze, bit po bicie, bajt za bajtem, a Ty sobie wszedłeś, odebrałeś ten jeden gotowy bajt i go dawno wysłałeś dalej, nie czekając na resztę.
Nawet jeśli sobie ustawisz to 115200, co dla soft serialu nie jest raczej dobrym pomysłem, to i tak będziesz miał kilkanaście pustych odczytów między bajtami, a jak program się rozrośnie to z softserialem nie zdążysz i się to posypie.
Transmisję można zrealizować wysyłając NAPIS, wtedy odczytujesz ciąg bajtów/liter, aż odczytasz cały napis o czym świadczy znak '\n', potem z niego konwertujesz na floata.
Zaraz obok były posty gdy kolega tu na forum walczył z floatami z falownika solarnego. On z kolei odbierał napisy z przecinkami, przecinek sobie zamieniał na kropki i konwertował gotową funkcją na floata. Skorzytaj.
Więc na początek napis, a jak bardzo chcesz te floaty, co ma sens, transmisja napisów to dużo więcej bajtów dla przesłania tej samej informacji, to musisz trochę dłużej powalczyć.
Nie robiłem tego, ale jak bym miał to wymyślić to czas jest tu kluczowy.
Na początek upewnij się że wysyłasz 4 bajty, tyle ma float, 4 bajty musisz też odebrać. Jak wysłać 4 bajty z floata writem, np. można znaleźć w Internetach by zrobić unie floata i tablicy 4 bajtów. Można zrobić wskaźnik na byte, wpisać mu wartość adresu zmiennej float, potem wysłać na serial write *byte, *(byte+1), +2 i +3. Jak z literkami one przylatują co jakiś czas. Trzeba wyznaczyć sobie jakiś okres czasu, gdzie nic nie leci, a jak przyleci, to wiesz, że to jest pierwszy bajt. Ale jak sprawdzić, czy odebrany ciąg bajtów ma jakiś sens bez CRC, przy napisie masz chociaż znak końca linii.
Reset pomiaru czasu i czekanie na kolejny bajt, jak nie przyleci w czasie spodziewanym dla prędkości transmisji to masz problem do obsłużenia. Jak przyleci 5 bajtów to kolejny, problem.
W sumie to możesz być zajęty innymi rzeczami, więc pomiar czasu jest średnim pomysłem na dłuższą drogę, biblioteka w tle może napełnić bufor programowy kilkoma bajtami, gdy Ty będziesz migał ledem.
Pomysł zadziała w takim programie jak pokazujesz, ale generalnie bez sensu.
No to oznaczenie początku ramki, wysyłasz w pierwszych bajtach napis "kopytko". Jak odbierzesz taki to wiesz, że to Twoja ramka, potem 4 bajty floata i 2 CRC dla kontroli, wszystko upchane w strukturę.
Nie ma sensu się z tym bawić na tym etapie, różnica między tekstem, a danymi binarnymi nie ma znaczenia przy przesyłaniu do kilkudziesięciu znaków.
Na razie nie ma sensu tracić czasu na napis "kopytko".
Miło być decenianym https://buycoffee.to/kaczakat