Discussions about active development projects
#7368 by Nils Roos
Sun Mar 19, 2017 11:04 pm
Amraam wrote:I'm considering the possibility to implement mods to manage triggers, could you tell me all the infos that you consider relevant?
All details are appreciated.

Hi Amraam,

My idea for this was to have a counter running from 0 with the effective sample rate and just store the counter value when a trigger condition is recognized. On the software side, you could poll the corresponding register and take appropriate actions when it changes. The new value would allow to identify the position in the sample stream where the trigger happened. Another idea would be to tie the transfer to ram to the trigger signal, start the transfer upon trigger and leave it running for a configurable time. You'll still need to implement a counter for when the trigger happened exactly, because the transfer logic stores blocks of 512 samples and you only know that the trigger position is somewhere in that frame without a counter.
#7373 by achimoe
Mon Mar 20, 2017 2:58 pm
Hi Nils,
thanks a lot for the quick answer, it worked as described.
According to my quick tests loading this binary has no effect to subsequent usage of the oszilloscope app.
Are the standard apps always reloading the standard binary?
Or is the modified binary compatible with the oszilloscope app?
Sorry if these are FAQs but so far I didn't find too much answers to such questions, any pointers are welcome.
#7386 by Nils Roos
Thu Mar 23, 2017 8:26 pm
When you start a web-app, the bazaar infrastructure will load the bitstream that the app needs (configured in the app's fpga.conf).

The modified binary is mostly compatible with the standard apps, with the one exception that the decimation settings do not match. The standard bitstream allows settings of 1, 8, 64, 1024, 8192, 65536, whereas the ddrdump.bit supports 1, 2, 4, 8, 16, ... 65536 .

Who is online

Users browsing this forum: No registered users and 1 guest