bors merge

bors merge

bors merge

profile-overrides landed in 1.41 https://github.com/rust-lang/cargo/pull/7591/

I appreciate that the intention may be to maintain support for earlier rust versions if the profile-overrides keys are deleted from the README. But if the crate throws an error when compiled with its MSRV compiler, that in my opinion/understanding defeats the purpose of the MSRV.

This has been fixed in master

Hi, what is needed for this is that the target has atomics. If the system has atomics it's safe to add it to the check.

I have no experience with AVR, so I am unable to say if this condition holds for AVR.

I have found a regression after the multicore removal. The following example that I added does not compile any more on master: https://github.com/rtic-rs/cortex-m-rtic/blob/schedule_regression/examples/double_schedule.rs

It fails with the error:

error[E0574]: expected struct, variant or union type, found static `P1_RQ`
  --> examples/double_schedule.rs:11:1
   |
11 | #[rtic::app(device = lm3s6965, monotonic = rtic::cyccnt::CYCCNT)]
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not a struct, variant or union type
   |
   = note: this error originates in an attribute macro (in Nightly builds, run with -Z macro-backtrace for more info)

And looking at the task dispatcher in the expanded code, one finds that the static mut P1_RQ is used as if it was a type:

    #[no_mangle]
    unsafe fn SysTick() {
        use rtic::Mutex as _;
        #[doc = r" The priority of this handler"]
        const PRIORITY: u8 = 1u8;
        rtic::export::run(PRIORITY, || {
            while let Some((task, index)) = (TQ {
                priority: &rtic::export::Priority::new(PRIORITY),
            })
            .lock(
                #[inline(always)]
                |tq| tq.dequeue(),
            ) {
                match task {
                    T::task1 => {
                        (P1_RQ {
                            priority: &rtic::export::Priority::new(PRIORITY),
                        })
                        .lock(|rq| rq.split().0.enqueue_unchecked((P1_T::task1, index)));
                        rtic::pend(stm32l4xx_hal::stm32::Interrupt::DFSDM1);
                    }
                    T::task2 => {
                        (P1_RQ {
                            priority: &rtic::export::Priority::new(PRIORITY),
                        })
                        .lock(|rq| rq.split().0.enqueue_unchecked((P1_T::task2, index)));
                        rtic::pend(stm32l4xx_hal::stm32::Interrupt::DFSDM1);
                    }
                }
            }
        });
    }

Could you have a look at this @AfoHT ?

Maybe try making a flashloader and see if it works? You can use this project as a starting point: https://github.com/korken89/stm32l4x2-flashloader/

Hi @theunkn0wn1, the CI seems to be failing for 1.36. Could you have a look into why?

bors retry

bors merge

Or, it is behind a feature-flag so I see no issue in including as is. This feature will be considered unstable until a proper release of defmt is available.

Thanks for the update!

Now we just need to await defmt to be on crates.io and this is ready for inclusion. Maybe @japaric knows when it will be released?

Has there been any progress on the stabilization of type_name?

This is usually up to the framework that is being used for resource handling. E.g. RTIC has examples for how this should be done, while in the raw cortex-m world it's a bit more ambiguous with multiple different solutions.

I tried to port heapless types from GenericArray to usize const generics. Here is branch.

Today I managed to compile it in release mode. For testing you can use: cargo test --release.

Issues:

• In debug mode compile fails.
• Queue doesn't work. Fails on type inference. I think the problem is in the interaction of default types and const generics. pub struct Consumer<'a, T, U = usize, C = MultiCore, const N: usize>
• I don't know how to set PowerOfTwo restriction for indexmap.

Everything else is pretty good.

rustc 1.37.0-nightly (8aa42ed7c 2019-06-24)

See #168 for up to date version of this.

Is it possible to get access to the associated paper? "Heapless: Dynamic Data Structures without Dynamic Heap Allocator for Rust" somewhere?

my environment is : os: osx 10.15 rust:nightly-x86_64-apple-darwin

in the heapless directory, cargo build returns successfully . but when I changed to tests directory and run cargo test， it reports error:

error[E0432]: unresolved import `scoped_threadpool`
 --> tests/tsan.rs:9:5
  |
9 | use scoped_threadpool::Pool;
  |     ^^^^^^^^^^^^^^^^^ use of undeclared type or module `scoped_threadpool`

error[E0433]: failed to resolve: could not find `pool` in `heapless`
   --> tests/tsan.rs:242:15
    |
242 |     heapless::pool!(A: [u8; 8]);
    |               ^^^^ could not find `pool` in `heapless`

error[E0433]: failed to resolve: use of undeclared type or module `A`
   --> tests/tsan.rs:244:5
    |
244 |     A::grow(unsafe { &mut M });
    |     ^ use of undeclared type or module `A`

error[E0433]: failed to resolve: use of undeclared type or module `A`
   --> tests/tsan.rs:249:25
    |
249 |                 let a = A::alloc().unwrap();
    |                         ^ use of undeclared type or module `A`

error[E0433]: failed to resolve: use of undeclared type or module `A`
   --> tests/tsan.rs:250:25
    |
250 |                 let b = A::alloc().unwrap();
    |                         ^ use of undeclared type or module `A`

error[E0433]: failed to resolve: use of undeclared type or module `A`
   --> tests/tsan.rs:259:25
    |
259 |                 let a = A::alloc().unwrap();
    |                         ^ use of undeclared type or module `A`

error: unused import: `heapless::pool::singleton::Pool as _`
   --> tests/tsan.rs:238:9
    |
238 |     use heapless::pool::singleton::Pool as _;
    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
note: the lint level is defined here
   --> tests/tsan.rs:3:9
    |
3   | #![deny(warnings)]
    |         ^^^^^^^^
    = note: `#[deny(unused_imports)]` implied by `#[deny(warnings)]`

error: cannot find macro `pool` in this scope
   --> src/pool/singleton.rs:309:9
    |
309 |         pool!(A: u8);
    |         ^^^^

error: cannot find macro `pool` in this scope
   --> src/pool/singleton.rs:347:9
    |
347 |         pool!(A: X);
    |         ^^^^

error: aborting due to 7 previous errors

Some errors have detailed explanations: E0432, E0433.
For more information about an error, try `rustc --explain E0432`.
error: could not compile `heapless`.

To learn more, run the command again with --verbose.
warning: build failed, waiting for other jobs to finish...
error[E0433]: failed to resolve: use of undeclared type or module `A`
   --> src/pool/singleton.rs:312:17
    |
312 |         assert!(A::alloc().is_none());
    |                 ^ use of undeclared type or module `A`

error[E0433]: failed to resolve: use of undeclared type or module `A`
   --> src/pool/singleton.rs:314:9
    |
314 |         A::grow(unsafe { &mut MEMORY });
    |         ^ use of undeclared type or module `A`

error[E0433]: failed to resolve: use of undeclared type or module `A`
   --> src/pool/singleton.rs:316:17
    |
316 |         let x = A::alloc().unwrap().init(0);
    |                 ^ use of undeclared type or module `A`

error[E0433]: failed to resolve: use of undeclared type or module `A`
   --> src/pool/singleton.rs:320:17
    |
320 |         assert!(A::alloc().is_none());
    |                 ^ use of undeclared type or module `A`

error[E0433]: failed to resolve: use of undeclared type or module `A`
   --> src/pool/singleton.rs:325:21
    |
325 |         assert_eq!(*A::alloc().unwrap().init(1), 1);
    |                     ^ use of undeclared type or module `A`

error[E0433]: failed to resolve: use of undeclared type or module `A`
   --> src/pool/singleton.rs:349:17
    |
349 |         let x = A::alloc().unwrap().init(X::new());
    |                 ^ use of undeclared type or module `A`

error[E0433]: failed to resolve: use of undeclared type or module `A`
   --> src/pool/singleton.rs:350:17
    |
350 |         let y = A::alloc().unwrap().init(X::new());
    |                 ^ use of undeclared type or module `A`

error: unused import: `Pool`
   --> src/pool/singleton.rs:302:30
    |
302 |     use super::{super::Node, Pool};
    |                              ^^^^
    |
note: the lint level is defined here
   --> src/lib.rs:76:9
    |
76  | #![deny(warnings)]
    |         ^^^^^^^^
    = note: `#[deny(unused_imports)]` implied by `#[deny(warnings)]`

error: aborting due to 10 previous errors

For more information about this error, try `rustc --explain E0433`.
error: could not compile `heapless`.

To learn more, run the command again with --verbose.

Hi, you can look here to see how the CI runs it: https://github.com/japaric/heapless/blob/master/ci/script.sh#L8

I'm a newbie to embedded rust (and rust in general). When I add heapless to this project, it fails to build. If I comment out heapless in the Cargo.toml, then it builds fine.

REPRO

1. Create lib

(base) ~/temp/break $ cargo new --lib abc
     Created library `abc` package

2. Build

(base) ~/temp/break/abc $ cargo build
   Compiling abc v0.1.0 (/home/todd/temp/break/abc)
    Finished dev [unoptimized + debuginfo] target(s) in 0.23s

3. Add heapless to Cargo.toml

Cargo.toml

[dependencies]
heapless = "0.5.6"

(base) ~/temp/break/abc $ cargo build
    Updating crates.io index
   Compiling typenum v1.12.0
   Compiling byteorder v1.3.4
   Compiling stable_deref_trait v1.2.0
   Compiling heapless v0.5.6
   Compiling hash32 v0.1.1
   Compiling generic-array v0.13.2
   Compiling generic-array v0.12.3
   Compiling as-slice v0.1.3
   Compiling abc v0.1.0 (/home/todd/temp/break/abc)
    Finished dev [unoptimized + debuginfo] target(s) in 6.80s

4. Switch to nightly and build

$ rustup override set nightly

rustup override set nightly
info: using existing install for 'nightly-x86_64-unknown-linux-gnu'
info: override toolchain for '/home/todd/temp/break/abc' set to 'nightly-x86_64-unknown-linux-gnu'

  nightly-x86_64-unknown-linux-gnu unchanged - rustc 1.48.0-nightly (dbb73f8f7 2020-09-12)

(base) ~/temp/break/abc $ cargo build
   Compiling typenum v1.12.0
   Compiling byteorder v1.3.4
   Compiling stable_deref_trait v1.2.0
   Compiling heapless v0.5.6
   Compiling hash32 v0.1.1
   Compiling generic-array v0.13.2
   Compiling generic-array v0.12.3
   Compiling as-slice v0.1.3
   Compiling abc v0.1.0 (/home/todd/temp/break/abc)
    Finished dev [unoptimized + debuginfo] target(s) in 6.78s

5. Add AVR stuff

copy from/somewhere/avr-atmega328p.json .
copy from/somewhere/.cargo/config.toml .cargo/.

(project files attached)

ERROR

    Updating crates.io index
       Fresh core v0.0.0 (/home/todd/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core)
       Fresh rustc-std-workspace-core v1.99.0 (/home/todd/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/rustc-std-workspace-core)
       Fresh compiler_builtins v0.1.35
       Fresh typenum v1.12.0
       Fresh byteorder v1.3.4
       Fresh stable_deref_trait v1.2.0
       Fresh generic-array v0.13.2
       Fresh generic-array v0.12.3
       Fresh hash32 v0.1.1
   Compiling as-slice v0.1.3
     Running `rustc --crate-name as_slice /home/todd/.cargo/registry/src/github.com-1ecc6299db9ec823/as-slice-0.1.3/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C panic=abort -C embed-bitcode=no -C debuginfo=2 -C metadata=fee3837ddb75675c -C extra-filename=-fee3837ddb75675c --out-dir /home/todd/temp/break/abc/target/avr-atmega328p/debug/deps --target /home/todd/temp/break/abc/avr-atmega328p.json -L dependency=/home/todd/temp/break/abc/target/avr-atmega328p/debug/deps -L dependency=/home/todd/temp/break/abc/target/debug/deps --extern 'noprelude:compiler_builtins=/home/todd/temp/break/abc/target/avr-atmega328p/debug/deps/libcompiler_builtins-7d4617280997064b.rmeta' --extern 'noprelude:core=/home/todd/temp/break/abc/target/avr-atmega328p/debug/deps/libcore-2d142ffef2835bf2.rmeta' --extern generic_array=/home/todd/temp/break/abc/target/avr-atmega328p/debug/deps/libgeneric_array-15924d526938d28b.rmeta --extern ga13=/home/todd/temp/break/abc/target/avr-atmega328p/debug/deps/libgeneric_array-16c4ac167d17a181.rmeta --extern stable_deref_trait=/home/todd/temp/break/abc/target/avr-atmega328p/debug/deps/libstable_deref_trait-900fefb67ab7dd77.rmeta -Z unstable-options --cap-lints allow`
error[E0080]: evaluation of constant value failed
   --> /home/todd/.cargo/registry/src/github.com-1ecc6299db9ec823/as-slice-0.1.3/src/lib.rs:169:102
    |
169 |     250, 251, 252, 253, 254, 255, 256, 1 << 9, 1 << 10, 1 << 11, 1 << 12, 1 << 13, 1 << 14, 1 << 15, 1 << 16
    |                                                                                                      ^^^^^^^ attempt to shift left by 16_i32 which would overflow

error[E0119]: conflicting implementations of trait `AsSlice` for type `[_; 0]`:
   --> /home/todd/.cargo/registry/src/github.com-1ecc6299db9ec823/as-slice-0.1.3/src/lib.rs:138:13
    |
138 |               impl<T> AsSlice for [T; $N] {
    |               ^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |               |
    |               first implementation here
    |               conflicting implementation for `[_; 0]`
...
156 | / array!(
157 | |     0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25,
158 | |     26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49,
159 | |     50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73,
...   |
169 | |     250, 251, 252, 253, 254, 255, 256, 1 << 9, 1 << 10, 1 << 11, 1 << 12, 1 << 13, 1 << 14, 1 << 15, 1 << 16
170 | | );
    | |__- in this macro invocation
    |
    = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0119]: conflicting implementations of trait `AsMutSlice` for type `[_; 0]`:
   --> /home/todd/.cargo/registry/src/github.com-1ecc6299db9ec823/as-slice-0.1.3/src/lib.rs:147:13
    |
147 |               impl<T> AsMutSlice for [T; $N] {
    |               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |               |
    |               first implementation here
    |               conflicting implementation for `[_; 0]`
...
156 | / array!(
157 | |     0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25,
158 | |     26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49,
159 | |     50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73,
...   |
169 | |     250, 251, 252, 253, 254, 255, 256, 1 << 9, 1 << 10, 1 << 11, 1 << 12, 1 << 13, 1 << 14, 1 << 15, 1 << 16
170 | | );
    | |__- in this macro invocation
    |
    = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

error: aborting due to 3 previous errors

Some errors have detailed explanations: E0080, E0119.
For more information about an error, try `rustc --explain E0080`.
error: could not compile `as-slice`

Caused by:
  process didn't exit successfully: `rustc --crate-name as_slice /home/todd/.cargo/registry/src/github.com-1ecc6299db9ec823/as-slice-0.1.3/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C panic=abort -C embed-bitcode=no -C debuginfo=2 -C metadata=fee3837ddb75675c -C extra-filename=-fee3837ddb75675c --out-dir /home/todd/temp/break/abc/target/avr-atmega328p/debug/deps --target /home/todd/temp/break/abc/avr-atmega328p.json -L dependency=/home/todd/temp/break/abc/target/avr-atmega328p/debug/deps -L dependency=/home/todd/temp/break/abc/target/debug/deps --extern 'noprelude:compiler_builtins=/home/todd/temp/break/abc/target/avr-atmega328p/debug/deps/libcompiler_builtins-7d4617280997064b.rmeta' --extern 'noprelude:core=/home/todd/temp/break/abc/target/avr-atmega328p/debug/deps/libcore-2d142ffef2835bf2.rmeta' --extern generic_array=/home/todd/temp/break/abc/target/avr-atmega328p/debug/deps/libgeneric_array-15924d526938d28b.rmeta --extern ga13=/home/todd/temp/break/abc/target/avr-atmega328p/debug/deps/libgeneric_array-16c4ac167d17a181.rmeta --extern stable_deref_trait=/home/todd/temp/break/abc/target/avr-atmega328p/debug/deps/libstable_deref_trait-900fefb67ab7dd77.rmeta -Z unstable-options --cap-lints allow` (exit code: 1)

Fixed it #178

I am unsure how to pursue this issue, heapless was specifically made for systems without allocation and this is clear from the interface. What this sounds like is as if the interface should change based on the environment it is in, or that there should exist a parallel interface which aliases to the std::Vec?

While I am positive to updating generic array, I am unsure if this is a breaking change in heapless. I think we had similar discussions before in as-slice where it became a bit of a storm when we updated the generic-array dependency.

bors merge

On a side-note, as soon as stable get const generics this crate will most likely remove the generic_array dependency

Hi, I have released as-slice v0.1.4 which should solve your issue.

This crate presently pulls in both generic-array v0.12 and v0.13.

It'd be nice to also support v0.14, and potentially toggle off v0.12 and/or v0.13 support unless they're really still needed.

Related: #2

Closes #6

Hey there,

the newest version the package at https://crates.io/crates/as-slice is 0.1.3 (there's also been a 2.0 version but it's yanked). The version in master is 0.1.2.

This is now fixed.

Now merged and fixed

On targets with 16bit for usize or less, the compilations fails due to the overflow of usize due to the shift by 16 https://github.com/japaric/as-slice/blob/9240346ebc12f09f59af10538ea7948b4d023062/src/lib.rs#L169

I noticed this while trying to use the heapless library with an atmega328p. If you want to stick to the implementations up to 1 << 16 it could be a better option to split the array! macro call into several and guard them with #[cfg(target_pointer_width = " ...")]. I'll fire up a PR for that ;)

Compilation error is something like that

error[E0080]: evaluation of constant value failed
   --> /home/bisbarn/.cargo/registry/src/github.com-1ecc6299db9ec823/as-slice-0.1.3/src/lib.rs:169:102
    |
169 |     250, 251, 252, 253, 254, 255, 256, 1 << 9, 1 << 10, 1 << 11, 1 << 12, 1 << 13, 1 << 14, 1 << 15, 1 << 16
    |                                                                                                      ^^^^^^^ attempt to shift left by 16_i32 which would overflow

See #8 . This PR tries to solve compilation errors for targets with usize of 16bit or less. This is based on v0.1.3, don't exactly know what branch to merge it into, it's a little bit confusing ;)

Thanks for the PR!

I see that something strange has happened with the tagging, so I'll push out a release with this.

Unfortunately I am not aware of any way to check for the non-existence of cortex_m_rt::__INTERRUPTS at compile time.

For reference the work is being done here: https://github.com/perlindgren/heapless/tree/const_generics

@perlindgren Could you make a WIP PR with the conversion work you did?

Glad it worked!

Hi,

You can provide your own version in your crate and RTIC will use the newer version. This should solve you issue, could you try it out?

We can look into this, lets just be careful with fmt bloat. But a panic which says "Unbound interrupt detected, is the rt feature enabled in the PAC/HAL?" should be helpful and optimize away well if the panic handler requests it.

Hi, thanks for the issue!

Unfortunately RTIC cannot detect this as it simple interfaces with the HAL/PAC to get the correct interrupt numbers. If the PAC has not had the rt flag enabled it means that you as the user are responsible for providing the interrupt vector and RTIC assumes the user has provided it.

If you have ideas for automatic checking of this it would be interesting! One could look into providing a default handler in RTIC that simply panics and says that the interrupt is not bound.

Thanks for the PoC! I have been swamped lately so I have not had time to look at this, but it's on my TODO.

Just wondering when / if a new release is expected?

I need https://github.com/japaric/heapless/pull/154, and packaging with Cargo.toml links to github is problematic!

Thanks for the amazing crate!

Released :)

bors merge

Hi, the PR is up and awaiting review: https://github.com/japaric/heapless/pull/175

@perlindgren has done the conversion, we are just awaiting stabilization to make a PR.

Hi, I have commented on the PR itself.

Hi, thanks for the PR!

Since you have started this, do you feel like adding support for String as well?

Lets release the latest additions @japaric

Oh it was missed in the release, I'll fix a release right away!

This seems weird, it should not be a problem. Which version of heapless are you running?

The Send impl looks like this now and XCore is implemented for SingleCore:

unsafe impl<'a, T, N, U, C> Send for Producer<'a, T, N, U, C>
where
    N: ArrayLength<T>,
    T: Send,
    U: sealed::Uxx,
    C: sealed::XCore,
{
}

The important part is that the

Ah, then you need to provide wrappers based on the i module in heapless to get const fns. Not sure how feasible that is though unfortunately.

Hi, sorry for missing this. Here is the current recommended approach which does not require the use of an option.

#[app(device = some::device)]
const APP: () = {
    struct Resources {
        // Queue resources
        reader: Consumer<'static, MyType, U32>,
        writer: Producer<'static, MyType, U32>,
    }

    #[init]
    fn init(cx: init::Context) -> init::LateResources {
        static mut QUEUE: Queue<MyType, U32> = Queue(heapless::i::Queue::new());

        // Split queues
        let (writer, reader) = QUEUE.split();

        init::LateResources {
            reader,
            writer,
        }
    }

    // ...
}

One question @blaind , when you deserialize - how do you perform the extraction of the CRC?

Thanks for the example @blaind ! I will have to take a look and compare with my old notes on the issues I saw, it looks like I was overthinking the issue :)

The commented lines are due to incompatibility issues with the PAC that does not have all the registers of the MCU yet, so once the PAC is updated with support these can be un-commented and all will start to work.

The commented lines are due to incompatibility issues with the PAC that does not have all the registers of the MCU yet, so once the PAC is updated with support these can be un-commented and all will start to work.

Hi, sorry for letting this go so slow - I'm currently swamped.

Could we look into in this again the coming weeks?