Cześć, próbowałem użyć analizatora stanów logicznych jako data logera, który odczytywał wartość 8-bitową z jednego z portów Atmegi.

Mam problem z momentami przejściowymi, analizator wykrywa stany pośrednie podczas zmiany stanów logicznych i rejestruje je.

Większość "szumu pomiarowego" udało mi się wyeliminować, zmniejszając rozdzielczość pomiaru do 7-bit a ostatni bit pozostawiając jako bit "ready to read".

Zmienna "pozycja" jest zmienną 10-bitową którą skaluję od mniejszej.
W kodzie wygląda to tak:



Pozostały jeszcze nieliczne błędy pojawiające się mimo tego zabezpieczenia. Ktoś byłby w stanie pomóc mi rozwiązać problem ? Jestem praktycznie pewien że to jest wciąż problem stanów pośrednich gdyż błędy pomiarowe ujawniają się w stałych miejscach.

Jakiego typu jest zmienna pozycja? Jak int to wystarczy dać >>3

uint16_t

Cenna uwaga, ale nie w tym tkwi kij

Witam,
Rozumiem, że loger rejestruje więcej bitów niż atmega wysyła.

Być może (jeśli podłączyłeś port mikrokontrolera do jakiegoś wejścia o wysokiej impedancji) występują stany przejściowe związane z brakiem dopasowania linii. Jeśli tak to najprostszym rozwiązaniem jest dopasowanie linii czyli wstawić pomiędzy mikrokontroler a "odbiornik" szeregowo rezystor o wartości 220ohm (oczywiście z bardzo dużą tolerancją wartości).

Pozdrawiam
Łukasz

Dorywczo rozwiązałem to, przesyłając informacje w kodzie Greta.
Nie za bardzo potrafię zrozumieć o co chodzi z tym dopasowaniem linii.

Oczywiście błędy transmisji możesz poprawiać stosując kodowanie, ale ja założyłem że masz problem hardwarowy. Mogę się mylić ponieważ jest dość mało danych.

Wytłumaczę obrazowo.

Port atmegi działa jak armata kulek schowana za ścianą. Kiedy zmienia się stan portu z 0 na 1 lub na odwrót armata strzela kulką. Wejście woltomierza czy analizatora to bardzo twarda ściana (wysoka impedancja wejściowa) z oknem przez które widać napis na kulce. Problem w tym że kulka się odbija i leci w kierunku armaty tam się odbija i z powrotem i tak wiele razy za każdym razem wolniej, aż w końcu zatrzyma się na ścianie. Przez ten czas kiedy kulka się odbiła wartość widziana przez okienko się cofa na poprzednią wartość bo kula informująca o zmianie uciekła.
Problem w sferze mechaniki można rozwiązać strzelając przez ośrodek który kulkę spowolni np przez wodę albo olej.

I tak jak w przykładzie dodaje się rezystory będące takim ośrodkiem do "wyhamowywania" zmian informacji.

Mam nadzieję że takie (bardzo uproszczone porównanie) nie jest zbyt mało naukowe.

Skądinąd należy zaznaczyć że Atmegi przez sposób realizacji obwodów wyjściowych są podatne na tego typu zjawisko.

Czyli chodzi o zjawisko podobne do drgań styków tak w uproszczeniu jeśli dobrze zrozumiałem.
Nie rozumiem w jaki sposób rezystory mają pomóc, ale jak będę miał możliwość to sprawdzę ten sposób i dam znać czy pomogło

Drgania styków nie mają z tym nic wspólnego. Chodzi o tłumienie oscylacji w obwodzie składającym się z pojemności oraz indukcyjnosci ścieżek/przewodów oraz wejścia w stanie HiZ ATmegi. Szeregowy rezystor pomaga wytłumić energię oscylacji.

Witam,

Napisz jaki to za analizator stanów logicznych i czy prawodłowo skonfigurowałeś standard jego wejść ( ttl, cmos, lvttl, lvcmos....).
Atmega jest na tyle wolna, że zjawisko niedopasowania linii oraz wejść/wyjść ma tu marginalne znaczenie. Duży wpływ na prawidłowy odczyt stanów portu Atmegi ma konfiguracja analizatora stanów logicznych.

Jeżeli - jak sam autor pisze - zjawisko występuje zawsze w tym samym miejscu, warto w pierwszej kolejności przeglądnąć kod, bo może to w nim siedzi babol?

Pozdrawiam.

_________________
Pozdrawiam,
sq8mvy, Paweł

Jest to podróbka saleae i w sumie nic nie konfigurowałem, bo nie wiedzialem że się da.

Zjawisko występuje w tych samych miejscach które są charakterystyczne, niestety pousuwane mam te złe pomiary. Ale chodziło o miejsca w stylu 64 128 itd.
Jeśli chodzi o kod to w zasadzie są te 3 linijki które podałem wcześniej.
Po przejściu na kod Greya problem znikł całkowicie.

Witam,

Podróbki analizatorów Saleae pracują bezproblemowo nawet pod linuksem. Nie mają też możliwości wyboru typu logiki wejściowej - nie było też wiadomo jakiego analizatora kolega używa.

Co do Tego kodu z pierwszego postu:

Tego nie rozumiem - dlaczego robisz jakieś mnożenia oraz dzielisz przez 1023 ?
Jeżeli pozycja to 10 bitów, a Ty chcesz na 7 bitów, to chyba lepiej jest tak zapisać:


Rozumiem, że zmiana stanu bitu 7 ( linia 1 oraz 5) to informacja, że dana jest gotowa do odczytu z portu ? A co się będzie działo, jeżeli wartość obliczana za pomocą linii 3 będzie miała wartość większą niż 7 bitów ( bo taka prawdopodobnie będzie z tych Twoich operacji matematycznych w kilku przypadkach ). Wówczas analizator odczyta dane nie takie jakich się spodziewasz, uznając je za jakieś stany przejściowe/nieustalone. A ostatecznie nie są to stany przejściowe portów, tylko błędy w kodzie.

Wprowadzając jakieś kodowanie danych w programie, nie zmieniasz właściwości podłączenia analizatora do portu, jak też właściwości samego portu. W takim wypadku analizator również powinien pokazywać te " stany przejściowe".

Ponadto, jeżeli już używasz tego 7 bitu do sygnalizowania danych gotowych do odczytania, to synchronizuj tym bitem również analizator logiczny ( o tym też nie wspomniałeś, jak odczytujesz te dane z portu analizatorem), aby odczytać właściwe stany portów.


To tak na szybko analizowałem, więc mogłem się gdzieś pomylić.

_________________
Pozdrawiam,
sq8mvy, Paweł

A w jakich przypadkach przekroczy 7 bit? Przy wartościach z zakresu 0-1023 to chyba niemożliwe, ale może się mylę.
Ten sposób to raczej z braku doświadczenia przy przeskalowywaniu i ten sposób wydawał mi się dawać bardziej przewidywalne rezultaty.
Tak, pin pb7 czyli w zasadzie ósmy bit odpowiada za gotowość do odczytu, przynajmniej taki był plan.

Witam,

Jeżeli rzeczywiście zmienna będzie się zawierać w przedziale od 0 do 1023, to wynik się zmieści w 7 bitach. Ale jaką masz pewność, że zmienna ta nie przyjmuje większych wartości ? Z tych 3 linijek kodu tego nie można wywnioskować - nie wiem jakie operacje są na niej przeprowadzane. To, że podałeś zakres wartości tej zmiennej ( 0 - 1023 ) mnie nie przekonuje.

Ja też, patrząc na szybko na obliczenia, pomyliłem pierwsze mnożenie z dodawaniem.
Nie zmienia to faktu, że szkoda marnować miejsce w pamięci na takie operacje mnożenia i dzielenia, skoro można zastosować przesunięcia bitowe. Sam zresztą sprawdź jaka jest różnica w wygenerowanym kodzie, między mnożeniem/ dzieleniem a przesunięciami bitowymi.

Przy odczytywaniu portu analizatorem, zsynchronizuj odczyt z tym najstarszym bitem - skoro on jest odpowiedzialny za sygnalizowanie prawidłowych danych na wyjściu portu.

_________________
Pozdrawiam,
sq8mvy, Paweł

Co do pewności to mam trzy powody
Pierwszy to kod programu tuż przed wystawieniem na wartości na port. Załączam go poniżej. Tutaj raczej nie dało się pomylić.

A drugi to fakt, że przy przejściu do kodu greya działa wszystko ok.

Trzeci to taki, że te szpilki rejestrowane przez analizator nie istnieją w programie. Tzn ustawiałem dodatkowy warunek że gdy zmienna przekroczy jakąś tam wartość to miała się zapalić dioda. I w analizatorze były błędne odczyty a dioda się nie zapalała. Eksperyment był robiony dla wielu wartości progowych, tak aby wykluczyć złe przeprowadzenie testu.

Co do niepotrzebnego mnożenia,rozumiem i poprawię

A jeśli chodzi o synchronizację z najstarszym bitem, to nie wiem jak to zrobić. Robiłem to w inny sposób.
Po prostu wszystkie dane były "przesiesane" przez skrypt w matlabie, który omijał pomiary dla stanu logicznego 0 przy ostatnim bicie.
Wiem że można powiedzieć, że nie ma pewności czy skrypt działa dobrze. Ale sprawdziłem, te błędne odczyty istnieją również w pliku źródłowym generowanym przez saleae.

Jedynym zarzutem do tego sposobu może być duża ilość generowanych danych. Może ten analizator jest zbyt wolny i to powoduje błędne odczyty ?

Witam,

Podaj model tego analizatora.
Jaką prędkość próbkowania ustawiałeś dla analizatora ?
Sprawdzałeś może częstościomierzem, jaka częstotliwość jest na PB7 - bo z tego co rozumiem dane są wysyłane w sposób ciągły ?
Jakiego programu używasz do obsługi analizatora. Najnowsze wersje programu od Saleae rozpoznają klony.

Wiem, wiele pytań....

_________________
Pozdrawiam,
sq8mvy, Paweł

Jeśli chodzi o model, to tu nic nie jest napisane. To jest typowy analizator jaki wyskakuje po wpisaniu hasła "saleae" na allegro. One wszystkie i tak z aliexpress z jednego źródła raczej pochodzą.

Ustawiam 24Ms/s (a ile to się do rzeczywistości ma to nie wiadomo).

Używam wersji 1.1.34 ponieważ ona nie wykrywa klonów.

Nie mam czestościomierza. Zmiana danych na porcie odbywa się gdy mikrokontroler w programie przechodzi do odczytu pozycji, więc nie jest to stały odstęp czasu.
Z tymże częstotliwość odczytywanych danych w okolicy błędu przy jednym z przykładów który analizuję, jest mała.
Przykład dla pomiaru 50 sekund - analizator zebrał ponad 203 tysięcy odczytów, większość z nich należą do pierwszych sekund ruchu (do ok 10s 140k odczytów) mimo dużej częstotliwości nie ma błędów. Później robi błąd w okolicy 21,71 sekundy gdzie danych jest już sporo mniej (dla przedziału 20,75 do 22,75 jest to ok 736 próbek).
Dorzucam screeny jak to wygląda w excelu i matlabie.
Ostatni bit to ready to read a poprzednie to dane. Nadmiarowy jest tutaj bit odpowiadający wartości 16.

Witam,

Staram się zrozumieć.......

Skoro prędkość analizatora masz ustawioną na 24Ms/s to znaczy, że analizator w ciągu sekundy zbierze 24 miliony próbek. Dla 50 sekund będzie to 50 razy więcej.
Jeżeli piszesz, że po 50 sekundach masz coś koło 203 tysiące to analizator jest ustawiony na 4Ks/s.

Z przedstawionego kodu widać, że stany na porcie PB zależne są od tego co jest na wejściu, czyli 8 bitów na porcie PA oraz 2 bity na porcie PC.
Stanów na wejściu już niestety nie widać

W ramach testu, jeżeli do portu PB masz podpięty tylko analizator, zaterminuj piny portu PB rezystorami 10K do masy.

_________________
Pozdrawiam,
sq8mvy, Paweł

Abym mógł widzieć stany na wejściu niestety potrzebowałbym analizatora z większa ilością wejść.

Test zrobię, narazie mam natłok innych obowiązków i nie mogę tymczasowo eksperymentu zrobić. Dam znać co z tego wyjdzie

Dopiero teraz znalazłem czas na wrócenie do tego. Podpięcie do masy nic nie daje, tak samo jak podpinanie rezystorów szeregowo. Niezależnie od tego czy system 7-bit + bit ready to read, czy zwykłe 8 bit.

Jedyne co się sprawdziło w moim zastosowaniu to kodowanie Greya. I chyba przy tym pozostanę jeśli chodzi o robienie odczytów w ten sposób.

W zasadzie tylko, aby zbadać czy mikrokontroler popoprawnie steruje silnikiem (na potrzeby pracy magisterskiej).
Ten sposób wybrałem ponieważ jest chyba najmniej obciążający dla mikrokontrolera i analizator stanów logicznych precyzyjnie określa mi czas.

Ten klon saleae to niezbyt wiarygodny sprzęt pomiarowy. Ja na Twoim miejscu wziąłbym jakiś oscyloskop cyfrowy ewentualnie porządny analizator

Ba, oczywiście że byłoby lepiej, ale do moich zastosowań to za duży wydatek.