Difference between revisions of "34C3"
| Line 31: | Line 31: | ||
Currently, plans are to make PV have a modularized internal structure and use flowgraphs internally to gather experience and have something working | Currently, plans are to make PV have a modularized internal structure and use flowgraphs internally to gather experience and have something working | ||
[2017-12-27] | [2017-12-27/28] | ||
This is what we have: | This is what we have: | ||
* Martin wrote a python PoC for some flowgraph architecture ideas | * Martin wrote a python PoC for some flowgraph architecture ideas | ||
* Soeren found | * Soeren found usable flowgraph UI code: https://github.com/paceholder/nodeeditor | ||
This is what we want: | This is what we want: | ||
| Line 43: | Line 43: | ||
* One thread per source block, downstream blocks are called within the same thread | * One thread per source block, downstream blocks are called within the same thread | ||
* FIFO blocks that act like a buffer+source block, creating a new thread to allow decoupling | * FIFO blocks that act like a buffer+source block, creating a new thread to allow decoupling | ||
* Signal (connection between two blocks) types are modeled by hierarchical C++ classes, e.g. Analog;Logic->Uncompressed/RLE;Decode to allow type checking at runtime and easy "don't care" block inputs: if a block accepts Logic, can just tell the Logic base class to hand over RLE data without needing to worry about any conversions required to obtain it | |||
* libsigrokgui as a library that contains Qt-based UI elements used to build a basic sigrok client UI; at least a sigrok flowgraph UI window (including all necessary libsigrokflow interfacing) and trace drawing widgets | |||
This is how we'll do it: | This is how we'll do it: | ||
| Line 53: | Line 55: | ||
* Blocks have key/value properties, keys being strings allowing the object to provide descriptions as well | * Blocks have key/value properties, keys being strings allowing the object to provide descriptions as well | ||
* This way, we can get the https://sigrok.org/wiki/Improved_configuration_enumeration for free | * This way, we can get the https://sigrok.org/wiki/Improved_configuration_enumeration for free | ||
* libsigrokgui is needed because otherwise, we will never see full-featured UIs - the UI code would be too tightly coupled to PV; if not doing this, PV will be regarded as the universal sigrok client and see more and more feature creep | |||
This needs more thinking: | This needs more thinking: | ||
| Line 58: | Line 61: | ||
* How can blocks be made available at runtime? (i.e. device blocks) | * How can blocks be made available at runtime? (i.e. device blocks) | ||
* How do we handle device discovery? | * How do we handle device discovery? | ||
* Do new signal types need to be addable at runtime, e.g. for PD blocks that provide binary data (e.g. images or EEPROM dumps) or do we simply use a "binary" type with metadata as properties, e.g. a MIME type to identify the contents? | |||
== PV: Definition of scope == | == PV: Definition of scope == | ||
Revision as of 01:25, 29 December 2017
We're getting together at the annual CCC conference, 34C3, 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!
What's decided here is what goes.
New sigrok file format
What's missing to make it happen?
Discuss concepts for sparse data loading presented here: https://sourceforge.net/p/sigrok/mailman/message/25153496/
Handling of RLE data
What is needed to make libsigrok able to handle RLE data? Should there be a common format that drivers have to convert custom formats to? Should there be a new session bus packet type? What are the implications?
See also the discussion from 30C3 here.
Analog I/O for libsigrokdecode
What are the requirements/use cases? What's needed to make it happen?
Flowgraph architecture
How do we achieve this step-by-step? It won't ever happen if it's a huge change :) Currently, plans are to make PV have a modularized internal structure and use flowgraphs internally to gather experience and have something working
[2017-12-27/28] This is what we have:
- Martin wrote a python PoC for some flowgraph architecture ideas
- Soeren found usable flowgraph UI code: https://github.com/paceholder/nodeeditor
This is what we want:
- libsigrokflow as a core library that provides the basic flowgraph architecture elements (potentially re-usable by different projects)
- The same library allows libsigrok and libsigrokdecode to be tied into the flowgraph architecture
- Library code in C/C++ for speed and flexibility to allow blocks to be written in any language later on
- numpy BitArray-like data type for uncompressed data, allowing blocks to hand over BitArray objects if they don't change it ("it's a view on the raw data")
- One thread per source block, downstream blocks are called within the same thread
- FIFO blocks that act like a buffer+source block, creating a new thread to allow decoupling
- Signal (connection between two blocks) types are modeled by hierarchical C++ classes, e.g. Analog;Logic->Uncompressed/RLE;Decode to allow type checking at runtime and easy "don't care" block inputs: if a block accepts Logic, can just tell the Logic base class to hand over RLE data without needing to worry about any conversions required to obtain it
- libsigrokgui as a library that contains Qt-based UI elements used to build a basic sigrok client UI; at least a sigrok flowgraph UI window (including all necessary libsigrokflow interfacing) and trace drawing widgets
This is how we'll do it:
- We'll work on top and bottom levels at the same time
- Martin will work on the C/C++ framework for the library
- Uwe will set up the subproject on git once the library is in a usable state (no longer PoC status)
- Soeren will work on a basic flowgraph UI to get a feeling for the flowgraph UI lib, maybe as a throwaway PoC client
Extra thoughts:
- Blocks have key/value properties, keys being strings allowing the object to provide descriptions as well
- This way, we can get the https://sigrok.org/wiki/Improved_configuration_enumeration for free
- libsigrokgui is needed because otherwise, we will never see full-featured UIs - the UI code would be too tightly coupled to PV; if not doing this, PV will be regarded as the universal sigrok client and see more and more feature creep
This needs more thinking:
- How would a plugin mechanism work for the blocks?
- How can blocks be made available at runtime? (i.e. device blocks)
- How do we handle device discovery?
- Do new signal types need to be addable at runtime, e.g. for PD blocks that provide binary data (e.g. images or EEPROM dumps) or do we simply use a "binary" type with metadata as properties, e.g. a MIME type to identify the contents?
PV: Definition of scope
What is PV supposed to be? What is it not supposed to be?
We should define this so we can determine a sane architecture and prevent feature creep. The architecture for PV would need major extension if we also want to support power supplies and frequency generators to be able to do (cool) stuff like network analysis, bode plots, load tests, pattern/signal generation and similar. However, the question is: what is realistic and what is better left to more specialized clients? Turning PV into a one-size-fits-all client will be too much work for one person and progress will slow down.
PV: Scripting
Is it useful to have scripting available in PV? What use cases are there? Determine what would need to happen to support it.
PV: Decode table view
The decode table view isn't going to be very usable at the moment because it lacks metadata that libsigrokdecode should provide. We should discuss what the decode table view should offer in terms of functionality and what's needed in libsigrokdecode to make it happen.
PV: Scope UI
PV is getting closer and closer to being usable for analog scopes. We should discuss ideas how a UI could look like that allows for full remote-control operation. There are good and bad UI examples to draw ideas from.
PV: Create "wishlist" wiki page
Users don't know what features are planned and when. Soeren has his own (non-public) to-do list and there are some items in the bugzilla. This should be unified so that users can see what's planned and what's not on our radar yet.