diff --git a/CHANGELOG.md b/CHANGELOG.md index 68e54a2..b6d5bc5 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -7,3 +7,7 @@ The format is based on [Keep a Changelog](http://keepachangelog.com/) and this project adheres to [Semantic Versioning](http://semver.org/). # [unreleased] + +# [v0.1.0] 2024-09-11 + +Initial release diff --git a/Cargo.toml b/Cargo.toml index c3adfe2..8225fa2 100644 --- a/Cargo.toml +++ b/Cargo.toml @@ -20,6 +20,10 @@ crc = "3" smallvec = "1" derive-new = "0.6" +[dependencies.spacepackets] +version = "0.12" +default-features = false + [dependencies.thiserror] version = "1" optional = true @@ -32,10 +36,6 @@ optional = true version = "1" optional = true -[dependencies.spacepackets] -version = "0.12" -default-features = false - [dependencies.defmt] version = "0.3" optional = true diff --git a/README.md b/README.md index 716c669..0479568 100644 --- a/README.md +++ b/README.md @@ -13,7 +13,12 @@ The underlying base packet library used to generate the packets to be sent is th # Features -`cfdp-rs` supports various runtime environments and is also suitable for `no_std` environments. +The goal of this library is to be flexible enough to support the use-cases of both on-board +software and of ground software. It has support to make integration on [std] systems as simple +as possible, but also has sufficient abstraction to allow for integration on`no_std` environments. +Currently, the handlers still require the [std] feature until +[thiserror supports `error_in_core`](https://github.com/dtolnay/thiserror/pull/304). + It is recommended to activate the `alloc` feature at the very least to allow using the primary components provided by this crate. These components will only allocate memory at initialization time and thus are still viable for systems where run-time allocation is prohibited. diff --git a/src/lib.rs b/src/lib.rs index c358bee..b9bd698 100644 --- a/src/lib.rs +++ b/src/lib.rs @@ -11,8 +11,17 @@ //! even for unreliable connections, including lost segment detection. As such, it can be compared //! to a specialized TCP for file transfers with remote systems. //! -//! The core of these high-level components are the [crate::dest::DestinationHandler] and the -//! [crate::source::SourceHandler] component. These model the CFDP destination and source entity +//! The goal of this library is to be flexible enough to support the use-cases of both on-board +//! software and of ground software. It has support to make integration on [std] systems as simple +//! as possible, but also has sufficient abstraction to allow for integration on `no_std` +//! environments. Currently, the handlers still require the [std] feature until +//! [thiserror supports `error_in_core`](https://github.com/dtolnay/thiserror/pull/304). +//! It is recommended to activate the `alloc` feature at the very least to allow using the primary +//! components provided by this crate. These components will only allocate memory at initialization +//! time and thus are still viable for systems where run-time allocation is prohibited. +//! +//! The core of this library are the [crate::dest::DestinationHandler] and the +//! [crate::source::SourceHandler] components which model the CFDP destination and source entity //! respectively. You can find high-level and API documentation for both handlers in the respective //! [crate::dest] and [crate::source] module. //! @@ -20,9 +29,6 @@ //! //! This library currently features two example application which showcase how the provided //! components could be used to provide CFDP services. -//! Both examples feature implementations of the [UserFaultHookProvider] and the [user::CfdpUser] -//! trait which simply print some information to the console to monitor the progress of a file -//! copy operation. //! //! The [end-to-end test](https://egit.irs.uni-stuttgart.de/rust/cfdp/src/branch/main/tests/end-to-end.rs) //! is an integration tests which spawns a CFDP source entity and a CFDP destination entity, @@ -43,6 +49,20 @@ //! The [Python Interoperability](https://egit.irs.uni-stuttgart.de/rust/cfdp/src/branch/main/examples/python-interop) //! example showcases the interoperability of the CFDP handlers written in Rust with a Python //! implementation. The dedicated example documentation shows how to run this example. +//! +//! # Notes on the user hooks and scheduling +//! +//! Both examples feature implementations of the [UserFaultHookProvider] and the [user::CfdpUser] +//! trait which simply print some information to the console to monitor the progress of a file +//! copy operation. These implementations could be adapted for other handler integrations. For +//! example, they could signal a GUI application to display some information for the user. +//! +//! Even though both examples move the newly spawned handlers to dedicated threads, this is not +//! the only way they could be scheduled. For example, to support an arbitrary (or bounded) +//! amount of file copy operations on either source or destination side, those handlers could be +//! moved into a [std::collections::HashMap] structure which is then scheduled inside a thread, or +//! you could schedule a fixed amount of handlers inside a +//! [threadpool](https://docs.rs/threadpool/latest/threadpool/). #![no_std] #![cfg_attr(docsrs, feature(doc_auto_cfg))] #[cfg(feature = "alloc")]