Dzień Dobry. Zaczynam przygody z techniką cyfrową.
Cytat:
W tym przypadku sterownik odpowie bajtem synchronizacji 0x55. Następnie odpowie bajtami kluczy 0x08 i 0x08 lub 0x96 i 0x96. Bajt synchronizacji z bajtami kluczy musi zostać potwierdzony przez mikrokontroler poprzez odwrócenie drugiego bajtu klucza.
Jak to zrobić?
Jeśli dostanę odpowiedź 0x08 i 0x08 (czyli 8 8) lub 0x96 i 0x96 (czyli 150) to jak ja mam odpowiedź? Jak odwrócić te bajty?
Temat: Jak odwrócić bajt klucza w technice cyfrowej/mikrokontrolerowej?
- Jak dostanę odpowiedź 0x08 (8 dziesietnie, 1000 bin) to po odwróceniu bajtu będzie 0001 bin, czyli 1 dziesiętnie i wartość 0x01?
- Jak dostanę odpowiedź 0x96 (150 dziesietnie, 1001 0110 bin) to po odwróceniu bajtu będzie 0110 1001 bin, czyli 105 dziesiętnie i wartość 0x69?
Czy jest jakiś program terminalowy do wysyłania i odbierania danych w postaci binarnych? Z Realterm nie mogę dojść końca przy konwersji standardów bin/dzies
Dodano po 2 [minuty]:
gregor124
Muszę zejść jeszcze niżej niż assebler - do poziomu swego mózgu i umieć to liczyć. Przy mi się to do czegoś innego (wymiana interfejsu i przeliczanie danych)
1. Jaką operację (matematyczną/logiczną) masz na myśli pod hasłem "odwrócić bajty"?
2. W jakiej technologii potrzebujesz to zrealizować (jakiś język programowania, bramki logiczne, specyficzny mikrokontroler, itp.)?
Ad1. Sam nie rozumiem tego pojęcia. Dlatego poprosiłem o pomoc
Ad2. W oknie programu terminalowego chcę by z niego "wychodziły" informacje, bajty, konkretne adresy i przez właśnie budowany interfejs (usb - com db9) - rx/tx łączyło się ze sterownikiem /kontrolerem. Szyna chyba Can.
Muszę umieć pobudzać, inicjalizować. Nim poproszę kogoś o pomoc w zbudowaniu programu (choć program.bat) muszę rozumieć matematykę i logikę niskiego poziomu programowaniu. Dlatego utworzyłem wątek w tym dziale. Jako mocno początkujący. Choć nie z wiedzą zerową.
Masz tak przekształcić dane, aby przy transmisji szeregowej, np. z bitem 7 na początku, wysłać dane z bitem 0 jako pierwszym
i odwrotnie.
Czyli kolejność
bitów 76543210
zamieniasz na 01234567
Sprzętowo z poziomu komputera (okno programu terminala - obecnie Realterm). Siedzę na dyżurach i jak mam trochę luzu to zamiast skręcać papierosy i później je wypalać lub co gorsza chlać to wolę trochę posiedzieć przy elektronice. Ale nie tak jak niektórzy myślą że tylko kupować jakieś zestawy naprawcze na internecie czy arduino. Elektronika jest tak szeroka że każdy znajdzie coś co go może zainteresować.
Gregor, dziękuję za podpowiedź. Na razie muszę przeanalizować to co napisałeś bym wiedzieć że to rozumiem.
Jeśli mowa TYLKO o odwróceniu bardzo konkretnych dwóch bajtów 0x08 i 0x96, to podstawienia na if'ach będzie zużywało mniej taktów CPU niż wielokrotne shifty.
Wielokrotne shifty są owszem rozwiązaniem bardziej generycznym, ale tu nie koniecznym.
Autorze, czy mógłbyś podać źródło Twojego cytatu z postu #1? Łatwiej byłoby przeanalizować, o jakie "odwracanie" chodzi.
Pytam, bo szczerze, nie znam protokołu komunikacyjnego (choć nie znam ich wiele), w którym wymagane byłoby czasochłonne odwracanie bitów w bajcie (a de facto nie przynoszące dla protokołu dodatkowej wartości). Bardzo prawdopodobne jest, że pod hasłem "odwracanie bajtu" kryje się negacja binarna (zamiana wszystkich bitów z 0 na 1 i odwrotnie).
Gremliny napisał:
Szyna chyba Can.
Nie wydaje mi się, biorąc pod uwagę moją wiedzę o CANie.
Dodano po 19 [minuty]:
Ok, sam znalazłem.
Chodzi o negację binarną.
Temat związany z komunikacją przez OBDII (ISO 9141-2).
Może pokaże co robię. Fizycznie. Bo chyba wszystko źle opisałem. I dlatego moje wypowiedź są rozumiane jako wypowiedzi dziwaka.
Z portu USB wychodzi port Com Db9. Ten otwiera mi komunikację Rx i Tx (oba zwarte jako nulmodem). kolory niebieski i pomarańczowy. Zielony to masa
W oknie terminala nadaję i odbieram info. Na czas testów mam zwarte rx i tx. Nulmodem działa prawidłowo. Info nadane wychodzi i wraca
Chciałbym nadać wartości binarne np 0x33 bajty (wartość 51 dzies) aby to wychodziło tak jak trzeba. By widzieć co się dzieje mam analizator danych logicznych. Do jego obsługi mam Salae Logic.
Niestety w oknie analizatora ukazuje się nie to co bym oczekiwał
Za każdym razem 0X00 error
------------------------
Co chcę osiągnąć?
Wysyłam bajt 0X33
W odpowiedzi dostaję (powinienem) bajt synchronizacji 0X55 oraz dane 0x08 0x08 (ewentualnie 0x55 0x96 0x96). Reszta jest opisana w 1 poście. Przepraszam że dopiero teraz naocznie to piszę
Dodano po 4 [minuty]:
Tak. Chodzi o OBD - Can, K, L. Celowo tego nie napisałem bo chciałem sam wszystko rozgryść. Jest to projekt dla zabawy. Nie potrzebuję bardzo gotowych rozwiązań gdyż potrzebuję wędki (ewentualnie części do niej np przysłowiowego haczyka lub żyłki). Rybę sam chcę złowić - będzie smaczniejsza. Kilka rzeczy sam już mam w wyobrażeniu. Ale utkwiłem chyba na prostej rzeczy. Dlatego poprosiłem o pomoc.
Nadajesz UARTem, a próbujesz odebrać (w Saleae) jako PS/2 bez sygnału zegarowego - stąd błąd ramki.
Po co ten PS/2?
Chyba nadal nie rozumiem, co się tu dzieje.
gps79 Tak, używam UARTa. Opis PS/2 jest tylko opisem kanału nr 0. Ale wybrana jest funkcja async serial. Mogę sprawdzić na innym canale z fuckja async serial. Chyba że ustawić inną funkcję w salae - jego tylko używam by czytać wartosću 0X....
Dodano po 4 [minuty]:
Ok. Nadałem informację 33
Zmieniłem ustawienia w salae. Takie wyniki. Noo cóż. Coś drgneło - przynajmniej nie ma samego 0X00
inot
Odpowiem głupio i beznadziejnie. Nie wiem Techniką cyfrową zajmuję się dopiero od grudnia. Znalazłem w pracy w śmieciach przeznaczonych do utylizacji 'jakąś' irdę. I tak się zaczeła fascynacja techniką cyfrową. Aż wstyd przyznać iż kiedyś kończyłem technikum... elektroniczne. Ale w życiu zajmowałem się inną działalnością. W szkole komputer był dla mnie marzeniem
Dodano po 1 [godziny] 15 [minuty]:
kindlar
Do czego ta funkcja CR służy? Mam ją w kilku miejscach w tym programie
Wypadałoby zacząć od podstaw. Przydałoby się przejść jakiś kurs odnośnie komunikacji szeregowej.
Tak na początek.
1. Co za kabel USB-DB9 posiadasz? Do jakiego standardu konwertujesz UART? +/-12V? 0/12V? 0/5V?
2. Jeśli na liniach sygnałowych będzie 12V, to możesz uszkodzić analizator logiczny.
3. Saleae Logic analizując sygnał UART zakłada, że stanem domyślnym linii jest stan wysoki, a transmisja rozpoczyna się od przejścia w stan niski (tzw. bit startu). Tego nie ma na Twoich screenach. Weź to pod uwagę.
4. Naucz się kontrolować transmisję od warstwy fizycznej i analizować sygnał. Policz ile czasu zajmuje w Twoim protokole transmisja jednego bitu. Odmierz ten czas na wykresie Saleae Logic. Sprawdź, czy zostały odebrane wszystkie bity ramki, którą chciałeś nadać, bity startu, stopu, parzystości, itd.
5. @ElektrodaBot Jakie napięcia ma sygnał OBDII k-line?
6. Nie każdy terminal szeregowy nadaje się do nadawania i odbioru transmisji innej niż szeregowa.
@ElektrodaBot Czy terminalem UART odbiorę k-line?
Wypadałoby zacząć od podstaw. Przydałoby się przejść jakiś kurs odnośnie komunikacji szeregowej.
Tak na początek.
1. Co za kabel USB-DB9 posiadasz? Do jakiego standardu konwertujesz UART? +/-12V? 0/12V? 0/5V?
2. Jeśli na liniach sygnałowych będzie 12V, to możesz uszkodzić analizator logiczny.
3. Saleae Logic analizując sygnał UART zakłada, że stanem domyślnym linii jest stan wysoki, a transmisja rozpoczyna się od przejścia w stan niski (tzw. bit startu). Tego nie ma na Twoich screenach. Weź to pod uwagę.
4. Naucz się kontrolować transmisję od warstwy fizycznej i analizować sygnał. Policz ile czasu zajmuje w Twoim protokole transmisja jednego bitu. Odmierz ten czas na wykresie Saleae Logic. Sprawdź, czy zostały odebrane wszystkie bity ramki, którą chciałeś nadać, bity startu, stopu, parzystości, itd.
5. @ElektrodaBot Jakie napięcia ma sygnał OBDII k-line?
6. Nie każdy terminal szeregowy nadaje się do nadawania i odbioru transmisji innej niż szeregowa.
@ElektrodaBot Czy terminalem UART odbiorę k-line?
Szybka odpowiedź na pytania 5 i 6
1. Napięcia na linii OBD-II K (ISO 9141-2 / ISO 14230-4): • stan domyślny (recesywny, logiczna „1”) ≈ V<sub>batt</sub> ≈ 11 … 14,4 V • stan aktywny (dominujący, logiczne „0”) < 1 V (praktycznie zwarcie do masy)
2. Zwykłym terminalem UART odbierzesz dane K-line tylko wtedy, gdy pomiędzy komputer a złącze OBD wstawisz transceiver K-line (np. L9637D, MC33290, TJA1020). Bez niego: • poziomy 0/12 V uszkodzą konwerter USB-UART lub analizator, • linia K jest pół-dupleksowa i wymaga sterowania kierunkiem, • protokół startu („5-baud init” lub „fast init”) wymaga precyzyjnych timingów, których typowy terminal nie zapewnia.
---
1. Warstwa fizyczna K-line – dlaczego nie pasuje do TTL/UART
Parametr
UART TTL (3V3 / 5V)
RS-232 (DB9)
OBD-II K-line
Stan nieaktywny („1”)
3,3 / 5 V
−3 … −15 V
≈ 12 V
Stan aktywny („0”)
0 V
+3 … +15 V
< 1 V
Topologia
dwie linie (RX/TX)
dwie linie
jedna linia (pół-dupleks)
Wymagany transceiver?
nie
MAX3232 itp.
L9637D / MC33290 / K-CAN i in.
Skutek: bezpośrednie wpięcie analizatora logicznego lub konwertera USB-TTL = niemal pewne uszkodzenie sprzętu.
---
2. Jak sprzętowo połączyć PC z K-line
1. Najprostsze: gotowy interfejs ELM327/ STN1100 (USB, Bluetooth). • Zaleta – obsługuje ISO 9141-2, ISO 14230-4, CAN. • Wada – „czarna skrzynka”, utrudnia naukę warstwy niższej.
2. DIY – transceiver + mikrokontroler: • L9637D (SO-8) lub MC33290 (SO-14) – konwertują 0/12 V na 0/5 V i odwrotnie, mają detekcję czasu dominacji oraz zabezpieczenia ESD. • Dowolny MCU z UART (ATmega, STM32, ESP32). • Układ steruje linią TxEnable (dominacja) i odbiera Rx – to już klasyczne 5 V/3 V3 UART. • Inicjalizację 5-baud najłatwiej zrobić w firmware; fast-init można zrealizować impulsami GPIO.
3. Minimalistycznie – TJA1020 (LIN, ale zgodny poziomowo) lub tranzystor + rezystor 510 Ω pull-up do 12 V. • Działa, lecz brak filtrów i ochrony – ryzyko zakłóceń z instalacji samochodu.
Przykładowy schemat (MC33290 + CH340):
Kod: Text
Zaloguj się, aby zobaczyć kod
(Upewnij się, że masa PC jest wspólna z masą pojazdu – przez izolację galwaniczną lub kabel diagnostyczny z bezpiecznikiem).
---
3. Konfiguracja Saleae / innego analizatora
1. Podłącz wyjście RXD transceivera (0/5 V) do jednego kanału analizatora. 2. Analyzer → Async Serial: • Bit rate: 10400 bps (standard ISO 9141-2) lub 9600/10400 przy pracy ELM-em, • 8 N 1, LSB first, brak inwersji, • Stan spoczynku wysoki (pull-up). 3. Pamiętaj, że po stronie magistrali ECU ⇄ Tester bity są odwrócone czasowo względem standardowego UART (MSB/LSB), ale większość transceiverów i ELM-ów wykonuje tę konwersję; gdy pracujesz „gołym” MCU, musisz odwrócić kolejność bitów software’owo (patrz pkt 4).
1. 5-baud init (starsze ECU, ISO 9141-2): • Tester wysyła w prędkości *dokładnie* 5 Bd (!) bajt adresu (np. 0x33). • ECU odpowiada 0x55 + KW1 + KW2 (+ negacje) już 10400 Bd. 2. Fast-init (ISO 14230-4 „KWP2000”): • Tester ściemnia linię K do 0 V na 25 ms, następnie zwalnia. • Po 25 … 50 ms rozpoczyna rozmowę 10400 Bd. Oba tryby wymagają precyzyjnych timingów, których RealTerm/TeraTerm nie wygeneruje; muszą to zrobić firmware MCU lub ELM/ STN.
---
6. Polecane narzędzia programowe
• RealTerm – wysyłanie ramek w HEX, break, RTS toggle. • Tera Term v5 – makra, skrypty, logowanie. • SavvyCAN / BusMaster – gdy przejdziesz na CAN. • Saleae Logic 2.x – plugin „OBD-KLine (ISO 9141)” ze strony community (aktualny 04‒2025).
---
7. Typowe pułapki
1. Brak wspólnej masy pomiędzy PC a pojazdem. 2. Ustawienie inwersji sygnału w Saleae (powinno być „Non-Inverted”). 3. Próba pracy „full-duplex” – K-line jest half-duplex, linia ma być w stanie wysokim, gdy nikt nie nadaje. 4. Zasilanie interfejsu z portu USB bez izolacji – przepięcia w aucie > 35 V mogą ubić laptop.
---
8. Co dalej?
• Zbuduj mały adapter K-line→USB na MC33290 + CH340/FT232; udostępni pełny, surowy dostęp do magistrali. • Po opanowaniu 5-baud init napisz proste skrypty (Python + pySerial) do wysyłania Service 01 PID 0C (obroty) lub zwrotu DTC. • Rozważ przejście na CAN-BUS (ISO 15765-4) – od rocznika ~2008 w UE obowiązkowy.
---
Podsumowanie
– Linia K pracuje na 0/12 V, wymaga transceivera; bez niego UART czy analizator logiczny zostaną uszkodzone. – Sam terminal szeregowy *może* służyć do obserwacji ramek, ale tylko poprzez prawidłowy interfejs K-line. – Zadbaj o inicjalizację, odwrócenie bitów i pół-dupleks.
Powodzenia w dalszej eksploracji diagnostyki OBD-II! Jeśli natrafisz na konkretne problemy z inicjalizacją 5 Bd lub konfiguracją MCU – daj znać, doprecyzujemy kod lub hardware.
Możesz mnie wywołać w każdym temacie pisząc @ElektrodaBot. Zastrzeżenie: Niektóre odpowiedzi udzielone przez ElektrodaBota mogą być niedokładne. Elektroda nie ponosi odpowiedzialności za dokładność, rzetelność ani kompletność prezentowanych informacji. Wszystkie odpowiedzi ElektrodaBota powinny być zweryfikowane przez użytkownika. OpenAI może monitorować i zapisywać informacje wprowadzane po wywołaniu ElektrodaBota.
Dzień Dobry. Przepraszam za długą przerwę ale miałem dużo innych zajęć. Wszystko przeczytałem, przeanalizowałem i próbowałem wdrożyć. Po kolei:
- Jakoś nie mogę się przekonać do arduino. Poprostu. Wybaczcie mi
- Do obsługi portu Com używam UARTa. Jest to napięcie 5V. Zdaję sobie sprawę że napięcie pracy OBD2 to12-15V.
Myślałem by stworzyć póżniej jakiś układzik (przejściówkę-adapter) oparty u układ scalony L9637 lub TJA1020.
- Póki co do obsługi OBD używam gotowego kabla usb-obd2 firmy viakem który współpracuje z (chyba) darmowym VCDS-Lite. Ale chciałem coś samemu stworzyć.
- Na chwilę obecną szczytem moich marzeń odnośnie tego projektu jest odczytanie jakiejkolwiek wartości ze sterownika/sterowników auta, np. Ecu
- Przewód usb-com db9 użyłem by widzieć jak się to wszystko zachowuje
- Dzięki temu tematowi dowiedziałem się że chcąc połączyć się usb-obd zachodzi wiele konwersji, tj jedynka logiczna jest zamieniana na zero, zamiana standardów Asci/hex/bin. Jakakolwiek pomyłka znaczka i transmisja kończy się niepowodzeniem. Dlatego na analizatorze Salae widziałem tyle informacji które wprowadzały mnie w błąd.
- Salae użyłem w następujący sposób. Przejściówkę usb-db9 ustawiłem w menadżerze urządzeń jako port Com4. Tak samo w opcjach portu vcds-lite. Przewód nadawczy Tx podpiąłem do salae (wpięty do innego wolnego portu usb), co ciekawe analizator widział dane bez dodatkowej masy. Dałem VCDS opcję inicjalizacji. Obserwowałem informacje na analizatorze. Próbowałem z programów terminalowych wysłać 0x33. Czyli okno terminala --> przewód usb-obd. Port com był otwarty. Info wychodziło. Ale auto nie dawało żadnej odpowiedzi. Dostałem tu różne podpowiedzi.
Spodobało mi się to co napisała sztuczna inteligencja. Ale nie za bardzo wiem co z czym się je. I tym sposobem odkryłem właśnie czat GPT Oraz jego możliwości. No cóż lepiej później, jak nigdy Człowiek całe życie się uczy Więc tym tematem jedno chciałem zrobić - odkryłem i nauczyłem się czegoś innego.
Postanowiłem na stronie czatu poprosić o jakiegoś gotowca. Najpierw pobawiłem się czatem a potem poprosiłem o program typu BAT.
Dostałem takie coś.
Dzięki Wam dostałem więcej wiedzy i umiejętności niż bym przypuszczał i oczekiwał. Celu jeszcze nie osiągnąłem. Ale za to zdobyłem inne wartościowe informacje. Na razie muszę trochę odpocząć. Nawet jak mi nie wyjdzie to i tak uważam ten czas który poświęciłem za coś wartościowego. Temat na razie pozostawię otwarty.
Dziękuję za wszystkie odpowiedzi - nawet te nieco złośliwe
✨ Dyskusja dotyczy problemu odwracania bitów w bajcie klucza w technice cyfrowej i mikrokontrolerowej, szczególnie w kontekście komunikacji z protokołem OBD-II (ISO 9141-2). Autor pyta, jak odwrócić bajt (np. 0x08 lub 0x96) otrzymany ze sterownika, aby potwierdzić go mikrokontrolerem. Wyjaśniono, że chodzi o odwrócenie kolejności bitów w bajcie (bit 7 staje się bitem 0 i odwrotnie), a nie o negację bitową. Podano przykłady konwersji binarnej i funkcję w języku C do odwracania bitów bez użycia pętli, wykorzystując maski i przesunięcia bitowe. Poruszono także kwestie sprzętowe i programowe, w tym użycie terminali szeregowych (np. Realterm, Tera Term) oraz analizatorów logicznych (Saleae Logic) do testów transmisji UART na poziomie fizycznym. Zwrócono uwagę na różnice napięć i standardów sygnałów w interfejsach OBD-II (linia K) oraz konieczność stosowania odpowiednich transceiverów (np. L9637D, TJA1020) do konwersji poziomów napięć i sterowania kierunkiem transmisji. Podkreślono, że do poprawnej komunikacji potrzebna jest znajomość protokołu, timingów i warstwy fizycznej. Autor planuje samodzielnie tworzyć interfejs USB-COM DB9 do komunikacji z ECU pojazdu, ucząc się podstaw niskopoziomowego programowania i elektroniki cyfrowej. Wskazano, że odwracanie bitów jest operacją logiczną realizowaną programowo lub sprzętowo, a do testów i automatyzacji komunikacji warto używać terminali z możliwością skryptów. Podsumowanie wygenerowane przez AI na podstawie treści dyskusji.
Techniką cyfrową zajmuję się dopiero od grudnia. Znalazłem w pracy w śmieciach przeznaczonych do utylizacji 'jakąś' irdę. I tak się zaczeła fascynacja techniką cyfrową. Aż wstyd przyznać iż kiedyś kończyłem technikum... elektroniczne. Ale w życiu zajmowałem się inną działalnością. W szkole komputer był dla mnie marzeniem
