protokol onewire...kto slucha, kto nadaje?

[farmaceuta]

Dzięki wielkie jutro działam dalej...

[_LM_]

Jest jeszcze jedno rozwiązanie: skoro występuje tam wymiana to weź w programie od analizatora uruchom coś co dekoduje UARTA w moim logic są takie opcje więc i u ciebie muszą być

[farmaceuta]

8 minut temu, _LM_ napisał:

Jest jeszcze jedno rozwiązanie: skoro występuje tam wymiana to weź w programie od analizatora uruchom coś co dekoduje UARTA w moim logic są takie opcje więc i u ciebie muszą być

Nie do końca wiem o co chodzi z tym dekodowaniem... Chodzi Ci o to żeby widzieć np bajty w Hex itp?

[_LM_]

Masz w programie od analizatora wbudowane dodatki do dekorowania, uart, can i2c i pewnie wiele więcej. Skup się lub odpocznij 

[farmaceuta]

7 minut temu, _LM_ napisał:

Masz w programie od analizatora wbudowane dodatki do dekorowania, uart, can i2c i pewnie wiele więcej. Skup się lub odpocznij 

No no no, to mi też o to chodziło, sprawdzałem dla uart 9600 i nam te same dane co w twoim skrypcie jutro spróbuję z rozładowana bateria i się zobaczy czy się wartość dla napięcia zmieni...jeszcze mnie zastanawiają te pojedyncze bity, jest ich tam cała masa tak jak na drugim skanie który podałem...między pierwszymi 3 bajtami a następnymi 6 jest ich że ho ho...właśnie tego w twoim skrypcie nie widziałem i nie łapałem o co chodzi z tą różna ilością bajtów...ale teraz już wiem że to nie bajty normalnej transmisji, tylko właśnie co?

[_LM_]

No a co się składa na bajt? Poza tym możesz z tym skryptem zrobić co chcesz, wrzuć do ai i tak dalej. Ale skoro twój analizator potrafi to zrobić live to skrypt jest już niepotrzebny. Musiałem mieć jakieś narzędzie które pokaże mi co tam lata

[farmaceuta]

1 minutę temu, _LM_ napisał:

No a co się składa na bajt? 

No bity ale w dekodowaniu jest tylko 9 bajtów, reszta jest odczytana jako pojedyncze bity, 0/1 na zmianę losowo...tego już dekoder nie składa w bajty...jutro wrzucę skan to zobaczysz o co mi chodzi

[_LM_]

To raczej nie są losowe dane, może tam być licznik ładowań (żeby wiedzieć kiedy zaplanować uszkodzenie xD), jakieś inne rzeczy etc, sprawdź w linkach od orba. Nie wiem co tam lata, skupiłem się na jakimkolwiek dopasowaniu danych 

Edytowano 24 maja przez _LM_

[farmaceuta]

Zaglądnę do tych linków, już je widziałem ale się uważniej przyjrzę

[farmaceuta]

no i tak...udalo sie polaczyc z ladowarka czyli komunikacja dziala, sekwencja bajtow chyba tez, ale po chwili wysakakuje blad ladowania, co moze byc spowodowane blednymi danymi (raczej nie bo sa skopiowane z dobrej transmisji) lub cos z pinem od termistora bo tam tak dziwnie napiecie skacze...najpierw jest 5v, po podlaczeniu aku 3v, pozniej znika na ulamek sekundy i jest 2.9v i oscyluje miedzy 2.8-2.9v... musze to dziadostwo podpiac do oscyloskopu i sprawdzwic co tam jest tak naprawde... ponizej pliki z oryginalnego polaczenia i z polaczenia ladowarka-arduino 

mak.zip

a ponizej to co @_LM_ dal tylko z dodatkiem czytania 1-wire

onewire.zip

Edytowano 26 maja przez farmaceuta

[farmaceuta]

@_LM_ i tak...coś tam pomotałem z protokołem i termistorem który jest podpięty fizycznie z ładowarką żeby w razie czego odcięła ładowanie i doszedłem do momentu w którym już nie mam błędu ale Aku jest czytane jako pełne bo ładowarka nie ładuje a po chwili informuje że Aku pełne...tak sobie obstawiam że w tej paczce danych jest zapisane napięcie i ładowarka na starcie sprawdza sobie te dane...dane między oryginalną bateria a ładowarką wyglądają tak...

Reset presence 

3 bajty z ładowarki

32 bajty z baterii

Reset

1 bajt z ładowarki

Reset

2 bajty z ładowarki

1 bajt z baterii i koniec komunikacji aż do końca ładowania...w sumie 39 bajtów danych...

i teraz dziwne rzeczy...u mnie komunikacja z Arduino wygląda identycznie ale dzieje się takie dziwne coś ze ucina mi pierwsze 2 bajty z ciągu 32 bajtów i na ostatnich dwóch miejscach nadpisuje 0xFF, czyli ilość się zgadza ale dane są jak by przesunięte o te dwa miejsca...próbowałem robić tak żeby czekać , nadpisywać , nasłuchiwać przez te pierwsze dwa bajty, jeśli wyślę tablice 34 bajtów to wtedy wszystkie się miejscami zgadzają, poprostu nie mam tych pierwszych dwóch w analizatorze, ale tak być nie może bo na ładowarce wyskakuje błąd elektroniki (pomarańczowa dioda) robiłem dziesiątki przeróbek kodu i nie mogę dojść do efektu gdzie tablica 32 bajtów wysłanych znajduje się w analizatorze...

Do tego w skrypcie który dałeś jest odczytywanych z kolei 35 bajtów w kolejności 0xFF...(moja tablica 32 bajty)......0xFF 0xFF, nie wiem skąd one się tam biorą skoro nie mam ich w analizatorze 

Będę wdzięczny za każdą wskazówkę

[_LM_]

Ale widzisz że skrypt ma opcję negowania bitów, już pisałem żebyś sobie nie zaprzątał nim głowy bo to było do testów aby sprawdzić "zdalnie" jak ta komunikacja wygląda. Masz przecież w oprogramowaniu analizę protokołów użyj tego 

[farmaceuta]

@_LM_ trochę kombinowałem...i dziwne bo Al napisała mi kod gdzie slot czasowy wynosi ~60us , a na analizatorze slot dla master (ładowarka) wynosi ~134us , a dla slave (ardu) ~204us...i to się zgadza z oryginalną komunikacją, jedynie presence jest dłuższe o kilkanaście us dziwne bo dane wysyłam na żywca z użyciem delay (ale tego sprzętowego od cykli)...gdy zmieniłem czasy na te z analizatora to komunikacja odrazu ucichła...jeśli troszkę tylko zmieniłem czasy to otrzymywałem randomowe bajty, ale cała komunikacja praktycznie przebiegała prawidłowo...no nic, może jutro dalej coś podziałam, myślę że w tej komunikacji trzeba pogrzebać bo te bajty dwa mi dziwnie znikają na początku...

[farmaceuta]

Trochę dziwne... odczytałem komunikację z klona bms Makity i zmienił się ostatni bajt na 0xFE...uwzględniłem zmianę w kodzie ale nadal ostatnim bajtem który nadaje bateria jest 0xFF... (Kod do bólu prosty więc nie ma pomyłek...) 

A może to bateria zaczyna nadawać 3 bajty a ładowarka odpowiada 32'oma bajtami tylko to mi gdzieś nie pasuje, no bo po co ładowarka wysyłała by tyle informacji do baterii?