Explore
For Enterprise
Join for Free
Log In

Гуманитарные науки и искусства
Бизнес
Компьютерные науки
Наука о данных
Информационные технологии
здоровье
Математика и логика
Личное развитие
Естественные и технические науки
Социальные науки
Изучение языков
Степени
Сертификаты

Полный обзор Coursera

Обзор
Поиск
Для организаций
Войти
Присоединиться бесплатно

5. Memory Alignment

Loading...

Embedded Software and Hardware Architecture

Колорадский университет в Боулдере

4.5 (оценок: 54) | Зарегистрировано учащихся: 4.4K

Embedded Software and Hardware Architecture is a first dive into understanding embedded architectures and writing software to manipulate this hardware. You will gain experience writing low-level firmware to directly interface hardware with highly efficient, readable and portable design practices. We will now transition from the Host Linux Machine where we built and ran code in a simulated environment to an Integrated Development Environment where you will build and install code directly on your ARM Cortex-M4 Microcontroller. Course assignments include writing firmware to interact and configure both the underlying ARM architecture and the MSP432 microcontroller platform. The course concludes with a project where you will develop a circular buffer data structure. In this course you will need the Texas Instruments LaunchPad with the MSP432 microcontroller in order to complete the assignments. Later courses of the Specialization will continue to use this hardware tool to develop even more exciting firmware.

Просмотреть программу курса

Рецензии

4.5 (оценок: 54)

5 stars
37 ratings
4 stars
12 ratings
3 stars
3 ratings
1 star
2 ratings

AP

Jun 29, 2019

All the videos are very helpful. All concepts are taught well. More hands on assignments could be added to course.

KR

Aug 08, 2019

Excellent Course by Alex. The slides and the material is top notch. Looking forward to the other courses.

Из урока

Interfacing C-Programs with ARM Core Microcontrollers

Module 1 will introduce the learner to how software/firmware can interface with an embedded platform and the underlying processor architecture. Embedded Software engineers must be very knowledgeable about the architecture in order to write efficient and bug free code. This requires knowledge of processor architecture. memory systems, microcontroller peripherals and more advanced use of the compiler. This module will continue to enforce good software design techniques with a focus on portability and maintainability without reducing your hardware’s performance.

1. Architecture-Software Interface5:49

2. Word Size and Data Types8:42

3. Pointers8:01

4. Interacting with Memory8:32

5. Memory Alignment6:51

6. Endianness5:54

7. Compiler Attributes6:58

8. Memory Map and Registers9:54

9. Register Definition Files8:33

Преподаватели

Alex Fosdick
Instructor

Текст видео

In this video, we will discuss how data is oriented in our code and data memory.

Micro controllers have complex memory architectures.

There are variety of memories being interconnected with the CPU.

This include Register memory, peripheral memory, code and data memory.

External core memory interfaces to the micro controller

through a number of different Busses.

This is important because a load store architecture requires that we do

all of the processing in the CPU,

after we have loaded data into the local general purpose registers.

Once processed, we can then rewrite that data back to memory.

The process to reading or

writing a piece of data is not as simple as calling a load or a store.

There's some specific orientation and alignment requirements for

memory that need to be taken into account for

our programs to work correctly Memory is oriented in a Byte addressable model.

We have a 32 bit address space,

which means we have over 4 billion unique addresses.

Since each address represents a Byte, we have 4 gigabytes of address space.

However, much of the data operations that we perform on a micro controller

use more than one Byte.

We often perform math with half words, words, floats, or doubles,

a range of one to eight Bytes of data manipulation.

This only becomes more complicated when we begin to define data structures.

A data structure can contain any number of variables, each with different sizes.

These can be integer types, floating point types, pointers, or even other structures.

Structures are a high level software construct that is architecture

independent, but

they can be organized more efficiently by knowing how data is oriented in memory.

The underlying instructions set architecture gives us three types of

Load/Store instructions.

These include byte, half-word and word length load stores.

There are no instructions for bit manipulation or

larger than word manipulation.

Bit manipulation must be done with larger data types being loaded and stored or

using bit banded memory regions.

For larger data types we actually need to perform multiple loads to get the data

into the CPU registers for processing.

This means that if you tend the write programs with types that are bigger than

the architecture word size, you're spending more CPU cycles performing

loads in stores and additional processing on larger data types.

This adds extra overhead to your data processing.

What makes these loads and

stores even more complicated is that they are designed to work on specific address

alignments, meaning bytes, half-words and words are required to be

oriented at certain address offsets depending on their data size.

Alignment will have effects on both CPU efficiency and your memory efficiency.

Aligned accesses make reading and writing to memory as efficient as possible, but

they may potentially waste memory space.

Unused memory is used to pad memory spots until the data type can be aligned.

These bytes are refered to as padding.

Unaligned memory will force the CPU to do more work to access data,

but it will more efficiently pack your data into memory.

This is referred to as packing data.

For instance, bytes can be stored at any address without issue.

Any address in memory space is byte addressable and

therefore byte accesses are always aligned.

There are exceptions for unused memory locations or the bit banded regions.

However, half-words, words, and double words require certain address alignment.

Half-words, must be stored at a two byte boundary.

Meaning, half-words can only be stored when aligned to an even address.

This will include all the addresses that end with hex, zero, two,

four, six, eight, a, c, and e.

Half-words at a maximum will waste one padded byte for them to be aligned.

Words need to be aligned at four byte boundaries.

These are addresses that can end in hex, zero, four, eight, or c.

These can pad a maximum of three bytes.

You can extend this to larger types like doubles.

Double words must be aligned to an eight byte boundary, or

addresses that end with zero or eight.

Word alignment is the most efficient for a programmer, as it will reduce the amount

of manipulation a CPU must perform on the data once it's inside the CPU.

Further, CPU instructions for our arm architecture can vary in size,

from two to four bytes.

These are forced to be aligned at least a half-ward boundary, and

cannot support unaligned accesses.

If your application is looking to be optimized for

speed, you'll want to make sure all your memory interactions are aligned.

If you're looking to optimize for

space, you'll want to try and pack all of your data.

Unfortunately, you may have an architecture that does not support

unaligned accesses.

Meaning your load and store word instruction cannot be given any address.

In such a case, multiple loads and extra processing will need to be done to read or

write an unaligned access.

Multiple stores will have to be done for an unaligned access as well.

An example would be unaligned word that is aligned on a half-word boundary.

In order to operate on this you would have to do two half-word loads.

One for the upper half-word and one for the lower half-word.

These loads would go into two separate registers.

You would then have to shift the upper word two bytes up and

combine it with a lower half-word register.

This would require about four extra operations to interact with an unaligned

memory access just to get into the registers for processing.

This would be a lot of processing overhead compared to a single load instruction.

Let us look at another example.

Here we have a very simple data structure declared with three internal members.

An 8-bit var1, a 32-bit var2, and an 8-bit var3.

Now, depending on how you declare the structure and

the architecture you're using, it can get allocated many different ways.

If this structure was aligned and

using fast standard data types, it could potentially take up the 12 bytes.

This could take a minimum of six bytes if we force the structure to be packed.

In order to specify packing or padding of a data item,

we can apply a compiler attribute to variable or structure.

Unfortunately, these attributes are not portable across compilers.

But we will cover these in more detail later in the course.

Alignment is an important concept with how we organize the data in memory.

This applies to both code and data memory.

An architecture is designed to interface with memory certain ways based on

the instruction set, while an engineer might think they are writing code that is

space efficient, they may have some performance issues.

Knowing the implications of how you store data in memory can help you optimize and

avoid potential bugs.

Ознакомьтесь с нашим каталогом

Присоединяйтесь бесплатно и получайте персонализированные рекомендации, обновления и предложения.

Coursera делает лучшее в мире образование доступным каждому, предлагая онлайн-курсы от ведущих университетов и организаций.

© Coursera Inc., 2019 Все права защищены.

Загрузить из App Store

Загрузить в Google Play

Coursera
О проекте
Руководство
Карьера
Каталог
Сертификаты
Сертификаты MasterTrack™
Степени
Для организаций
Для правительственных организаций

Сообщество
Learners
Partners
Developers
Beta Testers
Translators

На связи
Блог
Facebook
LinkedIn
Twitter
Instagram
YouTube
Технический блог

Еще
Условия
Конфиденциальность
Помощь
Доступность
Пресса
Контакты
Справочник
Филиалы