STM32F4 - USART, nieprawidłowe zakończenie transmisji stringu

Czołem,

Mam problem z przesyłem danych USARTEM. Mam taką o to funkcję:


Jeśli wyślę dwa stringi, z których drugi jest krótszy od pierwszego to na koniec drugiej transmisji dodawane są końcowe znaki pierwszej transmisji:


Otrzymuję:
tekst123
TEKST123

Jeśli zastosuję preinkrementację wskaźnika to obetnie mi pierwszy znak ze stringa. Nie wiem jak to rozwiązać

Zasadniczo nie jest to możliwe, tzn. funkcja wysyłająca wygląda dobrze, problem jest gdzieś indziej.
Masz dokładnie taki program, jak pokazałeś?
Jak odbierasz i wyświetlasz?

szelus napisał:

Zasadniczo nie jest to możliwe, tzn. funkcja wysyłająca wygląda dobrze, problem jest gdzieś indziej.
Masz dokładnie taki program, jak pokazałeś?
Jak odbierasz i wyświetlasz?

Rzeczywiście, problem był w programie odczytującym dane:


Dziękuję za pomoc.

To dalej nie jest dobry kod. Co, wg Ciebie, sprawdza poniższy warunek?

Cytat:

Kod: text

Zaloguj się, aby zobaczyć kod

Zamiast zerować bufor, zapewne wystaczy poprawnie sprawdzać długość.
Zwracając message przez wartość kopiujesz ją jeszcze raz.

Masz racje, wystarczy tak:



A co do wartości zwracanej, to próbuję wymyślić jakiś powód dla którego nie chcę zwracać wskaźnika
Ale wygląda na to, że wskaźnik będzie odpowiedni.

Wskaźnik możesz zwracać, o ile zaalokujesz message przez new. Ale to kłopot, bo potem trzeba pamiętać o zwolnieniu. No chyba, że shared_ptr (C++11).
Najprościej jest przekazać przez referencję jako argument zmienną, do której ma być zwrócona wiadomość:

W C++ można spokojnie zwracać zmienne przez wartosć, ponieważ wykorzystane zostanie "return value optimization". Ta optymalizacja jest wręcz obowiązkowa w C++11, w którym do tego celu zostanie użyte "move semantics". Zwracanie przez wartość to często najbardziej optymalna opcja jaką można zastosować!

A nawet jeśli to zwracanie stringa wywoła alokację, to co z tego? Komuś na PC skończy się RAM? U siebie mam w tym momencie 11GB wolnej pamięci - czy to jakiś problem jakbym sobie alokował krótkie stringi bez przesadnej kombinacji? Nie mówiąc już nawet o tym, że klasa std::string często posiada coś takiego jak "small string optimization", czyli krótkie łańcuchy nie są alokowane dynamicznie tylko przechowywane "wewnątrz" obiektu.

Tak więc naprawdę nie ma co kombinować - C++ jest skomplikowanym językiem, pewne nawyki znane z C są w nim często błędne lub przynajmniej zupełnie niepotrzebne.

Referencja jest chyba najlepszym sposobem, gdyż w innym miejscu (i oddzielnym wątku) odczytuję dane:



Jeszcze raz dziękuję.

Hyde911 napisał:

Referencja jest chyba najlepszym sposobem, gdyż w innym miejscu (i oddzielnym wątku) odczytuję dane:

Nie jest - jak włączysz C++11 i zwrócisz "przez wartość" to zostanie wykorzystany operator "move assignment" i nie będzie żadnej alokacji. Przy starszych standardach języka może być różnie - być może dokładnie tak samo ("return value optimization" zostało wprowadzone znacznie wcześniej niż C++11), ale na pewno zwracanie przez wartość nie będzie problemem w Twoim programie. Do tego taki sposób jest niezawodny, a to duża zaleta.

Freddie, ja sam w błąd wprowadzam, nie ma powodu do korzystania z liczby mnogiej.

Przyznaję, że za C++11 trochę nie nadążam, mimo, że to już trochę czasu obowiązuje - z wiekiem ten czas się jakoś tak dramatycznie kurczy. Jak to ktoś, gdzieś określił, "jak chińska koszulka w praniu".

Rzeczywiście, nie ma co kombinować, nawet, jeżeli to nie jest na PC-cie i nie ma paru giga RAMu. Mój błąd.

Freddie Chopin napisał:

ale na pewno zwracanie przez wartość nie będzie problemem w Twoim programie. Do tego taki sposób jest niezawodny, a to duża zaleta.

Zwracanie przez referencję też jest niezawodne, ale na pewno mniej czytelne. Stąd, domyślam się, takie a nie inne zmiany w C++11.

szelus napisał:

Freddie, ja sam w błąd wprowadzam, nie ma powodu do korzystania z liczby mnogiej.

Sorry, nie wiem czemu myślałem że w temacie wypowiadał się jeszcze jeden user na samym początku - nie sprawdziłem, mój błąd (;

szelus napisał:

Stąd, domyślam się, takie a nie inne zmiany w C++11.

Ponownie warto podkreślić, że RVO nie jest cechą tylko C++11 - wg wiki cecha ta (popularniejszą nazwą jest jednak "copy elision") została umieszczona już w standardzie C++03.

https://en.wikipedia.org/wiki/Copy_elision