introduction - osg.informatik.tu-chemnitz.de · synchronisation, at least so, that every...

Christine Jakobs, Martin Richter

Introduction

Embedded Software LabWinter Term 2018/19

Embedded Software Lab (Labor Eingebettete Software) 565040

Operating Systems Group, TU Chemnitz

http://osg.informatik.tu-chemnitz.deEmbLab WS18/19

Embedded Systems

▶ Computer system in a context ▶ Specific dedicated task (vs. all-purpose computer) ▶ Often hardware/software co-design ▶ Optimized design based on application ▶ Often non-visible for user ▶ Often real-time systems

(max. response time ≤ deadline) ▶ High cost pressure - low memory size, simple CPUs ▶ Energy efficiency

▶ Everywhere: Cell phones, printers, automobiles, aviation products, household devices, medical devices, children toys, …

2



Embedded Systems

▶ Ebert and Jones, 2009 ▶ Worldwide market of 160 billion € ▶ ~30 embedded processors per

person in developed countries ▶ 98% of all produced microprocessors

for embedded applications

▶ New emerging trends ▶ Internet of Things (IoT) ▶ Cyber-Physical Systems (CPS)

3



Design of Software for Embedded Systems

▶ Course 565050 ▶ Mandatory precondition for this lab ▶ Gives you the broad overview of embedded software development ▶ Now we dig deeper ....

4

Embedded Software Lab

Non-Functional Properties

(timeliness, reliability, availability, safety, ...)

Hardware

Control Theory

Frameworks / Middleware

Model-Driven Development

Process Control

Code-Driven Development

Winter Term 2018/19


Embedded Software Lab▶ Applied development and analysis of

software for embedded systems ▶ Focus on tools, architectures, fault finding,

and runtime analysis

▶ Qualification goals ▶ Specialized knowledge in embedded

software development ▶ Working close to applications

▶ Still very broad ▶ Complexity issues with industry use cases

5


„Das Praktikum beschäftigt sich mit der angewandten Modellierung, Analyse und Entwicklung eingebetteter Software-Systeme. Dabei werden folgende Teilaspekte behandelt :

• Umgang mit Werkzeugen zur Entwicklung eingebetteter Software (Cross Compiler, grafische Entwicklungsumgebungen, Debugger, Werkzeuge für den Erstellungsprozess)

• Modellierung und Analyse von Algorithmen und Architekturen für eingebettete Systeme

• Fehlerbehebung und Laufzeitanalyse für eingebettete Software Qualifikationsziele: Spezialisierte anwendungsnahe Fähigkeiten zum Entwurf und der Entwicklung eingebetteter Software“

Winter Term 2018/19


RASPNet▶ Serial real-time protocol, for education purposes only

▶ Overall task: Running RASPNet on a microcontroller ▶ Bare metal implementation on 8-Bit ATMega in C ▶ Restricted resources during execution ▶ Restricted tools and capabilities for debugging and testing ▶ Hard real-time constraints ▶ Ultimate goal of interoperability

▶ Development work guided by bi-weekly task sets

▶ Protocol description and add-on sources will be available on-line ▶ Beyond that, you are on your own ...

6


4 The RaspNet-Protocol 11

nodes are able to send their messages.

Mini-slotting is a good way to synchronise access to a shared bus, but it requires exact clock-synchronisation, at least so, that every synchronisation gap is equally long. The SG also couldcome from a central master, which synchronises the system.

Time-synchronisation without a master would be quite hard for the students to implementcorrectly. Using a bus also means, that the pin-modes have to be changed during runtime,which is prone to errors and may be even harmful to the ATMega or Raspberry Pi.

4 The RaspNet-Protocol

This section describes the RaspNet-protocol in detail. The first subsection will portray theprotocol from an architectural point of view, whereas every layer of the RaspNet-protocol-stackwill be outlined by itself. The protocol will then be illustrated in regards to some performance-metrics.

4.1 Architecture

RaspNet contains of several layers of protocols. Frames are send serialized over one wire. Thesecond wire is used as clock-signal. Therefore there are two wires used between two subse-quent nodes in the ring (see Figure 4), which can send up to 260 bytes (255 layer1-payload + 4CRC + 1 size) per frame.

Raspberry Pi

ATMega

Raspberry Pi

ATMega

Raspberry Pi

ATMega

Raspberry Pi

ATMega

Figure 4: Architecture of the logical token ring network with four nodes

The following sections describe the layers of the protocol. The numbering of the layers is ori-ented to the ISO/OSI-model.

4.1.1 Layer 1 - Physical Layer

Whenever the clock-signal changes (from 1 to 0 or from 0 to 1) there is a new bit ready forreading on the data-pin. The data-signal should change in the middle of two clock-changes,so there is a phase shift between data and clock-signal. A HIGH-signal level on the data-pin

11


Hardware▶ 16 boards ▶ RaspberryPi B+

• Standard Rasbian installation

• AVR compiler tool chain

• Used as development environment ▶ Gertboard v2.0

• Extension board

• Buffered I/O

• Pushbuttons

• Open collector drivers

• Motor controller

• 28pin ATMega microcontroller

• D/A, A/D converters

• Target for your implementation efforts

7



Gertboard

8


6

Figure 2: Functional blocks diagram: the key blocks are identified by coloured boundary marking. Please note that

the appearance of some components can vary.

This annotated photo of a populated (fully assembled) Gertboard shows where the functional blocks are located. Some of the blocks have two areas marked. For example, the turquoise lines showing the Atmel ATmega chip not only surround the chip itself and the header pins next to it (on the lower left) but also surround two header pins near the bottom of the board, in the middle. These two pins are connected to the Atmel chip and provide an easy way to interface the GPIO signals from the Raspberry Pi (which are in the black box) with the Atmel chip.

There is no connection (other than power and ground) between the different functional blocks on the Gertboard. The many headers (the rows of pins sticking up from the board) allow you to make these connections, using straps and jumpers. See Figure 11 on page 18 for an example of how these are used to connect the various blocks together.

[Ger

tboa

rd M

anua

l]

Winter Term 2018/19


Microcontroller@Gertboard

▶ Atmel AVR microcontroller ▶ ATmega328/P, 8 bit RISC Harvard, 12 MHz, 3.3V (!) power from the RaspberryPi ▶ 32kByte Flash (code), 1kByte EEPROM (storage), 2kByte SRAM (data) ▶ 2x 8-bit timer, 1x 16-bit timer, support for interrupt on pin change ▶ Same hardware as on the popular Arduino hardware, re-use of development tool chain ▶ Upload of software via SPI bus ▶ Input / output monitoring over serial connection ▶ Check Gertboard manual for further information

▶ Task descriptions contain a wiring plan ▶ Your responsibility to not break the hardware ▶ Beside that, toying around is fine

9


3ATmega48A/PA/88A/PA/168A/PA/328/P [DATASHEET]Atmel-8271J-AVR- ATmega-Datasheet_11/2015

1. Pin Configurations

Figure 1-1. Pinout ATmega48A/PA/88A/PA/168A/PA/328/P

12345678

2423222120191817

(PCINT19/OC2B/INT1) PD3(PCINT20/XCK/T0) PD4

GNDVCCGNDVCC

(PCINT6/XTAL1/TOSC1) PB6(PCINT7/XTAL2/TOSC2) PB7

PC1 (ADC1/PCINT9)PC0 (ADC0/PCINT8)ADC7GNDAREFADC6AVCCPB5 (SCK/PCINT5)

32 31 30 29 28 27 26 25

9 10 11 12 13 14 15 16

(PCI

NT21

/OC0

B/T1

) PD5

(PCI

NT22

/OC0

A/AI

N0) P

D6(P

CINT

23/A

IN1)

PD7

(PCI

NT0/

CLKO

/ICP1

) PB0

(PCI

NT1/

OC1

A) P

B1(P

CINT

2/SS

/OC1

B) P

B2(P

CINT

3/O

C2A/

MO

SI) P

B3(P

CINT

4/M

ISO

) PB4

PD2

(INT0

/PCI

NT18

)PD

1 (T

XD/P

CINT

17)

PD0

(RXD

/PCI

NT16

)PC

6 (R

ESET

/PCI

NT14

)PC

5 (A

DC5/

SCL/

PCIN

T13)

PC4

(ADC

4/SD

A/PC

INT1

2)PC

3 (A

DC3/

PCIN

T11)

PC2

(ADC

2/PC

INT1

0)

32 TQFP Top View

1234567891011121314

2827262524232221201918171615

(PCINT14/RESET) PC6(PCINT16/RXD) PD0(PCINT17/TXD) PD1(PCINT18/INT0) PD2


VCCGND


(PCINT21/OC0B/T1) PD5(PCINT22/OC0A/AIN0) PD6

(PCINT23/AIN1) PD7(PCINT0/CLKO/ICP1) PB0

PC5 (ADC5/SCL/PCINT13)PC4 (ADC4/SDA/PCINT12)PC3 (ADC3/PCINT11)PC2 (ADC2/PCINT10)PC1 (ADC1/PCINT9)PC0 (ADC0/PCINT8)GNDAREFAVCCPB5 (SCK/PCINT5)PB4 (MISO/PCINT4)PB3 (MOSI/OC2A/PCINT3)PB2 (SS/OC1B/PCINT2)PB1 (OC1A/PCINT1)

28 PDIP

12345678

2423222120191817

32 31 30 29 28 27 26 25

9 10 11 12 13 14 15 16

32 MLF Top View


GNDVCCGNDVCC


PC1 (ADC1/PCINT9)PC0 (ADC0/PCINT8)ADC7GNDAREFADC6AVCCPB5 (SCK/PCINT5)

(PCI

NT21

/OC0

B/T1

) PD5

(PCI

NT22

/OC0

A/AI

N0) P

D6(P

CINT

23/A

IN1)

PD7

(PCI

NT0/

CLKO

/ICP1

) PB0

(PCI

NT1/

OC1

A) P

B1(P

CINT

2/SS

/OC1

B) P

B2(P

CINT

3/O

C2A/

MO

SI) P

B3(P

CINT

4/M

ISO

) PB4

PD2

(INT0

/PCI

NT18

)PD

1 (T

XD/P

CINT

17)

PD0

(RXD

/PCI

NT16

)PC

6 (R

ESET

/PCI

NT14

)PC

5 (A

DC5/

SCL/

PCIN

T13)

PC4

(ADC

4/SD

A/PC

INT1

2)PC

3 (A

DC3/

PCIN

T11)

PC2

(ADC

2/PC

INT1

0)

NOTE: Bottom pad should be soldered to ground.

1234567

21201918171615

28 27 26 25 24 23 22

8 9 10 11 12 13 14

28 MLF Top View


VCCGND


(PCINT21/OC0B/T1) PD5

(PCI

NT22

/OC0

A/AI

N0) P

D6(P

CINT

23/A

IN1)

PD7

(PCI

NT0/

CLKO

/ICP1

) PB0

(PCI

NT1/

OC1

A) P

B1(P

CINT

2/SS

/OC1

B) P

B2(P

CINT

3/O

C2A/

MO

SI) P

B3(P

CINT

4/M

ISO

) PB4

PD2

(INT0

/PCI

NT18

)PD

1 (T

XD/P

CINT

17)

PD0

(RXD

/PCI

NT16

)PC

6 (R

ESET

/PCI

NT14

)PC

5 (A

DC5/

SCL/

PCIN

T13)

PC4

(ADC

4/SD

A/PC

INT1

2)PC

3 (A

DC3/

PCIN

T11)

PC2 (ADC2/PCINT10)PC1 (ADC1/PCINT9)PC0 (ADC0/PCINT8)GNDAREFAVCCPB5 (SCK/PCINT5)

NOTE: Bottom pad should be soldered to ground.

Table 1-1. 32UFBGA - Pinout ATmega48A/48PA/88A/88PA/168A/168PA

1 2 3 4 5 6

A PD2 PD1 PC6 PC4 PC2 PC1

B PD3 PD4 PD0 PC5 PC3 PC0

C GND GND ADC7 GND

D VDD VDD AREF ADC6

E PB6 PD6 PB0 PB2 AVDD PB5

F PB7 PD5 PD7 PB1 PB3 PB4

Winter Term 2018/19


Dates▶ Initial lecture: Today (11.10.2018)

▶ Lab 1 (26.10.2018) ▶ Get together ▶ Sub-project 1 starts: Hello ATMega!

▶ Lab 2 (9.11.2018) ▶ Presentation of sub-project 1 ▶ Sub-project 2 starts: RASPNet Layer 1+2

▶ Lab 3 (23.11.2018) ▶ Presentation of sub-project 2 ▶ Sub-project 3 starts: RASPNet Layer 3

▶ Lab 4 (07.12.2018) ▶ Presentation sub-project 3 ▶ Sub-project starts: Organize Project

▶ Lab 5 (21.12.2018) ▶ Presentation of gaps ▶ Sub-project 4 starts:RASPNet Layer 4

▶ Lab 6 (18.1.2019) ▶ Presentation of sub-project 4 ▶ Sub-project 5 starts: PlugFest

▶ Lab 7 (?) ▶ Final presentation

10



Organization▶ Lab slots (33% of the grade) ▶ Each team presents results to a peer team ▶ We (the supervisors) chose your peer team, announced on lab day ▶ We will listen and may participate in the discussion ▶ Your oral performance makes the grade here

(Level of preparation, acting as team, novel ideas, problem analysis strategies, answers to questions)

▶ Grade reduction: Not showing up, missing solutions for a sub-project ▶ No grade reduction: Non-working solution + solid explanation

▶ Beside the official slots, you are expected to spend >100h with the coding work on the hardware

▶ Lab slots are mainly for presentation and discussion ▶ The room (1/B208) is all yours in this semester

11



Organization

▶ Written report (33% of the grade) ▶ Summary of your implementation experience ▶ Condensed version of your oral lab presentations ▶ Explanation of special code parts (complicated algorithm, performance optimization, things

you spend a lot of time with) ▶ No lower / upper page limit ▶ To be submitted shortly after the last lab slot

▶ Code (33% of the grade) ▶ Project code must be managed in a Git repository ▶ References should show up in the report, we will also ask for it during semester ▶ Grading based on code commenting, structuring, consideration

of feedback and completeness (e.g. Makefile)

12



Help?!?

▶ Information exchange during the lab slots and in a discussion forum

▶ Supervisors will not solve your problems ▶ Learn how to debug over serial connections ▶ Learn how to write error-free C code from the very beginning ▶ Learn to live without visual debuggers / development environments

▶ Reliable sources: Data sheets, manufacturer manuals, man pages ▶ Proper citing in the code / final report expected ▶ Post your insights in the discussion forum

▶ Tricky sources: Blogs, code examples, Stack Overflow, forums, cheating

13



Skills▶ Lab work relies heavily on self-motivation

▶ Need for existing capabilities, or willingness to get them very fast ▶ Reasonably good programming skills in C ▶ Basic understanding of how a CPU works, e.g. pipelining ▶ Basic knowledge about (Unix) operating systems, e.g. memory-mapped I/O ▶ Working with source code versioning systems, especially Git

▶ Skills being developed during this course ▶ Reading and understanding detailed documentation of hardware chips ▶ „Survive“ without graphical user interfaces ▶ Debugging code that is out of your control ▶ Low-level I/O programming

14



Daily work▶ Leave no traces on the Raspberry SD cards ▶ Bad students will steal your code ▶ The lab is a shared resource, clean up your mess

▶ Learn to love your Git repository ▶ Create an according private repository on the TU Chemnitz GitLab service ▶ Give Ms. Jakobs and Mr. Richter read-only access ▶ Git command-line tools are available in the Rasbian installation ▶ Make use of tags and branches

▶ Final version of your repository must support Doxygen documentation ▶ Code modules, function signatures, source files ▶ Possible to generate the written report with it, too (Doxygen Markdown support)

15



Doxygen

16



Lab 1▶ Create a first binary, get familiar with the tools ▶ Blinking of Gertboard LEDs ▶ Driven by program running on the ATMega, independent from RaspberryPi operation ▶ Demands wiring between ATMega pins and the Gertboard LEDs ▶ Demands wiring between ATMega pins and the RaspberyPi for serial connection + flashing

▶ Task set 1 becomes official on the first lab slot

▶ Preview available online

▶ But first, you must be allowed to participate in this course ...

17



Course Restriction

▶ Only 14/28 seats ▶ 14 RaspberryPi work stations, with monitor, mouse and keyboard ▶ 1 or 2 persons per team, no change of team partner during semester

▶ Course only works with pre-existing knowledge ▶ Study regulations expect 565050 being passed ▶ Also needed: Skills in operating systems, real-time and low-level software development ▶ There is no time to teach you these basics here

▶ Too many people in the room? Multiple choice test will happen now. ▶ You are intentionally unprepared ▶ Everybody gets according feedback by eMail ▶ If you win, you will be able to open B/208 with your TUC card

18


introduction - osg.informatik.tu-chemnitz.de · synchronisation, at least so, that every...

Documents