No napisalem 41 - fakt moze przesadzilem, ale obecnie uzywam juz chyba wiekszosci prockow z roznych linii ST i troche tych plikow na dysku sie zgromadzilo.
No przesadziłeś, bo tak licząc można przecież powiedzieć, że do AVRów jest ze 100 errat - po jednej do każdego modelu. W STM32 jest nawet lepiej niż w AVR, bo masz erratę do części rodziny (np. ~10 układów) (;
tplewa wrote:
Natomiast co do Windows-a to tutaj sie nie zgodze, jesli chodzi o MSDN to jest jedna z lepszych dokumentacji i wielu moglo by sie uczyc jak to sie robi (np. google i dokumentacja Androida jak chcemy bawic sie w NDK).
Chodziło mi o obszerność, bo zarzut o fragmentacji jest mało sensowny - 2 dokumenty (+ ewentualnie errata) wystarczają w 99,666% przypadków.
Witam Panowie.
Pozwole sobie jeszcze wrocic do tego ekranu dotykowego.
Mam nadzieje, ze teraz juz nikt nie bedzie mial watpliwosci, ze to nie jest normalne, zeby poswiecac 2 dni i 2 telefony do ST, zeby miec pewnosc, ze ekran jest dotykowy:
Quote:
Hi Mariusz,
I am responding to your recent request to the Farnell Technical Support Group regarding the STM32F429I-DISCO dev board. I call ST Micro yesterday and they said they had to do some additional research on the LCD display to determine if it is touchscreen or not. I will let you know as soon as I hear back from them.
i troche pozniej:
Quote:
Hi Mariusz,
STI Micro called me back and they confirmed that STM32F429I-DISCO (Farnell part number 2355377 click on the link at left) has a touch-screen LCD display.
Best Regards,
Doug
Technical Support Engineer
Samo ST nie wie co sprzedaje, a ja mam miec pewnosc.
Rownie dobrze, moga tam wkladac raz LCD bez dotyku,a innym razem dotykowy.
Nikt im nie zabroni, zawsze beda gora, a ze zwyklym bym nie kupil.
Za to z dotykowym zaraz zamowie.
Kolego ja czarno widzę pisanie programów przez Ciebie na tym STM32 jak z tym ekranem dotykowym robisz takie zamieszanie. Wg schematu jest dotyk. Przykładowa aplikacja bez dotyku raczej nie działa jak należy. Chińczykowi produkcja dwóch wersji drożej by wyszła niż koszt tego dotyku. Masz naprawdę za wiele czasu chyba, żeby robić takie śledztwo w imię tego ekranu dotykowego. Zamiast tego byś napisał: openocd mi działa/nie działa (jak telnetuje się i wydam jakąś komendę to działa), ecplis działa/nie działa mi to i tamto itd. Wtedy może udało by Ci się pomóc aby Ci to poszło. Na tą chwilę raz wspomniałeś, że Ci działa openocd. Więc co dalej nie idzie? Ecplips szedł wszystkim, może użyłeś wersji 64 bit zamiast 32? Kompilator (gcc) działa? W ścieżce go widzi? Make i inne programy potrzebne do kompilacji są i masz do nich ścieżki? Itd itd itd... na elektrodzie już tyle razy to wałkowane było. Naprawdę pisanie pod te uC jest trudniejsze niż zmuszenie środowiska (Eclipse, openocd, gcc) do pracy.
Powracając do tego dotyku - dotyk jest, leżą w szufladzie mi te zestawy i mają dotyk. Do nauki jednak bym tego nie brał bo to skok na głęboką wodę i bardziej się zrazisz... na początek naprawdę trzeba pomigać diodą a dotyk i TFT może jednak za jakiś czas. Szczególnie jakby to bez bibliotek pisać i czytać RM'y...
Pozdrawiam i powodzenia życzę.
No coż - faktycznie w opisie produktu nie jest nigdzie napisane "wprost", że jest panel dotykowy, jednak:
- na zdjęciu widać, że jest to panel dotykowy (każdy kto widział raz w życiu panel rezystancyjny to zauważy),
- w schemacie jest,
- w opisie pinów jest opis podłączenia "touch panel",
- na każdym filmiku na youtube widać że obsługa jest z panelu dotykowego.
No i śledztwo jest niegodne ceny tej płytki - ja rozumiem jakby ona kosztowała 2000zl to wtedy lepiej sprawdzić na co się dokładnie taką kasę wydaje, ale płytka za 80zł (czy ile ona teraz kosztuje)?
Podobnie jak przedmówcy wydaje mi się, że zanim dojdziesz do tego panelu dotykowego to trochę czasu minie... I "trochę" nerwów pewnie też będzie... To przecież jak z programowaniem na PC - każdy umie napisać "hello world" w C, albo na informatyce pisało się jakieś proste programy i to szło. No ale od tych programików do czegoś na system okienkowy (niech będzie np na Qt) to są "lata świetlne" (;
Powracając do tego dotyku - dotyk jest, leżą w szufladzie mi te zestawy i mają dotyk. Do nauki jednak bym tego nie brał bo to skok na głęboką wodę i bardziej się zrazisz... na początek naprawdę trzeba pomigać diodą a dotyk i TFT może jednak za jakiś czas. Szczególnie jakby to bez bibliotek pisać i czytać RM'y...
Pozdrawiam i powodzenia życzę.
Ok, ok, mam zwykle F4Discovery, a dotyk zwrocil moja uwage, bo cena przystepna.
Pozniej sie wkurzalem, bo wszystko swiadczylo o tym, ze to dotyk.... tylko nie producent. On tego nie napisal slowem w zadnym ze swoich dokumentow, w zadnym.
I co ? I Wy mowicie, ze tak ma byc, ze to normalne, ze o co chodzi, przeciez wszystko wiadomo.
Mowcie co chcecie, ale to jakby obsiadlo mnie stado wron i mowilo, ze swieci slonce, a ja bym widzial ciemnosc.
Tak ludzie opisuja, a pozniej w PDF-ach ten sam facet nie napisze czegos innego i czlowiek traci 2 dni, zeby do tego dojsc. Pewnie Wy to pochwalicie, bo nie ma to jak samemu ....
Nie napisalem wiecej o OpenOCD i reszcie, bo srodowisko zadzialalo, a mam teraz tyle na glowie, ze nie bardzo jest czas na programy.
Pewnie bede mial jeszcze 1000 problemow i na pewno nie usiade tutaj od strzalu i nie bede marudzil. Latwo powtarzac, ze wszystko juz bylo, ale jakos nie znalazlem tematu o bledzie w Eclipse, ktory twierdzil, ze metoda kompresji mu nie odpowiada i nie zainstaluje tego czy tamtego. Fora mowia w tym punkcie mniej wiecej tak: instalujesz plugin-y i pozniej naciskasz NEXT... A kazdy komentuje: o co Ci chodzi, to takie latwe bylo, tam sie tylko naciska NEXT. Nie chce nawet odpowiedzi, ale chce uswiadomic niektorym, ze jak im sie udalo, bo akurat mieli wlasciwe wersje plikow, bibliotek, itd, to wcale nie znaczy, ze komus innemu sie to nie moze sypac co krok. To warto by bylo zrozumiec.
Pozdrawiam,
Mariusz
Dodano po 21 [minuty]:
Freddie Chopin wrote:
No coż - faktycznie w opisie produktu nie jest nigdzie napisane "wprost", że jest panel dotykowy, jednak:
- na zdjęciu widać, że jest to panel dotykowy (każdy kto widział raz w życiu panel rezystancyjny to zauważy),
No to brniemy dalej.
A jak nie widzial ? Po to kupuje taki zestaw, zeby sie pobawic dotykiem, wyciaga z pudelka, a dotyku nie ma. Sprzedawca mowi, ze przeciez mialo nie byc i o co chodzi ? Pewnie masz na mysli tasiemke z nakladki rezystancyjnej, ale wiem, ze sa jeszcze lepsze wersje tych modulow z lcd 3,5" i tam jest co 2 zdanie o tym, ze to jest touchscreen. Takze jesli chca, to potrafia.
Freddie Chopin wrote:
- w schemacie jest,
- w opisie pinów jest opis podłączenia "touch panel",
- na każdym filmiku na youtube widać że obsługa jest z panelu dotykowego.
To wszystko juz wiemy, ale nie sa to podstawowe czynnosci, ktore wykonuja godzac sie na zakup takiego modulu. Oczywiscie, ze przez wrodzona przezornosc czlowiek zajrzy gdzie sie da, zeby sie dowiedziec chociazby czy to ma jakies napiecia wyprowadzone na zewnatrz czy inne takie. To nie worek ziemniakow.
Co nie zmienia faktu, ze opisali to zle.
Freddie Chopin wrote:
No i śledztwo jest niegodne ceny tej płytki - ja rozumiem jakby ona kosztowała 2000zl to wtedy lepiej sprawdzić na co się dokładnie taką kasę wydaje, ale płytka za 80zł (czy ile ona teraz kosztuje)?
Freddie, mnie chodzi o zasady.
Tego nikt nie moze zrozumiec chyba, ze sa jakies zasady.
Dla mnie to oczywiste, ze zrobili blad w opsie nie wspominajac o tym dotyku, bo robia to w 10 innych plytkach, ktore sprzedaja i sie tym chwala.
Kosztuja ponad 300 zlotych chyba, no ale z dotykiem ! Kazdy sobie powie, ze jak z dotykiem, to musi kosztowac. Wtedy nie sprzedadza tej, o ktorej tutaj piszemy, bo ona kosztuje 91 w Farnell-u. Pewnie zarabiaja na niej grosze, a na tej za 300 juz dwa razy tyle. Jak widac, to sie przeklada pozniej na bardzo wiele rzeczy, ktorych ludzie nie widza. Ja dostrzegam i trudno mi sie z tym pogodzic. Liczylem na odzew w postaci: no tak, nie opisali badziewiarze, a ma dotyk i tyle Ci powiemy. A tu dyskusja na 2 dni. I niech bedzie skoro to potrzebne, ale w glowie mi sie nie miesci, ze mozna ST bronic w tym wypadku.
Tym bardziej, ze sami nie wiedza czy jest dotyk i musza to super sprawdzac.
Dlaczego ? Bo zaden geniusz nie wpadl na to, zeby to dopisac chociaz w jednym miejscu, w jednym !
Freddie Chopin wrote:
Podobnie jak przedmówcy wydaje mi się, że zanim dojdziesz do tego panelu dotykowego to trochę czasu minie... I "trochę" nerwów pewnie też będzie... To przecież jak z programowaniem na PC - każdy umie napisać "hello world" w C, albo na informatyce pisało się jakieś proste programy i to szło. No ale od tych programików do czegoś na system okienkowy (niech będzie np na Qt) to są "lata świetlne" (;
4\/3!!
Ok, nie mowie, ze bedzie latwo chociaz pomyslalem, ze w ASM byloby ciezko, za to tutaj pewnie sa gotowce w C i bedzie prosciej.
Skoro piszecie, ze nie, to zaczynam szukac informacji, zeby sprawdzic czy to naprawde daje w kosc.
Poki co mnie wystarczy proste menu tekstowe w pionie, dzieki czemu zamienilbym klawiaturke na 21 wiek.
Może więc warto by było napisać co zrobiłeś, że Ci zadziałało, w jakich konkretnych warunkach ten błąd wystąpi (np wersja Windows/Linux, wersja Ecplise) i pomóc innym? Sam walczyłem z Ecplipsem jak jeszcze nie był dla ARMów tak popularny, były z pluginami problemy ale trzeba było je zwalczyć np. zmienić wersje Eplipsa, zainstalować ponownie, poszukać i dodać plugin ręcznie- typowa robota dla informatyka-nic szczególnego właściwie. Ale w porównaniu do niektórych ciekawostek w tych uC to instalacja tego środowiska nie jest jakaś koszmarna. Nie liczyłbym, że "jak mam C to mi łatwo pójdzie". Zobaczysz jak zaczniesz pisać, jak przebrniesz przez część dokumentacji. Biblioteki są dobre aby zobaczyć to czego nie napisano jawnie w PDFach i... napisać to po swojemu. Szczególnie, że w przykładach jest wiele pułapek, w polskich książkach czasami też ciekawostki. Zobaczysz jak Ci przyjdzie napisać dobrą obsługę UARTu dla EIA-485 z parsowaniem odebranych znaków, dobry sterownik Ethernet który da się podpiąć pod sieć "produkcyjną", jak skonfigurować pamięć w RTOSie... i wiele innych. Te uC wymagają naprawdę sporo czasu i poświęconych nocy aby je "wyczuć". Jak napiszesz coś w bibliotece i ci nie zadziała to i tak bez sięgnięcia do dokumentacji i dokładnego przyjrzenia się działaniu biblioteki nie poprawisz problemu.
Discovery za 300zł? Jaki model? Może jakiś większy zestaw ale one kosztują jeszcze o tysiąc więcej...
Menu ma być dobrze zrobione czy jako przykład? Zrobienie dobrego menu wymaga najpierw poznania C (wskaźniki szczególnie), do tego obsługa HD44780 oczywiście z obsługą linii RW, buforowaniem i wyświetlanym w przerwaniu sterowanym z timera. Do tego maszyna stanów. Przykład był jakiś czas temu tutaj. Działa pięknie. Naprawdę zacznij od migania diodą, potem kilkoma, potem z timera, itd... Przykłady jedno, życie drugie.
Może więc warto by było napisać co zrobiłeś, że Ci zadziałało, w jakich konkretnych warunkach ten błąd wystąpi (np wersja Windows/Linux, wersja Ecplise) i pomóc innym? Sam walczyłem z Ecplipsem jak jeszcze nie był dla ARMów tak popularny, były z pluginami problemy ale trzeba było je zwalczyć np. zmienić wersje Eplipsa, zainstalować ponownie, poszukać i dodać plugin ręcznie- typowa robota dla informatyka-nic szczególnego właściwie. Ale w porównaniu do niektórych ciekawostek w tych uC to instalacja tego środowiska nie jest jakaś koszmarna. Nie liczyłbym, że "jak mam C to mi łatwo pójdzie". Zobaczysz jak zaczniesz pisać, jak przebrniesz przez część dokumentacji. Biblioteki są dobre aby zobaczyć to czego nie napisano jawnie w PDFach i... napisać to po swojemu.
Ze wstydem powiem, ze bylem tak zdesperowany, ze sciagnalem wszystko co sie dalo i probowalem w ciemno. Napalilem sie i tyle.
No i pozniej jak Eclipse wlasciwie nie chcialo juz ze mna rozmawiac, to sciagnalem je od nowa i zrobilem nowa instalacje. Pozniej odpalilem jakis przyklad z GPIO i nagle sie zaprogramowalo. Po drodze uaktualnialem firmware w ST-Linku kilka razy, bo jakims cudem okazywalo sie, ze mam starsza wersje, chociaz wrzucalem kilka godzin wczesniej najnowsza. Uznalem, ze te softy wgrywaja jakis swoj firmware, bo kombinowalem naprawde na wszystkie sposoby.
Zadzialalo oczywiscie w momencie jak napiasalem pierwszy post....
IS wrote:
Zobaczysz jak Ci przyjdzie napisać dobrą obsługę UARTu dla EIA-485 z parsowaniem odebranych znaków
No wlasnie w ASM to bylo "brzydkie", a jak widzialem tablice w C, gdzie sie wszystko pieknie "samo do nich pakowalo", to pomyslalem, ze to musi byc piekny swiat. I te wskazniki do tablic. Wszystko takie przejrzyste...
IS wrote:
dobry sterownik Ethernet który da się podpiąć pod sieć "produkcyjną",
Nawet zly bylby marzeniem Skonczylem niestety na obsludze ENC28J60 i i tak cieszylem sie jak dziecko, ale to mialo tylko 10M, wiec znowu czulem, ze przedszkolaki w Bascom-ie robia 100M w pol dnia.
Przerabialem Wiznet-a z C na ASM, bo znalazlem ladny przyklad, ale to wszystko byly protezy. Mialem wizje, zeby wszystkie sprzety w domu mialy ethernet za 30 zlotych sztuka. Od odkurzacza, lodowke, ekspres do kawy, po WC. Z tym ENC, to by sie moglo udac, ale jak bede mogl powiedziec, ze w moim WC siedzi ARM, to satysfakcja bedzie wieksza
IS wrote:
jak skonfigurować pamięć w RTOSie... i wiele innych.
Poki co science fiction
IS wrote:
Te uC wymagają naprawdę sporo czasu i poświęconych nocy aby je "wyczuć".
A tu dzieci, zona, remont. Grunt, to sie nie zalamywac po tym, co piszecie.
Zaraz ide na wodke i znowu nie bedzie czasu na nauke. Jak przychodzi jakies przerwanie NMI od sasiadow, to czlowiek nie ma wyjscia i musi sie zglosic Szkoda tylko, ze nie ma z kim pogadac. Elektronikow na tym swiecie chyba zbyt wielu nie ma - a przynajmniej "czynnych" i "w zawodzie".
IS wrote:
Jak napiszesz coś w bibliotece i ci nie zadziała to i tak bez sięgnięcia do dokumentacji i dokładnego przyjrzenia się działaniu biblioteki nie poprawisz problemu.
Dlatego nie jestem zwolennikiem uzywania gotowcow, a z drugiej strony, jesli ktos juz cos napisal, to wiekszosc powie, ze lepiej sie skupic na wlasciwym zadaniu.
Te 2 sprzecznosci caly czas we mnie walcza.
Quote:
Discovery za 300zł? Jaki model?
Może jakiś większy zestaw ale one kosztują jeszcze o tysiąc więcej...
Moze teraz ktos sie jednak w glowe podrapie i stwierdzi, ze gdyby wiedzial, ze lcd w zestawie za 99 pln jest dotykowy, to wolalby wydac wlasnie tyle, a nie 454 (wow !). Do tego za 30 ethernet i radosc z tego, ze jednak cos sie samemu zlozy.
Jak bylem mlodszy, to w ogole nie kupowalem zestawow i sam wszystko lutowalem.
Teraz juz chyba jestem stary, bo kupilem kiedys plytke stykowa, a w ogole jak cos robie (nawet prototyp), to zamawiam gotowa plytke. Teraz te zestawy od ST - to musi byc oznaka starosci...
Quote:
Menu ma być dobrze zrobione czy jako przykład?
Noooo, raczej dobrze, ale jestem gotowy na kompromisy.
Nie wiem co mozna zrobic zle.
Quote:
Zrobienie dobrego menu wymaga najpierw poznania C (wskaźniki szczególnie), do tego obsługa HD44780 oczywiście z obsługą linii RW, buforowaniem i wyświetlanym w przerwaniu sterowanym z timera. Do tego maszyna stanów. Przykład był jakiś czas temu tutaj. Działa pięknie. Naprawdę zacznij od migania diodą, potem kilkoma, potem z timera, itd... Przykłady jedno, życie drugie.
Miganie dioda wrzucilem tak na szybko w ramach testu i wiem, ze dziala.
Za to ilosc bibliotek i tekstu w srodku przyprawia mnie o bol glowy.
Wiem, ze tak musi byc, wiem. Przesledze to wszystko, bo madrzy ludzie mowia, ze jak bede pisal w C i za 2 lata siade, zeby cos poprawic/dodac, to zajmie mi to 10 minut. W moim ASM nawet z komentarzami, pewnie siedzialbym 2 dni.
Te dzialania w przerwaniach, to chyba fundament dla tych wszystkich RTOS-ow, o ktorych nie mam zbyt wiele pojecia, ale wydaje mi sie, ze jest to wlasnie "ubranie" przerwan w jakis logiczny ciag. W ASM byloby to trudne do zrobienia, ale w C pewnie juz nie tak bardzo. Zaleta jest chyba taka (to co mi sie rzucilo w oczy), ze zadania maja np. swoje priorytety. Jak robie te swoje programy, to co sie zglosi, to zostaje obsluzone. W PIC-ach mialem ten problem i to mnie do nich tez zniechecilo, ze jak mcu wchodzi w obsluge przerwania, to blokuje wszelkie zrodla przerwan dla innych. Niby tak, ale jak go atakowalem wtedy 100 wywolaniami przerwan z zewnatrz, to sie wysypywal (chyba resetowal).
Zaklada zawsze najgorszy przypadek i uwazam, ze soft sie nie moze wysypac chocby nie wiem co (zawiesic). Reset tez nie jest dobry w tym wypadku.Niech zglosi blad, zajetosc, cokolwiek....ale niech dziala.
W ARM-ach wyczytalem, ze mam priorytety juz na poziomie sprzetu i pewnie bym chcial to gdzies wykorzystac, ale poki co nie wiem ani jak, a co gorzej gdzie.
Jak sie cos zglasza, to moze jednk jest wazniejsze od drugiego, ale to drugie w koncu przestanie sie zglaszac, ale ja tego nie obsluze ?
Nie da sie tego chyba nigdzie "zapamietac" i bedzie wpadka.
Przycisk STOP w maszynie moze miec priorytet najwyzszy, ale jak w tym czasie bedzie sie zglaszalo przepelnienie zbiornika i zawor sie nie zamknie, to co wtedy ?
Wiem, ze skacze z tematami, ale to takie przemyslenia na swiezo i moze komus sie jednak bedzie chcialo mnie oswiecic.
Niby nic sie nie dzieje tak szybko i wszystko sie obsluzy (tym bardziej przy ARM z takimi czestotliwosciami jakies oferuje), ale samo zagadnienie mnie interesuje.
Meczylem tego PIC-a biednego, bo nie ma zadnego buforowania przerwan i nie wiem czy w ogole gdzies jest. Fakt, ze ustawienie flagi, zajmuje kilka us, ale czasami trzeba w przerwaniu zrobic cos wiecej i co wtedy ?
HD44780 mam w miare opanowane, ale fakt, ze zawsze zwieralem RW do masy i nigdy nie mialem z tym problemu. Nawet jak robilem tekstowe MENU z kilkoma poziomami. Fakt, ze obsluga bledow jest wazna i swiadczy tak naprawde o klasie programisty, ale tutaj nic zlego mi sie nie przytrafilo. Tak samo jak z RS-232, gdzie wystarczaly mi 2 linie TX i RX, chociaz gdybym robil cos seryjnie, to nie wyobrazam sobie wypchnac to do ludzi bez sprzetowej kontroli transmisji.
Jak zrobilem bootloader do PIC-a, to pierwszy raz w zyciu uzylem XON/XOFF wlasnie dlatego, ze pozalowalem tych 2 pinow i pomyslalem, ze to nie zadziala. Okazalo sie, ze calkiem dobrze dziala i mcu dawal rade odbierac bez bledow, chociaz PC zanim sie zatrzymal, to wysylal jeszcze mnostwo danych.
Przerwania jak byly, to dla innych rzeczy, a wyswietlanie non-stop.
Moze dlatego, ze to byla waga i miala glownie wyswietlac (wazyc).
Pewnie w bardziej zlozonych projektach bedzie to skomplikowane, albo masz na mysli to, ze jak nie ma niczego nowego do wyswietlenia, to zeby "nie meczyc" lcd i czekac na jakas akcje (przerwanie).
Skoro tutaj tylu madrych ludzi, to czy mozna tu jeszcze zadac jakies inne pytania, czy musialby byc nowy watek ?
Moze zaryzykuje...
Czy wiecie jak sie to robi parzadnie, zeby wykrywac na magistrali RS485 wszystko co tam jest podlaczone ?
Wiekszosc urzadzen ma sprzetowo ustawiany adres, ale ja bym chcial (bo widzialem) zrobic autowykrywanie. Jakis arbitraz skomplikowany by mnie zniechecil, tym bardziej, ze wiekszosc z jakiegos powodu daje jednak dipswitch-e.
Mam w glowie kilka pomoslow, ale trudno je sprawdzic z racji tego, ze dla 2 czy 5 odbiornikow zadziala, ale dla 100 sie moze wysypac.
Zastanawiam sie czy ktos robil cos takiego i moze sie pochwalic, ze mu to dziala i jak to zrobil (w skrocie oczywiscie). Czy moze jednak po to robia glownie sprzetowo, zeby bylo pewnie i lepiej nie kombinowac ? Montowalem kiedys kamery szybkoobrotowe Bosch-a. Kupe kasy, fajne, itd. Ale jak przyszli Panowie ze spawarkami i zaczeli w hali spawac, to wszystkie adresy sie zerowaly. EEPROM-y sie kasowaly w tych kamerach...najwyrazniej, albo raczej mialy jakies bledy i wcale nie byly odczytywane. Za to jak przestawilem przelaczniki, to problem przestal istniec. Stad moje obawy i podejrzenie, ze po to robia topornie, zeby zawsze dzialalo.
Pozdrawiam
Mariusz
P.S.
Ja wiem, ze tutaj kazdy by chcial rozmawiac zero-jedynkowo, zeby opisac jakis problem (najlepiej pokazac kod), ale zagadnienia typu ogolnego tez sa wazne.
Bardzo cenie kolege Freddiego, bo on tutaj naprawde ludziom pomaga.
Chyba nie bylo postu z jego udzialem, ktory by sie nie konczyl czyms w stylu:
O, dzieki za pomoc. A ja glupi nie zauwazylem...Dzieki Tobie w koncu mi to dziala..
Takich ludzi cenie, bo widac, ze nie sprawia mu to zadnego wysilku i chetnie pomaga. Za to jakos w innych grupach wieczne walki, dyskusje swiatopogladowe, co lepsze - czy PIC czy AVR, a kto i co robi lepiej..
Zdaje sobie sprawe, ze poki co zasmiecam watek i elektrode, ale przyjdzie jeszcze czas na prawdziwe pytania, fundamentalne.
Ciekawe czy komus sie bedzie wtedy jeszcze chcialo mi odpisywac
Jak sie cos zglasza, to moze jednk jest wazniejsze od drugiego, ale to drugie w koncu przestanie sie zglaszac, ale ja tego nie obsluze ?
Nie da sie tego chyba nigdzie "zapamietac" i bedzie wpadka.
Samo się zapamiętuje - przerwanie zgłoszone jest "zgłoszone" dopóki go nie obsłużysz (albo ręcznie nie "skasujesz"), wcale nie musi być wciąż "fizycznie" w jakimś stanie.
jaskol wrote:
Te dzialania w przerwaniach, to chyba fundament dla tych wszystkich RTOS-ow, o ktorych nie mam zbyt wiele pojecia, ale wydaje mi sie, ze jest to wlasnie "ubranie" przerwan w jakis logiczny ciag.
Wątki w RTOSach mają mało wspólnego z przerwaniami, choćby dlatego, że wykonywane są w "kontekście" normalnego programu. Jedynie przełączanie odbywa się w przerwaniu.
jaskol wrote:
Czy wiecie jak sie to robi parzadnie, zeby wykrywac na magistrali RS485 wszystko co tam jest podlaczone ?
Przecież RS-485 to tylko standard fizyczny - nie ma w nim ani słowa o adresowaniu, które jest zrealizowane w 100% programowo. Tak więc czy to jest RS-485, RS-232 czy zwyczajny UART to nie ma żadnego znaczenia (no może z wyjątkiem tego, że RS-485 często jest w half-duplex, ale UART też może być).
Zawsze można się wzorować na idei autodetekcji jaka jest zaimplementowana w protokole 1-wire.
Zadzialalo oczywiscie w momencie jak napisalem pierwszy post....
Heh...to często tak bywa..Człowiek się przyzwyczaił, że "forum nam podpowie" i najpierw pisze, potem myśli. Ale ponieważ temat go interesuje, a odpowiedzi nie tak szybko się pojawiają (jak to zwykle bywa), to dalej szuka i kombinuje, i zanim ktoś napisze/podpowie, to często samemu udaje się znaleźć rozwiązanie Mimo, to z takich dyskusji, czasami pobocznym wątkiem, coś zawsze ciekawego wynika i okazuje się, że można jeszcze coś udoskonalić - czy w samym kodzie, czy we własnym stylu programowania.
jaskol wrote:
Teraz juz chyba jestem stary, bo kupilem kiedys plytke stykowa, a w ogole jak cos robie (nawet prototyp), to zamawiam gotowa plytke. Teraz te zestawy od ST - to musi byc oznaka starosci...
Teraz wszyscy tak mają - sprzedaż zapełnia powoli wszystkie nisze samodzielnego działania. Szczerze mówiąc też mam mieszane uczucia - ale jeżeli ktoś już coś umie, potrafi w razie czego samodzielnie skonstruować taką płytkę, to kupienie gotowca, już mu krzywdy nie zrobi (a na czasie może zyskać). Ale gdy ktoś zaczyna przygodę z elektroniką i od razu jedzie na gotowcach, to będzie miał szybkie efekty, ale za wiele się nie nauczy i będzie ograniczony tylko do tego, co mu jeden czy drugi producent pod nos podsunie.
Chociaż, z drugiej strony może nie można wymagać od początkującego, żeby od razu umiał projektować PCB, tworzyć schematy.... Dlatego ciężko jednoznacznie odpowiedzieć na to pytanie...
jaskol wrote:
Ja wiem, ze tutaj kazdy by chcial rozmawiac zero-jedynkowo, zeby opisac jakis problem (najlepiej pokazac kod), ale zagadnienia typu ogolnego tez sa wazne.
Bardzo cenie kolege Freddiego, bo on tutaj naprawde ludziom pomaga.
Chyba nie bylo postu z jego udzialem, ktory by sie nie konczyl czyms w stylu:
O, dzieki za pomoc. A ja glupi nie zauwazylem...Dzieki Tobie w koncu mi to dziala..
Takich ludzi cenie, bo widac, ze nie sprawia mu to zadnego wysilku i chetnie pomaga. Za to jakos w innych grupach wieczne walki, dyskusje swiatopogladowe, co lepsze - czy PIC czy AVR, a kto i co robi lepiej..
Zdaje sobie sprawe, ze poki co zasmiecam watek i elektrode, ale przyjdzie jeszcze czas na prawdziwe pytania, fundamentalne.
Ciekawe czy komus sie bedzie wtedy jeszcze chcialo mi odpisywac
Im prostsze problemy i pytania, tym więcej chętnych do odpowiedzi (zależy też jeszcze od sposobu przedstawienia problemu, itd...).
Jak Twój problem zaczyna być bardziej wyspecjalizowany/rozbudowany, to liczba osób które może na niego odpowiedzieć maleje.
Pytania ogólne - jak najbardziej. Zwłaszcza w dziedzinach typu przedstawienie, problemu, jego przykładowej koncepcji rozwiązania i pytania o to czy jest to dobra koncepcja, czy może ktoś ma lepszą.
Na etapie planowania, kiedy jeszcze nie zaczęło się programować najłatwiej zmienić plan działania, bez ponoszenia strat.
Gorzej jak już się zaczęło, i okazuje się, że można to zrobić lepiej, szybciej, inaczej sprzętowo (jest jakiś gotowy scalak, który załatwia nam 90% roboty), itd, itp....
Wtedy albo brniemy dalej w nieoptymalne rozwiązanie, albo zaczynamy wszystko od nowa tracąc czas który już zużyliśmy.
Tak więc - kto pyta nie błądzi, ale nie zawsze dostanie odpowiedź, bo ludzie nie zawsze czas mają.
Przykładowo w weekendy jest tu mniejszy ruch.
Kolego ty nie szukasz discovery tylko zestawu embesta. Mam go. Ekran dotykowy służy w przykładzie do malowania po ekranie. Opcjonalnie w Kamami to maja to zadzwoń do nich.
Aby to działało musisz mieć discovery, wyświetlacz i płytkę z Ethernetem. Jak odpuścisz sobie Ethernet to kup discovery 429DISCO i za chyba 130zł będziesz miał wyświetlacz a Ethernet dokupisz. Za 30zł się nie da bo niewiele mniej kosztuje samo PHY z transformatorkiem. Na stronie którą podałeś mają za 20USD, w Kamami za ok. 90zł. Podłączałem to pod discovery. Nawet działało, ale stabilniejsze jest na tej gotowej płytce z początku postu - połączenia przewodami i przebiegi po 50MHz to nie jest dobry pomysł.
485: pytasz po kolei 32 urządzenia czy istnieją na magistrali (jedynka zgłoś się, czekasz np. 10ms, nie zgłasza się, dwójka zgłoś się, dwójka się zgłasza w ciągu 10ms tzn jest podpięta itd) albo wysyłasz pakiet "odezwać się" a każde urządzenia po innym czasie ma odpowiedzieć (np. numer urządzenia na magistrali razy 10ms...). Opcjonalnie można jeszcze robić nasłuchiwanie, arbitraż pomiędzy masterami jakby ich kilka miało być. Kwestia co "klient ma i potrzebuje".
Ethernet - 10Mbps wystarcza do większości zastosowań typu sterowanie.
Odczyt stanu HD44780 robi się aby uC nie marnował czasu na czekanie. Taki rdzeń nie ma sensu by się marnował na zwykłych delayach w pętli.
Proponuje zmienić priorytet sąsiadom:) NMI to zdecydowanie za wiele:)
Samo się zapamiętuje - przerwanie zgłoszone jest "zgłoszone" dopóki go nie obsłużysz (albo ręcznie nie "skasujesz"), wcale nie musi być wciąż "fizycznie" w jakimś stanie.
Ok, jakas flaga sie pojawia, ale jesli obsluguje takie z wyzszym priorytetem, to nizsze czeka. To nizsze niech bedzie czujnikiem zalania.
Wody przybywa, czujnik ciagle to sygnalizuje, skonczylem obsluge wazniejszego INT-a, zajmuje sie reszta. Ale co jesli reszta to 10 przyciskow. Ktos nacisnie 1, ja jestem zajety. Flaga sie pojawi, a ja ciagle jestem w HI INT (ze tak to skrotowo bede zapisywal). On w tym czasie nacisnie 2, a flaga juz jest ustawiona.
Cos tam obsluze, ale cos przegapie. Przy zalozeniu, ze sygnaly zawsze beda nadchodzily z jakims opoznieniem i sie wyrobie wszystko bedzie ok. Ale co jesli nie bede nadazal. Musialby byc jakis bufor tych zgloszen przerwan....
Freddie Chopin wrote:
Wątki w RTOSach mają mało wspólnego z przerwaniami, choćby dlatego, że wykonywane są w "kontekście" normalnego programu. Jedynie przełączanie odbywa się w przerwaniu.
No to musze poczytac, bo zastanawia mnie ich wyzszosc nad tym co robie zwykle - przerwanie, flaga, obsluga w petli glownej jakies inne rzeczy.
To ladnie wyglada, ze da sie np. sprawdzic ile jest watkow, itd.
To na pewno bajer, ale gdzie te RTOS maja naprawde przewage, w jakich zastosowaniach ? No i przewage nad czym, bo myslalem, ze ten moj model do nich pasuje, a skoro piszesz, ze przerwania tam nie wioda prymu, to pewnie te watki daja duzo swobody, bo mozna je tworzyc w trakcie dzialania.
Ok, doczytam.
Quote:
Przecież RS-485 to tylko standard fizyczny - nie ma w nim ani słowa o adresowaniu, które jest zrealizowane w 100% programowo. Tak więc czy to jest RS-485, RS-232 czy zwyczajny UART to nie ma żadnego znaczenia (no może z wyjątkiem tego, że RS-485 często jest w half-duplex, ale UART też może być).
Zawsze można się wzorować na idei autodetekcji jaka jest zaimplementowana w protokole 1-wire.
No tak, z przyzwyczajenia napisalem o 485. Chodzi mi o sam sposob. Warstwa fizyczna prawie nie ma znaczenia. Prawie, bo I2C ma adresy na wyprowadzeniach i co do tego nie mam pytan.
Co do 1wire, to wlasnie wykrywania przy wiekszej ilosci nie mialem okazji robic.
Przy jednej pastylce nie bylo tego problemu.
1Wire to dobry przyklad do mojego pytania o przerwania.
Tam sa dosyc krytyczne zaleznosci czasowe i flaga w przerwaniu moze nie wystarczyc (przy wolnym mcu) i trzeba w INT zrobic cala obsluge zdarzenia.
Co jesli wtedy zglosza sie nowe rzeczy i nawet jak zostanie flaga, to sygnal wyzwalajacy ustanie. Zapytam o cos urzadzenie, a ono powie, ze teraz to sie ...wypchaj, bo mialem cos dla Ciebie 20ms temu, a teraz juz nie mam.
Urzadzenie musi trzyamac te dane do czasu obsluzenia i kazdy wychodzi z tego zalozenia, wiec problemu nie ma ?
Wszedłeś na wyższe warstwy abstrakcji. Jak zrobisz dobrze sprzęt i program to zadziała. Jeśli nie - to nie.
jaskol wrote:
No to musze poczytac, bo zastanawia mnie ich wyzszosc nad tym co robie zwykle - przerwanie, flaga, obsluga w petli glownej jakies inne rzeczy.
Spróbuj w ten sposób obsłużyć cokolwiek "dużego" (stos TCP/IP, system plików na wolnym medium, GUI z okienkami, ...), korzystając z gotowej biblioteki. Gotowej, czyli takiej w której wywołanie jakiejś funkcji może trwać np. 100ms, bo akurat trzeba na coś poczekać. Owszem - możesz sobie to WSZYSTKO napisać samemu, rozbijając wszystko na najmniejsze możliwe kwanty w których nie ma blokowania, a następnie jakoś to poskładać do okrutnie wielkiej pętli głównej. Może nawet będzie jakoś działać, ale NIGDY nie uda Ci się w ten sposób uzyskać "real-time", ponieważ Twoja pętla sprawdza warunki sekwencyjnie, co jeden obieg, więc jeśli flagę ustawisz tuż po jej sprawdzeniu, to musisz czekać cały cykl. W RTOS mechanizm priorytetów i wywłaszczania powoduje, że ustawienie semafora na który coś oczekuje (gdy oczywiście priorytet jest najwyższy) powoduje NATYCHMIASTOWE obsłużenie tego zdarzenia.
Do tego dochodzi znaczące uproszczenie programu, ponieważ niezależne rzeczy są w nim faktycznie niezależne - system plików nie wie nic o GUI, a GUI nie wie nic o systemie plików. Można łatwo użyć gotowych kodów które nawet mogą być blokujące (byle blokowały się na funkcjach RTOSa typu semafory, mutexy, kolejki, delaye, ...). Łatwo można uzyskać zachowanie dynamiczne (można np. obsługiwać jednocześnie 1 albo 10 transmisji, każdą w osobnym, nowo tworzonym wątku).
jaskol wrote:
Tam sa dosyc krytyczne zaleznosci czasowe i flaga w przerwaniu moze nie wystarczyc (przy wolnym mcu) i trzeba w INT zrobic cala obsluge zdarzenia.
1-wire korzystając z przerwania zewnętrznego to doskonały przykład jak tego _NIE_ robić. Poczytaj w google o 1-wire przez UART i wtedy świat stanie się prostszy (;
[W RTOS mechanizm priorytetów i wywłaszczania powoduje, że ustawienie semafora na który coś oczekuje (gdy oczywiście priorytet jest najwyższy) powoduje NATYCHMIASTOWE obsłużenie tego zdarzenia.
4\/3!!
Przy okazji tematu się coś podpytam o RTOS'a Jeżeli przełączanie kontekstów w RTOS'ie idzie z częstotliwością 1kHz, to jeśli dany wątek ustawi ten semafor na samym początku swojej pracy, to reakcja na to ustawienie będzie dopiero po przełaczeniu kontekstu (wywłaszczeniu)?
Jeśli tak, to byłaby to w najgorszym wypadku 1ms. Czy tez istnieje jakiś inny mechanizm natychmiastowego wywłaszczenia wątku po ustawieniu w/w semafora?
"Tick frequency" dotyczy jedynie przełączania zdarzeń o tym samym priorytecie które są w stanie "gotowe" (czyli w zasadzie chodzi o "round-robin scheduling"). Wszelkie* operacje na "synchronization primitives" (semafory, mutexy, kolejki, delay, sekcja krytyczna, ...) powodują natychmiastowe przełączenie kontekstu (jeśli jest ono oczywiście konieczne). Takie samo natychmiastowe przełączenie powoduje też oczywiście yield() lub podobna funkcja.
Innymi słowy - systemowy "tick" potrzebny jest tylko do przełączania zadań gdy nie ma innego bodźca do takiej akcji. Takim bodźcem jest np. odblokowanie mutexa (na którym "ktoś" jest zablokowany) czy dopisanie czegoś do kolejki (na którą "ktoś" czeka).
* - pewnym wyjątkiem są operacje na takich obiektach _W_ sekcji krytycznej oraz w przerwaniach, gdy takiego "reschedule" trzeba sobie zwykle zażyczyć wprost (np makrem portEND_SWITCHING_ISR() we FreeRTOS). W takich wypadkach trzeba zwykle używać specjalnej wersji funkcji operujących na tych obiektach.
A..no widzisz - teraz to nabiera sensu Czyli musi być jakieś przerwanie, które z dużo większą szybkością cyklicznie sprawdza stan tych wszystkich zdarzeń (semafory, mutexy,itd...) - i w razie wykrycia zmiany wyzwala odp. akcję.
Witam.
To ja wlasnie wracam po wodce z sasiadem i ledwo widze na oczy, ale jeden cel mi przyswieca. Isc spac....
Za to skoro Freddie tak pisze o tym RTOS-ie, ze on tyle moze, to i tak mi sie to sprowadza do przerwan. Cos tam bylo o natychmiastowej obsludze.
No to tylko przerwania wchodza w gre, zeby bylo natychmiastowo.
Bedzie mi sie to pewnie snilo dzisiejszej nocy, ale nic lepszego ponad przerwania mi do glowy nie przychodzi.
Kolega cos pisze o czekaniu 100ms na cos, ale ja wlasnie nie czekam, bo mam flagi.
Jak mam flage, ktorej ustawienie trwa 10us (w ASM), to jestem gosc i moge sie zajac innymi rzeczami. Nie czekam 100ms, bo to by bylo bez sensu.
Wtedy ktos wlasnie wpadl na pomysl RTOS-a. Ja robie "szybka" petle, 100us trwajaca.
Nie wiem jak by to mialo dzialac, zeby zawsze natychmiast dalo sie cos obsluzyc.
Jak jest jedno przerwanie, to obsluga iles us trwa i inne czeka.
Zatem nigdy nie mozna mowic o natychmiastowym obsluzeniu kolejnego.
Nie ma nic szybszego niz przerwania, wiec nie wiem co kolega ma na mysl piszac, ze bez RTOS-a nie obsluze niczego natychmiast.
Ja wlasnie to zrobie korzystajac z przerwan, ale i tak zawsze bedzie kilka us opznienia. Nie wiem co moze byc lepszego, szybszego, nie znam.....
Ktorys kolega napisal, ze jest jakies szybkie przerwanie, ktore sprawdza stan innych przerwan czy flag. To by mialo sens, ale znowu wracamy do punktu wyjscia, do przerwan. Nic szybszego chyba nie wymyslono. Nazwy, to marketing czy inne takie, ale mnie chodzi o sens. Wyobrazam sobie, ze zamiast w main loop, ktora trwa 100ms czekac na jej zakonczenie i wtedy sprawdzac flagi przerwan, moze zrobic przerwanie co 100us, ktore sprawdza te flagi. Na tym ma sie opierac ten RTOS ?
Tylko co dalej ?
Kiedys to trzeba obluzyc i wziac sie za nastepne zdarzenia.
Nadal nikt nie odpowiedzial na pytanie, co jesli tych zdarzen bedzie 1000 na sekunde i wolny procek. Wypadaloby zrobic jaki bufor na wszelki wypadek - albo dobrac odpowienie mcu z odpowiednim kwarcem do wlasciwego zadania.
Ide ratowac zone (ciekawe czy ktos zgadnie co mam na mysli), bo dzieci juz spia....
Pozdrawiam,
Mariusz
Dodano po 15 [minuty]:
Jado_one wrote:
A..no widzisz - teraz to nabiera sensu Czyli musi być jakieś przerwanie, które z dużo większą szybkością cyklicznie sprawdza stan tych wszystkich zdarzeń (semafor
y, mutexy,itd...) - i w razie wykrycia zmiany wyzwala odp. akcję.
Ooooo, wlasnie. Czy wszystko sie sprowadza do przerwan, bo nic szybszego nie wymyslono.
I tak ja bym to rozumial. Tylko czy slusznie ?
Czy jest jakas zaleta poza wygoda ? Oto jest pytanie...
A..no widzisz - teraz to nabiera sensu
Czyli musi być jakieś przerwanie, które z dużo większą szybkością cyklicznie sprawdza stan tych wszystkich zdarzeń (semafory, mutexy,itd...) - i w razie wykrycia zmiany wyzwala odp. akcję.
Nie ma żadnego dodatkowego przerwania... Przecież to się opiera na zwyczajnym mechanizmie zdarzeń - żaden z obiektów synchronizacyjnych nie zmienia stanu "sam z siebie" i bez powodu, tylko to Ty go przestawiasz (zwalniając mutexa, wpisując coś do kolejki, ...). Tak więc po prostu wszystkie operacje na takich obiektach na koniec zawierają - w uproszczeniu oczywiście - wywołanie funkcji typu yield(), która powoduje "reschedule" (jeśli taka operacja jest oczywiście potrzebna).
jaskol wrote:
Kolega cos pisze o czekaniu 100ms na cos, ale ja wlasnie nie czekam, bo mam flagi.
Albo za dużo tej wódki, albo niezbyt dokładnie przeczytałeś to co napisałem. Obsłuż system plików, stos TCP/IP, duże GUI albo coś tego kalibru to zobaczymy czy Twoja pętla dalej będzie tak szybka, a Twoje podejście z flagami takie proste jak to opisujesz. Wydaje mi się, że spora część niezrozumienia wynika z tego, że - nie oceniam tylko stwierdzam fakt - Twoje programy na PIC w assemblerze nigdy nie otarły się o poziom skomplikowania programów które ja miałem na myśli - takich w których wielowątkowy RTOS ma sens i uzasadnienie.
jaskol wrote:
Nie wiem jak by to mialo dzialac, zeby zawsze natychmiast dalo sie cos obsluzyc.
jaskol wrote:
Nie ma nic szybszego niz przerwania, wiec nie wiem co kolega ma na mysl piszac, ze bez RTOS-a nie obsluze niczego natychmiast.
Ja wlasnie to zrobie korzystajac z przerwan, ale i tak zawsze bedzie kilka us opznienia. Nie wiem co moze byc lepszego, szybszego, nie znam.....
No to może najpierw się dowiedz, a dopiero potem przekonuj mnie że RTOSy są bez sensu i nie mają prawa dobrze działać? RTOS to RTOS, przerwania to przerwania - każde służy do czegoś innego.
jaskol wrote:
Ooooo, wlasnie. Czy wszystko sie sprowadza do przerwan, bo nic szybszego nie wymyslono.
I tak ja bym to rozumial. Tylko czy slusznie ?
Nie, całkowicie błędnie.
jaskol wrote:
Czy jest jakas zaleta poza wygoda ?
Czy wygoda nie jest powodem dla którego chcesz się przesiadać z assemblera na C? Przecież nie zaprzeczysz, że w assemblerze DA SIĘ zrobić wszystko, w końcu każdy język programowania tłumaczony jest ostatecznie do assemblera, a nie do voodoo... Tak więc czy jest jakaś zaleta używania C poza wygodą?
W skrócie RTOS każda literka jest istotna. Tutaj definitywnie ignorujesz literkę S oznaczającą System. RTOS nie ma sensu i uzasadnienia w urządzeniu które robi jedną "rzecz", za to w systemie, który realizuje wiele niepowiązanych ze sobą funkcji to już zupełnie inna sprawa.
Nie ma żadnego dodatkowego przerwania... Przecież to się opiera na zwyczajnym mechanizmie zdarzeń - żaden z obiektów synchronizacyjnych nie zmienia stanu "sam z siebie" i bez powodu, tylko to Ty go przestawiasz (zwalniając mutexa, wpisując coś do kolejki, ...). Tak więc po prostu wszystkie operacje na takich obiektach na koniec zawierają - w uproszczeniu oczywiście - wywołanie funkcji typu yield(), która powoduje "reschedule" (jeśli taka operacja jest oczywiście potrzebna).
4\/3!!
No teraz wszystko jasne Ok - nie będziemy zaśmiecać wątku Koledze.
W razie czego inny wątek
Nie ma żadnego dodatkowego przerwania... Przecież to się opiera na zwyczajnym mechanizmie zdarzeń - żaden z obiektów synchronizacyjnych nie zmienia stanu "sam z siebie" i bez powodu, tylko to Ty go przestawiasz (zwalniając mutexa, wpisując coś do kolejki, ...). Tak więc po prostu wszystkie operacje na takich obiektach na koniec zawierają - w uproszczeniu oczywiście - wywołanie funkcji typu yield(), która powoduje "reschedule" (jeśli taka operacja jest oczywiście potrzebna).
Zatem co miales na mysli i przy uzyciu jakiego mechanizmu cos ma sie wykonywac natychmiast, a moje przerwania nie ?
Chodzi mi o wartwe sprzetowa, chociaz tak teraz mysle, ze chyba za bardzo sie skupiam na urzadzeniach. Sa jeszcze jakies rzeczy do policzenia, zmierzenia, itd., ktore sie dzieja w tle i trwaja. Przetwornik to nadal sprzet i jak skonczy mierzyc, to zglosi przerwanie. Za to nie wiem i moze tutaj mam problem czy mozna zrobic jakies nowe "zadanie", ktore musi cos policzyc i ono przeciez przerwania nie zglosi.
Moze tylko ustawic jakas flage, ktora bede co jakis czas sprawdzal.
Tylko, ze to nigdy nie bedzie natychmiast. Tego nie rozumiem w Twojej wypowiedzi - jakim sposobem RTOS zrobi cos natychmiast ? Jesli to prawda, to rzeczywiscie bylaby przewaga na innymi rozwiazaniami, ale ja nie znam niczego szybszego od przerwan. Brakuje mi jakiejs niewiadomej w tym rownaniu, a mam podany wynik.
jaskol wrote:
Kolega cos pisze o czekaniu 100ms na cos, ale ja wlasnie nie czekam, bo mam flagi.
Freddie Chopin wrote:
Albo za dużo tej wódki, albo niezbyt dokładnie przeczytałeś to co napisałem. Obsłuż system plików, stos TCP/IP, duże GUI albo coś tego kalibru to zobaczymy czy Twoja pętla dalej będzie tak szybka, a Twoje podejście z flagami takie proste jak to opisujesz. Wydaje mi się, że spora część niezrozumienia wynika z tego, że - nie oceniam tylko stwierdzam fakt - Twoje programy na PIC w assemblerze nigdy nie otarły się o poziom skomplikowania programów które ja miałem na myśli - takich w których wielowątkowy RTOS ma sens i uzasadnienie.
Ja juz wstalem, ze to gorzej z zona. Nie wiem co ona pila, ale zaczynam sie martwic..
Tez tak podejrzewalem i chyba nawet dalem temu wyraz.
Nie robilem niczego tak skomplikowanego, co by pokazalo niedostatki moich metod.
Odczyt z karty SD, w trakcie trwania odczytu...tak mam sobie to wyobrazic, ze nagle dochodzi obsluzenie LCD i ktos tutaj musi byc poszkodowany, tak ?
No to moze 1wire bedzie juz najlepszym przykladem.
Wiadomo, ze tam sie licza us i nie mozna czegos pozniej zrobic.
Ja normalnie "czekam" ze wszystkim, az nie skoncze z 1wire, bo raz, ze trwa to szybko, a dwa ze jak nie zdaze "wrocic" z innych zadan, to wszystko przepadnie.
Chcesz powiedziec, ze w RTOS bede w tym samym czasie czytal z magistrali 1wire, wysylam cos po RS485 i w tym czasie odbieral pakiety z jakiegos CC1000 ?
Hm, brzmi super. Tylko, ze nie wiem jak mialoby to byc zrealizowane bez opierania sie na przerwaniach. Ja bym to wlasnie nimi zalatwil, gdybym musial. Tyle, ze nie mialem az takich potrzeb, zeby skakac po calym programie i patrzec co komu potrzebne. Jednym slowem taki RTOS pewnie jest nieodzowny w tablecie czy innym telefonie, ale czy zaraz w jakims urzadzeniu przemyslowym ?
Zastanawia mnie to wszystko, bo staram sie znalezc dla niego zastosowanie w moich warunkach i moze go zwyczajnie nie byc. Co nie znaczy, ze nie jest super i pewnie wiele osob nie widzi bez niego szans na realizacje swoich zadan.
Ciagle jednak nie rozumiem co znaczy, ze on wykonuje wszystko "natychmiast"...
i wcale nie opiera sie na przerwaniach.
jaskol wrote:
Nie wiem jak by to mialo dzialac, zeby zawsze natychmiast dalo sie cos obsluzyc.
Freddie Chopin wrote:
No to może najpierw się dowiedz, a dopiero potem przekonuj mnie że RTOSy są bez sensu i nie mają prawa dobrze działać? RTOS to RTOS, przerwania to przerwania - każde służy do czegoś innego.
Nie prawda, ze twierdze, iz nie maja prawda dzialac, bo przeciez sa i ludzie z nich korzystaja. Nie powiedzialem tez nigdzie, ze sa bez sensu. Przesadzasz.
Ooooo, wlasnie. Czy wszystko sie sprowadza do przerwan, bo nic szybszego nie wymyslono. I tak ja bym to rozumial. Tylko czy slusznie ?
Freddie Chopin wrote:
Nie, całkowicie błędnie.
A, to wszystko wyjasnia...
jaskol wrote:
Czy jest jakas zaleta poza wygoda ?
Freddie Chopin wrote:
Czy wygoda nie jest powodem dla którego chcesz się przesiadać z assemblera na C? Przecież nie zaprzeczysz, że w assemblerze DA SIĘ zrobić wszystko, w końcu każdy język programowania tłumaczony jest ostatecznie do assemblera, a nie do voodoo... Tak więc czy jest jakaś zaleta używania C poza wygodą?
Wygoda, ktora daje szybkosc. No i to bym zrozumial, ze RTOS daje wygode i wiele innych rzeczy. Z tym sie pogodze, ze moje rozwiazania tego mi nie dadza.
Za to przedstawiles argument, ze RTOS obsluzy mi moje "rzeczy" natychmiast.
I to mi nie daje spokoju, to to bylby koronny argument na to, ze jest cos wiecej niz wygoda, ze warto mi to zastosowac. Chodzi o to jedno slowo. Jesli to "natychmiast" wynosi 1ms np. przy zegarze 20MHz w PIC, to takie natychmiast mnie nie powala i pewnie nie warto mi tego stosowac.
Moje natychmiast zajmuje kilka us i RTOS mi nie bedzie potrzebny.
Czuje, ze to jest forma "ubrania" i uporzadkowania zadan, kore realizuje Twoj program. Gdyby nie powstal RTOS, to kazdy by musial napisac swoj, wiec ktos wpadl na pomysl, zeby zrobic ogolne narzedzie.
Ja w swoich programach dzialalem podobnie, a czy to sie nazwie flaga czy semaforem, to kwestia drugorzedna. Byl timer i przerwanie od niego, sprawdzanie flag i reakcja. Nawet przy krytycznych czasowo procesach dalo sie przezyc.
Pewnie przy 10 czy 20 zadaniach zaczyna sie robic goraco, a przy 200 juz w ogole nikt by nie wiedzial co sie dzieje. W RTOS jest ladnie, przejrzyscie i jeszcze sa narzedzia do sprawdzania ile mamy taskow i takie tam. Ogolnie fajne jak sie ma duzo rzeczy do zrelizowania.
Nadal twierdze, ze nie bedzie to natychmiastowe, bo u mnie to zalezy od tego przerwania od timera, a w RTOS tez cos musi sledzic te zadania....
Pozdrawiam,
Mariusz
Dodano po 2 [minuty]:
Jado_one wrote:
Freddie Chopin wrote:
Nie ma żadnego dodatkowego przerwania... Przecież to się opiera na zwyczajnym mechanizmie zdarzeń - żaden z obiektów synchronizacyjnych nie zmienia stanu "sam z siebie" i bez powodu, tylko to Ty go przestawiasz (zwalniając mutexa, wpisując coś do kolejki, ...). Tak więc po prostu wszystkie operacje na takich obiektach na koniec zawierają - w uproszczeniu oczywiście - wywołanie funkcji typu yield(), która powoduje "reschedule" (jeśli taka operacja jest oczywiście potrzebna).
4\/3!!
No teraz wszystko jasne Ok - nie będziemy zaśmiecać wątku Koledze.
W razie czego inny wątek
Sam go zasmiecam najbardziej, ale poki moze trwac....prosze sie nie krepowac.
Nigdy nie wiadomo, co sie komus kiedys przyda.
I to mi nie daje spokoju, to to bylby koronny argument na to, ze jest cos wiecej niz wygoda, ze warto mi to zastosowac. Chodzi o to jedno slowo. Jesli to "natychmiast" wynosi 1ms np. przy zegarze 20MHz w PIC, to takie natychmiast mnie nie powala i pewnie nie warto mi tego stosowac.
Kolega Freddie Chopin już o tym pisał. Jest coś takiego jak wywłaszanie. Jak obsługa przerwania będzie zaimplementowana poprawnie to czas obsługi zdarzeia będzie wynosił:
czas obsługi przerwania + czas przełączenia kontekstu. Po powrocie z przerwania program natychmiast obsłuży kolejkę, którą zapełoniono w przerwaniu. Jak wszystko będzie poprawnie zaimplementowane to czas ten będzie dużo mniejszy niż 1ms.
No to moze 1wire bedzie juz najlepszym przykladem.
Wiadomo, ze tam sie licza us i nie mozna czegos pozniej zrobic.
Chyba najgorszym - już pisałem, że do obsługi 1-wire należy użyć UARTu.
jaskol wrote:
Tylko, ze to nigdy nie bedzie natychmiast. Tego nie rozumiem w Twojej wypowiedzi - jakim sposobem RTOS zrobi cos natychmiast ? Jesli to prawda, to rzeczywiscie bylaby przewaga na innymi rozwiazaniami, ale ja nie znam niczego szybszego od przerwan. Brakuje mi jakiejs niewiadomej w tym rownaniu, a mam podany wynik.
Po prostu musisz zacząć od założenia, że świat nie kończy się na "obsłudze" trwającej 1us. Równie dobrze "obsługa" może trwać 27 minut i może się jej nie dać podzielić łatwo na nieblokujące fragmenty. Powiedzmy że masz policzyć FFT z ogromnej liczby próbek - to trwa, ręczne dzielenie algorytmu na krótkie fragmenty ma mały sens (bo on na nic nie czeka, tylko liczy), a do tego jeśli nie jesteś matematykiem to niekoniecznie jest takie proste. No i teraz powiedz mi jak wpasujesz takiego kalibru procesy (kilka) z których dane pochodzą z przerwań (kilku), które mają określone priorytety w "pętlę główną", a jak w RTOSa. Bo wg mnie coś takiego Ci tą pętlę główną rozwali całkowicie, bo Twój program będzie wtedy przez długi czas powieszony na obsłudze jednej rzeczy (i nie reagujesz na nic), a do tego w ogóle nie jesteś w stanie uwzględnić priorytetów. Tymczasem używając RTOSa, wątków i kolejek te wszystkie wymagania są spełnione "z założenia".
Powiem to tak... Znacząca większość wzorów fizycznych czy matematycznych jest wyprowadzonych na podstawie całkowania i pochodnych. Jednak w szkole zaczyna się od wprowadzenia tych wzorów bez wytłumaczenia skąd się wzięły, pewnie czasem jedynie jest przedstawiony dowód że są poprawne. Pochodne są dopiero w liceum, a całki dopiero na studiach. Tym samym po prostu pogódź się z tym, że dla osoby która pisała programy w assemblerze na tak mały mikrokontroler jak PICe coś takiego jak RTOS jest po prostu zbyt wysoką abstrakcją aby zobaczyć wszystkie zalety wątków i wszystkie wady "pętli głównej". Po prostu musisz napisać jakiś duży program korzystając ze znanej sobie "pętli głównej" i zobaczyć jak cudownie się w tym zakopiesz i jak dużo czasu poświęcisz na sprawienie żeby to zadziałało jak trzeba (priorytety, responsywność, niegubienie zdarzeń, ...) - jeśli w ogóle Ci się to uda... Ja zajmowałem się ARMami od kilku lat zanim pierwszy raz użyłem RTOSa...
Zresztą RTOS to nie jedyna rzecz do której trzeba dojrzeć (bez oceny, po prostu nie można od tego zacząć od razu - trzeba na własnej skórze przekonać się o wadach innych opcjach). To samo można powiedzieć o programowaniu obiektowym (czyli w naszym świecie mikrokontrolerów o C++), o rozproszonych mechanizmach typu publish-subscribe, o różnych konstruktach dynamicznych, ... No o wszystkim co jest postrzegane jako "wyższa szkoła jazdy".
Na koniec zaś - RTOS nie ma żadnej przewagi nad rozwiązaniem "ręcznym" poza wygodą - wszystkie pozostałe zalety są tylko następstwem tej pierwszej (; W końcu RTOS nie używa voodoo, więc ten sam (albo i lepszy) efekt można osiągnąć pisząc ręcznie rozwiązanie "szyte na miarę". Tak samo jak patrząc w ten sposób C nie ma zalet nad assemblerem, a programowanie obiektowe - nad programowaniem niskopoziomowym. Jednocześnie mikrokontrolery nie mają specjalnej przewagi nad dyskretnymi bramkami logicznymi, a te zaś - nad tranzystorami...
Na koniec raz jeszcze - wątki nie zawsze mają sens. Tam gdzie jest jedno zadanie lub zadania są ze sobą ściśle powiązane (np. akwizycja, obróbka, zapis - 3 zadania, ale w zasadzie jedna "sekwencja") da się osiągnąć taki sam stopień złożoności (albo raczej prostoty) kodu bez wątków. Za to gdy zadań jest wiele i nie mają one ze sobą praktycznie nic wspólnego (poza - oczywiście - działaniem na jednym sprzęcie) to wątki są rozwiązaniem wielu problemów. Np gdyby do poprzedniego urządzenia dorzucić prezentację zapisanych danych zarówno przez stronę WWW jak i przez graficzny interfejs, a akwizycja nie dotyczyła jednej wielkości tylko wielu (i niekoniecznie stałej ich ilości) które nie są ze sobą powiązane (bo pochodzą z różnych źródeł a więc i różnych czujników).
To samo można powiedzieć o programowaniu obiektowym (czyli w naszym świecie mikrokontrolerów o C++)
4\/3!!
Ostatnio tak spoglądam "łakomym okiem" na C++ - czy mi się dobrze zdaje, że kod napisany w tym języku jest jeszcze łatwiej "przenaszalny" niż pisany w C? (myślę o tym w kontekście pracy raz na procesorach typu PIC32, a raz ARM - póki co kod daje się przenosić bez większego problemu, (o ile zasoby sprzętowe pozwalają na analogiczną funkcje w danym procesorze jak w drugim), ale fragmenty bezpośrednio odwołujące się do rejestrów procesora muszą być już oddzielnymi plikami.
Postęp w tworzeniu nowych procesorów będzie trwał dalej - jak wiadomo - ale dobrze napisane, niezależne od sprzętu kody mogą dalej służyć w kolejnych projektach.
Na ile pisząc w językach wyższego poziomu zbliżamy się już do samego zapisu algorytmu? Zwłaszcza kontekście RealTime i mikrokontrolerów.
Czy przejście na C++ jest bardzo "bolesne"? Widziałem na jednym z forów, że ktoś pokazywał, że kod wygenerowany w C++ nie musi być wcale większy niż w C - ale trzeba już nieźle wiedzieć "o co chodzi", żeby dobrze sobie taki kod zoptymalizować.
Jak się ma szybkość wykonywania takiego kodu w stosunku do C?
Co do faktu między C a C++ to zależy też od pisanego kodu równie dobrze ktoś napisze kod w C++ i będzie działał szybciej niż jak ktoś inny napisze to w C. Używanie C++ może być ok, ale pod warunkiem że też używa się z głową, bo już na przykład użycie funkcji wirtualnych, dziedziczenia, może trochę spowolnić kod i zajmować więcej pamięci, dla takich funkcji wirtualnych musi być przecież vtable, więc no.
W C też da się napisać łatwo przenaszalny kod. Przejście na C++ jest jak przejście na cokolwiek innego - składnia jak składnia. Problemem jest zmiana idei, kod obiektowy to nie kod strukturalny. Chociaż patrząc na kody umieszczone w internecie może się wydawać, że jest zupełnie na odwrót. To za sprawką tego, że 80% osób używających języka obiektowego nie wie jak pisać obiektowo. Spotkałem się ze sporą ilością osób piszących w językach obiektowych i naprawdę mało kto wie jak poprawnie pisać programy obiektowo. Oczywiście też są pewne rzeczy, które nie nadają się na obiektowość, bo nie wszystko jesteśmy stanie/jest sens modelować obiektowo
Co do narzutu - ciężko to zmierzyć. Możesz w C++ napisać kod, który będzie się szybciej wykonywał niż kod napisany w C. Narzut jest raczej marginalny.
Widziałem na jednym z forów, że ktoś pokazywał, że kod wygenerowany w C++ nie musi być wcale większy niż w C - ale trzeba już nieźle wiedzieć "o co chodzi", żeby dobrze sobie taki kod zoptymalizować.
Jak się ma szybkość wykonywania takiego kodu w stosunku do C?
To są wszystko mity... Kod w C++ zajmuje tyle ile musi zajmować - ciężko oczekiwać, że możesz sobie np. użyć wyjątków i one zajmą 10 bajtów, albo że używanie funkcji wirtualnych spowoduje zerowy narzut. Tak wiec rzeczy w C++ zajmują tyle ile zajmować muszą. Jeśli ma się jako-takie pojęcie o tym jak te mechanizm działają "pod maską", to zajmują dokładnie tyle ile wychodzi z takiej analizy. Przykładowo:
- dziedziczenie bez funkcji wirtualnych - nic [; ,
- funkcje wirtualne - jeden wskaźnik na vtable na obiekt, jedna vtable na klasę w sekcji .text (wskaźnik na funkcję * ilość funkcji wirtualnych w klasie), narzut na prędkość wywołania to podwójna dereferencja wskaźników i wywołanie pośrednie,
- template'y zajmują tyle miejsca ile funkcje zrobione ręcznie,
- wyjątki - dosyć sporo danych w sekcji .text służących do "zwijania" funkcji (kilkanaście-kilkadziesiąt kB - zależnie od stopnia skomplikowania programu),
- dynamiczna alokacja - tyle co malloc()/free() + niewielki kod obsługi braku pamięci (albo wyjątek albo wywołanie abort()),
- ...
Jak masz pytanie o konkretną funkcjonalność C++ to mogę spróbować odpowiedzieć, ale potrzebuję konkretnego pytania, bo wiadomo że to jest temat na godziny dyskusji (;
Cała "różnica" w wielkości kodu pomiędzy C a C++ polega zapewne na tym, że takie kody po prostu nie są takie same funkcjonalnie - gdyby były to różnica wynosiłaby zero (; Pisząc w C++ piszesz obiektowo, program ma bardziej "obiektową" strukturę, starasz się używać fajnych rzeczy itd. Tak samo zresztą można napisać program obiektowy korzystając z C - z pewnymi wyjątkami można osiągnąć to samo co w C++ - wtedy analogiczny funkcjonalnie kod w C++ będzie zajmował praktycznie tyle samo (różnica będzie wynikać z tych wyjątków, ale nie powinna być wielka).
Bardzo wysoki stopień uniwersalności i przenośności można osiągnąć korzystając z funkcji wirtualnych, a dokładniej z klas interfejsowych (pure-virtual), implementacja dla konkretnego układu pochodzi wtedy z BSP i w kodzie używasz jedynie niebezpośrednich odwołań (wskaźnik/referencja). Narzut jest niewielki i całkowicie akceptowalny. Wydaje mi się, że właśnie o to pytałeś i takie rozwiązanie Cię interesuje. Zamiast funkcji wirtualnych można się pokusić o inne rozwiązania, ale są one dosyć problematyczne logistycznie (np. tzw. statyczny polimorfizm pozwoliłby na prawie to samo, ale wtedy "include paths" całego projektu są strasznie rozbudowane, a do tego jeszcze brak możliwości enkapsulacji/abstrakcji sprzętu [to ciężko wytłumaczyć, ale mogę spróbować]).
Główną "bolączką" jest jednak co innego - podejście obiektowe oczywiście wymaga obiektów (cóż za odkrycie!), więc często np. tworzysz obiekt LCD który zawiera dane zarówno stałe jak i zmienne. No i teraz przy programowaniu proceduralnym te zmienne dla kompilatora nie mają ze sobą nic wspólnego, więc stałe lądują w ROM, a zmienne w RAM. W przypadku obiektu jest inaczej - wystarczy jeden nie-stały bajt, konstruktor lub destruktor aby całość wylądowała w RAM. Wydaje mi się, że wiele "mitów" pochodzi właśnie stąd. Ten "problem" rozwiązuję osobiście zwykle tak, że obiekt składa się z dwóch części - stałej i zmiennej, jedne kawałek (zewnętrzny) zawiera referencję do drugiego (wewnętrznego). To czy zewnętrzny jest stały czy zmienny zależy od tego czy klasa potrzebuje konstruktora i/lub destruktora. Jest to niewielka niedogodność, ale ogranicza się ona do momentu tworzenia obiektów i odwołań do "drugiego kawałka" w funkcjach wewnętrznych obiektu. Generalnie opcja ta sprawdza się całkiem dobrze. Innym rozwiązaniem, jednak nie zawsze możliwym, jest używanie "static" przy stałych wchodzących w skład obiektu. Kiedyś pytałem o ten problem na stackoverflow - gdy narodziła się u mnie idea split-object - więc możesz prześledzić inne opcje http://stackoverflow.com/questions/14838284/is-there-a-nice-way-to-create-split-object-in-c
Swoją drogą - podstawową ideą do "narodzin" bleeding-edge-toolchain jest C++ - po prostu w GCC jest tylko jedna rzecz której bardzo ciężko się pozbyć - wyjątki. Żeby się ich pozbyć całkowicie trzeba mieć przekompilowane libstdc++ i libsupc++.
Generalnie mógłbym o tym pisać długo, bo ostatnio wszystko robię w C++, więc najlepiej konkretne pytanie zadaj, bo inaczej to mogę tylko filozofować, a niekoniecznie mi to wychodzi (; .\
To co byście polecili dobrego do nauki C++ w kontekście mikrokontrolerów?
Mam takie książki jak "C++ Primer Plus" i "Thinking in C++", ale patrząc na objętość (1200+ stron) to włos się trochę jeży Jest może jakiś fajny kurs w internecie?
Co do faktu między C a C++ to zależy też od pisanego kodu równie dobrze ktoś napisze kod w C++ i będzie działał szybciej niż jak ktoś inny napisze to w C. Używanie C++ może być ok, ale pod warunkiem że też używa się z głową, bo już na przykład użycie funkcji wirtualnych, dziedziczenia, może trochę spowolnić kod i zajmować więcej pamięci, dla takich funkcji wirtualnych musi być przecież vtable, więc no.
No właśnie o tym mówiłem (; Potworny narzut funkcji wirtualnych już pokrótce opisałem powyżej, ale teraz szczegółowo (wszystkie rozmiary przy założeniu architektury 32-bitowej):
- 4 bajty na obiekt - wskaźnik na vtable, jest to wartość stała, więc jeśli obiekt jest ROM-able to dalej taki będzie,
- (4 bajty * ilość funkcji wirtualnych w klasie) na każdą klasę (z funkcjami wirtualnymi oczywiście) wykorzystywaną w programie - vtable, wszystko ląduje w ROM,
- wywołanie jest nieco wolniejsze, ponieważ potrzebne jest pobranie adresu vtable z obiektu (dereferencja wskaźnika), pobranie adresu funkcji z vtable (dereferencja wskaźnika z offsetem), a samo wywołanie jest pośrednie (wywołanie funkcji spod wskaźnika).
Tak więc owszem, narzut nie jest zerowy. Moim zdaniem jednak jest on marginalny, bo wywołanie funkcji trwa może kilka cykli zegara dłużej (stawiam na mniej niż 10), a 4 bajty na obiekt i kilka-kilkanaście w ROM na klasę to tyle co nic. Zresztą - tak jak napisałem wcześniej - chcąc mieć taką abstrakcję jak oferują funkcje wirtualne - raczej ciężko oczekiwać tego za darmo. Robiąc to samo w C narzut będzie identyczny.
W moich programach (na mikrokontrolery oczywiście) są SETKI obiektów z funkcjami wirtualnymi. Uważam to za jedną z najważniejszych rzeczy programowania obiektowego. Bez tego w zasadzie ma ono mały sens.
Dodano po 4 [minuty]:
Jado_one wrote:
To co byście polecili dobrego do nauki C++ w kontekście mikrokontrolerów?
Mam takie książki jak "C++ Primer Plus" i "Thinking in C++", ale patrząc na objętość (1200+ stron) to włos się trochę jeży
Jest może jakiś fajny kurs w internecie?
C++ jest potężnym językiem - zarówno w kwestii objętości jak i możliwości (; Cudów nie ma... C to może 1/100 objętości C++ <:
Nic nie zastąpi własnego doświadczenia i własnych prób - ja wielokrotnie próbowałem i wielokrotnie się zrażałem - za którymś razem w końcu mnie wciągnęło (; Jednak jeśli dla oszczędzenia kilku bajtów zrobisz wszystko to C++ nie jest dla Ciebie...
No i bleeding-edge-toolchain wskazany (; Jakby co to najlepiej założyć o tym nowy wątek, jest w C++ kilka pułapek w które łatwo wpaść, a które w sumie łatwo ominąć, tak samo jak jest kilka tricków które warto stosować. No i oczywiście są pewne rzeczy których raczej nie warto używać <:
Freddie, co myślisz o języku D dla mikrokontrolerów? Widziałem, że jakiś czas temu interesowałeś się tym tematem na forum języka D. Udało m się skompilować toolchain oraz odpalić bibliotekę drundime. Z tego co wiem jeszcze nie wszystkie funkcjonalności biblioteki runtime są przeportowane. Odpaliłem też kilka przykładów. Warto się pakować w ten język ?
