Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

ATMEGA32 i DELPHI 7 - Konwersja String na Float

kamilpazdan 03 Mar 2015 19:26 834 17
  • #1 03 Mar 2015 19:26
    kamilpazdan
    Poziom 12  

    Witam,
    Dokonuję pomiaru dwóch temperatur przy użyciu DS18B20. Dane przesyłam po RS232 (MAX232) - docelowo chciałbym wysyłać cztery parametry na komputer.

    Podczas próby konwersji ciągu string z RS232 na zmienną typu "integer" lub "float", otrzymuję komunikat:
    EConvertError: is not valid integer value.

    Sprawa wygląda tak: próbowałem już konwersji zarówno na "integer" jak i "float"; próbowałem z ATMEGA32 wysyłać dane zarówno z znakami jak i same liczby - brak sukcesu.

    Szukałem na różnych forach, literaturze - wygląda to bardzo prosto - ale tak nie jest w moim przypadku.

    Nie jestem fachowcem w tej dziedzinie ale po prostu nie wiem już gdzie szukać - dlatego prośba o pomoc.

    Kod DELPHI:

    Kod: delphi
    Zaloguj się, aby zobaczyć kod


    Kod BASCOM:

    Kod: fortran
    Zaloguj się, aby zobaczyć kod

    0 17
  • #5 03 Mar 2015 20:54
    kamilpazdan
    Poziom 12  

    Separator wstawiony. Załączam plik (3) ze screen'em gdzie zatrzymuję się komponent CPort.

    Plik (4) - spróbowałem usunąć linię, która wyłącza zawijanie wiersza w memo:
    Str:=Memo.Lines[Memo.Lines.Count-2+Ord(P=Length(Str))];

    Zamieniłem na próbę:
    Memo.Lines.Add(Str);


    Kod: delphi
    Zaloguj się, aby zobaczyć kod

    0
  • #6 04 Mar 2015 20:01
    Dżyszla
    Poziom 42  

    Tym razem masz enter w ciągu tekstowym. Natomiast kod pokazany jest niezgodny z tym z (4) - tam do konwersji podstawiłeś str - po co, skro w T1 jest właściwa wartość?

    Proponuję inaczej - utwórz pomocniczą zmienną jako pole klasy formatki (czyli do definicji dopisz sobie w części private zmienną typu string).

    Jak rozumiem, odebranie Entera ma jest sygnałem, że kompletna dana została przesłana. Zatem odbierając wykonaj kod:

    Kod: Delphi
    Zaloguj się, aby zobaczyć kod
    (piszę z głowy, więc sorry, jeśli jakieś składniowe błędy popełniłem)
    Pamiętaj, że cała ta procedura zakłada, że na raz może być przesłana dana zawierająca do 1 entera, a sam enter składa się wyłącznie ze znaku #13.

    0
  • #7 04 Mar 2015 20:31
    kamilpazdan
    Poziom 12  

    Dziękuj kolego Dżyszla, że w ogóle pomagasz takiemu laikowi jak ja ;)

    Co do Entera może to być inny znak, który wykryję podczas odbierania paczki ale może być.

    Przerobiłem program - teraz jeszcze lepszy, ciekawszy błąd który dla laika mówi - wyrzuć komputer za okno... ;D

    Program się kompiluje ale wywala błąd po uruchomieniu COM.

    Kod: delphi
    Zaloguj się, aby zobaczyć kod


    Zastanawiam się czy problem nie wynika z samej biblioteki. Używam wersji cport 3.10. A jest dostępna 4.11.

    0
  • #9 05 Mar 2015 20:40
    kamilpazdan
    Poziom 12  

    Nie rozumiem. Z jakim kodem mam porównać ?

    Dodano po 2 [minuty]:

    kamilpazdan napisał:
    Nie rozumiem. Z jakim kodem mam porównać ?

    Ok. Już widzę. Dam znać jak sprawdzę.

    Dodano po 11 [minuty]:

    Bez konwersji do integer program działa bardzo płynnie - nawet memo mi się zwija 0 dziękuje. Jednakże po dołożeniu konwersji "test" - niby zmierzona temp. np. 25.7 jest nie poprawną wartością dla typu integer...

    0
  • #10 05 Mar 2015 20:47
    kamilpazdan
    Poziom 12  

    Ok. Dokonałem konwersji na zmienną typu float - program działa.

    Tylko teraz nie wiem jak sprawdzić czy konwersja się powiodła.
    Jak mogę ją wyświetlić ? np. jako = label.caption... ?

    0
  • #11 05 Mar 2015 22:43
    -psiak-
    Poziom 32  

    Kod: delphi
    Zaloguj się, aby zobaczyć kod

    0
  • #12 06 Mar 2015 11:36
    kamilpazdan
    Poziom 12  

    Jeszcze nie sprawdziłem tego rozwiązania.

    Ale wracając do błędu po otwarciu portu COM i po wczorajszych medytacjach - już wiem czym on jest spowodowany.

    Przy odebraniu pierwszej z linii zaraz po otwarciu COM zdarza się ( nie zawsze ) że ATMEGA wyślę kilka "krzaków"...,np. *&$% i wtedy debugger wurzuca błąd konwersji...

    Dziś dam znać kolego -psiak- jak działa Twoja propzycja.

    Serdecznie dziękuje za dotychczasową pomoc. Tematu narazie nie zamykam - może napotkam jeszcze problemy.

    0
  • #13 06 Mar 2015 13:46
    arnoldziq
    Moderator Programowanie

    kamilpazdan napisał:
    Przy odebraniu pierwszej z linii zaraz po otwarciu COM zdarza się ( nie zawsze ) że ATMEGA wyślę kilka "krzaków"...,np. *&$% i wtedy debugger wurzuca błąd konwersji...

    Przy tych ustawieniach ATMega-i (1MHz i 1200bps) masz jakie 0.2% błędów w wysyłanych informacjach.
    Może to nie jest dużo, ale z upływem czasu liczba błędów będzie rosła.
    Zmień ustawienia zegara i szybkości transmisji.

    0
  • #14 06 Mar 2015 20:25
    kamilpazdan
    Poziom 12  

    Jakaś konkretna propozycja co do ustawień ?

    0
  • #16 06 Mar 2015 21:11
    Eagle
    Poziom 23  

    Zaciekawiło mnie stwierdzenie :

    arnoldziq napisał:
    Może to nie jest dużo, ale z upływem czasu liczba błędów będzie rosła.

    Co miałeś na myśli, skoro z każdym bitem startu odbiornik się synchronizuje ?

    0
  • #17 06 Mar 2015 21:38
    arnoldziq
    Moderator Programowanie

    Eagle napisał:
    Co miałeś na myśli, skoro z każdym bitem startu odbiornik się synchronizuje ?

    Miałem na myśli to, że skoro raz na 500 bajtów jeden będzie wadliwy, to z czasem ilość tych błędów będzie znacząca, pomimo niewinnie wyglądającej wartości 0.2%.

    0
  • #18 06 Mar 2015 22:19
    Eagle
    Poziom 23  

    Przy 0,2% różnicy w prędkości nie może powstać błąd ani po 1B ani po 1GB, wynika to z tego, że skoro odbiornik synchronizuje się z bitem startu to każdy wysyłany bajt jest traktowany jako nowy i ta różnica nie będzie się w tym wypadku się kumulować. Wynika to z zasady na jakiej działa transmisja szeregowa. W dwóch słowach najprostszy odbiornik działa tak: wraz z opadającym zboczem bitu startu, uruchamiany jest timer z połową trwania bitu. Następnie odmierzany jest czas trwania całego bitu, co powoduje trafienie dokładnie w połowę zerowego bitu +-błąd zegara nadajnika + +-błąd zegara odbiornika. Z każdym kolejnym bitem błędy się sumują lub znoszą, aż do bitu stopu. Wraz z nowym bitem startu, odbiornik ponownie się zsynchronizuje. Dlatego zakładając najbardziej niekorzystny przypadek tj. błąd zegara odbiornika i nadajnika, jest co do znaku taki sam, odpowiednio duży jest to błąd oraz pakiet jest maksymalnie długi np z bitem parzystości, można wyliczyć jaki jest graniczny błąd przy którym odczytanie ostatniego bitu, może być błędne.

    Natomiast, jeśli jeden na 500 bajtów jest nieprawidłowy to są dwie możliwości : jedna to różnica w prędkościach nadawania/odbierania dużo powyżej 0,2% lub typowe zakłócenia, które będą dawać błędy nawet przy idealnych zegarach.

    0