Elektroda.pl
Elektroda.pl
X
Elektroda.pl
PCBway
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Wiele wejść - tablica prawdy. Jak rozwiązać kwestie zależności ?

13 Sty 2013 11:31 8601 55
  • Poziom 12  
    Witam.
    Chcialem zrobic urzadzenie podobne do inteligentnego domu czy alarmu.
    Wiele wejsc i wyjsc (np. 256). Wszystko pisze w ASM dla PIC16 lub PIC18.
    Pomijajac kwestie skomplikowania i ogarniecia wzrokiem (czytelnosc) wszystkiego dla asemblera zastanawiam sie jak to robia znawcy ;)

    Czuje podskornie, ze musi byc jakas wielka tablica, ktora ma zdefiniowane zaleznosci w rodzaju jesli wejscie 1 ma stan 1, to wyjscie 1 wlacz na 10 sekund, wyjscie 2 wlacz na 2 minuty, zacznij odliczac 20 sekund i wlacz wyjscie 3, itd.
    Troche mnie glowa rozbolala po kilku linijkach kodu, bo rzucilem sie od razu na wiele wejsc, a chyba musze zaczac od jednego i pozniej przez analogie rozszerzac to na wiecej. Nadal przeraza mnie jednak mysl, ze zrobie pozniej jakies makro (1 wejscie wlaczy kilka wyjsc) i chcialbym zeby jedno makro wlaczalo inne makra....pewnie kolejna tablica zaleznosci.
    Prosze o pomysly, ale jesli ktos robil cos podobnego, to prosze zaznaczyc, zebym wiedzial, ze to sprawdzone rozwiazanie.

    Pozdrawiam,
    Mariusz
  • PCBway
  • Moderator Mikrokontrolery Projektowanie
    A ten assembler to wybrałeś z powodu skłonności do masochizmu?
    Poczytaj o automatach stanu, jedna z implementacji wykorzystuje tablice, której wymiary to stan automatu i zdarzenie. Na wskazanej przez nie pozyvcji możesz umieścić np. funkcję, która realizuje obsługę odpowiedzi na zdarzenie przy danym stanie automatu.
  • Poziom 12  
    Witam.
    Temat rzeka.
    C jesli jest darmowe, to przez chwile, pozniej nie dziala optymalizacja i kod zajmuje polowe pamieci. Nauczylem sie wszystko robic w ASM i probowalem w C,ale mnie "trafialo". Zdaje sobie sprawe, ze pewnie nigdy nie zrobie nic z USB, bo wszystko jest gotowe tylko w C, wlasciwie sie nie dziwie. Za to ethernet prawie zrobilem w ASM, ale nie dokonczylem (przynajmniej wiem, ze sie da ;) ), wiec kto wie...moze i USB kiedys, jakims cudem....jak juz dzieci beda duze.
    Moj problem bardziej polega na tym, ze nie uzywam niczego napisanego przez kogos i patrze z zazdroscia jak 10 latek kupuje sobie zestaw startowy, sciaga wszystko gotowe, przerabia 4 linijki w Bascom-ie czy innym takim i ma cos, co mnie po glowie chodzi od lat, ale pisalbym to przez miesiac. Nie mam tyle czasu, wiec nie robie wcale.
    Za to ten sprzet z wejsciami chce zrobic, chocby to mial zajac pol roku.
    Automaty pamietam ze studiow, ale mnie bardziej chodzi o praktyke.
    Licze na podpowiedz typu:
    - wlaczasz timer, wystawia flage, wtedy to i to..
    Czy lepiej sprawdzac wejscie i jego stan na biezaco, czy moze korzystaniej jest
    przeczytac stan wszystkich wejsc i pozniej podejmowac akcje ?
    Rozum mowi, ze lepsze to pierwsze, ale .... nie mam doswiadczenia, a ktos pewnie ma.
    Wlasciwie wiem jak to by mialo dzialac, ale w teorii.
    Teraz bardziej mi zalezy na podpowiedzi praktycznej, teoria automatow jest dobra na kartke, olowek i kolokwium. Pytanie jak zrobic implementacje w mcu, w praktyce.
    Dzieki za pomoc, poszukam moze w google realizacji takich automatow na badzie mcu.
    Jesli chodzi o sprzet, to uzyje RS-485, jeden master, reszta slave, multiplesowanie wejsc, master pyta - reszta odpowiada po kolei. Pozniej to rozbuduje o wiecej roznych modulow - pomiar temperatury, jakis nadajnik GSM, itd.
    Uzyje ukladu do RS-485 z obsluga 128 albo i 256 adresow (urzadzen).
    Nie sa wcale drogie. Martwia mnie tylko opoznienia. Pewnie lepszy bedzie jakis hub, ktory zapyta od razu np. 24 urzadzenia i wtedy master zapyta hub-y o stany - bedzie szybciej, bo master ma rozne inne zadania, na ktore bedzie mial wtedy wiecej czasu.
    Zwykla centrala alarmowa tak dziala, Satel mnie zainspirowal, bo montuje ich centrale. Maja jakas swoja magistrale, ale po co kombinowac - RS485 jest w tym wypadku najlepszy. To jest piekne, ze wejscie moze miec np. 48 roznych wariantow (zwykle, opoznione, taki i owakie). To samo z wyjsciami.
    Jak to wszystko opanowac "myslac" jeszcze o timerach po drodze i operacjach logicznyhc uzytkownika typu OR, AND, itd, ktore user sam definiuje.
    To musi byc jakas ogrooooomna tablica, tak podejrzewam, ale zamiast zmarnowac pol roku na implementacje, ktora bedzie kiepska, chcialem sie dowiedziec jak to robia inni.

    Pozdrawiam,
    Mariusz
  • Moderator Mikrokontrolery Projektowanie
    Dlatego zapytałem o ten asm. Rozumiem, że na PICe jest problem z kompilatorami, ale dlaczego nie zmienić w takim razie MCU na AVR lub ARM? Masz kompilatory i środowiska pełnosprawne za darmo. Dzięki temu nie będziesz tracił czasu na wyważanie otwartych drzwi, typu implementacja stosu TCP/IP, skoro są dziesiątki gotowych. Nawet napisanie tego w asm to nie problem, ale potem testowanie...
    Wracając do podstawowego problemu. To IMHO największa zaleta maszyn stanu, że sobie to rysujesz na kartce, teraz zamień kartkę na jakiś program do rysowania diagramów UML, najlepiej powiązany z IDE i mały kroczek dzieli cię od rysunków na kartce do gotowego programu. To czy stan wejść leiej sprawdzać w przerwaniu, czy nie to zależy od potrzeb i możliwości MCU, można go tak skonfigurować, aby zmiana stanu IO generowała przerwanie. W takim przerwaniu odczytujesz tablicę automatu stanu, z wiersza odpowiadającego bieżącemu zdarzeniu odczytujesz np. adres funkcji przejścia, która zapewnia ci reakcję na zdarzenie i ew. zmianę stanu automatu. To jedna z prostszych implementacji. Inna możliwość to zastosowanie list i drzew. O tyle fajne, że struktura drzewa odzwierciedla wprost diagram UML. Przy takiej implementacji zmiana funkcji logicznej to po prostu zmiana wskaźnika do funkcji realizującej przejście/zmiana struktury drzewa. Pozornie jest to skomplikowane ale w większych projektach zapewnia dużą przejrzystość kodu i łatwość jego modyfikacji.
  • Użytkownik usunął konto  
  • PCBway
  • Poziom 20  
    Może sposób programowania logiki w centralach pożarowych seri fp2000 i 1200 firmy aritech kolegę zainspiruje. Tablica logiczna w tych centralach posiada taką funkcjonalność jak kolega zakłada i po kilku przemyśleniach może okazać się bardzo prosta w implementacji. Ogólnie polega to na tym że są 3 tablice: wejść, wyjść i logiki. W 2 pierwszych są zapisane informacje odnośnie rodzaju wejścia-wyjścia (nie tylko fizyczne ale np aktywacja wyjścia włącza jakiś stan w centralce) i przyporządkowywuje mu indywidualny numer po którym można łatwo użyć w logice. W trzeciej tablicy jest zapisana logika. Składa się z trzech pól: operator, operand i numer wejścia-wyjścia. I teraz jeżeli chcemy wysterować 2 wyjścia z jednego wejścia robimy coś takiego: jako operator wstawiamy "jeżeli", operand to "wejście" a pod numer podajemy numer wejścia w tablicy wejść. W następnym wierszu tablicy podajemy kolejno "to", "wyjście", "numer wyjścia 1",
    kolejny wiersz to: "I" "wyjście" "numer wyjścia 2". I teraz program przemiata kolejno wszystkie wiersze i trafia na te nasze trzy, w pierwszym widzi że będziemy sprawdzać wejście więc sprawdza parametry tego wejścia w tablicy wejść czy zgodnie z jego konfiguracją jego stan jest aktywny, przechodzi do następnego pola i tam widzi że wysterowywane jest wyjście więc sprawdza w tabilcy wyjść jak ono jest skonfigurowane(tutaj w konfiguracji można na przykład zamieścić informację o opóźnieniach,czasach, rodzaj itp.) i je ustawia w stan aktywny, i tak samo w kolejnym wierszu. Niestety te rozwiązanie mimo względnej prostoty ma jedną zasadniczą wadę, mianowicie potrzebuje dużo pamięci i jest stosunkowo wolne. Ale może to będzie dla kolegi jakimś punktem odniesienia.

    Pozdrawiam
  • Poziom 12  
    tmf napisał:

    dlaczego nie zmienić w takim razie MCU na AVR lub ARM? Masz kompilatory i środowiska pełnosprawne za darmo.


    Jestem juz na to za stary. Cale zycie asm, a zmieniac mcu z racji jezyka bym nie
    chcial - mam tak malo czasu, ze wolalbym sie skupic na algorytmie, bo reszte dobrze znam.
    Balem sie sporu swiatopogladowego na tym tle, ale na szczescie jest merytorycznie.
    Poki co ;)
    Robilem podejscie do AVR, kupilem jakis programator i napisalem kilka linijek w ASM, ale o C juz nie myslalem. Zawsze czlowieka korci, zeby sie doskonalic i moc dobierac swobodnie narzedzia do celow, ale przyjmijmy, ze jestem ograniczony i musze to zrobic w ASM dla PIC-ow. Swoja droga dowiedzialem sie od Ciebie, ze C dla AVR-ow jest darmowe i bez ograniczen - a tego nie wiedzialem i troche mi dales do myslenia...

    tmf napisał:

    Dzięki temu nie będziesz tracił czasu na wyważanie otwartych drzwi, typu implementacja stosu TCP/IP, skoro są dziesiątki gotowych. Nawet napisanie tego w asm to nie problem, ale potem testowanie...


    Taka mam niestety wade fabryczna, ze musze sam. Cierpie z tego powodu strasznie, ale do tego nie umiem tez pracowac zespolowo (pewnie jedno wynika z drugiego). Dlatego zamykam sie sam ze sprzetem na strychu i siedze tygodniami, az nie napisze programowej obslugi wszystkiego co sie da I2C, RS, SPI, i co tam jeszcze wymyslili. Zamiast sie skupic na tym co chce zrobic...Za to jak juz to napisze, to wiem jak to dziala i skad sie wzielo. Inaczej zwyczajnie nie potrafie.
    Zaladowac biblioteke i juz ? Tak sie nie godzi ;) Wiec brne i brne....przypadek beznadziejny.

    tmf napisał:

    że sobie to rysujesz na kartce, teraz zamień kartkę na jakiś program do rysowania diagramów UML

    Tylko, ze nie wyobrazam sobie rysowania tylu stanow na papierze.
    Kazde wejscie moze reagowac na stan, albo na zbocze.
    Chce rozrozniac czas trwania danego stanu na wejsciu, itd.
    Nie jestem malkontentem, ale chyba brakuje mi wyobrazni, zeby narysowac graf na pol pokoju. Za to wierze, ze siadam, pisze kod, robie symulacje i poprawiam.
    Tak robia Ci, ktorzy nie potrafia planowac, musza dzialac :(

    tmf napisał:

    To czy stan wejść leiej sprawdzać w przerwaniu, czy nie to zależy od potrzeb i możliwości MCU,

    O, i to jest tez ciekawe. Lekki przeskok, ale to mnie tez frapuje.
    Myslalem, zeby jednak stany sprawdzac w petli glownej, bo wlasciwie to bedzie podstawowe zadanie mastera. On ma panowac nad tym co sie dzieje, a jakby mial obslugiwac przerwania dla roznych zdarzen, to moglby nie nadazyc. Trudno teraz powiedziec ile trwalaby obsluga najdluzszego przerwania, ale chyba wolalbym je zostawic na "krotka" obsluge.
    Np. wysylam do jakiegos modulu rozkaz pomiaru temperatury i niech sobie ja mierzy i 300ms czy 500ms, bo ja bede wszystkie moduly odpytywal w czasie 200ms i jak ktorys cos bedzie mial dla mastera, to mu to "da", a jak nie...to nie.
    Za to w przerwaniu bylyby potwierdzenia np. wysylam rozkaz nadania sms-a przez modul GSM, on sobie wysyla i wysyla...a jak skonczy, to wysle krotka ramke "udalo sie". Wlasciwie to sie zastanawiam, czy w ogole do tego wykorzystywac przerwania, bo tam nie bedzie super krytycznych zaleznosci czasowych.
    Za to zastanawia mnie problem komunikacji z PC i przerwan.
    Jesli mcu bedzie zajety komunikacja z PC, bo kaze mu np. wyslac logi z calego roku, to bez sprzetowej obslugi handshaking sie nie obejdzie. Chcialbym, zeby master nadal dzialal bez uszczerbku na szybkosci, a w wolnych chwilach rozmawial z PC. Gdybym wrzucil w przerwanie komunikacje z PC, ustawil flage, ze trzeba wyslac do PC kilka tysiecy bajtow i zaczal wysylac, to :
    - bez przerwan
    co jakis czas musialbym zglaszac PC-towi, zeby sie wstrzymal, odpytac moduly, wrocic do komunikacji - niby ok
    - z przerwaniami
    kto wie jak kiedy i gdzie musialbym zrobic to co wyzej ;)

    Intuicyjnie przerwania dadza mi wieksza swobode, ale czy nie zostawic ich na lokalna obsluge RTC i innych takich, a moduly pytac "jak mi sie zachce" ?

    Teraz mi sie tylko nasuwa, ze dla przerwan, w idealnych warunkach (wszyscy milcza) komunikacja z PC bylaby w 100% plynna. Wejscia niczego nie generuja, rozmawiam z PC na "100% mocy". Bez przerwan musialbym zawsze przerywac komunikacje z komputerem i to byloby wada.

    Tylko, ze skoro to architektura z jednym masterem, to reszta siedzi cicho i nie wywoluje zadnych przerwan. Jesli mialyby to robic, to zaczynaja sie problemy chociazby z kolizjami. Slave nagle moglby sam nadawac komunikaty. Tego nie planowalem. Niech cos gdzies "zginie" i po robocie. Pewnie, ze mozna zaimplementowac powtorzenia i inne mechanizmy poprawiajace niezawodnosc, ale czy warto tak to komplikowac ?

    O, mam przyklad.
    A taka dajmy na to zmiana temperatury. Modulow jest 256 i kazdy ma termometr, tak standardowo, zawsze sie przyda. I pytajac moduly co jakis czas mam w miare aktualna temperature zebrana od wszystkich. Przy przerwaniach mcu bylby ciagle zajety, bo np. kazda zmiana o 0,5 stopnia generowalaby juz przerwanie.

    Pozdrawiam,
    Mariusz

    Dodano po 22 [minuty]:

    albertb napisał:

    "A co z drugą połową" - jak masz małe dzieci to wiesz skąd to.
    Nie widzę więc problemu.


    Chlopaku, 2 malych dzieci, zona nie pracuje i jestem w szoku, bo od 4 lat
    siedzi caly czas w domu i ....wychowuje. Zajecie procesora w 90%.
    Reszta to obiady, sprzatanie i na zycie zostaje jej moze 1%.
    Nie moge od niej wiecej wymagac, bo czasami cos projektuje i wtedy dzieci wstepu nie maja, siedza z mama na okraglo, bo "tata pracuje".

    albertb napisał:

    Jak coś w teorii jest dobre, to dlaczego miałoby nie być w praktyce?
    Twój błędny sposób myślenia jest szeroko rozpowszechniony tutaj.

    Wlasnie napisalem wczesniej, ze w teorii to jest proste, ale jak narysowac na papierze np. 550 stanow ?
    Albo pytajac inaczej - czy warto poswiecac ten czas na zawalenie pokoju kartkami, skoro mozna od razu usiasc i wymyslec ?
    Ja juz wymyslilem, ale zastanawiam sie czy nie mozna lepiej. Stad ten watek.
    Bywalem, ze robilem cos, co inni zrobili prosciej, bo ... to i owo.
    Moze i moje mialo wiecej zalet, ale i tak z nich nie korzystalem, a narobilem sie jak wol.

    albertb napisał:

    A podpowiedź praktyczna? Skorzystasz z niej czy i tak zrobisz po swojemu ;-)

    :) Widze, ze znasz ten typ osobowosci.
    Jestem silnie przekonany, ze mam racje, to fakt... ale czekam na Mesjasza, ktory sie pojawi i powie:
    - nawet dobrze kombinujesz, ale zauwaz, ze jesli ...to i tamto, to wlasciwie bedziesz mial to samo, a zobacz, ze zyskasz to i tamto.
    Na studiach tak bylo - jesli sie trafilo na normalnego wykladowce.
    Burak dawal pale i mowil, ze tak sie nie robi...bo mozna inaczej.
    Madry mowil, ze niepotrzebnie sie Pan tak napracowal, bo wystarczy zauwazyc, ze to i to nigdy sie nie wydarzy i z Pana 3 kartek A4 robi sie pol kartki ;)
    Pamietam jak przerwaniami zalatwilem jakies zadanie na egzaminie, a ludzie sie meczyli. Takich jak ja bylo 3 na roku, reszta sie meczyla.
    Tylko, ze dla mnie Bogami byli Ci, ktorym sie to udalo rozwiazac rysujac graf na kilka kartek. Ja po 2 kartkach wystrzelalem sie po twarzy i pomyslalem, ze albo to jest chamstwo straszne ze strony jakiegos dotoranta, albo chcial cos przez to powiedziec. Przerwanie zalatwilo wszystko w kliku krokach, ale i tak dla mnie zwyciezcami byli Ci, ktorzy umieli to doprowadzic grafami do konca.
    To nic, ze prawie nikt nie zdal, bo juz nie mial czasu na inne zadania ;) Takie zycie.
    Dlatego jak mi ktos w punkach napisze jak to widzi i bedzie to zawieralo elementy mi obce, ktore do mnie przemowia...to oczywiscie, ze zrobie jak mowi.
    Nie bede sie glupio upieral, ze wiem lepiej.

    Jakies grafy i stany sa fajne jak masz 0 lub 1, ale nie mam takiej wyobrazni, zeby to przelozyc w locie na timery, zbocza, czasy trwania i inne.
    Wiadomo, ze sprowadza sie to do odczytu 0/1, ale jak zrealizowac warstwe wyzsza ? Czy tabelami jakimis ? Jak je w locie rozbudowywac ?
    Szukam przewodnika we mgle ;)
    Jak nie znajde, to zrobie po swojemu.

    Pozdrawiam,
    Mariusz
  • Moderator Mikrokontrolery Projektowanie
    Dlatego właśnie zaproponowałem ci tabelę, aby nie rysować wykresów na kilka stron, z identycznymi zależnościami. Tak naprawdę czy masz 100 modułów np. pomiaru temperatury, czy jeden, to maszyna stanów wygląda praktycznie tak samo. Zdarzeniem nie jest 100xinfo z każdego modułu, tylko info, że temp. się zmieniła. Jeśli masz 10 różnych typów modułów i każdy wywołuje np. 4 zdarzenia to raptem masz 10 tablic, nic wielkiego. Przejrzyściej byłoby to napisać w C++ jako klasy. Zdarzeniem nie musi być też bezpośrednio sygnał podawany na wejście - może on być przetwarzany przez oddzielną maszynę stanów, która będzie dopiero generowała eventy dla kolejnej. Taki podział ogranicza liczbę zdarzeń i upraszcza projektowanie. No i pamiętaj, że po to wymyślono UML, aby nie bazgrać po kartkach :)
    Co do przerwań i zajętości procesora - możesz to komplikować i zrobić np. RTOS, wtedy np. komunikacja z PC to byłby jeden z wątków. To samo osiągniesz przerwaniami - PC nie oczekuje przecież stałego strumienia danych, to nie tryb izosynchroniczny USB :) PC czeka na kolejne znaki przesyłane po RS, jak są to je odbiera, jak ich nie ma to czeka, ew. się timeoutuje po jakimś czasie. Dane dla pewności przesyłasz w ramkach i wtedy w ogóle kłopotu nie ma.
    Co do odpytywania modułów - jakoś sobie tego nie wyobrażam. Idąc za twoim przykładem, jeśli masz 256 modułów pomiaru temperatury, to czas ich kolejnego odpytywania jest długi i generuje spory ruch na magistrali, obciąża także MCU. Jeśli moduł sam zgłasza, że coś istotnego się wydarzyło, to MCU komunikuje się wyłącznie z nim i nie traci czasu na odpytanie 255 modułów, których stan nie uległ zmianie. To oczywiście wymaga implementacji protokołu multimaster, a tu może się okazać, że zamiast RS485 lepiej wykorzystać CAN. CAN implementuje całą warstwę fizyczną i większość warstw logicznych protokołu, co rozwiązuje wiele problemów. Zauważ, że odpytywanie modułów ma jeszcze jedną wadę - moduły nie mogą usypiać. Praktycznie co chwilę master będzie je wybudzał, zupełnie bez powodu.
    Także ja na twoim miejscu jednak zacząłbym od projektowania, chyba, że wyznajesz zasadę, że "miesiące kodowania mogą zaoszczędzić godzin projektowania" :) No i obawiam się, że przy na tyle złożonym projekcie czas nauki C i zrobienia tego w C, będzie krótszy niż napisanie tego w asmie.
    BTW, zadania które wymieniłeś (transfer danych, odpowiedź na zdarzenia, RTC itd.) w przypadku sensownie napisanego programu nie obciążą zbytnio MCU. Z drugiej strony nie wiem jakimi peryferiami dysponują PICe, a tu posiadanie odpowiednich peryferii może być kluczowe.
  • Poziom 12  
    daniel6662 napisał:
    Może sposób programowania logiki w centralach pożarowych seri fp2000 i 1200 firmy aritech kolegę zainspiruje.

    Nie mialem przyjemnosci, ale kolega mi opowiadal, ze go chcialo trafic przy programowaniu tego i ze Satel zrobil to milion razy lepiej.
    Juz o tym kiedys myslalem i to by moglo sprawdzic, ale na etapie koncowym.
    Mam juz algorytm na wszystko co chce i nagle zapragnalem wprowadzic zaleznosci logiczne. Wtedy pewnie moglbym zrobic taka "tablice prawdy".
    Tylko, ze jestem dopiero na poczatku drogi ;)
    Dzieki za podpowiedz, gromadze "rozumki", na pewno sie to przyda.

    P.S.
    Gdyby isc tym tropem, to ...
    Wejscie moze reagowac na stan lub na zbocze. Ma tez jakas czulosc.
    To sa juz 3 parametry. Zatem tworze tablice z 3 kolumnami. W kazdej mam w wierszach kolejne wejscia. W kolumnie mam dana wlasciwosc.
    Tylko co dalej.
    Wiem, ze np. wejscie 1 ma reagowac na stan 0.
    Czytam wejscia i widze, ze jest 1 czyli to wejscie omijam, bo nic sie nie dzieje.
    Przy 2 wejsciu to samo, ale czytam, ze jest akurat 0, czyli to wejscie ma cos zrobic.
    Co to juz mowi niestety jakas inna tablica.
    Niech mowi np. ze mam wlaczyc wyjscie 6.
    Teraz musi byc jeszcze tablica dla wyjsc, zeby bylo np. wiadomo jak dlugo wyjscie ma byc aktywne.

    Teraz gwozdz programu.
    Robie iloczyn poszczegolnych komorek i jesli mam 1, to warunek reakcji jest spelniony ? Tez nie do konca. Jesli wejscie musi byc aktywne przez 10ms (taka ma ustawiona czulosc), to musze gdzies po drodze to mierzyc.
    Innymi slowy kazda wlasciwosc wejscia musze obliczac i wstawiac wartosc do tablicy stanow typu "realtime", mnozyc ze stala tablica wlasciwosci i jestli bedzie "1", to patrzec co z tym zrobic (czy i ktore wyjscie wlaczyc).

    Jak zrobic sledzienie czulosci 256 wejsc ?
    Dla uproszczenia niech beda 2 czulosci. 100ms i 1000ms.
    Zwieram druty (wejscie daje 1), wpisuje do tablicy i przeciez nie uzyje 256 timerow zeby to sledzic.
    Moge zwiekszac jakis licznik co np. 50 ms. Timer dziala w kolko, a ja mam kolejna tablice i jesli wejscie = "1", to wpisuje do tablicy aktualna wartosc licznika (wartosc startowa) i dopoki wejscie ="1", to zapisuje ciagle wartosc licznika do kolejnej komorki w tablicy dotyczacej timerow. Pozniej sprawdzam i jesli wejscie nadal = "1" i timer aktualny - timer start >= czulosc, to mam spelniony warunek.

    Ciekawe czy tak robia inni, czy nie jest to slepa uliczka.
    Tablca tablicę tablicą pogania. Az mi sie nie chce tego testowac, chyba, ze ktos mnie przekona, ze to dobre rozwiazanie.

    Pozdrawiam,
    Mariusz
  • Poziom 26  
    Może próbkuj wejście w przerwaniu od timera z jakąś częstotliwością np., co 20ms. Jeśli przez 5 okresów wejście się nie zmieni, uznaj je za jedynkę.

    Generalnie spróbowałbym to zaimplementować w formie rejestru przesuwającego taktowanego z jakiejś zadanej częstotliwości, który jeśli ma na wyjściach te same wartości daje odpowiedni sygnał.

    Jeśli potrzebujesz okresu 1s, to albo możesz poszerzyć rejestr, albo próbkować rzadziej. Nawet z wykorzystaniem jednego timera - można przecież programowo podzielić ten okres przez uzależenienie go od jakiejś inkrementowanej zmiennej.

    Możliwości jest generalnie sporo, zależy co dokładnie chce uzyskać.
    I mimo wszystko odradzam ASMa bo kontrola tak dużej ilości danych będzie po prostu uciążliwa.

    pozdrawiam
  • Poziom 20  
    jaskol napisał:
    Nie mialem przyjemnosci, ale kolega mi opowiadal, ze go chcialo trafic przy programowaniu tego i ze Satel zrobil to milion razy lepiej.

    Satel nie ma w ofercie central pożarowych, taka mała uwaga:) Co do samej przyjemności central to faktycznie do przyjemnych zadań nie należy ale to kwestia oprogramowania a nie mechanizmu działania który jest bardzo łatwy w implementacji i co najważniejsze intuicyjny jak się zrozumie jego działanie.

    jaskol napisał:
    Ciekawe czy tak robia inni, czy nie jest to slepa uliczka.
    Tablca tablicę tablicą pogania. Az mi sie nie chce tego testowac, chyba, ze ktos mnie przekona, ze to dobre rozwiazanie.

    Podałem Ci już przykład jak to robi aritech w centralach pożarowych. Tablice masz w zasadzie tylko 3 i program na bieżąco sprawdza tylko jedną, Tablice logiki, leci od wiersza do wiersz i dopiero gdy napotka że musi sprawdzić wejście to dopiero sprawdza tablicę wejść. jak napotka wyjście to sprawdza dany numer wyjścia. Takie podejście do tematu jest moim zdaniem bardzo elastyczne i ma duże możliwości rozbudowy, z tym że jak wspomniałem wcześniej jest mało wydajne i do obsługi tego potrzebny jest szybki procek i sporo pamięci.
    W Twoim wypadku gdy sterować chcesz tak dużą ilością we-wy i żeby to się odbywało z sensowną prędkością poszedłbym raczej w stronę ARM, nie zależnie od wybranego rozwiązania.
    Pozdrawiam
  • Moderator Mikrokontrolery Projektowanie
    jaskol napisał:
    Jestem juz na to za stary. Cale zycie asm, a zmieniac mcu z racji jezyka bym nie chcial - mam tak malo czasu, ze wolalbym sie skupic na algorytmie, bo reszte dobrze znam.

    Balem sie sporu swiatopogladowego na tym tle, ale na szczescie jest merytorycznie.
    Poki co ;)

    Robilem podejscie do AVR, kupilem jakis programator i napisalem kilka linijek w ASM, ale o C juz nie myslalem.

    Programując INTEL 8035 w assemblerze (koniec lat 80'tych), nie miałem wyjścia, gdyż była to wtedy jedyna możliwość. Teraz stosując C napiszę to samo w znacznie krótszym czasie, a ewentualna modyfikacja oprogramowania (co w Twoim przypadku będzie bardzo istotne), jest o wiele łatwiejsza.

    Nie bój się nowości - tutaj na forum zawsze znajdziesz osoby, które Ci pomogą w razie problemów. A zacząć możesz z wykorzystaniem CManiac'a: http://mikrokontrolery.blogspot.com/2011/02/kurs-jezyka-c-spis-tresci.html
  • Poziom 12  
    tmf napisał:

    Tak naprawdę czy masz 100 modułów np. pomiaru temperatury, czy jeden, to maszyna stanów wygląda praktycznie tak samo.

    To jedyne pocieszenie.

    tmf napisał:

    masz 10 tablic, nic wielkiego.

    Zazdroszcze Ci, bo mnie wlasnie takie rzeczy mentalnie ograniczaja.
    Zrobic 10 tablic w RAM....
    Juz wiem, ze mi go braknie i bede musial zapiac jakis zewnetrzny SRAM do tych celow. Z EEPROMu zewnetrznego bede kopiowal przy starcie wszystkie tablice do SRAM i pozniej dzilal juz na niej.
    Teraz widze, ze mieszam czesc sprzetowa z algorytmem i dla Ciebie graf, to graf i da sie to zrobic bez problemu, ale ja juz widze, ze u mnie przejscie ze stanu do stanu to nie goly warunek tylko jakis time, zbocze i inne takie. Przez to nie widze calosci, bo rozbijam wszystko na "boki" zamiast sie skupic na nurcie glownym.
    Chyba zostawie to na noc, we snie sobie to poukladam i moze bedzie lzej.

    tmf napisał:

    No i pamiętaj, że po to wymyślono UML, aby nie bazgrać po kartkach :)

    I pewnie jest do tego nawet jakis soft, ale dla jednego takiego projektu...
    Narysuje sobie graf, niech bedzie, ale co dalej ?
    Dlatego rozpoaczalem watek o tym, jak to przeniesc juz do mcu.
    Umowmy sie, ze jest graf, mam tylko kilka stanow.
    I pojdzmy dalej, jesli to mozliwe ;)

    tmf napisał:

    Co do przerwań i zajętości procesora - możesz to komplikować i zrobić np. RTOS,

    Nie nie, zmory przeszlosci. Wszyscy teraz daja jakiegos ARM-a z linux-em i jak te dzieci 10-letnie, ktorym zazdroszcze....robia kosmiczne sprzety ;) Tego juz nie dogonie, nawet sie nie ludze.
    Kiedys mnie kusilo, ale gotowego nie chce, a sam sobie zrobie cos pseudo na przerwaniach i moze mniej dumnie nazwe, ale bedzie robili to co chce.
    Tylko czy skonczy sie na wersji z przerwaniami ? Tego jeszcze nie wiem.
    Pewnie jak nie zrobie prototypu i sie nie przekonam, to bedzie bez.

    tmf napisał:

    wtedy np. komunikacja z PC to byłby jeden z wątków. To samo osiągniesz przerwaniami - PC nie oczekuje przecież stałego strumienia danych, to nie tryb izosynchroniczny USB :) PC czeka na kolejne znaki przesyłane po RS, jak są to je odbiera, jak ich nie ma to czeka, ew. się timeoutuje po jakimś czasie. Dane dla pewności przesyłasz w ramkach i wtedy w ogóle kłopotu nie ma.

    Ostatnio udalo mi sie napisac bootloader z RS-232 dla PIC16 i nie mialem sily lutowac kabli do sprzetowych potwierdzen, wiec pierwszy raz wykorzystalem XON/XOFF. O dziwo zadzialalo, ale nie bez klopotow. Trzeba idealnie trafic ze sterowaniem, bo jak sie spozni, to wszystko sie sypie. Teraz mnie olsnilo, ze to moze jeszcze zalezec od konkretnego PC, bo roznie to bywa..i chyba jednak nie bede tego uzywal.
    Teraz robilem taki licznik z pamiecia do zliczania ludzi i jak ma wyslac do PC zawartosc AT24C128, to wysyla w 2 sekundy, a PC dopiero po 4 "wraca do zywych". Testuje do programem Docklight, bo jest bardzo wygodny...ale jak sie przesiadlem na innego PC-ta, to nagle mam komunikat, ze program lub port w PC nie nadaza i czesc transmisji moze byc wadliwa. Nie uzywam zadnej kontroli transmisji, wprowadzam jedynie drobne opoznienie, zeby PC w ogole nie zawisnal.
    Sprawdze bootload-er, ale wlasnie mnie olsnilo, ze moze sie tez wysypac...

    tmf napisał:

    jeśli masz 256 modułów pomiaru temperatury, to czas ich kolejnego odpytywania jest długi i generuje spory ruch na magistrali, obciąża także MCU.


    Zalozenie jest takie, ze to beda jakies "drobne" bajty.
    START | ADDR | COM | BYTE7-BYTE0 | CRC | STOP
    Taki sobie ModBUS z okrojona suma CRC, 13 bajtow powinno wystarczyc.
    Przy zalozeniu, ze warstwa fizyczna to RS-232 + konwerter RS485, to mamy
    10 bitow do reprezentacji 1 bajtu, czyli 13 bajtow = 130 bitow.
    Przy predkosci 9600 bodow mamy 9600/130 = 73 transmisje w ciagu sekundy.
    Malo.
    No to 19200 bodow i mamy 147 transmisji w ciagu sekudny.
    Brnac dalej - zamiast 19200 zrobie 38400. Wtedy mam 295 transmisji czyli ok, ale i tak cienko, bo naciskajac guzik moge miec zwloke 1s i to nie bedzie dobre :(

    Przy zalozeniu, ze sie nie pomylilem liczac na szybko i ze to tylko teoria, a nic nie odpowie przeciez natychmiast, to rzeczywiscie nie wyglada najlepiej....

    Czyli trzeba zrobic hub-y, ktore podziela siec na segmenty np. po 24 urzadzenia.
    Przy 256 urzadzeniach mam 11 hub-ow. Odpytanie wszystkich zajmie mi jakies 100ms i to juz ma sens.

    tmf napisał:

    uległ zmianie. To oczywiście wymaga implementacji protokołu multimaster, a tu może się okazać, że zamiast RS485 lepiej wykorzystać CAN.

    Montowalem kiedys taki system firmy F&F, straszny badziew.
    To nie wina magistrali CAN, ktora tam zastosowali, ale ich wykonawstwa.
    Wystarczy wspomniec, ze dali wszedzie plastikowe gniazda RJ45 i jakos w sieciach nigdy nie mialem z tym problemow, a u nich co wtyczka, to inaczej pasowala. Co sie ruszylo kabelkiem, to po komunikacji. Za 10 wlozeniem wtyczki dopiero cos sie dobrze ukladalo w gniezdzie i jakos dzialalo....przez chwile.
    Zawsze wiedzalem, ze w przemysle tylko zlacza srubowe sie licza, a ten przypadek tylko mnie w tym utwierdzil.
    Pomysle o CAN, ale nic na tym jeszcze nie robilem, znowu przegryzanie sie prze dokumentacje...i nadal nie bede nad tym panowal jak cos pojdzie zle.
    No chyba, ze to jest naprawde idealne i samo za mnie wszystko zrobi, pakiety powtorzy, CRC policzy, itd. Sprawdze ;)

    tmf napisał:

    Także ja na twoim miejscu jednak zacząłbym od projektowania, chyba, że wyznajesz zasadę, że "miesiące kodowania mogą zaoszczędzić godzin projektowania" :)


    Jak tak siebie obserwuje przez lata, to niestety trafiles w 10 :(

    tmf napisał:

    No i obawiam się, że przy na tyle złożonym projekcie czas nauki C i zrobienia tego w C, będzie krótszy niż napisanie tego w asmie.


    Zalezy ktore C. Jesli na PIC, to nawet mi sie nie chce zaczynac, bo jak mam placic za cos, co moze mi sie juz nigdy nie przydac, to pewnie sie nie skusze.
    Jak mam sie przesiadac na AVR czy ARM, to musialbym sie wrocic do zlobka, a jak juz wspomnialem, chyba jestem na to za stary ;)

    Za to w ASM mam wszystko w glowie, siadam i pisze.
    I jaka radosc, ze kazdy bit jest "moj" i robi to co chce, a program zajmuje 20% pamieci i reszte moge poswiecic na generowanie muzyczki dla usera ;)
    Kupilem ostatnio modul radia z RDS, z I2C, kostka 5mmx5mm.
    Zrobie na tym radio, 10 sztuk. Wlasnie jako taki modul na magistrale.
    Pokazujesz na ekranie co gdzie ma grac (w ktorym pomieszczeniu) i gra.
    Tylko musze opanowac te czesc, o ktorej dyskutujemy.
    Zmusiles mnie jednak do tego, zeby zaraz wpisal AVR +C +examples i chociaz zobaczyl co napisali.

    tmf napisał:

    drugiej strony nie wiem jakimi peryferiami dysponują PICe


    Mnie sie przyda tylko sprzetowy RS-232, bo to dobrze dziala.
    Reszta jest zbedna. RAM-u i tak nigdy nie wystarczy, ethernet tez zrobie "z boku" chociazby z racji RAM-u, RTC takze.
    Z drugiej strony patrzylem na najlepsze PIC-e i wlasciwie tylko ethernet by odpadl, bo go maja, a pamieci (RAM) i tak bedzie za malo. Zawsze jest za malo ;)
    Chyba, ze ten CAN by sie tutaj sprawdzil, to sa takie, ktore maja w sobie.....

    Dzieki za pomoc,
    ciekawe co jeszcze wymyslimy.

    Mariusz

    Dodano po 18 [minuty]:

    daniel6662 napisał:

    Satel nie ma w ofercie central pożarowych, taka mała uwaga:)


    Jasne, to taki malo czytelny skrot myslowy ;)
    Chodzilo o sama zasade programowania.
    A tak w ogole, to maja maja...tylko sie nie chwala.
    Pewnie za moment cos wypuszcza, wiem, ze pracuja nad jakas taka centrala PPOŻ, chociaz nie wiem po co, bo ma byc "mala". Male to robi Polon-Alfa...tez.

    daniel6662 napisał:

    Tablice masz w zasadzie tylko 3 i program na bieżąco sprawdza tylko jedną,


    Sprawdza, czyli tworzy kolejna, do ktorej zapisuje aktualny stan.
    Moglby w locie, ale ja potrzebuje jeszcze dane historyczne.
    Skad mam wiedziec, ze nastapila zmiana stanu z 0 na 1 (wyzwalanie zboczem), jesli nie wiem co bylo wczesniej.
    Czyli nawet 2 tablice extra. Jedna jako historia, a druga z aktualnymi wartosciami.
    To dopiero mnoze z tablica "wlasciwosci".

    daniel6662 napisał:

    odbywało z sensowną prędkością poszedłbym raczej w stronę ARM, nie zależnie od wybranego rozwiązania.


    To moze poskromie apetyt i zadowole sie 128 wejsciami, a w ostatecznosci podziele siec na hub-y i tyle. Satel tez ma na plycie max. 16 wejsc, a reszte przez zewnetrzne moduly, czyli w moim wypadku hub-y. Wiecej klockow, ale dalbym rade "byle czym".

    Pozdrawiam,
    Mariusz

    Dodano po 28 [minuty]:

    CAN ? Do 1Mbit przy 40 metrach, a pozniej max. 250k przy max. 350 metrach.
    To jednak CAN odpada. Pewnie sa jakies wzmacniacze, ale po co ?
    Do do samochodow zrobili, tam 40m to moze w tirze bedzie...albo do samolotu (jesli zmiejsza predkosc). 350 metrow moze by wystarczylo, ale 250kbps, to osiagne na kilometrze przy RS-485.
    No ale nie ma tego zlego.
    Chyba kolega wlasnie mnie zmusil mimochodem do zabawy z arbitrazem i innymi takimi, to moze byc wyzwanie !

    Pozdrawiam,
    Mariusz
  • Moderator Mikrokontrolery Projektowanie
    Nie wiem dlaczego uważasz, że jesteś za stary na zmiany. Na zmiany to z pewnością za późno dla nieboszczyka, pozostali ciągle mają szansę :)
    Po pierwsze zacznij od projektu, żeby nie wyszły w czasie programowania kwatki takie jak powyżej z tym odpytywaniem, gdzie sam doszłeś do tego, że pomysł marny. Mając projekt łatwiej dobrać MCU. Tu też nie wiem dlaczego zakładasz, że zabraknie SRAMu i będzie potrzebny zewnętrzny... Nie znam PICów, dlatego piszę o AVR (czego nie traktuj jako próby nawrócenia na tą rodzinę), ale np. są AVRy, które mają 16-32 kB wewnętrznej pamięci SRAM, co IMHO do takiego projektu wystarczy. Zawsze też można dać zewnętrzny FLASH/FRAM szeregowy, co łatwiej podłączyć niż normalną równoległą kostkę, a dostęp po SPI nie jest jakoś dużo wolniejszy.
    Co do transmisji - to też bym sobie rozpisał za i przeciw RS485 vs. CAN. Są MCU z kontrolerem CAN na pokładzie, kontroler załatwia praktycznie całą transmisję, pozostaje tylko obsługa błędów, no i ... przygotowanie danych. Po CAN masz multimaster z automatu, więc żadne odpytywania/huby nie są potrzebne. Ale to tylko idea. Rzuć też okiem na protokół ZigBee - nie chodzi mi o to, że to wireless, ale jak rozwiązano problemy komunikacji. Naprawdę przemyślana implementacja i warto to potraktować jako wzór.
    Teraz wracając do tych stanów. Dla mnie eventem będzie np. aktywny poziom sygnału, aktywny przez 100ms, aktywny przez 500ms, nieaktywny. Te 4 eventy może produkować zupełnie inna maszyna stanów, związana bezpośrednio z IO, ona ma się martwić o detekcję czasów, zmian, itd. W efekcie masz tak: tablica w której jeden wymiar to eventy, drugi to stany. Na przecięciu masz np. funkcję przejścia. Event na danym stanie wywołuje tą funkcję, a ona dba o zmianę stanu - w szczególności sprawdzenie np. inych sygnałów, czy warunków przejścia. W efekcie zmiana reakcji na event to tylko zmiana funkcji (wskaźnika) na danej pozycji tablicy. To wszystko. Oczywiście implementacja w oparciu o tablice jest pamięciożerna. Dlatego oszczędniejsze (acz trochę bardziej skomplikowane w oprogramowaniu) jest zrobienie tego samego w oparciu o drzewa. Wtedy pamięci masz zużyte tylko tyle ile masz akcji + mały nadmiar na organizację struktury drzewa. Dla typowego alarmu nie sądzę aby to było więcej niż kilkaset bajtów, a najpewniej mniej. Bo masz prostą tranzycję - event np. aktywacja czujki na dowolnej linii-> alarm. Co najwyżej drugi - aktywacja czujki ->opóźnienie -> alarm. Dla eventów tego samego typu można dodać maski, co też znacząco zmniejszy zapotrzebowanie na pamięć. Np. masz 256 linii czujek, to dla każdego eventu 256 bitów. Robisz iloczyn logiczny eventu i maski i dopiero z wynikiem wchodzisz do tabeli stanów.
    Co do UMLa - z Eclipse są zintegrowane softy do UML, jeśli piszesz w c to z diagramu same ci zrobią pewne elementy programu. Ale to istotnie trochę wyższa szkoła c/UML i niestety naprawdę dobry soft kosztuje. Ale nawet bez takiej integracji warto.
    No i jeszcze o tym RS232. Coś musiałeś mieć skopane. Robię transmisję prawie 1 Mbps po USART AVR-PC i nie ma problemów najmniejszych z gubieniem czegokolwiek. Odwrotnie PC-AVR pewien problem by był (ale korzystam z DMA dostęnego w XMEGA i też problemu nie ma). RS232 jest protokołem asynchronicznym i start bajtu następuje po wysłaniu bitu startu. Jasne, że któraś ze stron może nie nadążać (raczej nie będzie to PC), dlatego dzielę transmisję na ramki, po każdej ramce odbiór kwitowany jest ACK + CRC ramki. Nie ma ACKa w zadanym czasie to robię retransmisję. Ze sprzętowej kontroli przepływu nigdy nie korzystałem (chociażby dlatego, że AVR jej nie ma:) ). Ale tez nigdy nie było mi to potrzebne.

    Dodano po 4 [minuty]:

    jaskol napisał:


    CAN ? Do 1Mbit przy 40 metrach, a pozniej max. 250k przy max. 350 metrach.
    To jednak CAN odpada. Pewnie sa jakies wzmacniacze, ale po co ?
    Do do samochodow zrobili, tam 40m to moze w tirze bedzie...albo do samolotu (jesli zmiejsza predkosc). 350 metrow moze by wystarczylo, ale 250kbps, to osiagne na kilometrze przy RS-485.
    No ale nie ma tego zlego.
    Chyba kolega wlasnie mnie zmusil mimochodem do zabawy z arbitrazem i innymi takimi, to moze byc wyzwanie !

    Pozdrawiam,
    Mariusz


    To prawda, CAN jest magistralą ze stanem recesywnym i stąd nie jest tak szybki. Ale dzięki temu, że masz multimaster, transmisja będzie tylko wtedy kiedy zajdzie jakieś zdarzenie. Najpewniej raz na kilka sekund :) W efekcie nawet 9600 bps na CAN da ci mniejszą latencję odpowiedzi na zdarzenia niż 250 kbps na RS485 z odpytywaniem, co zresztą już policzyłeś :) Oczywiście CAN to koszta, z drugiej strony multimaster można dodać też i do RS485.
  • Poziom 20  
    jaskol napisał:
    A tak w ogole, to maja maja...tylko sie nie chwala.
    Pewnie za moment cos wypuszcza, wiem, ze pracuja nad jakas taka centrala PPOŻ, chociaz nie wiem po co, bo ma byc "mala". Male to robi Polon-Alfa...tez.


    Satel ma jedynie centralki oddymiania i to na dodatek nie swojej produkcji tylko D+H.
    Swoją drogą miło by było zobaczyć jakąś centrale ppoż od satela, zawsze mi się dobrze na ich sprzęcie pracowało. Fakt Polon produkuję centralki ale cenowo Polon wypada kiepsko w porównaniu do np. wspomnianego wcześniej Aritecha, ale przynajmniej człowiek wie za co płaci. To tak poza tematem :)

    tmf napisał:
    No i jeszcze o tym RS232. Coś musiałeś mieć skopane. Robię transmisję prawie 1 Mbps po USART AVR-PC i nie ma problemów najmniejszych z gubieniem czegokolwiek. Odwrotnie PC-AVR pewien problem by był (ale korzystam z DMA dostęnego w XMEGA i też problemu nie ma). RS232 jest protokołem asynchronicznym i start bajtu następuje po wysłaniu bitu startu. Jasne, że któraś ze stron może nie nadążać (raczej nie będzie to PC), dlatego dzielę transmisję na ramki, po każdej ramce odbiór kwitowany jest ACK + CRC ramki. Nie ma ACKa w zadanym czasie to robię retransmisję. Ze sprzętowej kontroli przepływu nigdy nie korzystałem (chociażby dlatego, że AVR jej nie ma:) ). Ale tez nigdy nie było mi to potrzebne.

    Z tym że kolega w xmedze wykorzystywał zapewne sprzętowy USART a z tego co zrozumiałem kolega "jaskol" zrobił to programowo a to trochę inny poziom abstrakcji moim zdaniem :)
    Pozdrawiam
  • Użytkownik usunął konto  
  • Poziom 12  
    albertb napisał:

    Pisząc o drugiej połowie rozumiałem, że w darmowym trybie kompilatora C zostaje Ci jeszcze połowa pamięci - tak zrozumiałem Twój post. Być może źle.


    Ale numer.
    Dobrze, ze nie pomyslalem o 0,5 wyborowej, to tez polowa ;)
    Jeszcze kilka lat temu tylko tak bym mogl pomyslec.
    Zrozumialem, ze chodzi Ci o to moje narzekanie na brak czasu, ze co wtedy robi moja druga polowa..itd.

    albertb napisał:

    Aby Cię wyprowadzić z szoku powiem 6 dzieci i żona pracuje ;-)


    Powiem zonie, ale i tak nie uwierzy.
    Tzn. wiem co ona powie, a ja przebywajac dluzej z dziecmi nie bede jej zaprzeczal.
    Powie tak: ale nasze dzieci sa bardziej absorbujace, maja adhd, nie mozna ich zostawic na chwile samych, itd. Wszystko poza adha jest prawda. Mozna sobie wychowywac, a jak sie ma takie "potworki", ktore Cie na 10 sekund nie odstepuja (chyba, ze sie po chamsku wydrzesz, to cos dotrze na 10 minut). Moze to porazka wychowawcza, ale naprawde sie rece opadaja. 2 dziewczynki (2,5 i 4 lata), z tego jedna jest na diabla miejscu, druga sie od niej juz nauczyla tez taka byc i musialbym sie z domu wyniesc, zeby napisac kawalek programu....a nie mam gdzie pojsc.
    Tesciowa tez miala 3 dzieci i dawala rade, ale spokojnych dzieci...
    Moze przy 6 to starsza trojka zajmuje sie mlodsza trojka, bo tez sobie nie wyobrazam zajmowac sie wszystkimi jednoczesnie, pracowac...koniec swiata.
    Moze macie babcie na etacie ? Pociesz mnie jakos ;)
    Generalnie gratuluje koledze, bo dzieci sa skarbem i zawsze mowie, ze jak bede jeszcze kiedys bogaty, to przygarne kilkoro (zony juz nie namowie, to mi zapowiedziala).

    albertb napisał:

    Ależ to znowu błedne rozumowanie, aby dodać 1000 liczb nie pisze się 1000 linijek kodu.

    Rozumiem intencje (bardziej chodzi o algorytm), ale dodanie na papierze 1000 roznych liczb,metoda "w slupku", zajmie 1000 linijek...i nawet jeszcze kilka ;)

    Ok, AVR Studio6 juz sciagnalem, C jako takie znam, chociazby z PHP, ktorego czasami uzywam, albo Delphi czy VB.NET (chociaz to takie C dla dzieci).
    Teraz poszukam jakiegos programatora i moze ARM-a, zeby podliczyc koszty.
    Bylem przekonany, ze jesli bede musial uzyc kiedyc C,to z PIC-ami...a teraz taka rewolucja i wszystko do gory nogami.
    Tylko nie zostawcie mnie samego na tej glebokiej wodzie i napiszcie w wolnej chwili co byscie proponowali na poczatek - pewnie zly watek i w ogole mnie odeslecie do innych zrodel, ale jakbyscie tak od niechcenia mieli rzucic jaki ARM bylby dobry na poczatek i jaki programator - to bylbym wdzieczny.
    Chyba, ze przesadzam z tym ARM-em na starcie, ale jak juz robic skok przez galaktyke, to robic. Popieracie czy lepiej jednak zwolnic ?

    Mariusz

  • Poziom 28  
    Kolego
    Z tym C to jest o tyle fajnie, że jak dobrze pomyślisz przy tworzeniu sobie swoich własnych "bibliotek" to program napisany w C dla AVR bez problemu odpalisz później w PIC. Co mam na myśli? Otóż: załóżmy, że piszesz sobie funkcję która ma reagować np. na stany wejść i powiedzmy niech ta funkcja ustawia jakąś flagę itp. A więc wyrzucasz z tej funkcji definicje bezpośredniego dostępu do wejść do osobnego pliku. Plików zrobiło Ci się więcej, ale co za to zyskałeś? W jednym pliku masz funkcję która wykonuje jakieś działanie. Jej wygląd będzie niezależny od platformy: czy to pic czy avr czy arm... W drugim pliku masz zaszyty niskopoziomowy dostęp do zasobów. Zmieniasz procesor? Podmiesz tylko plik z dostępem niskopoziomowym. :)

    Na naukę nigdy nie jest za późno. Chylę czoła za Twoją wytrwałość z assemblerem. Ale obecnie nie tędy droga... Na początek z czystym sumieniem polecić mogę Ci Książki Tomasz Francuza oraz Mirosława Kardasia jeżeli zdecydujesz się na AVR. A jeżeli chcesz pozostać przy PIC to i dla tej rodziny coś jest: Paweł Borkowski. Każdy z autorów ma swój indywidualny styl przekazywania wiedzy, niemniej wszystkich trzech warto mieć na półce.


    Co do automatów - niepotrzebnie tak się wzdrygasz na samo słowo automat:) To oczywiste, że taki jeden wielki automat (graf przejść) dla programu to kilka kilogramów papieru może wyjść. Jednak zauważyłem Twój nawyk wyciągnięty z pisania w asm: instrukcja po instrukcji. Hmm... Przeczytaj ten artykuł. Pocieszę Cię - sam kiedyś byłem święcie przekonany, że nie ma innej drogi. Ale teraz, dzięki doświadczeniom jakie zdobyłem wiem, że system jaki chcesz stworzyć to "potwór" tylko na pierwszy rzut oka. Pomyśl sobie jak zgrabne te automaty mogą być, gdy podzielisz program na logicznie pogrupowane zadania... Czyli jeden "blok logiczny" powiedzmy sprawdza stan wejść z uwzględnieniem wszystkich założeń co do ich działania. Kolejny przeprowadza operacje na podstawie otrzymanych sygnałow. A kolejny steruje wyjściami w oparciu o sygnały z bloku wcześniejszego. I tu się zapętlamy i naturalnie nam się to zaczyna kojarzyć z tablicowaniem o którym wspomniał jeden z Kolegów pisząc odnośnie central p.poż.
    Każdy z "bloków logicznych" dzielisz na mniejsze bloczki. Niektóre z tych mniejszych na jeszcze mniejsze... Dochodzisz do momentu, w którym jeden zgrabny fragment kodu wywołujesz jako funkcja z parametrami w kilkudziesięciu miejscach programu.

    Pozwolę sobie zauważyć (może odniosłem mylne wrażenie), że Ty chciałbyś pisać od razu obsługę wszystkiego naraz. To złe podejście. Najpierw trzeba wydziergać obsługę jednego peryferium, potem następnego... i kolejnego. I na koniec, z tak przygotowanych "klocków" można sobie składać już dowolny program. :)
  • Poziom 12  
    daniel6662 napisał:

    Z tym że kolega w xmedze wykorzystywał zapewne sprzętowy USART a z tego co zrozumiałem kolega "jaskol" zrobił to programowo a to trochę inny poziom abstrakcji moim zdaniem :)

    Oj nie, to akurat tez sprzetowo. UART sprzetowy nadzwyczajnie dobrze dzialal ;)
    Za to obrazilem sie kiedys na I2C, bo nie dzialal poprawnie, pozniej znalazlem errate, ale niesmak pozostal. Godziny z oscyloskopem, ostatnie wlosy wyrwane z czaszki...i nic.
    Teraz to juz taka sztuka dla sztuki, mam napisana obsluge podstawowych peryferiow, ale jak sie da, to korzystam ze sprzetu - bo znam juz jego wady.
    Jak sie przesiade na AVR, to bede slepy i gluchy.

    Pozdrawiam,
    Mariusz
  • Moderator Mikrokontrolery Projektowanie
    Ale jak się przesiądziesz na AVR to masz chociażby tu wsparcie w postaci innych użytkowników AVR (a jest ich wielu). Podobnie jak przejdziesz na ARM to też jest tu parę osób naprawdę te klocki świetnie znających, więc nie jesteś sam. No i c to c, zawsze ktoś doradzi. Assembler pomimo, że nieskromnie powiem znam dosyć dobrze na kilku różnych prockach, to po prostu nie chce mi się czytać postów na ten temat - szkoda mi czasu. Myślę, że wiele osób ma podobnie i w efekcie wsparcie dla assemblera jest nikłe. PICe mają niezłe wsparcie anglojęzyczne (chociaż tu i tak avrfreaks wymiata). Peryferia są mniej lub bardziej podobne, czy to pic, czy avr, czy arm, w końcu USART to USART :) Niemniej jeśli byś przechodził na AVR to polecam ci XMEGA, jako bardziej przejrzyste, z doskonałymi peryferiami bez kruczków i wyjątków jak w pozostałych AVRach.
  • Poziom 12  
    To pewnien etap zamkniety i zaczynam szukac odpowiedniego AVR-a lub ARM-a.
    Kusi mnie to drugie, bo jak juz sie przesiadac, to raz,a porzadnie.
    Nigdy nie mialem doczynienia z zegarami powyzej 40MHz i wiem,ze
    moze w tym projekcie to nie ma sensu, ale to do celow dytaktycznych przy okazji kupuje.

    Tylko nie widze potrzebnych przejsciowek z PLCC na cos "domowego" (koncza sie na PLCC32). Gotowe zestawy tez maja max.
    Taki na przyklad AT91RM9200 w obudowie PQFP, 208 nozek, wystarczy mi juz do konca zycia, zegar 180MHz.

    Zdazyl napisac kolega TMF i chyba mnie przekonal z racji swojej wiedzy i wyzej wymienionych rozterek....zeby jednak szukac AVR-a.

    Programator kupie taki:
    ISPcable IV (AT AVRISP2) i do tego taki modul MMxmega z ATxmega128A3 (nie chce podawac linkow, bo moze sie jakis moderator obrazic).

    Jak czytam, ze to ma 7 usartow, to slychac jak przelykam sline ;)
    Apetyt rosnie i zaraz chcialbym ze 100 wyprowadzen, bo podobnie jak pamiec... zawsze sie przydadza, ale rozsadek mowi, zeby nie przesadzac na poczatku drogi.
    Troche mnie martwi kwarc 8MHz na tej plytce (bo ona ma jeszcze kilka elementow, zeby podpiac) i jednak nie moge zrozumiec jak mozna takie procki katowac takim zegarkiem. Wiem, ze on to pozniej mnozy, ale jakos mi nie pasuje taki kwarc, to takiego "kombajnu". Pewnie przyzwyczajenie z PIC-ow, tam bez 20MHz w ogole bym nie spojrzal na uklad.

    P.S.
    Koncze teraz urzadzenie, ktore liczy ludzi, 8 niezaleznych licznikow.
    Najwiecej czasu zajmuje zapisanie do pamieci co godzine ich stanow.
    Zapisywany jest do AT24C128 znacznik poczatku danych, liczniki, znacznik konca.
    Niby ok, ale mam dylemat. Jak bede mial ochote zapytac urzadzenie o stan licznikow, a ono akurat bedzie przemiatalo pamiec w poszukiwaniu wolnego miejsca na zrzut kolejnych wartosci licznikow, to urzadzenie zglosi zajetosc do PC (RS-232) i trudno. Nie moglem przerwac transmisji z pamiecia, zeby obsluzyc PC-ta, bo transmisja I2C by mi "padla". Tylko czy to jest ladne rozwiazanie ? Jestem ciekaw waszej opinii. Myslalem, zeby przy starcie urzadzenia ustalac ten adres pamieci, od ktorego zaczynaja sie wolne komorki do zapisu, ale pewniejsze wydaje mi sie szukanie "w locie". Zbytnio strachliwy jestem ? Wiecie, jedna komorka sie przesunie, zgubi, cokolwiek..i wszystko sie posypie.
    Niestety nie moge dac pamieci FRAM, ktore mnie zachwycaja, bo te male jeszcze w miare normalnie kosztuja, ale bardzo sie zdziwilem, kiedy schowalem do pudelka FM24C04 i zapragnalem zastapic ja 128kb.
    Dobrze, ze te zwykle maja zapisanie blokami/stronami, ale i tak trwa to chyba 10ms i ogolnie przeszukanie calosci + zapis 24 bajtow (oprocz licznikow jeszcze jakies alarmy, RTC, braki zasilania) zajmuje ok. 2 sekundy. Dzieje sie raz na godzine i tylko przez te 2 sekundy w ciagu godziny nie mozna ze sprzetem normalnie "porozmawiac", ale i tak mnie to zastanawia...

    Pozdrawiam,
    Mariusz
  • Poziom 22  
    Witam,

    Dawno nie zaglądałem na Elektrodę, więc moja wypowiedź będzie nieco spóźniona :-)
    Kiedyś stworzyłem taki systemik do sterowania domowego: http://zegaruz.republika.pl

    Też zastanawiałem się jak zrealizować zależności typu AND, OR, itd...
    W końcu powstało coś w rodzaju metajęzyka operującego nie tylko na rzeczywistych urządzeniach, ale również na wirtualnych typu: bajt AND, XOR, itd.... w których można było ustawiać/zerować poszczególne bity i jeśli ich suma logiczna dawała na wyjściu 1 (lub 0), to taki wirtualny bajt generował następny event. Ten event mógł włączać rzeczywiste urządzenie lub następny wirtualny bajt...i tak dalej :-)
    System powstawał w 2002 roku i wówczas programowałem w ASM na procesor PIC18 (co zajęło jakieś 1,5 roku a może i więcej? )
    Dzisiaj zrobiłbym to w C na jakiś nowy procesor, ale wówczas....
    System działa, ale też ma swoje wady np. spiętrzenia zdarzeń, co powoduje czasami lekkie opóźnienia w obsłudze urządzeń wyjściowych.
    Osobną sprawą wraz z pojawieniem się wirtualnych urządzeń i ich bitów jest postępujący brak czytelności pt. "Co my tutaj właściwie realizujemy?"
    Od tego ratuje mnie częściowo odpowiednie nazywanie eventów (można je przeglądać bezpośrednio na wyświetlaczu urządzenia), ale i tak - po kilku latach trzeba czasami się trochę nagłówkować co dany event realizuje :-)

    Dzisiaj łatwiej byłoby to zrealizować oczywiście w C, ale może coś z tego co wówczas stworzyłem przyda Ci się do własnych przemyśleń :-)
  • Moderator Mikrokontrolery Projektowanie
    jaskol napisał:

    Programator kupie taki:
    ISPcable IV (AT AVRISP2) i do tego taki modul MMxmega z ATxmega128A3 (nie chce podawac linkow, bo moze sie jakis moderator obrazic).

    Jak czytam, ze to ma 7 usartow, to slychac jak przelykam sline ;)
    Apetyt rosnie i zaraz chcialbym ze 100 wyprowadzen, bo podobnie jak pamiec... zawsze sie przydadza, ale rozsadek mowi, zeby nie przesadzac na poczatku drogi.
    Troche mnie martwi kwarc 8MHz na tej plytce (bo ona ma jeszcze kilka elementow, zeby podpiac) i jednak nie moge zrozumiec jak mozna takie procki katowac takim zegarkiem. Wiem, ze on to pozniej mnozy, ale jakos mi nie pasuje taki kwarc, to takiego "kombajnu". Pewnie przyzwyczajenie z PIC-ow, tam bez 20MHz w ogole bym nie spojrzal na uklad.


    MHz na AVR to trochę inne MHz niź te na PIC ;P Na AVR masz 1MIPS/MHz, w efekcie 20 MHz PIS to kilku MHz AVR. XMEGA ma PLL i z 8 MHz zrobisz 32 MHz bez problemu, zastosowany kwarc nie ma znaczenia. W ogóle kwarc jest niepotrzebny, bo to samo osiągniesz na wewnętrznym generatorze. No i XMEGA ma 8 USARTów.
    Co do programatora, to AVRISPMkII jest dobrym wyborem, ale IMHO lepszym jest AVR Dragon - masz tam JTAG, a to nieocenione narzędzie przy debugowaniu.
  • Użytkownik usunął konto  
  • Poziom 12  
    albertb napisał:

    Ja nie widzę podstaw do zmiany architektury, skoro autorowi zostaje połowa wolnej pamięci nawet używając darmowych narzędzi.


    Dzieki za troske ;),ale chyba jednak zmienie.
    Zawsze mnie kusily AVR-y, bo sa chyba jednak duzo popularniejsze od PIC (wiecej projektow znajde, przykladow) i maja wiecej peryferiow.
    PIC-ow jest mniejsza rodzina, mniejsze mozliwosci.
    Fakt, ze te PIC32 sa juz na poziomie ... wystarczajacym, ale chcialbym sie nauczyc czegos nowego i jak widze, ze bede mial tyle USARTOW i nawet gotowe RS485 w MCU (ale to chyba wyczytalem w ktoryms ARM-ie), to zew mi podpowiada - musisz to sprawdzic.
    Do przesiadki brakowalo mi jednego - chociaz wcale sie tym wczesniej nie interesowalem - informacji, ze C dla AVR jest za free.
    Dla PIC-a napisali, ze po 30 czy 60 dniach przestaje dzialac optymalizacja i wtedy nie mam pojecia do jakiej wielkosci urosnie zajetosc, bo to chyba wiadomo tylko w przyblizeniu i jak sie nie przekonam, to nie bede wiedzial.
    Zostaje mi polowa pamieci, ale mam bogate plany i wiem, ze jednak druga polowa szybko sie skonczy.
    No i to podejscie, ze musze placic za C, skoro inni mi go daja, to skorzystam.
    Nie porzucam PIC-ow, ale lubie miec wszystkiego wiecej niz potrzebuje i jak pomysle, ze docelowo uzyje jakiegos ARM-a, ktory ma tyle pamieci flash i sram, ze do "konca zycia" mu wystarczy, to po jego zastosowaniu bede czul jakis taki wewnetrzy spokoj, ze czego glupiego nie wymysle, to on mi nie stanie na drodze ;)

    albertb napisał:

    A co do flame'a to owszem, w takim sensie MHz są inne na PIC niż AVR (ale w PIC32 są takie same ;-) )


    Juz ich nie zdaze sprawdzic, bo mialem ochote, ale wtedy poczytalem o C i przygnebily mnie warunki korzystania z microchip-owych kompilatorow.

    albertb napisał:

    Także XMEGA są inne od MEGA,
    Także PIC jest inny od PIC16, a ten od PIC32.


    Troche poczytalem i potwierdza sie, to co napisal chyba "tmf",ze XMEGA jest rozsadniej zrobionania, wszystko jest logiczniejsze i prostsze.
    I chyba nie ma tych fusebitow, na ktore tak wszyscy psiocza.
    PIC tez ma slowo konfiguracyjne, ale jakos nigdy nie slyszalem o problemach z nim zwiazanych. Podane sa w naglowku pliku i juz. Nie mozna o nich "zapomniec" czy cokolwiek sie tam dzialo z AVR-ami...

    albertb napisał:

    Także mimo bełkotu marketingowego ARM od NXP jest inny od tego od ST.


    Podskornie czuje, ze najlepsze robi ST.
    Jakos kojarza mi sie z najwyzsza polka, moze to psychologiczne, bo widzialem ich tylko w najdrozszych sprzetach, moze dlatego, ze rzadko ktos w domu cos z nich robi, chociaz chyba tez daja darmowe narzedzia.


    Pozdrawiam,
    Mariusz
  • Użytkownik usunął konto  
  • Specjalista - Mikrokontrolery
    Ja jednak sugerowałbym zdecydowanie przesiadkę na ARM. środowisk darmowych co niemiara, dostawców też sporo (każdy ma inne peryferia, nawet zwykłe GPIO, ale procesor i system przerwań ten sam) Ceny też na ogół niższe niż większości 8- i 16-bitowców. ST jest najtańszy do zabawy, do produkcji pewnie tańsze będą układy innych firm. Zacznij raczej od jakiegoś Cortex M0, np. LPC11xx lub STM32F0. Przesiadka na M3 czy M4 jest zupełnie bezbolesna. Wiesz, nawet na starość warto coś zmienić, i to niekoniecznie od razu żonę. ;)
    W razie czego służę serią program'w dydaktycznych na STM32F0 lub LPC11.
  • Użytkownik usunął konto  
  • Specjalista - Mikrokontrolery
    1. LPCxpresso do 128 K (debug, generacja kodu bez limitu), CooCox bez limitu, Keil do 32 K, IAR do 32 K - czyli w praktyce za darmo do niemal wszystkich M0.

    2. Zgadza się, porównujemy "cięte w peryferia" ARM z "wypasionymi" 8-bitowcami, przy czym te pierwsze mają bogatsze "cięte" peryferia niż te drugie "wypasione". No i na ogół są tańsze, jeśli nie liczyć najtańszych modeli, takich jak ATmega8, ATtiny13 czy PIC10/12, ale tu nie ma już żadnego porównania mocy obliczeniowej i peryferiów. ATtiny25 lub ATmega88 jest już zwykle droższy od małych Cortexów.
  • Poziom 15  
    BlueDraco napisał:

    W razie czego służę serią program'w dydaktycznych na STM32F0 lub LPC11.


    Może dałoby się to opublikować dla ogółu? Na pewno wiele osób skorzysta, może ktoś się czegoś nauczy :)