removed most of warnings in first semester
This commit is contained in:
parent
c798bb1d70
commit
826b38e6a7
|
|
@ -156,7 +156,7 @@
|
|||
Исходя из данных полученных в ходе выполнения задачи, можно сделать вывод, что время выполнения алгоритмов, основанных на ленточном разбиении матрицы ниже чем у алгоритмов, основанных на блочном разбиении.
|
||||
|
||||
\subsection{Работа с графами}
|
||||
В соответствии с вариантом, при выполнении задания по работе с графами, использовались параметры настройки программы \code{ParaLab} представленные в таблице \hyperref[table:multiplytask]{\ref{table:multiplytask}}.
|
||||
В соответствии с вариантом, при выполнении задания по работе с графами, использовались параметры настройки программы \code{ParaLab} представленные в таблице \hyperref[table:multiplytask]{\ref{table:paralab-settings}}.
|
||||
|
||||
\begin{table}[H]
|
||||
\centering
|
||||
|
|
@ -170,7 +170,7 @@
|
|||
\hline
|
||||
\end{tabular}
|
||||
\caption{Параметры настройки программы \code{ParaLab} для работы с графами}
|
||||
\label{table:multiplytask}
|
||||
\label{table:paralab-settings}
|
||||
\end{table}
|
||||
|
||||
Настройка программы \code{ParaLab} для данного задания приводит к ошибке, связанной с тем, что ни один из алгоритмов обработки графов не может быть реализован на топологии типа \textbf{Гиперкуб}. Сообщение об ошибке представлено на рисунке \hyperref[pic:grapherror]{\ref{pic:grapherror}}. Исходя из сообщения об ошибки, топология была изменена на \textbf{Полный Граф}.
|
||||
|
|
@ -243,14 +243,14 @@
|
|||
\hline
|
||||
\end{tabular}
|
||||
\caption{Результаты обработки графа алгоритмлм Дейкстры}
|
||||
\label{table:prim}
|
||||
\label{table:deikstra}
|
||||
\end{table}
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[height=4cm]{01-dis-rpt-pldeix1.png}
|
||||
\caption{Зависимость времени обработки графа от количества процессоров}
|
||||
\label{pic:primgraph}
|
||||
\label{pic:deikstragraph}
|
||||
\end{figure}
|
||||
|
||||
\section{Контрольные вопросы}
|
||||
|
|
|
|||
|
|
@ -7,6 +7,8 @@
|
|||
\title{Проектирование программного обеспечения встраиваемых (встроенных) систем}
|
||||
\date{2021-09-07}
|
||||
|
||||
\def\makeyear{2021}
|
||||
|
||||
\begin{document}
|
||||
\maketitle
|
||||
\newpage
|
||||
|
|
@ -74,8 +76,7 @@
|
|||
Часто взять готовое аппаратное решение дороже в разработке, но дешевле в изготовлении, например:
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\def\svgwidth{90mm}
|
||||
\includesvg{pics/01-ess-00-economics.svg}
|
||||
\includesvg[scale=.59]{pics/01-ess-00-economics.svg}
|
||||
\caption{Отношение затрат на разработку и тиражирование к объёму выпуска }
|
||||
\label{pic:economics}
|
||||
\end{figure}
|
||||
|
|
@ -146,7 +147,7 @@
|
|||
\item скалярные, суперскалярные
|
||||
\begin{itemize}
|
||||
\item скалярные - выполняет в один момент времени только одну команду, в современных используется конвейеризация, то есть команда будет выполняться за 3-5 стадий. На рисунке ниже показано, что блок С1 обрабатывает команду 1, вызывая её из памяти, на втором такте С2 декодирует команду, а С1 уже берёт следующую, на третьем такте С3 вызывает операнды первой команды, на четвёртом С4 выполняет команду 1, а на пятом такте С5 записывает результат выполнения команды, в это время блоки С1, С2 продолжают выборку и декодирование следующих команд
|
||||
\begin{figure}[h]
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=12cm]{01-ess-00-conv.png}
|
||||
\caption{Принцип работы конвейеризации в процессорах}
|
||||
|
|
@ -267,18 +268,18 @@ store.w R5, @R4 // 1сл, 2т
|
|||
\item без операционной системы нет способа передачи информации между задачами. Нужно придумывать собственные механики вроде общих переменных итд. Чем сложнее система - тем сложнее велосипеды передачи сведений.
|
||||
\end{itemize}
|
||||
Обычно есть обработчики прерываний от периферии, но отдельно можно выделить прерывания от аппаратного таймера. То есть можем сделать прерывания по синхронным событиям, раз-в-сколько-то-сек.
|
||||
\begin{figure}[h]
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\input{pics/01-ess-00-longinterrupt}
|
||||
\caption{Проблема длинного обработчика прерываний}
|
||||
\label{pic:longinterrupt}
|
||||
\end{figure}
|
||||
Когда мы дробим обработчик таймера на несколько фаз мы решаем проблему, показанную на рисунке (пропущенные обработчики прерываний от serial). Поэтому важно понимать карту времени, и стараться не блокировать микроконтроллер надолго. с уровнем задач обычно проблем нет, а с другими прерываниями вполне могут быть. Также важно не забывать про пролог и эпилог прерывания (установка контекста, и так далее). Поэтому всегда предпочтительно - короткие прерывания
|
||||
\begin{figure}[h]
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\input{pics/01-ess-00-shortinterrupt}
|
||||
\caption{Проблема длинного обработчика прерываний}
|
||||
\label{pic:longinterrupt}
|
||||
\label{pic:shortinterrupt}
|
||||
\end{figure}
|
||||
Надо заметить, что время выполнения цикла не постоянно, О(цикла) это выполнение каждой задачи, $\Omega(\text{цикла})$, когда пустые обработчики - считанные такты и инструкции. Использовать \code{volatile} для переменных разных задач - плохой стиль. То есть если например, включить оптимизации компилятора и объявить переменные для условий внутри вайлтру нулями и не сделать \code{volatile} - компилятор решит, что это недостижимый код и его можно убрать. Так оптимизатор скомпилирует нам пустой вайлтру. То есть аппаратные прерывания компилятором не особо учитываются. volatile не оптимизируется компилятором никогда, потому что это всегда явное обращение к памяти или регистрам ввода-вывода.
|
||||
Резюме:
|
||||
|
|
@ -325,14 +326,12 @@ store.w R5, @R4 // 1сл, 2т
|
|||
\item с уровнем приложения
|
||||
\item с аппаратурой (по опросу, по прерыванию, с использованием ПДП (прямого доступа к памяти)).
|
||||
|
||||
\def\svgwidth{40mm}
|
||||
\includesvg[scale=1.01]{pics/01-ess-00-burstwrite.svg}
|
||||
|
||||
По опросу обычно делают короткие события не требующие быстрой реакции, вроде проверки ножки, изменения направления ветра или для приёма бёрстов данных.
|
||||
|
||||
ПДП не осуществляет анализ данных по приёму, поэтому не факт что хорошая идея так принимать ethernet пакеты.
|
||||
|
||||
\def\svgwidth{50mm}
|
||||
\includesvg[scale=1.01]{pics/01-ess-00-burstanswer.svg}
|
||||
|
||||
Если есть кэш и план по использованию прямого доступа к памяти - нельзя забывать о кэше. При использовании ПДП мы работаем как будто напрямую с подсистемой ПДП, но фактически работаем с кэшем, поэтому обязательно когда мы собрались записать данные - нужно выполнять cache flush.
|
||||
|
|
@ -341,7 +340,7 @@ store.w R5, @R4 // 1сл, 2т
|
|||
cache_flush(a, sizeof(a));
|
||||
start_data_tx(a, sizeof(a));
|
||||
\end{lstlisting}
|
||||
\def\svgwidth{50mm}
|
||||
|
||||
\includesvg[scale=1.01]{pics/01-ess-00-cacheflush.svg}
|
||||
|
||||
второй случай - подсистема прямого доступа к памяти данные модифицировала, а для процессора они остались старые, потому что кэш обычно надо сделать cache invalidate
|
||||
|
|
@ -515,7 +514,7 @@ OSTaskCreateExt();
|
|||
|
||||
Приоритеты задач (вытесняющая диспетчеризация) высший - меньшая цифра. Если задача высшего приоритета не уходит в сон - менее приоритетные никогда не выполнятся. Если в обработчике вызываются функции ОС, обязательно нужно написать \code{OSIntEnter();} и \code{OSIntExit();}
|
||||
|
||||
\subsection{Состояния задач в $\mu$C/OSII}
|
||||
\subsection{Состояния задач в uC/OSII}
|
||||
\includegraphics[width=15cm]{01-ess-01-tasks.png}
|
||||
|
||||
Основные переходы всегда между \textbf{ready} \textbf{running} и \textbf{waiting}. При возникновении прерывания текущую задачу переводим в состояние \textbf{ISR} но при этом при возврате мы можем быть вытеснены более приоритетными задачами.
|
||||
|
|
@ -529,7 +528,6 @@ OSTaskCreateExt();
|
|||
\begin{itemize}
|
||||
\item с фиксированными приоритетами ($\mu$C/OSII) приоритет может менять только программист. существует проблема инверсии приоритетов. Допустим, есть три задачи с разными приоритетами. Задача 1 самая приоритетная, она не выполняется. Задача 3 самая не приоритетная захватывает ресурс А. Приходит запрос прерывания, которого ждёт задача 1, диспетчер снимает задачу 3. Если задаче 1 нужен будет ресурс А, диспетчер отправляет 1 в ожидание и продолжает выполнять 3. Но тут случается плохое - прерывание для задачи 2. диспетчер снимает 3 и выполняет 2. Получается, что задача 1 ждёт менее приоритетную задачу 2, которая даже не задействовала ресурс А.
|
||||
|
||||
\def\svgwidth{140mm}
|
||||
\includesvg[scale=1.01]{pics/01-ess-00-tasks.svg}
|
||||
|
||||
Чтобы этого избежать в $\mu$C/OSII введён специальный тип семафоров (мьютексы) которые временно повышают приоритет задач, ожидающих ресурсы.
|
||||
|
|
@ -585,7 +583,6 @@ OSTaskCreateExt();
|
|||
|
||||
\item \textbf{Mutex.} (mutual exclusion) взаимное исключение. В большинстве операционных систем мьютекс это двоичный семафор, кроме $\mu$C/OSII. В $\mu$C/OSII это двоичный семафор, который решает проблему инверсии приоритетов. Каким образом решает? При создании мьютекса ему передаётся приоритет. Так как $\mu$C/OSII это операционная система с фиксированными приоритетами, для мьютекса нужно выделить отдельный приоритет, который не используется в других задачах и обязательно он должен быть выше, чем у любой задачи, которая будет использовать этот мьютекс. Как только какая-то задача пытается получить доступ к мьютексу, который занят, у задачи, которая владеет мьютексом становится приоритет мьютекса (становится выше, для задачи со средним приоритетом становится невозможно захватить ресурс).
|
||||
|
||||
\def\svgwidth{120mm}
|
||||
\includesvg[scale=1.01]{pics/01-ess-00-mutex.svg}
|
||||
|
||||
Проблема, например, может быть, если есть больше задач с разными приоритетами. Нужно разруливать вручную, внимательно расставляя приоритеты задач. Функции такие же как с семаформаи. В создании есть больше опций ошибок. Важная ошибка - ошибка о существовании такого-же приоритета или при задании недопустимого приоритета. Остальные функции идентичны.
|
||||
|
|
@ -631,7 +628,7 @@ OSTmrCreate, Del, NameGet, RemainGet
|
|||
OSTmrSignal() находится в файле остмр.с. фактически он просто постит семафор с параметром(ОСТмрСемСигнал). Это семафор, который создаётся со значением 0, то есть это семафор, созданный для того, чтобы кто-то его ждал (синхронизация). постит этот семафор ОСТаймТикХук (в котором ещё и происходит деление системного тикера на значение таймера). тайм тик хук - это пользовательская функция, которая может вызываться при создании задачи, но если мы создали таймер - она будет занята. ОСТаймТикХук вызывается в функции ОСТаймТик(), которая внутри себя инкрементирует время и содержит часть диспетчера ОС (одна из самых главных функций в этой цепочке). ОСТаймТик в заголовке с хуками переименовывается и вызывается из папки HAL, то есть из папки поддержки ПЛИС, из функции альтТик. функция альтТик вызывается альтАвалонТаймерСцИрку. чистая ниос функция - обработчик прерывания таймера, который мы настроили в кусисе. эта функция запускается критической секцией с запрещением прерываний, поэтому запретив прерывания где-то внутри прерывания по таймеру мы с большой вероятностью обрушим систему.
|
||||
пендит семафор таймера функция ОСТмрТаск. Эта функция считает в какой спице оказался таймер и вызывает зарегистрированный колбэк таймера. Колбэк вызывается в контекте таймера (не должна модифицировать никакие переменные других задач) должны совершаться минимальные действия и отправлять какие-то сообщения или флаги.
|
||||
|
||||
\subsubsection{Управление задачами в $\mu$C/OSII}
|
||||
\subsubsection{Управление задачами в uC/OSII}
|
||||
Важно, что удаление задач, пауза и возобновлени - нетипично, поскольку это должно по идее быть работой ОС, а не программиста. Задача в $\mu$C/OSII это всегда бесконечный цикл, в котором опрашиваются флажки мьютексов, почтовых ящиков, и так далее.
|
||||
\begin{enumerate}
|
||||
\item Создание задач. Функция, без которой ничего не получится - \code{OSTaskCreate()}. Принимает на вход нетипизированный контекст (собственно задача, ссылка на функцию), начальные параметры, вершину стека, приоритет.
|
||||
|
|
@ -641,7 +638,7 @@ OSTmrSignal() находится в файле остмр.с. фактическ
|
|||
\end{enumerate}
|
||||
Самый низкий приоритет у задачи IDLE, чуть выше у Stat. Если используются таймеры - самый высокий приоритет у задач таймеров. Всё, что между ними - пользовательские задачи. То есть если мы ничего не делаем - мы делаем задачу IDLE.
|
||||
|
||||
\subsubsection{Обработчики прерываний в $\mu$C/OSII}
|
||||
\subsubsection{Обработчики прерываний в uC/OSII}
|
||||
Если вызываем в обработчике прерываний какие-то функции операционной системы, то обязательно в начале надо вызвать \code{OSIntEnter}, а в конце \code{OSIntExit}. Это отключит диспетчеризацию, то есть мы кладём задачу в очередь, но не вызываем диспетчер.
|
||||
|
||||
\subsubsection{Критические секции, блокировка диспетчера и атомарные операции}
|
||||
|
|
@ -810,9 +807,8 @@ ISO/IEC 12207:2008 (ГОСТ 12207-2010) - про разработку ПО, ж
|
|||
\item в современных микроконтроллерах много памяти, поэтому, сохраняется не только указатель на стек, но и текущий контекст исполнения, поэтому при использовании вложенных обработчиков, требования к размеру стека ещё больше увеличиваются. в операционных системах реального времени обычно контекст сохраняется в стек операционной системы.
|
||||
\item всё равно ждать пока текущий низкоприоритетный обработчик закончит свои важные дела (недетерминированность во времени обработки уменьшается, но всё равно сохраняется) то есть для всех низкоприоритетных надо чётко знать сколько времени займут обязательные действия низкоприоритетных обработчиков
|
||||
\item возможные логические ошибки для связанных процессов
|
||||
\begin{figure}[h]
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\def\svgwidth{70mm}
|
||||
\includesvg[scale=1.01]{pics/01-ess-00-irq.svg}
|
||||
\caption{Проблемы разрешения вложенных прерываний}
|
||||
\label{pic:irq}
|
||||
|
|
@ -860,14 +856,12 @@ ISO/IEC 12207:2008 (ГОСТ 12207-2010) - про разработку ПО, ж
|
|||
\begin{itemize}
|
||||
\item фон-Нейманова модель - общая память для команд и данных.
|
||||
|
||||
\def\svgwidth{80mm}
|
||||
\includesvg[scale=1.01]{pics/01-ess-00-fon-neyman.svg}
|
||||
\label{pic:fon-neyman}
|
||||
|
||||
википедия: Архитектура фон Неймана (модель фон Неймана, Принстонская архитектура) — широко известный принцип совместного хранения команд и данных в памяти компьютера. Вычислительные машины такого рода часто обозначают термином <<машина фон Неймана>>, однако соответствие этих понятий не всегда однозначно. В общем случае, когда говорят об архитектуре фон Неймана, подразумевают принцип хранения данных и инструкций в одной памяти.
|
||||
\item гарвардская модель - разделение памяти на данные и команды физически по устройствам. Часто именно так устроены микроконтроллеры.
|
||||
|
||||
\def\svgwidth{80mm}
|
||||
\includesvg[scale=1.01]{pics/01-ess-00-harvard.svg}
|
||||
\label{pic:harvard}
|
||||
|
||||
|
|
@ -880,7 +874,6 @@ ISO/IEC 12207:2008 (ГОСТ 12207-2010) - про разработку ПО, ж
|
|||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\def\svgwidth{120mm}
|
||||
\includesvg[scale=1.01]{pics/01-ess-00-memory.svg}
|
||||
\caption{Обычное устройство микроконтроллера}
|
||||
\label{pic:memory}
|
||||
|
|
@ -913,7 +906,6 @@ ISO/IEC 12207:2008 (ГОСТ 12207-2010) - про разработку ПО, ж
|
|||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\def\svgwidth{70mm}
|
||||
\includesvg[scale=1.01]{pics/01-ess-00-sdram.svg}
|
||||
\caption{Обычно SDRAM выглядит так}
|
||||
\label{pic:SDRAM}
|
||||
|
|
@ -923,7 +915,6 @@ ISO/IEC 12207:2008 (ГОСТ 12207-2010) - про разработку ПО, ж
|
|||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\def\svgwidth{60mm}
|
||||
\includesvg[scale=1.01]{pics/01-ess-00-arrayrow.svg}
|
||||
\caption{Хранение данных из массива в памяти}
|
||||
\label{pic:arrayrows}
|
||||
|
|
@ -932,7 +923,6 @@ ISO/IEC 12207:2008 (ГОСТ 12207-2010) - про разработку ПО, ж
|
|||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\def\svgwidth{80mm}
|
||||
\includesvg[scale=1.01]{pics/01-ess-00-readmem.svg}
|
||||
\caption{Чтение данных из памяти SDRAM}
|
||||
\label{pic:readmem}
|
||||
|
|
@ -946,9 +936,8 @@ RAS, CAS: после выборки адреса чтение происходи
|
|||
Отличаются обращениями к блокам памяти одиночные или двойные
|
||||
Наша задача планирования размещения памяти расположить данные в SARAM и DARAM так, чтобы не было конфликтов обращений от разных модулей. Обычно это сводится к тому, что надо прагмами указать куда именно надо класть массивы и другие объёмные данные.
|
||||
|
||||
\begin{figure}[h]
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\def\svgwidth{80mm}
|
||||
\includesvg[scale=1.01]{pics/01-ess-00-s-d-aram.svg}
|
||||
\caption{Планирование памяти}
|
||||
\label{pic:sdaram}
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
\documentclass[a4paper,fontsize=14bp]{article}
|
||||
\documentclass[a4paper]{article}
|
||||
|
||||
\input{settings/common-preamble}
|
||||
\input{settings/fancy-listings-preamble}
|
||||
|
|
@ -9,6 +9,7 @@
|
|||
\def\grpNum{11М}
|
||||
|
||||
\begin{document}
|
||||
\fontsize{14}{21}\selectfont
|
||||
\setlength{\columnsep}{22pt}
|
||||
\thispagestyle{empty}
|
||||
\makeBMSTUHeader
|
||||
|
|
@ -634,7 +635,7 @@ int main(void) {
|
|||
// <@\lh{dkgreen}{выполнение нижеследующего цикла}@>
|
||||
// <@\lh{dkgreen}{r8 = r4 (указатель на массив) + r8}@>
|
||||
1000001c: 2211883a add r8,r4,r8
|
||||
// while (size > 8) { <@\label{line:unroll}@>
|
||||
// while (size > 8) { <@\label{line:unrollopt}@>
|
||||
// sum += *addr++;
|
||||
// sum += *addr++;
|
||||
// sum += *addr++;
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
\documentclass[a4paper,fontsize=14bp]{article}
|
||||
\documentclass[a4paper]{article}
|
||||
|
||||
\input{settings/common-preamble}
|
||||
\input{settings/bmstu-preamble}
|
||||
|
|
@ -10,6 +10,7 @@
|
|||
\def\grpNum{11М}
|
||||
|
||||
\begin{document}
|
||||
\fontsize{14}{21}\selectfont
|
||||
\thispagestyle{empty}
|
||||
\makeBMSTUHeader
|
||||
|
||||
|
|
@ -23,7 +24,7 @@
|
|||
Целью работы являлось освоение навыков проектирования программного обеспечения для операционных систем реального времени. Создание простого проекта программного обеспечения системы на кристалле Nios II на основе ОСРВ $\mu$C/OS-II. Изучение основных сервисов ОСРВ $\mu$C/OS-II. Реализация обработчика прерывания в системе на кристалле Nios II. Освоение методики обработки внешних событий в $\mu$C/OS-II.
|
||||
|
||||
\section{Выполнение}
|
||||
\subsection{Часть I. Создание простой системы на основе $\mu$C/OS-II}
|
||||
\subsection{Часть I. Создание простой системы на основе uC/OS-II}
|
||||
В первой части работы была создана простая система на основе ОСРВ $\mu$C/OS-II. В приложении \hrf{appendix:pt1full} приведён полный листинг готовой программы. Единственным отличием от предложенной в исходном материале было добавление переключения светодиода по вызову задачи второго семафора, согласно методического материала. В листинге \hrf{lst:pt1change} представлен код, добавленный в тело функции \code{getsem_task2}.
|
||||
\begin{lstlisting}[language=C, style=CCodeStyle, caption=Внесённые в исходный код изменения, label={lst:pt1change}]
|
||||
...
|
||||
|
|
@ -59,7 +60,7 @@ Idx Name Size VMA LMA File off Algn
|
|||
CONTENTS, READONLY
|
||||
\end{lstlisting}
|
||||
|
||||
\subsection{Часть II. Реализация обработчиков прерываний в $\mu$C/OS-II}
|
||||
\subsection{Часть II. Реализация обработчиков прерываний в uC/OS-II}
|
||||
В приложении \hrf{appendix:pt2isr} представлен полный листинг программы, включающий обработку прерываний. Основным отличием является подключение функции обработки прерываний (в листинге \hrf{lst:addisr} представлены фрагмент фукнции инициализации со строкой подключения и функция обработчика). Также, согласно задания, функция \code{send_task} была изменена таким образом, чтобы отправлять сообщения в очередь не по таймеру, а по сигналу от обработчика прерываний.
|
||||
\begin{lstlisting}[language=C,style=CCodeStyle,label={lst:addisr},caption=Функция обработки прерываний и изменённая функция \code{send_task}]
|
||||
void isr_button(void* context, alt_u32 id) {
|
||||
|
|
|
|||
|
|
@ -5,6 +5,11 @@
|
|||
\usepackage{fontspec}
|
||||
\input{settings/fancy-listings-preamble}
|
||||
|
||||
% для совместимости с настройками компилятора для остальных документов
|
||||
\usepackage{nomencl}
|
||||
\makeindex
|
||||
\makenomenclature
|
||||
|
||||
\makeatletter
|
||||
\def\beamer@framenotesbegin{% at beginning of slide
|
||||
\usebeamercolor[fg]{normal text}
|
||||
|
|
|
|||
|
|
@ -22,8 +22,7 @@
|
|||
Вероятность ошибок модуляции \newline
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\def\svgwidth{50mm}
|
||||
\includesvg{pics/01-itsp-01-ber.svg}
|
||||
\includesvg[width=50mm]{pics/01-itsp-01-ber.svg}
|
||||
\caption{график вероятности появления ошибки к соотношению сигнал-шум}
|
||||
\label{pic:BER}
|
||||
\end{figure}
|
||||
|
|
@ -45,18 +44,16 @@
|
|||
\item по ширине полосы:
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\def\svgwidth{50mm}
|
||||
\includesvg{pics/01-itsp-01-bandwidth.svg}
|
||||
\includesvg[width=50mm]{pics/01-itsp-01-bandwidth.svg}
|
||||
\label{pic:bandwidth}
|
||||
\caption{Понятие ширины полосы}
|
||||
\end{figure}
|
||||
|
||||
\[
|
||||
$$
|
||||
\Delta_f = f_1 - f_2
|
||||
\]
|
||||
\[
|
||||
$$$$
|
||||
\mu = \frac{\Delta_f}{f_c}
|
||||
\]
|
||||
$$
|
||||
где $\mu$ -- это показатель ширины полосы.
|
||||
|
||||
\begin{itemize}
|
||||
|
|
@ -99,9 +96,7 @@
|
|||
\end{enumerate}
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\def\svgwidth{60mm}
|
||||
\includesvg{pics/01-itsp-01-rxtx-ack.svg}
|
||||
|
||||
\includesvg[width=60mm]{pics/01-itsp-01-rxtx-ack.svg}
|
||||
\caption{Подтверждение приёма данных от передатчика}
|
||||
\label{pic:rxack}
|
||||
\end{figure}
|
||||
|
|
@ -123,8 +118,7 @@
|
|||
\item расширение спектра -- теоретически опциональный, нацелено на то чтобы не мешать другим и собирать меньше шумов, мы должны стремиться к тому чтобы полоса нашего сигнала должна быть наименьшая. позволяет повысить помехоустойчивость.
|
||||
|
||||
\begin{frm}
|
||||
\def\svgwidth{50mm}
|
||||
\includesvg{pics/01-itsp-01-bad.svg}
|
||||
\includesvg[width=50mm]{pics/01-itsp-01-bad.svg}
|
||||
|
||||
если есть помеха -- мы снижаем риск того что она будет критической для системы.
|
||||
\end{frm}
|
||||
|
|
@ -157,8 +151,7 @@
|
|||
При частоте 2,4 можем использовать более крутые модуляции, например используется для WiFi, IEEE 802.15.4.
|
||||
|
||||
\section{Распространение радиоволн}
|
||||
\def\svgwidth{60mm}
|
||||
\includesvg{pics/01-itsp-01-width.svg}
|
||||
\includesvg[width=60mm]{pics/01-itsp-01-width.svg}
|
||||
|
||||
\[u(t) = S_I(t)+jS_Q(t)\]
|
||||
|
||||
|
|
@ -195,8 +188,7 @@
|
|||
|
||||
Потери сигнала равны десяти десятичным логарифмам отношения переданного к принятому. В среднем скорость затухания линейно возрастает в логарифмической шкале относительно расстояния, но далее на этом пути начинают включаться негативные эффекты распространения сигнала.
|
||||
|
||||
\def\svgwidth{120mm}
|
||||
\includesvg{pics/01-itsp-01-zamir.svg}
|
||||
\includesvg[width=120mm]{pics/01-itsp-01-zamir.svg}
|
||||
|
||||
\begin{itemize}
|
||||
\item медленное (крупномаштабное) замирание, например, крупные препятствия на пути сигнала
|
||||
|
|
@ -210,8 +202,7 @@
|
|||
\begin{itemize}
|
||||
\item Изотропная антенна -- некая точка в пространстве, которая излучает электромагнитное излучение во все стороны (это абстракция, реально таких не существует). диаграмма направленности -- сфера.
|
||||
|
||||
\def\svgwidth{50mm}
|
||||
\includesvg{pics/01-itsp-01-izo.svg}
|
||||
\includesvg[width=50mm]{pics/01-itsp-01-izo.svg}
|
||||
|
||||
это трёхмерная характеристика
|
||||
|
||||
|
|
@ -221,16 +212,14 @@
|
|||
|
||||
\item монополь/диполь полуволновые, четвертьволновые. Коэффициент усиления антенны (значит в каком-то одном направлении антенна сильнее эталонной), но при этом игнорируем, что в других направлениях это значение будет компенсировано.
|
||||
|
||||
\def\svgwidth{50mm}
|
||||
\includesvg{pics/01-itsp-01-monopol.svg}
|
||||
\def\svgwidth{50mm}
|
||||
\includesvg{pics/01-itsp-01-dipol.svg}
|
||||
\includesvg[width=50mm]{pics/01-itsp-01-monopol.svg}
|
||||
|
||||
\includesvg[width=50mm]{pics/01-itsp-01-dipol.svg}
|
||||
|
||||
Зачем роутеру в этом случае две антенны? Чтобы выставить их под углом 90 градусов, чтобы получился и вертикальный и горизонтальный тор, формирующий почти сферу.
|
||||
\item направленная антенна, например, Яги (Yagi). это набор поперечных прутов. например, секторная антенна, используются в вышках сотовой связи. каждый сектор -- обслуживает физическую территорию (пространственное разделение каналов).
|
||||
|
||||
\def\svgwidth{100mm}
|
||||
\includesvg{pics/01-itsp-01-direct.svg}
|
||||
\includesvg[width=100mm]{pics/01-itsp-01-direct.svg}
|
||||
|
||||
G -- максимальный коэфф усиления G (например, 10дБ относительно изотропной антенны). Чем больше коэфф усиления, тем меньше угол $\alpha$ (ширина главного лепестка). Есть также уровень боковых лепестков, например, -30дБ, это значит, что он в 30 раз меньше, чем главный. Суммарная мощность антенны остаётся равной подаваемой.
|
||||
Так при использовании точка-точка мы можем использовать максимальный коэффициент усиления и узкой шириной главного лепестка -- нужно очень точно наводить антенны друг на друга, то есть появляется требование к точности наведения.
|
||||
|
|
@ -255,8 +244,7 @@ G -- максимальный коэфф усиления G (например, 1
|
|||
|
||||
Например, Для ракет томагавк используется система наведения через GPS. если делать широкополосные омехи на канале GPS -- это будет не эффективно, а эффективнее будет принимать сигнал GPS и переизлучать его.
|
||||
|
||||
\def\svgwidth{70mm}
|
||||
\includesvg{pics/01-itsp-01-station.svg}
|
||||
\includesvg[width=70mm]{pics/01-itsp-01-station.svg}
|
||||
|
||||
Поскольку станция постановки помех ближе -- она будет приоритетной, поэтому ракета за 1млн может быть отправлена в болото станцией за 20долларов. Выход для производителей ракет -- направленная вверх антенна.
|
||||
\end{enumerate}
|
||||
|
|
@ -282,27 +270,24 @@ G -- максимальный коэфф усиления G (например, 1
|
|||
|
||||
PL -- затухание
|
||||
|
||||
\[ PL = 10lg\frac{Pt}{Pr} = 10lg\frac{(4.d)^2}{GtGr\lambda^2} дБ \]
|
||||
\[ PL = 10lg\frac{Pt}{Pr} = 10lg\frac{(4.d)^2}{GtGr\lambda^2} \text{дБ} \]
|
||||
|
||||
затухание обратно пропорционально длине волны. чем больше длина волны, тем меньше затухание, или наоборот чем больше частота несущей -- тем больше затухание. Формула расчёта дальней зоны, где L размер антенны, а лямбда длина волны: $df = \frac{2L^2}{\Lambda}$ и результат должен быть много больше исходных
|
||||
|
||||
Наример частота 900Мгц (длина волны около 33см) и мы используем антенну размером 1метр. по формуле получаем расстояние дальней зоны -- 6 метров. Видим, что это много больше, чем 1 метр и чем 33см. Также есть эмпирическое правило, что дальняя зона -- это сумма длин волн.
|
||||
\item \textbf{двухлучевая модель распространения}. Предполагает уточнение высоты установки антенн передатчика и приёмника (не высоту самих антенн). получается два луча -- прямая видимость и отражённый от поверхности земли. Коэфф усиления а и б - прямая видимость с,д это падающий и отражённый лучи. угол падения Тета большое, расстояния падения и отражения х и хштрих. получаем формулу суммы лучей прямой видимости и отражённого луча, но отражённый луч приходит на время тау позже и формируется сдвиг фаз сигнала. В зависимости от того как приходят сигналы картина сигналов может значительно отличаться.
|
||||
|
||||
\def\svgwidth{60mm}
|
||||
\includesvg{pics/01-itsp-02-zamir.svg}
|
||||
\includesvg[width=60mm]{pics/01-itsp-02-zamir.svg}
|
||||
|
||||
Такая картина возникает из-за разницы фаз, но в асимптотическом случае получаем после какого-то расстояния мощность принятого сигнала будет (схлопываются до GrGt) как у прямой видимости. Также важно учесть коэффициент отражения (зависит от множества факторов, как от диэлектрических свойств, так и от длины волны, итд.) затухание происходит быстрее -- 4я степень расстояния, в отличие от квадрата в открытом пространстве и нет зависимости от длины волны.
|
||||
\item \textbf{десятилучевая модель распространения (Модель гранд каньон)}. Лучи отражаются как в двухлучевой модели + от стен + многократные отражения. Считается, что больше трёх отражений учитывать не нужно из-за слабости сигнала. Также в этой модели используются разные комбинации таких отражений.
|
||||
|
||||
\def\svgwidth{100mm}
|
||||
\includesvg{pics/01-itsp-01-ten.svg}
|
||||
\includesvg[width=100mm]{pics/01-itsp-01-ten.svg}
|
||||
|
||||
Так получаем оригинальный луч и сумму всех отражённых лучей с учётом разницы фаз и коэффициентов отражений от диэлектрической проницаемости среды. Если у лучей недостаточно широкая полоса -- сливаются в один. В сверширокополосных системах каждый импульс различим. Передаваемый сигнал обычно распространяется во все стороны и не учитывается сигнал, уходящий в другую сторону. Скорость затухания равна квадрату расстояния но вплоть до шестой степени. В некоторых случаях сигнал может приниматься даже лучше, чем в прямой видимости. Применяется в шахтах, на длинных улицах, ущельях.
|
||||
\item \textit{Эффекты дифракции и рассеивания}. Точно описать модель дифракции почти невозможно из-за разницы геометрии препятствий. Модель клиновидного препятствия хорошо описана. Волна попадает за препятствие (дифракция, затенение).
|
||||
|
||||
\def\svgwidth{70mm}
|
||||
\includesvg{pics/01-itsp-01-obstacle.svg}
|
||||
\includesvg[width=70mm]{pics/01-itsp-01-obstacle.svg}
|
||||
|
||||
Согласно этой модели есть два расстояния d и d' а также высота препятствия h, при этом если высота значительно меньше длины волны и расстояния значительно больше высоты возникает разница фаз и обозначается дифракционным параметром Френеля-Кирхгофа.
|
||||
\[\Delta d = \frac{h^2}{2}\frac{d+d'}{dd'}\]
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
\documentclass[a4paper,fontsize=9bp]{article}
|
||||
\documentclass[a4paper]{article}
|
||||
|
||||
\input{../common-preamble}
|
||||
\input{../bmstu-preamble}
|
||||
\input{settings/common-preamble}
|
||||
\input{settings/bmstu-preamble}
|
||||
\numerationTop
|
||||
|
||||
\begin{document}
|
||||
|
|
|
|||
|
|
@ -24,6 +24,7 @@ sorting=ntvy,
|
|||
\usepackage{tikz-timing}
|
||||
\renewcommand\appendixtocname{Приложения}
|
||||
\usepackage{icomma}
|
||||
\usepackage{csquotes}
|
||||
|
||||
\makeatletter
|
||||
\providecommand\text\mbox
|
||||
|
|
|
|||
Loading…
Reference in New Issue