tomiwroc6

Skoro światło dzienne ujrzał już taki temat to myślę że można coś dodać i od siebie. Tak wogóle to również polecam ten program ze względu na duże możliwości konfiguracyjne. Co zresztą zaraz zaprezentuje na przykładzie. Na początek główna zasada. Wiadomo jest że ECU przechowuje sobie dane nastawne zależne od parametrów pracy. Ze względu na małą pojemność sterownika trzeba było pójść na kompromis pomiędzy ilością ( szczegółowością ) danych a zajętym przez nie miejscem. Czyli np. nie podajemy wartości dla obrotów z dokładnością do 10 RPM tylko dzielimy cały zakres na np. 16 części , a wartości pomiędzy wartościami bazowymi wyliczamy na podstawie interpolacji. Dzięki zastosowanej technice, że podział nie musi być liniowy czyli nie dokładnie co RPM/16 możemy dać większą szczegółowość w danym zakresie ale mniejszą w innym. No i zawsze można zwiększyć rozdzielczość zmieniając zakres z 16 na np 24 ( kosztem objętości pamięci). System oparty jest na indeksach. Czyli za pomocą specjalnego przypisania, wartości X przypisujemy dany indeks bazowy i przesunięcie względem kolejnego. Czyli coś jak dzielenie całkowite i reszta z dzielenia. Przypisanie to jak wspomniałem może być dowolne ( nieliniowe ) Taki przykład : Dla wartości od 0...10 możemy zrobić mapę przypisania np. 0 , 2 , 6 , 8 Co znaczy tyle że dla wartości do 2 indeks będzie 0 dla wartości 1 dokładnie 0.5 wartości pomiędzy 2 a 6 dostaną wszystkie indeks 1. + oczywiście reszta z dzielenia 0 = 0 1 = 0.5 2 = 1.0 , 3 = 1.25 , 4 = 1.5 , 5 = 1.75 , 6 = 2.0 I teraz przechodząc do sedna sprawy, wczytując do programu tablice korekcji czasu wtrysku zależną od obrotów i ciśnienia za dużo w sumie nie wiemy . Nawet znając tablice konwersji MAP i RPM na obroty zawsze to trzeba sobie jakoś w pamięci przeliczać na odpowiednią komórke. Tutaj z pomocą przychodzi program, gdzie dla każdej osi można przypisać tablice konwersji na indeks, braną z tego samego wsadu. Wtedy dostaniemy ładnie opisaną oś. Dla przykładu zdefiniujemy sobie oś obrotów. Ponieważ obroty są opisywane przez czas obrotu w us dobrze by było sobie to przeliczyć na prawdziwe RPM. Tutaj również jest to możliwe za pomocą edytora konwersji wartości za pomocą zdefiniowanych obliczeń. Dzięki takim zabiegom mamy ładnie i czytelnie opisany wykres. To tyle tak na szybko, jeżeli są jakieś błędy to oczywiście oczekuje na sprostowanie, bo chciałem to zrobić szybko w odpowiedzi na zaczęty wątek i mogły się wkraść jakieś nieścisłości

> Czekałem aż dasz się sprowokować i podzielisz się swoim zasobem wiedzy Nie będę tu pisał swojej > interpretacji tego co napisałeś, bo zamieszam jeszcze bardziej, mi się w każdym razie wszystko > zgadza, w szczególności z tym x2. > Co do symetrii pracy tłoków. No to jest faktycznie tak jak dywagowałem wyżej i cylindry dostają > "nierówną" dawkę paliwa, równą tylko parami. Moje pytanie jest, skoro nie ma czujnika > położenia wałka rozrządu w 1.2MPI to ta para cylindrów, która dostaje paliwo "bezpośrednio" > będzie przy każdym odpaleniu silnika losowa i potem zostaje na cały czas pracy silnika po > odpaleniu, dobrze myślę? Nie bardzo, bo to dziala tak jak cewki, ECU jest w stanie ustalic ktora cewke odpalic tak samo jest z para wtryskow, zawsze dzialaja w cyklu z jedna konkretna cewka. Polozenie walka jest potrzebne dopiero przy pelnej sekwencji zeby ustalic ktory tlok z pary jest w gorze. Natomiast ktora para jest w gorze widac po polozeniu kolka rozrzadu ( przerwa w zebach punktem odniesnienia ) Tak bardziej sie zastanawiajac to jest to problematyczne w momencie kiedy wyliczona potrzebna dawka juz jest dluzsza od czasu suwu. Wtedy przemnozenie przez 2 zuplenie nic nie daje, wtryski powinny dzialac synchronicznie zeby zwiekszyc dawke

Ponieważ aktualnie omawiany temat zrobił sie dla mnie ciekawy, dorzuce jeszcze od siebie pare przemyslen zeby jeszcze sprawe zagmatwac. Wydaje mi sie ze w testowym idealnym "swiecie" skoro silnik pracuje na zasadzie ze kolejno tloki wchodza w faze zasysania mieszanki wlasnie w momencie kiedy tlok przekracza GMP i otwiera sie zawor dolotowy wtedy powinien zostac otwarty wtryskiwacz. Tlok konczy swoj suw i wtryskiwacz przestaje dzialac. Czyli maksymalny czas w jakim moze zostac dostarczona mieszanka to czas 1/2 obrotow silnika. Potem sytuacja powtarza sie na kolenych cylindrach. Tak jest w przypadku pelnej sekwencji. Aczkolwiek trzeba wziac pod uwage ze zanim tlok zacznie zasysac mieszanke wczesniej znajduje sie w fazie "wydalania" spalin czyli zawor dolotwy jest zamkniety i wtedy mozemy juz na "zapas" wtryskiwac paliwo. I teraz przechodzac do sedna sprawy jezeli rozwazymy system full-group czyli 4 wtryski zalezne od siebie to w momencie kiedy potrzebny jest czas wtrysku dluzszy od czasu suwu tloka powstaje sytuacja kiedy non-stop leje sie benzyna w kazdy cylinder , bez wzgledu na aktulna prace tloka. Moze to brzmi troche hmm dziwnie ale jakby sie zastanowic to przeciez nie dzieje sie nic zlego bo to zadaniem walka rozrzadu jest tak ustawiac zawory aby nie dopuscic mieszanki do cylindra w zlym momencie ( chociazby kompresji tejze ). Tak w przypadku kiedy brakuje benzyny w mieszance jest to sytuacji normalna i zapewne sekwencja tez potrafi pracowac w takim trybie, jednak przy normalnej pracy nie potrzeba tyle benzyny i wtedy w full-group powoduje nadmierne zuzycie paliwa poniewaz niepotrzebnie jest wtrysk na pozostale cylindry. Co ciekawe, chociaz to mozna ustawic w programie, niektore ECU "dziwnie" steruja wtryskami. W przypadku full-group jest tak ze wyliczany jest czas wtrysku, ktory nastepnie jest mnozony x 2 i wtryski pracuja dluzej ale co drugi suw tloka. Troche to dziwne bo wychodzi ze zamiast kazdy cylinder dostawac wtrysk "bezposredni" ( czyli przy otwartym zaworze ), dostaja tak tylko cylindry z jednej pary. Jako fana symetrii , bardzo mnie to zniesmaczylo . I na koniec jeszcze jedna dygresja, widoczna glownie przy maly obrotach wezmy 1200rpm czyli suw tloka co 25ms przy potrzebnym czasie wtrysku okolo 1ms. Teraz pytanie kiedy otworzyc ten wtrysk , mamy duzo czasu wiec duzo mozliwosci. To jest sytuacja odwrotna do zaplonu tam sie patrzy na jego moment ( kat wyprzedzenia ) a nie na dlugosc iskry. Przy wtrysku patrzy sie na dlugosc ale nie na jego kat wyprzedzenia, ktory jednak przy niskich predkosciach tez ma znaczenie

> wystarczyc, tymbardziej, ze nie bedziesz przeciez uaktualnial > tych map w czasie jak samochod jest w ruchu. No wlasnie to pierwsza rzecz w ktorej sie nie zroumielismy . Ogolnie moje podejscie jest takie, mapy juz zainicjowany RAM do ktorego wgrana jest zawartosc eeproma i odpalamy auto. ECU w czasie jazdy pracuje juz tylko na RAM-ie , wiec oprocz odczytuj moze tez zapisywac do "EEPROMA". Skoro auto juz chodzi to pracuje na jakiejs mapie, i teraz stwierdzamy ze trzeba poprawic jedna z nich. I tutaj drugie nieporozumienie - nie wysylamy "paczki" danych do zapisu tylko robimy to zawsze po 1 bajcie, ktorego poprawny zapis weryfikujemy od razu. Tak wiec blad moze pojawic sie tylko w jednej komorce jednej mapy. A konkretniej ECU po prostu nie zapisze zmiany 1 bajta. ( co samo w sobie nie stanowi zadnego problemu - auto bedzie pracowalo bez zadnych zmian). Wtedy wysylamy po prostu go jeszcze raz. Wydaje mi sie ze pakietowe wysylanie danych po iles bajtow nie ma sensu. Po 1 bajcie jest duzo prosciej i bardziej nie zawodnie, a przy malej ilosc danych do przeslania szybkosc nie jest taka wazna. Czyli algorytm wyglada tak : Wysylamy cztery bajty po RS-ie. [0] zapis/odczy [1] adrH [2] adrL [3] wartosc jezeli po czwartym bajcie dostaniemy spowrotem _wartosc_ ([3]) , to zapis poprawny, W przeciwnym wypadku wysylamy jeszcze raz. To jest po stronie PC. Jak wyglada obsluga po stronie ECU juz napisalem wczesniej. Teraz jasniej wyjasnilem o co mi chodzi ? Bo wydaje mi sie ze problem jest napewno rozwiazany . Poki co to oczywiscie caly czas tylko na papierze - od miesiaca probuje zbudowac zwykly emulator eeproma, tylko ze jak to z teoria bywa wszystko logicznie bylo proste, jednak z wykonaniem caly czas jest problem. Dlatego zdecydowalem sie odejsc od modyfikacji eeproma z zewnatrz, na rzecz zmian w nim poprzez ECU (co i tak bylo rozwiazaniem docelowym), dzieki czemu odpadnie problem synchronizjacji.

> No, super, ale to ci dalej nie rozwiazuje problemu przerwanej > komunikacji i mapy zapisanej do polowy. Mozesz oczywiscie > sledzic to po drugiej stronie, ale porzadnie napisany program > ecu powinien o to sam dbac. Hmm, no nie wiem gdzie jest problem, przy takim programie jak napisalem wczesniej ladujemy dane bit po bicie sekwencja znakow np.[00][00[00][FF] ( zapis pod adres 0000 wartosci FF ) a ECU wykonuje zapis do pamieci a nastepnie odsyla wartosc odczytana rowniez z tego adresu. Czyli jezeli po 4 bajtach zostaje odeslana wartosc ktora przeslalismy do zapisu mamy poprawna werfikacje zapisu 1 bajtu. Jak bajt nie zostanie odeslany trzeba go wyslac ponownie. Mozna jeszcze dodac zabezpiecznie po stronie ECU co do maksymalnego czasu oczekiwania na kolejny bajt z sekwencji, zeby po zerwaniu komunikacji w polowie sekwencji miec pewnosc ze ECU powroci do poczatku sekwencji a nie np. wezme 1-szy bajt kierunku jako adres. Moim zdaniem to w zupelnosci rozwiazuje problem wadliwej komunikacji.

> Znaczy, chcesz przez to powiedziec (bo dalej mi sie nie chce zagladac > w datasheet (dla pocieszenia - mam wydrukowany)), o to to , tak się złożyło że swoją zabawe z tym zacząłem w okresie wakacji, więc ludzi dziwnie się patrzeli na moją lekturę na plaży > ze jest tak > samo jak ze standardowym RAM-em, tylko jest pod innym adresem i > stad moze byc zaklopotanie Tak dokładnie, widać to po operacjach na komórkach. I tu pojawia się problem - drobna wskazówka z mojej strony - analizowanie wydruku z dhc11, to wyzwanie samo w sobie . Polecam zaopatrzyć się w porządny deasembler taki jak ja mam np. czyli IDA , generuje on schematy blokowe i ma wiele ułatwień, chociażby śledzenie miejsc gdzie jest przeprowadzana operacja na danej komórce. > "drobna" Dobre To cholerstwo musi byc pisane / czytane po jednym > bajcie (tak w kazdym razie dziala orgyginalna procedura > diagnostyczna), takze protokol troche masakryczny musial by byc. > Nie wspominajac, ze warto by calosc zrobic odporna na przerwe w > komunikacji, znaczy sie przy zmianie mapy trzeba by najpierw > pozbierac dane z sesji z urzadzeniem diag. do buforka, a potem > skontrolowac kompletnosc danych i calosc "szybciutko" przepisac > we wlasciwe miejsce. Bo nie podejrzewam, zeby ten uklad mial > jakis wbudowany mechanizm transakcji, Przez drobne miałem na myśli wyrzucenie tego co jest fabrycznie do kosza, i zastąpienie własną procedurą obsługi komunikacji. Procedura to może za dużo powiedziane, ja zastosowałem schemat przesyłania 4 znaków - typ operacji,adrH,adrL,znak po czwartym znaku motka zwraca badz probuje zapisac pod wskazany adres przesłany znak, ot i cała komunikacja .

> A jak jest adresowany ten SRAM, tak samo jak reszta, czy jest jakis > dodatkowy burdel z tym zwiazany. No widac tutaj braki czasu bo wszystko jest w dataheet-cie , i pisalem zreszta o tym, 68HC11 ma wbudowany kontroler pamieci zewnetrznych wiec on nawet nie musi wiedziec co sie znajduje pod konkretnym adresem, wazne zeby hardware byl zdolny do zapisu. Po drobnych przerobkach mozna by wsadzic i SRAM zamiast eeprom-a i jezeli wczesniej by sie go zainicjowało to już wogóle super,plus drobna korekta procedury komunikacyjnej i juz mamy zmiany map poprzez zlacze diagnostyczne . > To juz napotkalem we wsadzie od CCS-a, nie jest tak zle, pod > warunkiem, ze wskazniki nie tworza dlugich ciagow (sam pisalem > kiedys w C programy co mialy deklarace int ***v; , ale nie > pamietam juz po co). W 16V pratycznie wszystkie funkcje sa wywolywane poprzez wskazniki, a w 1.1 zdaza sie to tylko glownie przypadku takich pseudo-automatów skończonych. > Ale obiecuje sobie, ze sie za to > wezme.

> Dobra, uznajmy chwilowo, ze pytania nie bylo, wszystko wyglada na to, > ze mapa jest troche powywracana i z tego tez powodu dhc11 se > slabo z tymi plikami radzi... Nie bardzo rozumiem co znaczy mapa pamieci ? Jezeli rozklad danych i kodu, to w kazdym ECU jest troche inne ( najwieksze roznice miedzy 1.1 .1.2 75 1.2 16V, a w ramach jednej "rodziny" jest podobnie. ECU 1.2 mogo powodowac na poczatku konsternacje , poniewaz tam jest podpiety dodatkowy SRAM, z ktorego glownie sie korzysta, wewnetrzny jest prawie nieruszony oprocz miejsca na bajty bitowe. 16V to juz wogole masakara, najgorszy do rozszyfrowywania bo wiekszosc funkcji jest wywolywana przez wskazniki, wiec trzeba recznie szukac wszystkich wektorow. To chyba tyle tak ogolnie . Procki wszedzie sa takie same. Wiec kod jest taki sam tylko jego rozmieszczenie rozne.

> i owo, a ewidentnie sa rozne. Czy dobrze kombinuje, ze sa dwie > rozne skale do indeksowania predkosci obrotowej? Właśnie dlatego proponowałem przesiadke na mój wsad, bo z innym nie będę wstanie pomóc. Pozwoliłem sobie kontynuować ten temat w tym miejscu bo chyba jest odpowiedniejsze .

> Moze pracujemy na dwoch roznych obrazach eprom. Ja uzywam > tego z paru postow wstecz... Uciekł w moim wcześniejszym poście załącznik z wsadem. SC 1.1 SPI 1ED6 280124872-e11-1ed6.txt

Jak na taki czas samodzielnej pracy to bardzo ładnie . W takim razie może bym prosił o konsultacje w tej sprawie. Cały czas czekam na wszelkie opinie . > To co, dostane jakiegos bonusa? > bytes $f0a3 16 engine_speed_scale ; index stored at 010A > bytes $f11b tutaj raczej klapa, znajduje sie tutaj mapa przeskalowania ale od wczesniejszego adresu i dla innej wartości. Ta mapa pojawi się już niedługo.

> No chyba, ze w ecu jest pamiec Eprom a nie EEprom, to > przepraszam bardzo. Ale tak jak powiedzialem, hardware to nie > moja specjalnosc Tak jak zostało już napisane, 68HC11 w naszych ECU może współpracować z kośćmi które posiadają sposób obsługi identyczny z typową kością C512, sposób odczytu, wyprowadzenie pinów... Jaką kość zastosujemy, może byc eprom, Eeprom, pamięci Flash, nawet o większej pojemności, byle układ nóżek się pokrywał, lub można zrobić specjalną podstawkę. Problem z zapisem pozostaje jednak cały czas taki sam - jednak trzeba by było poczytać specyfikacje 68HC11, link był podany - i tam widać że wbudowany sterownik obsługi pamięci nie jest przystosowany do zapisu stronami, i zmiany napięć ( co jest potrzebne w przypadku eepromów ). Do linii adresowej są podpięte wszystkie urządzenia zewnętrzne, a w zależności do jakiej komórki się odwołujemy, procesor ustawia 1 na konkretnym pinie co można wykorzystać do aktywowania odpowiedniego układu, oraz jest osobny pin który oznacza czy wykonujemy akcje zapisu lub odczytu wybranej komórki. W 68HC11, przewidziane są 3 dodatkowe pamięci + pamięć o specjalnym przeznaczaniu na program, w tym przypadku nasz eeprom.

> Ja nie widzę w 1.2 żadnego sramka ECU na przedstawionym zdjęciu wygląda jak 1.1, moja informacja dotyczy ECU od 1.2 75km który posiadam i tam jest na 100% taki układ co widać w kodzie i na płytce również znajduje się dodatkowa kość ( dość duża w porównaniu z innymi elementami, z wyjątkiem procesora oczywiście ). Co do sramu to może przesadziłem, bo po nazwie układu nie mogłem znaleźć żadnego datasheet-u do niego, jednakże po sposobie jego wykorzystania w kodzie, wygląda że spełnia on funkcje zewnętrznej równoległej pamięci. A ze specyfikacji 68HC11 wynika że potrafi on obsługiwać jedynie układy z najprostszym sposobem zapisu. Nie wiedziałem że do 1.2 mogą być różne ECU. > A może przydało by się przybliżyć budowę sterownika Niestety od strony hardware-u nie posiadam żadnych informacji i raczej sam nie jestem w stanie rozpracować połączeń na płytce. Chociaż bardzo by to było przydatne.

> 3 - Jak wyobrażasz sobie zapis do Eproma i to jeszcze poprzez > interfejs taki jak Euroscan Skoro już pojawił się taki temat, to dam się trochę pociągnąć za język , ale konkrety pojawią się niestety nie za szybko, bo póki co to projekt nie jest jeszcze nawet w fazie testów. W skrócie, ponieważ mapy znajdują się w ROM-ie ( zewnętrzny eeprom ), to sprawa wydaje się beznadziejna, jednak to nie jest ostatnie słowo, program sterujący zostawia trochę wolnej pamięci RAM, więc teoretycznie , można tam przenieść jedną mapę. Teraz kwestia druga ( o tym możliwe że już niedługo ), trzeba by zastąpić wbudowany program obsługi komunikacji, na taki który odbiera dane i zapisuje je w RAM-ie, (nie) przypadkowo w miejscu gdzie przenieśliśmy którąś z map. Zaletą jest odpadnięcie jakiejkolwiek zabawy z emulatorami. Przeszkodą mała ilość wolnej pamięci, aczkolwiek 1.2 posiadają z tego co mi wiadomo pamięć sram zewnętrzną, więc tam może być łatwiej. Jednak szczegółów nie znam. Jeszcze dopowiem koledze Woj76 , wydaje mi się że ze stworzonego tematu wynika jasno że dane znajdują się w Eepromie, więc jakiekolwiek zmiany poprzez procesor są niemożliwe, jedynym rozwiązaniem mogą być zewnętrzne emulatory takich pamięci. Co do protokołu to być może napiszę co nieco niedługo, co przy sporym wkładzie własnym pozwoli rozpracować ten problem.

> to po co osobne cewki do 1-4 2-3? > no raczej nie bardzo tak jak, bo załozmy ze w cylindrach 1-4 mamy > sprezanie, a w 2-3 wydech, to ok, iskra idzie we wszystkich i > nic sie nie dzieje, ale gdy w cylindrach 2-3 mamy potem > sprezanie to w 1-4 jest zasysanie mieszanki. Przy założeniu że iskra jest podawana zarówno przy sprężaniu jak i wydechu to sprawa jest wyjaśniona . Dwie cewki potrzebne są ponieważ zapłon występuje tylko na jednej cewce,tej przy GMP pary tłoków, a wtedy druga para tłoków jest w DMP, i na nich zapłonu nie może być. Po zamianie pozycji par tłoków miejscami następuje zapłon na drugiej cewce.