Sprawozdanie z pracy badawczej finansowanej z dotacji ... · Zlecenie: 110-04910041 Okres...

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


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


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.


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.


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,


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,


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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


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.


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-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 {



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 {



/* uart0_rxd.uart0_rxd */

AM33XX_IOPAD(0x974, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*

uart0_txd.uart0_txd */

>;

};

cpsw_default: cpsw_default {


/* Slave 1 */


rmii1_ref_clk.rmii1_ref_clk */

AM33XX_IOPAD(0x90C, PIN_INPUT_PULLUP | MUX_MODE1)

/* mii1_crs.mii1_crs */


/* mii1_rxerr.mii1_rxerr */


mii1_txen.mii1_txen */


mii1_txd1.mii1_txd1 */


mii1_txd0.mii1_txd0 */


/* mii1_rxd1.mii1_rxd1 */


/* mii1_rxd0.mii1_rxd0 */

>;

};

cpsw_sleep: cpsw_sleep {


/* Slave 1 reset value */

AM33XX_IOPAD(0x944, PIN_OUTPUT_PULLDOWN | MUX_MODE7)

AM33XX_IOPAD(0x90C, PIN_INPUT_PULLUP | MUX_MODE7)







R_34725_1 Strona 24 z 45


>;

};

davinci_mdio_default: davinci_mdio_default {


/* 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 {


/* MDIO reset value */

AM33XX_IOPAD(0x948, PIN_INPUT_PULLDOWN | MUX_MODE7)

AM33XX_IOPAD(0x94c, PIN_INPUT_PULLDOWN | MUX_MODE7)

>;

};

mmc1_pins: pinmux_mmc1_pins {


AM33XX_IOPAD(0x960, PIN_INPUT | MUX_MODE7) /* GPIO0_6 */

>;

};

emmc_pins: pinmux_emmc_pins {


AM33XX_IOPAD(0x880, PIN_INPUT_PULLUP | MUX_MODE2) /*

gpmc_csn1.mmc1_clk */


gpmc_csn2.mmc1_cmd */


gpmc_ad0.mmc1_dat0 */





AM33XX_IOPAD(0x80c, PIN_INPUT_PULLUP | MUX_MODE1) /*








AM33XX_IOPAD(0x81c, PIN_INPUT_PULLUP | MUX_MODE1) /*


>;

};


R_34725_1 Strona 25 z 45

lcd_pins_default: lcd_pins_default {


AM33XX_IOPAD(0x8a0, PIN_OUTPUT | MUX_MODE0)

/* lcd_data0.lcd_data0 */





AM33XX_IOPAD(0x8ac, PIN_OUTPUT | MUX_MODE0)


AM33XX_IOPAD(0x8b0, PIN_OUTPUT | MUX_MODE0)






AM33XX_IOPAD(0x8bc, PIN_OUTPUT | MUX_MODE0)


AM33XX_IOPAD(0x8c0, PIN_OUTPUT | MUX_MODE0)






AM33XX_IOPAD(0x8cc, PIN_OUTPUT | MUX_MODE0)


AM33XX_IOPAD(0x8d0, PIN_OUTPUT | MUX_MODE0)






AM33XX_IOPAD(0x8dc, PIN_OUTPUT | MUX_MODE0)


AM33XX_IOPAD(0x8e0, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*

lcd_vsync.lcd_vsync */


lcd_hsync.lcd_hsync */


lcd_pclk.lcd_pclk */

AM33XX_IOPAD(0x8ec, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*

lcd_ac_bias_en.lcd_ac_bias_en */

>;

};

};

&uart0 {


pinctrl-0 = <&uart0_pins>;

status = "okay";

};


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-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>;

};


R_34725_1 Strona 27 z 45

};

};

&i2c2 {


pinctrl-0 = <&i2c2_pins>;

status = "okay";


};

&lcdc {

status = "okay";


pinctrl-0 = <&lcd_pins_default>;

display-timings {

800x480p62 {


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


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;

};


/* VDD_MPU voltage limits 0.95V - 1.26V with +/-4%

tolerance */

regulator-name = "vdd_mpu";



regulator-boot-on;


};


/* VDD_CORE voltage limits 0.95V - 1.1V with +/-4%

tolerance */

regulator-name = "vdd_core";


R_34725_1 Strona 29 z 45



regulator-boot-on;


};

ldo1_reg: regulator@3 {

regulator-name = "vio,vrtc,vdds";


};


regulator-name = "vdd_3v3aux";


};


regulator-name = "vdd_1v8";




};


regulator-name = "vdd_3v3a";


};

};

};

&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>;


R_34725_1 Strona 30 z 45

bus-width = <0x4>;


pinctrl-0 = <&mmc1_pins>;

cd-gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;

};

&mmc2 {

status = "okay";

vmmc-supply = <&vmmcsd_fixed>;

bus-width = <8>;


pinctrl-0 = <&emmc_pins>;

};

&aes {

status = "okay";

};

&sham {

status = "okay";

};

&rtc {

clocks = <&clk_32768_ck>, <&clkdiv32k_ick>;

clock-names = "ext-clk", "int-clk";

};


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; }


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;" …


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


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'


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


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)


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.


R_34725_1 Strona 38 z 45

Rys. 3.6.2 Opracowana płytka bazowa z wpiętym modułem SoM.


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.


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.


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.


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


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”.


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.


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

Sprawozdanie z pracy badawczej finansowanej z dotacji ... · Zlecenie: 110-04910041 Okres...

Documents

Transcript of Sprawozdanie z pracy badawczej finansowanej z dotacji ... · Zlecenie: 110-04910041 Okres...