diff options
| author | Suren A. Chilingaryan <csa@suren.me> | 2023-05-25 22:41:04 +0200 |
|---|---|---|
| committer | Suren A. Chilingaryan <csa@suren.me> | 2023-05-25 22:41:04 +0200 |
| commit | 6f4af841f6fdd099b97d071ae64c8be60f809456 (patch) | |
| tree | d4f9a18b38e1ce3cfc0a5336215d5ce3afe830d2 /README | |
| download | pcidev-6f4af841f6fdd099b97d071ae64c8be60f809456.tar.gz pcidev-6f4af841f6fdd099b97d071ae64c8be60f809456.tar.bz2 pcidev-6f4af841f6fdd099b97d071ae64c8be60f809456.tar.xz pcidev-6f4af841f6fdd099b97d071ae64c8be60f809456.zip | |
A sample event engine for pcitool (not requiring any PCIe hardware). Initial (barely tested and intended only as an example) release
Diffstat (limited to 'README')
| -rw-r--r-- | README | 19 |
1 files changed, 19 insertions, 0 deletions
@@ -0,0 +1,19 @@ +Sample event engine for pcilib driver platform + - This driver does not require real PCIe hardware and produces dummy data + * Register values are random + * DMA continuously return current buffer context with anyway modifying it (so it is either 0 or random content) + - The pciDriver should be loaded in 'dummy' mode with the following options + modprobe pciDriver DUMMY_DEVICE=1 + - The driver implements all 3 APIs define by pcilib + * Register protocol generating random numbers (and ignoring 'set' values). The registers are defined via included xml definitions and by DMA engine + * DMA engine just prvoiding unmodified buffers in the memory as fast as possible + * Event engine building a histogram over pre-defined integration period and returning either this histograms or raw data via rawdata-callback mechanism. + The access to raw data via standard getdata mechanism is not implemented as it would inflict significant performance penalty. As well, get_next_event API + call is not implemented and is expected to be implemented (with substantial performance penalities) in pcitool via general-purpose implementation relying + on available 'stream' call. This is general-purpose implementation is not enabled yet, but is available and just need testing. + - The implementation of histograming is single-threaded and not optimized. Some thinking should be put here for real applications to ensure that + * It is fast enough to process expected data stream. Likely multi-processing will be needed here and can be implemented either with OpenMP (question of efficiacy) + or using dedicated threads (see ipecamera event engine for an example of trully multiprocessed event engine). + * If still processing was too slow for some period of time, the system can drop some data and recover operation (in provided example, it will misbehave after + losing the data for a first time) + |