greencontrol/1.0/bare
| Package | greencontrol |
|---|---|
| Version | 1.0-gs1 |
| gspkgname | greencontrol |
| gspkgversion | 1.0 |
| gspkgvariation | bare |
| Section | electronics |
| Priority | optional |
| Architecture | all |
| Pre-Depends | debconf |
| Depends | greenbus-virtual | greenbus |
| Provides | greencontrol-virtual |
| Installed-Size | 38040 |
| Maintainer | GreenSocs |
| Description | GreenSocs Control Framework |

Change Log GreenConfig: http://www.greensocs.com/en/projects/GreenControl/GreenConfig/docs/GCnfDevelopmentNotes/ChangeLog
Change Log GreenAV: http://www.greensocs.com/en/projects/GreenControl/GreenAV/docs/GAVDevelopmentNotes/ChangeLog
Compatible to GreenBus release 1.1 http://www.greensocs.com/en/node/1996
GreenConfig v. 1.0
- gs_param constructors: added force_top_level_name bool to allow arbitrary parameter names
- constructors of gs_param_base, gs_param_t<T> and gs_param<t> slightly changed
- gs_param, gs_param_array: added constructors getting parent array references (not only pointers)
- marked GCnf_Api::getNewParamEvent as deprecated, use callback mechanism instead
- iterator of gs_param_array returns pointer to member instead of reference
- gs_param template specializations (user and provided ones) need to implement a static deserialize function instead of a non-static one.
- Added GCnf_Api and gs_param_base function get_gs_param<T> returning a casted gs_param (see details).
- Added GCnf_Api and gs_param_base functions getValue<T> returning the value (independent of implicit or explicit status) (see details).
- Added API-Plugin command CMD_GET_VAL to get the implicit or explicit parameter value (as string).
- gs_params now may be used/instantiated at top-level. They are named without any prefix.
- All GCnf_Api calls now are allowed to get non-hierarchical parameter names (to allow top-level parameters).
- moved example demonstration_platform_0.3 -> demonstration_platform and mixed_tests_0.3 -> mixed_tests
- New coding rule: use gs::cnf::GCnf_Api::getApiInstance(module_ptr) instead of creating an own GCnf_Api instance!
- Use interface gs::cnf::cnf_api to store and access GCnf_Api pointers returned by getApiInstance(mod):
gs::cnf::cnf_api *mApi = gs::cnf::GCnf_Api::getApiInstance(this); - gcnf_api_if renamed to initialize_if (and file renamed)
- GCnf_Api header file moved (old one deprecated): use greencontrol/gcnf/apis/GCnf_Api/GCnf_Api.h
- gs_param<*array>: Array size implicitly set during construction according to the implicit member params in the database.
- Array at() 'operator' does automatically resize if member no (yet) existing.
Details
New parameter constructors taking forced top-level names and
Parameter names allow delimiters ('.'):
Parameter constructors now have an optional bool switch which forces the parameter name to be exactly like the submitted name. No prefix (parent's name) is attached. Some example constructors (many more are available):
- gs_param(string name, string/type value, bool force_top_level_name);
- gs_param(string name, string/type value, bool force_top_level_name);
- gs_param(string name, string/type value, parent_array, bool force_top_level_name);
- gs_param<int> myparam1("anyTopLevelName", 10, true);
- gs_param<int> myparam2("anyTopLevelName.hierarchicalparam", 20, true);
- gs_param<int> myparam3("anyHieraryName.subHierarchy.hierarchicalparam", 30);
myparam2 will be named "anyTopLevelName.hierarchicalparam" and NOT "mymodule.anyTopLevelName.hierarchicalparam".
myparam2 will be named "mymodule.anyHieraryName.subHierarchy.hierarchicalparam".
New parameter constructors getting parent array references:
Parent parameter arrays now may be given as references to the created parameter (or array):
- gs::gs_param_array pararr("TestArray");
- gs::gs_param<int> arrMember1("parname1", 42, pararr); // take reference
- gs::gs_param<int> arrMember2("parname2", 42, ¶rr); // take pointer
Access implicit (or explicit) values without using the parameter object itself:
- bool cnf_api::getValue<T>(const std::string &parname, T &value)
- int i;
- bool success = myApi->getValue<int>("modA.int_param", i);
- T cnf_api::getValue<T>(const std::string &parname)
- int i = myApi->getValue<int>("modA.int_param");
Get a gs_param object instead of a gs_param_base object:
- gs_param<T>* cnf_api::get_gs_param<T>(const std::string &parname) (may be used instead of cnf_api::getPar(parname))
- gs_param<unsigned int> *par = myApi->get_gs_param<unsigned int>("modA.uint_par");
gs_param_array iterator returns pointer to member;
Changed from (*it).getString() to (*it)->getString()
- gs::gs_param_array::iterator it;
- for (it = topArr.begin(); it != topArr.end(); ++it) {
- }
GreenAV v. 1.0
- output plugin 'enabled parameters' allowing observing parameters simply by creating and modifying parameters
- added OutputPlugin init functionality to allow creation without much memory allocations before being used
- changed OutputPlugin_base constructor (for naming)
- renamed OutputPlugin functions:
- observe_param -> observe
- dont_observe_param -> remove
- pause_output -> pause
- start_output -> resume
- added GAV_Api::get_default_output (see details)
- renamed OutputPlugin type enums to NULL_OUT, TXT_FILE_OUT, STDOUT_OUT, CSV_FILE_OUT, SCV_STREAM_OUT
- added simulation-wide default output plugin (see details)
- added 'activated' parameter for StatCalc objects to access and modify its activation status (see details)
Details
'Enabled' parameters for output plugins:
Observe parameters by creating and manipulating parameters belonging to special output plugins:
To enable the observation of a parameter (which may be already existing or may not), create a new implicit parameter which is a child parameter of the output plugin and is named as the parameter that should be observed. This comes clear in the following example:
- The GAV Plugin is named AnalysisPlugin.
- The output plugin which should observe the parameter is the default stdout one, automatically named STDOUT_OUT_default.
- The parameter that should be observed is named mymodule.submodule.myparam.
- To observe the parameter with the output plugin, simply create a so-called enabled parameter (child of the output plugin) named AnalysisPlugin.STDOUT_OUT_default.mymodule.submodule.myparam by doing the following call on the config user API:
-
mCnfApi->setInitValue("AnalysisPlugin.STDOUT_OUT_default.mymodule.submodule.myparam", "true"); - The output plugin will automatically make the implicit parameter explicit immediately.
-
- Afterward you can enable and disable the observation of the parameter by modifying the 'enabled parameter' to true or false, e.g.
- gs::gs_param<bool> *enabled = mCnfApi->get_gs_param<bool>("AnalysisPlugin.STDOUT_OUT_default.mymodule.submodule.myparam");
- *enabled = false;
Simulation-wide default output plugin:
A simulation-wide default output plugin type should be set by the user during construction. Any module that is not interested in a special output type should output its parameters to this default output.
Specify the default during construction:
gs::av::GAV_Plugin analysisPlugin("AnalysisPlugin", gs::av::STDOUT_OUT);
Output to the default output:
mGAVApi->add_to_default_output(param_for_default_op);
Get the default output plugin by calling
OutputPlugin_if* get_default_output()
'Activated' parameter for StatCalc:
The activation status of the trigger can be accessed and manipulated with the parameter < statcalc name >.activated which is returned by the function
- gs_param<bool>* get_activated_param();
or can be accessed using the config API:
- mCnfApi->getPar(<statcalc name>.activated);
Posted June 10th, 2008 by ChristianSchroeder