Kanał - ATNEL tech-forum
Wszystkie działy
Najnowsze wątki

KURS HOME ASSISTANT

Chcesz zautomatyzować swój dom bez skomplikowanego kodowania?
Zastanawiasz się nad wyborem sprzętu, oprogramowania i aplikacji?
Od czego zacząć przygodę z HA? Co będzie najlepsze na start?

Nasz kurs Home Assistant nauczy Cię krok po kroku, jak łatwo zautomatyzować swój dom i oszczędzić na rachunkach za prąd i ogrzewanie. Bez chmur, bez zbędnych abonamentów. Twoja przygoda z Home Assistant zaczyna się tutaj!

↓↓↓

    Szanujemy Twoją prywatność. Możesz wypisać się w dowolnym momencie.




    Teraz jest 9 lip 2025, o 15:24


    Strefa czasowa: UTC + 1





    Utwórz nowy wątek Odpowiedz w wątku  [ Posty: 7 ] 
    Autor Wiadomość
    PostNapisane: 13 lut 2012, o 17:31 
    Offline
    Nowy

    Dołączył(a): 11 lut 2012
    Posty: 6
    Pomógł: 0

    Witam, stworzyłem prosty program sprawdzający transmisję USART podczas którego wysyłany był znak o kodzie 0x37 (czyli '7') jednak na komputerze w programie putty wyświetlany był znak o kodzie 0x64 (czyli 'd'). Co może być przyczyną zmian w transmitowanych danych? Spotkał się już ktoś może z czymś takim?

    Oto kod tego programu:


    Składnia: [ Pobierz ] [ Ukryj ] [ Zaznacz wszystko ]
    język c
    Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.



    Dodam jeszcze, że korzystałem z mikroprocesora ATmega664pa oraz próbowałem różnych wariantów przy inicjalizacji tej komunikacji(liczba bitów stopu, częstotliwość mikroprocesora, różne kody ASCII wysyłanego znaku) a także sprawdziłem wysyłane dane przy użyciu innego programu niż putty(tak więc problem tkwi z pewnością w programie mikroprocesora, a nie w ustawieniach programu monitorującego).

    Jestem wdzięczny za wszelką pomoc.



    Góra
     Zobacz profil  
    cytowanie selektywne  Cytuj  
    PostNapisane: 13 lut 2012, o 17:53 
    Offline
    Moderator
    Avatar użytkownika

    Dołączył(a): 03 paź 2011
    Posty: 27415
    Lokalizacja: Szczecin
    Pomógł: 1043

    Po pierwsze czy jesteś pewien, że procek ustawiony jest na 11,0592MHz ??? Tylko może pokaż jakiś zrzut ekranu w którym widać odczytane z procka Fusebity żeby to potwierdzić OK ?

    Po drugie czy masz na pewno tak samo ustawione parametry transmisji z programem terminala ?

    Bo testowy program tak na pierwszy rzut oka wygląda OK - zatem winę za taki stan rzeczy może ponosić właśnie któryś z wyżej wymienionych punktów.

    _________________
    zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]



    Góra
     Zobacz profil  
    cytowanie selektywne  Cytuj  
    PostNapisane: 13 lut 2012, o 19:41 
    Offline
    Nowy

    Dołączył(a): 11 lut 2012
    Posty: 6
    Pomógł: 0

    Najwyraźniej z powyższym wszystko w porządku, oto fotki:
    http://imageshack.us/g/189/fusebity.png/

    Przy okazji: zapomniałem wcześniej wspomnieć, że używam do tego przejściówki usb-rs232 (jeśli to istotne).



    Góra
     Zobacz profil  
    cytowanie selektywne  Cytuj  
    PostNapisane: 13 lut 2012, o 20:50 
    Offline
    Moderator
    Avatar użytkownika

    Dołączył(a): 03 paź 2011
    Posty: 27415
    Lokalizacja: Szczecin
    Pomógł: 1043

    Oczywiście obrazka z fusami pod wskazanym linkiem nie widać niestety.

    Kod sprawdziłem i jest napisany w taki sposób że na 100% powinien działać na ATmega644P(A)

    Nie mam pod ręką tego procka ale skompilowałem sobie twoje dzieło pod ATmega32 zmieniając oczywiście TYLKO nazwy rejestrów i bitów no i dodając jeszcze bit URSEL bo przy ATmega32 taki akurat jest.

    i jak myślisz działa ?

    Oczywiście, że działa i to bez mrugnięcia oka ;) wyświetlają się znaki 7 albo dowolne inne które wysyłam.

    Dlatego jeszcze raz ci podpowiem - patrz na punkty, które ci wyżej napisałem. Ja obstawiam:

    że na 99,999% po skompilowaniu na ATmega644P też by działał ale że nie mam go pod ręką i nie mogę sprawdzić skompilować to daję sobie ten 0,001% że może coś byłoby nie tak ;)

    Nadmienię, że także używam przejściówki USB/RS232 wbudowanej w zestaw uruchomieniowy ATB.

    _________________
    zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]



    Góra
     Zobacz profil  
    cytowanie selektywne  Cytuj  
    PostNapisane: 14 lut 2012, o 17:07 
    Offline
    Nowy

    Dołączył(a): 11 lut 2012
    Posty: 6
    Pomógł: 0

    Sprawdziłem jeszcze dziesiątki razy czy wszystko dobrze skonfigurowałem i cóż.. wygląda na to, że lepiej już nie potrafię. W ostateczności znalazłem pewną prawidłowość w tych różnicach(pomiędzy znakami w programie ustawionymi do transmisji, a znakami w terminalu). Otóż po przesunięciu bitowym o jedno miejsce w lewo i zamianie zer na jedynki w zapisie binarnym tego znaku zaczął on odpowiadać oczekiwanemu znakowi w kodzie ASCII.

    Oto jak ta modyfikacja wygląda w kodzie funkcji transmisji znaku:
    Kod:
    void USART_Transmit( unsigned char znak )
    {
       uint8_t _znak;
    znak=(znak<<1);    // kalibracja kodu  ASCII
    _znak=(znak^0xFF); // kalibracja kodu ASCII

    /* Wait for empty transmit buffer */
    while ( !( UCSR1A & (1<<UDRE1)) );
    /* Put data into buffer, sends the data */
    UDR1 = _znak;
    }


    Teraz wszystko wyświetlane jest już poprawnie, ale to dlaczego dane są transmitowane w tak dziwny, przekombinowany sposób dalej mnie nurtuje, więc jak ktoś zna odpowiedź chętnie posłucham. :)



    Góra
     Zobacz profil  
    cytowanie selektywne  Cytuj  
    PostNapisane: 14 lut 2012, o 17:31 
    Offline
    Moderator
    Avatar użytkownika

    Dołączył(a): 03 paź 2011
    Posty: 27415
    Lokalizacja: Szczecin
    Pomógł: 1043

    No tak ale tą drogą obchodzisz tylko problem okrężną drogą a nie go rozwiązujesz.

    Bo po takim efekcie to tym bardziej można być pewnym, że program bez żadnych przeróbek w procku jest dobry ;)

    Lepiej sprawdź sobie czy przypadkiem nie masz zanegowanej transmisji na liniach Tx i Rx w przejściówce USB/RS232 bo coś tak mi pachnie ;)

    _________________
    zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]



    Góra
     Zobacz profil  
    cytowanie selektywne  Cytuj  
    PostNapisane: 14 lut 2012, o 20:24 
    Offline
    Nowy

    Dołączył(a): 11 lut 2012
    Posty: 6
    Pomógł: 0

    Sprawdziłem właśnie przy pomocy diody tj. wysyłając na katodę sygnał z portu transmisji mikroprocesora(anoda diody do VCC) i przy wykorzystaniu niezmienionego kodu z początku tego tematu wysłałem znak 0xFF oraz 0x00 i tu obyło się bez niespodzianek -dioda świeciła wyraźnie jaśniej przy wysyłaniu 0x00. Wygląda więc faktycznie na to, że to przejściówka odwraca bity i przez to było te całe zamieszanie. Tak więc tajemnica rozwiana... dzięki za pomoc. :)



    Góra
     Zobacz profil  
    cytowanie selektywne  Cytuj  
    Wyświetl posty nie starsze niż:  Sortuj wg  
    Utwórz nowy wątek Odpowiedz w wątku  [ Posty: 7 ] 

    Strefa czasowa: UTC + 1


    Kto przegląda forum

    Użytkownicy przeglądający ten dział: Brak zidentyfikowanych użytkowników i 5 gości


    Nie możesz rozpoczynać nowych wątków
    Nie możesz odpowiadać w wątkach
    Nie możesz edytować swoich postów
    Nie możesz usuwać swoich postów
    Nie możesz dodawać załączników

    Szukaj:
    Skocz do:  
    cron
    Sitemap
    Technologię dostarcza phpBB® Forum Software © phpBB Group phpBB3.PL
    phpBB SEO