A Rust Embedded-HAL for the rp series microcontrollers

Related tags

GUI rp-hal



A Rust HAL impl for the RP family of microcontrollers from the Raspberry Pi Foundation
Explore the docs »

View Demo · Report Bug · Request Feature

Table of Contents

  1. Getting Started
  2. Usage
  3. Roadmap
  4. Contributing
  5. License
  6. Contact
  7. Acknowledgements

Getting Started

To get a local copy up and running follow these simple steps.



  1. Clone the repo or use the crate
    git clone https://github.com/rp-rs/rp-hal
    cargo install rpXXXX-hal


Use this space to show useful examples of how a project can be used. Additional screenshots, code examples and demos work well in this space. You may also link to more resources.

For more examples, please refer to the Documentation


NOTE This HAL is under active development. As such, it is likely to remain volatile until a 1.0.0 release.

See the open issues for a list of proposed features (and known issues).


Contributions are what make the open source community such an amazing place to be learn, inspire, and create. Any contributions you make are greatly appreciated.

  1. Fork the Project
  2. Create your Feature Branch (git checkout -b feature/AmazingFeature)
  3. Commit your Changes (git commit -m 'Add some AmazingFeature')
  4. Push to the Branch (git push origin feature/AmazingFeature)
  5. Open a Pull Request


Distributed under the MIT OR Apache2.0 License. See MIT or APACHE2.0 for more information.


Project Link: https://github.com/rp-rs/rp-hal/issues


  • rp-pico pico_usb_twitchy_mouse not working

    rp-pico pico_usb_twitchy_mouse not working

    Hi all

    I am trying to build a custom USB HAL device for my rp-pico device. When I try using the pico_usb_twitchy_mouse example, I can see the USB device through lsusb, but using hidviz I am unable to see any HID devices.

    For reference

    • My host machine is an M1 based Mac
    • I am using probe-run

    output from lsusb is:

    Bus 002 Device 005: ID 16c0:27da 16c0 Twitchy Mousey  Serial: TEST

    Regards Matt

    opened by m5p3nc3r 18
  • DMA (alternative to #209)

    DMA (alternative to #209)

    Rebased #209 onto current trunk. Updated to embedded-dma 0.2

    Current plan is to drop everything except for SingleChannel, since I think that should end up being simpler and more flexible than the current approach. To get bidirectional functionality from SingleChannel, will need to update peripherals to provide TX/RX endpoints so that the user can have 2 channels targeting the same peripheral for reading/writing. For double-buffering I was thinking to pass the second DMA channel as an Option to the constructor, so the same interface is used regardless of single-shot/double buffering.

    Will probably rename SingleChannel to Channel or Transfer or something to match the above changes.

    EDIT: After splitting it up, it looks like it already resembles the above somewhat so this might only require minor changes

    Other goals:

    • support transfer widths other than 32bit for peripherals
    • address concerns with current interface raised in #13 and #209
    opened by 9names 15
  • Make BSPs provide boot2 as a default feature

    Make BSPs provide boot2 as a default feature

    Provide definition for BOOT2 inside of each BSP hidden behind the boot2 feature flag, and make boot2 a default feature of the BSPs This moves

    #[cfg(feature = "boot2")]
    #[link_section = ".boot2"]
    pub static BOOT2: [u8; 256] = rp2040_boot2::BOOT_LOADER_W25Q080;

    from the BSP examples into the BSP library. Users of the BSP then have one less thing to paste/change in their own code.

    While I was already changing this code I also updated the HAL and all BSP crates to use the latest git commit for rp2040-boot2.

    Closes #145

    Might be worth merging https://github.com/rp-rs/rp2040-boot2-rs/pull/11 first, then doing a release of rp2040-boot2. After updating to use the crates.io version of rp2040-boot2 we could also deal with #92 in this PR.

    opened by 9names 14
  • Rework the PIO API

    Rework the PIO API


    The current PIO API has a number of limitations:

    • As the state machines are contained in PIO, they cannot be moved around individually. Sometimes, a single PIO block implements multiple functions that are used in completely different parts of the code base.
    • StateMachine is not Send, although it could be.
    • Multiple state machines should be able to share code to reduce instruction space usage, yet currently they are not because PIOBuilder always allocates space. Sometimes, multiple state machines implement the same functionality (e.g., multiple SPI or I2C buses).
    • Some functions must only be called in specific configurations. For example, pin directions have to be set while the state machine is stopped, as PINCTRL is modified. The current API does not reflect such restrictions, which makes it harder to use than necessary.

    Also, during my work, I found a bug where used instruction space was not marked properly.

    This PR also fixes #141 by providing a function to set pin directions.


    This PR uses different types to represent state machines in different states - UninitStateMachine<P> is not associated with any program, whereas StateMachine<P, Stopped> and StateMachine<P, Running> are. Program installation in instruction memory is separated from state machine initialization via InstalledProgram and PIO::install(). Access from state machines to shared registers is performed via atomic operations to enable Send.

    Old usage example:

    let pio = rp2040_hal::pio::PIO::new(pac.PIO0, &mut pac.RESETS);
    let sm = &pio.state_machines()[0];
    let div = 0f32; // as slow as possible (0 is interpreted as 65536)
        .set_pins(led_pin_id, 1)
        .build(&pio, sm)

    New usage example:

    let (mut pio, sm0, _, _, _) = pac.PIO0.split(&mut pac.RESETS);
    let installed = pio.install(&program).unwrap();
    let div = 0f32; // as slow as possible (0 is interpreted as 65536)
    let sm = rp2040_hal::pio::PIOBuilder::from_program(installed)
        .set_pins(led_pin_id, 1)


    I tested that the blink examples work, and I tested with my own code that, however, does not use much more PIO functionality yet (except for sideset pins). Those programs work fine.

    opened by mgottschlag 14
  • RTIC scheduled software tasks consume TIMER, preventing use of Timer/Alarm hardware interrupts

    RTIC scheduled software tasks consume TIMER, preventing use of Timer/Alarm hardware interrupts

    When using RTIC, if one wants to be able to schedule a software task (eg taskname::spawn_after(duration)) it is necessary to bind the TIMER peripheral to the monotonic: let mono = Rp2040Monotonic::new(c.device.TIMER);. This makes the Timer peripheral and its four hardware Alarm interrupts unavailable.

    It would be useful to have Timer/Alarm hardware interrupts and scheduled software tasks available simultaneously. For example, to set key timing cycles using low overhead HW interrupts, and schedule SW tasks relative to them.

    Perhaps deriving the monotonic from SYSTICK rather then TIMER would work.

    opened by xabra 13
  • Gate usb Suspend/Resume feature with a feature: usb-suspend

    Gate usb Suspend/Resume feature with a feature: usb-suspend

    Because this is broken in the current version of usb-device, we need to gate this until the upstream fix is published in a version.


    I didn't get to test it yet. It'd be greatly appreciated if reviewer could build one of the example and confirm that it is broken without the gate (you'll need to make the usb host suspend the link, typically by putting a laptop host into sleep/suspend).

    opened by ithinuel 11
  • Add simple interrupt_disable+spinlock critical-section impl

    Add simple interrupt_disable+spinlock critical-section impl

    Implement critical section's custom-impl trait based (heavily) on examples and feedback from dirbaio and jannic.

    Interrupts are disabled before acquiring the spinlock to ensure that an interrupt on the same core does not deadlock. The interrupt-enable on failure to acquire the lock ensures that interrupts still have a chance to fire on the same core if main() is blocked on the critical-section. Performance for this implementation is not expected to be great.

    This assumes that spinlock31 is reserved exclusively for this purpose.

    This should not be merged before https://github.com/rp-rs/rp2040-pac/pull/39 to avoid churn.

    Definitely squash when you do perform the merge, we don't need the history from this branch.

    opened by 9names 11
  • PIO support

    PIO support

    Add support for PIO hardware. This PR is based on #9 and implements most of the missing features, including interrupts.

    This PR depends on pio-rs#3.

    Closes #5.

    opened by henkkuli 11
  • Support dual-core operation

    Support dual-core operation

    opened by leo60228 11
  • Bootrom functions

    Bootrom functions

    Does the bootrom table lookup code work? It's just that according to Datasheet section 2.8.3, the Bootrom stores the table addresses as 16-bit values - these need to be read as 16-bit values, then expanded to 32-bit, then converted to the appropriate pointer. I suspect the code as written will read 32-bits from the bootrom, and get thus get the pointer very wrong.

    opened by thejpster 11
  • Avoid 64bit division

    Avoid 64bit division

    While looking at the code generated by https://github.com/rp-rs/rp-hal/pull/288, I wondered why there were references to 64bit division code (compiler_builtins::int::specialized_div_rem::u64_div_rem) for a basically empty firmware.

    Turned out that init_clocks_and_plls() contained 64bit integer divisions.

    As the code to do those divisions takes about 1kB even in fully optimized builds, I changed the clock calculation code to use 32bit divisions, instead.

    To keep the code small, I accepted some minimal additional rounding error: In case the remainder of the division is bigger than 2^24, the lower 8 bits will be thrown away, causing a relative rounding error of at most 2^-16. (To be exact, instead of the expected rounding-down of normal integer division, the value might get rounded up, instead. The resulting difference from the true value might be even smaller than before.)

    opened by jannic 10
  • SPI slave implementation not available

    SPI slave implementation not available

    I am not sure that the functionality of configuring the peripheral as a slave exists yet, and I think this is an important feature. If so, please let me know if this can be done with my own pull request, or if this will be implemented later.

    opened by DmitriLyalikov 1
  • Not able to blink the onboard led on rpi pico w

    Not able to blink the onboard led on rpi pico w

    I'm trying to get started with running rust on my newly purchased rpi pico w ( with wifi support ). Initially when I set everything up and run the blinky example, it did not work. I then ran the micro python example and the led was working. For the w version the rpi community says that there is a slight change in the way onboard led is configured

    Link to the thread https://forums.raspberrypi.com/viewtopic.php?t=336836

    Is there any change that must be made in the rust blinky example to get it working?

    opened by Narayanbhat166 3
  • the name `_critical_section_1_0_acquire` is defined multiple times

    the name `_critical_section_1_0_acquire` is defined multiple times

    We had to update our version of critical_section, since critical_section 0.2.0 will silently break when mixed with critical_section 1.0. If you see the above error message, you need to update your dependency to rp2040-hal v0.6.1 (or downgrade to an older version of the HAL) Sorry for any inconvenience!

    Full error for anyone who needs more context:

     Compiling rp2040-hal v0.6.0 (/home/nine/vc/rust/rp2040/rphal-update/rp2040-hal)
    error[E0428]: the name `_critical_section_1_0_acquire` is defined multiple times
     --> rp2040-hal/src/critical_section_impl.rs:5:1
    5 | critical_section_0_2::custom_impl!(RpSpinlockCs);
      | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `_critical_section_1_0_acquire` redefined here
    6 | #[cfg(feature = "critical-section-impl")]
    7 | critical_section::set_impl!(RpSpinlockCs);
      | ----------------------------------------- previous definition of the value `_critical_section_1_0_acquire` here
      = note: `_critical_section_1_0_acquire` must be defined only once in the value namespace of this module
      = note: this error originates in the macro `critical_section_0_2::custom_impl` (in Nightly builds, run with -Z macro-backtrace for more info)

    Please comment or emote on this issue if you've hit this problem so we have an idea of how many people are affected. Also: feel free to ask if you don't know how to resolve this.

    opened by 9names 0
  • Async / executer

    Async / executer

    As the dual core paradigm is one of the key features of the Pico / 2040, Rust support would need to allow for async fn to be executed in parallel without introducing an operation system in the project but by simply distributing the tasks to the two cores with the "executer". Is there already anything planned with such a goal ? Thanks a lot for listening, -Michael

    opened by mschnell1 5
  • Prototype of an I2C constructor which doesn't own pins

    Prototype of an I2C constructor which doesn't own pins

    Just a simple PoC showing that the existing I2C struct is flexible enough to be extended with a variant that doesn't own SCL/SDA pins. That way, it would be easy to use I2C with DynPins.

    For now I only tested that this still builds. And the function naming needs to be improved. (Also, lots of unnecessary code duplication in controller.rs)

    @cr1901: Would that, in combination with #482, solve #481?

    opened by jannic 6
  • v0.7.0(Dec 11, 2022)

    0.7.0 - 2022-12-11


    • Fixed: First frame is getting lost on a USB-CDC device - @MuratUrsavas
    • Moved BSP crates to separate repo at https://github.com/rp-rs/rp-hal-boards - @jannic
    • Avoid losing USB status events by reading ints rather than sie_status in poll - @ithinuel
    • Allow setting clock divisors on running state machines - @jannic
    • Remove unnecessary mut from static mut LOCK_OWNER: AtomicU8 in critical section impl - @zachs18
    • Update dependency on rp2040-pac to 0.4.0 - @jannic
    • Update embedded-hal alpha support to version 1.0.0-alpha.9 - @jannic (Non-blocking traits were moved to embedded-hal-nb, which is not yet supported)
    • Implement UartConfig::new constructor method - @jannic
    • Deprecate uart::common_configs - @jannic
    • Fix spelling error in UART error discarded field - @Sizurka
    • Fix contents of UART error discarded field - @Sizurka
    • Fix watchdog counter load value - @Sizurka
    • Fix concurrent accesses to sm_execctrl and sm_instr when sideset isn't optional - @ithinuel
    • pio: Move interrupt related (en|dis)abling/forcing methods to the statemachine - @ithinuel
    • Mark Timer & Alarm* Send and Sync - @ithinuel
    • The feature critical-section-impl is now enabled by default from the BSP crates - @jannic
    • Simplify signature of Alarm::schedule, removing generic parameter - @ithinuel
    • USB: Use the dedicated write_bitmask_* functions - @ithinuel


    • Add docs.rs metadata - @icedrocket
    • Implement embedded-hal aplha SPI traits - @ptpaterson
    • Add derive(Debug) and derive(defmt::Format) to error types - @9names
    • Add ability to modify installed PIO program wrap bounds - @davidcole1340
    • Add rtic-monotonic support for timer & alarms (feature gated) - @ithinuel
    • Add SPI is_busy function - @papyDoctor
    • Add set_fifos/set_rx_watermark/set_tx_watermark - @papyDoctor
    • Add a method to allow setting the PIO's clock divisor without floats - @ithinuel
    • Use TimerInstant in Timer::GetCounter & add Alarm::schedule_at - @ithinuel


    • Removed support for critical-section 0.2 (was already deprecated) - @jannic
    Source code(tar.gz)
    Source code(zip)
  • v0.6.1(Dec 10, 2022)

    0.6.1 - 2022-11-30


    • Upgraded dependency on critical-section 0.2 to 0.2.8 - @jannic (There is also a dependency on version 1.0.0)
    • Remove critical-section impl for version 0.2 - @jannic Both 0.2.8 and 1.x use the same symbols internally to implement the critical sections, so one impl is sufficient, and having both causes compilation errors
    Source code(tar.gz)
    Source code(zip)
  • v0.6.0(Aug 26, 2022)

    [0.6.0] - 2022-08-26


    • Documentation Example for the bsp_pin! macro - @hmvp
    • Timer: Documentation & doc examples for Timers - @9names
    • Add suspend, resume and remote wakeup support. - @ithinuel & @jannic
    • rp2040-e5 feature enabling the workaround for errata 5 on the USB device peripheral. - @ithinuel
    • NonPwmPinMode for gpio::Disabled - @FlorianUekermann
    • RAM-based interrupt vector tables - @9names
    • Support for critical-section 1.0.0. Critical-section 0.2 is still supported (ie. a custom-impl is provided, compatible with the 1.0.0 implementation), to avoid a breaking change. It will be removed later. - @jannic
    • Add support for the Interpolator. @fenax


    • Update dev dependencies on cortex-m-rtic to 1.1.2 - @jannic
    • Use correct interrupt names in timer::alarms - @hmvp
    • Update embedded-hal alpha support to version 1.0.0-alpha.8 - @jannic
    • Fix PIO rx fifo status - @jannic
    • Implement From<&SomeClock> for Hertz instead of From<SomeClock> for Hertz for the clocks in rp2040_hal::clocks. - @jannic
    • Fix i2c example using the wrong clock. - @jannic
    • Fix duty cycle handing on disabled pwm channels. - @jannic
    • GPIO IRQ example: add check for interrupt source - @9names
    • Align USB synchronisation requirements with the manual & pico-sdk - @ithinuel
    • Update dependencies on usb-device to 0.2.9 - @ithinuel
    • Use wfi in otherwise empty infinite loops in examples. - @jannic
    • Use generic bootloader in examples - @jannic
    • Use rp2040-hal's entry function. - @ithinuel
    • Migrate from embedded-time to fugit - @ithinuel
    • Fix PIO's set_pins and set_pindirs when out_sticky is set. - @jannic & @ithinuel


    • Unnecessary cortex_m::interrupt::free in timer.rs - @jannic
    • Unused embassy-traits deps - @9names
    Source code(tar.gz)
    Source code(zip)
  • v0.5.0(Jun 14, 2022)

    [0.5.0] - 2022-06-13


    The Minimum-Supported Rust Version (MSRV) for this release is 1.61


    • RP2040 specific #[entry] macro that releases spinlocks - @jannic
    • Start multiple state machines in sync with each other - @astraw
    • Unsafe fn for freeing all spinlocks when you can't use the RP2040 entry macro (eg RTIC) - @9names
    • Optional feature for enabling defmt formatting for i2c errors - @ithinuel
    • Accessor for getting the offset of an installed PIO program - @fenax


    • Use thread send safe UART* marker when splitting, improves UART ergonmics - @marius-meissner
    • Improve performance for hardware division instrinsics. Internal intrinsics cleanup - @Sizurka
    • Provide a better alarm abstraction - @ithinuel
    • Update Multicore::spawn to be able to take a closure without requiring alloc. Improve Multicore ergonomics and add example for how to use new API - @Liamolucko
    • Allow PIO program to be 32 instructions long, was previously limited to 31 - @jannic
    • Fix Typos - @mqy, @danbev
    • Replace generic pio::Tx::write with write_u8_replicated, write_u16_replicated, and update write to take a u32. The generic version was too easy to misuse. - @9names


    • I2c async driver. Use new one at https://github.com/ithinuel/rp2040-async-i2c/ - @ithinuel
    • Unused fields from UartPeripheral and Reader - @jannic
    Source code(tar.gz)
    Source code(zip)
  • v0.4.0(Mar 11, 2022)


    • ROM function caching
    • ROM version lookup function
    • Compiler intrinsics for ROM functions
    • Compiler intrinsics for hardware divider
    • Document bsp_pins! macro
    • UART IRQ examples
    • PIO side-set example
    • Stopped PIO state machines can change their clock divider
    • Added HAL IRQ example


    • Rewrite UART driver to own its pins
    • Improve UART defaults
    • Fix repeated-read in i2c embassy driver
    • Fix bug in i2c peripheral state machine
    • Fix race condition in alarm
    • Fix safety bugs in hardware divider
    • Enable watchdog reset trigger bits when watchdog enabled
    • Update spinlocks to use new PAC API
    • Use generics to improve spinlock implementation
    • Update critical_section to use new spinlock implementation
    • Update embedded-hal alpha support to version 1.0.0-alpha.7
    • Avoid 64-bit division in clock calculations
    • Update pio and pio-proc to 0.2.0
    Source code(tar.gz)
    Source code(zip)
  • rp2040-hal-0.3.0(Dec 20, 2021)


    The Minimum-Supported Rust Version (MSRV) for this release is 1.54.


    • A README!
    • Implementation of the critical-section API
    • Embedded HAL 1.0-alpha6 support
    • I²C Controller and Peripheral support
    • Multi-core support, including spin-locks and SIO FIFO
    • RTC support
    • USB Device support
    • Timer support
    • PIO support
    • Implementation of rng_core::RngCore for RingOscillator
    • ADC example
    • GPIO Interrupt support
    • Multi-core FIFO example
    • PIO LED Blinky example
    • ROM Functions example
    • SPI example
    • Watchdog example
    • ADC documentation
    • Lots of bug fixes :)


    • Modified PIO API for better ergonomics
    • Updated PAC to 0.2.0
    • Exported common driver structs from top-level (e.g. it's now Sio, not sio::Sio)
    Source code(tar.gz)
    Source code(zip)
  • v0.2.0(Aug 14, 2021)

    • Updated version with support for:
      • Ring Oscillator
      • Crystal Oscillator
      • Plls
      • Watchdog
      • Clocks
      • GPIO
      • PWM
      • ADC
      • SPI
      • I²C
      • Resets
      • UART
      • Hardware divide/modulo
    Source code(tar.gz)
    Source code(zip)
Rust on the RP series of microcontrollers. https://matrix.to/#/#rp-rs:matrix.org
A simple, cross-platform GUI automation module for Rust.

AutoPilot AutoPilot is a Rust port of the Python C extension AutoPy, a simple, cross-platform GUI automation library for Python. For more information,

null 271 Dec 27, 2022
A data-first Rust-native UI design toolkit.

Druid A data-first Rust-native UI toolkit. Druid is an experimental Rust-native UI toolkit. Its main goal is to offer a polished user experience. Ther

null 8.2k Dec 31, 2022
The Rust UI-Toolkit.

The Orbital Widget Toolkit is a cross-platform (G)UI toolkit for building scalable user interfaces with the programming language Rust. It's based on t

Redox OS 3.7k Jan 1, 2023
An easy-to-use, 2D GUI library written entirely in Rust.

Conrod An easy-to-use, 2D GUI library written entirely in Rust. Guide What is Conrod? A Brief Summary Screenshots and Videos Feature Overview Availabl

PistonDevelopers 3.3k Jan 1, 2023
Rust bindings to Core Foundation and other low level libraries on Mac OS X and iOS

core-foundation-rs Compatibility Targets macOS 10.7 by default. To enable features added in macOS 10.8, set Cargo feature mac_os_10_8_features. To hav

Servo 685 Jan 2, 2023
Rust bindings for the FLTK GUI library.

fltk-rs Rust bindings for the FLTK Graphical User Interface library. The FLTK crate is a crossplatform lightweight gui library which can be statically

Mohammed Alyousef 1.1k Jan 9, 2023
Build beautiful desktop apps with flutter and rust. 🌠 (wip)

flutter-rs Build flutter desktop app in dart & rust. Get Started Install requirements Rust flutter sdk Develop install the cargo flutter command cargo

null 2k Dec 26, 2022
Idiomatic, GTK+-based, GUI library, inspired by Elm, written in Rust

Relm Asynchronous, GTK+-based, GUI library, inspired by Elm, written in Rust. This library is in beta stage: it has not been thoroughly tested and its

null 2.2k Dec 31, 2022
Rust bindings for Dear ImGui

imgui-rs: Rust bindings for Dear ImGui (Recently under new maintenance, things subject to change) Window::new(im_str!("Hello world")) .size([300.0

null 2k Jan 7, 2023
Clear Coat is a Rust wrapper for the IUP GUI library.

Clear Coat Clear Coat is a Rust wrapper for the IUP GUI library. IUP uses native controls and has Windows and GTK backends. A macOS backend has been o

Jordan Miner 18 Feb 13, 2021
Rust binding for IUP

IUP Rust This library provides a high level wrapper around IUP, a multi-platform toolkit for building graphical user interfaces. See rust-iup-sys for

David Campbell 41 May 28, 2022
A simple UI framework for Rust built on top of IUP (http://webserver2.tecgraf.puc-rio.br/iup/)

KISS-UI A UI framework for Rust based on the KISS (Keep It Simple, Stupid!) philosophy. Powered by the IUP GUI library for C by Tecgraf, via the bindi

null 342 Jul 11, 2022
Rust bindings to the minimalist, native, cross-platform UI toolkit `libui`

Improved User Interface A cross-platform UI toolkit for Rust based on libui iui: ui-sys: iui is a simple (about 4 kLOC of Rust), small (about 800kb, i

Rust Native UI Group 865 Dec 27, 2022
Integrate Qml and Rust by building the QMetaObject at compile time.

QMetaObject crate for Rust The qmetaobject crate is a crate which is used to expose rust object to Qt and QML. Objectives Rust procedural macro (custo

Woboq GmbH 495 Jan 3, 2023
QtQuick interface for Rust

qmlrs - QtQuick bindings for Rust qmlrs allows the use of QML/QtQuick code from Rust, specifically Rust code can create a QtQuick engine (QQmlApplicat

Mikko Perttunen 432 Nov 24, 2022
Qt5 binding for rust language. (stalled)

Qt5 binding for Rust language. qt.rs This project provides bindings that allow the QT Gui toolkit to be used from the Rust Programming language. Compi

yatsen1 37 Oct 12, 2021
QML (Qt Quick) bindings for Rust language

QML-rust - bindings for Qt Quick Bindings are based on DOtherSide C bindings for QML Library is mostly feature-compliant with other bindings based on

Oak 204 Dec 8, 2022
Rust bindings for Sciter

Rust bindings for Sciter Check this page for other language bindings (Delphi / D / Go / .NET / Python / Rust). Introduction Sciter is an embeddable mu

Terra Informatica Software, Inc 757 Dec 30, 2022
A cross-platform GUI library for Rust, inspired by Elm

Iced A cross-platform GUI library for Rust focused on simplicity and type-safety. Inspired by Elm. Features Simple, easy-to-use, batteries-included AP

Héctor Ramón 17.5k Jan 2, 2023