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



Teraz jest 13 gru 2024, o 16:57


Strefa czasowa: UTC + 1





Utwórz nowy wątek Odpowiedz w wątku  [ Posty: 10 ] 
Autor Wiadomość
PostNapisane: 3 lis 2012, o 15:49 
Offline
Użytkownik

Dołączył(a): 26 lut 2012
Posty: 82
Pomógł: 0

Witam,

Napisałem sobie kawałek kodu odpowiedzialny za wykonanie zadanej ilości kroków w prawo i lewo który nie pozwala przekroczyć zakresu pełnego obrotu silnika krokowego.
Jeśli silnik posiada 100 kroków do pełnego obrotu to zadanie mu wartości np 150 kroków w prawo spowoduje obcięcie 50 nadmiarowych, analogicznie w drugą stronę.
Natomiast przy podaniu np 60 kroków w prawo obrót w lewo będzie możliwy jedynie o <60.
Ogólnie chodzi o to by silnik pracował w zakresie 0-360 stopni w dwie strony.
Początkowo napisałem sobie kod w C który uruchomiony w konsoli idealnie spełnia swoje zadanie:
Składnia: [ Pobierz ] [ Ukryj ]
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.


Przy przepisywaniu na avr pierwszym problemem był za mały zakres int8_t więc postanowiłem użyć int16_t co niestety nie zniwelowało mojego problemu który jest następujący:
Jeśli zadam kroki_lewo < 100 a następnie kroki_prawo < kroki_lewo wszystko jest w porządku.
Jeśli zadam kroki_lewo > 100 to wykona się 100 kroków i układ się zawiesi.
Jeśli zadam kroki_lewo < 100 a następnie kroki_prawo > kroki_lewo układ się zawiesi.
Kod dla avr (Tutaj pierwszy obrót jest możliwy najpierw w lewo, odwrotnie było w powyższym kodzie):
Składnia: [ Pobierz ] [ Ukryj ]
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.

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

Są globalne



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 4 lis 2012, o 13:13 
Offline
Uzytkownik zasłużony dla forum.atnel.pl
Avatar użytkownika

Dołączył(a): 16 lip 2012
Posty: 2088
Lokalizacja: Leżajsk / Kraków
Pomógł: 411

Na moje oko w tym kodzie wszystko gra (oprócz tego, że jak zadasz np.210 to wykona się 200, a nie 100 kroków). Może problem masz gdzieś dalej, a określenie "układ się zawiesi" jest zbyt ogólne.

_________________
Dragonus Cracovus: Biomagia



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 4 lis 2012, o 19:04 
Offline
Użytkownik

Dołączył(a): 26 lut 2012
Posty: 82
Pomógł: 0

Docelowo na stronie www będzie suwak w js więc zmienna nie przyjmie wartości >100 dlatego nie skupiałem się na liczbach większych od 199.
Co do zawieszenia układu to uruchomiłem sobie timer na przerwaniu który co sekundę wysyła przez rs232 do terminala kropkę. Przy zawieszeniu układu pingi przestają lecieć, strona www się nie wyświetla a kropki nadal się pojawiają więc mniemam, że coś dzieje się z samym ATB-ETHERNET.
Link do projektu na githubie:
https://github.com/mlekorlz/serwery_tcp_ip_atmega32/tree/working_on/20_ETH_serwer_www_test_step%2Blcd



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 4 lis 2012, o 19:19 
Offline
Moderator
Avatar użytkownika

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

No tak, problem z działaniem programu i co ? ;) .... oczywiście od razu winny ATB-ETHERNET albo no w zasadzie sam scalak ENC28J60. Eeeeeeh ta firma Microchip - takiego bubla wypuściła :( .... ciągle się zawiesza :( ....

Bardzo przepraszam, za troszkę sarkastyczny ton tej wypowiedzi - ale na prawdę, to właśnie "z takim podejściem do programowania" (wyszukiwanie wszędzie winy - nawet w sprzęcie, tylko nie w kodzie, który piszę) wciąż walczę i tłumaczę, że tak nie można - ale widzę, że jak grochem o ścianę.

_________________
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: 4 lis 2012, o 20:19 
Offline
Użytkownik

Dołączył(a): 26 lut 2012
Posty: 82
Pomógł: 0

Panie Mirku nie winię układu tylko w odpowiedzi na pierwszy post pod moim piszę co zauważyłem.
Co do kodu to również nie twierdzę, że jest w 100% w porządku, napisałem jedynie, że konsolowa wersja obliczania ilości kroków spisuje się rewelacyjnie a po przepisaniu jej na AVR pojawiają się problemy których nie potrafię rozgryźć - stąd mój post.
Takie uroki programowania na Uc, że prócz złego kodu, problem może tkwić w połączeniach, uszkodzonych układach itp stąd, gdy kompilator nie wyświetla błędów człowiek zaczyna się zastanawiać czy aby na pewno sprzęt jest sprawny:)
Ale wracając do tematu, dzisiaj robiłem sobie testy i zauważyłem, że owo zawieszenie to właściwie loteria, kod z terminala:
Kod:
RS232 OK!
ox rec, state: 150,150
ox oversteps: 50
ox todo: 100
ox rec, state: 50,150
ox oversteps: 50
ox todo: 0
ox rec, state: 50,150
ox oversteps: 50
ox todo: 0
oy rec: 150
oy state: -50
oy oversteps: 50
oy todo: 100
oy rec: 50
oy state: -50
oy oversteps: 50
oy todo: 0
ox rec, state: 50,50
ox todo: 50
oy rec: 60
oy state: -10
oy oversteps: 10
oy todo: 50
oy rec: 70
oy state: -70
oy oversteps: 70
oy todo: 0
ox rec, state: 99,99
ox todo: 99

ox - obroty w lewo
oy - obroty w prawo
rec - kroki otrzymane z URLa
state - aktualny stan kroków
oversteps - kroki nadmiarowe
todo - kroki do zrobienia

Jak widać z powyższego dzisiaj silnik kręcił się w obydwie strony nie przekraczając zakresu - czyli wszystko idealnie, jednak po ostatniej linijce układ przestał działać, nie wykonując ostatnich kroków. Kolejne próby przynosiły różny rezultat, czasami udało się zrobić kilkanaście ruchów, czasami kilka.
Z racji tego, że kod znam już praktycznie na pamięć nie umiem zauważyć błędów, piszę na forum bo wiadomo, że "co dwie głowy to nie jedna" i trzeźwemu spojrzeniu łatwiej coś zauważyć.



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 4 lis 2012, o 20:59 
Offline
Moderator
Avatar użytkownika

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

mlekorlz napisał(a):
Takie uroki programowania na Uc, że prócz złego kodu, problem może tkwić w połączeniach, uszkodzonych układach itp stąd, gdy kompilator nie wyświetla błędów człowiek zaczyna się zastanawiać czy aby na pewno sprzęt jest sprawny:).


Widzisz ...... ja w takich przypadkach zastanawiam się, czy aby na pewno gdzieś błędu nie popełniłem. Zastanawiam się co przeoczyłem - bo przecież nie może być winny układ scalony, producent i na pewno zaraz nic mi się nie przepaliło.

Poza tym w kodzie źródłowym może być milion razy więcej przyczyn że coś nie działa niż w samym sprzęcie.

Ty się skupiasz tu nad silnikiem i wysyłaniem kropek na UART .... i to cię gubi niestety, bo uznałeś że cała reszta, czyli obsługa serwera http jest OK. A to tam pewnie leży pies pogrzebany.

_________________
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: 4 lis 2012, o 21:17 
Offline
Użytkownik

Dołączył(a): 26 lut 2012
Posty: 82
Pomógł: 0

Na kodzie również się skupiam, przestudiowałem go setki razy, tyle samo razy poprawiałem coś, co moim zdaniem mogło być nie tak.
Czy mój tok myślenia, że skoro kropki nadal się wysyłają to znaczy, że sam moduł sieciowy się zawiesił jest błędny?
Kod serwera pochodzi z książki więc uznałem, że był on przez Pana przetestowany, zcztywanie z URLa pochodzi z tuxgraphics, zczytane zmienne są prawidłowe. Podłączanie innych układów do niego nie powodowało problemów. Jak zatem mogę jeszcze sprawdzić gdzie leży problem?



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 4 lis 2012, o 22:03 
Offline
Moderator
Avatar użytkownika

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

mlekorlz napisał(a):
Kod serwera pochodzi z książki więc uznałem, że był on przez Pana przetestowany,

Czy ty widziałeś kod serwera z książki ? czy ten serwer coś robi poza statycznym wyświetleniem czegoś ? A i tak może się zawiesić z byle powodu gdy naraz do serwera dotrze zbyt wiele zapytań z zewnątrz np z różnych adresów IP.

mlekorlz napisał(a):
zcztywanie z URLa pochodzi z tuxgraphics, zczytane zmienne są prawidłowe. Podłączanie innych układów do niego nie powodowało problemów.

To widziałem po twoim kodzie. Jeśli myślisz, że pisanie bardziej zaawansowanych aplikacji z użyciem stosu TCP i mikrokontrolera 8-bit a SZCZEGÓLNIE w postaci serwera HTTP to poezja - to się GRUBO mylisz niestety, to jest piekło :( .... więc zaczynając pisać to "welcome to hell" ;) ....

mlekorlz napisał(a):
Jak zatem mogę jeszcze sprawdzić gdzie leży problem?


Przede wszystkim to od BARDZO ale to BARDZO dokładnego przestudiowania całej strony tuxgraphics i o tym jak autorzy sami piszą od początku o swoim stosie TCP, o kłopotach, problemach itp - np tych związanych także z ENC gdy w pierwotnych ich aplikacjach był zasilany wraz z prockiem z 3,3V i procek był taktowany 8MHz. Dlaczego poszli w stronę taktowania 12,5MHz z ECN ... ale ok ten temat już cię nie dotyczy bo masz ATB-ETHERNET i możesz procka zasilać +5V dzięki czemu możesz go taktować np 20MHz. Do poprawnej pracy z ENC procek powinien być taktowany minimum 16MHz a najlepiej 20MHz .... inaczej mogą być zwiechy i konieczny przede wszystkim Watchdog. Ciekawe jakie ty masz taktowanie?

Kolejna sprawa - pisanie aplikacji z użyciem stosu TCP to przede wszystkim próba dogłębniejszego poznania stosu i jego zasad działania. A nie że się tam weźmie jakiś stos i nagle wszystko super.

Ja już nawet na tym forum, bo nie pamiętam czy w książce nawet tego nie napisałem. Że generalnie odpalanie serwera HTTP na procesorze 8-bitowym to POMYŁKA GENETYCZNA :(

czy to oznacza, że ethernet i 8-bitowce to tylko "pic na wodę fotomontaż" ? NIE

ale dlatego trzeba zwrócić na inne sposoby pracy i wykorzystania ethernetu. 8-bitowiec nie podoła już nawet kilku żądaniom konkurencyjnym http, tu trzeba i to dobrego ARM'a !

ale za to 8-bitowiec sobie dobrze poradzi np z UDP, albo ......

albo z klientem www (web client) .... a tak się składa, że fajny stosik z tuxgraphics daje takie możliwości. Chodzi o to aby nie narażać procka na konkurecyjne zapytania w trybie TCP (HTTP) bo to masakra. Podczas gdy z krótkimi i szybkimi zapytaniami ale niewielkimi ramkami UDP dosyć dobrze sobie poradzi

dlatego można pisać serwery http dla 8-bitowców ale to wymaga już na prawdę większego doświadczenia w TCP i programowaniu wielowątkowym, żeby można było zrozumieć na jakich etapach dochodzi do zwiechy w takim stosie. Nawet z debugerem sprzętowym ciężko byłoby to wyłapywać - a gdy jeszcze weźmiemy kłopoty ENC, który oczekuje bardzo szybkiej komunikacji po SPI z prockiem, a tu np AVR próbuje z nim gadać z poziomu prędkości ŚLIMAKA - to czasem będzie miał focha i się zawiesi - to akurat normalka.

to wszystko w takim telegraficznym skrócie - więc zobacz ile rzeczy tu jest ważnych poza twoimi kropkami wysyłanymi na uart i pozostałymi rzeczami w programie ..... a zresztą ....

zapytania http wymagają prawie 100% mocy procka - a ty przecież "kradniesz" sporo procent mocy na obsługę silników i jeszcze innych pętli w swoim programie głównym, z których pewnie część jest bardzo mało optymalnych. A jeszcze jak gdzieś wstawisz byle kociego _delay'a - to KAPLICA z ZONKIEM razem wzięta :(

teraz jaśniej ?

_________________
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: 5 lis 2012, o 07:14 
Offline
Uzytkownik zasłużony dla forum.atnel.pl
Avatar użytkownika

Dołączył(a): 16 lip 2012
Posty: 2088
Lokalizacja: Leżajsk / Kraków
Pomógł: 411

mlekorlz napisał(a):
Jeśli zadam kroki_lewo < 100 a następnie kroki_prawo < kroki_lewo wszystko jest w porządku.

mirekk36 napisał(a):
zapytania http wymagają prawie 100% mocy procka - a ty przecież "kradniesz" sporo procent mocy na obsługę silników i jeszcze innych pętli w swoim programie głównym, z których pewnie część jest bardzo mało optymalnych.

Myślę, że trochę się rozjaśniło. Operacje dzielenia modulo liczb 16-bitowych zajmują zbyt dużo czasu. Dlaczego przesyłasz o ile przestawić silnik? Może lepiej wysyłać na jaką pozycje silnik ma się ustawić. Wtedy zmienne mogły by być 8-bitowe, a dzielenia by nie było:

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

Podglądnij kod w asemblerze jak się zmienił. Obrót w lewo i prawo korzysta tylko z parametru "ox".

PS. Zmienna cmd powinna być ze znakiem skoro masz warunek cmd==-1

_________________
Dragonus Cracovus: Biomagia



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 20 lis 2012, o 19:48 
Offline
Użytkownik

Dołączył(a): 26 lut 2012
Posty: 82
Pomógł: 0

Zamontowałem kwarc 20Mhz, zmienną cmd zmieniłem na int8_t, dołożyłem suwak w HTML5 + Js i wszystko hula aż miło:)
Suwakiem ustawiamy liczbę kroków dla silnika krokowego, klikamy button i obserwujemy jak machina rusza:) Suwak działa w obydwie strony, w planach mam dodanie drugiego steppera.
Co ciekawe przy kwarcu 16Mhz gubiła się komunikacja z SPI a przy obecnym mam dodatkowo uruchomiony LCD i UART i układ chodzi od 3 dni bez problemu;)
Tak więc dla wszystkich którzy poddają się przy projektach - czasami trzeba posiedzieć i kilka tygodni (miesięcy) ale w końcu się udaje:)
Obrazek



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: 10 ] 

Strefa czasowa: UTC + 1


Kto przegląda forum

Użytkownicy przeglądający ten dział: Brak zidentyfikowanych użytkowników i 0 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:  
Sitemap
Technologię dostarcza phpBB® Forum Software © phpBB Group phpBB3.PL
phpBB SEO