Difference between revisions of "30C3"
Jump to navigation
Jump to search
| Line 9: | Line 9: | ||
* To sr_filter_probes() or not, that is the question. | * To sr_filter_probes() or not, that is the question. | ||
** frontends have probe location info, they pass it to sr_filter_probes() after all | ** frontends have probe location info, they pass it to sr_filter_probes() after all | ||
** very nice for output modules: avoids having to | ** very nice for output modules: avoids having to map probe location to bit on ''all'' the modules | ||
** waste of time for PV, which will soon do its own reformatting of logic data anyway | ** waste of time for PV, which will soon do its own reformatting of logic data anyway | ||
** SRD currently needs it, but has a probe mapping mechanism already, so can be adapted | ** SRD currently needs it, but has a probe mapping mechanism already, so can be adapted | ||
Revision as of 17:05, 14 November 2013
We're getting together at the annual CCC conference, 30C3, for a sigrok hackathon. In addition to the usual "whatever we feel like hacking on", we also have several architectural decision to make, and doing this in person is a lot easier. If you want to be part of the conversation and decision-making process, show up!
In addition to the 4 days of the congress, we will also get together the day before (26 December 2013) for a hopefully less crowded and more productive day. Venue is not yet decided.
What's decided here is what goes.
- To sr_filter_probes() or not, that is the question.
- frontends have probe location info, they pass it to sr_filter_probes() after all
- very nice for output modules: avoids having to map probe location to bit on all the modules
- waste of time for PV, which will soon do its own reformatting of logic data anyway
- SRD currently needs it, but has a probe mapping mechanism already, so can be adapted