Software AreasOfWork » History » Version 5
Anonymous, 02/19/2016 10:49 PM
Fixed one of my entries.
1 | 4 | laforge | = Areas of Work = |
---|---|---|---|
2 | This page lists the various areas of the project that require some work, and who (if at all) is |
||
3 | working on fixing it. |
||
4 | 1 | laforge | |
5 | == Infrastructure == |
||
6 | |||
7 | === Build System === |
||
8 | * we need a clean/known base as a compiler |
||
9 | 4 | laforge | * At the moment, we're mostly using the 4.0.2 release from gnuarm.com, which is fairly old |
10 | * independence of system-provided header files |
||
11 | * We should be mostly there now. But testing this and verifying our independence of system headers would be great |
||
12 | 1 | laforge | |
13 | === Operating System === |
||
14 | 4 | laforge | * Decide which RTOS to use on the Calypso |
15 | * we don't want to use FreeRTOS |
||
16 | * OS should have clear abstraction of core (ARM7TDM), SoC and board level features |
||
17 | * OS should cleanly compile to a library that we can link with all our other code |
||
18 | * While we only work on the GSM stack, no OS is needed. But as soon as UI comes around, that changes. |
||
19 | 1 | laforge | |
20 | === Development Tools === |
||
21 | * try to make JTAG (C155) work with OpenOCD |
||
22 | |||
23 | == Host Software == |
||
24 | 4 | laforge | * osmocon support for the native ROM loader in the Calypso, like it is found on most non-Compal phones |
25 | 1 | laforge | |
26 | == Target Software == |
||
27 | |||
28 | === Drivers === |
||
29 | * charger detection, battery charging (roh) |
||
30 | * SIM card reader (dexter) |
||
31 | 4 | laforge | * Color display driver for C155 (steve-m) |
32 | 1 | laforge | * backlight driver |
33 | * vibrator driver |
||
34 | 4 | laforge | * buzzer driver for C123 |
35 | * C155 ringtone chip driver for SPMA100 chip |
||
36 | * Fix the I2C driver to use the b/w LCD without any sleep/delay loops |
||
37 | 1 | laforge | |
38 | === GSM Stuff === |
||
39 | * TRF6151, TPU, TSP, AGC, AFC (laforge) |
||
40 | 2 | laforge | * Layer1, particularly the synchronous part (laforge, spaar) |
41 | 4 | laforge | * Layer2 (zecke, laforge) |
42 | * Layer3 (eversberg) |
||
43 | * Playing with the Voice part using the dsp misc task (spaar?) |
||
44 | 1 | laforge | |
45 | 3 | laforge | === General Infrastructure === |
46 | 5 | laforge | * Flash-based log-structured filesystem (prom) |
47 | 1 | laforge | |
48 | === Bootloader === |
||
49 | * Put together a bootloader (prom) |
||
50 | * Define linkage situations (prom) |
||
51 | |||
52 | === UI related === |
||
53 | * proportional fonts in at least two sizes, as small as possible |
||
54 | 4 | laforge | * monospaced fonts waste too much scarce screen real estate |
55 | 3 | laforge | * cache the frame buffer in RAM and sync when needed |
56 | 4 | laforge | * once we have a scheduler and tasks, run screen refresh as low-priority task |
57 | 3 | laforge | * hardware independent API to support C123, C155 (and later other) displays |
58 | 4 | laforge | * software should not care if it is using color or b/w display |
59 | * some kind of fixed screen layout masks, where |
||
60 | * a data structure defines a screen mask |
||
61 | * the application can easily update the content without having to deal with formatting/positioning |
||
62 | * UI widgets like |
||
63 | * lists that can be scrolled through |
||
64 | * menus build of a tree of such lists |