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:


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):

Zmienne:

Są globalne

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

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

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 ]

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:

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ć.

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 ]

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?

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.


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" ....



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 ]

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:


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

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:)