Difference between revisions of "30C3"
Jump to navigation
Jump to search
| Line 13: | Line 13: | ||
** 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 | ||
* Rethinking how we enumerate and assign drivers to hardware | * Rethinking how we enumerate and assign drivers to hardware | ||
** Device tree model | ** Pre-scan for all resources such as serial ports & USB devices | ||
** How users/frontends resolve ambiguity | |||
** How to handle "gateway" devices such as GPIB adapters, networked servers with instruments, etc. | |||
** Device tree model? | |||
Revision as of 14:59, 20 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.
- New sigrok file format
- Improved Configuration Enumeration
- 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
- Rethinking how we enumerate and assign drivers to hardware
- Pre-scan for all resources such as serial ports & USB devices
- How users/frontends resolve ambiguity
- How to handle "gateway" devices such as GPIB adapters, networked servers with instruments, etc.
- Device tree model?