\documentclass[10pt]{article}
\usepackage[T1]{fontenc}\usepackage[utf8]{inputenc}\usepackage[polish]{babel}
\usepackage[a4paper,margin=1.55cm]{geometry}
\usepackage{array,tabularx,booktabs,amsmath,amssymb,xcolor,listings,hyperref,fancyhdr,lastpage,enumitem}
\definecolor{accent}{HTML}{16324A}\definecolor{accentlight}{HTML}{EEF3F7}\definecolor{rulegray}{HTML}{D7DEE5}
\hypersetup{colorlinks=true,linkcolor=accent,urlcolor=blue}
\IfFileExists{build-meta.tex}{\input{build-meta.tex}}{\newcommand{\BuildCommit}{local}}
\newcommand{\PublisherDomain}{mpabi}
\newcommand{\CardArea}{inf}
\newcommand{\CardSeries}{freertos-cpp}
\newcommand{\CardNumber}{16}
\newcommand{\CardCount}{16}
\newcommand{\CardSlug}{integration}
\newcommand{\CardVersion}{v00.01}
\newcommand{\DocumentUUID}{05b4f486-a27c-455d-a315-f4e51a4c66b3}
\newcommand{\blank}[1]{\rule{#1}{.2pt}}
\lstset{language=C++,basicstyle=\ttfamily\scriptsize,columns=fullflexible,keepspaces=true,frame=single,breaklines=true,showstringspaces=false,numbers=none,backgroundcolor=\color{accentlight},rulecolor=\color{rulegray}}
\pagestyle{fancy}\fancyhf{}
\lhead{\textbf{K16 · FreeRTOS C++ · Integration}}\rhead{\small L15 · evidence report}
\lfoot{\scriptsize commit \BuildCommit}\cfoot{\scriptsize \thepage/\pageref{LastPage}}\rfoot{\scriptsize V11.3.0 / \CardVersion}
\setlength{\headheight}{14pt}\setlength{\footskip}{19pt}
\setlist[itemize]{nosep,leftmargin=1.45em}\setlist[enumerate]{nosep,leftmargin=1.65em}
\begin{document}\sloppy
\begin{center}
{\LARGE\bfseries Integracja usług RTOS i raport dowodów}\par
\vspace{.25em}{\large barrier, IRQ, timer, pipeline, pressure, heap i stack HWM}\par
\end{center}
\noindent\begin{tabularx}{\textwidth}{@{}p{1.65cm}Xp{1.75cm}X@{}}
\toprule
Karta & K16 / \CardCount & Czas & 30 minut \\
Platforma & Hazard3 / RV32I & Trace & 24 events \\
Dynamic & 1 queue / 128 B & Digest & \texttt{c474ac09} \\
Wersja & \CardVersion & UUID karty & \texttt{05b4f486-...} \\
\bottomrule
\end{tabularx}

\section*{Kompozycja, bez nowego prymitywu}
\begin{lstlisting}
StaticTask producer, processor, reporter;
StaticQueue<Sample, 2> input;
Queue<Report> output{2};             // one measured dynamic service
EventGroup<ServiceBit> startup;
PeriodicTimer<TimerContext> sampler;
\end{lstlisting}

\noindent\fcolorbox{accent}{accentlight}{\begin{minipage}{.94\textwidth}
\textbf{Kontrakt K16.} ISR i timer tylko budzą task. Pipeline, transformacja,
backpressure i raport są task-context work. Każdy storage, priority, queue
policy, failure i pomiar ma jawne uzasadnienie.
\end{minipage}}

\section*{Plan 30 minut}
\noindent\begin{tabularx}{\textwidth}{@{}p{1.35cm}p{3.1cm}X@{}}
\toprule Czas & Tryb & Dowód \\
\midrule
0--5 & inventory & static delta 0; dynamic queue 128 B \\
5--10 & startup & barrier mask 0x7 \\
10--15 & input & IRQ@1, timer@5/10 \\
15--20 & pipeline & 3 reports, sum 120 \\
20--25 & pressure & peaks 2/2, drop seq 4, recovery \\
25--30 & report & latency 6, HWM, digest \\
\bottomrule
\end{tabularx}

\section*{Predykcja}
Który element może być dynamiczny i dlaczego? \blank{5cm}.
Co musi się stać po zapełnieniu queue? \blank{5cm}.

\newpage
\section{Service graph i startup barrier}

\begin{center}
\texttt{EventGroup: producer|processor|reporter = 0x7}\\
$\downarrow$ \texttt{external IRQ@1 -- notify producer -- one yield}\\
$\downarrow$ \texttt{timer@5,@10 -- producer -- input queue}\\
$\downarrow$ \texttt{processor -- report queue -- reporter -- GPIO/report}
\end{center}

\noindent\begin{tabularx}{\textwidth}{@{}p{5.1cm}p{3.2cm}X@{}}
\toprule Pomiar & Predykcja & Odczyt \\
\midrule
startup barrier mask & \texttt{0x7} & \blank{2.5cm} \\
ISR wake / yield calls & 1 / 1 & \blank{2.5cm} \\
ISR kick / producer tick & 1 / 1 & \blank{2.5cm} \\
reporter resume widzi kick & true & \blank{2.5cm} \\
timer callback ticks & 5, 10 & \blank{2.5cm} \\
timer active po stop & false & \blank{2.5cm} \\
\bottomrule
\end{tabularx}

\section*{Granice wykonania}
\begin{itemize}
  \item external ISR: clear source, notification FromISR, one yield;
  \item timer daemon: bounded \texttt{xTaskNotifyGive(producer)};
  \item producer: tworzy sample i realizuje pressure policy;
  \item processor: transformuje value $\times 2$;
  \item reporter: agreguje pod \texttt{CriticalSection}, ustawia GPIO.
\end{itemize}

Dlaczego transformacji nie wykonuje timer callback?\\[.4em]
\blank{16cm}\\[.8em]\blank{16cm}

\section*{Timestamped trace}
Pierwszy sample: tick \blank{1.5cm}. Ostatni report: tick \blank{1.5cm}.
Latencja: \blank{1.5cm} ticków. Liczba eventów: \blank{1.5cm}.

\newpage
\section{Pressure injection i recovery}

\noindent\begin{tabularx}{\textwidth}{@{}p{5.2cm}p{3.1cm}X@{}}
\toprule Zdarzenie & Predykcja & Odczyt \\
\midrule
sample seq 1 / value 10 & accepted & \blank{2.5cm} \\
burst seq 2 i 3 & accepted & \blank{2.5cm} \\
seq 4 przy full input & drop-newest & \blank{2.5cm} \\
input queue peak & 2 & \blank{2.5cm} \\
report queue peak & 2 & \blank{2.5cm} \\
end marker po zwolnieniu miejsca & accepted & \blank{2.5cm} \\
\bottomrule
\end{tabularx}

\section*{Wynik pipeline}
\[
10\cdot2 + 20\cdot2 + 30\cdot2 = \blank{2cm}
\]
Produced / processed / reported: \blank{1.5cm} / \blank{1.5cm} /
\blank{1.5cm}. Dropped sequence: \blank{1.5cm}.

\section{Memory inventory}
\noindent\begin{tabularx}{\textwidth}{@{}p{5.2cm}p{3.1cm}X@{}}
\toprule Pomiar & Predykcja & Odczyt \\
\midrule
static services heap delta & 0 B & \blank{2.5cm} \\
dynamic report queue cost & 128 B & \blank{2.5cm} \\
oversized allocation result & null & \blank{2.5cm} \\
free heap przed/po failure & equal & \blank{2.5cm} \\
minimum-ever free & $\le$ current & \blank{2.5cm} \\
\bottomrule
\end{tabularx}

\section*{Stack report}
\noindent\begin{tabularx}{\textwidth}{@{}p{5.2cm}p{3.1cm}X@{}}
\toprule Task & HWM words & Interpretacja \\
\midrule
producer & 169 & \blank{5cm} \\
processor & 183 & \blank{5cm} \\
reporter & 189 & \blank{5cm} \\
\bottomrule
\end{tabularx}

Czy dodatni HWM sam dowodzi wystarczającego zapasu dla wszystkich wejść?
\blank{4cm}. Dlaczego? \blank{8cm}.

\newpage
\section{Hazard3/GDB i raport końcowy}
\begin{lstlisting}[language=bash]
make check
riscv64-unknown-elf-gdb build/task01_integration/prog.elf
b integration_debug_checkpoint
\end{lstlisting}
\begin{lstlisting}
p/x g_barrier_mask
p g_isr_wake_requested
p g_timer_ticks
p g_samples_produced
p g_samples_processed
p g_reports_received
p g_input_queue_peak
p g_report_queue_peak
p g_pressure_dropped_sequence
p g_dynamic_queue_heap_cost
p g_allocation_failure_recovered
p g_producer_hwm
p g_processor_hwm
p g_reporter_hwm
p g_end_to_end_latency
p/x g_trace_digest
p g_integration_pass
\end{lstlisting}

\section*{Zaliczenie}
\begin{itemize}
  \item $\square$ uzasadniam graph, priorities, ownership i storage;
  \item $\square$ pokazuję barrier 0x7, IRQ@1 oraz timer@5/10;
  \item $\square$ trzy sample dają reports i sumę 120;
  \item $\square$ peaks 2/2, seq 4 drop i end-marker recovery;
  \item $\square$ static delta 0, dynamic queue 128 B, failure bez wycieku;
  \item $\square$ raportuję latency 6, HWM 169/183/189 i digest c474ac09.
\end{itemize}

\section*{Wyjście}
Który invariant uzasadnia każdy użyty wrapper?\\[.5em]\blank{16cm}\\[1em]
Jak odtworzysz ten raport bez screenshotu?\\[.5em]\blank{16cm}

\vfill
\noindent\textbf{Koniec bloku K02--K16:} dalszy projekt rozszerza aplikację,
ale nie zmienia zaliczonych kontraktów storage, lifetime, ISR i evidence.
\end{document}