1 Hints on Phone Hardware Design
2 ==============================
4 This document provides a number of hints regarding the design of phone hardware.
5 As phones are always on, a main concern below is saving energy.
7 The 0cpm Firmerware has been designed specifically to take advantage of the
8 following hardware facilities.
14 It is not common for phones to employ a bistable display, but it makes a lot of sense
15 to use them. An LCD display usually needs a backlight, causing them to glow rather
16 loudly in the evening, and be hard to read at daytime, unless the backlight is constantly
17 active. Bistable displays usually have excellent contrast, and will reflect ambient
18 light in much the same way as paper; this is why such displays are sometimes referred
21 Aside from the backlight, an LCD driver also sends constantly changing signals to the
22 LCD, and that too can be improved upon.
28 They keyboard of a phone is usually a matrix. It is simpler than a PC keyboard, in that
29 no phones seem to rely on pressing more than one key at the same time.
31 Traditionally, keyboards were scanned at regular intervals. This however, means that
32 the processor must be active very often, and may not be able to sleep as deeply as it
33 could otherwise. Given that (a) phone keys are rarely used, and (b) the keys should
34 be responded to quickly, it is better to ensure that the keys raise an interrupt on
35 the target CPU. This may take a bit more hardware than usual, but it should save in
36 the total power budget.
38 Note that a matrix allows selection of all input columns at the same time; any key
39 pressed would then immediately show up as an activated row. Once that signal has
40 arrived, the columns can be scanned to find the actual key being pressed. Depending
41 on the CPU, even the release of the key may be picked up on as an interrupt, or it
42 may require scanning while the keyboard is active.
48 The hook contact is usually connected to a GPIO port. Make sure it can trigger an
49 interrupt, both when pickup up and putting down the horn. The reason is the same as
50 for the keyboard matrix, with which it usually is not integrated.
56 The codec that exchanges sound with the user is best operated under DMA, so as to
57 make the rate at which samples are exchanged highly constant. Without DMA, the
58 timing would have to rely on something like interrupts; but interrupts may get
59 delayed by other interrupts and critical sections. DMA should cut through
60 everything in a very resource-friendly manner.
66 If a CPU or DSP or SoC has a low-power mode, design for it. Phones are rarely used,
67 but must always be on. While setting up a call, the CPU can speed up its clock and
68 wake up peripherals for the duration of a call. If the voltages of the CPU can be
69 lower in its inactive mode, chances are that even more power is saved. This is a
70 common phenomenon in processors, memories and more chips. Design for it and win
71 the beauty contest of the lowest-energy phone!
77 A phone often has two connectors on its back side; one is the uplinnk the the LAN, the
78 other is the downlink to a PC. The 0cpm Firmerware assumes that the ports are marked
81 Inasfar as PC traffic travels through the phone to the uplink, it should be switched at
82 the lowest possible level of the network stack. Usually, this means Ethernet switching.
83 If it is implemented in a hardware switch, the little CPU in the phone can never become
84 the bottle neck for networking; also, it does not have to spend time, wake up, and so on.
87 Ideally, but not commonly, a switch could connect the PC to the uplink at the physical
88 layer, by connecting the wires of the two ports. It would however also observe what
89 travels over the wires, and be able to take them apart and sit in between as a switch.
90 It would do the latter to respond to Ethernet traffic directed at its MAC address and
91 when operating as a phone. As was said, this is not common practice, but it would make
92 sense for a wide variety of embedded applications that only send very rarely, and in
93 determined bursts. That includes phones, measuring equipment, and probably many more
100 The heart of the 0cpm Firmerware is essentially a tickless RTOS. It will not do
101 anything until an event occurs -- where events could be picking up or putting down
102 the horn, operating a button, or receiving a network packet. There should be no
103 other reason for a phone to wake up. (Although one can never fully predict what
104 applications people will want to run on their phones -- they might be used for
105 surveying a room by sampling the sound level, for instance.)
107 The RTOS is split in a top half (with generic code) and a bottom half (with drivers).
108 Needless to say, a tickless RTOS will only work well on drivers that support the
109 tickless behaviour. So the aforementioned advantages in hardware must be built
110 into the drivers, and the proper configuration flags should also be applied.
113 Differentiate with extravagant hardware
114 ---------------------------------------
116 SIP phones can do much more than just telephony, and the 0cpm Firmerware exists to
117 make just that happen. You could consider an alarm clock, a door bell (with camera)
118 for one home or a building block for appartment blocks that can be forwarded or
119 voicemailed like any other phone; but there are other variations that can be made
120 true with simple extensions -- and you might not always be able to foresee them.
121 In short, it pays to be different, and add extras.
123 **PS/2.** A simple externalised UART port could do fun things. Imagine hooking up
124 a keyboard to enable realtime text (RTT) between users. This is an RTP-protocol
125 that is much loved by people with hearing impairments, because it enables them to
126 interrupt each other, something they cannot do with plain chat. Needless to say
127 that devices in support of disabled users also benefit regular users. It is an
128 incredible benefit from what is a trivial extension in terms of hardware. The
129 interesting thing of adding a feature like RTT to an open source application also
130 implies that other devices, from other manufacturers, can be updated with your
131 application code, so your application can be adopted much faster than with a
132 product that only your company markets.
134 **HiFi sound.** Many office workers enjoy music in their work place. Using a codec
135 with high quality speaker outputs may not only save you the cost of integrating a
136 speaker in the phone, it also creates possibilities for webradio support. But do
137 keep in mind that most phone calls use a sampling rate in the audible region -- so
138 your codec must be able to either oversample and filter away anti-aliasing aspects
139 in the sound -- or your user will be very tense from high tone disturbance.
141 **Stereo sound.** Whether HiFi or not, stereo sound is useful for telephony, and the
142 protocols support it. The utility of stereo sound would be that contacts could be
143 positioned in a semicircle surrounding the caller, so the voices are much simpler
144 for a user to separate. This facility could be implemented in a meeting room service
145 or in the phone itself -- by combining incoming mono voice channels. As before, this
146 code would be general 0cpm Firmerware code, and would thus be made available to other
147 devices as well. This means that those devices can pick up on stereo telephony
148 faster than if it was limited to a closed system.
150 Stereo sound can also be surprisingly useful for microphones. If you have never
151 experienced being blind, you might try dining in absolute darkess (asking a real
152 blind person to serve you in avoidance of a mess). It is a striking sensation to
153 notice that you immediately feel if someone is talking directly to you. Imagine
154 the value of having that in a phone conversation!
156 **Be extravagant.** The big lesson seems to be that support for disabled or specialised
157 users is not a burden, it can actually be an inspiration. Even if you don't see a
158 useful application, you can be fairly certain that the open source community will.
159 Just ship a few of your phones to active developers and see what will happen... it's
160 the cheapest marketing possible!
166 The openness of the 0cpm Firmerware is not a danger, it is a feature that will
167 save you lots of work. Development cycles can shorten dramatically, and the
168 World is full of potential programmers that may pickup where you left. By
169 pointing to an open source community, you can actually tell people to some
170 extent to help themselves when it comes to support and repair.
172 To gain these qualities, all you need to do is open your changes to the code.
173 This is not just a legal requirement of using the 0cpm Firmerware, but it is
174 also necessary to allow people to help themselves. That means that any driver
175 code that you develop in-house for your target chip must also be open.
177 There are a few checks that you should make before choosing a hardware platform
178 for the 0cpm Firmerware:
180 * You must use a freely distributable toolchain. A lot of platforms are supported
181 by ``gcc`` and ``binutils``, including quite a few embedded environments. In more
182 and more cases, the platform vendor will have embraced open source support for the
183 same reasons you are now considering it for your phone. Choose another platform
186 * You can only use libraries that are compatible with GPL. Using libraries that
187 may not be redistributed or linked to GPL code and/or that come without source code
188 make it impossible for you to open up your application. Choose another platform
189 if this check fails, or decide to write the basic drivers yourself, and add them
190 to the bottom half of the 0cpm Firmerware.
192 * You should not base your work on limited-access documentation. The lack of
193 documentation severely limits future developers to make any contributions
194 that are specifically lucrative on your platform. You may want to choose
195 another platform if this check fails.
197 * You must make it possible for end users to replace the firmware on your device
198 with any version that they may have created themselves, or found somewhere
199 online. Obviously, you are not required to support a product with third-party
200 firmware. But you should probably provide a bootloader (like the generic one
201 provided as part of the 0cpm Firmerware) or other mechanism to permit an
202 upgrade of the firmware. As a general rule, you should make it as easy for
203 end users as it is for you
204 to develop for the device, and upload firmware to it. This implies that you
205 must not use digital signatures to ban uploads of firmware that were not
206 authorised by you. Checksums and hashes to validate the contents of an
207 image before burning it into Flash memory are a different story; they are a
208 good precaution; be sure to document such platform-specifics though, for
209 example by including it in the build chain for the firmware.
211 If you incorporate the bootloader of the 0cpm Firmerware then you should also
212 enable end-users to replace that part of Flash (as a separate module), but
213 if you use a closed bootloader then you need not support its replacement. The generic
214 bootloader in the 0cpm Firmerware can be used to upload to independent flash partitions,
215 and the same mechanism can also be used to upload other things, like ringtone
218 * Your management should underwrite the opening up of any changes that you
219 make to the 0cpm Firmerware; if they question this, you can
220 explain that they will save lots of money on development and support
221 by incorporating lots of existing code and that only a little bit has to be
222 added and opened to the World. In case your manager argues that this makes
223 the code available to competitors, explain that the competitor can already
224 choose to download complete code for other platforms, and that the essence
225 of the advantage is that adding less value in the form of firmware means
226 that less protection can be gained from it -- but that the essence of being
227 in electronics is not to create and support firmware, but rather to produce hardware.
228 And when it comes to making money from a total solution, it is hardware that
229 feels an asset to buyers, not firmware. Be very clear to your managers -- they
230 should understand that pulling out of intended openness after porting the
231 0cpm Firmerware would make it illegal to sell the product at all -- and that
232 there are volunteers who care enough about these things to prosecute
233 companies that invalidate open source licenses.
235 * As soon as your port is working, write a document in the ``doc/bottom/``
236 directory. You can clone ``SKELETON.rst`` as a starting point. Please
237 create a directory with your manufacturing domainname and place your
238 documents in there. The document should explain the following things to
239 developer-type end users:
241 - Whether they loose their warrenty if they upload their own firmware;
242 - What hardware is used for the product they bought;
243 - If you feel so inclined, a schematic circuit of the hardware;
244 - Where to find the source code (possibly at the 0cpm project itself);
245 - Where to find the toolchain that you used to develop the firmware;
246 - How you built the firmware for the device (cmdline instructions);
247 - Whether debugging interfaces exists, and how to use them;
248 - Possibly how to retrieve the current firmware from your device;
249 - How to upload newly built firmware to your device;
250 - Possibly how to recover if a firmware version fails.
252 The ``SKELETON.rst`` file gives examples for each, and you are welcome to
253 reuse it to construct this documentation, with or without modification.
254 Please retain the ``.rst`` extension and follow the Docutils_ guidelines
255 when documenting, and test with a tool like ``doc2html`` whether it is free
256 of errors. You will find that Docutils is a very useful tool for writing
257 documentation efficiently for a variety of output formats.
259 .. _Docutils : http://docutils.sourceforge.net/rst.html
261 Please keep in mind that the requirements of openness exist to keep the
262 0cpm Firmerware open at all times. This is beneficial for your end users,
263 and will reflect upon the popularity of your hardware. Even if you have to
264 select a different platform from a closed one with a lower per-unit cost, it
265 will still save you lots in development and support, and make your hardware
266 more popular and longer-lasting; so, as a result the open platform is likely
267 to be a financially better alternative due to more than the per-unit cost.
projects / firmerware / blob