Post on 23-Jun-2020
Zlecenie: 110-04910041 Okres realizacji: 01-01-2017 - 31-12-2017 Zakład: A1 ZATWIERDZAM:
Sprawozdanie z pracy badawczej finansowanej z dotacji statutowej
Tytuł: Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
Kierownik pracy: Radosław Przybysz
Podpis Kierownika pracy
Zespół wykonawców:
Przemysław Angielczyk, Krzysztof Broda, Jerzy Chudorlioski, Paweł Dąbkowski, Bożena Dobrowiecka, Andrzej Gacek, Andrzej Jaworski, Adam Kalinowski, Anna Kołtun, Grzegorz Kowalski, Leszek Książek, Aleksander Kuźmioski, Aleksander Lisowiec, Anna Liżewska, Karol Makowiecki, Paweł Michalski, Piotr Prystupiuk, Radosław Przybysz, Karol Reszczyk, Maciej Rup, Łukasz Sapuła, Krzysztof Skibioski, Wojciech Sokół, Paweł Wlazło, Grzegorz Wojtaś, Michał Zaklika, Andrzej Nowakowski
Warszawa, grudzieo 2017
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 2 z 45
SPIS TREŚCI 1. Cel i zakres pracy ........................................................................................................................................ 3
2. Wprowadzenie ........................................................................................................................................... 4
2.1 Opracowanie wymagao .............................................................................................................................. 6
2.1.1 Wymagania dla platformy sprzętowej ............................................................................................ 6
2.1.2 Wymagania dla platformy programowej ......................................................................................... 7
3. Przebieg realizacji ....................................................................................................................................... 9
3.1 Opracowanie platformy sprzętowej ............................................................................................................ 9
3.1.1 Wybór jednostki centralnej CLU ..................................................................................................... 9
3.1.2 Wybór rozmiaru obwodu drukowanego PCB ................................................................................ 13
3.1.3 Wybór stosu obwodu drukowanego ............................................................................................. 14
3.1.4 Obliczenia impedancji różnicowej ................................................................................................. 15
3.2 Schemat ideowy modułu SoM .................................................................................................................. 16
3.3 Schemat obwodu drukowanego PCB ......................................................................................................... 17
3.4 Model 3D obwodu drukowanego .............................................................................................................. 19
3.5 Opracowanie oprogramowania systemowego........................................................................................... 20
3.5.1 Konfiguracja kontrolera pamięci DDR ........................................................................................... 31
3.5.2 Zapis pamięci EEPROM ................................................................................................................. 32
3.5.3 Obsługa modemu GSM................................................................................................................. 33
3.6 Wykonanie i badanie modelu CLU ............................................................................................................. 37
3.6.1 Badanie interfejsu Ethernet .......................................................................................................... 39
3.6.2 Badanie interfejsu transmisji szeregowej UART............................................................................. 40
3.6.3 Wyznaczenie poboru prądu .......................................................................................................... 41
3.6.4 Analiza termiczna modułu SoM .................................................................................................... 41
4. Wyniki pracy ............................................................................................................................................. 42
5. Podsumowanie ......................................................................................................................................... 43
6. Syntetyczny opis pracy.............................................................................................................................. 44
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 3 z 45
1. Cel i zakres pracy
Tab. 1.1. Informacje dotyczące projektu
Obszar badawczy: Innowacyjne technologie i procesy przemysłowe
(w ujęciu horyzontalnym)
Inteligentna specjalizacja:
KIS 15. Inteligentne sieci i technologie geoinformacyjne
I. Technologie internetu przyszłości, technologie internetu rzeczy,
systemy wbudowane
Czas realizacji: 01.01.2017r. – 31.12.2017r.
Koszt: 600 tyś PLN
Kierownik projektu: mgr inż. Radosław Przybysz
Zakład: A1
Tab. 1.2. Struktura projektu
Opis
Problem:
Technologia IoT (Internetu Rzeczy) ukierunkowana jest głównie na
rozwiązania konsumenckie. Nie ma modułów SoM („System On Module”)
przystosowanych do zastosowania w przemyśle, gdzie wymagane są wyższe
parametry eksploatacyjne oraz specyficzna funkcjonalnośd, obsługa
protokołów i interfejsów przemysłowych, odpornośd na wysoki poziom
zakłóceo EMC oraz wymagania związane z obsługą w czasie rzeczywistym
„Real Time Computing”. Instytut prowadzi prace związane z IIoT w zakresie
urządzeo dla sieci Smart Grid.
W Instytucie brak jest rozwiązao typu SoM zoptymalizowanych
funkcjonalnie i kosztowo do opracowywania i wdrażania aplikacji IIoT.
Cel główny:
Opracowanie uniwersalnej jednostki CLU (Communication & Logic Unit)
wykorzystującej SoM do zastosowao w aplikacjach Przemysłowego
Internetu Rzeczy.
Cele
Szczegółowe:
Opracowanie platformy sprzętowej uniwersalnej jednostki CLU
Opracowanie oprogramowania systemowego uniwersalnej
jednostki CLU
Wykonanie modelu CLU
Wyniki:
Model uniwersalnej jednostki CLU
Dokumentacja modelu
Sprawozdanie zawierające opis przeprowadzonych prac oraz wyniki
badao modelu
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 4 z 45
Tab. 1.3. Plan zadaniowy
Nr Zadania I II III IV V VI VII VIII IX X XI XII
1. Opracowanie wymagao dla CLU:
2. Opracowanie platformy sprzętowej:
3. Opracowanie oprogramowania systemowego:
4. Wykonanie i badanie modelu CLU:
System w module ( ang. System On Module - SoM ) jest rozwiązaniem integrującym funkcjonalnośd
systemu na jednym obwodzie drukowanym PCB - w jednym module.
W poniższym sprawozdaniu przedstawiono informacje oraz wyniki badao dotyczące opracowanego
rozwiązania modułu SoM dla aplikacji Przemysłowego Internetu Rzeczy IIoT wykorzystującego
innowacyjne rozwiązanie firmy Octavo Systems *1+, OSD335x System w Pakiecie (ang. System-in-
Package SiP). Porównano rozwiązanie SiP z rozwiązaniem wykonanym w technice elementów
dyskretnych na podstawie porównania z mikrokomputerem Beagle Bone Black. Zaprezentowano
parametry techniczne oraz omówiono zalety powstałego rozwiązania.
2. Wprowadzenie
Z obserwacji trendów w zakresie rozwoju urządzeo dla sieci inteligentnych i M2M wynika wniosek
o potrzebie poszerzenia wiedzy i zdobycia nowych kompetencji w zakresie rozwiązao dedykowanych
dla przemysłowych sieci Ethernet oraz Przemysłowego Internetu Rzeczy IIoT. Sercem takich
rozwiązao są mikrokontrolery lub systemy w układzie scalonym (ang. System on Chip - SoC),
obudowane interfejsami pozwalającymi na podłączenie różnego typu układów peryferyjnych –
modułów rozszerzeo. Coraz większa powszechnośd stosowania zintegrowanych modułów SoC wynika
z faktu, że możliwa jest implementacja coraz bardziej zaawansowanych rozwiązao w obszarach do tej
pory niedostępnych ze względów ekonomicznych. Dodatkowym czynnikiem wpływającym na coraz
to większe wykorzystanie mikrokomputerów jest upowszechnienie się zdalnego monitorowania
i sterowania procesami, a co za tym idzie konieczności przesyłania dużej ilości danych z zachowaniem
ich poufności.
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 5 z 45
W ciągu kilku ostatnich lat liczba jak i różnorodnośd dostępnych jednopłytkowych modułów
mikroprocesorowych wzrosła kilkukrotnie. Z porównania cenowego obecnie dostępnych rozwiązao
wynika, że za kwotę 10 $ możliwy jest zakup mikrokomputera obsługującego interfejs HDMI,
posiadającego 2GB pamięci RAM, 8GB pamięci dyskowej oraz 4 rdzeniowy procesor o taktowaniu 1
GHz, przy czym zakres temperatury pracy tych modułów nie przekracza zakresu od 0°C do 70°C,
a więc nie pokrywają zakresu przemysłowego.
Poniżej w formie tab. 1. przedstawiono zestawienie porównawcze jednych z najbardziej popularnych
rozwiązao modułów mikrokomputerów na rynku polskim: Raspberry Pi *2+, BeagleBone *3+, Orange Pi
[5], Nano Pi *4+. Przy czym głównym celem porównania jest przedstawienie możliwości wykorzystania
ich do budowy urządzeo przemysłowych.
Tab. 2.1. Porównanie podstawowych parametrów technicznych SoM
Nazwa SOM Raspberry Pi Beagle Bone
Black Orange Pi Nano Pi
Opracowany moduł SoM
Temperatura pracy 0 … +70 :C
-25 … +70 :C dla wersji CM
0 … +70 :C -25 …+ 85 :C
dla wersji Industrial
brak danych brak danych - 40 … + 85 :C
Montaż na złączu 2.54mm
DIMM 204 dla wersji CM
na złączach 2.54mm
na złączach 2mm/2.54m
m
na złączach 2mm/2.54m
m
4 złącza SMD o rastrze 0.8mm i 4
otwory 3.1mm
Liczba interfejsów Ethernet
1 1 1 1 2
Obsługa interfejsu światłowodowego
Nie Nie Nie Nie Tak
Wbudowane gniazdo RJ-45
Tak Nie dla wersji
CM Tak Tak Tak Nie
Cena 180 PLN 300 PLN od 70 do 300 PLN
od 70 do 300 PLN
250 PLN
Podstawowymi korzyściami zastosowania SoM w aplikacjach przemysłowych są:
zmniejszenie kosztów płyty bazowej lub płyty modułu głównego,
możliwośd wykorzystania tego samego rozwiązania w różnych urządzeniach.
Ponadto w każdym rozwiązaniu dedykowanym do zastosowao przemysłowych bardzo ważnymi
elementami są:
układy zasilania i kontroli pracy baterii,
interfejsy komunikacyjne,
obsługa wyświetlacza,
wielkośd, typ zainstalowanej i obsługiwanej pamięci,
warunki środowiskowe, w szczególności temperatura pracy.
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 6 z 45
2.1 Opracowanie wymagao
W ramach zadania opracowano wymagania dla platformy sprzętowej i programowej jednostki SoM.
2.1.1 Wymagania dla platformy sprzętowej
W ramach tego punktu opracowano wymagania dla platformy sprzętowej jednostki CLU. Przy
tworzeniu wytycznych kierowano się maksymalizacją funkcjonalności rozwiązania modułu pod kątem
zastosowania go w różnych typach urządzeo z obszaru elektroniki konsumenckiej i przemysłowej
oraz z uwzględnianiem dużego nacisku na aspekty komunikacji M2M.
Opracowane wymagania:
zasilanie z pojedynczego napięcia 5V oraz z baterii litowo-jonowej 3.6 V,
pobór mocy nie większy niż 3W,
zintegrowany moduł ładowania baterii litowo-jonowej z monitorowaniem temperatury pracy
baterii,
ładowanie baterii z napięcia roboczego 5V,
zastosowanie złącz płytka-płytka umożliwiające swobodny dostęp do modułu centralnego
w przypadku konieczności wymiany,
raster pinów złącza płytka-płytka nie mniejszy niż 0.8mm,
jeden rdzeo procesora głównego w architekturze ARM,
jeden rdzeo procesora czasu rzeczywistego,
maksymalne taktowanie 1GHz z możlwiością skalowania w dół,
512 MB pamięci operacyjnej RAM,
8 GB pamięci masowej eMMC,
obsługa pamięci masowej MMC/SD z interfejsem 4-bitowym,
obsługa dwóch portów USB w trybie OTG, Device i Host,
obsługa dwóch portów Ethernet o szybkości 100MBit/s,
obsługa portów Ethernet typu RJ45 oraz światłowodowych,
obsługa magistrali TTL wyświetlacza LCD, minimalnie 16 bitów koloru i rozdzielczośd
wyświetlanego obrazu nie mniej niż 1024 x 600 pikseli,
obsługa dwóch portów transmisji szeregowej UART,
obsługa dwóch portów transmisji szeregowej SPI,
obsługa dwóch portów transmisji szeregowej I2C,
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 7 z 45
obsługa zegara czasu rzeczywistego,
obsługa modemów GSM sieci 3G i 4G,
wymiary modułu nie większe niż 60mm x 60mm,
możliwośd zastosowania modułu w urządzeniach zabezpieczających, konwerterach
komunikacyjnych, jednostkach agregujących dane oraz innych urządzeniach
ukierunkowanych na zastosowanie przemysłowe np. sterowniki silników czy siłowników
elektrodynamicznych oraz urządzeniach komunikacji M2M,
dedykowane złącze na potrzeby konsoli serwisowej,
dedykowane złącze zasilające pozwalające na podstawowe sprawdzenie modułu
bez konieczności montażu w urządzeniu docelowym,
zintegrowany 4 kanałowy 10 bitowy przetwornik analogowo-cyfrowy,
temperatura pracy -40° do 85°C.
2.1.2 Wymagania dla platformy programowej
W ramach tego punktu opracowano wymagania dla platformy programowej. Przy tworzeniu
wytycznych kierowano się maksymalizacją funkcjonalności rozwiązania modułu pod kątem
zastosowania go w różnych typach urządzeo z obszaru elektroniki konsumenckiej
i przemysłowej oraz z uwzględnianiem dużego nacisku na aspekty komunikacji M2M
oraz integralności i bezpieczeostwa transmitowanych danych.
Opracowane wymagania:
system operacyjny typu Linux lub Android,
pamięd operacyjną alokowaną przez system nie większa niż połowa dostępnej pamięci
operacyjnej RAM,
możliwośd implementacji transmisji danych wykorzystujących protokoły komunikacyjne: IEC
61850, DNP 3.0, MODBUS, IEC 60870-5-104, EtherCAT i ProfiNET,
możliwośd implementacji nadmiarowej transmisji danych zgodnie z IEC 62439-3,
obsługa modemów GSM wykorzystujących klasy CDC standardu USB,
możliwośd zestawienia kanału VPN/IPSec o minimalnych parametrach: IKE2, AE256, SHA1,
DH14 oferująca możliwośd pracy w trybie NAT-Traversal, czyli konwersje pakietów IP
na protokół UDP, który umożliwia translację NAT i transmisję ramek miedzy węzłami sieci,
obsługa klienta protokołów DHCP i DDNS,
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 8 z 45
obsługa mechanizmów wymieniany kluczy symetrycznych i asymetrycznych
z informacjami towarzyszącymi (certyfikaty) w trybach: cyklicznym i na żądanie
z zachowaniem uwierzytelniania, autoryzacji podmiotu wprowadzającego zmiany
oraz integralności wymienianych informacji,
możliwośd walidacji certyfikatów za pomocą protokołu SCSP,
możliwośd zdalnej aktualizacji oprogramowania z zaufanego źródła dostępu
oraz zagwarantowanie integralności pakietu oprogramowania, który ma zostad
zainstalowany,
wykorzystanie mechanizmów bezpieczeostwa zgodnie z normą IEC 62351-9
w aspekcie automatyzacji wymiany certyfikatów cyfrowych a w szczególności zarządzania
certyfikatami oraz kluczami prywatnymi i publicznymi w celu ochrony danych,
wykorzystanie protokołu SNMP do sygnalizacji przekroczenia minimalnej długości ważności
certyfikatów zainstalowanych w urządzeniach pracujących w obrębie IIoT,
wbudowana baza danych zgodna z specyfikacją SQL,
wbudowany serwer WWW z obsługą serwera PHP,
wbudowana biblioteka Qt,
obsługa kont użytkowników,
możliwośd przechowywania zaszyfrowanych danych w pamięci,
dziennik systemowy pozwala na rejestrowanie zdarzeo występujących w systemie
jak również przychodzących z innych źródeł, sortowanie wpisów oraz decydowanie
jak wykorzystad nowe informacje,
możliwośd przesłania zapisanych zdarzeo do zewnętrznego serwera,
obsługa zadao w czasie rzeczywistym oraz przerwao na tym samym urządzeniu, bez względu
na stan, w jakim znajduje się system,
odpornośd na wycieki danych oraz ataki mające na celu przejęcie kontroli nad urządzeniem,
praca w trybie Real Time Computing oferująca wymianę danych w czasie rzeczywistym,
obsługa interfejsu komunikacyjnego do systemu zarządzania pozwalającego na akwizycję
aktualnych pomiarów, wizualizację danych, sterowanie procesami, alarmowanie o błędach
oraz archiwizację danych.
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 9 z 45
3. Przebieg realizacji
3.1 Opracowanie platformy sprzętowej
W ramach zadania zaprojektowano platformę sprzętową jednostki CLU „System On Module”
uwzględniający wymagania z punktu 2.
3.1.1 Wybór jednostki centralnej CLU
Jako jednostkę centralną CLU wybrano zintegrowany układ scalony MPU OSD335x-SM produkcji
OCTAVO SYSTEM *1+. Układ jest przedstawicielem rozwiązao hybrydowych, integrujących w jednej
obudowie scalonej różne bloki funkcyjne: MCU/CPU, pamięd DDR, pamięd EEPROM oraz układu
zasilania PMIC. W porównaniu do rozwiązao wykonanych z elementów dyskretnych, rozwiązanie
w postaci zintegrowanego układu hybrydowego zmniejsza od 2- do 3-krotnie wymaganą
powierzchnię obwodu drukowanego oraz upraszcza konstrukcje stosu PCB. Wymagana liczba warstw
dla rozwiązania z elementów dyskretnych wynosi od 6 do 10. Natomiast dla układu hybrydowego
liczba wymaganych warstw wynosi 4 lub nawet 2 w przypadku niewykorzystywania wszystkich
sygnałów peryferyjnych układu. Dla porównania na rys. 3.1.1 i 3.1.2 przedstawiono rozwiązanie
modułu PCB mikrokomputera Beagle Bone Black wykonanego w technice dyskretnej
oraz przy wykorzystaniu układu hybrydowego OSD335x.
Rys. 3.1.1 Elementy obwodu drukowanego zastępowane przez układ hybrydowy OSD335x.
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 10 z 45
Rys. 3.1.2 Porównanie modułu Beagle Bone Black wykonanego w technice dyskretnej oraz przy wykorzystaniu układu hybrydowego OSD335x.
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 11 z 45
Budowę wewnętrzną układu OSD335x-SM przedstawiono na rys. 3.1.3.
Rys. 3.1.3 Budowa układu OSD335x-SM.
Układ OSD335x-SM składa się z:
rdzenia MPU firmy Texas Instruments AM335x,
512 MB pamięci DDR3L SDRAM,
4Kb EEPROM,
układu stabilizatora liniowego LDO TL5209,
układu kontrolera zasilania PMIC PS65217C.
Parametry rdzenia MPU AM335x:
jednostka CPU ARM Cortex-A8 32-bit RISC,
taktowanie zegara 800-MHz maksymalnie 1GHz,
koprocesor NEON ™ SIMD,
2 jednostki PRU,
pamięd cache 32KB / 32KB L1 Instrukcji / Dane,
256 KB pamięci podręcznej L2 z Error CorrectingCode (ECC),
2 porty USB 2.0 OTG,
7 portów szeregowych (2 x I2C, 2 x SPI, 2 x SDIO, 1 x CAN ).
Całośd umieszczona jest w obudowie BGA o liczbie padów 256 i rastrze wyprowadzeo kulek 1.27 mm.
Zaletą układu MPU OSD335x-SM jest również integracja w strukturze dwóch niezależnych jednostek
PRU.
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 12 z 45
PRU to autonomiczna jednostka mikroprocesora 32-bitowego pozwalająca na realizację zadao
o charakterze deterministycznym. Zasoby sprzętowe jednostki PRU nie są tak duże jak zewnętrznych
mikroprocesorów, ale zaleta wynikająca z umieszczenia ich w jednej strukturze w dużym stopniu
niweluje te ograniczenia. Największym ograniczeniem w relacji do zewnętrznych mikrokontrolerów
jest mniejsza pamięd kodu i danych. W omawianym układzie kod programu jednostki PRU nie może
byd większy niż 8kB, a dane - niż 20kB. Częstotliwośd pracy jednostki PRU wynosi 200 MHz.
Dzięki podłączeniu przez dedykowane magistrale do układów peryferyjnych, jednostki PRU mogą
w pełni niezależnie odczytywad i zapisywad dane z/do rejestrów. Bezpośredni dostęp do rejestrów
warstwy sprzętowej MAC pozwala na realizację komunikacji w standardzie EtherCAT i ProfiNET
w czasie rzeczywistym.
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 13 z 45
3.1.2 Wybór rozmiaru obwodu drukowanego PCB
Zgodnie z wytycznymi z punktu 2 założono wymiar obwodu drukowanego PCB modułu SoM
o geometrii 52 mm x 60 mm. Na stronie dolnej obwodu drukowanego PCB umieszczono cztery złącza
do montażu powierzchniowego. Jako złącze powierzchniowe wybrano rozwiązanie firmy TE
Connectivity o numerze 5177983-1. Złącze charakteryzują: raster wyprowadzeo - 0.8 mm, liczba
pinów - 40 oraz dwa kołki pozycjonujące zlokalizowane w obudowie. Pozwala to na jednoznaczne
pozycjonowanie złącza podczas automatycznego montażu Pick & Place pakietu obwodu
drukowanego PCB. Ułożenie złącz zostało tak dobrane, żeby nie było możliwości odwrotnego
włożenia modułu w złącza płytki docelowej. Dodatkowo w rogach obwodu drukowanego PCB
umieszczono otwory o średnicy 3.1mm pozwalające na przykręcenie modułu do płytki docelowej.
Szczegółowe wymiary modułu SoM przedstawiono na rys. 3.2.1.
Rys. 3.1.2 Wymiary modułu SoM.
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 14 z 45
3.1.3 Wybór stosu obwodu drukowanego
Na rys. 3.3.1 przedstawiono budowę stosu obwodu drukowanego PCB modułu SoM.
Obwód drukowany składa się z czterech warstw miedzi. Warstwy wewnętrzne mają grubośd 18 um,
a zewnętrzne - 35 um. Izolacja pomiędzy warstwami wynosi 360 um i jest realizowana
za pośrednictwem dwóch folii typu 7628 AT 01. Rdzeo ma grubośd 710 um. Dla tak dobranego stosu
grubośd koocowa otrzymanego obwodu drukowanego PCB wyniesie 1.55 mm, a względna stała
dielektryczna dla obu par warstw - 4.6.
Rys. 3.1.3 Budowa stosu obwodu drukowanego PCB.
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 15 z 45
3.1.4 Obliczenia impedancji różnicowej
W celu zapewnienia maksymalnego dopasowania energetycznego dla sygnałów różnicowych
interfejsu USB i Ethernet, dokonano obliczeo wymaganych średnic i odległości ścieżek linii
sygnałowych. Obliczenia wykonano w oprogramowaniu Saturn PCB Toolkit rys. 3.4.1.
Rys. 3.1.4 Obliczenia dla linii sygnałowych interfejsu USB.
Dla linii sygnałowych USB otrzymano następujące wyniki:
średnica ścieżki 0.35mm,
odległośd w parze 0.15 mm.
Dla linii sygnałowych Ethernet otrzymano następujące wyniki:
średnica ścieżki 0.28 mm,
odległośd w parze 0.15 mm.
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 16 z 45
3.2 Schemat ideowy modułu SoM
Schemat ideowy opracowanego rozwiązania modułu SoM został zmieszczony w załączniku
do sprawozdania. Schemat rozwiązania podzielony jest na pięd stron. Na stronie pierwszej
przedstawiono schemat połączenia układu OSD335x-SM wraz z przypisaniem sygnałów do pinów
złącz. Ponieważ układ OSD335x-SM charakteryzuje możliwośd wczytania oprogramowania z różnych
typów pamięci oraz interfejsów, dokonano wstępnej polaryzacji pinów odpowiedzialnych za wybór
i ograniczono go do dwóch typów pamięci. Wybór, z której pamięci nastąpi pierwsza próba
wczytania oprogramowania określona jest za pośrednictwem zwory J4. Układ OSD335x-SM wymaga
podłączenia dwóch rezonatorów kwarcowych 24MHz i 32.768kHz do prawidłowego działania.
Domyślnie port komunikacyjny UART1 wykorzystany jest jako konsola systemowa i oprócz
wyprowadzenia go na złącze wyjściowe, sygnał linii nadawania i odbierania dołączony jest do złącza
J5. Pozwoli to na wykonanie wstępnego testu funkcyjnego modułu bez konieczności jego montażu
w urządzeniu docelowym przy założeniu, że do złącza J7 zostanie dołączone napięcie zasilania
o wartości 5V. W celu sygnalizacji optycznej poprawności działania modułu dodano diodę LED,
do której należy podłączyd sygnał Hearbeat z jądra sytemu operacyjnego. Sygnał przerywany
sygnalizuje poprawne działanie systemu. Na stronie drugiej schematu przedstawiono cześd zasilającą
układu OSD335x-SM. Zgodnie z poprawką producenta rdzenia AM335x, w celu zapewnienia
poprawności działania funkcji usypiania wymagane jest dodanie zwory elektronicznej pomiędzy
dwoma napięciami zasilania. Funkcję tę realizuje tranzystor Q1 i układ detektora napięcia U2. W celu
komunikacji z wewnętrznym układem zasilania PMIC połączono linię zegarową PMIC_SCL z I2C0SCL
i linię danych PMIC_SDA z I2C0_SDA. Dzięki temu możliwe jest konfigurowanie układu zasilania
za pośrednictwem magistrali I2C o numerze 0. Ponieważ wewnętrzny układ pamięci EEPROM
jest zabezpieczony przez zapisem, pin EEPROM_WP spolaryzowano rezystorem R29 do potencjału
zera logicznego, dzięki czemu możliwe jest wykonywanie operacji zapisu pamięci nieulotnej.
Na stronie trzeciej przedstawiono schemat ideowy połączenia elementów dyskretnych wymaganych
przez układ warstwy fizycznej Ethernet PHY. Wybrany układ KSZ8041FTLI pozwala na pracę w trybie
10 lub 100 Mb/s oraz obsługuje komunikację optyczną za pośrednictwem układu nadajnika
i odbiornika światłowodowego. Wybór adresu, pod jakim zgłasza się układ KSZ8041FTLI w warstwie
MAC układu OSD335x-SM definiowany jest za pośrednictwem rezystorów polaryzujących R20 i R21.
W module SoM założono obsługę dwóch układów KSZ8041FTLI pod adresami 0 i 1. Wybrany tryb
pracy RMII ustawiany jest przez spolaryzowanie rezystorem R15 pinu o nazwie COL. Na stronie
czwartej i piątej przedstawiono połączenie sygnałów do pamięci masowej eMMC i MMC/SD. Oba
typy pamięci wymagają rezystorów podciągających linie magistrali w stanach przejściowych.
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 17 z 45
3.3 Schemat obwodu drukowanego PCB
Na rys. od 3.3.1 do 3.3.4 przedstawiono widok warstw opracowane obwodu drukowanego.
Rys. 3.3.1 Pierwsza warstwa obwodu drukowanego PCB modułu SoM.
Rys. 3.3.2 Druga warstwa obwodu drukowanego PCB modułu SoM.
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 18 z 45
Rys. 3.3.3 Trzecia warstwa obwodu drukowanego PCB modułu SoM.
Rys. 3.3.4 Czwarta warstwa obwodu drukowanego PCB modułu SoM.
Dla linii sygnałowych interfejsu USB i Ethernet wykonano wyrównanie długości ścieżek tak,
aby uzyskad zgodnośd faz impulsu na pinach złącza. Dla linii zegarowej pamięci eMMC
oraz MMC/SD wykonano operacje wydłużenia linii tak, aby były one najdłuższymi z całej wiązki
sygnałów danego interfejsu. Na warstwie drugiej rozprowadzono jednolitą powierzchnię masy GND,
a na trzeciej napięcia zasilania 3.3V.
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 19 z 45
3.4 Model 3D obwodu drukowanego
Na rys. 3.4.1 i 3.4.2 przedstawiono widok modelu 3D opracowanego obwodu drukowanego PCB
modułu SoM.
Rys. 3.4.1 Strona górna modułu SoM.
Rys. 3.4.2 Strona dolna modułu SoM.
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 20 z 45
3.5 Opracowanie oprogramowania systemowego
Oprogramowanie systemowe modułu SoM opracowano na bazie systemu operacyjnego Linux.
Jako narzędzie do budowy systemu plików Rootfs oraz jądra systemu wybrano rozwiązanie Buildroot
*6+. Oprogramowanie Buildroot tworzy obraz docelowego systemu na podstawie skryptów
konfiguracyjnych wywoływanych w ściśle określonej kolejności. Jako pierwsze wykonywane są
skrypty pobierające pliki kompilatora oraz pliki źródłowe aplikacji Rootfs, jadra systemu
oraz bootloadera u-boot. Następnie wykonywana jest operacja kompilacji plików źródłowych
do postaci binarnej. Jeżeli w trakcie kompilacji nie wystąpi błąd i zostaną utworzone pliki binarne
wykonywany jest skrypt mający za zadanie utworzenie obrazu systemu w formacie IMG zawierający
dane Rootfs, bootloadera oraz pliki jądra systemu Linux.
Żeby wykorzystad narzędzie Buildroot do utworzenia obrazu systemu należy utworzyd
w folderze config nowy plik opisowy żądanego do zbudowania systemu operacyjnego.
W pliku należy podad typ architektury rdzenia na jakim ma zostad utworzony system
oraz podad skąd mają zostad pobrane pliki źródłowe jądra sytemu Linux oraz bootloadera u-boot,
ścieżkę do folderu z plikami rozszerzeo tzw. PATCHES oraz zdefiniowad jakie parametry aplikacji mają
zostad dodane do systemu. Plik konfiguracyjny dla opracowanego modułu SoM przedstawiono
poniżej.
BR2_arm=y
BR2_cortex_a8=y
BR2_GLOBAL_PATCH_DIR="board/beaglebone/patches"
BR2_TOOLCHAIN_BUILDROOT_GLIBC=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV=y
BR2_TARGET_GENERIC_GETTY_PORT="ttyO0"
BR2_ROOTFS_POST_IMAGE_SCRIPT="$(BR2_EXTERNAL_ITR_EXT_PATH)/board/octavo/pos
t-image.sh"
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_GIT=y
BR2_LINUX_KERNEL_CUSTOM_REPO_URL="https://github.com/beagleboard/linux.git"
BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="4.9"
BR2_LINUX_KERNEL_DEFCONFIG="bb.org"
BR2_LINUX_KERNEL_DTS_SUPPORT=y
BR2_LINUX_KERNEL_INTREE_DTS_NAME="am335x-evm am335x-bone am335x-boneblack
am335x-evmsk"
BR2_PACKAGE_FBV=y
BR2_PACKAGE_QT5=y
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 21 z 45
BR2_PACKAGE_QT5BASE_EXAMPLES=y
BR2_PACKAGE_QT5BASE_EGLFS=y
BR2_PACKAGE_QT5QUICKCONTROLS=y
BR2_PACKAGE_LIBMODBUS=y
BR2_PACKAGE_GD=y
BR2_PACKAGE_LIBSSH=y
BR2_PACKAGE_OPENSSL_BIN=y
BR2_PACKAGE_LIBPNG=y
BR2_PACKAGE_LIBPCAP=y
BR2_PACKAGE_ETHTOOL=y
BR2_PACKAGE_OPENSSH=y
BR2_PACKAGE_PPPD=y
BR2_PACKAGE_SSHPASS=y
BR2_PACKAGE_SUDO=y
BR2_PACKAGE_HTOP=y
BR2_PACKAGE_NANO=y
BR2_TARGET_ROOTFS_EXT2=y
BR2_TARGET_ROOTFS_EXT2_4=y
BR2_TARGET_UBOOT=y
BR2_TARGET_UBOOT_BUILD_SYSTEM_KCONFIG=y
BR2_TARGET_UBOOT_CUSTOM_VERSION=y
BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE="2017.01"
BR2_TARGET_UBOOT_BOARD_DEFCONFIG="am335x_boneblack"
BR2_TARGET_UBOOT_NEEDS_DTC=y
BR2_TARGET_UBOOT_FORMAT_IMG=y
BR2_TARGET_UBOOT_FORMAT_CUSTOM=y
BR2_TARGET_UBOOT_FORMAT_CUSTOM_NAME="spl/u-boot-spl.bin"
BR2_TARGET_UBOOT_SPL=y
BR2_TARGET_UBOOT_SPL_NAME="MLO"
BR2_PACKAGE_HOST_DOSFSTOOLS=y
BR2_PACKAGE_HOST_GENIMAGE=y
BR2_PACKAGE_HOST_MTOOLS=y
Nazwy rozpoczynające się na BR2_PACKAGE dotyczą aplikacji Rootfs, BR2_TARGET_UBOOT -
konfiguracji bootloadera u-boot, a na BR2_LINUX_KERNEL - jądra system Linux. Od wersji 4. jądra
systemu Linux do konfiguracji warstwy sprzętowej został wprowadzony opis symboliczny za pomocą
pliku drzewa urządzeo „Device Tree”. Stworzony plik opisowy dla modułu SoM przedstawiono
poniżej.
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 22 z 45
/ {
cpus {
cpu@0 {
cpu0-supply = <&dcdc2_reg>;
};
};
memory@80000000 {
device_type = "memory";
reg = <0x80000000 0x10000000>; /* 256 MB */
};
chosen {
stdout-path = &uart0;
};
leds {
pinctrl-names = "default";
pinctrl-0 = <&user_leds_s0>;
compatible = "gpio-leds";
led2 {
label = "octavo:green:heartbeat";
gpios = <&gpio3 20 GPIO_ACTIVE_LOW>;
linux,default-trigger = "heartbeat";
default-state = "off";
};
};
vmmcsd_fixed: fixedregulator0 {
compatible = "regulator-fixed";
regulator-name = "vmmcsd_fixed";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
};
};
&am33xx_pinmux {
pinctrl-names = "default";
pinctrl-0 = <&clkout2_pin>;
user_leds_s0: user_leds_s0 {
pinctrl-single,pins = <
AM33XX_IOPAD(0x9A8, PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
mcasp0_axr1.gpio3_20 */
>;
};
i2c0_pins: pinmux_i2c0_pins {
pinctrl-single,pins = <
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 23 z 45
AM33XX_IOPAD(0x988, PIN_INPUT_PULLUP | MUX_MODE0)
/* i2c0_sda.i2c0_sda */
AM33XX_IOPAD(0x98c, PIN_INPUT_PULLUP | MUX_MODE0)
/* i2c0_scl.i2c0_scl */
>;
};
uart0_pins: pinmux_uart0_pins {
pinctrl-single,pins = <
AM33XX_IOPAD(0x970, PIN_INPUT_PULLUP | MUX_MODE0)
/* uart0_rxd.uart0_rxd */
AM33XX_IOPAD(0x974, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
uart0_txd.uart0_txd */
>;
};
cpsw_default: cpsw_default {
pinctrl-single,pins = <
/* Slave 1 */
AM33XX_IOPAD(0x944, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
rmii1_ref_clk.rmii1_ref_clk */
AM33XX_IOPAD(0x90C, PIN_INPUT_PULLUP | MUX_MODE1)
/* mii1_crs.mii1_crs */
AM33XX_IOPAD(0x910, PIN_INPUT_PULLUP | MUX_MODE1)
/* mii1_rxerr.mii1_rxerr */
AM33XX_IOPAD(0x914, PIN_OUTPUT_PULLDOWN | MUX_MODE1) /*
mii1_txen.mii1_txen */
AM33XX_IOPAD(0x924, PIN_OUTPUT_PULLDOWN | MUX_MODE1) /*
mii1_txd1.mii1_txd1 */
AM33XX_IOPAD(0x928, PIN_OUTPUT_PULLDOWN | MUX_MODE1) /*
mii1_txd0.mii1_txd0 */
AM33XX_IOPAD(0x93c, PIN_INPUT_PULLUP | MUX_MODE1)
/* mii1_rxd1.mii1_rxd1 */
AM33XX_IOPAD(0x940, PIN_INPUT_PULLUP | MUX_MODE1)
/* mii1_rxd0.mii1_rxd0 */
>;
};
cpsw_sleep: cpsw_sleep {
pinctrl-single,pins = <
/* Slave 1 reset value */
AM33XX_IOPAD(0x944, PIN_OUTPUT_PULLDOWN | MUX_MODE7)
AM33XX_IOPAD(0x90C, PIN_INPUT_PULLUP | MUX_MODE7)
AM33XX_IOPAD(0x910, PIN_INPUT_PULLUP | MUX_MODE7)
AM33XX_IOPAD(0x914, PIN_OUTPUT_PULLDOWN | MUX_MODE7)
AM33XX_IOPAD(0x924, PIN_OUTPUT_PULLDOWN | MUX_MODE7)
AM33XX_IOPAD(0x928, PIN_OUTPUT_PULLDOWN | MUX_MODE7)
AM33XX_IOPAD(0x93c, PIN_INPUT_PULLUP | MUX_MODE7)
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 24 z 45
AM33XX_IOPAD(0x940, PIN_INPUT_PULLUP | MUX_MODE7)
>;
};
davinci_mdio_default: davinci_mdio_default {
pinctrl-single,pins = <
/* MDIO */
AM33XX_IOPAD(0x948, PIN_INPUT_PULLUP | SLEWCTRL_FAST |
MUX_MODE0) /* mdio_data.mdio_data */
AM33XX_IOPAD(0x94c, PIN_OUTPUT_PULLUP | MUX_MODE0)
/* mdio_clk.mdio_clk */
>;
};
davinci_mdio_sleep: davinci_mdio_sleep {
pinctrl-single,pins = <
/* MDIO reset value */
AM33XX_IOPAD(0x948, PIN_INPUT_PULLDOWN | MUX_MODE7)
AM33XX_IOPAD(0x94c, PIN_INPUT_PULLDOWN | MUX_MODE7)
>;
};
mmc1_pins: pinmux_mmc1_pins {
pinctrl-single,pins = <
AM33XX_IOPAD(0x960, PIN_INPUT | MUX_MODE7) /* GPIO0_6 */
>;
};
emmc_pins: pinmux_emmc_pins {
pinctrl-single,pins = <
AM33XX_IOPAD(0x880, PIN_INPUT_PULLUP | MUX_MODE2) /*
gpmc_csn1.mmc1_clk */
AM33XX_IOPAD(0x884, PIN_INPUT_PULLUP | MUX_MODE2) /*
gpmc_csn2.mmc1_cmd */
AM33XX_IOPAD(0x800, PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad0.mmc1_dat0 */
AM33XX_IOPAD(0x804, PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad1.mmc1_dat1 */
AM33XX_IOPAD(0x808, PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad2.mmc1_dat2 */
AM33XX_IOPAD(0x80c, PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad3.mmc1_dat3 */
AM33XX_IOPAD(0x810, PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad4.mmc1_dat4 */
AM33XX_IOPAD(0x814, PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad5.mmc1_dat5 */
AM33XX_IOPAD(0x818, PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad6.mmc1_dat6 */
AM33XX_IOPAD(0x81c, PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad7.mmc1_dat7 */
>;
};
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 25 z 45
lcd_pins_default: lcd_pins_default {
pinctrl-single,pins = <
AM33XX_IOPAD(0x8a0, PIN_OUTPUT | MUX_MODE0)
/* lcd_data0.lcd_data0 */
AM33XX_IOPAD(0x8a4, PIN_OUTPUT | MUX_MODE0)
/* lcd_data1.lcd_data1 */
AM33XX_IOPAD(0x8a8, PIN_OUTPUT | MUX_MODE0)
/* lcd_data2.lcd_data2 */
AM33XX_IOPAD(0x8ac, PIN_OUTPUT | MUX_MODE0)
/* lcd_data3.lcd_data3 */
AM33XX_IOPAD(0x8b0, PIN_OUTPUT | MUX_MODE0)
/* lcd_data4.lcd_data4 */
AM33XX_IOPAD(0x8b4, PIN_OUTPUT | MUX_MODE0)
/* lcd_data5.lcd_data5 */
AM33XX_IOPAD(0x8b8, PIN_OUTPUT | MUX_MODE0)
/* lcd_data6.lcd_data6 */
AM33XX_IOPAD(0x8bc, PIN_OUTPUT | MUX_MODE0)
/* lcd_data7.lcd_data7 */
AM33XX_IOPAD(0x8c0, PIN_OUTPUT | MUX_MODE0)
/* lcd_data8.lcd_data8 */
AM33XX_IOPAD(0x8c4, PIN_OUTPUT | MUX_MODE0)
/* lcd_data9.lcd_data9 */
AM33XX_IOPAD(0x8c8, PIN_OUTPUT | MUX_MODE0)
/* lcd_data10.lcd_data10 */
AM33XX_IOPAD(0x8cc, PIN_OUTPUT | MUX_MODE0)
/* lcd_data11.lcd_data11 */
AM33XX_IOPAD(0x8d0, PIN_OUTPUT | MUX_MODE0)
/* lcd_data12.lcd_data12 */
AM33XX_IOPAD(0x8d4, PIN_OUTPUT | MUX_MODE0)
/* lcd_data13.lcd_data13 */
AM33XX_IOPAD(0x8d8, PIN_OUTPUT | MUX_MODE0)
/* lcd_data14.lcd_data14 */
AM33XX_IOPAD(0x8dc, PIN_OUTPUT | MUX_MODE0)
/* lcd_data15.lcd_data15 */
AM33XX_IOPAD(0x8e0, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
lcd_vsync.lcd_vsync */
AM33XX_IOPAD(0x8e4, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
lcd_hsync.lcd_hsync */
AM33XX_IOPAD(0x8e8, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
lcd_pclk.lcd_pclk */
AM33XX_IOPAD(0x8ec, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
lcd_ac_bias_en.lcd_ac_bias_en */
>;
};
};
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins>;
status = "okay";
};
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 26 z 45
&usb {
status = "okay";
};
&usb_ctrl_mod {
status = "okay";
};
&usb0_phy {
status = "okay";
};
&usb1_phy {
status = "okay";
};
&usb0 {
status = "okay";
dr_mode = "peripheral";
interrupts-extended = <&intc 18 &tps 0>;
interrupt-names = "mc", "vbus";
};
&usb1 {
status = "okay";
dr_mode = "host";
};
&cppi41dma {
status = "okay";
};
&i2c0 {
pinctrl-names = "default";
pinctrl-0 = <&i2c0_pins>;
status = "okay";
clock-frequency = <400000>;
tps: tps@24 {
reg = <0x24>;
};
baseboard_eeprom: baseboard_eeprom@50 {
compatible = "atmel,24c256";
reg = <0x50>;
#address-cells = <1>;
#size-cells = <1>;
baseboard_data: baseboard_data@0 {
reg = <0 0x100>;
};
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 27 z 45
};
};
&i2c2 {
pinctrl-names = "default";
pinctrl-0 = <&i2c2_pins>;
status = "okay";
clock-frequency = <400000>;
};
&lcdc {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&lcd_pins_default>;
display-timings {
800x480p62 {
clock-frequency = <30000000>;
hactive = <800>;
vactive = <480>;
hfront-porch = <39>;
hback-porch = <39>;
hsync-len = <47>;
vback-porch = <29>;
vfront-porch = <13>;
vsync-len = <2>;
hsync-active = <1>;
vsync-active = <1>;
};
};
};
/include/ "tps65217.dtsi"
&tps {
/*
* Configure pmic to enter OFF-state instead of SLEEP-state ("RTC-
only
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 28 z 45
* mode") at poweroff. Most BeagleBone versions do not support RTC-
only
* mode and risk hardware damage if this mode is entered.
*
* For details, see linux-omap mailing list May 2015 thread
* [PATCH] ARM: dts: am335x-bone* enable pmic-shutdown-controller
* In particular, messages:
* http://www.spinics.net/lists/linux-omap/msg118585.html
* http://www.spinics.net/lists/linux-omap/msg118615.html
*
* You can override this later with
* &tps { /delete-property/ ti,pmic-shutdown-controller; }
* if you want to use RTC-only mode and made sure you are not
affected
* by the hardware problems. (Tip: double-check by performing a
current
* measurement after shutdown: it should be less than 1 mA.)
*/
interrupts = <7>; /* NMI */
interrupt-parent = <&intc>;
ti,pmic-shutdown-controller;
charger {
status = "okay";
};
pwrbutton {
status = "okay";
};
regulators {
dcdc1_reg: regulator@0 {
regulator-name = "vdds_dpr";
regulator-always-on;
};
dcdc2_reg: regulator@1 {
/* VDD_MPU voltage limits 0.95V - 1.26V with +/-4%
tolerance */
regulator-name = "vdd_mpu";
regulator-min-microvolt = <925000>;
regulator-max-microvolt = <1351500>;
regulator-boot-on;
regulator-always-on;
};
dcdc3_reg: regulator@2 {
/* VDD_CORE voltage limits 0.95V - 1.1V with +/-4%
tolerance */
regulator-name = "vdd_core";
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 29 z 45
regulator-min-microvolt = <925000>;
regulator-max-microvolt = <1150000>;
regulator-boot-on;
regulator-always-on;
};
ldo1_reg: regulator@3 {
regulator-name = "vio,vrtc,vdds";
regulator-always-on;
};
ldo2_reg: regulator@4 {
regulator-name = "vdd_3v3aux";
regulator-always-on;
};
ldo3_reg: regulator@5 {
regulator-name = "vdd_1v8";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
};
ldo4_reg: regulator@6 {
regulator-name = "vdd_3v3a";
regulator-always-on;
};
};
};
&cpsw_emac0 {
phy_id = <&davinci_mdio>, <0>;
phy-mode = "rmii";
};
&mac {
slaves = <1>;
pinctrl-names = "default", "sleep";
pinctrl-0 = <&cpsw_default>;
pinctrl-1 = <&cpsw_sleep>;
status = "okay";
};
&davinci_mdio {
pinctrl-names = "default", "sleep";
pinctrl-0 = <&davinci_mdio_default>;
pinctrl-1 = <&davinci_mdio_sleep>;
status = "okay";
};
&mmc1 {
status = "okay";
vmmc-supply = <&vmmcsd_fixed>;
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 30 z 45
bus-width = <0x4>;
pinctrl-names = "default";
pinctrl-0 = <&mmc1_pins>;
cd-gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;
};
&mmc2 {
status = "okay";
vmmc-supply = <&vmmcsd_fixed>;
bus-width = <8>;
pinctrl-names = "default";
pinctrl-0 = <&emmc_pins>;
};
&aes {
status = "okay";
};
&sham {
status = "okay";
};
&rtc {
clocks = <&clk_32768_ck>, <&clkdiv32k_ick>;
clock-names = "ext-clk", "int-clk";
};
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 31 z 45
3.5.1 Konfiguracja kontrolera pamięci DDR
Ponieważ układ OSD335x-SM nie posiada zaprogramowanej pamięci EEPROM, domyślna konfiguracja
pamięci DDR wykonywana przez program u-boota kooczy się niepowodzeniem. Wymagane jest
przeprowadzenie wstępnego uruchomienia ze specjalnie zmodyfikowanym kodem. W tym celu
w metodzie sdram_init w pliku u-boot/board/ti/am335x/board.c należy dodad wywołanie funkcji
config_ddr z odpowiednimi wartościami parametrów czasowych użytej pamięci DDR. Ponieważ układ
OSD335x-SM jest kompatybilny z Beagle Bone Black można zastosowad nastawy przypisane
dla pamięci tego mikrokomputera.
void sdram_init(void) { /* config ddr for custom hardware */ config_ddr(400, &ioregs_bonelt, &ddr3_beagleblack_data, &ddr3_beagleblack_cmd_ctrl_data, &ddr3_beagleblack_emif_reg_data, 0);
return; }
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 32 z 45
3.5.2 Zapis pamięci EEPROM
W celu wprowadzenia do pamięci EEPROM danych identyfikacyjnych modułu tak, aby możliwe było
użycie standardowego kodu konfiguracyjnego bootloadera u-boot, do zmiennych środowiskowych
należy dopisad instrukcję eeinit. Każdorazowe uruchomienie polecenia eeinit skutkuje zapisem
do pamięci EEPROM zdefiniowanych wartości danych. Zmianę zmiennych środowiskowych
wykonujemy edytując plik o nazwie u-boot/include/configs/am335x_evm.h. Polecenie eeinit należy
dopisad do definicji zmiennej CONFIG_EXTRA_ENV_SETTINGS.
#define CONFIG_EXTRA_ENV_SETTINGS \
… "eeinit =" \
"i2c mw 50 0000.2 0xAA 1;"\ "i2c mw 50 0001.2 0x55 1;"\ "i2c mw 50 0002.2 0x33 1;"\ "i2c mw 50 0003.2 0xEE 1;"\ "i2c mw 50 0004.2 0x41 1;"\ "i2c mw 50 0005.2 0x33 1;"\ "i2c mw 50 0006.2 0x33 1;"\ "i2c mw 50 0007.2 0x35 1;"\ "i2c mw 50 0008.2 0x42 1;"\ "i2c mw 50 0009.2 0x4E 1;"\ "i2c mw 50 000A.2 0x4C 1;"\ "i2c mw 50 000B.2 0x54 1;\0"\
…
Dodatkowo należy dodad polecenie uruchomienia instrukcji eeinit w definicji zmiennej
CONFIG_BOOTCOMMAND.
#define CONFIG_BOOTCOMMAND \
"run eeinit; "\ "run findfdt; "\ "run mmcboot; "\ "setenv mmcdev 1; "\ "setenv bootpart 1:2; "\ "run mmcboot; "\
"run nandboot;" …
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 33 z 45
3.5.3 Obsługa modemu GSM
W celu dodania obsługi modemu 3G/4G, wymagane jest dodanie obsługi protokołu PPP oraz klasy
CDC interfejsu USB do jądra systemu operacyjnego Linux. W tym celu korzystając
z polecenia menuconfig należy wybrad i ustawid na aktywne następujące opcje:
CONFIG_PPP:
PPP (Point to Point Protocol) is a newer and better SLIP. It serves the same purpose: sending Internet
traffic over telephone (and other serial) lines. Ask your access provider if they support it, because
otherwise you can't use it; most Internet access providers these days support PPP rather than SLIP.
Device Drivers --->
[*] Network device support --->
PPP (point-to-point protocol) support
PPP BSD-Compress compression
PPP Deflate compression
[*] PPP filtering
PPP MPPE compression (encryption)
[*] PPP multilink support
PPP over Ethernet
PPP support for async serial ports
PPP support for sync tty ports
CONFIG_USB_ACM:
This driver supports USB modems and ISDN adapters which support the
Communication Device Class Abstract Control Model interface.
Please read <file:Documentation/usb/acm.txt> for details.
Device Drivers --->
[*] USB support --->
USB Modem (CDC ACM) support
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 34 z 45
Następnie należy utworzyd następujące pliki konfigurujące:
plik konfiguracyjny protokołu PPP /etc/ppp/options
auth
crtscts
lock
hide-password
modem
mru 296
mtu 296
lcp-echo-interval 30
lcp-echo-failure 4
noipx
persist
asyncmap 0xa0000
mru 1500
refuse-chap
ipcp-max-failure 30
logfile /home/root/ppp
plik zawierający hasło /etc/ppp/pap-secrets
# * password test test test
plik zawierający dane konfiguracyjne dostawcy internetu /etc/ppp/peers/test-3g.provider
hide-password
noauth
debug
defaultroute
noipdefault
user vivo
remotename test
ipparam test
persist
usepeerdns
/dev/ttyUSB0 115200 crtscts
replacedefaultroute
connect 'chat -v -f /etc/ppp/chat/test-3g.chat'
plik zawierający listę poleceo AT modemu /etc/ppp/chat/test-3g.chat
ECHO
ON
ABORT
'BUSY'
ABORT
'NO CARRIER'
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 35 z 45
ABORT
'ERROR'
""
ATZ OK
\d\dAT+CGDCONT=1,"IP","internet" OK
\d\d\dATDT*99# CONNECT
Następnie należy dodad do listy skryptów startowych systemu operacyjnego polecenie uruchomienia
protokołu PPP po starcie systemu. W tym celu należy utworzyd plik 100.ppp.init i dodad go do folderu
/etc/init.d.
#!/bin/sh
start() {
pon test-3g.provider
# utworzenie nowego kanał PPP
}
stop() {
poff
# zamykamy utworzony kanał PPP
}
case "$1" in
start)
start
;;
stop)
stop
;;
restart)
stop
start
;;
*)
echo "Usage: /etc/init.d/100.ppp.init {start|stop|restart}"
exit 1
esac
exit 0
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 36 z 45
Wynikiem działania skryptu będzie utworzenie nowego interfejsu PPP w drzewie urządzeo.
W celu wyświetlenia drzewa urządzeo, należy w oknie terminala wydad polecenie ifconfig.
Jeżeli interfejs został utworzony na liście zostanie wyświetlony wpis o nazwie ppp*x+.
eth0 Link encap:Ethernet HWaddr 00:14:2D:C0:00:4C
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:1181 errors:0 dropped:0 overruns:0 frame:0
TX packets:1223 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:107025 (104.5 KiB) TX bytes:149841 (146.3 KiB)
ppp0 Link encap:Point-to-Point Protocol
inet addr:179.133.47.109 P-t-P:179.133.47.109 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:296 Metric:1
RX packets:13 errors:0 dropped:0 overruns:0 frame:0
TX packets:35 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:1330 (1.2 KiB) TX bytes:2131 (2.0 KiB)
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 37 z 45
3.6 Wykonanie i badanie modelu CLU
Na rys. 3.6.1 przedawniono zdjęcie opracowanego modułu SoM, a na rys. 3.6.2 zdjęcie wpiętego
modułu SoM do opracowanej płytki bazowej. Na płytce bazowej PCB umieszczono transformatory
impulsowe dla łącz Ethernet, złącze modemu GSM wraz z złączem karty SIM, złącza USB typu A i mini
B, złącze TTL do wyświetlacza LCD 4.3” oraz złącze zasilania.
Rys. 3.6.1 Model opracowanego modułu SoM.
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 38 z 45
Rys. 3.6.2 Opracowana płytka bazowa z wpiętym modułem SoM.
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 39 z 45
3.6.1 Badanie interfejsu Ethernet
Opracowany moduł SoM wyposażony jest w dwa układy warstwy fizycznej Ethernet PHY
KSZ8041FTLI. W celu sprawdzenia poprawności działania jak i określenia szybkości transmisji danych
z układów wykonano test obciążenia wykorzystujący oprogramowanie testowe
IPerf. IPerf to aplikacja pracująca w trybie klient-serwer. Aplikacja serwera oraz aplikacja klienta
mogą zostad uruchomione pod kontrolą systemu operacyjnego Linux jak i MS Windows.
Procedura badania polegała na utworzeniu na jednym z komputerów w sieci lokalnej, do której
był wpięty moduł SoM serwera i wykonaniu połączenia testowego do niego
z modułu SoM.
W celu uruchomienia aplikacji serwera na komputerze PC należy w oknie terminala wydad polecenie:
iperf -s -p 45678 -i 1
Następnie na module należy uruchomid aplikację klienta wykonując polecenie:
iperf -c 192.168.1.180 -p 45678 -t 30 -P 8 -i 1
Wynikiem badania jest wypisanie na okno terminala szybkości transmisji w MB/s rys. 3.6.3
Rys. 3.6.3 Wynik badania szybkości transmisji.
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 40 z 45
3.6.2 Badanie interfejsu transmisji szeregowej UART
Badanie transmisji szeregowej UART polegało na wyznaczeniu czasu potrzebnego na przesłanie
pomiędzy modułem SoM a komputerem PC ramki danych o zdefiniowanym rozmiarze - 1MB.
Ponieważ szybkośd transmisji jest zdefiniowana i określona przez standardowe wartości, celem
badania było wyznaczenie opóźnienia transmisji danych wynikającego z zapisów do kolejki FIFO
układu nadajnika przez system operacyjny Linux. Szybkośd transmisji danych ustalono na 460800
bitów/s. Jako odbiornik po stronie komputera PC zastosowano scalony konwerter FTDI o nazwie
C232HD-DDHSP-0. W celu przeprowadzenia testu na module SoM uruchomiono program rsTx,
który wysyła na zadanych parametrach transmisji dane z pliku testowego. Po zakooczeniu transmisji
danych program zwraca na konsolę ile czasu upłynęło od rozpoczęcia do zakooczenia zadania
transmisji danych. Po stronie komputera uruchomiono natomiast program rsRx, który zapisuje
odczytane dane do pliku o zadanej nazwie. W celu sprawdzenia czy odczytane dane nie zawierają
błędów wyliczono z otrzymanych danych sumę kontrolną MD5, którą porównano z sumą MD5 pliku
testowego.
W wyniku badania uzyskano wartośd czasu potrzebnego na przesłanie danych wynoszący 25.12 s.
Teoretycznych czas potrzebny na przesłanie 1MB danych wynosi 22.75 s, czyli wyznaczone
opóźnienie transmisji wyniosło 2.36 s.
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 41 z 45
3.6.3 Wyznaczenie poboru prądu
Kluczowym aspektem w eksploatacji modułu SoM jest określenie charakteru jak i wartości
pobieranego prądu przez moduł. Określnie wartości dla stanu ustalonego oraz charakteru zmian
w czasie pracy.
Prac związanych z tym zagadnieniem nie udało się zrealizowad i będą one kontynuowane.
Wykonanie badao w tym zakresie wymaga opracowania dodatkowych aplikacji systemowych
pozwalających na sztuczne obciążenie procesora oraz załączanie i wyłączanie poszczególnych
modułów jednostki MPU oraz GPU.
3.6.4 Analiza termiczna modułu SoM
Kluczowym aspektem w eksploatacji modułu SoM jest określenie temperatury nagrzewania
poszczególnych elementów modułu. W celu określenia temperatury nagrzewania, wymagane jest
przeprowadzenie badao dla różnych poziomów obciążenia procesora i załączonych lub wyłączonych
modułach jednostki MPU oraz GPU. Prac związanych z tym zagadnieniem nie udało się zrealizowad
i będą one kontynuowane w kolejnym roku. Badania te są ściśle powiązane z badaniami z zakresu
określenia poboru prądu.
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 42 z 45
4. Wyniki pracy
W ramach pracy opublikowano artykuł:
1. A. Nowakowski, K. Broda, R. Przybysz, P. Wlazło; „ITR-SOM-33735 - system w module
do zastosowao w warunkach przemysłowych”; Elektronika – nr 12/2017
Dokumentacje opracowanego modelu platformy sprzętowej i programowej zamieszczono
na serwerze w systemie elektronicznego nadzoru nad dokumentacją centrum CA. Dokonano wpisu
informacji o pracy badawczej w systemie SYNABA.
Rys. 4.1 Dokumentacja modelu SOM_01
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 43 z 45
5. Podsumowanie
W ramach pracy:
wykonano i przebadano model jednostki, w którym wykorzystano innowacyjny układ
OSD335x-SM produkcji OCTAVO System,
wykonano badanie:
szybkości transmisji łącz komunikacyjnych Ethernet i UART.
Nie zrealizowane badania poboru prądu oraz nagrzewania będą kontynuowane w ramach pracy
statutowej „Innowacyjne rozwiązania ICT do Inteligentnych Sieci i Internetu Rzeczy”, zadanie:
„Opracowanie mechanizmów zdalnej konfiguracji modułu komunikacyjnego dla Internetu Rzeczy”.
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 44 z 45
6. Syntetyczny opis pracy
Syntetyczny opis do Raportu ITR z wykorzystania środków finansowych na utrzymanie potencjału badawczego
Tytuł zadania:
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego
Internetu Rzeczy (IIoT).
Cel zadania: Opracowanie uniwersalnej jednostki CLU (Communication & Logic Unit)
wykorzystującej SoM do zastosowao w aplikacjach Przemysłowego Internetu
Rzeczy.
Opis
realizowanych
prac:
W ramach pracy wykonano następujące zadania:
Opracowano platformę sprzętową uniwersalnej jednostki CLU
wykorzystującą układ hybrydowy OSD335x-SM produkcji OCTAVO
System.
Zaprojektowano schematy oraz topologię ścieżek obwodów
drukowanych PCB wraz z dokumentacją produkcyjną.
Opracowano oprogramowanie systemowego uniwersalnej jednostki
CLU. W tym program bootloadera pierwszego poziomu na bazie
rozwiązania u-boot. Oprogramowanie systemowe na bazie systemu
operacyjnego Linux w wersji jądra systemu 4.9 wraz z modelem
drzewa urządzeo. Oba opracowane oprogramowania dodano, jako
rozszerzenie do systemu budowania obrazów systemowych
Buildroot.
Wykonano model jednostki CLU wraz z modelem płytki bazowej
umożliwiającej swobodną wymianę modułu i połączenie
z elementami peryferyjnymi: gniazda RJ-45, gniazda USB oraz
połączenie do modemu GSM i wyświetlacza LCD.
Przeprowadzono badania szybkości transmisji danych przez porty
komunikacji sieciowej Ethernet i interfejsy szeregowe.
Opis
najważniejszych
osiągnięd:
Realizacja projektu umożliwiła podniesienie kwalifikacji zespołu w zakresie
opracowywania systemów CLU bazujących na koncepcji System of Module.
Zwiększono kompetencje w zakresie wykorzystania systemu Linux,
dostosowania go do konkretnych wymagao, konfiguracji sterowników
warstwy sprzętowej i sieciowej MAC.
Opracowanie rozwiązao „System On Module” dla aplikacji Przemysłowego Internetu Rzeczy (IIoT)
R_34725_1 Strona 45 z 45
Wykorzystanie
uzyskanych
wyników:
Uzyskane wyniki posłużą przy opracowywaniu przyszłych rozwiązao
dedykowanych dla urządzeo elektroenergetyki, sieci inteligentnych, sieci
M2M, interfejsów operatorskich HMI oraz aplikacji Przemysłowego Internetu
Rzeczy IIoT.
Literatura
1. https://octavosystems.com
2. https://www.raspberrypi.org
3. https://beagleboard.org
4. http://www.nanopi.org/
5. http://www.orangepi.org/
6. https://buildroot.org/
7. R. Przybysz, P. Wlazło; Wykorzystanie standardu ethernet w rozwiązaniach automatyki
i zabezpieczeo sieci rozdzielczych SN; ElektroInfo 4/2014
Załączniki
1. Zał. 1 – Dokumentacja modułu SOM