0% found this document useful (0 votes)
13 views46 pages

CMPE 246 Lecture 7 - (Jan.28)

The document outlines the course details for CMPE 246, Computer Engineering Design Studio, taught by Dr. Ling Bai at UBC Okanagan. It covers topics such as hardware verification, embedded testing, debugging techniques, and the use of GitHub for project management. The instructor provides contact information and office hours for student consultations.

Uploaded by

siamibne1512
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
13 views46 pages

CMPE 246 Lecture 7 - (Jan.28)

The document outlines the course details for CMPE 246, Computer Engineering Design Studio, taught by Dr. Ling Bai at UBC Okanagan. It covers topics such as hardware verification, embedded testing, debugging techniques, and the use of GitHub for project management. The instructor provides contact information and office hours for student consultations.

Uploaded by

siamibne1512
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 46

CMPE 246 (3) Computer Engineering

Design Studio
Dr. Ling Bai
ling.bai@ubc.ca
IEEE Member, ACM Member
Faculty of Applied Science | School of Engineering
The University of British Columbia, Okanagan Campus
1137 Alumni Avenue, Kelowna BC, V1V 1V7 Canada
Instructor Name: Ling Bai

Instructor Contact Information: ling.bai@ubc.ca

Office Hours: By appointment


Please click on the link to book a 15-minutes
appointment during office hours ( EME 3280,
Friday, 2:30pm-4:30pm). You may book multiple
time slots if needed. If none of the available times
work for you, please feel free to email me.
ling.bai@ubc.ca
Appointment booking link:
https://lingbai.youcanbook.me

2
Lecture 4

3
1- Start

4
1- Start In the Online Interactive Review Pages!

HD

HD

5
1- Start
In the Online Interactive Review Pages!

compiled languages VS interpreted(scripting) languages


C/C++/Python/Assembly Languages

6
1- Start

7
2- Hardware Verification
Embedded Testing is soft- and hardware verification and validation
(V&V) to ensure the entire system is defect-free.

• Verification: Ensuring that the system meets its specified design


requirements.

• Validation: Ensuring that the system meets the needs and requirements
of its intended users and the intended use environment.

8
2- Hardware Verification
Embedded Testing is soft- and hardware verification and validation
(V&V) to ensure the entire system is defect-free.
• Verification: Am I building the system right?
• Validation: Am I building the right system?

9
2- Hardware Verification
Embedded Testing is soft- and hardware verification and validation
(V&V) to ensure the entire system is defect-free.

• Verification is an iterative process that occurs during the middle of the


design phase. It focuses on ensuring that the product is being built
according to the specified requirements.

• On the other hand, validation is the final step, aimed at confirming that
the finished product meets the user's needs and expectations.
10
2- Hardware Verification
Embedded Testing is soft- and hardware verification and validation to
ensure the entire system is defect-free.

Two common types:

• Unit testing
• Integration testing

System testing(optional)
11
2- Hardware Verification

12
2- Hardware Verification
V-model of design flows

13
2- Hardware Verification
V-model of design flows

Individual modules are


tested to ensure they
function correctly.

14
2- Hardware Verification
V-model of design flows

Modules are integrated


and tested as a group
to identify any interface
defects.

15
2- Hardware Verification
Acceptance testing: System is tested in the real-world environment to ensure it meets
user requirements. (Beta testing)

16
2- Hardware Verification
Embedded Testing is soft- and hardware verification and validation to
ensure the entire system is defect-free.

Two common methods:

• Black Box Testing


• White Box Testing

Grey Box Testing (Optional)


17
2- Hardware Verification

Black box testing involves testing a system with no prior knowledge of its
internal workings. (Functionality testing)

18
2- Hardware Verification
White box testing analyze the internal structures the used data structures,
internal design, code structure.

19
2- Hardware Verification
Test-driven development is an agile development method where test
units are written before the code.

Agile development methodologies are project management techniques that


involve breaking down projects into smaller, manageable tasks, called
sprints.

Agile project management (APM) is an incremental, iterative approach to


delivering a project throughout its life cycle.
20
2- Hardware Verification
An agile sprint is like a short race.
A sprint is a short, time boxed period.

21
2- Hardware Verification
In many cases where there is no need for powerful embedded OSes, the
firmware is developed using bare-metal approach or with small RTOSes.
Embedded systems contain firmware.
Firmware is program that provides basic machine instructions that allow the
hardware to function and communicate with other software running on a device.

embedded into hardware


provide low-level control
Firmware is often referred to generically as a BIOS(Basic Input/Output System)
Reading: https://www.techtarget.com/whatis/definition/firmware 22
https://www.rinf.tech/bare-metal-firmware-development-what-when-and-how/
2- Hardware Verification
In many cases where there is no need for powerful embedded OSes, the
firmware is developed using bare-metal approach or with small RTOSes.

Bare Metal: By bypassing the layers of operating systems, it allows


developers to interact directly with the hardware.

Reading, For your interest: 23


https://www.instructables.com/Bare-Metal-Raspberry-Pi-3Blinking-LED/
2- Hardware Verification
Device Driver?

24
2- Hardware Verification

Reading:
https://www.intel.com/content/www/us/en/docs/programmable/683211/current/bare-
metal-user-guide.html

25
3- Flashing and Debugging
In most cases the chip is programmed while it is already soldered onto the board, called In-
System-Programming (ISP).

26
Soldering pins with iron tool
3- Flashing and Debugging

27
3- Flashing and Debugging
In most cases the chip is programmed while it is already soldered onto the board, called In-
System-Programming (ISP).

Initial version of the firmware can be programmed already to the microprocessor/microcontroller


by its manufacturer before soldering it to the board.

There are basically two ways to upgrade the firmware.


• Using a programmer and a dedicated hardware interface (JTAG/SWD) on the board.

• Via a bootloader using communication interfaces (UART) that are used for other
purposes during normal operation of the device.

Bootloarder is a program that is responsible for booting device.


28
Joint Test Action Group (JTAG) Serial Wire Debug (SWD) Universal Asynchronous Receiver-Transmitter (UART)
3- Flashing and Debugging

ESP32 is a series of low-cost, low-power system-on-


https://blog.wokwi.com/gdb-debugging-esp32-using-raspberry-pi/ chip microcontrollers with integrated Wi-Fi and dual- 29
https://pinout.xyz/pinout/uart mode Bluetooth.
3- Flashing and Debugging
• The process of changing the firmware is called Flashing.
• Common reasons for flashing a device:
- fixing bugs
- adding features to the device
- use an free software instead of the stock firmware.

The firmware that comes installed in the device when you buy it is called stock
firmware.

Firmware is held in non-volatile memory devices such as ROM.


30
3- Flashing and Debugging
You need to print some text on your blank book.

31
3- Flashing and Debugging
An editor revising a written document to correct errors.

32
3- Flashing and Debugging

Debugging is a series of techniques and processes used for identifying,


tracking, and correcting errors or issues.

In embedded system development, debugging can be particularly complex


because it involves not only software but also hardware.

33
3- Flashing and Debugging
In order to find bugs, you can use the same serial interface/communication interface
and print debug messages to it. (JTAG/SWD/UART)
• monitor debugger
a piece of software that was programmed in
the memory of the embedded system and
reacted to requests of a debugger software
from outside.
• in-circuit emulator
a (large) piece of hardware that replaced and
emulated the processor located in the target
hardware by adaptation.

https://www.embedded.com/debugging-stories-from-printf-just-flash-and-beyond/
34
https://runtimerec.com/firmware-debugging-techniques-using-jtag-and-serial-interfaces/
https://medium.com/@lanceharvieruntime/using-debugging-interfaces-uart-jtag-and-swd-demystified-3f33b8f0513e
3- Flashing and Debugging
GNU Compiler Collection (GCC): a compiler suite that supports many
languages, such as C/C++ and Objective-C/C++.

GDB Debugger is the GNU Project's debugger, a powerful tool used primarily
for debugging programs written in C, C++, and other languages.

35
3- Flashing and Debugging
Features of GDB
• Breakpoints: Set breakpoints to pause program execution at specific points
to examine the current state.
• Step Execution: Execute programs step by step, monitoring the changes in
program states.
• Variable Inspection: Check variables and memory states.
• Stack Inspection: View the call stack to trace the path of execution.
• Thread Debugging: Manage and debug threads.

36
3- Flashing and Debugging

Breakpoint

37
3- Flashing and Debugging

Step Execution:
• step into: enter into the
function
This will take you inside the
add function, allowing you to
see what happens at the
line 5
Breakpoint

38
3- Flashing and Debugging

Step Execution:
• step over: skip over
function calls
This will execute the add
function without entering it,
and the debugger will stop
after it has finished, at the next
line 17
Breakpoint

39
3- Flashing and Debugging
Step Execution:
• continue
If you want the program to continue
running until the next breakpoint
If there are no other breakpoints
after the functions, Continue will
allow the program to run to
completion and exit.

Breakpoint

40
4- To Supplement
makefile
If you want to run or update a task
when certain files are updated, the
make utility can come in handy.

41
4- To Supplement
bash
your shell script

42
In Advance
• Please activate your UBC GitHub account. You can do this by visiting the
UBC GitHub Service page https://activate.github.ubc.ca/ and using your
UBC CWL to activate your account.
• After your account has been activated, log in to UBC GitHub
https://github.ubc.ca/ with your UBC CWL. This will complete the setup of
your account.

Organizations on GitHub are group accounts where members can collaborate on projects together.
We will use GitHub to manage the advanced project repository and conduct some evaluations through
Insight. When the course ends, you can make your project public by registering and opening your
43
personal GitHub account at github.com.
In Advance
Blinky Led
https://www.jeffgeerling.com/blogs/jeff-geerling/controlling-pwr-act-leds-raspberry-pi

Raspberry pi 4:
https://youtu.be/CL39xCXdU64
https://youtu.be/jO994kxodPU
https://roboticsbackend.com/raspberry-pi-control-led-python-3/

Raspberry pi 3: https://youtu.be/w_z0BUkzbIg

On Canvas

44
In Advance

45
Dr. Ling Bai
(email: ling.bai@ubc.ca)

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy