Difference between revisions of "30C3"

From sigrok
Jump to navigation Jump to search
Line 1: Line 1:
We're getting together at the annual CCC conference, [https://events.ccc.de/congress/2013/wiki/Main_Page 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!
We're getting together at the annual CCC conference, [https://events.ccc.de/congress/2013/wiki/Main_Page 30C3], for a [https://events.ccc.de/congress/2013/wiki/Assembly:Sigrok 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.
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.

Revision as of 18:01, 27 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?
  • Testing
    • automated unit tests on commit (SR and SRD)
    • VMs for *BSD, linux dists on kiutl for automated build/unit tests
    • VMs with connected hardware (bert and uwe)?