Skip to content

Commit

Permalink
fixed typos
Browse files Browse the repository at this point in the history
  • Loading branch information
mariusmm committed Mar 7, 2019
1 parent 1cc26e8 commit 2273273
Show file tree
Hide file tree
Showing 3 changed files with 15 additions and 15 deletions.
2 changes: 1 addition & 1 deletion capitol_3.tex
Original file line number Diff line number Diff line change
Expand Up @@ -112,7 +112,7 @@ \chapter{Gestió de rellotges}

Per aquesta tasca de controlar els rellotges, acostuma a existir un perifèric concret que fa tota la gestió, tant de manegar l'entrada de diferents senyals de rellotge com de preparar i enviar aquests senyals als diferents perifèrics. En els microcontroladors tant de SiliconLabs com de ST tenim diferents branques de rellotge per diferents perifèrics i la CPU. En termes generals podem dir que els perifèrics considerats lents (RTC, LEUART, etc.) reben un senyal de rellotge de baixa freqüència, els perifèrics considerats ràpids (USART, SPI, DAC, ADC, Timers, etc.) un senyal de rellotge d'alta freqüència i la CPU i els perifèrics més relacionats (DMA, Interrupcions, etc.) un altre rellotge \cite[94]{EFM32GRM}\cite[152]{STM32F4RM}.

Al llarg dels diferents exemples s'anirà veient com es gestionen els rellotges. En els casos més senzills, tant sols cal activar el rellotge pel perifèric desitjat cridant a la funció {\bf CMU\_ClockEnable()}\index{CMU\_ClockEnable()}. aquesta funció rep com a paràmetre el perifèric al que se li vol enviar o desactivar el rellotge.
Al llarg dels diferents exemples s'anirà veient com es gestionen els rellotges. En els casos més senzills, tant sols cal activar el rellotge pel perifèric desitjat cridant a la funció {\bf CMU\_ClockEnable()}\index{CMU\_ClockEnable()}. Aquesta funció rep com a paràmetre el perifèric al que se li vol enviar o desactivar el rellotge.

Altres funcions permeten decidir quin senyal rellotge concret es connecta amb quina branca (funció {\bf CMU\_ClockSelectSet()}\index{CMU\_ClockSelectSet()}); dividir un rellotge abans d'entrar a cert perifèric ({\bf CMU\_ClockDivSet()}\index{CMU\_ClockDivSet()}) (Llistat~\ref{clk_mng}).

Expand Down
24 changes: 12 additions & 12 deletions capitol_4.tex
Original file line number Diff line number Diff line change
Expand Up @@ -256,7 +256,7 @@ \chapter{Controlant el temps a les tasques}

\section{Un exemple amb vTaskDelayUntil()}

A l'exemple \href{https://github.com/mariusmm/cursembedded/tree/master/Simplicity/FreeRTOS_Delay}{FreeRTOS\_Delay} es fa servir la funció \index{vTaskDelayUntil()}{\bf vTaskDelayUntil()} dins una tasca que cada cop que s'executa un cicle te un temps diferent d'execució. Això és fa amb una crida a \index{vTaskDelay()}{\bf vTaskDelay()} amb un delay d'un valor aleatori entre 0 i 300 mil·lisegons.
A l'exemple \href{https://github.com/mariusmm/cursembedded/tree/master/Simplicity/FreeRTOS_Delay}{FreeRTOS\_Delay} es fa servir la funció \index{vTaskDelayUntil()}{\bf vTaskDelayUntil()} dins una tasca que cada cop que s'executa un cicle te un temps diferent d'execució. Això és fa amb una crida a \index{vTaskDelay()}{\bf vTaskDelay()} amb un retard aleatori amb valors entre 0 i 300 mil·lisegons.
Després d'aquesta execució es crida la funció {\bf vTaskDelayUntil()} per suspendre de manera que la seva periodicitat sigui sempre de 500 mil·lisegons (veure Llistat~\ref{FreeRTOS_Delay}).


Expand All @@ -280,7 +280,7 @@ \section{Un exemple amb vTaskDelayUntil()}
}
\end{lstlisting}

Per comprova el correcte funcionament es treu per la consola de {\em debug} el {\em tick} que s'està executant i el temps aleatori que es gasta per la tasca (veure Figura~\ref{fig:TaskDelayConsole}). Es pot veure com, a la primera columna, el tick on s'executa la tasca és sempre múltiple de 64 i que el temps que està executant-se la tasca va variant (segona columna).
Per comprova el correcte funcionament es treu per la consola de {\em debug} el {\em tick} en que s'està executant i el temps aleatori que es gasta per la tasca (veure Figura~\ref{fig:TaskDelayConsole}). Es pot veure com, a la primera columna, el tick on s'executa la tasca és sempre múltiple de 64 i que el temps que està executant-se la tasca va variant (segona columna).

\begin{figure}
\centering
Expand All @@ -290,7 +290,7 @@ \section{Un exemple amb vTaskDelayUntil()}
\end{figure}

\subsection{Comprovació amb l'oscil·loscopi}
Es pot aprofitar que l'exemple fa {\em toggle} del LED que també està connectat a un pin del connector d'expansió de la placa de desenvolupament (al pin 15 del {\em Expansion header}).
Es pot aprofitar que l'exemple fa {\em toggle} del LED el GPIO també està connectat a un pin del connector d'expansió de la placa de desenvolupament (al pin 15 del {\em Expansion header}).
A més, s'ha reduït el temps del període a 100 mil·lisegons i un {\em delay} aleatori d'entre 0 i 75 mil·lisegons. Així es pot comprovar amb l'oscil·loscopi que el senyal generat és prou bo i estable (veure Figura~\ref{fig:DelayUntil}).

\begin{figure}
Expand Down Expand Up @@ -423,7 +423,7 @@ \subsection{Exemple amb cues}
\begin{figure}
\centering
\includegraphics[width=0.85\textwidth, keepaspectratio]{imatges/QueueFreeRTOS.png}
\caption{Diagrama de seqüència de l'exemple de {\em debounce}}
\caption{Diagrama de seqüència de l'exemple de cues}
\label{fig:SeqDiagramQueue}
\end{figure}

Expand Down Expand Up @@ -477,7 +477,7 @@ \subsection{Enviant múltiples dades per una cua}

L'altra opció podria ser posar tres cues, una per cada coordenada i la tasca consumidora anar llegint de cada una. Això però, sembla que és una mica massa complexitat per un problema senzill.

La millor solució consisteix a preparar una estructura de dades i que sigui aquesta estructura la que s'envia per la cua. Així, les tres dades viatgen juntes i cada una associada al seu camp corresponent.
La millor solució consisteix a preparar una estructura de dades i que sigui aquesta estructura la que s'envia per la cua. Així, les tres dades viatgen juntes i cada una associada al seu camp corresponent. La definició de l'estructura haurà de ser comú a totes les tasques i cues que la facin servir; en un projecte gran caldrà definir-la en un {\em header} comú per la resta de mòduls del projecte.

Així, podríem definir una estructura tal com es veu al llistat~\ref{queue_struct_example}.

Expand Down Expand Up @@ -508,7 +508,7 @@ \subsection{Enviant múltiples dades per una cua}
...
\end{lstlisting}

Al \href{https://github.com/mariusmm/cursembedded/tree/master/Simplicity/FreeRTOS_Queue_2}{repositori} l'exemple FreeRTOS\_Queue\_2 es fa servir una estructura per passar dades mitjançant una cua.
Al \href{https://github.com/mariusmm/cursembedded/tree/master/Simplicity/FreeRTOS_Queue_2}{repositori} l'exemple FreeRTOS\_Queue\_2 es fa servir una estructura per passar dades mitjançant una cua.


\section{Mutex}
Expand Down Expand Up @@ -654,7 +654,7 @@ \chapter{Una aplicació completa amb FreeRTOS}
Per resumir i posar un exemple de tot el vist sobre \gls{FreeRTOS}, agafarem l'aplicació d'exemple feta a \fullref{ch:aplicaciosenzilla} i es transformarà en una aplicació amb FreeRTOS. Per començar es treballarà amb la versió amb {\em polling} de l'aplicació original.

\section{Tasques}
Una de les característiques d'un \gls{RTOS} és que les diferents tasques a fer per l'aplicació es divideixen en tasques. En aquest cas, sembla senzill pensar que es pot dividir la feina a fer en dos parts: (i) Llegir la dada del sensor i (ii) canviar el \gls{duty cycle} del \gls{PWM} segons el valor llegit. En resum, les tasques seran:
Una de les característiques d'un \gls{RTOS} és que les diferents tasques a fer per l'aplicació es divideixen en tasques. En aquest cas, sembla senzill pensar que es pot dividir la feina a fer en dos parts: (i) llegir la dada del sensor i (ii) canviar el \gls{duty cycle} del \gls{PWM} segons el valor llegit. En resum, les tasques seran:

\begin{itemize}
\item {\bf ReadSensor\_task}: aquesta tasca llegeix periòdicament el valor de proximitat del sensor i envia aquesta dada cap a l'altra tasca. Això ho fa cada mig segon i fa {\em polling} del registre d'{\em estatus} del sensor (veure llistat~\ref{readsensor_task}).
Expand Down Expand Up @@ -722,7 +722,7 @@ \section{Tasques}
...
\end{lstlisting}

Com ja hem vist anteriorment, es creen les dues tasques a la funció {\bf main()}\index{main()}
Com ja hem vist anteriorment, es creen les dues tasques dins de la funció {\bf main()}\index{main()} (Llistat~\ref{createtasks}).

\section{Modificant el {\em wrapper} d'I2C}
\label{sec:wrapperI2C}
Expand All @@ -748,13 +748,13 @@ \section{Modificant el {\em wrapper} d'I2C}

D'aquesta manera en el cas que dues tasques fessin servir el {\em wrapper} per accedir al bus \gls{I2C}, quan cridessin a la funció {\bf I2C\_WriteRegister()}\index{I2C\_WriteRegister()} o {\bf I2C\_ReadRegister()}\index{I2C\_ReadRegister()} aquestes funcions es protegeixen de la re-entrada amb el mutex {\em I2C\_mutex} impedint que es pogués cridar dos cops (un cop de cada tasca) a la funció {\bf I2C\_Transfer()}\index{I2C\_Transfer()}, que faria que les transferències \gls{I2C} no es fessin correctament.

El {\em mutex} (anomenat {\bf I2C\_mutex}) està definit com {\em static} dins el fitxer {\bf I2C\_Wrapper.c}.
El {\em mutex} (anomenat {\bf I2C\_mutex}) està definit com {\em static} dins el fitxer {\bf I2C\_Wrapper.c}. Això farà que aquesta variable només estigui disponible dins el mòdul i no sigui una variable global a tot el projecte. Aquest {\em mutex} s'inicialitza a la funció {\bf I2C\_initialize()}\index{I2C\_initialize}.

\begin{lstlisting}[style=customc,label=I2CMutex]
static SemaphoreHandle_t I2C_mutex;
\end{lstlisting}

Això farà que aquesta variable només estigui disponible dins el mòdul i no sigui una variable global a tot el projecte. Aquest {\em mutex} s'inicialitza a la funció {\bf I2C\_initialize()}\index{I2C\_initialize}.


\index{I2C\_initialize}\index{xSemaphoreCreateMutex()}
\begin{lstlisting}[style=customc,label=CreateI2CMutex]
Expand Down Expand Up @@ -808,7 +808,7 @@ \chapter{Ús del {\bf watchdog} en RTOS}
#define WATCHDOG_TASK2 0x02
#define WATCHDOG_TASK3 0x04
#define WATCHDOG_TASK4 0x08
#define WATCHDOG_FULL 0x0F
#define WATCHDOG_FULL 0x0F

static uint8_t watchdog_list;
SemaphoreHandle_t watchdog_mutex;
Expand Down Expand Up @@ -844,6 +844,6 @@ \chapter{Ús del {\bf watchdog} en RTOS}

El codi que es veu al Llistat~\ref{Watchdog_RTOS} proporciona la funció {\bf watchdogTouch()}\index{watchdogTouch()} que és la que haurà de cridar les diferents tasques del sistema, cadascuna amb un paràmetre {\bf WATCHDOG\_TASK<N>} diferent i únic.

Com es pot veure a l'exemple, la variable local a la biblioteca {\em watchdog\_list} emmagatzema l'estat de totes les tasques i s'hi accedeix a la funció {\bf watchdogTouch()} que protegeix l'accés amb un {\em mutex}. La tasca {\bf watchdogTask()}\index{watchdogTask()} avalua aquesta variable d'estat i si tot ha anat correctament (totes les tasques han cridat la seva funció almenys un cop), alimenta el {\em watchdog} En cas contrari, la tasca no l'alimenta i acabarà per reiniciar el sistema.
Com es pot veure a l'exemple, la variable local a la biblioteca {\em watchdog\_list} emmagatzema l'estat de totes les tasques i s'hi accedeix a la funció {\bf watchdogTouch()} que protegeix l'accés amb un {\em mutex}. La tasca {\bf watchdogTask()}\index{watchdogTask()} avalua aquesta variable d'estat i si tot ha anat correctament (totes les tasques han cridat la seva funció almenys un cop), alimenta el {\em watchdog}. En cas contrari, la tasca no l'alimenta i acabarà per reiniciar el sistema.

A l'exemple aquesta tasca s'executa un cop cada segon, i el {\em watchdog} s'ha de configurar d'acord a aquest temps (un temps de {\em watchdog} de 2 segons seria l'adequat). La resta de tasques haurien de cridar la funció {\bf watchdogTouch()} amb un període de temps prou curt (per exemple cada 500 mil·lisegons) per tal de que tot el sistema s'executi correctament.
4 changes: 2 additions & 2 deletions capitol_5.tex
Original file line number Diff line number Diff line change
Expand Up @@ -35,7 +35,7 @@ \section{Exemple detectant errors greus}
}
\end{lstlisting}

A la primera part (veure Llistat~\ref{HardFaultHandler_1}) de la \gls{ISR} es treu per la consola de debug la causa de l'excepció ({\em bus fault}, {\em memory access}, {\em divide by zero}, etc.).
A la primera part (veure Llistat~\ref{HardFaultHandler_1}) de la \gls{ISR} es treu per la consola de {\em debug} la causa de l'excepció ({\em bus fault}, {\em memory access}, {\em divide by zero}, etc.).

Tot seguit es treu per la mateixa consola els valors dels registres que hi ha a l'\gls{stack} per tenir dades que ens permetin localitzar l'error (Llistat~\ref{HardFaultHandler_2}).

Expand Down Expand Up @@ -196,7 +196,7 @@ \subsection{Exemple de baix consum}
\begin{figure}
\centering
\includegraphics[width=0.85\textwidth, keepaspectratio]{imatges/ADC_LP1_Measurement.png}
\caption{Captura de les mesures temps de l'analitzador lògic}
\caption{Captura de les mesures de temps amb l'analitzador lògic}
\label{fig:adc_logic}
\end{figure}

Expand Down

0 comments on commit 2273273

Please sign in to comment.