-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathplan.txt
159 lines (140 loc) · 6.54 KB
/
plan.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
HARDWARE
========
1. Constructed basic board with IR send and receive capability.
2. Built separate IR send only board
3. Constructed I2C switch matrix for keypad prototype
4. Constructed adapter board to break out I2C GPIOs, power & ground to
allow 2 & 3 to be used together
5. Constructed load switching circuit to allow charging & operation simultaneously: breadboard, then soldered circuit
6. Constructed 555 timer based IR LED driver on breadboard: manually tested to tune frequency, tested with Pi GPIO and LIRCD to check real functionality.
Load switch testing
-------------------
1. Charge from arbitrary level to full.
- start time: 11:06
- observed full time:
- PSU: 5.2V, 1.5A
- observations:
- at 11:59, power supply went pop, made a burning smell and failed.
- switched to 5.25V, 2A PSU - charging continued from 12:00
- still not switched on 'charged' LED at 14:19
- stopped and shut down at this point
- battery checked via independent charging setup using PowerBoost (5V 1A supply)
- started 14:27
- charging LED observed off 14:50
- battery checked via independent charging setup using MicroLipo charger (5V 1A supply)
- started 15:41
- ...
- found black terminal wire disconnected, so tried again:
- started ~18:55
- observed charged 19:40
2. Charge from low to full.
- started PiMony running on full charge at 19:55
- still working fine at 23:49 (+4 hours)
- restarted next day at 09:55
- observed flat & off at 12:43
- started charge & power on 12:45
- would not boot Pi - turned out to be incorrect wiring of load sharing breadboard.
- corrected and powered up Pi,
switched load sharing back on 12:58
(Pi remained powered up, charge LED
lit)
- observed charged 22:08
SOFTWARE
========
Phase 1 - first working buttons
===============================
- Create demo set of touch buttons to control TV:
Power, Volume up/down, Channel up/down, Guide, Back, Input
- Associate each with an LIRC string
e.g. Power: RM-ED050-12 KEY_POWER Phillips-HTS KEY_POWER
Volume: Phillips-HTS KEY_VOLUMEUP
Phillips-HTS KEY_VOLUMEDOWN
- When a button is pressed, spawn command with string
e.g. "irsend SEND_ONCE %s" % button_lirc_string
- encapsulate irsend it in its own class/module to replace later
Results
- Done, but irsend spawn is too slow:
- multiple commands need separate spawns, which causes errors
- Touchscreen flickers and touches bounce, causing lots of repeats
Phase 2 - Direct LIRC connection
================================
Replace spawn of irsend with direct LIRC communication via directly opening & using
socket in PyMony code.
Results:
- This worked, but didn't alleviate the bouncing/repeating issue
- Not sending IR keeps the UI nice and stable, without bouncing
- Wrote a test C++ app to try sending IR regularly and use SDL to read touchscreen - same bounce issue
- Modified the C++ app to directly read touchscreen via tslib and not SDL - same bounce issue
- Investigated lirc_rpi driver source and touchscreen source (stmpe_ts.c):
- http://harctoolbox.org/downloads/lirc_rpi.c
- http://lxr.free-electrons.com/source/drivers/input/touchscreen/stmpe-ts.c
- lirc_rpi uses bitbanging on gpio port to generate output waveform, and uses a kernel spinlock with
interrupts disabled when sending an entire code - this can be at least 75ms for a 12 bit Sony IR
code (2 repeats with delay between).
- stmpe_ts uses an IRQ to read data from the touchscreen, and also schedules a 'delayed work' timeout
callback which sets a 'no touch' after kernel HZ / 50 delay (which will be about 20ms)
- hypothesis is that the disable interrupt period can cause the touchscreen to timeout and generate
'no touch' events as a result, leading to the bouncing observed.
- Rewrote Python app main loop to separate input reading and IR sending:
- Input event handling loop runs until a button press is detected
- Then any further events are flushed, touch screen events are disabled
- Then IR codes are sent, and a 100ms delay occurs
- Then touch screen events are enabled and loop back to input event handling
- current button is still set to avoid repeats
- This doesn't bounce...
- Seems fairly responsive
- Doesn't repeat send; but could be added
Phase 3 - GPIO buttons
======================
Ideas:
* Use RPIO in Python to set up interrupts/polling on buttons
- modify startup to ensure Python RPIO module can be used without sudo
- create GPIO button class to associate GPIO pin and LIRC string
- on press 'edge' generate IR output
Results
- Added GPIO handling code to read buttons on TFT screen to trigger code sending - worked well.
- Still requires sudo to run.
Phase 4 - Switch matrix
=======================
Ideas:
* Use SMBus in Python to poll I2C
- modify startup to ensure Python SMBus module can be used without sudo
- create SwitchMatrix button class to associate matrix code and LIRC string
- poll I2C to read matrix; on press 'edge' decode to LIRC string and send IR code
Results
- Extended Python app to poll key matrix - worked well
Phase 5 - Devices
=================
* Device has:
- Name
- State variables: power (on/off), input (1,2,3...), audio mode (1,2,3...)
- Current state vector: power, input, audio mode
- Button layout: map touch screen, gpio, keys to remote codes, and optionally to state variables
* Provide device handling
- Device initialisation: read definitions, create instances & default state variables
- Device selection
- Device layout rendering
- Device layout processing (read input, generate remote codes and state changes)
Phase 6 - Activities
====================
* Activity has:
- Name
- Expected state for each available device
* Activity processing
- Initialisation: read definitions, create instances
- Activity selection and switching
- Process expected device state against known state; issue IR commands to achieve expected state
Phase 7 - Advanced UI
=====================
* Richer styles:
- Varied colours
- Varied fonts: faces, styles, colours
- Bitmaps
* More flexible layouts:
- Variable size grids
- Crosses and stars
- Circular
Phase 8 - C/C++ Implementation
==============================
Phase 9 - Microcontroller Implementation
========================================