/alps/ipecamera

To get this branch, use:
bzr branch http://suren.me/webbzr/alps/ipecamera

« back to all changes in this revision

Viewing changes to NOTES

  • Committer: Suren A. Chilingaryan
  • Date: 2011-12-12 04:45:35 UTC
  • Revision ID: csa@dside.dyndns.org-20111212044535-6no1q7g230i8uvlv
multithread preprocessing of ipecamera frames and code reorganization

Show diffs side-by-side

added added

removed removed

Lines of Context:
186
186
Buffering
187
187
=========
188
188
 The DMA addresses are limited to 32 bits (~4GB for everything). This means we 
189
 
 can't really use DMA pages are sole buffers. Therefore,
190
 
 1. In streaming mode a second thread will be spawned copying the data from the
191
 
    DMA pages into the allocated buffers. On duration expiration this thread
192
 
    will be stopped but processing will continue until all copyied data is 
193
 
    passed to the callbacks.
194
 
 2. In synchronous mode, a single event will be extracted from the the DMA
195
 
    memory.
196
 
 
197
 
 - Actually, we can make another in-module buffering. But this hopefully can
198
 
 be avoided.
 
189
 can't really use DMA pages are sole buffers. Therefore, a second thread, with
 
190
 a realtime scheduling policy if possible, will be spawned and will copy the 
 
191
 data from the DMA pages into the allocated buffers. On expiration of duration
 
192
 or number of events set by autostop call, this thread will be stopped but 
 
193
 processing in streaming mode will continue until all copyied data is passed 
 
194
 to the callbacks.
 
195
 
 
196
 To avoid stalls, the IPECamera requires data to be read continuously read out.
 
197
 For this reason, there is no locks in the readout thread. It will simplify
 
198
 overwrite the old frames if data is not copied out timely. To handle this case
 
199
 after getting the data and processing it, the calling application should use
 
200
 return_data function and check return code. This function may return error
 
201
 indicating that the data was overwritten meanwhile. Hence, the data is 
 
202
 corrupted and shoud be droped by the application. The copy_data function
 
203
 performs this check and user application can be sure it get coherent data
 
204
 in this case.
 
205
 
 
206
 There is a way to avoid this problem. For raw data, the rawdata callback
 
207
 can be requested. This callback blocks execution of readout thread and 
 
208
 data may be treated safely by calling application. However, this may 
 
209
 cause problems to electronics. Therefore, only memcpy should be performed
 
210
 on the data normally. 
 
211
 
 
212
 The reconstructed data, however, may be safely accessed. As described above,
 
213
 the raw data will be continuously overwritten by the reader thread. However,
 
214
 reconstructed data, upon the get_data call, will be protected by the mutex.
199
215
 
200
216
 
201
217
Register Access Synchronization