microgeek.eu

rezasurmar pisze:Hmm tak się zastanawiałem, czy w dobie ARMów nie dało by się zgłaszać Eventów (przerwań softwerowych).

W sumie sam jestem ciekaw jak zgłaszać takie eventy. Jeżeli nie ma do tego już jakichś rozwiązań, to myślę że trzeba by było napisać moduł, który rezerwuje jakaś częśc pamięci, a potem jedzie po tej pamięci i sprawdza czy coś się nie zmieniło.

A Ty mówisz o przerwaniach przechodzących z zewnątrz. Ja myślałem raczej o eventach, które dzieją się jedynie w oprogramowaniu.

Temat długi i szeroki jak cholera. Jeżeli chodzi o pomiar ADC, to fajną sprawą jest zaprzęgnąć do tego jakiś Timer, do tego DMA i przerwanie. Mamy gotowe wyniki z ustawionym przez nas samplowaniem

rezasurmar pisze:Hmm tak się zastanawiałem, czy w dobie ARMów nie dało by się zgłaszać Eventów (przerwań softwerowych).Po co w ogóle zajmować czas pętli głównej?Nad zgłaszaniem eventów łatwiej zapanować (priorytety i grupy).

Musiałbyś precyzyjnie określić, co rozumiesz pod pojęciem "przerwanie software'owe". Wtedy może coś podpowiem, a przede wszystkim będzie wiadomo, o czym mowa. Zasadniczo, dopóki nie korzystasz z DMA, zawsze ingerujesz w czas obiegu pętli głównej. Albo wciskasz jakiś "Task" w pętlę główną, albo coś upychasz w przerwanie i wtedy (w tym drugim przypadku) również czas wykonania pętli głównej ulega wydłużeniu o skok do przerwania, obsługę zdarzenia, które je wywołało i powrót do pętli głównej.

jeśli mamy wywoływać kilka funkcji typowo cyklicznie to można użyć timer z 4 kanałami i do każdego podpiąć funkcję odpowiednią. Niestety w przypadku STM i tak będzie trochę kodu do sprawdzenia tego, bo mamy wspólne przerwanie na te wszystkie eventy, ale pozbędziemy się tego z poziomu pętli głównej.

Nawet można zrobić mechanizm, że funkcja zapewni sobie sama kiedy się następny raz uruchomi- odpowiednio sterując własnym rejestrem porównania.

Tego typu mechanizmy można mnożyć i mnożyć.

Klawisz na EXTI na pewno "zakłóci" pętlę główną tylko wtedy, gdy rzeczony zostanie wciśnięty. Występuje wtedy zdarzenie (event), który następnie możemy obsłużyć lub nie, zależnie od potrzeb w danej chwili. Tutaj masz całkowitą rację, ale skoro mamy do dyspozycji szybki układ z rdzeniem ARM, to co komu po kilku cyklach traconych na testowanie flagi, skoro marnuje się setki cykli korzystając z HAL lub SPL? Te wszystkie ładne opakowania (funkcje) ułatwiające pisanie programu powodują znaczne straty. Nie przejmujemy się nimi, bo mamy szybkie układy, ale strata jest stratą. I żeby nie było, że się czepiam bibliotek... Zdecydowanie popieram ich wykorzystanie, a wspomniałem o nich jedynie po to, by stratę kilku cykli na testowanie flagi porównać do innych strat, o których tak chętnie zapominamy.

W tym konkretnym przypadku sporo zależy od sposobu, w jaki obsługujemy sam UART. Tutaj EXTI może przyjść z pomocą, ale pod warunkiem, że ma wyższy priorytet od przerwań wykorzystywanych przez UART (o ile są wykorzystywane). Soft musi być wyważony, a w przypadku korzystania z UARTU trzeba zwracać szczególną uwagę na płynność działania, bo jest to chyba najwolniejszy moduł w układzie.

tu przypomnę przy okazji o tej bibliotece dla uarta z DMA co napisałem - może ktoś przetestuje kiedyś wszystko na DMA, wchodzimy w funkcje tylko wtedy gdy chcemy coś przesłać/ mamy coś do odbioru. Jak teraz myślę to brakuje w niej callbacków - niedługo ją przerobie na nie

Ciekawe, czy ta logika programowalna w PICach umożliwia jakieś ciekawe sztuczki z debouncem, eventami itp

Ewentualnie jeśli mowa już o debounce - nowsze expandery I/O na np I2C mogą sprzętowo to robić i odsyłać info o tym/wybudzać procka itp.

dambo pisze:Ciekawe, czy ta logika programowalna w PICach umożliwia jakieś ciekawe sztuczki z debouncem, eventami itp

A to już jest inny temat, ale już podpowiadam, że to służy między innymi do łączenia ze sobą różnych modułów wewnątrz układu.