Mam pewien problem i borykam się z nim od pewnego czasu.
Chciałem zapisać impulsy do bufora, uruchomiłem w tym celu przerwanie ICP1.
Przy pomocy tego przerwania chciałem zapisać wszystkie impulsy występujące w ramkach, grupa impulsów pojawia się w ramkach co 2,83 ms.
W tej grupie impulsów zawarta jest informacja o wyświetlaniu cyfr w 4-rech wyświetlaczach, pierwsza grupa impulsów to informacja o jednym danym wyświetlaczu i itd...

Tak wygląda przebieg:


Pokaże przykładowy przebieg w poszczególnych ramkach dla liczby 1478 :


Pokaże fragment kodu do zapisu długości impulsów do bufora wzorowałem się na książce Pana Mirka fragment dotyczył pilotów Attmega 32 11059200 hz :


Ustawienie timera 1 gwarantowało odzczytać poprawnie wszystkie impulsy pokże przerwanie:


I niestety za dużo linijek w przerwaniu za długi program i przy krótkich impulsach program nie może zdążyć , a jestem tego pewien bo jak chciałem zapisać tylko 1 ramkę to wszystkie impulsy
zostały zapisane.
Podpowiedzcie jak mogę to spróbować inaczej zapisać żeby każde przerwanie zdążyło zapisać wszystkie impulsy z zachowaniem poprawności że bufor_w1[] to pierwszy wyświetlacz , bufor w2[] to drugi itd ???

Co robi wywołanie funkcji RAMKA() w przerwaniu?
Jaki minimalny jest czas między kolejnymi zboczami?
Jakie masz taktowanie procesora?

--
Pozdrawiam,
Robert

------------------------ [ Dodano po: 7 minutach ]

Na pewno można trochę zoptymalizować kod:
ramka może być równa 4 tylko jak L było 0, bo wtedy była zwiększana, więc nie ma sensu dla każdego L to sprawdzać a L może być równe 0 tylko jak PulseWidth jest > 3000. Więc można dać i część kodu będzie wykonywana raz na ramkę a nie przy każdym zboczu:


to samo dla warunków

tylko jeden może być prawdziwy, więc po co tyle zwykłych ifów - lepiej dać switch-a.

Ja również tak samo zrozumiałem intencje autora kodu, jednak 100% pewności mieć nie można. Zmienne ramka oraz L nie są zdefiniowane wewnątrz procedury obsługi przerwania, więc należy przyjąć, że są zdefiniowane globalnie. Skoro tak, to istnieje możliwość ich modyfikacji w innych fragmentach kodu. Poza tym, jeśli jeszcze są zdefiniowane jako volatile, to dostęp do nich będzie raczej mało optymalny. Jeśli więc te zmienne są używane tylko w przerwaniu, lepiej zdefiniować je lokalnie wewnątrz procedury obsługi przerwania jako static.

Przy założeniu, że kolega rskup dobrze odgadł intencje autora wątku, można by jeszcze bardziej kod zoptymalizować.

Przykładowo:
można napisać np. tak:
To powinno dać zysk około 10 taktów zegara.

Przykładowo:
Cały powyższy fragment można zastąpić jedną linijką:
gdyby cztery tablice jednowymiarowe zastąpić jedną tablicą dwuwymiarową zdefiniowaną tak:

Oczywiście, jak wspomniał kolega rskup, wywoływanie wewnątrz procedury dodatkowych funkcji (które też nie wiadomo ile trwają) to nie najlepszy pomysł. Należałoby rozważyć przeniesienie tych zadań do pętli głównej programu.

Być może udałoby się jeszcze coś wymyślić, ale te rozważania nie mają większego sensu, dopóki nie znamy odpowiedzi na istotne pytania, które zadał kolega rskup na początku swojego posta. W zależności od odpowiedzi może okazać się konieczna zmiana ogólnej koncepcji programu.

Może się też okazać, że zadanie jest w ogóle niewykonalne na tym mikrokontrolerze. Trzeba pamiętać, że sam prolog i epilog procedury obsługi przerwania może zająć od kilkunastu do kilkudziesięciu taktów zegara. Do tego kod zapewne też minimum kilkadziesiąt (przy dobrej optymalizacji), więc jeśli najkrótszy odstęp między zboczami trwa poniżej 100-150 taktów, to istnieje ryzyko "gubienia" zboczy, co w efekcie da niepoprawne wyniki działania programu. A przecież oprócz obsługi przerwań mikrokontroler będzie musiał zapewne wykonywać jeszcze jakieś zadania, na które również potrzeba trochę taktów.

Jak tak obserwuję przedstawione przez kolegę AKSELINEK oscylogramy, to trochę mam wątpliwości, czy uda się to zrobić na tym mikrokontrolerze. Jeśli już AVR, to raczej jakaś XMEGA by się tutaj przydała. Można by nieco przyspieszyć pewne zadania wykorzystując DMA, no i taktowanie też można w nich przyspieszyć.

Bardzo dziękuję za zainteresowaniem tematu funkcja RAMKA ma na celu synchronizację i ponumerowanie kolejności ramek ,niestety jestem teraz na wyjeździe ale w Poniedziałek dokładnie opiszę.

Spróbuje wyjaśnić dokładniej o co chodzi z tymi ramkami:
Jak wcześniej wspomniałem badany przebieg składa się z ramek powtarzających się cyklicznie co ok 2,83 ms czas ten zostanie zmierzony jako PulseWidth>3000 i przy tym preskalerze
zostanie to dobrze odczytane.
Wspomniane ramki ponumerowałem od 0-3 ramka=0,ramka=1,ramka=2,ramka=3 i o co chodzi z tymi ramkami że muszą być ponumerowane ponieważ ramka=0 to grupa impulsów określających między innymi cyfrę pierwszego wyświetlacza ramka=1 to impulsy dla drugiego wyświetlacza , ramka=2 to trzeci wyświetlacz, ramka=3 to czwarty wyświetlacz, o tak sobie oznaczyłem.
Powstaje jednak pewien problem otóż jak to zrobić żeby w takiej kolejności ramki zawsze w programie były przypisywane do właściwego wyświetlacza i pokaże coś na rysunku



Co robi fragment kodu :

jeśli L==3 czyli trzeci impuls będzie miał długość określoną w przedziale <90 i > od 55 czyli ok 80 to ma się wykonać zerowanie ramki czyli:


i teraz ramki są w odpowiedniej dla mnie kolejności .
Odpowiadam po kolei na zadanie pytania:
Taktowanie procesora 11059200 Hz

Teraz pokażę dokładniej pełne impulsy przykładowej ramki


Faktycznie nie ma sensu sprawdzać wartość ramki dla każdego zbocza tylko pewnie co kolejną ramkę???
Zmienna ramka jest niestety zdeklarowana globalnie jako :




jak widać z rysunku impuls 5,41 jest za krótki i jest nie odczytany .
Jak po kolei zmodyfikować kod żeby się w tym nie pogubić od czego zacząć ? jak przerzucić zmienne lokalnie do przerwania podpowiedzcie - ja stawiam pierwsze kroki i się dopiero
uczę a wasze podpowiedzi są dla mnie Bardzo cenne - proszę pokażcie drogę???

Impuls 5 us to ~55 takty zegara ...
Może warto pomyśleć o szybszym taktowaniu?

--
Pozdrawiam,
Robert

Czyli nie pomoże modyfikaja zmiennych i programu w przerwaniu co ciekawe że 7,5 us czyta poddaj pomysł może jednak zanim zwiększę zegar coś spróbuje zmienić, a przy okazi
może policzyć ilość taktów potrzebnych dla poszczególnych linijek kodu, do tego nie potrzebnie sprawdzenie ramki dla każdego L, podpowiedz od czego zacząć i jak zbudować przerwanie
trochę prościej zrobię próbę i o wynikach dam znać ?

Jak zwiększysz zegar. Napiszesz optymalnie kod, to masz szansę się zmieścić.
Skorzystaj przy optymalizacji kodu wcześniej podane uwagi. I koniecznie wywal skakanie do jakiejkolwiek funkcji z przerwania.

Jak kompilujesz to masz tworzone dodatkowe pliki .lss, gdzie masz kod wynikowy, który możesz (powinieneś) poanalizować.
Skorzystaj tez z porady topic3741.html.

--
Pozdrawiam,
Robert

Co znaczy wywal skalanie?

Ja myślę, że chyba nie uda się tego zrobić przy obecnej ogólnej koncepcji programu, o ile w ogóle się da.

Jest szereg problemów, których pewnie w tej chwili nie dostrzegasz, ale prędzej czy później one wyjdą na światło dzienne

Przykładowo ilość zboczy. Poszczególne cyfry różnią się ilością zboczy. Jeśli jakaś cyfra się zmieni, a przedtem do tablicy zapisane było więcej zboczy niż jest ich po zmianie, to w tablicy pozostaną "śmieci" po przedniej cyfrze. Aby tego uniknąć, trzeba byłoby zerować tablicę po każdym cyklu, a na to potrzebny jest dodatkowy czas. Nawet, jeśli nie będziesz robił tego w przerwaniu, mikrokontroler musi zdążyć to zrobić przed zapisaniem nowych danych, a jak będzie tak dużo czasu spędzał na obsłudze przerwań, to może być z tym kłopot, tym bardziej, że przed wyzerowaniem musi coś z tymi danymi zrobić (przeanalizować lub przynajmniej przesłać gdzieś do analizy).

Inny przykład - identyfikacja ramki/cyfry.

Pomijam już fakt, że wywoływanie funkcji w czasie obsługi przerwań jest nieekonomiczne czasowo (o czym już pisał wcześniej kolega rskup), a procedura obsługi przerwania powinna być jak najkrótsza (tym bardziej, że tu masz do dyspozycji tylko 55 taktów, a to naprawdę niewiele, jak na zdania, które chcesz wykonać). Zresztą skoro funkcja RAMKA() posiada tylko jedną instrukcję(?) - zerowanie zmiennej ramka - to po co tak kombinować.
Bardziej chodzi mi o to, że jeśli w pewnym momencie wyzerujesz zmienną ramka, to co z poprzednimi zboczami (gdy L było równe 0, 1 lub 2), które były zapisane do innej tablicy, kiedy zmienna ramka miała inną wartość?

Nie wiem, co dokładnie próbujesz osiągnąć, więc trudno mi się tutaj szczegółowo określić, jakie ewentualnie inne problemy mogą wystąpić. Myślę jednak, że najlepszym rozwiązaniem byłoby w procedurze obsługi przerwania skoncentrować się tylko i wyłącznie na zapisywaniu danych do tablicy (oczywiście kod musi być jak najbardziej optymalny), a inne rzeczy, jak np. wyżej wymieniona identyfikacja cyfry, można zrobić w programie głównym (wtedy może uda się zdążyć przed następnym zboczem). Między cyframi jest trochę czasu (ok. 3000 taktów), który można przeznaczyć na analizowanie.

Tutaj trudno dać jakąś jedną prostą "złotą radę" (czy nawet kilka), która spowoduje, że Twój program zacznie działać zgodnie z Twoimi oczekiwaniami. Prawdopodobnie wykonanie tego, co chcesz wykonać, jest możliwe, jednak to wymaga dobrego planu. Nie wiem, czy przy Twoim stopniu zaawansowania (napisałeś, że jesteś początkujący) nie jest to zbyt ambitny projekt, a pomoc na forum musiałaby być zbyt obszerna i "całościowa", bo tak jak już napisałem, według mnie to nie jest tylko kwestia optymalizacji procedury obsługi przerwania. Niewykluczone, że ktoś się podejmie, bo ja niestety nie znajdę chyba tyle czasu (choć nie wykluczam, że jeszcze się włączę do dyskusji w tym wątku)

Życzę powodzenia.

Dzięki do projektu wrócę tyko tydzień mnie nie będzie ale o wynikach będę informował i jeszcze raz dzięki, jeszcze będę kontynuował wątek.
Mam tylko kilka spraw do przemyślenia na urlopie to jeszcze coś mi chodzi po głowie jak zapisuje tylko dane z jednej ramki:



a nie analizuje pozostałych trzech program zawsze zdąży :
To jak zrobić żeby bufor_w1[L] zapisywał w ramce 0 , a w kolejnej ramce=1 bufor_w2[L] i tu tu widzę błąd .
A może zapisać do jednego bufora 4 ramki analiza - wyzerowanie bufora i kolejny zapis, przecież między ramkami jest długi czas to zawsze będę wiedział że to koniec lub początek ramki?
A może robić zatrzask bufora z zachowaniem kolejności ramek , ramki lecą bardzo szybko a mi tylko chodzi żeby wynikiem końcowym zapisać wartość wyświetlanej cyfry do zmiennej globalnej.
Jak zrobić zerowanie bufora ??? jak zatrzasnąć bufor?? czy jakoś przerywać przerwanie jakie są sposoby?? Na początek poprawię ten zapis żeby nie wywoływał funkcji na prostszy :



zmienna ramka jest globalna to pętla główna ją widzi to jeśli ramka==3 i jest jej koniec muszę zrobić analizę w pętli głównej szybko wyzerować bufor i jak ramka==0 zapisać cztery ramki i td,

czy dobrze zrozumiałem i czy moje myślenie idzie w dobrym kierunku?????
A może całą w/w funkcję przeniosę do pętli głównej?

Czy przerwanie ma wyglądać tak?

Bardzo dziękuję za owocne podpowiedzi próbowałem różnych rozwiązań niestety impulsu 5,41 nie udało się odczytać i pewnie racja na tej prędkości procesora to chyba niemożliwe.

Jednak zastosowanie swith-a jak podpowiedział kolega rskup rewelacyjnie rozwiązało problem dzięki temu udało się odczytać 7,41 w każdym impulsie cyfry można dzięki temu odróżnić
i choć to może nie jest dokładnie ale cyfry idzie rozróżnić.

Dziękuję również koledze andrews jego pomysł z zastosowaniem jednego bufora w tablicy dwuelementowej świetnie zadziałał i również można tego sposobu użyć bo czasowo jest ok.

Jeszcze raz chciałem podziękować za pomocne podpowiedzi.

Pisałeś, że używasz kwarc 11.0592 MHz, więc masz jeszcze zapas na zwiększanie częstotliwości. Jak dasz kwarc 16 MHż to zwiększysz częstotliwość taktowania procesora prawie o 50%. A możesz dać bez problemu nawet tak 18 MHz, i procesor będzie poprawnie działał, a masz dzięki temu jeszcze większą częstotliwość i szanse na łapanie krótszych impulsów.

--
Pozdrawiam,
Robert

Tak oczywiście na pewno zrobię taką próbę i dam znać o wynikach.

Podniosłem taktowanie procka do 16MHZ i zaczęło czytać impulsy 5us i z tego jestem zadowolony, jednak okazało się że niektóre urządzenia posiadają impusy 0 ko 4,6 us i tu trochę kicha
ale podniosłem taktowanie do 18 MHZ i się chyba udało .
Mam pytanie na koniec jaką maksymalną prędkość taktowania procka mogę użyć w przypadku Atmegi 32??

Może Kolega zajrzałby kiedyś do noty układu na którym pracuje?

No dzięki ale czy w takim przypadku 18 MHZ to nie będzie za dużo bo tu podają Max 16 MHZ ???

Możesz dać nawet 20MHz i powinno działać

_________________
Pomóżcie mi stanąć na nogi

Może działać a może nie działać. Obaj wiemy że zadziała w domu na stykówce czy zestawie uruchomieniowym bo to przetestowaliśmy. Ale po coś producent podaje te wartości. WIęc jeżeli wsadzisz kwarc 18MHz czy 20MHz to może nie działać prawidłowo bo producent gwarantuje poprawną prace do 16MHz. Więc jak zrobisz urządzenie i wsadzisz coś czego producent nie zaleca to robisz błąd projektowy i Twoje urządzenie jest wadliwe.