Although the Cmake rules to build Rust applications keeps the target
directory inside of the build directory, some IDE tools may generate a
target directory while editing the code. Ignore these so they never get
checked in.
Signed-off-by: David Brown <david.brown@linaro.org>
Rustc for RISCV encodes optional features on the CPU available as part
of the target tuple. Clang, on the other hand does not. In order to be
able to use libclang with bindgen on RISCV, we need to simplify the
target tuples a bit. Do this by just matching 'riscv32' or 'riscv64'
and then passing in a generic tuple. We aren't generating any code, and
the structs should always match between the targets.
Signed-off-by: David Brown <david.brown@linaro.org>
GCC automatically defines a `__SOFTFP__` define on targets that are
using software floating point. The clang compiler does not do this by
default, so check this, and define it.
Signed-off-by: David Brown <david.brown@linaro.org>
This reverts commit 2046760e71.
Put these back so we get the zero element structures when using just
rust and not CPP. A subsequent patch will suppress the warning.
Signed-off-by: David Brown <david.brown@linaro.org>
Zephyr takes advantage of a gcc/clang extension that allows structs that
have no elements. Rust is perfectly happy with this (it is quite common
in Rust code), but generates a warning when a struct containing no
elements is passed to C code.
For now, suppress this warning on the generated bindings. This has the
disadvantage of suppressing it entirely, which might possibly detect
other cases of invalid structs. However, the bindings are
auto-generated from C structs so should always be valid.
Signed-off-by: David Brown <david.brown@linaro.org>
Re-export all of the bindgen generated bindings in the zephyr-sys crate
into `zephyr::raw`. This keeps things easier, as users of `zephyr` only
need to worry about the single `zephyr` crate.
Signed-off-by: David Brown <david.brown@linaro.org>
Change the header passed into bindgen to be an absolute path. This will
cause the generated wrapper to refer to this file also using an absolute
path. As such, remove the explicit include path added as part of the
build.
Signed-off-by: David Brown <david.brown@linaro.org>
When compiling Rust programs, the bindgen utility generates a wrapper file
to expand inline functions, as these otherwise cannot be accessed from
rust. Pass a consistent name to the cargo build, and add it to our source
build so that this wrapper get compiled.
Signed-off-by: David Brown <david.brown@linaro.org>
For CPP builds, a few structs that end up empty in some configurations will
generate compile errors. With the Rust tools, bindgen ends up producing
empty structsw for these as well. Although the code compiles, it generates
warnings. For now, add CONFIG_RUST to the ifdef checks so that these
structs don't end up empty with Rust either.
Signed-off-by: David Brown <david.brown@linaro.org>
Instead of trying to manually generate the bindings, use those generated by
bindgen in the zephyr-sys crate.
Signed-off-by: David Brown <david.brown@linaro.org>
With a lot of work done by Mario Jaun <mario.jaun@zuehlke.com>.
Use the rust-bindgen tool to extract bindings from the Zephyr header files.
The tool is run with the exact configuration of the current build, and
therefore the bindings will match the current target. The ifdefs and such
are not translated into the Rust code, and this must be generated live for
each build.
Signed-off-by: David Brown <david.brown@linaro.org>
Rename the sample to just hello world. As long as the actual sample
name is different, there won't be index conflicts in the documentation.
Signed-off-by: David Brown <david.brown@linaro.org>
Apply the rules to ignore some cargo generated or used files to the
whole tree, not just the samples.
Signed-off-by: David Brown <david.brown@linaro.org>
We use the `#[cfg(...)]` directive in rust to pass Kconfig values through.
Because it is possible for the code to depend on a Kconfig value that isn't
present in a given build, there isn't a way for us to tell the Rust
toolchain about all possible config values.
For now, just disable this warning entirely. This functionality could be
supported by the patch validation scripts, which seems like a better place
than trying to gather a list of all possible configs at build time.
Signed-off-by: David Brown <david.brown@linaro.org>
Add initial docs for Rust language support. Explains the support
currently present, how to install the toolchain needed, and explains
what is in the current sample.
Signed-off-by: David Brown <david.brown@linaro.org>
Create the Rust equivalent of the hello_world application. This shows
the use of printk from Rust as well as accessing a string value from
Kconfig.
Signed-off-by: David Brown <david.brown@linaro.org>
When `CONFIG_PRINTK` is enabled, provide macros `printk` and `printkln`
within the `zephyr` crate that applications can use to print. This
currently sends messages, with a small amount of buffering, using
`k_str_out`.
Until C functions are made generally available from the Rust side,
we use a small wrapper function to call `k_str_out`, as it is
implemented as an inline syscall.
Signed-off-by: David Brown <david.brown@linaro.org>
This provides the function `rust_cargo_application()` within Cmake to
give applications written in Rust a simple way to start.
This implements the basic functionality needed to build a rust
application on Arm, including target mapping, and invoking cargo during
the build.
Most of the functionality is about passing the appropriate flags to
`cargo`, which is used to perform the actual build of the rust code.
Cargo generates `librustapp.a` which is added to the link dependencies
for the application.
The cargo rule is written such that cargo will always be built (provided
`app` is being built), as there will be complex dependencies on the
cargo side. Cargo will not modify the `librustapp.a` file if nothing
needs to be build, so this will generally be fast if there are no
changes to files that affect the Rust build.
Signed-off-by: David Brown <david.brown@linaro.org>
This is the initial Zephyr-specific crates that provide support for Rust
on Zephyr. Currently, what they do is fairly minimal, but important.
`zephyr-build` is a build time crate (linked against the `zephyr`
crate's build.rs) that processes the current build's Kconfig settings,
and does three things with them:
- Boolean Kconfig values given given to the Rust toolchain so that
conditional compilation can be based off of them.
- Numeric Kconfig settings end up as constants in `zephyr::kconfig`.
- String valued Kconfig settings end up as constants in
`zephyr::kconfig`.
None of these cause code or data to be generated or allocated (but note
that if there is a reference to a string, that string will be placed in
read-only memory).
The `zephyr` crate is built for the target, and intended to be
referenced by the application. It provides minimal support needed for a
"bare" Rust build, notably a panic handler. At this point, the panic
handler is not implemented as we need better support for calling into
Zephyr's C code, so it just stops in an infinite loop.
It also ensures that `CONFIG_RUST` is set as a sanity check, and
includes the generated kconfig.rs file with the kconfig definitions for
the current build.
Signed-off-by: David Brown <david.brown@linaro.org>
Until further variants are needed, this provides a `main()` function
that simply calls into the `rust_main()` function. This is adequate for
applications where main can be directly written in Rust.
The reason that this is written here, rather than just writing `main`
directly in Rust is that `kernel/main_weak.c` provides a weak default
implementation that will be brought in before the Rust application's
`main` is linked in.
Signed-off-by: David Brown <david.brown@linaro.org>
Add the `CONFIG_RUST` Kconfig. This can be set to indicate that an
application wishes to use Rust support.
Adds `CONFIG_RUST_SUPPORTED` to indicate what platforms Rust is known to
work on. This is set to the targets that are supported by subsequent
commits.
Signed-off-by: David Brown <david.brown@linaro.org>
The twister workflow contains two references to the docker image to use.
The earlier change only updated one of these. Update the other to
match. This should allow rust code to be built in the whole twister
workflow.
Signed-off-by: David Brown <david.brown@linaro.org>
Add cargo's bin to the path, and print out the versioning of the tool to
make it easy to ensure the right version has been installed.
Signed-off-by: David Brown <david.brown@linaro.org>
There was hardcoded value for user_data which is no longer valid.
Use proper CONFIG_BT_CONN_TX_USER_DATA_SIZE for that.
Signed-off-by: Szymon Janc <szymon.janc@codecoup.pl>
Fix warnings generated when performing sensor drivers build test
due to typos in i2c DT definition.
Signed-off-by: Armando Visconti <armando.visconti@st.com>
All the network related shell activities should be under
network shell so moving it to "net bridge ..." command.
Add this information to migration guide.
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
Remove the references to the breathe extension in the
Schematic of the documentation build process graph and
the filtering expected warnings section.
Signed-off-by: Simon Hein <Shein@baumer.com>
The generated HTML was broken, even though the rst files themselves
contained the correct URLs. Update to a different format which should
generate the right output.
Signed-off-by: Johan Hedberg <johan.hedberg@silabs.com>
set high_bandwidth and use the cfg->mps to set
ep_init.maxPacketSize because NXP MCUX controller
driver supports additional transaction bits in
maxPacketSize.
Signed-off-by: Mark Wang <yichang.wang@nxp.com>
Instead, use the helper to get the size field from the MPS value.
MPS value may contain information about additional transaction
per microframe (bits 12..11).
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
