[pepepanpatryk]

Hej jak macie rozwiązane takie sytuacje gdy mikrokontroler wykonuje jakieś zadanie, które trwa np. 30 sekund, przez co główna pętla programu jest zablokowana przez to właśnie zadanie, a chcielibyście np. zmienić godzinę na wyświetlaczu? Myślałem nad implementacją jakiegoś prostego schedulera, który "żonglowałby procesami" dając, złudzenie pracy równoległej. Coś podobnego jak np. w FreeRtos.

http://www.freertos.org/implementation/a00016.html

#programowanie #elektronika #avr #atmega

[A.....k]

@inspektor_gadzet: Bzdura. Jeśli wszystko jest dobrze skonfigurowane to takie przerwanie niczego nie zaburzy. A gadka w stylu tylko ustaw flagę to jakieś straszne #!$%@?. Ofc, im szybciej tym lepiej ale zdecydowanie większe znaczenie ma ogólna konstrukcja systemu a nie to czy przerwanie pętli w main na 100us, gdzie 99% czasu to delay ma znaczenie.

[inspektor_gadzet]

@Analityk: jak rozumiem masz jakieś doświadczenie w tej materii? Bo jak na razie tam gdzie ja pracowałem zawsze #!$%@? za zbyt długie przerwania, a wiesz może co się stanie jak przerwanie wywłaszczy przerwanie i zacznie się kaskada? Albo procek się zawiesi, albo nigdy nie wróci do pętli głównej

[Jarek_P]

gdy mikrokontroler wykonuje jakieś zadanie, które trwa np. 30 sekund

@pepepanpatryk: gdy tak jest to w 99% przypadków oznacza to źle napisany program. Koledzy wyżej zbiorowo doradzają przerwania, ale to można zrobić i bez przerwań. Po prostu program niech nie zatrzymuje się na czas tych 30 sekund, tylko niech sobie ta pętla główna się wykonuje tak szybko, jak tylko zdoła, a w tym czasie niech jedynie kontroluje proces, który został uruchomiony.

[A.....k]

@inspektor_gadzet: Wszystko zależy. Jak masz jedno przerwanie to po ki grom masz się przejmować? Jedyny problem to zakończyć isr zanim znowu nie trzeba będzie go wykonać. Nawet to nie zawsze jest problmem.

[inspektor_gadzet]

: @Analityk: jest coś takiego jak zasady pisania dolnego kodu i według nich kod który wykonuje w przetrwaniu coś co mógłby wykonać w pętli głównej jest błędem i tyle, przerwanie ustawia flagę, ewentualnie jakieś bardzo proste operacje ale nic co w sobie zawiera pętlę albo co gorsza instytucję NOP

[A.....k]

@inspektor_gadzet: Przerwania są po to, by reagować na coś natychmiast. Jak ustawiasz w przerwaniu flagę, żeby coś zostało wykonane w nieokreślonym czasie w main to po ki #!$%@? ci to przerwanie?
Jak masz przerwanie od enkodera to W PRZERWANIU sprawdzasz, czy maszyna jest na właściwej pozycji a nie czekasz na 1000 takich przerwań bo akurat coś w main wypluwa 2kB bufor danych na LCD i maszyna właśnie miażdży krańcówkę. Zero wyobraźni,

[inspektor_gadzet]

@Analityk: ale #!$%@?, pętla main jest własnie po to żeby reagować, ale ona ma być tak napisana żeby nic się nie blokowało. Akurat w przerwaniu od krańcówki wysyłasz sygnał STOP i tyle. I znowu, jak wypluwasz tyle danych to ustawiasz sobie DMA, albo robisz to w taki sposób żeby nie blokować pętli

[pepepanpatryk]

@Analityk: Akurat trafiła mi się ksiażka Kardasia, i tak losowo otworzyłem przypadkiem na przerwaniach. Co mi się od razu rzuciło w oczy? "W procedurze obsługi przerwań nie powinno się wykonywać jakichkolwiek działań w pętli czy aktualizacji wyświetlacza LCD.

[A.....k]

@inspektor_gadzet: #!$%@? wafla, i co tera? Oba podejścia są dopuszczalne i stosowane. Jak będziesz liczył na to, że pętla main po prostu stoi i czeka na jedno #!$%@? wydarzenie, to powodzenia.
@pepepanpatryk: No i? Kardaś ma rację. Nie napisał, że to błąd taki jak dzielenie przez zero tylko, że w przypadku skomplikowanego systemu może to stwarzać trudne do wychwycenia błędy. Ale wcale nie musi.

[pepepanpatryk]

@Analityk: No to, że sugerowałbym się raczej opinią gościa, który nie jest jakimś no name'm z Internetu.