tomiwroc6

> 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.

> 1. czy nie powinno być czasem tłok 1-4 i 2-3, bo chyba tak sa > ułożone tłoki w naszych silnikach z tego co widziałem? Akurat od strony mechanicznej moja wiedza jest <=0 , jak ktoś potwierdzi to oczywiście poprawie. > 2. To jest bardzo ciekawy problem, z którego sam dopiero niedawno zdałem sobie sprawę, i niestety sam nie mogę znaleźć odpowiedzi na to pytanie, bo wszystko zgadza sie z wypowiedzią kolegi. Czujnik na wałku rozrządu by załatwił sprawę, jednak nie ma czegoś takiego. Jak dla mnie jedynym rozwiązaniem jest mechaniczne zatrzymywanie silnika zawsze w tym samym położeniu ( fazie ). Ale czy tak jest to nawet sam czekam na wypowiedź któregoś ze specjalistów na forum . > ja mam takie dwa pytania, troce laickie ale prosze nie besztac i sie > nie smiac bo sie nie znam Jak widać pytanie wcale nie banalne, widać że kolega rozważył dokładnie problem .

Aby poznać działanie procesora 68HC11, w naszych ECU proponuje chociaż przez chwile zastanowić się, jak by samemu próbować rozwiązać sterowanie pracą silnika. Ogólnie problem sprowadza się do śledzenia położenia tłoków, oraz w odpowiednich momentach należy wtrysnąć do cylindrów dawkę paliwa, lub wywołać zapłon mieszanki już tam się znajdującej. Teoria wydaje się mało skomplikowane, ale jak by przejść do praktyki... Do określenia położenia tłoków przyjęło się stosowanie czujników tzw. GMP ( położenia wału ). Do wału silnika przykręcone jest koło posiadające zęby co 6 stopni, z przerwą na 2 zęby. Dzięki takiemu rozwiązaniu możliwe jest określenie położenia cylindrów z dokładnością do 6 stopni. Dużo to czy mało ? Na początek musi wystarczyć. Zakładając że znamy położenie przerwy w zębach względem pozycji tłoków, moglibyśmy już w dość prymitywny sposób pokusić się o próbę ożywienia silnika. Jak zapewne wiadomo nasze silniki są cztero-suwowe, co to oznacza dla nas w praktyce - wyznaczone zadanie ( zapłon , lub wtrysk ) będziemy realizować co drugi skok tłoka, naprzemiennie dla pary cylindrów. tj. Jeżeli 1-3 tłok idzie w górę, a w cylindrze znajduje się już mieszanka, przed GMP ( szczytowym położeniem tłoka ), należy wykonać zapłon. Teraz przy zejściu w dół tłok wykonuje pracę, a następnie przy podejściu w górę wypychane są z tłoka spaliny. Przy następnym suwie ( w dół ) do cylindra będzie zasysana mieszanka, więc chwilę wcześniej należy wtrysnąć ja do kolektora dolotowego. Tak to wygląda : (z) - zapłon , (w) - wtrysk Kierunek tłoka--: góra.......dół...................góra......................dół Akcja 1-3--------: (z)..........(w) +praca......(w).........................zasysanie Akcja 2-4--------: praca....(w)...................(w)+zasysanie.....(z) Jak widać ze schematu działanie będzie podejmowane dla jednych cylindrów przy ruchu tłoka w górę, a dla drugiej pary w dół. Teraz posiadając odpowiednie urządzenie można je zaprogramować w taki sposób by przy określonym kącie przed GMP wykonywało zapłon na odpowiednich cylindrach, i wtryskiwało paliwo. Jeden minus to dokładność zapłonu co do kąta wyprzedzenia - co 6 stopni to zdecydowanie niezadowalająca wartość. Jak by to usprawnić. Chwila zastanowienia i... przecież dzięki czujnikowi GMP możemy określić prędkość obrotową silnika i za pomocą prostych wyliczeń dla ząbka z odpowiednim wyprzedzeniem wyliczyć czas kiedy należy wykonać zapłon. Tak, można to zdanie przeczytać dowolną ilość razy i za każdym wiedzieć mniej.... przyjrzyjmy się więc temu dokładniej : Załóżmy czas obrotu silnika na 10ms, co daje: 1000ms(1 sec) / 10ms = 100 (obrotów na sekundę) * 60sec = 6000 obr/min. Zapłon przewidujemy na 45 stopni przed GMP. Dla uproszczenia załóżmy że czekamy na ząbek 90 stopni przed GMP. Jeżeli znamy teraz dokładny czas przejścia tego ząbka, i "prędkość" silnika, możemy wyliczyć czas kiedy będzie 45 stopni do GMP. X - kąt który nas interesuje T - czas wystąpienia ząbka na 90 stopni przed GMP V - czas jednego obrotu wału ( ms ) czas_zapłon = T + (90 - X) * (V/360) dla naszego przypadku do T należy dodać (90-45)*(100/360) = 45 * 0,278 = 12,51ms. Sprawdźmy : przebyty dystans to 45 stopni czyli 1/8 obrotu = 12,51 * 8 = 100,8ms czyli czas pełnego 1 obrotu. Co do czasu wtrysku to można założyć stałe położenie rozpoczęcia, a jego czas nie wymaga już żadnych specjalnych obliczeń. Ok, w dość dużym skrócie ( przepraszam specjalistów za ogromne uproszczenia ), ustaliliśmy jak można by sterować silnikiem. Teraz spróbujmy określić minimalne zdolności jakie musi posiadać urządzenie które będzie spełniało to zadanie. 1. Musimy umieć zliczać impulsy, 2. Sterować włączaniem / wyłączaniem prądu 3. Możliwością zliczania czasu z dużą dokładnością. To są minimalne wymagania, które jak się w kolejnych odcinkach zresztą przekonamy, 68HC11 posiada, jak i sporo innych równie przydatnych. Przejdźmy zatem do poznawania naszej "zabawki". Tak jak każde urządzenie zarówno mechanicznie lub elektroniczne, 68HC11 może wykonywać różne czynności, w przypadku procesora jednak są to głównie obliczenia matematyczne. Jednak każda czynność musi być określona przez programiste. Ciąg instrukcji czynności do wykonania nazywa sie kodem maszynowym, jest to ciąg liczb dla człowiek raczej nie zrozumiałych, więc wymyślono zamiennik który przedstawia po kolei każda z czynności, jednak za pomocą w miarę zrozumiałych słów ( instrukcji ), wraz z parametrami. ( Za chwile przykład który myślę sporo wyjaśni ). Aby wykonywać jakiekolwiek operacje matematyczne, musimy mieć miejsce na przechowywanie liczb. Dla procesora są to rejestry - 68HC11, posiada rejestry : 8bitowe nazwane A i B ( w których możemy przechowywać wartości 0..255 ). A i B tworzą razem rejestr D, co daje zamiast dwóch liczb 8bit, jedna 16bit (0...65535). 16bitowe X,Y. plus oczywiście pamięć wewnętrzną ( 1024 bajty ), na przechowywanie wyników obliczeń. Teraz poznamy podstawowe możliwości procesora, jak załadowanie konkretnej wartości do rejestrów ( rozkazy w języku assembler ) : dla A ldaa _wartość_, ldab, ldx, ldy dla kolejnych. Wczytywać również można wartości z komórek pamięci ( jak i zapisywać ). Zapis : staa, stab,std, stx ,sty. Podstawowe działania jak dodawanie addd _komórka ,adx,ady , dodanie do rejestru wartości z ramu. Przykład : ldaa 10 ldab 40 staa $0 stab $1 ldd 10 addd $0 std $2 czyli "po polsku", wczytujemy do A wartość 10, do B 40. Zapisujemy wartości do ramu pod adres 0=10 , 1=40. Następnie do D czyli (A:B) wczytujemy 10, i dodajemy tą wartość do komórki 0. ( ponieważ rejestr D jest 16bit to dodawanie też, czyli brana jest liczba 16bit z komórek 0 i 1 ) czyli praktycznie 10*256+40 + 10 = 2610. Taka wartość zostaje zapisana do komórek 2 i 3. Na koniec mamy : A:10 B:50 [$0] = 10 [$1] = 40 [$2] = 10 [$3] = 50 Podane działania wynikają z matematyki dziesiętnej i szesnastkowej. Dokładniejsze objaśnienia znajdą się być może w kolejnych odcinkach. To chyba tyle odnośnie wstępu do tematu. Wiem że wszystko zostało omówione, bardzo ogólnie, ale myślę że w kolejnych odcinkach, na konkretnych przykładach, wszystko zostanie dokładniej i po kolei przedstawione. Podsumowując, do sterowania silnikiem wcale nie jest potrzebne bardzo zaawansowane urządzenie, procesor 68HC11, w zupełności wystarczy, dodatkowo wykonuje masę innych zadań pomocniczych. W zakresie używalności możemy na niego spojrzeć jak na urządzenie które potrafi wykonywać zlecone za pomocą kodów czynności. Większość prezentowanego kodu będzie się skupiała na operacjach matematycznych ( na liczbach 16,10,2 bitowych, jak i zależności między nimi). Więc jakieś krótkie powtórki dla osób które chcą się podszkolić są raczej nieodzowne. Tutaj dla chętnych pełna specyfikacja procesora. Na stronie 33 pełny wykaz instrukcji procesora. Parę użytecznych uwag na temat kodu znajdującego się w naszych ECU i jego przetwarzaniu już wkrótce. Za wszystkie błędy merytoryczne przepraszam, i każdy wykazany natychmiast będę poprawiał. Linki : Część I Część II