Allow splitting Serial into Reader and Writer

[lights0123]

I'm doing some fun stuff with async/await and came across the need to have one task reading separately from writing without blocking the other.

[Rahix]

I'm doing some fun stuff with async/await and came across the need to have one task reading separately from writing without blocking the other.

Just out of curiosity: I was also playing around with that but I'm running into tons of miscompilations (at least as far as I can tell ...). Do you mind sharing you approach if you have something working?

[lights0123]

@Rahix I'm working on a blog post about getting this to work, but here's what I have so far. I didn't run into a single compilation problem, and have async UART and SPI working just fine. My next step is to get interrupts working so it can go to sleep when not running a task, but I'll need to work on getting timers working before then.

[Rahix]

I see, you've chosen a different design from what I tried, which does not need trait objects. Because that's probably what bit me: rust-lang/rust#74743

I have to say, this looks really cool!

[Rahix]

The code looks good, I just have one minor nit: You have mixed indentation with both tabs and spaces. Please convert that to all-spaces to put it in line with the rest of the code base.

Apart from that, we are good to go! Thanks a lot for the PR! :)

[lights0123]

Fixed—IntelliJ decided to ignore the existing indentation style.

[lights0123]

@Rahix here's my blog post in case you're interested: https://lights0123.com/blog/2020/07/25/async-await-for-avr-with-rust/

[Rahix]

Really cool! I hope to iron out the remaining uglyness of getting avr-device to work and finally get it published to crates.io, soon. And then, avr-hal as well, of course.

[Rahix]

For waking up your tasks, maybe the leonardo-interrupt example I recently added helps?

[lights0123]

Yeah, I know how to do it, I just need to do it. I think I'm going to send a PR here to expose an API in the Usart* structs to enable interrupts (because you overwrite previously set control registers), and then have a global function in my crate that you call for each interrupt type (i.e. "I got a byte from a serial port!"). I just need to figure out if I want to have a global e.g. 32-byte buffer in case the task isn't resumed in time (a la Arduino) or just wake up the task.

I would prefer, though, if your interrupt macros took an interrupt name and then figured out how to map that to the chip (I think you have everything you need to do that, because you have feature flags), i.e. this. Also, is there any need for the interrupt handlers to always be unsafe?

Also, would it be possible to use form, svd2rust, and atdf2svd as build deps, and figure out a way to get around the pyyaml requirement? That would be amazing.

[Rahix]

I think I'm going to send a PR here to expose an API in the Usart* structs to enable interrupts (because you overwrite previously set control registers)

Ouch, true ... Yeah, please do!

would prefer, though, if your interrupt macros took an interrupt name and then figured out how to map that to the chip (I think you have everything you need to do that, because you have feature flags)

Hm, not sure if that is possible. The interrupt names collide between different chips and because of how cargo's features work, this can be tricky. Originally I only allowed a single feature to be enabled, but that would also lead to its own issues ... If you have a solution, feel free to send a PR, though!

Also, is there any need for the interrupt handlers to always be unsafe?

Huh, that should not be necessary? If it is, that's a bug in the macro.

Also, would it be possible to use form, svd2rust, and atdf2svd as build deps, and figure out a way to get around the pyyaml requirement? That would be amazing.

That's what I'm working on right now; once ready for crates.io, none of those dependencies will be needed anymore :)

BTW, don't forget to submit your blog post for TWiR!

[lights0123]

Oh yeah, I misread this line and thought that it said that unsafe was required instead of what it actually is, optional.

https://github.com/Rahix/avr-device/blob/c314463726a2867b038b243f818b1f999c8ca22a/macros/src/lib.rs#L63