Stos TCP/IP dla Arduino v1.1

Postanowiłem dodać jeszcze kilka nowych rzeczy do poprzedniego kodu. Miało to na celu poprawienie/przyśpieszenie komunikacji oraz uzyskanie interfejsu bardziej zbliżonego do tego co można znaleźć w Arduinowej bibliotece Ethernet dla chipu W5100.

Poniżej krótka lista zmian:

- Funkcja write może teraz składać duże pakiety kawałek po kawałku. Nie musimy więc wysyłać niepotrzebnie małych pakietów (np podczas generowania dynamicznej strony WWW złożonej głownie z danych zapisanych w pamięci flash). Przyśpiesza to znacząco komunikacje protokołu TCP.

- Utworzyłem bufor dla danych przenoszonych przez protokoły TCP/UDP bezpośrednio na enc28j60. Dane przenoszone są w odpowiednie miejsce na chipie poprzez kanał DMA i nie przerzucane poprzez interfejs SPI. Bufor może pomieścić dane z pakietu o maksymalnej długości. Dzięki takiemu buforowi nie musimy odczytywać wszystkich danych natychmiast po odebraniu, tylko możemy odczytać je później w dowolnych kawałkach. Ma to ogromne znaczenie dla mikro-kontrolerów z minimalną ilością pamięci RAM.

- Weryfikowana jest suma kontrolna dla przychodzących pakietów TCP i UDP. Obliczenia są wykonywane przez enc28j60 więc możemy zweryfikować nawet duże pakiety o maksymalnej długości.

Załączony przykład jest dużo bardziej rozbudowany i skomplikowany. Umożliwia on zmianę podstawowych parametrów sieciowych oraz hasła. Oczywiście edycja ustawień możliwa jest dopiero po poprawnym zalogowaniu ;)





Kod źródłowy można pobrać tutaj

Stos TCP/IP dla Arduino

Jakiś czas temu wpadłem na pomysł by dodać do Arduino możliwość komunikowania się poprzez Internet. Nie jest to nic odkrywczego, takich projektów było już dziesiątki. Wygodnie jest wejść przez przeglądarkę by zobaczyć jak sobie radzi nasz mały przyjaciel.

Implementacji stosu TCP/IP dla systemów osadzonych również jest kilka. Mają jednak one wspólną wadę: są mimo wszystko zbyt duże i potrzebują zbyt wiele zasobów jak dla Arduino z chipem Atmega168, posiadającym 16kB flash i 1kB ramu ;]

Poniższy projekt wykorzystuje chip enc28j60 oraz moją implementacje TCP/IP dzięki czemu po skompilowaniu potrzebuje poniżej 7kB flashu oraz 224 bajtów pamięci RAM do działania :)

Dla wszystkich zainteresowanych kod źródłowy na licencji GNU jest dostępny tutaj

VBS i instalacja czcionek

Instalacja czcionek w Windowsie jest bardzo prosta i nie ma w tym żadnej filozofii. Czcionkę należy skopiować przy pomocy Eksploratora do folderu np c:\windows\fonts. Dodatkowo w systemach Windows Vista i Windows 7 mamy do dyspozycji menu kontekstowe (prawy-klik na pliku) z którego wybieramy po prostu "Zainstaluj".

Sytuacja jednak trochę się komplikuje gdy instalacje czcionek musimy przeprowadzić na wszystkich komputerach w domenie (Active Directory czy innej). Problem ten można rozwiązać przy pomocy prostego skryptu VBS.

W takim przypadku najlepiej uruchamiać go na końcu skryptu logowania :)

KWP2000 Ecu Emulator

Kiedyś obiecałem, że opublikuje kod źródłowy prostego emulatora protokołu KWP2000 - oto on w pełnej krasie :P

Napisany został w Processingu bo tak było po prostu najszybciej ;] Processing jest prostym językiem dla początkujących na którym bazuje Arduino IDE, ale to w sumie nie ma żadnego znaczenia w tym momencie.

Programik ma bardzo prostą klawiszologię:

'r' - resetuje do stanu "nie zainicjowano połączenia"
'q' - włącza podmianę wartości dla wybranego bajtu w ReadDataByLocalIdentifier
'w' - następny bajt
's' - poprzedni bajt
'd' - wartość bajtu +1
'a' - wartość bajtu -1

ecuemu.pde

Windows sockets initialization failed

Biblioteka Winsock odpowiada za obsługę połączeń tcp w systemie windows. Jak się okazuje problemy z nią związane migrowały aż do najnowszych wersji systemu Windows Vista i Windows 7 :)

Czasami jakiś wirus lub de-instalacja programu potrafi nam zepsuć system i wtedy przy próbie połączenia z internetem, otrzymujemy komunikat podobny do tego: Windows sockets initialization failed

Problem nie jest groźny ale doszukanie się dobrego rozwiązania chwile zajmuje, dlatego podaje je tutaj, na wypadek gdybym sam zapomniał :)

Z linii poleceń należy klepnąć komendę resetującą bibliotekę winsock:

netsh winsock reset

Następnie restartujemy system. Jeżeli to nie pomogło, możemy dodatkowo spróbować zrestartować ustawienia firewalla:

netsh firewall reset

Diagnostyka samochodowa (2)

Niestety pierwsza próba stworzenia mojego interfejsu pod USB zakończyła się porażką. Tak jak się spodziewałem konwertery i samo przesyłanie danych USB do UART wprowadzają pewne losowe opóźnienia i ciężko jest w ten sposób zainicjować poprawnie komunikacje z ECU. Ponieważ nie posiadam w tym momencie oscyloskopu (planuje kupić używany oscyloskop analogowy lub w ostateczności złożyć samemu jakąś zabawkę), nie potrafię w tym momencie nawet dokładnie powiedzieć jakiego rodzaju są to przesunięcia i zakłócenia. Najprostszym rozwiązaniem byłoby wstawienie mikro-kontrolera który zadbałby o właściwą synchronizacje. Chciałbym jednak najpierw zobaczyć jak to wszystko wygląda pod oscyloskopem, więc na razie interfejs na USB odkładam do szuflady.

Oczywiście nie oznacza to, że nie próbowałem zdobyć informacji na temat czujników na inne sposoby :)

Zdobyłem kompletną dokumentacje do kontrolerów stosowanych w różnych markach samochodów. Dzięki temu pewnie uda mi się w końcu połączyć z samym sterownikiem wyciągniętym z jakiegoś wraka. Podając odpowiednie impulsy na jego wejścia również będę w stanie określić w jaki sposób odczytywać wartości z jego czujników. Jest to jednak droga kosztowna, dlatego tymczasem próbuje jeszcze inaczej :)

Idea jest taka żeby stworzyć emulator ECU pracujący na komputerze do którego będą się łączyć programy diagnostyczne. Dzięki takiemu emulatorowi byłbym w stanie na bieżąco modyfikować wartości czujników i w ten sposób dowiedzieć się wszystkiego czego potrzebuję :)

Taki emulator udało mi się napisać w miarę szybko a dzięki wirtualnym portom COM wszystko można zrobić na jednym komputerze, bez potrzeby spinania dwóch maszyn kabelkiem Null-modem. Oczywiście znowu pojawiają się tutaj pewne problemy ale już zupełnie innej natury :/

Problem oczywiście leży w samych programach diagnostycznych. Autorzy takich programów wymuszają na użytkowniku kupienie interfejsu swojej produkcji i z innymi program nie chce współpracować, a tym bardziej nie można ustawić komunikacji przez zwykły port COM. Wygląda na to, że w sieci do Opla dostępne są tylko dwa programy: AutoScanner i OP-COM. Przy czym AutoScannera narazie nie używałem.

Z OP-COM jest sprawa o tyle ciekawa, że w sieci krąży jego beta wersja (Opel Tech2) nie zawierająca w ogóle odczytu czujników oraz wersja crackowana znana jako AB-COM.

Opel tech2 nie nadaje się więc do użycia a sporo użytkowników go poleca na forach :) Zresztą przeczytajcie tutaj sami co napisał autor programu. Natomiast AB-COM wygląda na to, że źle odczytuje bloki pomiarowe. Nie pokazuje mi napięcia z sondy Lambda, a inne wartości też nie zgadzają się do końca.

Jest jeszcze dostępne demo OP-COM, ale jak na razie nie chce "współpracować" :P Wersja demo jest spakowana programem Pecompact, który na szczęście da się łatwo wypakować. Być może głębsze wniknięcie w kod programu rozwiąże ten problem. Z tego powodu kod źródłowy emulatora zamieszczę dopiero za jakiś czas, po rozwiązaniu tego typu problemów. Być może dodam do niego funkcje emulacji któregoś z interfejsów współpracujących z OP-COMem.

Interfejsy diagnostyczne do samochodów

W poprzednim wpisie napisałem, że większość schematów interfejsów które można znaleźć w sieci jest niekompletna lub zła. Tym razem chciałbym napisać coś więcej na ten temat i wytłumaczyć niektóre niuanse związane z tworzeniem takiego interfejsu.

Mimo wszystko pewne standardy istnieją i obowiązują wszystkich producentów aut. W każdym standardzie pierwsze co jest zdefiniowane to właśnie właściwości elektryczne. Opis ten dotyczy warunków jakie maja panować podczas przesyłania danych oraz w jaki sposób ma się zachowywać podczas transmisji kontroler w samochodzie i urządzenie testujące. Skupie się tutaj przede wszystkim na protokołach zdefiniowanych przez ISO-9141 i ISO-14230, ponieważ oba te standardy są zgodne w warstwie elektrycznej.

Z tych standardów wynika kilka najważniejszych rzeczy:

- zakres temperatur w jakich pracujemy waha się pomiędzy -20C a +50C. Należy wiec pamiętać, że charakterystyki wielu elementów (np. rezystorów) zależą mocno od temperatury

- akumulator daje napięcie w granicach 12-14V, jednak tester powinien pracować poprawnie w granicach 8-16V

- komunikacja przebiega po "jednym drucie", tzw. linii K. Linia K jest oczywiście dwu-kierunkowa, czyli obsługuje nadawanie i odbieranie danych

- kodowanie danych na linii K jest identyczne jak podczas transmisji szeregowej UART (RS232) w formacie 8N1 (czyli 8 bitów danych, brak parzystości, jeden bit stopu, brak kontroli przepływem).

- linia K musi być podciągnięta do zasilania z akumulatora (tzw. pull-up) poprzez opornik 510 ohm 5%

- stan traktowany jako logiczne 1 na linii K to minimum 90% napięcia akumulatora

- stan traktowany jako logiczne 0 na linii K to maksymalnie 10% napięcia akumulatora. Prąd maksymalny 100mA

- tester nie powinien podawać na linie K napięcia wyższego od napięcia akumulatora, ani napięcia poniżej -1V

Jak widać nie ma tutaj żadnej magii. Wszystkie problemy z podłączeniem do danego sterownika wynikają tylko z tego jak bardzo dany interfejs nagina wyżej wymienione zasady i jak mocno trzyma się wyznaczonych parametrów elektrycznych. Od strony sterownika sytuacja zresztą wygląda podobnie.

Teraz przyszedł czas by się zastanowić jaką funkcjonalność powinien posiadać interfejs. Tak naprawdę mowa tutaj tylko o trzech rzeczach. Po pierwsze więc, musimy wziąć pod uwagę, że układy AVR czy inne chipy pracują przy napięciu 3.3V lub 5V. Interfejs powinien zatem konwertować poziom napięć pomiędzy 12-14V a napięciami TTL (czyli 5V lub 3.3V). Po drugie powinien poprawnie rozpoznawać stany logiczne 0 i 1, i po trzecie umożliwić nam nadawanie danych po linii K.

Oczywiście możemy tutaj użyć gotowych układów scalonych w stylu Si9243, L9637, MC33290 lub innych które zrobią to wszystko za nas. Trzeba jednak pamiętać, że są one drogie i trudno dostępne. Na dodatek w bardzo prosty sposób można poradzić sobie samemu, wykorzystując zaledwie 1-2 tranzystory, kilka oporników i komparator napięć LM393 lub LM339N. Dodatkowo ponieważ np. komparator LM339N jest poczwórny będziemy mogli bez problemu dołożyć obsługę linii L (linia ta służy tylko do inicjowania połączenia i występuje tylko przy starszych sterownikach w standardzie ISO-9141). Obsługę linii L realizujemy identycznie jak linii K.

Komparator napięć odwali za nas większą cześć brudnej roboty, czyli konwersje napięć oraz określenie stanu logicznego na linii K. Sam komparator jest zasilany napięciem ~12V z akumulatora (pracuje przy napięciach 2-36V). Konwersje napięć robimy w bardzo prosty sposób. Wystarczy jego wyjście podciągnąć pod 5V lub 3.3V.

Rozróżnianie stanów logicznych najlepiej jest zrobić podając napięcie odniesienia na nóżkę wejścia odwracającego układu poprzez dzielnik napięcia. Dzielnik napięcia można zrobić z dwóch rezystorów 10k ohm podciągniętych do +12V lub wykorzustując rezystory 10k ohm i 5k ohm podciągnięte do +5V. Jak widać dużo zależy tutaj od naszej fantazji :)

Całość układu może wyglądać tak jak na schemacie poniżej. Trzeba jednak pamiętać, że nawet tutaj można dokonać pewnych modyfikacji np. wyjście TXD można puścić poprzez pojedynczy tranzystor a nie dwa (tworzące bramkę NOT). Do złącza serial można doczepić układ MAX232 konwertujący poziomy napięć do standardu RS232, FT232 będący konwerterem USB-UART, czy też Atmega328p używany w Arduino.

Diagnostyka samochodowa

Diagnostyka samochodowa to nie tylko przykręcanie i rozkręcanie śrubek. Od dawna samochodowe silniki i inne podzespoły sterowane są elektronicznie. Jeżeli więc posługiwanie się kluczami nasadowymi, płaskimi czy grzechotką nie jest naszą mocną stroną, możemy również tuningować i monitorować pracę naszego autka elektronicznie. Robimy to poprzez wbudowany system diagnostyczny (OBD ang. On-Board Diagnostics).

System diagnostyczny zwykle składa się z różnych podzespołów (np. sterownik silnika, sterownik ABSu czy wspomagania kierownicy), które są połączone i tworzą wspólną sieć, podobną do sieci komputerowej. Na chwile obecną istnieje kilka standardów tego typu sieci. Nas jednak najbardziej będą interesowały tylko trzy spośród nich, najszerzej wykorzystywane w europie:

- ISO 9141-2: Wykorzystywany szeroko do roku 2000. Jego obsługa jest bardzo prosta i szczegółowo zdefiniowana, sygnalizacja opiera się o złącze UART a maksymalna długość pakietu to 12 bajtów.

- ISO 14230: Znany również jako KWP2000 (Keyword Protocol 2000). Jest to rozwinięcie standardu ISO 9141-2, ale kompatybilny z nim tylko w warstwie elektrycznej. Rozmiar pakietu może sięgać nawet 255 bajtów. Niestety wiele z jego funkcji standard ISO pozostawia do zdefiniowania dla producenta samochodu. Poprzez taki zabieg bez odpowiedniej dokumentacji praktycznie można tylko odczytać kody błędów. Nie trzeba chyba też dodawać, że z tego powodu implementacja KWP2000 może się różnić nawet w obrębie tego samego producenta.

- ISO 15765: Czyli sieć CAN, wykorzystywana praktycznie we wszystkich pojazdach od roku 2008. Oferuje przede wszystkim dużo wyższe prędkości transmisji.

Jakiś czas temu uzbrojony w tego typu informacje postanowiłem stworzyć swoje własne urządzenie do obsługi interfejsu diagnostycznego. Zmotywowały mnie przede wszystkim dwie sprawy, czyli brak obrotomierza oraz zapalanie się kontrolki check engine (sygnalizującej nieprawidłowe działanie któregoś z podzespołów lub nieprawidłowe odczyty z czujników).

Na początku nie byłem nawet pewien jaki protokół jest wykorzystywany w moim samochodzie. Wkrótce okazało się, że jest to KWP2000, przyszedł więc czas na budowę całego urządzenia oraz interfejsu. Jak widać wszystko opierało się o Arduino.






Niestety na każdym kroku największym problemem jest brak odpowiedniej dokumentacji. Mimo kilku prób nie udało mi się połączyć bezpośrednio z sterownikiem silnika co prawdopodobnie przyśpieszyłoby cały proces testowania



Wnioski z tych eksperymentów są takie, że większość schematów publikowanych w internecie jest niekompletna lub zła, a dostęp do informacji dla kogoś z poza branży utrudniony do granic możliwości. W końcu jednak przyszedł czas na pierwsze udane połączenie dzięki interfejsowi, którego schemat musiałem dopracować opierając się na poprzednich próbach i dokumentacji standardu.



Wkrótce potem podczas lutowania płytki z interfejsem spaliłem wyświetlacz LCD. Nie ma tego złego coby na dobre nie wyszło i tak nowa płytka posiada już wyświetlacz graficzny.







Jak widać na zdjęciach obecna wersja posiada niewielkie możliwości. Potrafi odczytać i skasować kody błędów, oraz zresetować sterownik (ECU ang. Electronic Control Unit).
W planach mam stworzenie interfejsu podpinanego poprzez złącze USB do komputera. Dzięki niemu w prosty sposób będę mógł podglądać komunikacje innych programów na złączu diagnostycznym i w ten sposób zebrać dalsze informacje potrzebne do obsługi protokołu KWP2000 również dla innych marek i modeli samochodów.

Język powiadomień Exchange 2007

Z jakiegoś dziwnego powodu czasami Exchange wysyła powiadomienia systemowe (np. o niedostarczonym mailu) w innym języku niż życzyłby sobie tego użytkownik. Poprzednia wersja (Exchange 2003) wykrywała automatycznie ustawienia językowe Outlooka i w zależności od nich wiadomość była widoczna w odpowiednim języku. W nowszej wersji (Exchange 2007) nie wystarczy zmienić ustawienia w Outlooku. Tego typu właściwości są wbudowane w skrzynkę pocztową na serwerze.

Najprościej zmianę tego typu ustawień przeprowadzić z pomocą power shella, niestety Exchange Management Console nie daje nam nawet takiej możliwości. Na początek pobieramy i sprawdzamy ustawienia językowe naszej skrzynki

$Mailbox = Get-Mailbox adrb
$Mailbox.Languages

Jako wynik otrzymujemy:

LCID Name DisplayName
---- ---- -----------
1031 de-DE German (Germany)

Następnie zmieniamy język na angielski i zapisujemy zmiany:

$Mailbox.Languages = "en-US"
Set-Mailbox -Instance $Mailbox

Ubuntu 10.04 LTS, problem z wygaszaczem

Niestety czas leci a dobrych sterowników pod Linuksa dla kart VIA dalej nie ma. Instalacja na starej maszynie z zintegrowana karta VIA przebiegła pomyślnie, problem zaczął się później :(

Wygaszacz ekranu to normalna sprawa, ale dlaczego wyłącza od razu cały monitor i na dodatek nie reaguje na zmianę żadnych ustawień? Nie pomogło nawet wywalenie ACPI wraz ze wszystkimi serwisami zarządzającymi energią.

Może trzeba zmienić ustawienia w systemie X? Ok, ale gdzie się podział xorg.conf? Normalnie powinien być w katalogu /etc/X11/, tymczasem okazuje się, że Ubuntu wykrywa wszystko w locie i nie zapisuje pliku z konfiguracja. Na szczęście plik z konfiguracją można wygenerować samemu: Xorg -configure. Ubuntu łyknie go bez problemu jeżeli tylko skopiujemy go jako /etc/X11/xorg.conf.

W wygenerowanym pliku w sumie nic podejrzanego nie ma. Zobaczmy w logi. W pliku /var/log/gdm/:0.log od razu rzuca się w oczy linijka na końcu pliku:

(II) CHROME(0): ViaDisplayDisableCRT

Hmm, czyli to jednak X-sy wyłączają monitor. Wykonanie

xset -display :0 dpms force on

przywraca monitor do życia. Dobra nasza, w razie czego można odpalić prosty skrypt monitorujący log i wykonujący taką komendę. Wypada jednak poszukać przyczyny problemu. Może trzeba jednak wyraźnie powiedzieć X-om, że monitor rzecz święta?

W sekcji "ServerLayout" dodajemy:

Option "BlankTime" "0"
Option "StandbyTime" "0"
Option "SuspendTime" "0"
Option "OffTime" "0"

Na wszelki wypadek w "Monitor" można jeszcze dać:

Option "DPMS"

Teraz restart Xorg i co? Działa.

Kiedy już nic nam nie przeszkadza możemy sobie w spokoju popracować :)

Kompilacja kodu C++ pod Arduino

Kto jeszcze nie słyszał o Arduino? Można powiedzieć, że Arduino otworzyło programowanie mikro-kontrolerów dla mas :) Kilka dobrych bibliotek, zestaw prostych funkcji, programator na usb, kompilator gcc. Wszystko to zintegrowane w jedno proste środowisko i ciężko się oprzeć żeby sobie nie wsadzić diody i popatrzeć jak błyska takie świecidełko :)

Jak to często jednak bywa, szczęście innych jest utrapieniem drugich :) Arduinowy edytor jest ładny i prosty w obsłudze ale brakuje mu zaawansowanych możliwości. Tak samo kompilacja plików pde potrafi dostarczyć niezapomnianych wrażeń i może być w kilku miejscach zaskakująca.

Dla chcącego nic trudnego, dzięki temu prostemu skryptowi bat mogę edytować kod w dowolnym edytorze i pisać go po prostu w C++.

Jak usuwać sterowniki Windows

Czy nigdy was nie wkurzyły sterowniki Windowsa? Jak to jest, że gdy zainstalujesz złe (albo same się zepsują, w końcu to Windows) tak ciężko go zmusić do wywalenia ich i użycia nowych?

Nieraz mi to psuło krew aż w końcu znalazłem rozwiązanie. Zainstalowane sterowniki Windows zapisuje w swoim katalogu %windir%\inf\oem*.inf :) Wystarczy przeglądnąć pliki oem*.inf, znaleźć ten który opisuje nasz niechciany sterownik i go usunąć wraz z odpowiadającym mu plikiem pnf (nazwa ta sama, ma tylko inne rozszerzenie).

Teraz tylko restart i instalacja nowych sterowników :)

Wymiana kondensatorów elektrolitycznych

Często się słyszy, że jak pada płyta główna czy coś innego to trzeba sprawdzić czy czasem kondensatory nie są "wybulone", czyli popsute. Zawsze się zastanawiałem czy wymiana takich kondensatorów ma szanse w czymkolwiek pomóc. Chodzi tutaj głównie o to czy taki zepsuty kondensator nie uszkadza przy okazji innych układów?

Ostatnio wpadła w moje ręce zepsuta karta graficzna i płyta główna z takimi właśnie objawami. Sprzęt co prawda działał, ale na monitorze pokazywały się dziwne artefakty, a płyta główna miała tendencje do nagłych restartów i innych dziwnych zachowań. Okazuje się, że to wszytko prawda, wymiana kondensorów przywróciła sprzęt do pełnej sprawności :)

Witam

W końcu założyłem sobie bloga. Stwierdziłem, że zamiast robić niektóre projekty itp do szuflady mogę je wrzucać tutaj. Sam bardzo dużo skorzystałem z informacji zamieszczanych na tego typu blogach, wiec czemu nie :/