Witam wszystkich

Nie wiem czy dobrze mi się wydaje ale temat który zamierzam przedstawić jeszcze na forum się nie pojawił.

W miarę czasu i możliwości postaram się przedstawić, może nie mające praktycznego zastosowania, ale z pewnością interesujące ciekawostki na temat algorytmów działania naszych ECU.

Przykłady będą podawane na podstawie komputera z 1.1 SPI.

Na początek może krótkie wprowadzenie:

Często powiedzenie ze w aucie znajduje się "komputer" sterujący praca silnika, jest uważane za eufemizm szczególnie w odniesieniu do dzisiejszych komputerów PC. Jednak po zagłębieniu się w "program" działania - w miarę nieskomplikowanego - ECU do naszych autek, można dojść do wniosku ze jest on bardziej złożony od niejednego programu komputerowego.

Tak naprawdę sercem układu który jest rozumiany jako ECU auta jest procesor Motorola 68HC11F1, to praktycznie jedyny element "cyfrowy" znajdujący się na płytce. Pozostałe elementy to elementy do "przetwarzania" sygnałów analogowych.

Procesor działa z "oszałamiająca" prędkością 16Mhz, jednak jego konstrukcja sprawia ze tak naprawdę jest to 4 Mhz. Hmmm mój pierwszy komputer 286 działał z prędkością 20 Mhz, wiec 4 Mhz wydaje się dosyć małą wartością, biorąc pod uwagę zadania ECU.

Dodatkowo jest on wyposażony w zawrotna ilość pamięci : ramu - 1024b(bajty!) + eepromu - 512b.

Do niewątpliwej zalety można jedynie zaliczyć sprzętowa obsługę pamięci zewnętrznych, które z poziomu programowania są praktycznie równoznaczne z pamięcią wewnętrzną.

Posiada on również wbudowany przetwornik ADC ( sygnałów analogowych na postać cyfrowa ), którego przykład wykorzystania zostanie przedstawiony w dzisiejszym odcinku.

Z poznanych do tej pory różnych mikroprocesorów, Motorola wyróżnia się dosyć ciekawą cechą - posiada wspólną przestrzeń adresową dla wszystkich podzespołów. Intuicyjnie rozdziela sie kod programu, ram, eeprom na osobne adresy od 0x0000. W przypadku Motoroli pod konkretnym adresem, w zależności od konfiguracji, może znajdować się ram lub eeprom, lub jakiekolwiek urządzenie zewnętrzne. Na takiej właśnie zasadzie działa eeprom, o którym mówi się że znajdują się tam mapy - a tak naprawde w eepromie siedzie cały kod maszynowy wykonywany przez procesor, ponieważ nie posiada on pamięci wewnętrznej FLASH. Dzięki temu że posiada wbudowany kontroler pamięci zewnętrznej, jest to rozwiązanie lepsze, szczególnie dla różnej maści "badaczy". W prosty sposób można uzyskać pełny kod maszynowy procesora po prostu sczytując wyjęty eeprom.

Oczywiście analiza kodu maszynowego jest praktycznie niewykonalna przy takim skomplikowaniu kodu, można zastosować specjalne programy ( deasemblery ), które zamieniają kod maszynowy na instrukcje asemblera ( o tym szczegółowiej w następnej części ), który już jest łatwiej zrozumiały. Jednak ogarnięcie całości kodu jest dalej dosyć trudne. Niestety poziom wyżej już przejść się nie da, prawdopodobne źródła w jakimś języku ( np C ), posiadają tylko producenci oprogramowania.

Tak więc pozostaje żmudne analizowanie asemblera, co pochłania bardzo dużo czasu - rozgryzienie zaledwie kawałka kodu wraz z wcześniejszym poznaniem samego procesora zajęło mi parę miesięcy.

Pomimo dość skromnych możliwości sprzętowych, jak pokazuje praktyka jest to procesor niezwykle niezawodny i realizujący naprawdę skomplikowany program, bez zbędnych problemów.

To tyle kwestia wstępu, a teraz jeden z przykładów "od podszewki" algorytmu obsługi odczytu temperatury powietrza. Zamieszczony przykład to 100%-owa wizualizacja kodu maszynowego stworzona automatycznie. Tak wiec to co jest na obrazku są to informacje z "pierwszej ręki", które odpowiadają fizycznemu kodowi wykonywanemu przez procesor. Żeby uprościć zrozumienie algorytmu zamiast instrukcji asemblera przedstawiam już interpretacje "przełożona" na język zrozumiały dla człowieka.

1. Czy włączone obejście procedury obsługi błędów czujnika IAT.

2a. Czy odczytane napięcie z czujnika jest większe od maksymalnego

2b. Wyczyść bieżący i tymczasowy błąd IAT

3a. Czy odczytanie napięcie z czujnika jest mniejsze od minimalnego

3b Ustaw błąd zwarcia do plusa

4. Ustaw błąd zwarcia do masy

5. Czy wcześniej wystąpił tymczasowy błąd odczytu IAT?

6a. Ustaw tymczasowy błąd odczytu IAT

6b. Ustaw bieżący błąd odczytu IAT, zapisz informacje o błędzie w EEPROMIE.

7. Koniec procedury

Po zweryfikowaniu odczytu, następuje jego przeskalowanie w celu uniknięcia błędów pomiarów.

wartość_napięcia = wartość_napięcia + ( (wartość_napięcia - aktualny_odczyt_napięcia) * 0,25 )

Następnym krokiem jest wyznaczenie indeksu dla odczytanej wartości napięcia na podstawie tzw. mapy.

Algorytm wyliczeń nie będzie przedstawiony, ponieważ mam nadzieje że wiadomo o co chodzi. Np. dla wartości 63 będzie to indeks 4 + procent odległości pomiędzy kolejnym indeksem.

Po wyliczeniu indeksu z kolejnej mapy na jego podstawie jest odczytywana i zapamiętana wartość temperatury = wartość z mapy - 40C.

Po wyznaczeniu temperatury IAT, następuje procedura weryfikacji.

0. Wczytaj wartość temperatury z mapy.

1. Czy oznaczony bieżący błąd odczytu IAT

2a. Czy wyczyszczony tymczasowy błąd odczytu IAT

6. Idź dalej

2b. Czy oznaczony błąd odczytu WATER

3. Wczytaj temperaturę WATER. Czy temperatura WATER < od 38C

4. Wczytaj 38C

5. Zapisz wczytaną wartość jako aktualna temperaturę IAT.

7. Koniec procedury

I to by było tyle w dzisiejszym odcinku. Prosty odczyt napięcia i zamiana go na wartość w C, nie jest taka banalna jak by można było się spodziewać.

Jak widać możliwe jest dopasowanie się do charakterystyki czujnika, oraz nieliniowości odczytywanej temperatury.

I co ważniejsze jak widać domyślna temperaturą przyjmowaną przy braku czujnika jest 38C. Wygląda na to że jest to optymalna temperatura kiedy, silnik pracuje najekonomiczniej, ale to tylko moje domysły.

Warto sprawdzać wartość rzeczywistą tego parametru, ponieważ, dla przykładu pomiary temperatury w dolocie w moim autku pokazywały ponad 50C.

dla mnie to ciornyja magia

czekam na kolejne odcinki

pozdr.

podstawy programowania

mialem do czynnienia jedynie z programowaniem w pascalu - na tej samej zasadzie sie opiera

fajna lektura czekam cierpliwie na inne tryby pracy ECU tj. rozgrzewanie, przyśpieszanie, hamowanie silnikiem, pętla zamknięta, tryb awaryjny

fajne, moze teraz część ignorantów zrozumie czemu "alledrogo-chip" działa i moze dac te pare kuni

pzdr

Pierwszy raz Tomku ktoś dzieli sie wiedzą na forum *normalnie.....

jak to działa od podszewki naprawde chyle czoła szacun

Witam ponownie !

Jako że już od jakiegoś czasu korciło mnie żeby troszkę podgryźć ECU od 1.2, postanowiłem sobie zerknąć na adekwatną funkcje obsługi podaną w tym wątku. Oczekiwałem bardzo podobnej procedury, gdyż wydaje mi się ona bardzo przejrzysta, mało skomplikowana i przez to szybka w działaniu. Jakież było moje zdziwienie kiedy zobaczyłem jak tam przedstawia się sprawa. Za chwilę szczegóły ale pierwszy wniosek nasuwa sie od razu - w porównaniu do ECU 1.1 , 1.2 działa chyba tak wolno jak Windows na 32MB ram-u .

A teraz trochę szczegółów :

Najpierw tak samo jak w 1.1 odczytujemy wartość napięcia na czujniku. Następnie weryfikujemy odczyt... i tu pierwsze zdziwienie kodu sporo przybyło i wogóle tak prosto to już nie wygląda .

Ale po kolei, poza ekranem znajduje się część gdzie sprawdzane jest czy napięcie nie wyskoczyło poza min i max granice ( zwarcie do masy lub plusa ). Jeżeli mieści się w granicach to pojawia się pierwsza nowość : sprawdzana jest różnica w napięciu pomiędzy aktualnym i ostatnim odczytem. Jeżeli przekroczy stała wartość ( 0x80 ) to zostaje stwierdzony bład zakresu, i w zależności czy wystąpił już wcześniej, albo bierzemy jako aktualną wartość poprzednią, i zapamiętujemy błąd, lub też zwiększamy lub zmniejszamy ostatnią wartość jedynie o 0x02.

W tym miejscu znajduje się również odejście przy zaznaczonym bicie w byte_0_72, ale o tym za chwile.

Drugą możliwością błędu, oprócz za dużej różnicy pomiędzy odczytami, może być właśnie przekroczenie dopuszczalnego zakresu napięcia - wtedy podejmowane są bardziej radykalne kroki . ( Lewa część wykresu ), po zdiagnozowaniu błędu, zaznaczany jest jednorazowo bit w byte_0_8A i inicjalizowany licznik ( 8D,8E ). Jako aktualną wartość bierzemy wartość ostatnią.

Tu rownież jest odejście w zależnosci od byte_0_72, które oznacza wzięcie odczytu z czujnika wody, jeżeli > 0x72 , lub też 0x72. Nie mam pewności ale tutaj chyba wartości są w F* a nie w C*.

Tylko teraz pozostaje pytanie w którym miejscu ustawiany jest byte_0_72, który jak widać decyduje czy jesteśmy w stanie "błędu", bez wzgledu na to czy kolejny odczyt jest prawidłowy czy nie.

Do tego celu przyda się kolejny schemacik

Z poprzedniego schematu widać że w przypadku błędu zakresu, ustawiany jest jednorazowo bit w byte_0_8A, i teraz w przypadku stwierdzenia wystąpienia aktualnie błędu , jest zmniejszany byte_0_8E, natomiast za każdym razem pomniejszamy licznik 8D. Jeżeli dojdzie do zera, sprawdzamy również czy wyzerował się 8E, ( jeżeli tak idziemy w prawo ). Za pierwszym razem ustawiamy bit byte_0_72 ( czyli włączamy pobieranie wartości z czujnika wody ), i ustawiamy ponownie liczniki, na wartości zależne od błędu którego czujnika. Jeżeli i w tym wypadku po upłynięciu określonego czasu ( 8D ) , zostanie wyzerowany 8E, to prawdopodobnie zostaje to zapamiętane w eepromie , oraz odblokowujemy bit w 8A.

W przypadku gdy 8E się nie wyzeruje zostaje zwolniona blokada awaryjnej obsługi czujnika IAT ( bit w byte_0_72).

Trochę to wygląda skomplikowanie ale w skrócie :

Odczyt napięcia na czujniku jest weryfikowany na dwa rodzaje - duża różnica między odczytami, mała szkodliwość, więc jedynie korygujemy ostatni odczyt o dużo mniejszą wartość niż wynika z aktualnych odczytów. Natomiast w przypadku błędu samego odczytu, możemy określić czas na jego powrót do prawidłowego działania i ilość błednych odczytów która definitywnie go dyskawilifikuje. Czyli najpierw 4 odczyty i przy 3 błędnych ustawiamy już wartości dużo dłuższe wzięte z mapy dla IAT będzie to 0x4C(8D) i 0x16 ( 8E ), jeżeli po tym czasie dalej odczyt nie jest wiarygodny zostaje zapamiętany błąd na stałe. Jednak w przypadku gdy czujnika "załapie", błędu nie będzie.

To chyba tyle, traktuje to jako ciekawostkę, co dziwne wydaje mi się że ECU 1.2 jest starsze od 1.1, więc wygląda na to, że programiści odeszli od takich "skomplikowanych" procedur obsługi błędów. Możliwe że właśnie ze względu na problem szybkości działania, bo procedura zajmuje dużo więcej czasu i jest podobna dla wszystkich czujników. A ECU przecież ma dużo więcej i to ważniejszych działań do wykonania.

Pozdrawiam

Acha opis powstał na szybko, więc jeżeli przypadkiem komuś chciałoby się zweryfikować to co napisałem, będę wdzięczny za wszelkie poprawki.