Rtic:app macro problem

Embedded
1

I'm 100% new to Rust. My first tutorial project is a firmware for RPi Pico, using RTIC.
I'm mixing hardware interrupt-based tasks and scheduled software tasks.

#[rtic::app(device = pac, peripherals = true, dispatchers = [SW0_IRQ])]
mod app {
    ...
    #[task(binds = USBCTRL_IRQ, priority = 4, shared = [b0p])]
    fn irq_usbctrl(mut ctx: irq_usbctrl::Context) {
    ...
    }
    ...
    #[task(priority = 1)]
    async fn prio5(_ctx: prio5::Context) {
        hprintln!("prio5");
    }
}

The hardware-irq task is fine (and I've 24 of those). As soon as I add 1 software task, I get 2 errors on the #[rtic:app()] line:

    | expected 1 generic argument
    | help: remove this generic argument

and

    | expected `Error`, found `()`
    | arguments to this enum variant are incorrect

If I remove the "dispatchers" parameters, the error disappear but then I get another error as there are not enough IRQs to trigger the software tasks.
I'm completely stuck since 2 days; any tip would be appreaciated.

2

Macros can have trouble producing useful errors. In this case, the nonsensical errors pointing at the #[rtic::app] indicates that the macro output is not valid Rust code. Usually but not always, this means the input to the macro wasn't as expected; you'll need to consult documentation for what syntax the macro expects as input.

Unfortunately, the library documentation has no syntax description, and the linked book appears to be all tutorial and no reference. This should be considered a deficiency in the documentation — you're stuck because important resources haven't been provided.

1 Like
3

I suggest changing the category to Embedded to try to catch the eye of others working in that area. To do that, you click the link for changing the title.

4

Thanks both contributors.

TL;DR
I a trial&error rage moment I swapped use bbqueue::* with

    use bbqueue::BBBuffer;
    use bbqueue::Producer;
    use bbqueue::Consumer;

and ther error on #[rtic::app] automagically resolved. I'm dazed but ... the code builds.

I must spend more time on my setup because the error messages are somewhat misleading or "nonsensical": is it normal or ... my tools are not proper?
I'm using vscode with rust-analyzer extension. I get multiple real-time debugging info while typing both from rustc and rust-analyzer. I even don't know how to report properly the problems on forums and alike. It's kind of frustrating.

1 Like
5

Aha! I checked the documentation of bbqueue for sources of trouble, and I see it defines a bbqueue::Result. This shadowed (replaced) the usual Result, which the rtic::app macro must have been trying to use. This indicates a bug in the macro; it should be producing references to ::core::result::Result, not unqualified Result.

That said, my personal coding style is that I never write use some_module::* (glob) imports except when some_module is a module I defined in the same crate. This is because of risks like the one above (unintended shadowing, which could affect regular code as well as macro code), and also because it makes code harder to read (you can't tell which names might be shadowed, and if there are two glob imports it's impossible to definitively tell what name comes from where without compiling the program).

Rust error messages try to be helpful, but macros are one of the hardest things to produce good error messages about. (They're also hard for IDEs to help with.) The lesson I think you should take from this is that macros are a thing to use sparingly. Prefer to use libraries that don't demand that you use macros. Arrange so that not much of your code is inside macros (by separating code into functions that the macro-using code calls), and you'll get better support from rust-analyzer.

3 Likes
6

About glob-use, yes, I just realized the same good habit after I've found this bug. It's learning time for me... but despite the newbie frustration, Rust is giving good vibes to me...

Oh, that's a simple lesson: I simply HATE macros of any kind, since EVER. I never mastered preprocessor macros in C when I fist met them back in late 80s. Then, since a girl told me "I macro" referring to her ability to use a book to push the keyboard against the monitor in order for 1 key to repeat all the day long... I decided I wanted to be a better monkey and do not macro, ever.

Problem is I have no idea how to not use them in Rust. I mean, can I start an RTIC app without that macro? It looks like the only way to start an application is to use a macro (ex: #[entry] or #[rtic:app]). What am I missing?

7

I'm not familiar with rtic, but it looks to me like it’s designed so you have to use the macro. What I'm saying is: consider this a reason not to use rtic. Of course, other factors may outweigh this consideration.

And I don't mean to never use macros. Just that it's a tradeoff.

2 Likes
8

@anichang Maybe if you file an issue and it is fixed fairly promptly, your confidence in the crate will be restored. :slight_smile: Looks like they have a chat as well.

9

Why did you link the RTIC issue tracker? If that is a bug, it's a BBQueue bug, am I right?

10

There is nothing wrong with bbqueue::Result. The problem as @kpreid pointed out is that the rtic::app macro "should be producing references to ::core::result::Result, not unqualified Result".

Macros must produce code that reference existing types using their fully qualified names. Otherwise, with unqualified names, your imports (in this case) or your own code might define those unqualified names as well. For example, you are free to defined a Result type of your own and in fact this is common.

1 Like
11

Reported: rtic::app macro "should be producing references to ::core::result::Result, not unqualified Result" · Issue #965 · rtic-rs/rtic · GitHub

Thanks all

1 Like
12

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.