rccn-gen 1.1.0__tar.gz → 1.3.0__tar.gz

{rccn_gen-1.1.0 → rccn_gen-1.3.0}/.gitignore

@@ -2,7 +2,7 @@
 *.DS_Store
 *.ipynb
 *.pyc
-venv/
+.venv/
 examples/
 tests/
 *.diff
@@ -15,7 +15,7 @@ __pycache__/
 *.xml
 *.whl
 *.egg-info/
-/dist
+dist/
 rccn_usr_com_app/Cargo.toml
 .rccn_diffs/
 .rccn_snapshots/

rccn_gen-1.3.0/CHANGELOG.md

@@ -0,0 +1,34 @@
+# CHANGE LOG
+
+## [1.3.0] - 2025-05-15
+- Added methods to the RCCNContainer class to directly add parameters
+- Added documentation for Application, Service, RCCNCommand and RCCNContainer classes
+- Added support for Float datatype Rust generation in Arguments and ParameterEntries
+
+## [1.2.0] - 2025-05-05
+- Added argument hints for RCCNCommand, Service and RCCNContainer
+- New create_and_add_service() method for the Application
+- New create_and_add_command() method for the Service
+- Better error messages
+- Subtypes of RCCNCommands and RCCNContainers are defined automatically, if not specified by the user
+- General refactoring for more readable code
+- Added add_integer_parameter method to RCCNContainer
+- Bug fixes
+
+### [1.1.2] - 2025-04-23
+- The `export_directory` argument for the `Application` is now mandatory.  
+
+### [1.1.1] - 2025-04-22
+- Changed the user input checking to allow for multiple command with the same name and subtype, as long as they are associated to different services.
+
+## [1.1.0] - 2025-04-14
+- Added derive statements to the rust container structs in the telemetry.rs file.
+- Inherit subtype of a container from the `condition` argument, if given, or from the new (optional) `subtype` argument. If only the latter is given, condition is created from that. Subtype is included in the derive statements.
+- Added missing `use anyhow::Result` import and bug fixes in `main.rs` file. 
+- Added new dependencies in `cargo.toml` file.
+- Changed names of command structs to differentiate between trait names and struct names. 
+- Include bit number statement in enum declaration.
+- The `tc` parameter in the service.rs file is now mutable.
+- `System` of a command is obtained from the base command, if no system argument is given.
+- Added support for long and short descriptions of commands, arguments and supported telemetry parameters.
+- Bug fixes.

{rccn_gen-1.1.0 → rccn_gen-1.3.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: rccn_gen
-Version: 1.1.0
+Version: 1.3.0
 Summary: A python based generator for RACCOON OS source files in Rust from yamcs-pymdb config files.
 Project-URL: Homepage, https://gitlab.com/rccn/pymdb_code_generation
 Project-URL: Issues, https://gitlab.com/rccn/pymdb_code_generation/issues
@@ -29,10 +29,11 @@ To see whats new, see the [CHANGELOG](CHANGELOG.md).
 ## Using the Generator
 The generator is based on [`pymdb`](https://github.com/yamcs/pymdb) and uses the same structure. Where `pymdb` gives the user freedom in defining systems, subsystems and their respective relations, the definitions for rust code generation is more restricted. For the rust generation, the user is bound to the following classes:
 - `Application`,
-- `Service`, and
-- `RCCNCommand`.
+- `Service`,
+- `RCCNCommand`, and
+- `RCCNContainer`.
 
-All classes inherit from pymdb's Subsystem class and extend their functionality. This means that an existing pymdb definition can be used to generate rust code by renaming the respective instances. No functionality for pymdb's XTCE generation will be lost. 
+The Application and Service classes inherit from pymdb's Subsystem class and extend their functionality. The RCCNCommand extends the Command class and the RCCNContainer extends the Container class of pymdb. This means that an existing pymdb definition can be used to generate rust code by renaming the respective instances. No functionality for pymdb's XTCE generation will be lost. 
 
 A root system may be defined for the satellite.
 ```python
@@ -44,7 +45,7 @@ An application can be defined with the following statement.
 ```python
 app = Application(system=root_system, name="ExampleApp", apid=42)
 ```
-It has the obligatory arguments **system**, **name** and **apid**. After all Applications, Services and RCCNCommands are defined, the rust code generator can be called on the application with `app.generate_rccn_code()`.
+It has the obligatory arguments **system**, **name** and **apid**. After all Applications, Services and RCCNCommands are defined, the rust code generator can be called on the application with `app.generate_rccn_code(export_directory='.')`.
 
 ### Service
 
@@ -81,7 +82,7 @@ my_command = RCCNCommand(
 service.add_command(my_command)
 ```
 
-The only obligatory arguments are **name** and a **subtype assignment**, like shown in the example. The connection to a service can also be achieved with base commands, where every base command must be unique to a service. For example:
+The only obligatory argument is **name**. If the subtype assignment is not given, a value will be chosen automatically. The connection to a service can also be achieved with base commands, where every base command must be unique to a service. For example:
 
 ```python
 base_cmd = RCCNCommand(
@@ -98,6 +99,34 @@ my_command = RCCNCommand(
 )
 ```
 
+### RCCNContainer
+A container to hold telemetry information can be created with:
+```python
+my_container = RCCNContainer(
+    system=service,
+    name='BatteryInformation',
+    short_description='This container holds information on battery voltage and current'
+)
+my_container.add_integer_parameter_entry(
+    name='BatteryNumber',
+    minimum=1,
+    maximum=4,
+    encoding=IntegerEncoding(bits=3),
+    short_description='Number of the battery'
+)
+my_container.add_float_parameter_entry(
+    name='Current',
+    units='Ampere',
+    encoding=FloatEncoding(bits=32),
+    short_description='Electric current of the battery.'
+)
+my_container.add_float_parameter_entry(
+    name='Voltage',
+    units='Volts',
+    encoding=FloatEncoding(bits=32),
+    short_description='Electric voltage of the battery.'
+)
+```
 ## Output
 From the python configuration, the `main.rs`, `service.rs`, `command.rs`, `mod.rs`, `Cargo.toml` and `telemetry.rs` files are generated and are structured accordingly:
 - rccn_usr_example_app/
@@ -155,4 +184,4 @@ Snapshots of the .rs files in the export directory are stored in `/user/`. These
 app.keep_snapshots = 15 # Whatever value you want
 ```
 
-With the sequence from above, it becomes apperant that changes to the .rs file in the export directory always trump changes to the pymdb config. If for example, a main.rs file is generated for an application with and APID of 42, and this apid is changed in the main.rs file to 45, this change will persist after regenerating from the python config. Even if changes to the pymdb config where made after the changes to the main.rs file. 
+With the sequence from above, it becomes apperant that changes to the .rs file in the export directory always trump changes to the pymdb config. If for example, a main.rs file is generated for an application with and APID of 42, and this apid is changed in the main.rs file to 45, this change will persist after regenerating from the python config. Even if changes to the pymdb config where made after the changes to the main.rs file. 

{rccn_gen-1.1.0 → rccn_gen-1.3.0}/README.md

@@ -13,10 +13,11 @@ To see whats new, see the [CHANGELOG](CHANGELOG.md).
 ## Using the Generator
 The generator is based on [`pymdb`](https://github.com/yamcs/pymdb) and uses the same structure. Where `pymdb` gives the user freedom in defining systems, subsystems and their respective relations, the definitions for rust code generation is more restricted. For the rust generation, the user is bound to the following classes:
 - `Application`,
-- `Service`, and
-- `RCCNCommand`.
+- `Service`,
+- `RCCNCommand`, and
+- `RCCNContainer`.
 
-All classes inherit from pymdb's Subsystem class and extend their functionality. This means that an existing pymdb definition can be used to generate rust code by renaming the respective instances. No functionality for pymdb's XTCE generation will be lost. 
+The Application and Service classes inherit from pymdb's Subsystem class and extend their functionality. The RCCNCommand extends the Command class and the RCCNContainer extends the Container class of pymdb. This means that an existing pymdb definition can be used to generate rust code by renaming the respective instances. No functionality for pymdb's XTCE generation will be lost. 
 
 A root system may be defined for the satellite.
 ```python
@@ -28,7 +29,7 @@ An application can be defined with the following statement.
 ```python
 app = Application(system=root_system, name="ExampleApp", apid=42)
 ```
-It has the obligatory arguments **system**, **name** and **apid**. After all Applications, Services and RCCNCommands are defined, the rust code generator can be called on the application with `app.generate_rccn_code()`.
+It has the obligatory arguments **system**, **name** and **apid**. After all Applications, Services and RCCNCommands are defined, the rust code generator can be called on the application with `app.generate_rccn_code(export_directory='.')`.
 
 ### Service
 
@@ -65,7 +66,7 @@ my_command = RCCNCommand(
 service.add_command(my_command)
 ```
 
-The only obligatory arguments are **name** and a **subtype assignment**, like shown in the example. The connection to a service can also be achieved with base commands, where every base command must be unique to a service. For example:
+The only obligatory argument is **name**. If the subtype assignment is not given, a value will be chosen automatically. The connection to a service can also be achieved with base commands, where every base command must be unique to a service. For example:
 
 ```python
 base_cmd = RCCNCommand(
@@ -82,6 +83,34 @@ my_command = RCCNCommand(
 )
 ```
 
+### RCCNContainer
+A container to hold telemetry information can be created with:
+```python
+my_container = RCCNContainer(
+    system=service,
+    name='BatteryInformation',
+    short_description='This container holds information on battery voltage and current'
+)
+my_container.add_integer_parameter_entry(
+    name='BatteryNumber',
+    minimum=1,
+    maximum=4,
+    encoding=IntegerEncoding(bits=3),
+    short_description='Number of the battery'
+)
+my_container.add_float_parameter_entry(
+    name='Current',
+    units='Ampere',
+    encoding=FloatEncoding(bits=32),
+    short_description='Electric current of the battery.'
+)
+my_container.add_float_parameter_entry(
+    name='Voltage',
+    units='Volts',
+    encoding=FloatEncoding(bits=32),
+    short_description='Electric voltage of the battery.'
+)
+```
 ## Output
 From the python configuration, the `main.rs`, `service.rs`, `command.rs`, `mod.rs`, `Cargo.toml` and `telemetry.rs` files are generated and are structured accordingly:
 - rccn_usr_example_app/
@@ -139,4 +168,4 @@ Snapshots of the .rs files in the export directory are stored in `/user/`. These
 app.keep_snapshots = 15 # Whatever value you want
 ```
 
-With the sequence from above, it becomes apperant that changes to the .rs file in the export directory always trump changes to the pymdb config. If for example, a main.rs file is generated for an application with and APID of 42, and this apid is changed in the main.rs file to 45, this change will persist after regenerating from the python config. Even if changes to the pymdb config where made after the changes to the main.rs file. 
+With the sequence from above, it becomes apperant that changes to the .rs file in the export directory always trump changes to the pymdb config. If for example, a main.rs file is generated for an application with and APID of 42, and this apid is changed in the main.rs file to 45, this change will persist after regenerating from the python config. Even if changes to the pymdb config where made after the changes to the main.rs file. 

{rccn_gen-1.1.0 → rccn_gen-1.3.0}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "rccn_gen"
-version = "1.1.0"
+version = "1.3.0"
 authors = [
   { name="Fabian Krech", email="f.krech@tu-berlin.de" },
 ]