Dlatego też Johan Kanflo ze Szwecji zdecydował się na próbę poprawy tej sytuacji i opracowanie alternatywnego firmware dla tego modułu zasilacza (soft ten powinien działać także z innymi modułami z rodziny DPS, jednakże autor testował go tylko z DPS5005).
Cały proces opracowania nowego oprogramowania autor zaczął od inżynierii wstecznej modułu. Szybko dostrzegł on, iż we wnętrzu modułu znajduje się mikrokontroler z rodziny STM32, co oznaczało, że stworzenie nowego firmware jest możliwe – te układy mają w pełni dostępną dokumentację i są bardzo popularne zarówno w przemyśle, jak i wśród hobbystów.
Aby rozpocząć pracę nad nowym softem, konieczne było dokładniejsze poznanie funkcji oryginalnego software w układzie. Ta część poniższego artykułu będzie szczególnie interesująca dla tych, którzy z jakichś przyczyn są zainteresowani inżynierią wsteczną innych urządzeń.
W dalszej części omówione zostanie otwarte, alternatywne oprogramowanie dla tego modułu – OpenDPS oraz proces budowania i wgrywania tego oprogramowania do zasilacza. Jeśli interesuje Was tylko opis aktualizacji oprogramowania modułu, to śmiało możecie przejść do dalszej części artykułu.
Cały proces inżynierii wstecznej DPS5005 ograniczyć można do opisu “dowiedzieć się jak najwięcej o sprzęcie wokół mikrokontrolera STM32 I napisać aplikację dla tego systemu”. Zasadniczo tak właśnie tworzy się aplikacje na mikokontrolery, co autor OpenDPS robi na co dzień, jednakże zazwyczaj ma się do dyspozycji jeszcze schematy urządzenia oraz elektronika, który projektował system pod ręką. Tutaj sytuacja nie była tak sprzyjająca.
Pierwszym krokiem jest lokalizacja portu szeregowego. Udało się to zrobić dosyć łatwo, śledząc odpowiednie ścieżki na płytce drukowanej. Niestety port był w 100% cichy i głuchy, mikrokontroler nawet go nie inicjalizował. Pomoże on jednak później, podczas debugowania nowej aplikacji.
Sam mikrokontroler znajduje się pod wyświetlaczem TFT, który z główną płytką połączony jest z wykorzystaniem ośmiu pinów. Autor – dla oszczędzenia czasu – przeciął wyświetlacz, aby dostać się do układu pod spodem.
Interfejs programowania SWO procesora wyprowadzony jest na pola lutownicze, znajdujące się na PCB. Wystarczyło przylutować do tych pól kable, aby możliwe było podłączenie programatora. W tym przypadku by to klon STLinka. Autor wykorzystując OpenOCD, skonfigurowane pod układ STM32F100, połączył się z mikrokontrolerem. Oto, jakie informacje udało mu się uzyskać:
Code: bash
Log in, to see the code
Pierwszy sukces! Teraz można skorzystać z OpenOCD do połączenia się z mikrokontrolerem, aby uzyskać jeszcze więcej informacji na temat mikrokontrolera:
Code: bash
Log in, to see the code
Widzimy zatem, że włączona jest opcja zabezpieczenia przed odczytem („readout protection”), więc nie będziemy w stanie odczytać zawartości pamięci Flash układu. Nie jest to duży problem, jako że oryginalny firmware nie interesuje nas sam w sobie, chcemy jedynie dowiedzieć się czym i w jaki sposób on steruje. Co zatem musimy wiedzieć, aby stworzyć nowy firmware – nasz OpenDPS? Potrzebujemy dowiedzieć się:
* gdzie i jak podłączone są poszczególne przyciski i inne linie wejścia/wyjścia (I/O);
* jakie peryferia wbudowane w STM32 wykorzystane są do sterowania funkcjami zasilacza;
* jak kontrolowane jest napięcie wyjściowe (czy kontroluje je jakiś DAC?);
* jak zrealizowana jest kontrola i ograniczenie prądu (jest w układzie jakiś ADC?);
* jak mierzone jest napięcie wejściowe i wyjściowe (z pewnością poprzez jakiś ADC);
* jak można przyciemniać wyświetlacz TFT.
Do pomocy przy inżynierii wstecznej autor stworzył skrypt w Pythonie, który łączy się z OpenOCD i sczytuje wartości różnych rejestrów mikrokontrolera, na przykład dzięki zgraniu wszystkich wartości rejestru związanego z przetwornikiem cyfrowo-analogowym (DAC) udało się wyśledzić, że przetwornik jest wykorzystywany w urządzeniu. Analogicznie było z liniami GPIO i np. przyciskami. Autor zgrał wartość rejestrów GPIO, po czym nacisnął przycisk i ponownie zgrał wartość rejestrów. Porównując ich wartości ze sobą, możliwe było zdeterminowanie, który przycisk podłączony jest do jakiej linii GPIO.
W opisany powyżej sposób autor rozpoznał w pełni połączenia linii GPIO. Udało się także potwierdzić, że wbudowany DAC wykorzystywany jest do sterowania napięciem wyjściowym. Podświetlenie wyświetlacza TFT sterowane jest przez timer 4. Prąd wyjściowy i napięcia wejściowe oraz wyjściowe mierzone są wbudowanym w układ przetwornikiem ADC na kanałach, odpowiednio: 7, 8 oraz 9.
Wyświetlacz TFT w systemie posiada sterownik ILI9163C – do sterowania nim autor wykorzystał bibliotekę stworzoną przez użytkownika SumoToy. W projekcie zastosowano sprytną sztuczkę – jako że wyświetlacz jest jedynym urządzeniem na interfejsie SPI w systemie, to pin sterujący (Chip Select) podłączony jest na stałe do masy. Dzięki temu oszczędza się jeden pin GPIO mikrokontrolera. Kolejny pin oszczędza się nie korzystając z linii MISO wyświetlacza – nie nadaje on żadnych informacji, które mikrokontroler chciałby czytać.
Teraz musimy dowiedzieć się jak dokładnie wysterować DAC, by sterować napięciem wyjściowym oraz jak przeliczać odczyty przetwornika ADC1 na realne napięcia. Normalnie wystarczyłoby sprawdzić to na schemacie, ale tutaj takim nie dysponujemy. Musimy zatem kontynuować inżynierię wsteczną. Na szczęście to nie było trudne – wystarczy podłączyć multimetr, zmierzyć napięcie i porównać z odczytem z ADC1 w mikrokontrolerze. Po porównaniu kilku wartości można było łatwo wyznaczyć liniową zależność.
Następnie autor stworzył prostą aplikację, korzystającą z libopencm3 i przetestował rozpoznane dotychczasowo funkcje przed skasowaniem oryginalnego firmware DPS5005. Połączył się poprzez telnet na port 4444 i spróbował:
Code: bash
Log in, to see the code
Porażka! Wyłączmy i włączmy układ ponownie, zresetujmy OpenOCD, i wtedy spróbujmy znowu.
Code: bash
Log in, to see the code
I od razu lepiej. Nie wiadomo w sumie, czemu za pierwszym razem to się nie udało. Taka sytuacja miała miejsce wiele razy na dwóch różnych używanych przez autora modułach.
Następnie wgrano próbną aplikację poprzez proste ‘make flash’. Na wyświetlaczu od razu pojawił się testowy wzór, a na wyjściu pojawiło się spodziewane napięcie równe 5 V. Inżyniera wsteczna urządzenia zakończyła się powodzeniem, co oznacza że można przejść do pisania docelowej aplikacji sterującej urządzeniem.
OpenDPS w porównaniu do oryginalnego oprogramowania ma ma mieć takie same możliwości techniczne, ale posiadać bardziej czytelny interfejs użytkownika oraz dodatkowe funkcje związane z zdalnym sterowaniem modułu poprzez WiFi lub port szeregowy. Firmware dedykowany jest do DPS5005 i innych zasilaczy z tej rodziny.
Aplikacja musi odpowiadać równolegle na sterowanie zarówno z poziomu przycisków, jak i poprzez port szeregowy. Dodatkowo reagować musi też na pomiary z przetwornika ADC, które mówią np. o przekroczeniu ustawionego maksymalnego prądu wyjściowego.
Linie GPIO przycisków oraz RX interfejsu UART obsługiwane są w swoich przerwaniach. Przetwornik ADC także obsługiwany jest w przerwaniu, aby zapewnić sobie szybką reakcję układu na nadmierny prąd – to z pewnością ograniczy liczbę awarii podczas korzystania z zasilacza w warsztacie.
Pozostałe funkcje, takie jak obsługa wyświetlacza TFT czy reagowanie na komendy użytkownika – np. zmianę parametrów pracy – można pozostawić dla wolniejszej części aplikacji, gdyż tutaj prędkość nie jest tak krytyczna.
Opis systemu
Firmware OpenDPS składa się z szeregu następujących modułów:
* event – moduł, który korzystając z buforu pierścieniowego, przechowuje wydarzenia z kontekstów poszczególnych przerwań, aby były one obsłużone w kontekście głównym aplikacji. Wydarzeniami – eventami – są naciśnięcia przycisków, odebrane poprzez UART bajty oraz informacja o przekroczeniu maksymalnego prądu wyjściowego.
* hw – warstwa abstrakcji sprztęowej – przetworniki ADC i DAC, linie GPIO etc.
* ili9631c – sterownik wyświetlacza TFT.
* opendps – główna aplikacja.
* past – moduł odpowiedzialny za zapis parametrów persystentnych (nieulotnych) do pamięci Flash.
* protocol – funkcje pomocnicze do obsługi protokołu komunikacyjnego z urządzeniem OpenDPS.
* pwrctl – moduł kontroli zasilacza, zawierający funkcje pomocnicze do obliczeń parametrów dla DAC oraz konwersji odczytów z ADC do fizycznych wartości.
* ringbuf – implementacja bufora pierścieniowego.
* spi_driver – sterownik interfejsu SPI.
* tft – funkcje pomocnicze do kontroli wyświetlacza TFT.
* tick – funkcja obsługująca timer systemowy systick. W tej implementacji pracuje on z rozdzielczością równą 1 ms.
* uframe – moduł odpowiedzialny za tworzenie ramek dla protokołu szeregowego, które wysyłane będą przez moduł.
* ui – moduł sterujący interfejsem użytkownika zasilacza.
Kontrola przepływu
Główny program znajduje się w opendps.c, a w nim znajduje się pętla, która oczekuje na nadejście nowych wydarzeń w buforze pierścieniowym. Informacje o naciśniętych przyciskach, odebranych bajtach danych i przekroczeniu maksymalnego prądu wyjściowego umieszczane są w buforze.
Aplikacja cyklicznie komunikuje się z modułem ui, aby zaktualizować interfejs użytkownika co 250 milisekund. Moduł ui odpowiada także za obsługę komend użytkownika, niezależnie czy są to informacje wysłane poprzez interfejs szeregowy czy też naciśnięcia przycisków.
Każde wydarzenie w buforze kodowane jest jako 16-bitowa zmienna całkowita – opisuje to rodzaj eventu oraz opcjonalnie dodatkowe dane, które mogą mu towarzyszyć. Dla interfejsu UART danymi tymi jest oczywiście odebrany bajt, a w przypadku naciśnięcia przycisku - informacja o tym, czy było to krótkie, czy długie przytrzymanie przycisku.
Zarządzanie przetwornikami ADC i DAC
Jako że autor projektu nie posiadał schematu urządzenia, więc tak jak pisaliśmy - musiał eksperymentalnie zbadać zależności pomiędzy odczytami z poszczególnych modułów a realnymi wartościami.
Po zrekonstruowaniu zależności na podstawie przeprowadzonych pomiarów, zostały one zawarte w szeregu funkcji w kodzie programu:
V_in(ADC1_IN8) – znając wartość odczytaną z kanału 8 przetwornika ADC, funkcja zwraca wartość napięcia wejściowego.
V_out(ADC1_IN9) – znając wartość odczytaną z kanału 9 przetwornika ADC, funkcja zwraca rzeczywistą wartość napięcia wyjściowego z zasilacza.
V_out(DAC) – zwraca spodziewaną wartość napięcia wyjściowego dla zadanej wartości zapisanej w przetworniku DAC oraz odwrotnie (z napięcia wyznaczany kod DAC).
I_out(ADC1_IN7) – znając wartość odczytaną z kanału 7 przetwornika ADC, funkcja zwraca aktualny pobór prądu z modułu zasilacza oraz odwrotnie (z wartości rzeczywistej prądu kod ADC).
Aby uprościć obsługę krytycznych elementów mierzonych przez przetwornik ADC w przerwaniu, wartość przetwornika ADC jest wstępnie przeliczana w momencie ustawiania progu prądu wyjściowego i do przerwania podawany jest już konkretny kod z ADC, przekroczenie którego powoduje wystąpienie wydarzenia związanego z przekroczeniem maksymalnego prądu wyjściowego.
Tutaj pojawiły się pewne problemy – odczyty ADC dla dwóch różnych modułów, na których autor testował swój firmware, różniły się. Sprowadzało się to do podawania nieprawidłowego prądu dla zerowego poboru z wyjścia zasilacza. Autor rozwiązał to poprzez prosty system autokalibracji – po włączeniu systemu układ zbiera pierwsze 1000 próbek z przetwornika i je uśrednia. W ten sposób wyznacza poziom odniesienia, który przyjmuje za prąd 0,00 mA. Pozwala to na kompensację różnic pomiędzy poszczególnymi urządzeniami. Funkcje za to odpowiedzialne (m.in. adc_i_offset) zawarte są w module hw.c.
Dodatkowo, autor w obecnej wersji oprogramowania zastosował pewną zwłokę zadziałania zabezpieczenia nadprądowego. Event związany z przekroczeniem ustawionego progu prądu wyjściowego jest sygnalizowany dopiero po zebraniu większej ilości próbek, w których mierzony jest nadmiarowy prąd po sobie. Ten sposób działania wymaga jednakże, jak pisze sam autor, jeszcze dokładniejszej analizy i optymalizacji działania.
Nieulotne zapisywanie danych w pamięci mikrokontrolera
Niektóre ustawienia wprowadzane przez użytkownika powinny być na stałe zapisywane w pamięci urządzenia. Za ich zapis odpowiada moduł past.c. Wykorzystuje on dwa bloki w pamięci, do których zapisuje on dane. W momencie, gdy jeden z bloków zostanie w pełni zapełniony danymi, do działania przystępuje algorytm sprzątania (garbage collector), który kopiuje potrzebne dane do drugiego bloku pamięci, a ten wykorzystywany dotychczasowo jest czyszczony. O tym, który blok jest tym najświeższym mówi wartość licznika. W ten sposób układ powinien by odporny na utratę danych np. w czasie utraty zasilania.
Grafika
Do wyświetlania wartości na interfejsie użytkownika wybrano czcionkę Ubuntu Condensed, która wykorzystywana jest w dwóch rozmiarach. Czcionka znajduje się w folderze gfx/fonts i składa się z dwóch plików – samych znaków (np. pliku ubuntu_condensed_48.png) oraz obrazka opisującego szerokość poszczególnych znaków czcionki. (np. plik ubuntu_condensed_48_width.png).
Czcionka Ubuntu Condensed, rozmiar 48.
Czcionka z obrazka (PNG) konwertowana jest przez skrypt font-convert.py, wywoływany komendą „make fonts”. Czcionka z PNG konwertowana jest do standardu zgodnego z BGR565 i zapisywana do pliku font-X.h oraz font-X.c.
Każdy znak konwertowany jest do osobnego ‘bloba’, co przyspiesza prezentację ich na ekranie TFT. Więcej detali na temat wykorzystania tych czcionek w takim formacie dowiedzieć możemy się z analizy funkcji tft_putch(…) zawartej w module tft.c
Dane do wyświetlacza wysyłane są poprzez blokujące DMA. Jednym z możliwych usprawnień tego jest wykorzystanie całej listy deskryptorów DMA, aby uruchamiać kolejny transfer DMA w kontekście ISR po zakończeniu poprzedniego transferu.
Wyświetlane na ekranie ikony są obsługiwane w podobny sposób (patrz na przykład wifi.h). Są one konwertowane przez „make graphics”. Zasadniczo bez problemu można podmienić czcionki bądź grafiki w projekcie.
Zdalna kontrola
Urządzenia OpenDPS mogą być sterowane zdalnie przez port szeregowy (UART). Podłączony do niego może być stosowny układ FTDI (mostek USB-UART) lub układ ESP8266, który pozwala na komunikację poprzez sieć Wi-Fi. Zwłaszcza ta druga operacja jest bardzo ciekawa.
Do komunikacji wykorzystany jest prosty protokół szeregowy (więcej detali znaleźć można w protocol.h oraz uframe.h). Niezależnie od wybranej metody komunikacji (USB lub Wi-Fi) wykorzystać możemy skrypt napisany w Pythonie, jaki dołączony jest do OpenDPS – dpsctl.py:
Code: bash
Log in, to see the code
Skrypt jest zupełnie agnostyczny na metodę komunikacji z docelowym urządzeniem. Wystarczy podać adres IP, z jakim komunikować ma się skrypt lub numer portu TTY i już, gotowe. Dodatkowo, jeśli chodzi o zasilacze podłączone po Wi-Fi, skrypt oferuje opcję skanowania sieci – dzięki temu może on automatycznie odnaleźć wszystkie urządzenia OpenDPS, jakie znajdują się w tej samej sieci, co komputer.
Do komunikacji po Wi-Fi wystarczy dowolny moduł z ESP8266, do którego portu UART należy się połączyć. Łączymy ze sobą masy (GND) oraz linie RX i TX, a następnie programujemy esp8266-proxy na układ Espressifa i już, system jest gotowy do działania.
Poniżej znajdziemy skrócony opis. jak zaprogramować ESP8266 odpowiednim wsadem:
Code: bash
Log in, to see the code
Warto zwrócić uwagę na fakt, że obecnie nie można korzystać z głównej gałęzi ESP Open RTOS, jako że zmiany wprowadzone przez autora, które potrzebne są do dystrybucji typu multicast, nie zostały jeszcze scalone z główną gałęzią systemu operacyjnego dla ESP.
Oprogramowanie esp8266-procy jest dosyć minimalistyczne. Moduł ten odbiera pakiety UDP na porcie 5005 i wysyła ich zawartość poprzez port szeregowy. Następnie odpowiedź – otrzymaną przez port szeregowy – wysyła do nadawcy (na ten sam adres IP i port, z jakiego przyszedł wcześniejszy pakiet) poprzez protokół UDP.
Gdy OpenDPS uruchamia się, ikonka Wi-Fi będzie mrugać z częstotliwością około 1 Hz. Gdy zapali się na stałe, oznacza to, że system połączył się z siecią Wi-Fi. Aby odnaleźć jego adres IP w sieci, możemy przeskanować sieć z wykorzystaniem wspomnianego powyżej skryptu:
Code: bash
Log in, to see the code
Następnie możemy spróbować wysłać do modułu ping:
Code: bash
Log in, to see the code
W tym momencie ekran urządzenia powinien jednorazowo mrugnąć. Jeśli zamiast tego otrzymamy komunikat o błędzie, to oznacza, że coś jest nie tak. W pierwszej kolejności musimy sprawdzić, czy nie zamieniliśmy ze sobą linii RX i TX. Jeśli nie i chcemy głębiej debuggować nasze urządzenie, to możemy podłączyć do linii RX i/lub TX moduł z układem FTDI, który pozwoli nam na podglądanie tego, co nadaje ESP8266, albo też co odpowiada zasilacz z wgranym OpenDPS.
Zmiana firmware w zasilaczu
Przejdźmy teraz do części poświęconej wymianie firmware w naszym module zasilacza. Tak jak pisaliśmy powyżej, oprogramowanie OpenDPS dedykowane jest do DPS5005, aczkolwiek powinno działać dla całej rodziny tych zasilaczy.
Uwaga!
Zanim przejdziemy dalej – ostrzeżenie. Pamiętajmy, że zmiana firmware na OpenDPS spowoduje skasowanie oryginalnego oprogramowania, jakie jest wgrane na mikrokontroler w systemie. Nie będzie możliwości przywrócenia go, ponieważ STM32 w układzie ma załączone zabezpieczenie przed odczytem wsadu. Z tego względu nie jest możliwe odczytanie zawartości przed wgrywaniem nowego oprogramowania.
Autor nie bierze żadnej odpowiedzialności za uszkodzone moduły zasilaczy czy inne niepowodzenia. Cały pakiet oprogramowania wykorzystujemy na własną odpowiedzialność.
To by było na tyle części ‘oficjalnej’. Do zabawy potrzebujemy DSP5005 (lub podobny) i programator, autor korzystał tutaj z klona STLinka. Dodatkowo potrzebujemy jeszcze kilka kabli do podłączenia programatora do modułu zasilacza. Kable te możemy wlutować w oczka w module lub po prostu przyczepić je tam na czas programowania. Prześledźmy teraz cały proces modyfikacji urządzenia.
Najpierw musimy wymontować PCB z plastikowej obudowy. Najprościej będzie skorzystać z niewielkiego, płaskiego śrubokręta, aby wyjąć płytkę drukowaną zza przytrzymujących ją plastikowych klipsów obudowy. Operacje tą należy wykonywać delikatnie, uważając, by nie połamać obudowy – nie jest ona jakoś szczególnie delikatna, ale mimo wszystko delikatność jest mocno wskazana. Klipsy są bardzo ważne, ponieważ trzymają one w miejscu PCB podczas naciskania przycisków.
Do pól lutowniczych interfejsu do programowania dolutowujemy kabelki, które pozwolą nam na podłączenie układu do programatora. Niewskazane jest montowanie w tym miejscu złącza, ponieważ może się ono po prostu nie zmieścić w obudowie. Autor po prostu wetknął w pola lutownicze zwykłe piny (bez lutowania) podłączone do cienkich drucików, które następnie podłączył to programowania. W nowszej wersji modułu zasilacza jest to trochę trudniejsze, ponieważ raster wyprowadzeń układu jest mniejszy i wynosi 1,25 mm (zamiast 2,54 mm wcześniej). Na stałe przylutować musimy jedynie kable od interfejsu szeregowego.
Budowanie firmware OpenDPS
Po podłączeniu modułu do programatora możemy rozpocząć przygotowania firmware.
Powinniśmy zacząć od zainstalowania OpenOCD oraz całego łańcucha narzędzi ARM GCC. Jeśli chodzi o GCC, to dobrym punktem wyjścia jest Launchpad. Jeśli korzystacie z MacOSa to instalkę OpenOCD pod ten system znaleźć można tutaj. Detale narzędzi być może dobrać będzie trzeba do własnego systemu i komputera.
Po zainstalowaniu możemy przystąpić do budowania aplikacji:
Code: bash
Log in, to see the code
W ten sposób mamy gotową paczkę, którą zaprogramować możemy STM32 w naszym module DSP5005.
Ładowanie programu do pamięci mikrokontrolera
Kolejnym krokiem jest załadowanie do pamięci układu programu. Zacząć musimy od odblokowania pamięci Flash, która fabrycznie jest zabezpieczona. Odblokowanie pamięci spowoduje także kompletne jej wyczyszczenie. Uruchamiamy OpenOCD i wpisujemy:
Code: bash
Log in, to see the code
W odpowiedzi otrzymać możemy kilka linijek tekstu, które kończyć powinny się na “Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints”, jeżeli udało nam się poprawnie połączyć z układem, który chcemy odblokować.
Uwaga!
Zanim przystąpimy do odblokowania i skasowania STM32, warto jest zgrać ustawienia peryferiów mikrokontrolera z naszego modułu. Hardware zasilaczy może w każdej chwili się zmienić, a wgranie OpenDPS jest najgorszym sprawdzianem, czy nic się nie zmieniło. Na przykład pin GPIO, załączający wyjście, mógł ulec zmianie, co spowoduje, że zasilacz przestanie działać, a debugowanie tego będzie bardzo trudne.
Jeśli zgramy wartości rejestrów odpowiedzialne za ustawienia poszczególnych peryferiów mikrokontrolera, to jeżeli okaże się, że coś jest nie tak, zawsze będziemy mogli spróbować rozszyfrować, co dokładniej poszło źle (patrz wyżej, gdzie opisywaliśmy, jak autor wykorzystał to do inżynierii wstecznej urządzenia).
Do zgrania wykorzsujemy skrypt ocd-client.py, który z kolei korzysta z OpenOCD do zgrania wartości wspomnianych rejestrów mikrokontrolera. OpenOCD czasami sprawia problemy z oryginalnym firmware, co oznacza, że będzie wymagało resetu. Zacznijmy od wyłączenia wyjścia z zasilacza i ustawienia napięcia na znanym poziomie, np. 5 V. Wpisujemy wtedy w konsoli:
Code: bash
Log in, to see the code
Jeśli będzie to koniecznie, zresetuj teraz moduł i OpenOCD, załącz wyjście na 5 V i wpisz w linii komend:
Code: bash
Log in, to see the code
Następnie powtórzmy dokładnie tą samą sekwencję dla kilku (jednego..dwóch) innych napięć wyjściowych. Zajrzyjmy jeszcze do wygenerowanych logów – nie powinno tam być żadnych linii, w których znajduje się wpis „Parsing error”.
Jeśli po wgraniu OpenDPS nie zadziała, to pliki te będą bezcenne do zlokalizowania problemu. Przed wgrywaniem nowego firmware powinniśmy jeszcze przetestować zasilacz, aby być pewnym, że z oryginalnym firmware jest on w pełni sprawny.
Teraz przystąpić możemy do czyszczenia pamięci Flash w mikrokontrolerze. W innym oknie terminala wpisujemy:
Code: bash
Log in, to see the code
I tam wpisujemy:
Code: bash
Log in, to see the code
Najprawdopodobniej program zwróci nam następujący komunikat, zakończony błędem:
Code: bash
Log in, to see the code
Nie przejmujmy się. Zresetujmy OpenOCD oraz moduł zasilacza (wyłączmy i włączmy ponownie zasilanie). Możemy teraz ponowić próbę odblokowania i skasowania pamięci. Po powtórzeniu powyższych czynności powinniśmy zobaczyć komunikat podobny do poniższego:
Code: bash
Log in, to see the code
Teraz czas na programowanie. Najpierw główny program, a potem bootloader:
Code: bash
Log in, to see the code
Ostatnie dwie linijki odpowiedzi na nasze komendy powinny wyglądać następująco:
Code: bash
Log in, to see the code
I gotowe – nasz moduł DPS5005 stał się OpenDPS5005.
Zasilacz po wgraniu OpenDPS
Teraz zmodyfikowany zasilacz jest gotowy do działania. Można używać modułu samodzielnie lub kontrolując go przez port szeregowy – samodzielnie, z wykorzystaniem kontrolera USB-UART lub specjalnie zaprogramowanego modułu ESP8266, który zapewnia komunikację poprzez sieć Wi-Fi.
Krótka instrukcja użytkowania
Po uruchomieniu OpenDPS na ekranie zobaczymy aktualne ustawienia napięcia i prądu. Domyślnie, po uruchomieniu, wyjście jest wyłączone. Naciśnięcie przycisku ON/OFF powoduje przełączenie stanu wyjścia.
Po włączeniu wyjścia, układ pokazywać będzie mierzoną na wyjściu rzeczywistą wartość napięcia oraz pobierany z zasilacza prąd. Jeśli w pewnym momencie ekran mrugnie i powróci do wyświetlania ustawień napięcia i prądu, to oznacza, że zdziałało zabezpieczenie nadprądowe. Aby wyłączyć wyjście, należy wtedy nacisnąć przycisk ON/OFF ponownie.
Po naciśnięciu przycisku SET przechodzimy do trybu edycji ustawień. Naciskając przyciski oznaczone V oraz A, zmieniamy edytowany parametr, odpowiednio napięcie i maksymalny prąd wyjściowy. Naciskając pokrętło przechodzimy w bok, a kręcąc nim zmieniamy wartość. Naciśnięcie SET ponownie pozwoli nam wyjść z trybu edycji parametrów.
Naciśnięcie pokrętła i przytrzymanie go w ten sposób przez około dwie sekundy spowoduje zablokowanie przycisków. Aby je odblokować, należy ponownie przytrzymać wciśnięte pokrętło. Długie naciśnięcie przycisku set z kolei spowoduje inwersję kolorów na wyświetlaczu (negatyw).
Po uruchomieniu się OpenDPS będzie czekał na połączenie modułu ESP8266 z siecią Wi-Fi. Dopóki nie połączy się on z siecią, ikonka sieci bezprzewodowej mrugać będzie z częstotliwością około 1 Hz. Po 10 sekundach prób połączenia ikonka zgaśnie, jeśli nie uda się nawiązać połączenia. Jeśli system połączy się z siecią, ikonka zapali się na stałe. Błędy podczas łączenia z siecią zostaną zasygnalizowane szybszym mruganiem ikonki sieci bezprzewodowej – około 4 Hz.
Zdalna kontrola poprzez port szeregowy
Jeśli przylutowałeś do wyprowadzenia portu UART kabelki, to można podłączyć je do adaptera z układem FTDI i po podłączeniu wszystkiego do komputera, skorzystać z narzędzia dpsctl.py do nawiązania komunikacji z OpenDPS:
Code: bash
Log in, to see the code
Po połączeniu się z systemem, ekran urządzenia powinien raz mrugnąć. Jeśli jednakże w odpowiedzi otrzymujesz komunikat “Error: timeout talking to device”, to oznacza najpewniej, że pomyliłeś linie RZ z TX lub np. zapomniałeś połączyć masy adaptera z masą modułu.
Ustawienia portu zmieniamy w zmiennej środowiskowej:
Code: bash
Log in, to see the code
Po ustawieniu wartości zmiennej DPSIF możemy rozpocząć testowanie modułu i komunikacji z nim. Ustawmy napięcie wyjściowe na 3,3 V:
Code: bash
Log in, to see the code
I włączmy wyjście:
Code: bash
Log in, to see the code
Sprawdźmy teraz parametry zasilacza:
Code: bash
Log in, to see the code
Finalnie, możemy wykonać aktualizację firmware poprzez port szeregowy. Jest to szczególnie praktyczne w nowszej wersji modułu, gdzie raster wyprowadzeń jest mniejszy i lutowanie pinów do interfejsu SWD trudniejsze:
Code: bash
Log in, to see the code
Jeśli komunikacja poprzez port szeregowy to to, czego Ci było trzeba, to możliwe jest zupełne wyłączenie funkcjonalności Wi-Fi w programie. Wystarczy, że podczas kompilacji dodamy parametr WIFI=0:
Code: bash
Log in, to see the code
W ten sposób zbudowana zostanie wersja oprogramowania OpenDPS pozbawiona funkcji komunikacji poprzez Wi-Fi, a na ekranie modułu nie będzie wyświetlała się ikona Wi-Fi.
Zdalna kontrola poprzez Wi-Fi
Aby podłączyć OpenDPS do sieci Wi-Fi, wykorzystamy moduł z ESP8266. Wystarczy nam dowolny moduł, do którego linii RX i TX interfejsu UART podłączyć możemy analogiczne linie z STM32 w module zasilacza. Tak jak pisaliśmy powyżej, do ESP wgrać musimy odpowiednie oprogramowanie – esp8266-proxy. Nie zapomnijmy ustawić w kodzie naszych danych sieci Wi-Fi – SSID oraz hasła. Po wpisaniu tych danych możemy przystąpić do budowy firmware i programowania naszego modułu.
Cały proces przebiega następująco:
Code: bash
Log in, to see the code
Warto zwrócić uwagę na fakt, że obecnie nie można korzystać z głównej gałęzi ESP Open RTOS, jako że zmiany wprowadzone przez autora, które potrzebne są do dystrybucji typu multicast, nie zostały jeszcze scalone z główną gałęzią systemu operacyjnego dla ESP.
Po połączeniu się OpenDPSa z naszą siecią bezprzewodową możemy przeskanować ją w poszukiwaniu naszego urządzenia. Wystarczy tylko uruchomić skrypt komunikacyjny z odpowiednią komendą:
Code: bash
Log in, to see the code
Następnie możemy spróbować wysłać do modułu ping:
Code: bash
Log in, to see the code
W tym momencie ekran urządzenia powinien jednorazowo mrugnąć. Jeśli zamiast tego otrzymamy komunikat o błędzie, to oznacza, że coś jest nie tak. Debugowanie tego problemu opisane zostało wyżej.
Niestety nie można zasilać modułu z ESP8266 prosto z OpenDPS. Pin VDD w interfejsie do programowania podłączony jest do układu U4 – stabilizatora napięcia 3,3 V MD7133H. Ma on wydajność prądową równą zaledwie 30 mA – znacznie za mało do zasilenia tego energochłonnego układu. Co więcej, stabilizator ten bierze zasilanie z U3, układu XL7005A, który dostarcza napięcie 5 V z wydajnością prądową na poziomie 400 mA. To nadal może być trochę zbyt mało dla startującego ESP8266.
Plany na przyszłość
Co pozostało do zrobienia w tym projekcie? Niewiele. Autor zamierza jeszcze poprawić kilka niuansów w kodzie programu, ale poza tym wszystko wskazuje na to, że prezentowane tutaj oprogramowanie jest stabilne i gotowe do codziennego korzystania.
Źródła:
https://johan.kanflo.com/hacking-the-dps5005/
https://johan.kanflo.com/opendps-design/
https://johan.kanflo.com/upgrading-your-dps5005/
Cool? Ranking DIY
. Sam mam dwa podobne moduły i będę sprawdzał ich kompatybilność, jak tylko kupię jakiś zasilacz do ich zasilenia.
Oryginalny interfejs na początku był dla mnie nie intuicyjny, po kilku miesiącach nie mam żadnych problemów.
