Witam !
Mam pewien problem i od kilku dni zastanawiam się nad rozwiązaniem, a mianowicie:
Odbieram sobie dane po UDP gdzieś tam z sieci na moim uC (enc i te sprawy), i generalnie wszystko działa(program oparty na tym od Mirka z płyty). W pewnym momencie trafił się problem, program nie zawsze potrafił odebrać ramkę i odpowiednio ją przerobić(uC gdzieś wisiał). Jeden kolega z forum zasugerował mi, że być może mam timeouta. Moje poszukiwania doprowadziły mnie do samego początku funkcji UDP event, przed która wystarczyło dać małego delay. Od tamtej pory kiedy ethernet miałem wpięty po kablu wszystko śmigało elegancko.
Poszedłem krok dalej i podłączyłem moj moduł ethernetowy do wifi ( ap klient) po odpowiedniej konfiguracji uC znowu odbierał dane, jednak znowu zdarzyło mi się od czasu do czasu zawiesić(w podobny sposób jak przedtem). Postanowiłem rozwiązać problem raz na zawsze za pomocą watchdoga jednak mam co do tego pewne wątpliwości..
Chciałbym, aby po wywołaniu watchdoga został wysyłany do komputera komunikat "wyślij te info raz jeszcze", co oczywiście można zrobić w przerwaniu. Jednak kolejnym warunkiem poprawnego działania takiego programu musiał by być POWRÓT programu do pętli głównej, i tu mam problem, jak to zrealizować ? myślałem nad jakimś asm ret, czy coś w tym stylu jednak nie wiem jak zachowa się program odbierając ret w przerwaniu. Spodziewam się że nic z tego nie będzie. Z drugiej strony mógłbym wywołać przerwanie(wysłać wiadomość) a następnie reset uC. Jednak ten uC jest podłączony z kilkoma innymi uC za pomocą rs232 czy też spi, i nie chcę by przez przypadek pojawiały się na tych liniach jakieś zakłócenia(przy resecie uC), gdyż mogło by to spowodować zapisanie do tablic w innych uC śmieci, na co nie mogę sobie pozwolić.
Macie może jakieś pomysły ? Każda pomoc mile widziana Oczywiście w razie potrzeby służę kawałkami kodu, jednak potrzebuję głównie jakiegoś nakierowania na odpowiednie tory

Niestety pomysły o jakimś kosmicznym powrocie z przerwania do pętli głównej to dalszy ciąg twojego "obchodzenia" problemu od tyłu zamiast jego rozwiązania. Tyle że już taki pomysł jest mega drakoński i przysporzy ci dopiero siwych włosów Tak się NIGDY nie robi - NIGDY dziwne powroty z przerwań do pętli głównej ....

toż bez wielkiego namyślania się można tak na szybko pomyśleć np o zapisaniu w EEPROMIE znacznika jakiegoś itp ... jeśli chodzi o przerwanie watchdoga, które ma uratować wiszący system ...

ale ja poleciłbym ci jednak szukać babola gdzie się dzieje to zawieszanie - bo narobisz się jak koń pod górę, nałatasz , nawrzucasz poprawek i zabezpieczeń do zabezpieczeń, które już wcześniej były trzykrotnie zabezpieczane a i tak przyjdą momenty gdy wszystko będzie już wisiało na włosku i w razie awarii - KLOMPS !

Tak debugowanie takich przypadków gdy mamy już np Ethernet to nie przelewki i nie to co debugowanie projektu z miganiem diodą LED..... niestety.

Ale patrząc na skalę projektu - że jak już ethernet i się coś zawiesza to człowiek podświadomie sobie myśli ... aha! pewnie gdzieś babol w bibliotekach tuxgraphicsa do którego sam nigdy nie dojdę więc co tam będę szukał - ... walnę to watchdogiem i będzie pozamiatane ... a tu proszę - teraz przydałoby się powtórzenie transmisji - potem jeszcze coś jeszcze coś ...

Stop! warto sobie pomyśleć - ja tak często robię w takich sytuacjach bo też przecież się z nimi spotykam. Niestety programowanie to w znacznej mierze szukanie naszych błędów. I o TYM warto pamiętać - bo jak się dobrze poszuka - czasem nawet spędzi się nad tym kilka dni a może miesięcy - ale jak się znajdzie BYKA to potem człowiek nie może uwierzyć że to było tak banalne, taki błąd prosty i to nie np w bibliotekach tuxgraphicsa tylko w moim własnym kodzie - bo mi gdzieś się tam np zapomniało że a to przekraczam granicę tablicy i nadpisuję coś, albo gdzieś mi stos idzie w diabły, albo coś źle rzutuję przy udziale wskaźników itp itd itp

z doświadczenia wiem, że warto iść najpierw tą drogą - a po watchdoga to wiesz kiedy sięgać ?

wtedy gdy projekt już pracuje non stop, przez ileś dni i nie można wyłapać już ŻADNEGO BŁĘDU, ŻADNEJ ZWIECHY ... O! to jest moment tuż przed oddaniem projektu aby włączyć watchdoga "NA WSZELKI WYPADEK" .... Bo po to on jest a nie po to aby łatać dziury - bo jak sam widzisz - przylepienie jednej łaty powoduje że projekt PRUJE się dalej i mocniej i powstają jeszcze większe DZIURY i znowu ŁATY .....

reasumując - moim zdaniem, i tak ZAWSZE - suma sumarum, szybciej (chociaż to pojęcie względne) potrwa wyszukanie błędu niż próba jego ŁATANIA ...

stąd kolejny wniosek, że sztuka programowania to nie tylko programowanie i debugowanie ale jeszcze coś ... jeszcze tworzenie kodu do wyszukiwania - symulacji błędów .... O! ... to jest kolejne "TO"

Ja np nie mógłbym pójść spać - gdybym klientowi miał oddać projekt, który mi się wiesza czasem na stole .... i miałbym to próbować watchdogiem załatwiać. Bo zawsze wiem , że takie coś wróciłoby do mniej jak koci bumerang tylko że ze zdwojoną jak nie potrojoną siłą .... np za pół roku - i wtedy leżysz już sobie na wakacjach odpoczywasz - cieszysz się że u klienta działa a tu telefon .... ! Panie Kowalski - system mi się wyłożył i hala maszyn stoi ... zrób pan coś - bo tylko pan wiesz o co tam chodzi

------------------------ [ Dodano po: 5 minutach ]

dlatego jak piszesz że po jakiejś tam ramce się wiesza - to hajda:

1. sprawdzanie czy stos się nie przepełnia - nawet w przerwaniu watchdoga - można przecież - w greenbooku masz przepis jak to sprawdzać

2. stworzenie przejściowo działającego kodu z własnymi wstawkami debugującymi czyli np przesyłającymi LOG'i z operacji po każdej odebranej albo tylko po niektórych ramkach i wysyłanie ich przez RS232 do terminala czy na kartę SD a potem przeglądanie żmudne

nie ma że boli - każdego BUG'a da radę złapać i nogi mu wyrwać z tyłka

jak mówię jeden z moich projektów działa już w jednej firmie i to na stosie tuxgraphicsa po UDP z wieloma komputerami ... mającymi dostęp do sterowania tym urządzeniem ... hmm dzisiaj to już chyba będzie ze 2-3 lata ... Jest watchdog ... ale jeszcze (nawet sam się dziwię) ani razu się nie odezwał bo aplikacje na kompach miałyby zwiększony licznik odpaleń watchdoga

_________________
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 ]

Najciekawsze jest to że " po kablu" mogę bombardować ten uC nawet i bez przerwy przez cały tydzień i zero zwiechy a po WiFi klapa no nic, w sumie już mi się nigdzie nie śpieszy z tym projektem także podłubię w nim jeszcze troszkę

po WiFi pewnie przychodzi to jakoś pakietowo ... może są porwane ramki - tak tylko próbuję zgadywać. Przydałoby się posprawdzać je programem WireShark ... może ?

_________________
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 ]

Jaki masz moduł wifi? np. wiznety po niewłaściwej konfiguracji "zawieszają" się co prawda nie jest to typowy zwiech, a po prostu przejście modułu w tryb oszczędzania energii, wystarczyło uruchomić broadcast samego modułu wizfi, zmniejszyć czasy wysyłania, wyłączyć tryb oszczędzania energii i moduł przestał się rozłączać nawet jak żadne dane przez niego nie przelatują.

No ale pytanie, po zawieszeniu sie, jak wypniemy kartę wifi, a wepniemy bezpośrednio kabel, to działa, czy też wisi?
Zresztą to łatwo sprawdzić w którym miejscu (mniej wiecej) zawisa program.

Łatwo czy nie łatwo .... ale przede wszystkim WARTO właśnie takie testy porobić .... dokładnie takie - bo czasem może się już na tym etapie coś okazać ....

------------------------ [ Dodano po: 1 minucie ]



no tak tylko obawiam się, że na avr'ku nikt raczej nie robi tak dużej transmisji żeby swoje dane słać chociażby w dwóch datagramach .... ale może ? może akurat kolega tak robi ? .... no wtedy to bardzo cenna uwaga ...

bo oczywiście jeśli mniej niż jednym datagramie czyli mniej niż 1024 bajty - to nie ma obaw że to zostanie podzielone na mniejsze paczki i przyjdzie w odwrotnej kolejności.

_________________
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 ]

No łatwo w sensie, że co za problem wrzuć w kilku linijkach LED_TOG , i paczać która dioda przestała migać .

No dokładnie - takie najprostsze rozwiązania często bywają najskuteczniejsze - więc jak najbardziej jak najbardziej ...

_________________
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 ]

Powiem więcej, dorzucamy obsługę UARTa wysyłanie tj. sam Tx i mozemy nawet sobie wysyłać wartości zmiennych/tablic po uarcie , na terminalu potem ładnie widać co się dzieje .

No dokładnie tak jak mówisz ... wysyłanie większej ilości danych tak żeby trzeba było aż kilku datagramów to raczej w takim przypadku avr'a mało realne wręcz. Dlatego wspomniałem tylko, że brak kolejności nadsyłanych pakietów tylko wtedy mógłby doskwierać ewentualnie. A w praktyce w sieci lokalnej można przyjąć, że nigdy się to nie zdarzy jak już to gdy komunikacja leci przez wiele routerów po całym świecie przez internet

_________________
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 ]

Dziękuję za odpowiedzi !
Udało mi się namierzyć funkcje w których najprawdopodobniej dochodzi do zawieszenia Kombinuje narazie i wciąż testuje, także jak na coś wpadnę to oczywiście napiszę.

Co do wielkości przesyłanej ramki, nie przekraczają one zwykle 100 bajtów, gdyż zawierają tylko linijkę hexa (43 znaki) i 2 polecenia by wywołać odpowiednie funkcje. Po odebraniu linii uC odpowiada do kompa, że chce więcej i tak to się kręci. Oczywiście jeśli komputer nie otrzyma potwierdzenia, nie wysyła kolejnych paczek.

Jak pisałem, po kablu wszystko fajnie chodziło, po dołączeniu routera troszkę się posypało.
Mam takie swoje luźne domysły więc może od razu mnie sprostujecie ?:) Czy jest możliwe żeby transmisja SPI się zawieszała gdzieś miedzy modułem ethernetowym, a avr ? Jeśli ma to jakiś wpływ, moduł taktowany kwarcem 20 Mhz, atmega wewnętrznym 8Mhz.

No a drugie co mi przychodzi do głowy to być może jakiś problem ze stosem ? Troszkę mi to nie pasuje gdyż na zwiechę nie ma reguły, czasem po odebraniu 2 linii a czasem po 190. Aczkolwiek pojawia się jeszcze jeden ciekawy objaw
Po odpaleniu programu na PC klikam "Połącz" na co odpowiada mi uC ( wywołana w nim zostaje odpowiednia funkcja), następnie przesyłam hasło na co znowu odpowiada mi uC(też odpowiednai funkcja) i teraz uwaga. . Kiedy tak się zawiesi podczas odbierania różnych danych, bardzo często SAME wykonują się powyższe 2 funkcje (bez odebrania odpowiednich poleceń z kompa). I wykonują się one zawsze w tej samej kolejności.

Większość moich problemów na forum została już określona jako Kosmiczne Dobrze jednak że ktoś sprowadza mnie na ziemię )


Edit:

Przepraszam najmocniej, jednak to taktowanie etherneta 25 Mhz

O matko a co to za moduł ethernetowy ? Pierwszy raz w życiu słyszę żeby był taktowany kwarcem mniejszym niż 25MHz. ENC28J60 ma w nocie wyraźnie napisane 25MHz

a teraz druga sprawa - ja piszę o tym w bluebooku ale i powtarzałem na forum często też to co opisywali na tuxgraphics. Że przy powolnym taktowaniu procka AVR np 8MHz dochodzi do zawieszania się transmisji właśnie pomiędzy ENC28J60 a prockiem AVR. Ci z tuxgraphics pisali nawet w tej sprawie do supportu Microchipa ale uzyskiwali tylko mało przychylne odpowiedzi, że oni sugerują po pierwsze używanie wraz z ENC procków PIC oraz żeby zapewnić możliwe największe taktowanie zegara SPI ze strony procka. W AVR jak ustawisz bit SPI2X gdy masz taktowanie 8MHz to uzyskasz raptem 4MHz czyli LIPA ...

dlatego ci z tuxgraphics wpadli na pomysł aby taktowanie procka brać z wyjścia CLKOUT scalaka ENC o częstotliwości 12,5MHz nawet przy założeniu że procek będzie przetaktowany bo przecież zasilają go oni zawsze z 3,3V ... Pisali że się znaczenie poprawiło ale i tak zalecają stosowanie watchdoga ...

dlatego ja już od dawien dawna nie bawię się w taki chocki klocki tylko biorę procka AVR zasilam go normalnie 5V daję mu kwarca 20MHz ew minimum 16MHz i wtedy dopiero gadam z ENC po konwersji sygnałów na swojej karcie też zgodnie z notą microchipa

takie podejście dopiero w 100% eliminuje te problemy

a jak ty jedziesz na ŚLIMAKU 8MHz to hmmm nie ma co się dziwić

_________________
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 ]

o w takim razie jutro montuje jak trzeba i dam znać co z tego wyszło dzięki !

Tylko nie odbierz tego źle - to zawieszanie przy wolnym taktowaniu to wcale nie jest tak że ZAWSZE i od razu - z opisów na tuxgraphics wynikało że to się dzieje bardzo rzadko no ale wiadomo wtedy jest najbardziej upierdliwe ...

a skoro u ciebie to się dzieje tak że jak włączysz procka i poczekasz chwilkę i od razu BACH!... no to raczej masz jeszcze gdzieś Bugi w sofcie - na to wygląda ... Najgorzej jak się miesza wiele bugów i w sofcie i w sprzęcie wtedy jest Bonanza.

_________________
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 ]

Swoją drogą sprawdzałeś Mirku w jakich momentach się to dzieje dokładnie? może podłączyć analizator i zobaczyć przy jakich rozkazach jest to najczęstsze? czy ogólnie przez wolną transmisję po prostu ENC świruje gdzieś wewnętrznie i nie jest to zależne od tego jaki w danym momencie rozkaz/daną otrzymuje.

Wiesz co? to zawieszanie przy taktowaniu 8MHz to jak kiedyś próbowałem testować - ale to było hmm no dawno temu - to wiesz jak to bywa, ślęczałem godzinami i nic, i nic .. i działa ..... no zero problemu - więc zostawiałem na noc działające ... a rano przychodziłem i zwykle działało ale czasem ... raz na jakiś czas ZONK wisi wszystko ... wtedy też doczytałem o tym kłopocie na tuxgraphics i odpowiedzi z Microchipa i dałem sobie spokój z testowaniem ... zrobiłem tak jak teraz opisywałem i od tamtego czasu nie mam nigdy żadnych problemó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 ]

Witam !
Po dołożeniu kwarca transmisja rzeczywiście troszkę się poprawiła na pewno nie zacina się tak często jak poprzednio
Jednak jest małe "ale", bo jednak się czasem zacina . .
No ale zdaje się, że znalazłem źródło problemu, potrzebuję jednak wytłumaczenia o co kaman
Kiedy po SPI mam do uC wpięty tylko moduł ethernetowy, transmisja lubi się zaciąć od czasu do czasu, kiedy jednak mam też jednocześnie wpięty programator ... 0 błędów ! bezproblemowa transmisja z neta do uC. Testowałem to przez kilka godzin i nie może być mowy o pomyłce.
W czym więc leży problem ? Czy może on wynikać z budowy płytki stykowej, czy zasilania linii SPI ? a może potrzeba mi tutaj jakiegoś pull up ?
Zaznaczam że z programatora nie zasilam płytki

To ty to testujesz na płytce stykowej ??? ..... szok

na stykówce to można się spodziewać cudów niewidów i innych hop-sztosó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 ]

Odkopię temat z przed miesiąca, nie chcę siać zamętu na głównej a wątek wciąż tyczy się jednego projektu
Płytki wytrawiłem, wszystko połączone ok i .. Problem dalej ten sam, tz jeśli mam moduł połączony moduł etherentowy to transmisja lubi się czasem zacinać. Po podłączeniu programatora USBasp pod złącze ISP (może być nawet nie wpięte złącze usb) transmisja przebiega idealnie.. to skłoniło mnie do poszukiwań w hardware, i kiedy jeszcze miałem wszystko na płytce stykowej, jak ręką odjął pomogło podciągnięcie linii SS uC do vcc. Niestety na pcb ta sztuczka nie zaowocowała ale . .
Jeśli moduł ethernetowy mam połączony z moją płytką(pcb) poprzez taśmę 10 żyłową, wraz z 10 pinową końcówką transmisja lubi się zawiesić, nie zawiesza się jednak NIGDY kiedy zamiast tej taśmy zastosuję przewody wykorzystywane na płytce stykowej ( takie jakimi Mirek łączy USBasp z uC). Mówię tutaj o sytuacji kiedy w złącze isp programator NIE jest wpięty. Sprawa pewnie dotyczy pojemności, i kombinuje jak sobie z tym poradzić "domowymi" sposobami, bo wiadomo jutro święto i nie kupię przewodów ekranowanych aby i z nimi spróbować Nie ukrywam że pasowało by mi podłączenie taśmą głównie z powodu estetyki i niezawodności połączenia. Chciałem też dodać, że podłączałem taśmy o różnych długościach 30 cm, 15, 3, efekt bez różnicy może ma ktoś jakieś rady ? czy jednak pozostaje mi czekać do wtorku

dlatego jak widzisz ja nie podłączam modułu Ethernetowego na kabelkach - gdzie ty widziałeś u mnie takie rozwiązanie ? Moduł jest wpinany w gniazdo KANDA - żadnych przewodów połączeniowych.

_________________
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 ]

Rozumiem w takim razie z czystej ciekawości mam jeszcze jedno pytanko. Jeśli podłączoną mam taśmę miedzy eth ,a uC oraz ze złącza ISP do programatora mam podpięte tylko MISO oraz SCK to wszystko śmiga elegancko Chciałem dodać że są to te same linie. Zastanawiam się o co to chodzi, co daje wpięcie tych 2 linii w programator ? No i można wywnioskować że po wpięciu tych 2 linii, sygnały po taśmie się już nie zakłócają

Jak tak dalej pójdzie to dostanę chyba . . . No nie ważne
Przerobiłem dziś wtyczkę na taśmę ( złącze KANDA) na 2x5 żeński gold pin, tak aby możliwe było podłączenie "na kanapkę". Wszystkie sygnały sprawdziłem 5x czy aby napewno wszystko idzie tak jak trzeba i ..... ? Wciąż się zacina ;o Odbieram nieduże paczki danych i zacina się wciąż w różnych momentach. Dlaczego więc na długich przewodach które szły osobno wszystko działało ? eh .. Wygląda mi to jak by któraś nóżka (prawdopodobnie sck lub miso) podtrzymywała swój stan i uniemożliwiała komunikację z uC.

Mam prośbę , pokarz schemat i pokaż fotkę połączeń , jak masz to na stykówce to może się dziwnie zachowywać i nie obliczalnie , ale zastanowiło to co pisałeś wcześniej ... że z wpiętym programatorem się nie wiesza i dlatego chcę cos zobaczyć mam pewne podejrzenia , ale muszę to zobaczyć

ok ??

Zastanawiające jest to że czy to na stykówce czy na PCB, problem był ten sam.
Wstawiam zdjęcia:


Oczywiście w miejscu tych żeńskich goldpinów było złącze KANDA po drugiej stronie.
Dodam jeszcze ze złącze do ENC to jest ta pozioma KANDA

Właśnie nad tym się zastanawiam , bo z opisu wynika że gdzieś brakowało, któregoś sygnału