rune-rs/rune

Visit the site 🌐

Memory safe through Template literals πŸ“–

rune


- Read the book πŸ“–


An embeddable dynamic programming language for Rust.

Contributing

If you want to help out, there should be a number of optimization tasks available in Future Optimizations. Or have a look at Open Issues.

Create an issue about the optimization you want to work on and communicate that you are working on it.


Highlights of Rune

  • Clean Rust integration πŸ’».
  • Memory safe through reference counting πŸ“–.
  • Template literals πŸ“–.
  • Try operators πŸ“–.
  • Pattern matching πŸ“–.
  • Structs and enums πŸ“– with associated data and functions.
  • Dynamic vectors πŸ“–, objects πŸ“–, and tuples πŸ“– with built-in serde support πŸ’».
  • First-class async support πŸ“–.
  • Generators πŸ“–.
  • Dynamic instance functions πŸ“–.
  • Stack isolation πŸ“– between function calls.
  • Stack-based C FFI, like Lua's (TBD).

Rune scripts

You can run Rune programs with the bundled CLI:

cargo run --bin rune -- run scripts/hello_world.rn

If you want to see detailed diagnostics of your program while it's running, you can use:

cargo run --bin rune -- run scripts/hello_world.rn --dump-unit --trace --dump-vm

See --help for more information.

Running scripts from Rust

You can find more examples in the examples folder.

The following is a complete example, including rich diagnostics using termcolor. It can be made much simpler if this is not needed.

use rune::termcolor::{ColorChoice, StandardStream};
use rune::EmitDiagnostics as _;
use runestick::{Vm, FromValue as _, Item, Source};

use std::error::Error;
use std::sync::Arc;

#[tokio::main]
async fn main() -> Result<(), Box<dyn Error>> {
    let context = runestick::Context::with_default_modules()?;
    let options = rune::Options::default();

    let mut sources = rune::Sources::new();
    sources.insert(Source::new(
        "script",
        r#"
        pub fn calculate(a, b) {
            println("Hello World");
            a + b
        }
        "#,
    ));

    let mut diagnostics = rune::Diagnostics::new();

    let result = rune::load_sources(&context, &options, &mut sources, &mut diagnostics);

    if !diagnostics.is_empty() {
        let mut writer = StandardStream::stderr(ColorChoice::Always);
        diagnostics.emit_diagnostics(&mut writer, &sources)?;
    }

    let unit = result?;
    let vm = Vm::new(Arc::new(context.runtime()), Arc::new(unit));

    let mut execution = vm.execute(&["calculate"], (10i64, 20i64))?;
    let value = execution.async_complete().await?;

    let value = i64::from_value(value)?;

    println!("{}", value);
    Ok(())
}
Issues

Collection of the latest Issues

udoprog

udoprog

enhancement
Comment Icon0

Fields do not have any PrivMeta beyond their names (See PrivStructMeta), so their documentation strings are not being made publicly available following #408 and therefore cannot be walked in #412 (and eventually used in generated documentation).

@Xemiru this might be an interesting issue for you to work on.

scambier

scambier

bug
Comment Icon2

Hello, I've installed the extension, and configured it to set the full path to the rune-languageserver.exe. However, it looks like it's doing nothing, and I have literally 0 log from "Rune (Client)" in the Output window.

By "doing nothing" I mean that I have a .rn file open in vscode, with a few errors that go undetected. Syntax highlighting works, but that's it.

udoprog

udoprog

enhancement
Comment Icon0

This is a tracking issue for introducing a HIR for Rune.

This is currently done in the hir branch.

Why a HIR?

The intention here is to further decouple AST from code generation which should make it feasible to perform internal code generation to simplify the compiler.

As an example, all of these loop-style constructs currently have their own dedicated representation being processed by the assembler:

While loop:

Unconditional loop:

For loop:

With a HIR all of these could be "desugared" into the same loop construct rather than being fed into the assembler as distinct constructs, so the for loop would be desugared into something like:

This also has benefits for constant evaluation, since a HIR can be designed to be simpler to evaluate than directly evaluating AST.

I want to help out!

Great! This is an excellent issue that will improve the compiler for Rune and get you deep into its architecture. You couldn't have made a better choice!

To contribute, indicate what you want to do in this thread to coordinate, once you've done something that you want reviewed set up a pull request against the hir branch.

JohnnnyWang

JohnnnyWang

needs triage
Comment Icon1

Hi, I can't construct struct like this:

its will cause an error:

I know I must be doing something wrong, but I don't know how to debug and fix it.

Here is my rune code

ZhangHanDong

ZhangHanDong

thanks β™₯
Comment Icon0

Hi, I really like the design of this language, thanks for sharing your code, I learned a lot from it.

WechatIMG24143

udoprog

udoprog

enhancement
Comment Icon0

We currently only support matching over external structs, such as:

Which would allow for the following in Rune:

These are currently not supported, but both could and should be:

Tuple structs

In Rune:

Enum variants:

In Rune:

Implementation details

It is necessary to add getters for accessing fields of external types, because Rune has no other way of doing so. It's also a natural extension of how #[rune(get)] currently works. I.e. it permits external.field to work as intended.

This requires that field functions are extended to be capable of addressing the "numeric indexes" of tuples. Which is perfectly doable but would require additional APIs to Module. Similar to how we have Module::field_fn it might be appropriate to add Module::tuple_fn.

In order to support enums we also need additional ways to register enum metadata. in #384 we introduced Module::struct_meta which is used for registering the limited amount of metadata necessary to compile matches over structs. For enums this would have to be much more exhaustive. What we need it to register is:

  • A collection of all the variant names.
  • For each variant, if they are struct, tuple, or empty.
  • For struct variants, the names of its fields.
  • For tuple variants, how many items it has. E.g. Foo(a, b) has 2 items.
genusistimelord

genusistimelord

Comment Icon4

Maybe Add to Module to have Object call overrides than will run a set function for checks and returns similar to module.field_fn but as object_fn.

So maybe module.object_fn(Type_Npc , "obj", Npc::handle_object_lookup)?;

pub fn handle_object_lookup(&mut self, key: String) -> Value {}

So when someone calls

obj.x

then x will be sent as the key for lookup and return. this way we could lookup data and error it out if it doesn't Exist on the script side which would allow for slightly more dynamic structures. OR static Data returns that don't need to be pre-made or saved into the struct.

As request by "Granny Joe" on Discord. For more information or if I'm a bit wrong on what they are asking Ill link them here so they can fix anything missed in comments.

udoprog

udoprog

bug
Comment Icon0

A nested import where the item imported is the same as the module being imported causes import resolution to spin forever.

For example, like this:

What's probably causing this is that the last component in the import foo::foo is lazily registered in the namespace. And once we try to resolve it as the leading component in foo::foo it just tries to resolve itself.

udoprog

udoprog

enhancement
Comment Icon0

So we almost have all the support we need for benchmarks with the #[bench] attribute in order to replace all benchmarks that are currently written in Rust.

What's missing is the following:

  • Rune benches need to generate a compatible output.txt so that they work with https://rune-rs.github.io/rune/dev/bench
  • Rune benches need to process and present results better, so that among other things outliers are filtered and they can be presented in a manner similar to with cargo bench (or criterion).
udoprog

udoprog

enhancement
Comment Icon0

While working on cleanup for VmExecution it became apparent to me that it should be possible to re-use the same virtual machine in VmExecution.

VmExecution currently is essentially a stack of virtual machines - because the execution context might hop between various contexts and units in cases such as sharing Function objects across executions. But this stack of vms could potentially be replaced with a stack of context, unit, and instruction offsets. Everything needed to modify a single virtual machine.

Doing this means we can re-use a single stack of values even in complex execution environments which should be better for memory locality than multiple vms per execution each with their individual stacks.

pkolaczk

pkolaczk

bug
Comment Icon1

I registered a macro param in crate latte:

Then I can access that macro in the rune source by using fully qualified name:

However this results in the compile error:

And the following code causes Rune compiler to fall into an infinite loop:

pkolaczk

pkolaczk

enhancement
Comment Icon2

I noticed the parser parses function attributes:

Is there a way to define them to make them recognized? I'd like to be able to provide some metadata in the embedded rune script that would be read by the host app.

pkolaczk

pkolaczk

enhancement
Comment Icon1

My Rune script can call into the Rust host program and pass an Any object into it. I can do this:

However if I have many different types to handle, I guess a pattern match on type_hash() would be both more readable and probably faster (I guess the compiler can generate a constant-time jump-table instead of a series of comparisons). How do I use type_hash() in a pattern match? Unfortunately I can't because they are not constants.

So I thought that maybe they could be somehow made const functions? Rune generates them in a proc-macro, so I don't think there is anything preventing their values to be known at compile time.

Or maybe there could be some official way to do dynamic dispatch by type supported by the API directly?

lupan

lupan

enhancement
Comment Icon7

This is 2 different things which I have used many times in lua for more powerful dynamic object handling, simply the act of overloading what happens when you use either object.whatever and object["whatever"], I have used this many times to write dynamic message systems via internal templates to create fully runtime handled objects, this is horrible to use in rust due to fact its a lot of function calls, but in scripting langs it is quite simple and beautiful, for example:

in lua I usually override the index function on the userdata and make it simply run the set and get dynamic field functions, allowing me in lua to write this:

I realize this is possible using Object but that comes with 2 issues for me, one it doesn't handle if I try to access or create a field which isn't part of the msg, and it has to be parsed from and into the Object type, as for the dynamic struct system which is great, it requires the scripter to write the structs themselves.

p.s. this example above is purposely simple and far from what the optimized and expanded version would look like.

lupan

lupan

enhancement
Comment Icon1

The title is clear, I simply feel like it would be highly advantageous to have a section or even its own category regarding the default modules within the language, for example I was surprised to see std::bytes which I do admit is very useful, but considering the only reference I saw to it was within the example scripts; I was surprised to see it working perfectly well within the playground etc. side note, the field functions section does not include "copy"

lupan

lupan

enhancement
Comment Icon1

I wish to start by saying I think having a simple type system is all fair and good, however coming from using LUA as my scripting language within my rust projects: I do have needs for unsigned 64 bit literals for tasks; I understand it adds further complexity, but even if it is something that requires a prefix/suffix, I am happy enough with that; example being: let a = 18446744073709551615U;

Roba1993

Roba1993

enhancement
Comment Icon0

Hi all,

I'm switching from rhai to rune because of the async support of rune. One feature I'm really missing are global changeable variables.

In my case it's needed because I have up to 30 different inputs for the engine which all can change within the engine (by rhai code from the user) and need to be read out at the end again.

My actual workaround is to have a struct which is the input of each function and need to be the output. But this is not really user friendly and prevents additional use-cases where I want to return function specific data in addition.

tgolsson

tgolsson

enhancement
Comment Icon0

It'd be very nice to have an auto-formatter for Rune which can take a source-snippet and format it properly.

tgolsson

tgolsson

question
Comment Icon2

This is a topic I've been thinking about for a while based on the following observations:

  • Value conversions take an observable amount of time in flamegraphs
  • Function lookup and calling takes an observable amount of time
  • Untyped ISA leads to an interpreter with heavy branching and in a mixed workload there's a low likelihood that the branch predictor will work well

Thus, I'd like to propose a secondary compilation stage (or maybe deferring primary compilation). In this new mode of operation, every function call becomes a generic function over the input types. Invocation leads to monomoprhization over all input value types, including receiver.

Thus, code along the lines of

would compile the following code for Case A:

and the function call would reach this function and the interpreter execution would continue branch free. For the second case, we'd transform the current runtime error to a compilation/monomorphization error instead of a runtime error, and the final call will reuse the first compilation artifacts. This'd apply recursively, so monomorphized functions would end up calling other monomorphized, direct jump functions. This'd work for both native and Rune function calls.

There are some challenges here that I foresee, which share some overlap/complexities/incompatibilities with SSA IR. The biggest challenge by far is that not all code paths are created equal during invocation. Code that doesn't execute cannot be monomorphized, and we'll thus need to incrementally compile it as more code paths are explored. A function can therefore exist in three states: raw, partially monomoprhized, fully monomorphized, and no matter if these states are explicit or implicit we need to deal with them.

I still think this'd open up the door for a lot of other optimizations when no type information/function hashes/... needs to be looked up at runtime. Like SSA, it will likely be more impactful for a register machine than a stack machine, but either approach should benefit. I think that straight out of the box we'd see improvements for points 2 and 3 above, while point 1 likely require a bit more thought.

I tried implementing this as part of the current instruction set and tracing during execution but it became very complex to manage modification in-place. I think a more tractable approach would be to implement a streaming compiler from IR to a modified set of runtime instructions, or streaming to a lower level instruction set. This'd require some funky tricks to switch to interpretation when one hits an unknown branch and then inserting those branches back but it seems tractable.

This is mostly just a brain dump at the moment to get some initial thoughts while I'm reading papers on JIT-compilation.

tgolsson

tgolsson

enhancement
Comment Icon0

Currently, a lot of tests are Rust tests that execute a single script to validate the language. In order to dogfood the language capabilities we could migrate some of these tests to actual Rune tests instead.

tgolsson

tgolsson

enhancement
Comment Icon0

In order to provide good diagnostics it'd be helpful if the DebugInst not only pointed to the span of the instruction but also any related parts that are useful for diagnostics. For example, in a let binding it would make sense to have spans for all lhs elements as well as rhs. In a binary op, having the two operands would make sense. This can then be used to generate more detailed diagnostics with more exact spans for codespan-reporting.

tgolsson

tgolsson

documentation
Comment Icon0

For example, the LSP could expose commands to run, check, or test the current code by sharing some code with rune-cli.

Potentially has some overlap with DAP, for debugging capabilities.

udoprog

udoprog

enhancement
Comment Icon0

Come up with a generics scheme that works at runtime and allows for:

  • Dynamically dispatching a function call to the correct implementation depending on the type of the arguments.
  • Directly address the exact generic implementation at compile-time using generic function-call syntax (e.g. std::parse::<i64>(string)).

Suggested implementation details

The idea is that native generic functions are monomorphized at registration time. Take:

It would actually look up a function named "parse", who's hash includes the int type constructor. Programmatically this would be something like:

So what happens if we call the function generically?

This will error, since there's no generic type information available. We don't know which str::parse impl to pick:

The above case has to be specified at compile time, because the type of the argument doesn't determine the implementation to use:

For case where we can look at the type of the argument (like String::split), the generic function by first looking up the split instance fn, then using the metadata to resolve all generic parameters and notice that they are input arguments, so it can generate the necessary type hash:

Or can be used more explicitly to avoid the dynamic dispatch:

sapir

sapir

enhancement
Comment Icon0

For example:

Currently, runestick::Any requires std::any::Any which requires 'static, and also UnsafeFromValue and UnsafeToValue require 'static, so this is impossible. Also the derive macro doesn't handle the lifetime correctly.

It would be nice if this were allowed when not using async.

Versions

Find the latest versions by id

0.12.0 - Jun 11, 2022

0.10.3 - Dec 16, 2021

Fixed

  • Stop depending on yanked futures-core (#372) (thanks d00z3l!).

0.10.2 - Dec 09, 2021

Fixed

  • Fix rune-cli build when building with default features, as it does when installing from crates.io (#368) (thanks tgolsson!).

0.10.1 - Dec 06, 2021

Fixed

  • Fix shadowed variables being incorrectly captured (#363).

0.10.0 - Dec 02, 2021

For a guide on how to go from 0.9.x 0.10.x, see the upgrade guide for 0.9.x to 0.10.x.

Changed

  • Rune is now a single rune crate instead of being divided between runestick and rune.
  • Completely overhauled how rune is compiled.
  • Changed how diagnostics is emitted.
  • Macros now take an explicit ctx macro rather than relying on TLS (#304).
  • Native functions no longer have to be Copy (#329).
  • Many types that used to be publicly exported are now hidden.
  • rune test (and rune bench) now captures all output (#354).

Added

  • We can now compile rune source inside of macros (#302).
  • Basic benchmarking tool has been added to rune-cli through rune bench (#296).
  • Vm::with has been added so we can call functions like Value::string_display that "must be run withing a virtual machine" (#291).

Fixed

  • Fixed issue when expanding template literals which prevents properly using them as expressions (#326) (thanks Steven0351!).
  • Constant values are not exported so they can be looked up in the unit (#316, #317) (thanks pkolaczk and tgolsson!).
  • Make SyncFunction documentation visible (#279).

0.9.1 - Nov 28, 2021

Fixed

Added

  • Enable passing Deref/DerefMut into Rune as Values (#269) (thanks tgolsson).
  • Support for deriving Any on generic types (#268) (thanks tgolsson).
  • Add display implementations for byte and bool (#258) (thanks Roba1993).

Changed

  • Correctly mark AnyObj::{from_ref, from_mut} as both super unsafe (#265)
  • Various internal refactorings (thanks Roba1993).

0.9.0 - Nov 28, 2021

Changed

  • rune-modules now uses tokio 1.x.

Fixed

  • Vm::async_call didn't use async completion functions ([#253]) (thanks Roba1993!).

0.8.0 - Jan 19, 2021

0.8.0

Added

  • Support for #[test] annotations (#218, #222) (thanks tgolsson!).
  • Add file!() and line!() macros (#168) (thanks tgolsson!).
  • Support for field functions and derives to implement them (#169, #170).
  • Support for crate in modules (#172).
  • std::any APIs for runtime inspection of types (#178) (thanks tgolsson!).
  • Support for range expressions (#180).
  • Missing implementations for FromValue conversions for i16 and u16 (#235) (thanks genusistimelord!).
  • More APIs and iterator-heavy benchmark (#232) (thanks tgolsson!).
  • Added initial benchmarks (#189).
  • Added cellular automata benchmark (#220) (thanks tgolsson!).
  • Added fibonacci and brainfuck benchmarks (#193) (thanks tgolsson!).
  • Projection APIs for internal Ref / RefMut (#211).
  • Many API additions and fixes (#219, #229, #233, #241, #196, #199, #185) (thanks tgolsson!).
  • Annotations to improve measuring the performance of individual operations in the VM (#190).
  • Pattern matching for booleans (#188) (thanks genusistimelord!).
  • Added support for continue inside of loops (#183).
  • Add support for registering and accessing runtime constants (#239).
  • Support for panicking pattern binding in function arguments (#195).
  • Added parsing for yet-to-be supported path segments (#206).
  • Add basic support for threaded execution (#97).

Changed

  • Minor changes (#247, #208).
  • Improved CLI with cargo-like subcommands (#223) (thanks tgolsson!).
  • Compile-time metadata has been simplified (#163, #164).
  • Internal compiler improvements (#173, #174).
  • Make types used in Context iteration APIs public (#176).
  • Slim down the size of runtime meta (#177).
  • Change and improve how protocol functions are called (#210, #209).
  • Improve performance of runtime hashing (#191).
  • Improve diagnostics when using an exclusive reference which is not exclusive (#213).
  • Improve performance by reducing the number of copies generated (#194).
  • Make compile hooks refcounted for increased flexibility (#221).
  • Expose LSP server as a modular library for custom uses (#186) (thanks tgolsson!).
  • Improve performance of small objects by using BTreeMap for field storage (#231) (thanks tgolsson!).
  • Report errors and warnings through same diagnostics structure (#227, #228).

Fixed

  • Minor fixes (#198, #201).
  • Documentation fixes and improvements (#248, #234, #242) (thanks robojumper, maxmcd, and hvithrafn!).
  • Fix negative fractional literals (#184) (thanks tgolsson!).
  • Various fixes for use in OxidizeBot (#161).
  • Bug with using wrong protocol for MUL and DIV (#167).
  • Add missing macro modules in rune-wasm (#171) (thanks tgolsson!).
  • Fixed buggy visibility checks for paths (#175).
  • Various fixes and improvements due to AoC (#181, #187, #192, #197, #203, #204, #205, #216, #217).
  • Give SourceLoader a lifetime (#245) (thanks tgolsson!).
  • Fix miscompilation in struct literals (#246) (thanks robojumper!).
  • Fix miscompilation in pattern matching (#214).
  • Introduced and fixed binding bug (#202).
  • Fix so that different variants of the same enum have different equalities (#215).
  • Make float associated fns associated (#240) (thanks tgolsson!).
  • Bump nanorand to fix incorrect generation of random numbers in rand module (#243) (thanks tgolsson!).
  • Fixed broken assembly of more than one if else (#230).

0.7.0 - Oct 19, 2020

Added

  • The Rune project now has a Code of Conduct (#12).
  • Support for bitwise operations on numbers (#13, #20).
  • Book now has support for highlighting rune blocks (#14).
  • Preliminary support for modules without visibility (#16, #17).
  • Debug information for function variable names now reflect source (#24).
  • Initial support for macros (#29, #30, #31, #114, #135, #136, #137, #138, #141, #142, #143, #144).
  • Add cargo build cache (#36) (thanks shekohex!).
  • Rust quote! macro for Rune macro authors (#34).
  • Support for object- and tuple-like field assignments (#38, #39, #40, #66).
  • Support for lazy evaluation for and/or (&& / ||) (#50) (thanks seanchen1991!).
  • Add AsTokens, FromValue, ToValue, and Spanned derives (#41, #85, #87, #88, #113).
  • Visual studio code extension with syntax highlighting and basic language server (#46, #47, #48, #60, #74) (thanks killercup!).
    • As-you-type building (#49).
    • Jump to definitions (#61).
    • Multifile project support (#64).
    • Automatic downloading of language server binary (#69).
  • Non-zero exit status on script errors (#58, #59) (thanks killercup!).
  • Improve CLI by parsing arguments using structopt (#51) (thanks shekohex!).
  • Executing functions in the virtual machine can use external references (#52).
  • Remove unused instruction in loop (#53) (thanks genusistimelord!).
  • Tweak module dependencies to use native Rust modules (#54) (thanks killercup!).
  • Internal changes to support a future C FFI (#55).
  • Improving module API (#56).
  • Extending http module to deserialize JSON directly (#57) (thanks killercup!).
  • Automatic build releases on tags (#68).
  • Fixed locals bug with breaking control in the middle of an index get operation (#71).
  • Community site at https://rune-rs.github.io (#75).
  • Add WASM-based Playground to community site https://rune-rs.github.io (#77).
  • Support for limiting execution of rune-wasm (#80).
  • Support for modules, imports, re-exports, visibility, and path resolution (#83, #92, #98, #124, #125, #128, #129, #130, #131, #133, #134, #148, #155) (thanks dillonhicks!).
  • Add WASM support for a couple of showcased rune modules (#89).
  • Added runtime type information (RTTI) for values in Runestick (#90, #112).
  • Add a rand module to rune-modules (#100) (thanks aspenluxxxy!).
  • Initial support for constant evaluation (#93, #94, #99, #104, #105, #106, #107, #117, #122, #123, #153).
  • Add Args implementation for Vec (#147) (thanks MinusGix!).
  • Export a Function variant called SyncFunction that is thread-safe (#149, #151) (thanks MinusGix!).
  • Support move modifier to async blocks and closures to take ownership of values being used (#152).
  • Basic Iterator support (#156, #157) (thanks MinusGix!).
  • Support for calling protocol functions from native code using Interface (#159).

Changed

  • Make units more efficient by separating runtime and compile-time metadata (#24).
  • Change the internal representation of Item to be more memory efficient (#63).
  • Make the implementation of ParseError and CompileError more consistent (#65).
  • Remove the rune-testing module (#67).
  • Made evaluation order of index set operations the same as Rust (#70).
  • Make hashing less error prone (#72).
  • Various parser changes and tests (#110).
  • Various internal changes (#103, #108, #109).
  • Parser simplifications (#120, #121).
  • Negative literals are handled as expressions (#132).
  • Syntax for template strings now follows EcmaScript (#145).

Fixed

  • Introduced custom highlight.js to fix issue with hidden lines in the book (#10).
  • Semi-colons in blocks weren't required, they now are (#32).
  • Fixed field assignments (#38, #40) (thanks MinusGix!).
  • Book typos (#11, #18, #28, #37) (thanks Sparkpin, seanchen1991, stoically, and macginitie!).
  • Fix broken book links (#84, #86) (thanks dillonhicks!).
  • Fix pattern miscompilation (#62).
  • Fixed bug with Closure optimization where it's being treated as a function (#21, #22) (thanks MinusGix!).
  • Fixed a number of clippy lints (#35) (thanks shekohex!).
  • Fix using closures in literals, like (0, || 42) or #{a: || 42} (#78).
  • Shared access guards didn't implement Drop allowing them to leak their guarded value (#119).

nightly - Sep 17, 2020

Information - Updated Jul 30, 2022

Stars: 998
Forks: 48
Issues: 47

Repositories & Extras

embedded-msgpack

MessagePack serialization implementation for Rust optimized for embedded environments

embedded-msgpack

embedded-template-rs

This is a repository with templates for embedded projects in cargo-generate

embedded-template-rs

Embedded rust HAL (hardware abstraction layer) for the STM32WL

This is a work in progress, it is unstable, incomplete, and (mostly) untested

Embedded rust HAL (hardware abstraction layer) for the STM32WL

Embedded graphics

Additional functions provided by external crates

Embedded graphics

Drogue device is an open source async, no-alloc framework for embedded devices

It integrates with rust, an efficient, memory safe and thread safe programming language

Drogue device is an open source async, no-alloc framework for embedded devices

Embedded Rust Template

This template is based on stm32f4xx-hal

Embedded Rust Template

embedded-semver  

Compact representation of semantic versions as an i32, u32 i64 or u64

embedded-semver  

embedded-rust-H2AL

Hardware abstraction layer - abstraction layer

embedded-rust-H2AL

Embedded Linux controlled Hardware Manager

This is a rust based project making use of

Embedded Linux controlled Hardware Manager

Embedded rust HAL (hardware abstraction layer) for the STM32WL series

This is still in development, the code that exists today covers basic usage of:

Embedded rust HAL (hardware abstraction layer) for the STM32WL series

This project is a prototype for a car dashboard camera, created to learn more about...

This project is a prototype for a car dashboard camera, created to learn more about the Rust programming language and the embedded Rust ecosystem

This project is a prototype for a car dashboard camera, created to learn more about...
Facebook Instagram Twitter GitHub Dribbble
Privacy