Przeróbka ECU w S13

[ToM]

prawde mowiac z plytkami 3 warstwowymi sie jeszcze nie spotkalem no ale kij..

Temat samej plytki nie jest jeszcze zamkniety, choc musze przyznac ze nie nawidze robic plytek i nie jest to moja mocna strona.
Myslalem jeszcze nad uproszczeniem ukladu tzn. Atmela zasilic z 3.3V z nizsza czestotliwoscia pracy, odpadna wtedy uklady sprzegajace z logika FPGA, zostanie tylko zatrzask dla adresow
- z niego nie chce tezygnowac bo mam wtedy uproszczony dostep do FPGA z poziomu atmela. Jest wtedy w przestrzeni adresowej, mozna i bez tego ale wtedy bedzie trzeba komunikacje robic bardziej w software.

W sumie to Atmel wyladowal w projekcie tylko z jednego powodu , a mianowicie przetwornik Analog/Cyfra... W sumie jego zadanie to tylko komunikacja z otoczeniem, przetworzenie danych (np. uwzglednienie xharakterystyki czujnikow) i wyslanie do FPGA.

Co do prowadzenia sciezek to tez trzeba uwazac mimo ze np. komunikacja atmel > fpga to tak w uproszczeniu ujmujac 15MHz (66ns), ale w zatrzasku adresow jest uklad serii szybkiej i przejscia 0->1 i 1->0 moga trwac max 2ns. Tutaj dochodzimy wlasnie do dlugosci sciezek itp. pozatym Altium ma dosf fajne narzedzie Signal Integrity - pozwala przesymulowac odbicia sygnalow w liniach, przesluchy miedzy liniami na magistralach itp.
W sumie przy plytce wielo warstwowej warto dac wtedy jako srodkowa warstwe mase, a przynajmniej pod szybkimi magistralami.

No ale nic narazie sie nie spiesze bo nie chce skopac tematu obwodu drukowanego wole powoli, a dokladnie tak by uniknac wszelkich zaklucen i innych tego typu problemow...

Odnosnie firm to wildcat podeslal mi namiary na jedna firme maja specjalna oferte na male serie (prototypy):

http://zwod.technoservice.com.pl/index. ... 9pZFRvcD0w
http://zwod.technoservice.com.pl/index. ... lkVG9wPTA=

jak ktos zna inne firmy bede wdzieczny za info...

Co do Signal Integrity to pare przykladow mozliwosci dla zainteresowanych tematem elektroniki:

[katod]

tak.
atmela zasil z 3.3V (są teraz bardzo fajne stabilizatory 3.3V w małych obudowach SMD i bardzo stabilne).
na środkowej warstwie płyty dajesz głównie zasilanie (grube ścieżki) i oblewasz masą w okolicach kwarców (tam najbardziej sieje na całą płytę, szczególnie przy takich częstotliwościach). Na środkowej warstwie możesz jeszcze dać mało rygorystyczne sygnały, jednak jak najmniej ich.
a główne sygnały niech idą na górze i dole...
technoserwis robi dość małe przelotki i ścieżki więc wyrobisz spokojnie.
robią wysokiej jakości płyty (więc np. nie podtrawią czegoś - jak się zdaża w innych "profesjonalnych" płytkarniach).

Jeszcze jedna propozycja, bo nie wiem czy już rozwiązałeś problem...
Zastanawiałeś się nad wrzuceniem głównego programu na EPROM.
Jest to dobry pomysł, ponieważ WSZYSTKIE pamięci (flash, FRAM itd itd) są BARDZO zawodne i potrafią się skasować lub przekłamać na pojedynczych bitach lub nawet wyzerować całe bajty.
Auto = zmiany temperatury, drgania, przeciążenia struktury.
A to jest bezpieczeństwo.
Możesz zrobić tak: oryginalny program na EPROMie, a obszary MAP zamaskowane obszarami flasha (masz tam FPGA - więc łatwo to zrobić).
Oprócz tego maskujesz również inne obszary programu EEPROMa, gdzie chcesz ewentualnie coś dynamicznie zmieniać.
Standardowo i awaryjnie - chodzi główny prog z EPROMa, a opcjonalnie maskujesz mapę z flasha (lub RAMu) lub fragmenty programu z flasha itd...
a we flashu (lub w RAMie) wydzielasz obszar "dynamiczny" i tam:
1) atmel ładuje konkretną mapę przy każdym przełączeniu
2) przełącza maskę (zakrywa obszar mapy w EPROMie)

Chyba faktycznie najlepiej wszystkie "wgrane MAPy" trzymać na flashu (nowe flashe oprócz protekcji softwarowej mają dodatkowe piny zabezpieczające przed przypadkowym zapisem przy hazardach).
A te mapy w odpowiednich momentach przepisywać do RAMu i wtedy zmieniać maskę.
czyli zmiana mapy moze odbywać się tak:
1) aktualna mapa w RAMie
2) przełączenie maski na mapę EPROMa (orginalny prog "awaryjny")
3) przepisanie odpowiedniej mapy z flasha do RAMu
4) przełączenie maski na mapę z RAMu
a zapis flasha tylko podczas transmisji z kompa wraz z weryfikacją na końcu transmisji
(np. obliczając wewnętrznie CRC16 i porównując czy wszystko ok)

i najlepiej przy wkładaniu wtyczki programowania zewnętrznego niech zwora powoduje zdjęcie blokady zapisu flasha na tym pinie o którym pisałem, a w innych przypadkach, nie będzie możliwości (teoretycznie) uszkodzenia zawartości flasha.

Główne zabezpieczenia najlepiej zrobić sprzętowo (i to jak najprościej), bo softwarowo nie będzie to bezpieczne.
Pamiętaj, że przy hazardach może sobie skoczyć w dowolny fragment programu na atmelu i np. przeprogramować lub skasować fragment flasha.

Pozdrawiam!

[ToM]

Tak zastanawialem sie nad epromem jednak troche inaczej to rozwiazane - taki backup wrazie wysypania sie pamieci. Niestety sama zmiana map nie wystarczy kiedys cos takiego wlasnie mialo byc, jednak na chwile obecna potrzebuje mozliwosci zmiany calego frmware dla oryginalnego ECU. Poprostu w przypadku jakis zmian musial bym za kazdym razem przeprogramowywac osobno EPROM. W takim rozwiazaniu cale UPDATE mozna robic po kabelku...

Sama zmiana map (maskowanie) miala byc rozwiazana tak:

Kod: Zaznacz cały

--------------------------------------------------------------------------------
-- SubModule DataDetector
-- Created   2006-05-14 23:21:10
--------------------------------------------------------------------------------
library IEEE;
use IEEE.Std_Logic_1164.all;
Use ieee.std_logic_unsigned.all;

entity DataDetector is port
   (
     Ain         : in    std_logic_vector(14 downto 0);
     Aout        : out   std_logic_vector(14 downto 0);
     Mapa        : in    std_logic_vector(2 downto 0);
     Ena         : in    std_logic
   );
end DataDetector;
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
architecture RTL of DataDetector is

-- Component Declarations
Signal Offset1 : Std_Logic_Vector (14 downto 0);

-- Signal Declarations
-- Offset:

-- 0000-00ff REG_FUEL,&H3700,16,16,256,1,Low octane Fuel map
-- 0100-01ff REG_FIRE,&H3A00,16,16,256,1,Low octane Ignition time
-- 0200-02ff HIGH_FUEL,&H3D00,16,16,256,1,High octane Fuel map
-- 0300-03ff HIGH_FIRE,&H3C00,16,16,256,1,High octane Ignition time
-- 0400-040f TP_SCALE_FUEL,&H3BC0,16,1,16,1,TP scale (Fuel)
-- 0410-041f RPM_SCALE_FUEL,&H3BD0,16,1,16,50,RPM scale (Fuel)
-- 0420-042f TP_SCALE_FIRE,&H3BE0,16,1,16,1,TP scale (Ignition time)
-- 0430-043f RPM_SCALE_FIRE,&H3BF0,16,1,16,50,RPM scale (Ignition time)
-- 0440-044f AF_LIMIT,&H3690,16,1,16,1,TP Limit
-- 0450-045f ADD_MAP3,&H3890,32,1,16,1,Dwell Duty
-- 0460-046f ADD_MAP1,&H3990,16,1,16,1,Variable air close
-- 0470-047f ADD_MAP2,&H39A0,16,1,16,1,Variable air open
-- 0480-048f ADD_MAP5,&H3EB0,16,1,16,1,AFR enrich vs Water Temp
-- 0490-049f TTP_MAX,&H3F40,16,1,16,1,TTP MAX
-- 04a0-051f VQ_MAP,&H3E00,16,1,128,1,VQ map
-- 0520-053f ADD_MAP4,&H39E0,32,1,32,1,voltage (0.16v step) vs water temp (value - 50ş)
-- 0540-0547 ADD_FUEL,&H3970,8,1,8,1,Acceleration increase volume
-- 0548-0549 K_DATA,&H3F80,2,1,2,1,K required number
-- 054a      SPEED1_LIMIT,&H392C,2,1,1,2,Speed Limit 1
-- 054b      REV1_LIMIT,&H3980,1,1,1,50,Rev. Limit 1
-- 054c      REV2_LIMIT,&H3981,1,1,1,50,Rev. Limit 2
-- 054d      REV3_LIMIT,&H3982,1,1,1,50,Rev. Limit 3
-- 054e      REV4_LIMIT,&H3983,1,1,1,50,Rev. Limit 4
-- 054f      IGN_TIME,&H3F8F,1,1,1,1,Void blast-off time


begin

Process (Mapa)
begin

     if (Mapa = "00") then Offset1    <= "100000000000000";
     elsif (Mapa = "01") then Offset1  <= "100011000000000";
     elsif (Mapa = "10") then Offset1  <= "100110000000000";
     elsif (Mapa = "11") then Offset1 <= "101001000000000";
     end if;

end Process;


Process (Ain)
begin
     if (Ain >= X"3690") and (Ain <= X"369F") and (Ena = '1') then
        Aout <= Ain - "11011010010000" + "10001000000" + Offset1;               -- AF_LIMIT,&H3690,16,1,16,1,TP Limit
     elsif (Ain >= X"3700") and (Ain <= X"37FF") and (Ena = '1') then
           Aout <= Ain - "11011100000000" + Offset1;                            -- REG_FUEL,&H3700,16,16,256,1,Low octane Fuel map
     elsif (Ain >= X"3890") and (Ain <= X"389F") and (Ena = '1') then
           Aout <= Ain - "11100010010000" + "10001010000" + Offset1;            -- ADD_MAP3,&H3890,32,1,16,1,Dwell Duty
     elsif (Ain = X"392C") and (Ena = '1') then
           Aout <= Offset1 + "10101001010";                                     -- SPEED1_LIMIT,&H392C,2,1,1,2,Speed Limit 1
     elsif (Ain >= X"3970") and (Ain <= X"3977") and (Ena = '1') then
           Aout <= Ain - "11100101110000" + "10101000000" + Offset1;            -- ADD_FUEL,&H3970,8,1,8,1,Acceleration increase volume
     elsif (Ain = X"3980") and (Ena = '1') then
           Aout <= Offset1 + "10101001011";                                     -- REV1_LIMIT,&H3980,1,1,1,50,Rev. Limit 1
     elsif (Ain = X"3981") and (Ena = '1') then
           Aout <= Offset1 + "10101001100";                                     -- REV2_LIMIT,&H3981,1,1,1,50,Rev. Limit 2
     elsif (Ain = X"3982") and (Ena = '1') then
           Aout <= Offset1 + "10101001101";                                     -- REV3_LIMIT,&H3982,1,1,1,50,Rev. Limit 3
     elsif (Ain = X"3983") and (Ena = '1') then
           Aout <= Offset1 + "10101001110";                                     -- REV4_LIMIT,&H3983,1,1,1,50,Rev. Limit 4
     elsif (Ain >= X"3990") and (Ain <= X"399F") and (Ena = '1') then
           Aout <= Ain - "11100110010000" + "10001100000" + Offset1;            -- ADD_MAP1,&H3990,16,1,16,1,Variable air close
     elsif (Ain >= X"39A0") and (Ain <= X"39AF") and (Ena = '1') then
           Aout <= Ain - "11100110100000" + "10001110000" + Offset1;            -- ADD_MAP2,&H39A0,16,1,16,1,Variable air open
     elsif (Ain >= X"39E0") and (Ain <= X"39FF") and (Ena = '1') then
           Aout <= Ain - "11100111100000" + "10100100000" + Offset1;            -- ADD_MAP4,&H39E0,32,1,32,1,voltage (0.16v step) vs water temp (value - 50ş)
     elsif (Ain >= X"3A00") and (Ain <= X"3AFF") and (Ena = '1') then
           Aout <= Ain - "11101000000000" + "100000000" + Offset1;              -- REG_FIRE,&H3A00,16,16,256,1,Low octane Ignition time
     elsif (Ain >= X"3BC0") and (Ain <= X"3BCF") and (Ena = '1') then
           Aout <= Ain - "11101111000000" + "10000000000" + Offset1;            -- TP_SCALE_FUEL,&H3BC0,16,1,16,1,TP scale (Fuel)
     elsif (Ain >= X"3BD0") and (Ain <= X"3BDF") and (Ena = '1') then
           Aout <= Ain - "11101111010000" + "10000010000" + Offset1;            -- RPM_SCALE_FUEL,&H3BD0,16,1,16,50,RPM scale (Fuel)
     elsif (Ain >= X"3BE0") and (Ain <= X"3BEF") and (Ena = '1') then
           Aout <= Ain - "11101111100000" + "10000100000" + Offset1;            -- TP_SCALE_FIRE,&H3BE0,16,1,16,1,TP scale (Ignition time)
     elsif (Ain >= X"3BF0") and (Ain <= X"3BFF") and (Ena = '1') then
           Aout <= Ain - "11101111110000" + "10000110000" + Offset1;            -- RPM_SCALE_FIRE,&H3BF0,16,1,16,50,RPM scale (Ignition time)
     elsif (Ain >= X"3C00") and (Ain <= X"3CFF") and (Ena = '1') then
           Aout <= Ain - "11110000000000" + "1100000000" + Offset1;             -- HIGH_FIRE,&H3C00,16,16,256,1,High octane Ignition time
     elsif (Ain >= X"3D00") and (Ain <= X"3DFF") and (Ena = '1') then
           Aout <= Ain - "11110100000000" + "1000000000" + Offset1;             -- HIGH_FUEL,&H3D00,16,16,256,1,High octane Fuel map
     elsif (Ain >= X"3E00") and (Ain <= X"3E7F") and (Ena = '1') then
           Aout <= Ain - "11111000000000" + "10010100000" + Offset1;            -- VQ_MAP,&H3E00,16,1,128,1,VQ map
     elsif (Ain >= X"3EB0") and (Ain <= X"3EBF") and (Ena = '1') then
           Aout <= Ain - "11111010110000" + "10010000000" + Offset1;            -- ADD_MAP5,&H3EB0,16,1,16,1,AFR enrich vs Water Temp
     elsif (Ain >= X"3F40") and (Ain <= X"3F4F") and (Ena = '1') then
           Aout <= Ain - "11111101000000" + "10010010000" + Offset1;            -- TTP_MAX,&H3F40,16,1,16,1,TTP MAX
     elsif (Ain >= X"3F80") and (Ain <= X"3F81") and (Ena = '1') then
           Aout <= Ain - "11111110000000" + "10101001000" + Offset1;            -- K_DATA,&H3F80,2,1,2,1,K required number
     elsif (Ain = X"3F8F") and (Ena = '1') then
           Aout <= Offset1 + "10101001111";                                     -- IGN_TIME,&H3F8F,1,1,1,1,Void blast-off time
     else Aout <= Ain;
     end if;
end Process;

end RTL;
--------------------------------------------------------------------------------

Jednak mysle ze FRAM powinien byc w tym wypadku stabilny jesli chodzi o zapis i odczyt.
W przypadku zastosowania FLASH-a musial bym jeszcze dolozyc SRAM gdyz same RAMBLOCK-i z FPGA nie wystarcza pozatym potrzebuje czesc z nich uzyc jako szybkie pamiecy dwuportowe. Kolejna sprawa do dozucenie epromu to kolejna elektronika i mniejsce na plytce...
No i FLSH to kolejny problem podzial na bloki czyli zmiana = kasowanie calego sektora i zapis go na nowo wiec w SRAM trzeba przechowac caly sektor. W przypadku zaniku napiecia po wykonaniu komendy kasowania sektora wszystko co bylo zpamietane w SRAM leci w kosmos...

Odnosnie Atmela na 3.3V to nie ma problemu z zasilaniem bo FPGA i wiekszosc ukladow ma takie zasilanie. W sumie FPGA potrzebuje napiec 1.2V 2.5V i 3.3V - wszystko to jest zrealizowane.

[katod]

rozumiem.

jednak główną sprawą na którą chciałem zwrócić uwagę jest samouszkadzanie się:
- flasha
- FRAMu i pochodnych
- flasha w atmelu
1) dorób sumy kontrolne zawartości FRAMu
2) Nie zapomnij o tym konstruując komendy programowania flasha wewnętrznego IAP w atmelu - tak, aby dodatkowe flagi (w kolejnych krokach) zabezpieczyły przed przypadkowym wykonaniem fragmentu firmwaru kasującego lub zapisującego flasha (np. podczas zawieszenia procesora lub przypadkowego zmulenia całego układu).
np. na początku firmwaru jedna flaga (jej obecność będzie sprawdzać funkcja), a żeby skasować flash lub go zapisać bajty zatwierdzające (wiesz o czym mówię - w samej procedurze zapisu IAP - sama sekwencja IAP) ładować z zewnątrz, a nie przechowywać ich w samej funkcji w firmwarze.
bo problemy się zaczną - mogę to zagwarantować - atmele tak mają, zresztą wszystkie MCU z wew. flashem.
po prostu zastanów się nad prostym "obejściem" całego układu (np. zwykły komparator działający na zasadzie watchdoga w razie czego - pozostawi widoczny sam EPROM z awaryjnym programem, a wszystko inne zablokuje tak żeby MCU nissana mógł nadal działać). Nieznacznie skomplikuje to układ, ale moim zdaniem taki EPROM - na DILu i przewlekany, grube scieżki itd.
można to zrobić na zasadzie CSów (od góry kontrolowanych przez watchdoga) - jak nic nie działa, to "CSy" wszystkiego poblokuje watchdog, a uaktywni tylko EEProm. taki nadrzędny dekoder...
Pamiętaj, jak ktoś akurat będzie wyprzedzał, a na wyboju przez zimny lut (na atmelu SMD np) na chwilę zabraknie zasilania - to nie będzie zbyt ciekawie...

idąc dalej w takim rozumowaniu:
nie warto za bardzo zmieniać rozmieszczenia głównych części programu nissana (ewentualnie dorobić jeden skok gdzieś wyżej, tam coś wykonać i wrócic do normalnych adresów (ORYGINALNYCH)), bo jak watchdog o którym piszę zadziała - to musi mieć coś z sensem na tym eepromie pod aktualnym adresem programu, a nie - inne rzeczy pod adresami na MOD a inne na ORG.

Nie chcę się wtrącać w projekt i robić rewolucji, na pewno masz ogólny zarys i wiesz co robisz.
Chcę po prostu pomóc uniknąć ewentualnych problemów, bo przechodzenie przez cały etap prototypu jest bardzo czasochłonne, a kolejne wersje płytki z dużymi zmianami - to męka.
Więc lepiej z góry przewidzieć jak najwięcej...

[ToM]

Tak tylko nie mozna do konca popadac w paranoje Wiadomo ze elektronika moze byc zawodna. Prawde mowiac to wiekszosc osob powinna wyjac z ECU epromy i zaprogramowac je na nowo W sumie najczesciej gwarantowana trwalosc to 10lat choc i zdazaly sie firmy dajace 20lat A w realu jest roznie mialem epromy ktore lazily po 18 lat, a mialem uklady w ktorych eprom dostal dziur po 7 latach

Odnosnie zapisu do pamieci to bedzie on sie odbywal tylko podczas strojenia, programowanie atmela realizowane bedzie przez SPI (interfejs SPI<->USB bedzie zawarty w FPGA). To samo jest z pamiecia FRAM ktora zastapi EPROM, jednak tutaj dostep bedzie na dwa sposoby.

Update to odlaczenie pamieci od ECU (w FPGA) i caly jej zapis czyli standardowe update.
Podczas strojenia FPGA tak samo tostanie komende ktora pozwoli na zapis do FRAM, jednak sam zapis bedzie realizowac procek w ECU tak aby nie wystapily kolizje z zapisem i wykonywanym programem.
Samo wywalenie sie ATMELA doprowadzi jedynie do braku informacji z dodatkowych czujnikow w tym moze to byc MAP sensor, jednak w takim wypadku wszystko zadziala jak w przypadku oryginalnego ECU (przejdzie w tryb awaryjny).

Niestety pamieci EPROM ida powoli do lamusa i trzeba zaczac ufac alternatywnym pamiecja jak i danym z datasheetow... Prawde mowiac to robilem juz troche ukladow opartyuch o FLASHE jak i EEPROMY i nigdy nie mialem z nimi problemow. Kilka ukladow pracuje od lat w automatyce przemyslowej i jak narazie bez jakichkolwiek awarii. Kiedys mialem dyskusje na temat niestabilnosci ATMELI oraz ich zdolnosci do resetow... Owszem Atmele sa np. mniej tolerancyjne od PIC-ow ktore trudno zwiesic , jednak wszystko zalezy od samego projektu jak i dobrze wykonanej plytki.

Wiele osob zapomina o podstawach czyli kondensatory blokujace itp., a nawet jak daja to najczesciej zapominaja ze taki kondensator powinien byc podpiety przez jak najmniejsza indukcyjnosc. Kolejna sprawa ktora powoduje bledy w EEPROM-ach to zapis do nich przy zbyt malym napieciu, niestety wiele osob tez o tym zapomina. Jednak nawet sprawdzenie tego nie jest gwarancja ze napiecie nie spadnie 1 ns po sprawdzeniu tego faktu Fakt sa elektrolity i powinny uratowac sytuacje, ale czy to zrobia w wszystkich przypadkach jest jakis procent szansy ze zapis sie nie powiedzie...

Mozna eliminowac takie dziwne sytuacje do minimum, a i tak moze cos dziwnego stac sie w ukladzie podczas uzytkowania... Sumy kontrolne oczywiscie beda, zreszta ECU tez ma oryginalnie funkcje ich sprawdzania... Jednak zmieniajac mapy dowolnym programem nikt ich nie naprawia wiec ECU mysli ze ma uszkodzony EPROM

Procka sprawdzajaca zawartosc EPROMU z ECU:

Kod: Zaznacz cały

9 rom_checksum:                           ; CODE XREF: hardware_test?+22J
ROM:AEF9                 ldx     #$7FFF
ROM:AEFC                 clra
ROM:AEFD                 clrb
ROM:AEFE
ROM:AEFE rc_1:                                   ; CODE XREF: hardware_test?+F0j
ROM:AEFE                 inx
ROM:AEFF                 eora    0,x
ROM:AF01                 addb    0,x
ROM:AF03                 clr     byte_1079       ; watchdog_counter
ROM:AF06                 cpx     #$BFFF          ; (reset_vector+1)
ROM:AF09                 bne     rc_1
ROM:AF0B                 staa    checksum_xor
ROM:AF0E                 stab    checksum_add
ROM:AF11                 cmpa    byte_BFC0       ; ref_checksum_xor
ROM:AF14                 bne     rc_2
ROM:AF16                 cmpb    byte_BFC1       ; ref_checksum_add
ROM:AF19                 bne     rc_2
ROM:AF1B                 aim     #%11101111, flags ; Bit 4 = 0 means checksum OK
ROM:AF1E                 rts
ROM:AF1F ; -----------------------------------------------------------------------------------
ROM:AF1F
ROM:AF1F rc_2:                                   ; CODE XREF: hardware_test?+FBj
ROM:AF1F                                         ; hardware_test?+100j
ROM:AF1F                 oim     #%10000, flags  ; Bit 4 = 1 means checksum KO
ROM:AF1F                                         ;
ROM:AF22                 rts

[pascalek]

ToM, znalazłem coś baaardzo interesującego odnośnie przeróbki ecu w s13. Mianowice nazywa się to nistune http://home.aanet.com.au/nistune/
Układ wsadzany w miejsce chipa. Z tego co zrozumiałem, z laptopa jest możliwość obserwowanie parametrów silnika jak w consulcie, edycja map w czasie w rzeczywistym i co jest najpiękniejsze możliwość podłaczenia szerokopasmowej lambdy.
Co o tym sądzisz ? Byłby to dobry zakup ?

[ToM]

ToM, znalazłem coś baaardzo interesującego odnośnie przeróbki ecu w s13. Mianowice nazywa się to nistune http://home.aanet.com.au/nistune/
Układ wsadzany w miejsce chipa. Z tego co zrozumiałem, z laptopa jest możliwość obserwowanie parametrów silnika jak w consulcie, edycja map w czasie w rzeczywistym i co jest najpiękniejsze możliwość podłaczenia szerokopasmowej lambdy.
Co o tym sądzisz ? Byłby to dobry zakup ?

Z tym ze jest to cos w stylu emulatora pamieci EPROM. Tzn. zawiera statyczna pamiec RAM i po odlaczeniu napiecia wszystkie dane uciekaja... Reszte danych wyciaga zapewne sledzac magistrale (tzn. dane jakie sa po niej przesylane). Np. po wystrojeniu auta musisz zapisac projekt i zaprogramowac danymi ze strojenia pamiec EPROM.

Obecnie tez nad czyms podobnym pracuje z tym ze nie bedzie tracil danych (pamiec FRAM).
Jest to mocno uproszczona wersja mojej modyfikacji. Niestety ale to co jest opisane wyzej narazie stoi z braku finansow jak i problemow z zakupem czesci.

Choc ten uproszczony uklad nie straci az tak duzo z funkcjonalnosci, odpanie VGA, MMC i reszta bajerow. Tak samo bedzie mniejsza liczba wejsc i wyjsc. W sumie niezbedna podstawa. Jak sie uda upchac na plytce to bedzie miejsce na wlutowanie MAX-ow od EGT...
Do tego jakis prosty interfejs do innych modulow przyszlosciowych... Komunikacja RS lub USB... zobacze jak wyjdzie z kosztami - poprostu ma byc tanie. A sama cena pamieci FRAM
nie jest niska.

W sumie w ukladzie bedzie Atmel AVR + FRAM + jakies tanie CPLD pracujace jako dekoder adresow i jeszcze pare drobnych funkcji dopasowujacych.

Po kabelku bedzie mozliwosc zmiany softu Atmela jak i softu ECU. Do ECU bedzie wchodzic dosc mocno zmodyfikowany soft... dajacy pare opcji (kilka map - ile zobaczymy napewno wiecej niz jedna) mozliwosc wylaczenia/wlaczenia Lambdy dla kazdej z map.

Mysle ze opcje jakie beda to (a przynajmniej bede chcial zaimplementowac):

1. EBC + MAP Sensor
2. Przelaczane MAP-y
3. Shift Light
4. Strojenie z tracinkiem w trybie rzeczywistym, odczyt wszystkich parametrow itd.
5. Uniwersalne wyjscie np. natrsko wody na FMIC itp.
6. Moze EGT i obsluga wideband

Co bedzie to sie zobaczy calosc ma byc tania i zmiescic sie na malej plytce wpinanej zamiast EPROMU... + podlutowanie kilku kabelkow...

Oczywiscie funkcjonalnosci beda przybywac w miare pisania oprogramowania
Ogolnie mowiac ma to byc konkurencja dla wszystkich swinek (cena na poziomie SMT6) dajaca namiastke standalone...

Jesli sie uda wepchac EGT to bedzie trzeba sobie samemu zalatwic scalaki i je wlutowac soft z ta funkcja bedzie do pobrania za free....

A czy cos z tego wyjdzie to zobaczymy - narazie testuje kilka rozwiazan i zapowiada sie obiecujaco... Ale jak to w zyciu bywa zawsze moze cos wyskoczyc...

[ToM]

aaa na poczatku nie zalapalem z tym nistune. Uklad ten od jakiegos czasu robi darkhalf. Mial troche problemow bo ECU robil restart przy podlaczaniu USB. Ale widac ze juz dziala

tutaj wiecej danych:
http://home.aanet.com.au/nistune/docs.html

W sumie uklad nie do konca sledzi pamiec, tez ma napisana procke konsulta z tym ze umieszczona w innej pamieci i wspolpracuje z oryginalnym softem (wyciagajac dane z komurek pamieci). Kiedys rozmawialem wlasnie z darkhalfem nad taka realizacja problemu...
I kolejna moja pomylka to jest nvRAM czyli nie traci zawartosci - fajne kostki. Ciekawsze od FRAM i zapewne tansze tylko gdzie je kupic w PL

[ToM]

No i powstal wstepny zarys MINI MOD ECU... powinno sie go udac szybciej ukonczyc i bedzie sporo tanszy... He he Pajak nie martw sie ze kombinuje ale ten mod powstal pod katem szybkiego ukonczenia projektu

Wstepnie co zawiera:

wejscia:
--------------------------------------

1. MAP SENSOR
2. Temp Powietrza w dolocie
3. Cisnienie oleju / Temp oleju itp. (Czujnik rezystancyjny)
4. O2 Wideband sygnal (0-5V)
5. ABS SENSOR / UNIVERSAL (0-5V) lub ON/OFF
6. START PROCEDURE ON (ON/OFF) zwierany do masy

wyjscia:
---------------------------------------
1. PWM BOST - do zaworka EBC
2. SHIFT LIGHT / UNIVERSAL

Planowane Funkcje:
---------------------------------------
1. Procedura startowa - czujnik podpiety pod sprzeglo + w przyszlosci dane o poslizgu z ABS

2. Konwersja MAF MAP

3. Mapy NORMAL / SPORT dla kazdej z grup po 2 mapy - czyli razem 4 mapy
np.

NORMAL: Mapa 1 ekonom, Mapa 2 Normal
SPORT: Mapa1 lekkie sciganie, Mapa2 wlaczona proc. startowa, zero ograniczen itp.

4. LED ALARM - Miganie informacja o bledach w sterowniku, stale swiecenie ALARM o przekroczeniu jakiejs (do ustawienia) wartosci ktora grozi uszkodzeniem silnika...

5. Komunikcja z PC po USB - Real time tuning, tracking map itd.

6. Mozliwosc wlaczenia/wylaczenia lambdy dla kazdej mapy osobno...


Przyszlosciowe dodatki:
----------------------------
1. Obsluga 4 x czujnik EGT (trzeba sobie zalatwic scalaki)

2. Przyszlosciowa magistrala RS485 (jednokierunkowa) - do podlaczenia np. wyswietlacza, wskaznikow itp. - protokolik bedzie publicznie dostepny wiec ci co sie bawia w procesorki itp. beda sobie mogli cos podpiac Wysylane beda wszystkie istotane dane na temat pracy silnika....

Wstepny schemat ukladu:
http://www.turbokillers.com/tom/elektro ... D_MINI.pdf

Wsad do Xilinx-a juz napisany, jak sie wszystko uda pogodzic z ECU - bo jeszcze nie testowalem to mod powstanie wmiare szybko... oczywiscie pierwszy soft nie bedzie powalal na kolana bo to wymaga pracy

P.S.

Wszelkie uwagi mile widziane - puki robie to jeszcze na uniwersalnej plytce bo potem to juz amen...

[.wildcat.]

Czekam z niecierpliwością

Przewidujesz jakieś modyfikacje oryginalnego softu pod WB, czy tylko wyświetlanie przez USB?

[ToM]

Czekam z niecierpliwością

Przewidujesz jakieś modyfikacje oryginalnego softu pod WB, czy tylko wyświetlanie przez USB?

Dokladnie bedzie mozliwosc uzywania wideband do korekcji mieszanki przez ECU...
...ale to jak mowilem z biegiem czasu...

[ToM]

No i wszystko na dobrej drodze Plytka zaprojektowana trzeba teraz znalezc firme ktora za wiele nie skroi za wykonanie plytki prototypu... miejmy nadzieje ze bedzie dzialal

Jak wykonaja plytki bedzie mozna brac sie za montowanie i pisanie softu, czesc jest juz zrobiona, ale nie wszystko bedzie pasowac do tej wersji. Mimo ze jest dosc mocno okrojona w stosunku do poprzedniej zalatwia chyba wszystkie najpilniejsze sprawy.

Z biegiem czasu moze uda sie stworzyc sie firmware obslugujace inne ecu wyposazone w EPROM...

Schemacik sie troche zmienil ale glownie pod katem plytki, wylecial tez uklad zasilania 5V -
napiecie brane jest z ECU. Wymagane jest podpiecie jedynie 12V do obslugi np. zaworu EBC itp.

Schemacik i plytka do wgladu tutaj:
http://www.turbokillers.com/tom/elektro ... NI_PCB.pdf

A tu mala wizualizacja 3D jak to mniejwiecej bedzie wygladac:

[ToM]

Narazie papierowy wydruk Ale plytki juz niedlugo beda...

Tak to bedzie wygladac w ECU od S13:

[rzeszuwp]

Wypas ładny!!!

[trabirider]

gratki za wytrwałość przy projekcie