This is the packaged crate combining different RusPiRo crates into one library. The library can be configured with feature gates
and allowes a more convinient usage pattern for the dependencies in your Cargo.toml file. See the details and usage patterns
below...
To use the crate just add the following dependency to your Cargo.toml file. The components of the sdk crate could be configured using feature gates. The most important one is to set the ruspiro_pi3 feature to enable compiling the peripheral address space and Raspberry Pi 3 specific components successfully.
[dependencies]
ruspiro-sdk = { version = "0.1.0", features = ["ruspiro_pi3"]
The always usable crates are:
Additional features/crates are:
| Feature | Default | Description |
|--------------------|---------|-------------|
| with_boot | yes | Bundle the ruspiro-boot crate into the sdk package providing Raspberry Pi boot code.|
| with_allocator | yes | Bundle the ruspiro-allocator crate into the sdk package|
| with_console | no | Bundle the ruspiro-console crate into the sdk package. This requires an allocator to be present. |
| with_uart | no | Bundle the ruspiro-uart crate into the sdk package. This will always bundle ruspiro-console and does also require an allocator to be present.|
| with_i2c | no | Bundle the ruspiro-i2c crate into the sdk package. This requires an allocator to be present. |
The following sections give some guidance how the ruspiro-sdk might be utilized. Each scenario provides an example
that could be found in the sub-folders mentioned in the respective chapter. Those examples should build just fine and could
be used as starting point for your own projects.
This scenario is the proposed entry point in using the RusPiRo SDK the first time. In this scenario the ruspiro-sdk
will be used with the set of default features only.
Find the whole crate structure here: Scenario-1
This advanced scenario is intended for those who either already have their own boot assembly or do want to write their own one.
Additionally some other core requirements to successfully build a binary when not using the ruspiro-boot need to be fulfilled:
1. provide a panic handler and a ehpersonality function.
2. provide unwind stubs:
- _aeabiunwindcpppr0
- _aeabiunwindcpppr1
- _UnwindResume
3. when using the ruspiro-allocator in this scenario the linker need to provide the two symbols:
- __heap_start
- __heap_end
indicating the physical memory address space of the heap.
This might be the most typical scenario to start with as it provides the functions to successfully initialize the Uart to be used as console output channel which makes "debugging" on the real hardware a bit easier. Find the whole crate structure here: Scenario-2
Licensed under Apache License, Version 2.0, (LICENSE or http://www.apache.org/licenses/LICENSE-2.0)