Płytka do auta i 12 V, które chce ją zabić

Elektronika w moim Golfie IV to dziś Raspberry Pi Zero 2 W i kilka modułów na przewodach: UPS, przetwornik ADC, sterowniki ULN i osobna ładowarka z 12 V. Połączeń jest dużo, a zasilanie z instalacji auta nie ma żadnej ochrony przed przepięciami. Obecny układ w aucie na razie zostaje, ale docelową płytkę na Raspberry Pi Pico 2 W zaprojektowałem już teraz, żeby przejście na nią nie wymagało potem kombinowania. Od razu zaznaczam: to rewizja 0.1, której jeszcze nie zamówiłem. Opisuję projekt i decyzje, które do niego doprowadziły, a nie działający egzemplarz.

Dlaczego Pico 2 W

Pico 2 W ma RP2350 z 520 KB SRAM i 4 MB flash oraz radio CYW43439 z Wi-Fi i Bluetooth LE. Wybrałem wersję bez goldpinów, którą lutuje się płasko do płytki za krawędzie z półotworami (castellated), bo lepiej zniesie wibracje. Ten wybór od razu skrócił listę modułów. UPS przestał być potrzebny, bo Pico startuje w mniej niż sekundę, a system plików LittleFS znosi nagły zanik zasilania. Osobny przetwornik ADC też odpadł, bo RP2350 ma własny.

Nie wiem jeszcze, czy Pico udźwignie Bluetooth w dwóch rolach naraz i TLS 1.3 przez PPP. Nie chciałem, żeby od odpowiedzi na to pytanie zależał cały projekt, więc na płytce zostaje nieobsadzone złącze UART pod Pi Zero 2 W. Jeśli Pico sobie nie poradzi, Pi stanie obok, a płytka zostanie bez zmian.

Z czym musi sobie poradzić wejście 12 V

Instalacja auta nie przypomina zasilacza laboratoryjnego. Najgroźniejszy jest zrzut obciążenia (load dump), czyli przepięcie, które powstaje, gdy przy ładującym alternatorze nagle odłączy się akumulator. Do tego dochodzą odwrotnie podłączone przewody. Ochronę rozpisałem więc jako cztery stopnie, przez które napięcie przechodzi, zanim dotrze do przetwornic. Tak wygląda ten fragment w skrypcie, który generuje schemat:

place('F1', 'Device:Polyfuse', '3A/33V 1812', X + 20, Y, {'1': '+12V_IN', '2': '+12V_F0'}, FP['PTC'])
place('Q1', 'Transistor_FET:Q_PMOS_GSD', 'SQD50P06-15L (-60V)', X + 50, Y,
      {'1': 'Q1_G', '2': '+12V_P', '3': '+12V_F0'}, FP['DPAK'])
place('D1', 'Device:D_Zener', 'BZT52C15 (15V)', X + 45, Y + 20, {'1': '+12V_P', '2': 'Q1_G'}, FP['SOD'])
place('D2', 'Device:D_TVS', 'SMBJ24A', X + 60, Y + 20, {'1': '+12V_P', '2': 'GND'}, FP['SMB'])
place('L1', 'Device:L', '10uH 4A', X + 85, Y, {'1': '+12V_P', '2': '+12V_F'}, FP['L12'])

Na początku stoi polimerowy bezpiecznik 3 A / 33 V, a przed nim, w wiązce, zostaje zwykły bezpiecznik topikowy 5 A. Za bezpiecznikiem jest ochrona przed odwrotną polaryzacją na P-MOSFET-cie SQD50P06-15L (dren–źródło −60 V), z diodą Zenera 15 V na bramce. Przepięcia od zrzutu obciążenia bierze na siebie dioda TVS SMBJ24A. Całość zamyka filtr LC: dławik 10 µH na 4 A oraz kondensatory 100 µF 50 V i 1 µF.

Jak doszedłem do TPS54360

Dioda TVS przy zrzucie obciążenia trzyma około 39 V i tyle może zobaczyć wejście przetwornicy. Od tej liczby zależał cały wybór. Pierwszy szkic miał LM2596 z wejściem do 40 V, co przy 39 V nie zostawia prawie żadnego zapasu. Przez chwilę LMR33630 wyglądał na wybór z większym zapasem, ale po sprawdzeniu okazało się, że wytrzymuje tylko 36 V, więc też odpadł. 25 września przeszedłem na TPS54360 z wejściem do 60 V, i to od razu w dwóch egzemplarzach.

Dwóch, bo taśma LED i logika nie powinny wisieć na jednym źródle. Przetwornica A zasila Pico (przez diodę Schottky'ego SS34 na VSYS), czujniki prądu i modem. Przetwornica B zasila tylko taśmę, więc skok prądu taśmy nie ściągnie w dół napięcia logiki. Obie dają 5 V przy prądzie do 3,5 A i pracują z częstotliwością około 600 kHz. Nie liczyłem wartości elementów od zera, tylko wziąłem je z przykładu w karcie katalogowej TI: dławik 8,2 µH i diodę B560C.

Taśma dostaje zasilanie przez klucz high-side na P-MOSFET-cie AO3401A, którym steruje Pico. Na długim postoju taśma jest odcięta całkowicie i nie pobiera prądu z akumulatora. Modem ma osobny, taki sam klucz.

Wejścia z zamków

Fabryczne zamki Golfa IV dają cztery sygnały: pozycję rygla i stan drzwi, osobno dla kierowcy i pasażera. Styk w zamku zwiera linię do masy auta, a na tych przewodach nie ma 12 V. Każda linia dostała na płytce podciągnięcie 2,2 kΩ do 3,3 V, rezystor 10 kΩ szeregowo do pinu i kondensator 100 nF. Stała czasowa wychodzi około 1 ms, co wystarcza na szpilki od silników zamka. Ten sam rezystor 10 kΩ ogranicza prąd płynący przy przepięciu do diod zabezpieczających, a resztę załatwia programowa eliminacja drgań styków (50 ms).

Szyby, lusterka, zamek

Szyby i lusterka obsługują sterowniki Darlingtona ULN2803A i ULN2003A wpięte równolegle do fabrycznych przycisków, więc płytka „naciska” je tak samo jak kierowca. Wspólny zacisk COM idzie do 12 V za zabezpieczeniami, dzięki czemu działają diody gaszące wbudowane w te układy.

Jeden szczegół wziąłem z erraty. RP2350 ma opisany błąd E9 dotyczący wewnętrznych rezystorów pull-down, więc na nich nie polegam. Wejścia ULN-ów mają własne rezystory do masy, a bazy tranzystorów, transoptory i wejścia przekaźników dostały zewnętrzne pull-downy 100 kΩ. Dzięki temu po resecie, zanim program ustawi piny, żadne wyjście nie jest „wciśnięte”, więc nie ruszy żadna szyba ani przycisk pilota.

Zamek centralny rozwiązałem tak, jak jest rozpisany dla Pi: dwa transoptory PC817 naciskają przyciski zapasowego pilota impulsem 400 ms, a pilot pozostaje galwanicznie oddzielony od płytki. Zostawiłem też pola pod dwa przekaźniki Omron G5V-2 do odwracania polaryzacji silników lusterek. Na razie są nieobsadzone, bo jeszcze nie sprawdziłem na schemacie auta, czy przełącznik lusterek tego wymaga.

Schemat i płytka ze skryptów

Niczego tu nie rysowałem ręcznie. Obwód opisuje skrypt gen_sch.py i to on jest źródłem prawdy: generuje schemat KiCada z etykietą sieci na każdym pinie, a decyzje projektowe spisuję osobno w specyfikacji. Z gotowego schematu kicad-cli eksportuje listę sieci. Drugi skrypt, uruchamiany w Pythonie KiCada, buduje z niej płytkę: rozmieszcza elementy według słownika pozycji, rysuje obrys, ustawia klasy sieci, strefę wolną pod anteną i pola masy. Ścieżki prowadzi potem Freerouting (20 przejść zajmuje około 10 minut), a na końcu kolejny skrypt dokłada przelotki zszywające masę. Każda zmiana w specyfikacji oznacza przepuszczenie całego łańcucha od nowa. Ręczne poprawki w KiCadzie zostałyby przy tym nadpisane, więc każda zmiana musi trafić do skryptów.

Wynik to płytka 140 × 100 mm, dwie warstwy, pole masy na obu stronach, 96 elementów do obsadzenia w 48 pozycjach BOM. Ścieżki zasilania mają 1,2 mm szerokości, sygnałowe 0,3 mm. Pico leży przy górnej krawędzi, obrócone tak, żeby antena wychodziła na brzeg płytki i nie miała pod sobą miedzi. ERC i DRC nie zgłaszają błędów. DRC zostawia tylko kosmetyczne ostrzeżenia na sitodruku i cztery pady masy Pico niepołączone z polem płytki. To akceptuję, bo wszystkie masy Pico łączy wewnętrzna masa modułu. Pliki produkcyjne są gotowe: Gerber, BOM, pozycje elementów i model STEP do projektowania obudowy w FreeCAD-zie.

Czego jeszcze nie wiem

Zanim zamówię płytki, prototyp na samym Pico musi rozstrzygnąć to, co wymusiło złącze pod Pi. Bluetooth ma działać w dwóch rolach naraz: centralnej wobec sterownika taśmy i peryferyjnej wobec telefonu. TLS 1.3 ma przejść przez modem LTE po PPP, a kanał WireLink na mbedTLS ma dawać bajt w bajt te same wyniki co wektory testowe z obecnej bramy. Na samej płytce muszę jeszcze sprawdzić w dokumentacji Waveshare, czy PWRKEY modemu włącza się zwarciem do masy (tak jest narysowany), i przeliczyć kompensację TPS54360 dla kondensatorów wyjściowych 2 × 47 µF.

Opis projektu jest w portfolio, a płytkę można obejrzeć z każdej strony w interaktywnym modelu 3D. Model pochodzi prosto z projektu w KiCadzie; po kliknięciu w blok widać, co on robi i z czego się składa.