summaryrefslogtreecommitdiff
path: root/ir
diff options
context:
space:
mode:
authorWerner Almesberger <werner@almesberger.net>2014-07-23 08:41:04 -0300
committerWerner Almesberger <werner@almesberger.net>2014-07-23 08:41:04 -0300
commit2af07957828423b61913408476c6d29dc2419db7 (patch)
treeb39ccef9d483256f78dd5a7af9506fa0d90403e4 /ir
parent4ad5b08774b05e6a879cc5ed1c35fe4754577d91 (diff)
downloadmisc-2af07957828423b61913408476c6d29dc2419db7.tar.gz
misc-2af07957828423b61913408476c6d29dc2419db7.tar.bz2
misc-2af07957828423b61913408476c6d29dc2419db7.zip
ir/: draft version, for review
Diffstat (limited to 'ir')
-rw-r--r--ir/cir.fig4
-rw-r--r--ir/ir.tex155
-rw-r--r--ir/irda.fig4
-rw-r--r--ir/sys.fig4
-rw-r--r--ir/uart.fig4
5 files changed, 116 insertions, 55 deletions
diff --git a/ir/cir.fig b/ir/cir.fig
index 522ed0a..06c4c2c 100644
--- a/ir/cir.fig
+++ b/ir/cir.fig
@@ -78,5 +78,5 @@ Single
4 2 0 50 -1 22 12 0.0000 4 165 1125 1080 2610 uart3_cts_rctx\001
4 2 0 50 -1 22 12 0.0000 4 165 990 1080 2295 uart3_tx_irtx\001
4 2 0 50 -1 22 12 0.0000 4 180 570 1080 1395 gpio(s)\001
-4 1 0 50 -1 22 12 0.0000 4 180 510 1575 4095 config\001
-4 1 0 50 -1 22 12 0.0000 4 180 510 1575 1260 config\001
+4 1 0 50 -1 22 12 0.0000 4 180 510 1575 4095 control\001
+4 1 0 50 -1 22 12 0.0000 4 180 510 1575 1260 control\001
diff --git a/ir/ir.tex b/ir/ir.tex
index a392878..8661b39 100644
--- a/ir/ir.tex
+++ b/ir/ir.tex
@@ -6,10 +6,19 @@
\usepackage{url}
\title{GTA04b7 Infrared Subsystem}
-\author{J\"org Reisenweber, Werner Almesberger}
+\author{J\"org Reisenweber%
+\footnote{Concept and design requirements.}
+%~\url{<joerg@openmoko.org>} \\
+,
+Werner Almesberger%
+\footnote{Specification details and illustrations.}
+%~\url{<werner@almesberger.net>}
+}
\date{July 22, 2014}
+\def\TODO{{\bf TO DO}}
\def\todo#1{\begin{center}{\bf TO DO:} #1\hfill~\end{center}}
+
\def\degree{\,^{\circ}}
\newenvironment{tab}{\vskip4mm\qquad\begin{minipage}{430pt}}%
{\end{minipage}\vskip4mm\noindent}
@@ -23,16 +32,18 @@ It is intended to be used both as tentative specification and as
documentation of actual functionality, and may be revised as
focus shifts over time from requirements to implementation.
+\todo{In this context, do we call it ``GTA04b7'' or ``Neo900'' ?}
% -----------------------------------------------------------------------------
\section{System overview}
The IR subsystem consists of a high-powered transmitter and a receiver.
-It connects to UART3 of the DM3730, where hardware-assisted
-IrDA\footnote{\url{http://en.wikipedia.org/wiki/Infrared_Data_Association#IrPHY}}
+It connects to UART3 of the DM3730 CPU, where hardware-assisted
+IrDA\footnote{\url{http://en.wikipedia.org/wiki/Infrared_Data_Association}}
(SIR) and
-CIR\footnote{\url{http://en.wikipedia.org/wiki/Consumer_IR#Technical_information}}
+CIR\footnote{\url{http://en.wikipedia.org/wiki/Consumer_IR}}
+(``Consumer CIR'')
functions are available.
The IR subsystem also connects to the ``Hackerbus'' which can use the
@@ -54,7 +65,7 @@ is described in section \ref{reset}.
\subsection{IR modes}
\label{modes}
-The IR subsystem supports both ``Consumer CIR'' (CIR) and
+The IR subsystem supports both CIR and
IrDA operation. In CIR mode, it can also receive incoming
IR signals and thus act as a ``learning'' remote control.
Furthermore, the IR transceiver can be configured to send and receive
@@ -88,9 +99,12 @@ characteristics that achieve compatibility with all these modes of operation.
\subsection{CIR}
While there is no common standard for CIR, the characteristics of most IR
-remote control typically lie in the following ranges,
+remote controls typically lie in the following ranges%
+\footnote{Based on the following Wikipedia article:
+\url{http://en.wikipedia.org/w/index.php?title=Consumer_IR&oldid=615137350#Technical_information}}%
+,
with amplitude-shift keying (ASK) being the most common form of modulation,
-although with other types of modulation being possible:
+although other types of modulation are possible:
\begin{tab}
\begin{tabular}{l|cll}
@@ -109,7 +123,9 @@ Beam angle & $\ge 50$ & $\hbox to 0pt{}\degree$
\subsection{IrDA}
IrDA (SIR) uses a pulse modulation with UART-like framing and has the
-following characteristics:
+following characteristics:\footnote{Based on the following Wikipedia
+article:
+\url{http://en.wikipedia.org/w/index.php?title=Infrared_Data_Association&oldid=615436526#IrPHY}}
\begin{tab}
\begin{tabular}{l|cll}
@@ -139,8 +155,8 @@ Parameter & Value & Unit \\
\hline
Data rate & 19.2--115.2 & kbps (typical) \\
Duty cycle & 9.1--91 & \% &%
-\footnote{The duty cycle range of 9.1--91\% (1/11 to 10/11) is for 8 bits plus
-one parity bit, as used by the DM3730 ROM boot loader.
+\footnote{The duty cycle range of 9.1--91\% (1/11 to 10/11) is for 8 bits with
+even parity, as used by the DM3730 ROM boot loader.
The duty cycle range would be 10--90\% for the more common 8 bits
without parity format.} \\
\end{tabular}
@@ -246,9 +262,8 @@ The IR subsystem can be configured for several different modes of operation.
The following sections detail the various configurations.
\todo{J\"org once mentioned the possibility of Hackerbus overriding the
-CPU's configuration signals, but later seemed to care less about this
-unlikely use case. The
-following assumes that the CPU is exclusively in charge of configuring
+CPU's configuration signals.
+The following assumes that the CPU is exclusively in charge of configuring
IR. Is that okay ?}
The following sections show the configuration of both the transmitter and
@@ -280,13 +295,12 @@ by EEPROM content and is therefore retained across power-cycling,
the open-collector output is always set to ``1'', i.e., it is high-Z.
If bq.GPIO is high-Z and the CPU's control signals are in their reset
-state, the IR subsystem shall be deactivated: it must draw as
-little current as possible, the transmitter must ignore its TX or CTS
-inputs, and the receiver must not drive the RX line.
+state, the IR subsystem shall be deactivated as described in section
+\ref{off}.
If bq.GPIO is ``0'' and the CPU's control signals are in their reset state,
both transmitter and receiver shall be active and operate in IR-UART mode.
-The purpose of this mode is allow the CPU's ROM boot loader to try to boot
+The purpose of this mode is to allow the CPU's ROM boot loader to try to boot
from UART3 via infrared.
\todo{Do we agree that bq27200 power on reset defaults to ``IR off'' ?}
@@ -298,7 +312,7 @@ after CPU reset:
\begin{tabular}{ll|l}
CPU.controls & bq.GPIO & IR configuration \\
\hline
-CPU off & any & ??? \\
+CPU off & any & \TODO \\
reset state & ``1'' (High-Z) & off (minimum power) \\
& ``0'' & IR-UART TX/RX \\
active & ignored & defined by controls \\
@@ -306,7 +320,7 @@ active & ignored & defined by controls \\
\end{tab}%
%
Use of the data signals in IR-UART mode is is further explained in
-section {cfg:iruart}.
+section \ref{cfg:iruart}.
Note that Hackerbus can override the receiver and the CPU can therefore
boot from (wired) UART even if the IR-UART configuration is selected.
@@ -317,8 +331,8 @@ boot from (wired) UART even if the IR-UART configuration is selected.
\subsection{IR deactivated}
\label{off}
-The CPU can deactivate the transmitter and receiver, either both or
-individually, through the control signals of the IR subsystem.
+The CPU can deactivate the transmitter and receiver, either both together
+or one at a time, through the control signals to the IR subsystem.
When deactivated, the IR subsystem must draw as little current as possible.
The transmitter must ignore its data inputs, e.g., TX and CTS, and under no
@@ -328,14 +342,17 @@ circumstance activate the IR LED. The receiver must not drive the RX line.
\subsection{CIR mode}
-In CIR mode the CPU uses CTS as an active-high output for transmit data.
+In CIR mode the CPU uses CTS as an active-high output%
+\footnote{Note that CTS is an input at the CPU when UART3 is used as
+regular UART.}
+for transmit data.
The CIR module in the CPU could also use RTS for configuration purposes,
but we seem to have no use for this and the IR circuit must ignore its
state.
The use of RX in CIR mode is not specified and it seems safe to use it
similar to IrDA mode.
-TX is not used and can be assigned to other tasks. The state of TX must
-therefore be ignored when the IR circuit is in CIR mode.
+TX is not used and can be assigned to other tasks. The IR circuit must
+therefore ignore the state of TX when in CIR mode.
CIR mode configuration is illustrated in the following drawing:
\begin{center}
@@ -348,9 +365,9 @@ CIR mode configuration is illustrated in the following drawing:
In IrDA (SIR) mode, the CPU uses TX as active-high output and RX as
active-low input. RTS could again be used for configuration but is not
-relevant in our application and must be ignored by the IR circuit.
-CTS is not used and its state must therefore be ignored when the IR
-circuit is in IrDA mode.
+relevant in our application. CTS is not used in IrDA mode.
+The IR circuit must therefore ignore the state of RTS and CTS when in
+IrDA mode.
IrDA mode configuration is illustrated in the following drawing:
\begin{center}
@@ -364,8 +381,8 @@ IrDA mode configuration is illustrated in the following drawing:
IR-UART mode is identical to IrDA mode as far as the use of UART
signals is concerned. One important difference is that the IR LED
-driver must be configured at a current that does not exceed the
-allowable continuous forward current.
+driver must be configured to operate at a current that does not exceed
+the LED's maximum continuous forward current.
% - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@@ -382,6 +399,33 @@ UART mode configuration is illustrated in the following drawing:
\includegraphics[scale=0.9]{uart.pdf}
\end{center}
+% - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
+
+% \subsection{Mode summary}
+%
+% \def\unspec{---}
+% \def\outpos{$\stackrel{\strut\sqcap}{\longrightarrow}$}
+% \def\outneg{$\stackrel{\strut\sqcup}{\longrightarrow}$}
+% \def\inppos{$\stackrel{\strut\sqcap}{\longleftarrow}$}
+% \def\inpneg{$\stackrel{\strut\sqcup}{\longleftarrow}$}
+%
+% The following table summarizes the configuration of the I/O pins at
+% the CPU in the various IR modes. $\longrightarrow$ indicates a signal from
+% CPU or Hackerbus to the IR
+%
+%
+% \begin{tab}
+% \begin{tabular}{l|ccccc}
+% Signal & \multicolumn{5}{c}{Mode} \\
+% & Off & CIR & IrDA & IR-UART & UART \\
+% \hline
+% TX & \unspec & \outpos \\
+% CTS & \unspec &
+% RTS & \unspec &
+% RX & \unspec &
+% \end{tabular}
+% \end{tab}
+
% -----------------------------------------------------------------------------
\section{Possible component selection}
@@ -392,13 +436,13 @@ UART mode configuration is illustrated in the following drawing:
% http://www.vishay.com/docs/83498/vsmb2948sl.pdf
% is a better match for our purposes
-Taking into account the requirement specified in section \ref{modes},
+Taking into account the requirements specified in section \ref{modes},
available space (see section \ref{placement}), and general component
availability, we consider the Vishay VSMB2948SL%
\footnote{\url{http://www.vishay.com/docs/83498/vsmb2948sl.pdf}}
IR LED and the Vishay VEMD2023SLX01%
\footnote{\url{http://www.vishay.com/docs/83493/vemd2023slx01.pdf}}
-photodiode suitable for our purposes.
+photodiode suitable for our purpose.
\begin{tab}
\begin{tabular}{l|cl|cc}
@@ -414,7 +458,7 @@ Peak frequency & $\ge$ 0.3 & MHz & 23 & $\approx 2$ \\
Note that the peak frequency of 2 MHz for the receiver is an estimate
based on the specified rise and fall times of 100 ns each, which are
specified for a reverse voltage of 10 V whereas we would expect to
-operate at 3.3 V.
+operate at a lower voltage.
% Daylight filter
%
@@ -446,8 +490,11 @@ not have to rely on external filtering and shielding.
% proper discharge resistor on base
We considered the use of a phototransistor, but found that the readily
-available SMT parts all had rise and fall times in the order of 15 $\mu$s
-and did not allow improving their response by biasing the transistore.
+available SMT parts all had rise and fall times in the order of 15 $\mu$s,
+which would limit the maximum signal frequency to only about 30 kHz,
+and did not allow improving their response by biasing the transistor.
+
+\todo{Is the use of ``biasing'' correct here ?}
% -----------------------------------------------------------------------------
@@ -459,9 +506,9 @@ characteristics. The window is approximately 5 mm $\times$ 5 mm.
The window is designed for a single IR LED but we will have a LED
and a photodiode. Since IR components are generally large, it won't
-be possible to place both ``nicely''. However, as the following drawing
-illustrates, both components can ``see'' the window if placed behind each
-other:
+be possible to place both ``nicely'' side by side. However, as the
+following drawing illustrates, both components can ``see'' the window
+if placed behind each other:
\begin{center}
\includegraphics[scale=0.9]{window.pdf}
@@ -483,21 +530,22 @@ is more important than that of the receiver.
% so it can get overridden by HB, given HB driver has lower ESR. Same for
% RX from photodiode which HB can override before it raches UART
-When a line is driven as output from multiple sources, conflict resolution
-strategy shall be applied:
+When a line is driven as output from multiple sources, the following
+conflict resolution strategy shall be applied:
\begin{tab}
\begin{tabular}{l|ll|l}
-Line & Dominant & Subordinate & Applicable CPU states \\
+Line & Dominant & Subordinate & Applicable IR system states \\
\hline
-TX & Hackerbus & CPU & IrDA, UART, use as GPIO \\
-CTS & Hackerbus & CPU & CIR, use as GPIO \\
-RX & Hackerbus or CPU & IR sensor & IrDA, CIR \\
+TX & Hackerbus & CPU & IrDA, IR-UART \\
+CTS & Hackerbus & CPU & CIR \\
+RX & Hackerbus or CPU & IR sensor & CIR, IrDA, IR-UART \\
\end{tabular}
\end{tab}%
%
Conflicts between CPU and Hackerbus on RTS or RX result in undefined
-behaviour and should be avoided.
+behaviour and should be avoided. Conflict increases overall power
+consumption and should be avoided during normal system operation.
Precedence is established by series resistors next to the CPU for TX and
CTS, and a series resistor on the digital output of the IR sensor,
@@ -505,6 +553,19 @@ before entering the RX line.
% -----------------------------------------------------------------------------
+\section{Undriven signals}
+
+If a UART signal is driven by neither CPU, Hackerbus, or the IR receiver,
+...
+
+\todo{What do we do then ? Let it float ? Add a hardware pull up/down ?
+In the latter case, which way ?}
+
+Control signals that float after CPU reset and that are not ignored by the
+IR subsystem must be pulled to a safe state.
+
+% -----------------------------------------------------------------------------
+
\section{Overload protection}
\label{overload}
@@ -515,8 +576,9 @@ before entering the RX line.
Since the IR LED can be driven with a current significantly above its
permitted continuous forward current, the pulse width at high current
-must be limited. This shall be done by hardware, apply to any mode,
-and the maximum continuous pulse width shall be 100$\mu$s.
+must be limited. This shall be enforced by hardware, apply to any mode
+but IR-UART (see below),
+and the maximum continuous pulse width shall be 100 $\mu$s.
\todo{We didn't discuss this property of IR-UART yet. It okay to introduce
this ``low-current'' mode ?}
@@ -530,4 +592,3 @@ therefore not be applied.
\end{document}
% Jul 09 16:47:10 <DocScrutinizer05> re any multiplexing: I expect the whole IR section to get powered down by asserting a GPIO pin to a non-POR-default state, so the IR is active by default after power on reset. By connecting the whole IR via some series resistors to the UART, I expect anything on hackerbus to be able to override what comes from IR, particularly when IR is powered down
-
diff --git a/ir/irda.fig b/ir/irda.fig
index 9867151..eaa913e 100644
--- a/ir/irda.fig
+++ b/ir/irda.fig
@@ -78,5 +78,5 @@ Single
4 2 0 50 -1 22 12 0.0000 4 165 1125 1080 2610 uart3_cts_rctx\001
4 2 0 50 -1 22 12 0.0000 4 165 990 1080 2295 uart3_tx_irtx\001
4 2 0 50 -1 22 12 0.0000 4 180 570 1080 1395 gpio(s)\001
-4 1 0 50 -1 22 12 0.0000 4 180 510 1575 4095 config\001
-4 1 0 50 -1 22 12 0.0000 4 180 510 1575 1260 config\001
+4 1 0 50 -1 22 12 0.0000 4 180 510 1575 4095 control\001
+4 1 0 50 -1 22 12 0.0000 4 180 510 1575 1260 control\001
diff --git a/ir/sys.fig b/ir/sys.fig
index 43907e3..8dedc29 100644
--- a/ir/sys.fig
+++ b/ir/sys.fig
@@ -83,5 +83,5 @@ Single
4 2 0 50 -1 22 12 0.0000 4 165 1125 1080 2610 uart3_cts_rctx\001
4 2 0 50 -1 22 12 0.0000 4 165 990 1080 2295 uart3_tx_irtx\001
4 2 0 50 -1 22 12 0.0000 4 180 570 1080 1395 gpio(s)\001
-4 1 0 50 -1 22 12 0.0000 4 180 510 1575 1260 config\001
-4 1 0 50 -1 22 12 0.0000 4 180 510 1575 4095 config\001
+4 1 0 50 -1 22 12 0.0000 4 180 510 1575 1260 control\001
+4 1 0 50 -1 22 12 0.0000 4 180 510 1575 4095 control\001
diff --git a/ir/uart.fig b/ir/uart.fig
index 1c7b762..88ce574 100644
--- a/ir/uart.fig
+++ b/ir/uart.fig
@@ -78,5 +78,5 @@ Single
4 2 0 50 -1 22 12 0.0000 4 165 1125 1080 2610 uart3_cts_rctx\001
4 2 0 50 -1 22 12 0.0000 4 165 990 1080 2295 uart3_tx_irtx\001
4 2 0 50 -1 22 12 0.0000 4 180 570 1080 1395 gpio(s)\001
-4 1 0 50 -1 22 12 0.0000 4 180 510 1575 4095 config\001
-4 1 0 50 -1 22 12 0.0000 4 180 510 1575 1260 config\001
+4 1 0 50 -1 22 12 0.0000 4 180 510 1575 4095 control\001
+4 1 0 50 -1 22 12 0.0000 4 180 510 1575 1260 control\001