Booten

Notwendige Dateien

preloadImage.bin                 // falls doppel-Boot
fpgaSystem.rbf                     // binäre Systemdatei
socfpga.dtb                           // device Tree
U-Boot.scr                            // script bootloader
zImage                                  // Yocto-Ergänzungen

Die Images können z.B. mit Bitbake (yocto) erstellt werden.

Build-System

Für ein eigenes Linux, muss im

Minimum

  • Files-System mit von Hand kompilierten Programmen für das Target

oder im Normalfall für ein

Kleines Linux

  • Bibliotheken (uCLib)
  • Bootlaoder
  • Sytemprogramme (Busybox) oder Kernel
  • Applikationsprogramme

Für das Target kompilieren und dort zum Laufen (Booten) bringen.

Diese Schritte können von Hand, oder mit der Hilfe eine Build-Systems getan werden.

Vorteil Build-System

Bei der Installation wird die korrekte Reihenfolgen durch die Automatisation eingehalten. Abhängigkeiten sind bekannt und das Build-System zeigt Inkompatibilitäten an.

 

Bekannte Build-Systeme

  • Buildroot
  • OpenWRT (basiert auf Buildroot)
  • Yocto

 

Build Programme

  • bitbake (Yocto):
    In Yocto wird für den bootloader (+ preloader), den kernel mit dem dazugehörendem device tree und für das file System ein separates Image gebildet.  Alle Images und Zusatzdateien zusammen führen zu einer grossem Image.bin.

 

 

 

TI Wireless Sensor Board: SensorTag

TI stellte ein Board mit 10 Sensoren und App zur Verfügung, das CC26050STK  Starter Kit.

Sensoren
Umgebungs- und Objekttemperatur, Feuchtigkeit, Druck, Höhe, Bewegung (neun Achsen), Geschwindigkeit, Drehzahl, Magnet und Licht.

Sensordaten auf Cloud
Mit der App können die Daten über die Cloud ausgelesen und weitergeleitet werden.

Entwickler Erweiterung
Zum Sensor Board gibt es eine Erweiterung für Entwickller: das SimpleLink SensorTag DevPack. Die Erweiterung beinhaltet ein JTAG Schnittstelle  und eine IDE zum Debuggen und Programmieren.

Komponenten des Sensor Board
CC26xx_Block_Diagram– zwei Prozessoren:
M3 als CPU und
M0 für RF (BLE )
– JTAG zum Programmieren/Debuggen
– Schnittstellen UART, I2S, SPI
– Sensor Controller
Datenblatt und Beschreibung

 

 


Der RF Chip DA14580

RF_Prozessor_Blockdiagramm– Braucht zum Senden 4.9 mA.
– Braucht im Sleep Mode nur 600nA.
– Betriebsspannung von 0.9 V.
– Hat JTAG Schnittstelle (SWD)
– Hat einen BLE Core mit AES-128
für Single Mode

 

 

 

 

Je nach dem, welches Protokoll man benutzen will, wird ein anderer protocol stack heruntergeladen.

 

Bluetooth Low Energy: Introduction (Ch. 1, 2, 3)

Robin Heydon, Bluetooth Low Energy, The Developer’s HandBook (2013)

Kapitel 1: Was ist BLE?
Das Ziel von BLE ist, die energiearmste wireless Verbindung zu ermöglichen. BLE hat nur wenig mit Bluetooth classic zu tun. Anstelle immer höherer Datenraten, ist hier die kleinst notwendige Datenrate gefragt (R = 0.3 Mbps). f = 2.4 GHz
Bluetooth ab Version 4  kennt den Dual-Mode, in dem sowohl BLE wie auch Bluetooth benutz werden können.
Glossar: FrequenzHopping

Kapitel 2: Basic Concepts
– Gespiesen wird mit der kleinstmöglichen Battterie (Knopfbatterie), die 3 V /230 mAh. Spitzenstrom von 15 mA. Die Batterie hält länger, wenn keine Leistungen an ihrem Limit bezogen werden.

– Zeit = Energieverlust: Jede Abfrage ist auf das Minimum beschränkt. Sich wiederholende Abfragen (ID senden) sind zu minimieren. Jede Abfrage muss dafür so sicher wie möglich sein, denn für Wiederholung wäre eine Energieverschwendung. Aus diesem Grund sind nur 3 der 16 Frequenzen bei der Datenübermittlung parallel aktiv (1 oder 2 sind zu wenig sicher).

– Speichern der Daten = Energieverlust: Speicher sind Stromfresser.

Asynchrones Kommunikationskonzept: Es wird klar unterschieden zwischen der Energiefähigkeit unter den Geräten. Das energiearme Gerät behandelt auf allen OSI-Layern nur das Minimum. Die Arbeit übernimmt das Energiestärkere Gerät.
Physical Layer: Theoretisch kann ein Gerät Senden und Empfangen. Doch um zu Sparen, tätigen im asynchronen Konzept die energiearmen Geräte nur 1 Sache und nur 1 Gerät erledigt alle energiefordernden Prozesse.
Link Layer: Die Aufgaben advertize (Packete senden), scannen (Packete erhalten) in den Rollen master, slave (nur Instruktionen erhalten) werden strikt zugewiesen. Der master übernimmt das timing, wählt die Frequenzen, entschlüsselt die Daten und weitere komplexe Aufgaben.
Protocol Layer: Aufgeteilt in Server – Client. Der Client generiert die Daten und teilt dies per Request dem Server mit. Der Server macht,  ähnlich wie der Slave auf dem Link Layer, macht nur, was man ihm sagt. Der Client macht die Arbeit.

Zustandsgesteuert:  Jede Inhalt setzt einen Zustand im Attribut Protocol. Die aktuelle Temperatur, der Ladungszustand der Batterie,  der Name des Geräts oder die Beschreibung, wo die Temperatur erfasst wurde: alles wird einem Zustand zugewiesen. Der Vorteil davon ist, dass Slave sich zu jedem gewünschten Zeitpunkt ausklicken können.

Kapitel 3: Aufbau
Der Kontroller, der Host, der Applikations Layer und der Stack werden im Überblick vorgestellt und jedes dieser Komponten erhält nachher ein eigenes Kapitel.

BLE_architecture
– Der Kontroller:
Physical Layer: f = 2.4 GHz, Modulation: GFSK (Gaussian Frequenz Shift Keying = die Frequenzen werden gewechselt. Gauss wird als Filter gebraucht, da der Frequenzwechsel Störpulse generiert). Direct Test Mode: Direkter Paketversand zum Testen des Physical Layers. Link Layer: Tätigt fast alle Aufgaben: advertizing (Packete anbieten), scanning (Packete abholen), Auf- und Abbau sowie die Unterhaltung einer Verbingung. Packete richtig aufbauen.
Kommuniziert wird auf 3 advertizig channels: Wer ist da? Wer hat Daten? Eine Verbindung wird aufgebaut. Neben den 3 advertizing channels gibt es 37 data channels.  Auf einem davon werden die Daten gesendet (mit einem ACK).
Ein Standard-Packet ist minimum10 Bytes lang, das längste 47 Bytes.BLE_packet_structure

The Host/ControllerInterface (HCI): Stellt sicher, dass das BLE Gerät mit einem Host kommunizieren kann. Der Host sendet Befehlte, das BLE sendet vorwiegend Daten. Der HCI hat zwei getrennte Bereiche: einer beinhaltet die Anbindung zum Physical Layer und der andere die Anbindung zum Logica Link.
In der Andbingung zum Physical Layer ist die Kommunikationsart definiert. Erlaubt ist USB, SDIO und UART.

..

WLAN-Chip für hohen Datendurchsatz

Texas Instruments hat mehhrere Wireless Module, die sich direkt an einen ARM Prozessor anbinden lassen. Hier wird einer der mehreren wireless Chips erklärt, der für höchstleistungen gedacht ist (Datenblatt  WL1835)
und deshalb oft angeboten wird mit starken Cortex Prozessoren

WLAN Chip WL1835
TI verkauft Beagle Bones (ARM Cortex A8 Prozessor Boards), mit denen sich dieser Chip über ein Zusatz-Cap mit Beagle Bone Prozessor per Stecker verbinden lässt. Eine Alternative sind die TI SimpleLink Module. Diese basieren auf einem ARM Cortes M3.

Sende Fähigkeiten
Nr. 35 sendet WLAN auf  2.4 GHz und Bluetooth  (Projekt Brüt.)
Nr. 37 auf auf 5 GHz, 2.4 GHz und Bluetooth  (Projekt Brüt. 2)
Nr. 31 hat nur Bluetooth v4:  Mit Dual-Mode Bluetooth Low Energy

Der Chip ist explizit stromsparend ausgelegt und kann für low power-Anwendungen gebraucht werden.

Prozessor AM335x
Ist ein Coretex A8 mit Schwerpunkt auf der Ethernet-Kommunkation.
Nordic bindet sein RF-Chip an einen ARM Mx-Prozessor. Die Instruktionen sind dann etwas anders.

 

Bootloader

Notwendige Dateien zum Booten

  • BSP (Board Support Packet)
  • Buildsystem

Das BSP wird oft vom Hersteller mitgelierfert (oder kann bei FPGAs über Quartus generiert werden.) Wesentliche Dateien im BSP sind der Device Tree, der die Grundeinstellungen der Komponenten beschreibt.

Das Buildsystem fügt die Komponenten

  • BSP
  • Treiber
  • Bibliotheken
  • Software (Kernel und Applikationen)
     

     

zusammen zu einem Image, und definiert  das File System. Zum Buildsystem gehört die Definition des Bootloader, der den ganzen Prozess ausführt.

Aufgabe des Bootloaders
Es ist der Bootloader, der den Startvorgang kennt. Er lädt die Dateien  (als Image) aus einem festen Speicher in das static RAM.

Mit dem Befehlt mkimage -h  kann der Inhalt des u-boot images angesehen werden.

Starten des bootens  boot.script
Das Build-System (z.B. Yocto) erzeugt über ein Build-Programm (z.B.  u-boot) ein boot.script. Das Script liegt an einem nicht flüchtigen Speicher. Beim Booten weiss das System, wo das Skript liegt und startet den Prozess automatisch.

Datenarten
Konzeptionell unterscheidet man zwischen zwei Dateitypen:
– Das Betriebsystem (Image, DeviceTree)
– Die Applikationssoftware

Gestaffeltes Booten
Booten heisst, unter anderem die Startadresse aller Vektoren für die Interrupts setzen.
Detaillierte technische Beschreibung zum Booten in http://stackoverflow.com/questions/31244862/what-is-the-use-of-spl-secondary-program-loader

Primary boot (Programm U-boot)
Der primary boot lädt die notwendigen Betriebsdateien ins RAM.

Secondary Programm loader (SPL)
Wird gebraucht, wenn das RAM nicht das ganze Image speichern kann und ein Teil des Boots, in ein externer Speicher abgelegt wird.

Firmware

Firmware
Bezeichnet spezifische Software für ein Bauteil oder ein System. Da dies Software abgelegt werden muss, braucht das Bauteil einen Speicher (z. B Flash oder SD-Karte) , in dem die Firmware liegt.
Die Firmware ist sehr hardwarenahe bzw. direkt mit ihr verbunden. Firmware kann auch „nur“ der Konfiguration des Gerätes dienen.

Firmware Komponenten

– Alle Bauteile, die angeschlossen werden bzw. deren Software
– Das OS
– Der Bootloader

SD Karten

Als externer Speicherplatz kann eine SD (Secure Digital Memory) Karte genommen werden. Es gibt die Mini- und Micro-Ausführung.

Spezialitäten
– Ihr Speicherprinzip ist die Flash-Speicherung.
– Speicherbereich kann partitioniert werden:
In einem Teil liegt ein System-Image, im anderen Teil das File Sytem
– besitzt einen internen Controller
– 9 Kommunikationspins
– SD-Karten mit integriertem WLAN oder GPS
– SD-Karte mit USB-Stecker Typ A (normaler Stecker) zum Anschliessen

In Enbedded Systemen
Das Betriebssystem und die Applikatins Software wird meist in Flash Speichern abgelegt und von dort gebootet. Man kann aber auch eine genug grosse SD-Karte zum Booten des Systems nehmen.

Kommunikation
Die Kommunikation basiert auf dem SPI-Prinzip.
SD_Pins– Initialisierungssequenz:
Schützt vor unberechtigtem Zugriff auf die Daten
– Pin 1: Kartenerkennung (Dateinleitung 3)
– Pin 2: Kommandos (Befehl/Antwort)
– Pin 3/6: GND
– Pin 4: VCC
– Pin 5: CLK
– Pin 7/8/9: Data (Datenleitung 0, 1, 2)