Co to za protokół komunikacji?

Witam,
nie jestem dobry w te klocki, wiem jak wygląda CAN, na tym konczy się moja wiedza nt komunikacji. Jakiś czas temu sprawdzałem inne protokoły ale nic nie mogłem przypasować. 3 linie komunikacyjne:



Nie jestem w stanie lepiej tego uchwycić na DS1104Z.
Wygląda mi na to, że na kanale 1 po pojawieniu się sygnału LOW na kanale 2 pojawia się taktowanie oraz komunikacja na kanale 3.

Jeśli jest to jakiś standardowy protokół chciałbym go zdekodować aby później użyć zewnętrznie.

Jest to połączenie mikrokontrolera Freescale MC908AZ60A ze sterownikiem PWM do silników krokowych, który jest robiony na zamówienie i nie ma do niego żadnej dokumentacji. MC908 używa standardowych pinów I/O do tej komunikacji (PTA2, PTA4 i PTA7).

Z góry dziękuję za wszelką pomoc.

Wygląda jakby SPI. Fioletowy linia MOSI, niebieski sck a żółty CS

Ogromne dzięki. To ma sens. Kilka lat temu bawiłem się Arduino i poznałem SPI, jednak pamiętałem, że jest MISO, MOSI, SCK i CS. Tutaj miałem tylko 3 linie więc automatycznie odrzuciłem SPI. Faktycznie tutaj jednak jest komunikacja jednostronna więc MISO jest zbędny,
Jutro zbadam sprawę.

Jednak teraz patrzę w datasheet i widzę, że MC68HC908AZ60A ma SPI na pinach:

MOSI - PTE6
SS - PTE4
SCK - PTE7

a tutaj mamy domniemane:
MOSI - PTA7
SS - PTA2
SCK - PTA4

Sprawdzę to jutro i dam znać.

o_Tadeusz wrote:

Może SPI zrobione jest programowo? Niektóry programiści lubią takie zabawy

Możliwe. Całe urządzenie jest tak zaprojektowane, jakby projektanci byli pod wpływem silnych środków odurzających. Wszystko jest strasznie przekomplikowane.

o_Tadeusz wrote:

O programowym rozwiązaniu może świadczyć fakt niesymetrycznego sygnału SCK.

Nie mogę nic znaleźć na ten temat ale będę jeszcze szukał.

Właśnie czytałem o SPI i ten SCK mi się nie zgadza, normalnie jest high a tu mamy low.
Normalnie MISO i MOSI są podciągnięte do gnd, tutaj nie ma żadnych pull down. Wszystkie 3 linie idą od MCU przez rezystory 470 Ohm w szeregu.

Dziękuję za wskazówki/informacje.

Albo mój Rigol nie bardzo sobie radzi z dekodowaniem SPI albo coś tu nie gra.
Zresztą, i tak muszę "nagrać" wysyłany ciąg znaków aby potem go odtworzyć. Na Arduino.cc czytam, że trzeba znać kilka parametrów jak format słowa, LSB/MSB, rising/failing edge itd. a tutaj dokumentacja żadna nie istnieje.

Na razie straciłem chęci do dalszej zabawy ale temat na pewno wróci.

Proponuję wpisać w wyszukiwarkę hasło "saleae" i potem zakupić tani klon lub nawet oryginał.
Ustawiasz polaryzację SCK czyli w stanie spoczynkowy HI lub LO, w zależności od tego ustawiasz kiedy odczytywane są stany linii MOSI i MISO (najczęściej w momencie powrotu do stanu spoczynkowego).
Taki analizator pozwoli Tobie "nagrać" (ale nie odtworzyć) dłuższe fragmenty a nawet na nagranych przebiegach potestować kilka innych protokołów. Dane może Tobie przedstawić DEC, HEX, ASCII, BIN itp...
Nie wiem dlaczego podglądasz w ASCII - taki znak " } " oznacza w DEC 125 a "h" to 104. Tam pewnie lecą wartości HEX a nie literki.

Mam sentyment bo kiedyś rozkodowywałem radyjka na procesorach motoroli jak jeszcze nie było kalkulatorów no i czasem się grzebało też w licznikach

Mówisz, że takie coś wartości paczki fajek zda egzamin do tej konkretnej aplikacji?:

https://www.aliexpress.com/item/32960102049.html

Nie mam problemu z wydaniem $300-1000 za orginał ale raczej do niczego innego mi się nie przyda więc szkoda kasy.

Skoro grzebałeś w licznikach to powiem, że to komunikacja HC08 z L9143 w liczniku Magneti Marelli (Jaeger). L9143 to sterownik produkowany przez Magneti Marelli, steruje 4ma silnikami.

Do nagrania i póżniejszego odtworzenia z innego MCU (np. Atmega) miałbym w sumie 1-2 sekundy komend.

o_Tadeusz wrote:

Os Saleae lepszy jest LA, np LA2016. Oryginał kosztuje 400..500zł i ma bufor na próbki.

Dobra zamawiam ten:

https://www.amazon.co.uk/Inno-Maker-Analyzer-Channels-KingstVIS-Instrument/dp/B07D35FNYL?th=1

Ten tani klon na początek wystarczy. Mój się przydał dwa, trzy razy w ciągu trzech lat - zależy co kto robi.
Dane możesz eksportować i przy odrobinie wprawy, bez wklepywania w Arduino nadasz to samo z powrotem
Nigdy nie użyłem więcej niż czterech kanałów na raz...taki lepszy/szybszy/więcej kanałowy jest do pracy np. z FPGA czy wyświetlaczami.

@rosak Nie wiem po co chcesz kupować jakiś analizator logiczny, jeśli masz porządny oscyloskop z dużym buforem. Chcesz rozgryźć ten protokół, czy tylko odtworzyć dane sekwencje? Jeśli tylko odtworzyć to wszystko masz już na tacy. Nagraj jakąś sekwencję oscyloskopem i spróbuj ją, odczytaną "recznie", odtworzyć przez interfejs SPI na mikrokontrolerze. Jeśli urządzenie zachowa się poprawnie to chyba osiągnąłeś to co chcesz. Analizator może się przydać, jeśli chcesz poznać dogłębnie format danych, a to może być niełatwe.
Swoją drogą, patrząc na mizerną częstotliwość taktowania tego protokołu (sądząc z opisu oscylogramów), zwykła ATMega, czytająca po SPI i wysyłająca odczytane bajty po UART do PC wystarczy. Kilkadziesiąt linii kodu załatwi sprawę.

o_Tadeusz wrote:

No właśnie, ręcznie, bo Rigol nie potrafi na zarejestrowanych danych przerprowadzić dekodowania protokołu.

Nie do końca. Dekodowanie jest dalekie od ideału,m.in. dlatego, że działa dla danych pokazanych na ekranie (przynajmniej tak było kiedy ostatnim razem to testowałem). Jednak przesuwając zarejestrowany przebieg z odpowiednią podstawą czasu da się go całego zdekodować. Oczywiście wygoda softu analizatora logicznego jest nieporównywalnie większa.
Ja bym jednak po prostu podpiął SPI procka pod te linie i przesłał odczytane wartości przez UART do PC.

Kiedy napisałem "bez wklepywania" to chodziło mi o to, że przy użyciu dwóch, trzech programów nie trzeba wpisywać niczego "z palca".
Nie takie ramki się łapało
Eksportujesz dane np. jako CSV (taki standard "Comma separated" i data as HEX), potem odpalasz Notepad++ i w zależności od potrzeb zamieniasz przecinek na co chcesz czyli zamiast CTRL+F .. CTRL+R (Find and replace)
Dla C, C++ zamieniasz przecinek na ",0x" a dla Bascom ",&H" i to wklejasz do kodu jako coś co ma odtworzyć procek wybranym interfejsem.
Szybko, łatwo i wygodnie
Czasem, ostatecznie, używam WinHEX, HEX Workshop....

Uważam, że posługiwanie się funkcją Replace powinno wejść do szkół tak samo jak powinno wejść do szkół umiejętność posługiwania się wyszukiwarką ahahahaha

Można zamieniać "#define" na "Constans" lub "If varexist" itp. jeśli ktoś wie do czego to się może przydać

tmf wrote:

Ja bym jednak po prostu podpiął SPI procka pod te linie i przesłał odczytane wartości przez UART do PC.

Jak się nie ma analizator to trzeba stosować takie protezy. Ale jednak nawet ten najtańszy 24MHz jest narzędziem, którego użyteczność trudno jest negowac. Warto kupić i mieć w szufladzie.

Debugowanie przez odbieranie innym prockiem dodaje dodatkową niewiadomą do równania . W końcu w programie na ten drugi procek też się możemy walnąć.

osctest1 wrote:

Jak się nie ma analizator to trzeba stosować takie protezy. Ale jednak nawet ten najtańszy 24MHz jest narzędziem, którego użyteczność trudno jest negowac. Warto kupić i mieć w szufladzie.

Nikt nie neguje użyteczności analizatora jako takiego. Uważamy tylko, że jeśli autor ma oscyloskop z dużym buforem (a ma), to to co chciał się dowiedzieć, już się dowiedział. Analizator nic nowego ne wniesie. Natomiast test polegający na odczytaniu wartości przez SPI, a następnie wysłaniu ich przez SPI do urządzenia docelowego i porównanie czy zachowuje się tak jak przy oryginalnej transmisji, da ostateczny dowód na to, że wszystko działa.
BTW, taki analizator logiczny na 24 MHz, to można sklecić w parę minut z procka który ma się pod ręką...

tmf wrote:

BTW, taki analizator logiczny na 24 MHz, to można sklecić w parę minut z procka który ma się pod ręką...

odważna teza, szczególnie że te odczytane dane trzeba czymś obrobic . Nawet znając protokół np. Sigrocka to bedzie troche roboty aby to wysłać do pc-ta.

Długo, długooo byłem mechatronikiem. To nie jest skomplikowane. Wystarczy wiedzieć jak działa silnik i ...wiedzieć jak działają procesorowe sterowniki.
Mimo młodego wieku bolało mnie w krzyżu co noc.
Dlatego zmieniłem coś u siebie, ale wiem co to znaczy Carprog, X-progM, firmy ELNEC i ELRASOFT...długo mozna by wymieniać

Po tym jak odwiedziłem stronę www OT (topic owner) to poczytałem, rozglądnałem się i czytam "we do not doing this for living"
Okay.
I found you young boy.
Korekta licznika to pikuś. Fachowiec czyta noty/datasheety

masz konto na MHHAUTO? (to the TO)

osctest1 wrote:

odważna teza, szczególnie że te odczytane dane trzeba czymś obrobic . Nawet znając protokół np. Sigrocka to bedzie troche roboty aby to wysłać do pc-ta.

Są niezłe programy do analizy z otwartymi protokołami. W jednej ze swoich książek dodałem przykłąd takiego analizatora na XMEGA - w pełni funkcjonalny kod, napisanie tego zajęło mniej niż oczekiwanie na kuriera z przesyłką...

Po kolei w skrócie:

tmf wrote:

Nie wiem po co chcesz kupować jakiś analizator logiczny, jeśli masz porządny oscyloskop z dużym buforem.

Wiem, że w teorii oscyloskop lepszy ale raz, że właśnie dane przepisywać na piechotę, a dwa- fajnie mieć nowy sprzęt w szufladzie Oczywiście protokół chciałbym rozgryźć ale z braku czasu do tego nie dojdzie.

tmf wrote:

Kilkadziesiąt linii kodu załatwi sprawę.

Wiem, taki był plan przed napisaniem wątku.

bart-projects wrote:

Uważam, że posługiwanie się funkcją Replace powinno wejść do szkół

A ja uważam, że jest to tak proste i oczywiste, że nie ma czego uczyć. Jeśli ktoś nie zna takich najprostszych funkcji edytorów tekstowych nie powinien pracować w żadnym państwowym urzędzie (MOPS- Panie, nas tu jest 6 a was 10000, na decyzję (pismo) musi Pan czekać 3 miesiące! - dla mnie samego to robota na 2 godziny ale odbiegam od tematu).

bart-projects wrote:

Długo, długooo byłem mechatronikiem. To nie jest skomplikowane. Wystarczy wiedzieć jak działa silnik i ...wiedzieć jak działają procesorowe sterowniki.

Nie jestem mechatronikiem, nie jest skomplikowane i wiem, jak działa silnik i sterownik. i...?

bart-projects wrote:

Mimo młodego wieku bolało mnie w krzyżu co noc.

Mnie również, i...?

bart-projects wrote:

ale wiem co to znaczy Carprog, X-progM, firmy ELNEC i ELRASOFT...długo mozna by wymieniać

Coś mi się wydaje, że kolega w sobotni wieczór przesadził z alkoholem, ale ok, ma takie prawo

bart-projects wrote:

Po tym jak odwiedziłem stronę www OT (topic owner) to poczytałem, rozglądnałem się i czytam "we do not doing this for living"

Hmm.. że moją stronę..? Kompletnie przekręcone i niepoprawne zdanie, nie mogłeś użyć CTRL+C, CTRL+V?

bart-projects wrote:

Okay.
I found you young boy.

What do you mean..?

bart-projects wrote:

Korekta licznika to pikuś. Fachowiec czyta noty/datasheety

Jest to oczywista oczywistość. Kolejne zdanie i jeszcze bardziej nie wiem co to ma wspólnego ze mną czy tematem.

bart-projects wrote:

masz konto na MHHAUTO? (to the TO)

Mam, jak i na 100 innych forach. Zdradzisz w końcu do czego zmierza Twoja logika lub jej brak..?

tmf wrote:

napisanie tego zajęło mniej niż oczekiwanie na kuriera z przesyłką...

Wierzę, choć tu kurierzy są niesamowicie sprawni, zamówiłem wieczorem a rano już było

Do rzeczy, dziękuję wszystkim za udział w temacie. Analizator leży na stole jednak nie miałem czasu nic ruszyć. Przez następne kilka dni mnie nie ma ale jak tylko wrócę do tematu dam znać, co z tego wyszło.

rosak wrote:

Analizator leży na stole

Słuszna decyzja.

rosak wrote:

wieczorem a rano już było

Kolega prime sobie wykupił

rosak wrote:

Wiem, że w teorii oscyloskop lepszy

Czy lepszy? Po prostu do czego innego służy tak naprawdę. Do oglądania przebiegów analogowych. Analizator podłączony komputera zapewnia zupełnie inny komfort pracy.

Najlepiej mieć oba i używać do tego, do czego zostały zoptymalizowane. Są oczywiście oscyloskopy mające wyrafinowane analizatory, ale niestety są to urządzenia drogie, a często sonda cyfrowa https://uk.tek.com/logic-probe jest droższa niż kilka oryginalnych sealae. ( że ne wspomnę o kilkuset euro za za Soft z bardziej zaawansowanymi funkcjami)

Kiedy napisałem "I found you young boy." to miało znaczyć coś takiego -> "Wyczuwam w Tobie młodego, butnego"
Nie nauczam angielskiego. Może moje idiomy są amerykańskie a nie angielskie.
Z innej strony, Dave EEV (tam gdzie skaczą kangury) mówi o takich ludziach "young players".

Nic się nie złość

o tym posługiwaniu się edytorem napisałem dlatego, że dla mnie to też oczywiste, proste i łatwe, ale w życiu codziennym okazuje się, że wielu tego nawet nie potrafi...

[EDIT}....a odpowiem na to "bolało mnie w krzyzu" potem przeczytałem odpowiedź "mnie też i?"
no to Tobie odpowiem. Od jakiegoś czasu nie naprawiam samochodów...i przestało mnie boleć w krzyżu.
Rób jak chcesz, tylko potem nie narzekaj

bart-projects wrote:

Wyczuwam w Tobie młodego, butnego

Młody średnio, butny absolutnie nie.

bart-projects wrote:

"young players"

Moim zdaniem niezależnie od tego ile lat poświęcił bym na naukę czy praktykę, zawsze będę young player. Zresztą Dave sam nie raz przy swoich własnych projektach natknął się na jakąś pułapkę, stając się poniekąd young player w danym temacie. Elektronika/technika zbyt szybko się rozwija, co dzień trzeba się uczyć.

bart-projects wrote:

Od jakiegoś czasu nie naprawiam samochodów...i przestało mnie boleć w krzyżu.

Rozumiem. Myślałem, że masz na myśli, że Ty siedziałeś po nocach (jak ja) podczas gdy Twoi 'konkurenci' o godzinie 17:00 zapominali o temacie. Ja nie naprawiam samochodów a liczniki. Mimo nalegań moich klientów tłumaczę, że moja 'moc' kończy się na złączu licznika Moją pracę można porównać do naprawy telefonów/laptopów etc.

bart-projects wrote:

Nic się nie złość

Spoko, nie złoszczę się.
Nie wiem tylko o co Ci chodzi z 'kalibracją liczników' czy tekstem, że fachowiec czyta datasheety.
Kiedy 1 na 500 klientów pyta mnie o zmianę przebiegu odmawiam tłumacząc, że takie rzeczy umie każdy, ja robię rzeczy których nikt inny nie potrafi.

Możesz coś więcej o sprzęcie, który analizujesz napisać?
Co to za sterowniki, co tam znajdziesz jeszcze na płytce, jakieś fotki? Parametry?

Może zamiast nich da się użyć coś innego po prostu?

Dziś się trochę "pobawiłem". Rzeczywiście logic analyzer to bajka w porównaniu do mojego oscyloskopu. Niestety niewiele zdziałałem. Moe ktoś z Was przynajmniej rzuci okiem i stwierdzi, czy to wygląda jak SPI czy nie.

Najpierw trochę więcej o układzie aby zrozumieć komunikację. Pracuję na działającym sprzęcie- licznik samochodowy. MCU za pomocą tych 3 linii komunikuje się ze sterownikiem PWM który to steruje 4ma silnikami krokowymi.
Potrzebuję 1 z nich wychylić o 400 kroków w prawo za pomocą tegoż sterownika (oczywiście odłączając w tym czasie wbudowany MCU a dane przesyłać np z Atmegi).

Na poniższym screenie widać 5 sekund. Gęsty obszar w środku to czas w którym zewnętrznie emuluję sygnał o prędkości obrotowej, wtedy MCU każe wychylić silnik od obrotów:



W powiększeniu:


Nowych problemów i niewiadomych mam teraz kilka:
1. Odstępy między taktami domniemanego zegara nie są równe, wyliczona częstotliwość wacha się od ok 230 do 260kHz.
2. podczas trwania jednego stanu niskiego w domniemanym CS/SS zegar ma długie przerwy
3. to chyba największy problem- skąd nie mając dokumentacji mam ustalić jak to wszystko poustawiać:



wiem tylko że zegar jest low kiedy nieaktywny oraz CS. Jeśli zmieniam te ustawienia program również dekoduje ale podaje inne wartości.

4. Raczej się tym nie przejmuję ale zapytam. Na poniższym screenie widać, że pomiędzy danymi, kiedy CS pozostaje high, widać regularne 'piki' zegara oraz linii MOSI o częstotliwości 400Hz, czy to normalne? Oraz to- MOSI raz jest low a raz high pomiędzy CS:



Nie wiem też, jak zinterpretować dane ale tu mogę eksperymentować. Widzę, że pierwszy bajt zmienia się 0xA0, 0xA1 itd.

Na chwilę obecną mam w planie poszukać/napisać program na Arduino który będzie wysyłał podobne bajty i zobaczę czy uda się którymkolwiek silnikiem poruszyć, jednak dobrze byłoby znać odpowiedzi na powyższe pytania.

uzi18 wrote:

Możesz coś więcej o sprzęcie, który analizujesz napisać?
Co to za sterowniki, co tam znajdziesz jeszcze na płytce, jakieś fotki? Parametry?

Dziękuję kolego za chęć pomocy. To o co pytasz zostało już napisane, w pierwszych postach oraz dokładniej w tym. Nie ma co fotek wrzucać, jest HC08 - 3 rezystory na liniach i L9143 do którego nie istnieje dokumentacja.

uzi18 wrote:

Może zamiast nich da się użyć coś innego po prostu?

Potrafię sterować tymi silnikami z samej Atmegi, to nie problem, ale nie o to chodzi w tym projekcie.

Dodano po 16 [minuty]:

Wiem już, skąd się biorą te 'tiki' 400Hz choć nie rozumiem dlaczego.
Emulując zewnętrznie prędkość obrotową silnika podaję z zewnątrz prostokąt o częstotliwośći 200Hz, wtedy widać owe 'tiki' 400Hz. Kiedy podaję 300Hz wtedy widać 600Hz. Mógłbym pomyśleć, że to zakłócena/przebicie ale nie, po pierwsze częstotliwość jest podwojona, po drugie ja podaję sygnał o wypełnieniu 50%. Hmm.. w sumie te 'tiki' pojawiają się przy zmianie stanu z Hi na Lo, myśląc w ten sposób częstotliwość by się zgadzała. Tylko czy to przebicie czy celowe działanie..

Może ten L9143 to zwykły układ sterujący dla silniczków który jako sygnał wejściowy bierze sygnał zegarowy (coś jak obrotomierz).
Liczniki mają tryb serwisowy. Np. Audi/VW itd. wchodząc testerem diagnostycznym możemy wychylić wszystkie wskazówki zegara.
Tak więc może kiedy licznik nie jest w trybie serwisowym to przekazuje impulsy a kiedy ma zrobić test zegarów wysyła płynny sygnał zegarowy od minimum do maksa.
Wiadomo że w nowszych prędkość dostaje z ABS, obrotomierz i temperature po CAN z silnika a poziom paliwa w zależności od modelu też analog lub po CAN z body...a driver może być dalej stary bo MCU to zamieni na sygnał zegarowy.
Może to nie dane. Próbowałeś tam nadać na nogę jakiś zegar 400Hz?

ad 1. Te różnice w częstotliwości wynikają zapewne z aliasingu próbkowania. Zwiększ częstotliwość próbkowania w analizatorze, a wahania powinny się zmniejszyć.
ad 2. Zegar w SPI jest nadawany tylko w trakcie nadawania danych. W efekcie może się zdarzyć, że w trakcie aktywnego sygnału CS masz dłuższe przerwy na SCK. Ważne, że SCK powinno w czasie przerwy mieć zawsze ten sam poziom logiczny - niski lub wysoki w zależności od trybu pracy SPI.
ad 3. CPOL i CPH okreśłają jeden z 4 trybów pracy SPI. Możesz to ustalić m.in. na podstawie stanu SCK i MOSI w czasie nieaktywnym SPI. Poczytaj o tych trybach pracy, to wszystko stanie się jasne. Czy masz LSB czy MSB to w sumie bez znaczenia - zmieni to wartości liczbowe, ale nie zmieni samego przebiegu.
ad 4. Zobacz te piki na oscyloskopie - czy ich kształt różni się od normalnego sygnału SCK. Jeśli mają np. mniej strome zbocza lub są nieregularnej długości i amplitudy to mogą to być przesłuchy.

bart-projects wrote:

Wiadomo że w nowszych prędkość dostaje z ABS, obrotomierz i temperature po CAN z silnika a poziom paliwa w zależności od modelu też analog lub po CAN z body...a driver może być dalej stary bo MCU to zamieni na sygnał zegarowy.

W tym konkretnym liczniku mamy w zależności od wersji oprogramowania obroty albo po CAN albo po prostokącie. Niezależnie od wersji prędkość leci po prostokącie a temperatura i poziom paliwa po dzielniku napięcia. To jest licznik z Audi TT MK1 / A3 8L ale ten sam sterownik mamy w wielu innych licznikach jak MB W168, VW Beetle, Peugeoty itp. Generalnie większość produkowana przez Magneti Marelli w latach 1998-2006.

bart-projects wrote:

Próbowałeś tam nadać na nogę jakiś zegar 400Hz?

Miałem taki zamiar dopóki nie podłączyłem analizatora również pod silnik, i tam widać na każdej nodze te same tiki więc to pewnie przesłuchy.

tmf wrote:

ad 1. Te różnice w częstotliwości wynikają zapewne z aliasingu próbkowania. Zwiększ częstotliwość próbkowania w analizatorze, a wahania powinny się zmniejszyć.

Zwiększyłem do max 200MHz i jest bez zmian.

tmf wrote:

ad 2. Zegar w SPI jest nadawany tylko w trakcie nadawania danych. W efekcie może się zdarzyć, że w trakcie aktywnego sygnału CS masz dłuższe przerwy na SCK. Ważne, że SCK powinno w czasie przerwy mieć zawsze ten sam poziom logiczny - niski lub wysoki w zależności od trybu pracy SPI.

Tak myślałem, dziękuję za potwierdzenie.

tmf wrote:

ad 3. CPOL i CPH okreśłają jeden z 4 trybów pracy SPI. Możesz to ustalić m.in. na podstawie stanu SCK i MOSI w czasie nieaktywnym SPI.

CPOL widać jak na dłoni, CPH o ile dobrze rozumiem nie da się ustalić z samego przebiegu, ale w tym momencie to jest szczegół do ustalenia.

tmf wrote:

Jeśli mają np. mniej strome zbocza lub są nieregularnej długości i amplitudy to mogą to być przesłuchy.

To już odpuściłem, ponieważ:

rosak wrote:

Miałem taki zamiar dopóki nie podłączyłem analizatora również pod silnik, i tam widać na każdej nodze te same tiki więc to pewnie przesłuchy.

Dodano po 26 [minuty]:

Na stronie ST znalazłem jedynie L9177, dużo bardziej rozbudowany i prawdopodobnie nowszy układ, ale możliwe, że specyfikacje protokołu będą podobne:

https://www.st.com/content/ccc/resource/technical/document/datasheet/group3/bf/e6/6d/ef/74/8a/40/b4/DM00400387/files/DM00400387.pdf/jcr:content/translations/en.DM00400387.pdf

Dodano po 1 [godziny] 59 [minuty]:

Chińczycy handlujący wylutami twierdzą, że to jest na I2C choć wiem, że nie ma co się tym sugerować.

Jest możliwe żeby domniemany MOSI był SDA a SCLK SCL? Tylko wtedy SS nie ma sensu.
Próbuję rozkminić zmiany w bajtach HEX/DEC i nic mi z tego nie wychodzi.

rosak wrote:

Na stronie ST znalazłem jedynie

to układ na zamówienie i nie znajdziesz do niego dokumentacji. To że numer podobny to nic nie oznacza