<FrreJacques[m]>
Can one write a crate that provides both an async and a blocking driver and the user can choose?
<FrreJacques[m]>
I guess one could put them in different modules and probably have the ehal_async as optional drpendency.
Ralph[m] has joined #rust-embedded
<Ralph[m]>
<FrreJacques[m]> "Can one write a crate that..." <- i still haven't read it, but i think this link has been handed around a few times already when it came to this topic: https://nullderef.com/blog/rust-async-sync/... (full message at
<FrreJacques[m]>
I ordered me a 40x04 display with dual HD44780 to have a test device for that. After digging around so deeply in this spec, getting the read working, which I think I never saw and the reading the busy flag. I think it should result in something that can be used :). Getting this multi chip lcds working is just the final piece for a somewhat feature complete realization.
<M9names[m]>
<FrreJacques[m]> "Can one write a crate that..." <- if you implement both it doesn't make sense to make e-h-async optional - it's not a heavy dependency and it doesn't change often
<FrreJacques[m]>
M9names[m]: In your reply I only see my own message 🤔
<M9names[m]>
if you implement both it doesn't make sense to make e-h-async optional - it's not a heavy dependency and it doesn't change often
<FrreJacques[m]>
Strange in my reply to you, I see your message.
<M9names[m]>
which client?
<FrreJacques[m]>
Maybe some element bug.
<FrreJacques[m]>
Element on Android
<M9names[m]>
element on android is pretty bad. SchildiChat is basically the same client but it doesn't have that issue, at least
<M9names[m]>
the element folks are focusing on element x so a bunch of stuff doesn't get fixed in the old client
<FrreJacques[m]>
Will have a look. Thought element is the reference with most features implemented although missing multi account management.
<M9names[m]>
SchildiChat is a fork, so it has the same base features
<FrreJacques[m]>
But also no multi account right.
<M9names[m]>
no idea, not something i need
<thejpster[m]>
<matoushybl[m]> "Are there any resources on..." <- the rust reference and the rustonomicon. It's not ideal.
<thejpster[m]>
https://github.com/rust-lang/rust/pull/125579 is in 1.84, so we should be careful to now talk about "Host tuples" and "Target tuples" to describe the foo-unknown-bar-elf strings that rustc uses. The books might need updating.
m5zs7k has quit [Ping timeout: 252 seconds]
m5zs7k has joined #rust-embedded
duderonomy has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
diondokter[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]>
I also just gave flip-link a full expression parser, so everyone trying to do subtraction or other weird arithmetic in your ORIGIN and LENGTH will appreciate that (previously we only handled addition, and we handled it very manually)
<thejpster[m]>
I have had an RP2040 that had blown GPIO pins. Might be worth trying a different chip.
<ted-996[m]>
well, it seems like I've missed the sm.set_pindirs call, just noticed it just now :)) I did not find any such functions on the PIOBuilder :)) Thank you very much, I'll try that now!
<ted-996[m]>
oh yes, this worked, that was a bit stupid of me :)) Thank you for the link!
duderonomy has joined #rust-embedded
<thejpster[m]>
np
<thejpster[m]>
it's a method on the state machine, not the PIO program
<ted-996[m]>
yeah, I just checked, it does this by pushing set pindirs instructions to the state machine manually - that's an interesting way to do it, it explains why I haven't seen anything about pin directions in the RP2040 datasheet
<thejpster[m]>
I think it's how the pico-sdk does it?
<JamesMunns[m]>
(if you are using embassy hals where there is no type for the specific pin, or the hal you use does have an .erase() method)
<FrreJacques[m]>
I have used multiple, because I thought they might could differ.
<FrreJacques[m]>
Because I thought PinA needs to implement OutputPin and PinB needs to implement OutputPin. But they could be different types. If I would use the same generic they would need to be of same type.
<FrreJacques[m]>
Or am I wrong about that?
<dirbaio[m]>
pretty much all HALs have a way to "type-erase" pins so different pins become the same time
<dirbaio[m]>
so the user has to use the turbofish syntax to still specify the `T` type, even if they're passing None: `let bus = Bus::<MyPin>::new(None);`
<dirbaio[m]>
because the compiler can learn what type T is from the some_pin arg.
<dirbaio[m]>
and as a bonus it prevents spam of generic parameters :)
<FrreJacques[m]>
I tried out to define the optional pin to be of same type like it's counterpart and that works.
<FrreJacques[m]>
Not spamming generics would improve readibility a lot. Because I have only three different kind of types. OutputPin, OutputPin+InputPin, DelayNs.
<FrreJacques[m]>
So if I have eg PinA to be embassy::gpio::Output and PinB OutputOpenDrain. And I want one to be the mandatory and the other to be the Some(). Would that work? Or am I start to limitate versatility?
<FrreJacques[m]>
In a short test the compiler complains that the types differ.
<dirbaio[m]>
yeah if the types are different then you need two generic params
<FrreJacques[m]>
And that would work with powerfish syntax, if I understood.
<dirbaio[m]>
yeah... :(
<dirbaio[m]>
you can do some type hacks to avoid it
<dirbaio[m]>
so if the user does new_one_pin(my_pin), the type of IO is forced to be NoIoPin
<dirbaio[m]>
so no turbofish needed
<dirbaio[m]>
another solution is: make a trait Interface with two impls, one with 1 pin and another with 2 pins, and make the main driver generic on that
<dirbaio[m]>
depends on what the driver is for...
<FrreJacques[m]>
I think I do something like the latter already for the main struct. As it gets a type that implements the Bus Trait. And J have different busses that I impl that Trait for.
<FrreJacques[m]>
I could split the struct in two, but then I would need to implement the trait for both with lots of duplication.
<FrreJacques[m]>
I have to leave for some time, will come back later.
<FrreJacques[m]>
Using the same type does not work, if I use the Some() variant. I think thats probably also one reason I specified each type seperately in the first run. The pins have the type Output<_, PAi>. So pin A2 as Output is a different type than having B2 as Output.
<dirbaio[m]>
in embassy-stm32 from git (and in 0.2 soon to be released) it's just `Output<'_>`, same type for all pins
<FrreJacques[m]>
That sounds handy. But I guess one can't expect that behavior for all HALs.
<dirbaio[m]>
pretty much all do
<dirbaio[m]>
in embassy it's automatic, but in most others there's some sort of .degrade() or similar that type-erases the pin numbers
<dirbaio[m]>
and if a hal doesn't have it, it really should, because it's needed for extremely basic stuff like ... making an array of pins
adamgreig[m] has quit [Quit: Idle timeout reached: 172800s]
<FrreJacques[m]>
So you are saying I should expect that Output pins share the same type and current behaviour of the embassy_stm32 is an exception, right? Is there a workaround till 0.2?
<FrreJacques[m]>
I guess using the github version.
<dirbaio[m]>
in embassy-stm32 0.1 you can still unify the pin types doing .degrade()
<dirbaio[m]>
Output::new(p.PA4.degrade()
<dirbaio[m]>
s//`/, s//)`/
<FrreJacques[m]>
In that case reducing to three generics will be feasible again.
<dirbaio[m]>
this gives you an `Output<'_, AnyPin>` for all pins
<FrreJacques[m]>
Ahhh!
<dirbaio[m]>
this is more similar to how other hals work
<dirbaio[m]>
* this `.degrade()` is more
<dirbaio[m]>
in git and upcoming 0.2 it's changed to simply not have the pin as a generic param, so it's always `Output<'_>` and there's no need to `.degrade()`
<FrreJacques[m]>
Okay so I can expect that the amount of pin types for each HAL is limited to a few like Output, Input, etc. and reduce that 10 kind of generics.
adamgreig[m] has joined #rust-embedded
<adamgreig[m]>
hi @room, it's meeting time again! hope you all enjoyed our two week break :) agenda is https://github.com/rust-embedded/wg/discussions/810, please add anything you'd like to discuss or announce and we'll start in a few mins
<FrreJacques[m]>
Thanks a lot for your help, I am learning so much! I will try now to implement some design ideas I had during the day. I have to rework them, because I forgot that I don't have Vec in core.
therealprof[m] has joined #rust-embedded
<therealprof[m]>
FrreJacques[m]: You could have `Vec` by using `heapless`.
<adamgreig[m]>
ok, let's begin! i've rounded up a few cortex-m things that came up over the break, but there was a whole ton of work on svd2rust and riscv too that I'm not in a position to summarise
<adamgreig[m]>
no specific announcements from me though, does anyone have anything to announce first?
adamhott[m] has joined #rust-embedded
<adamhott[m]>
hi all, it's been awhile since I attended a meeting. Just real quick - I'm on the job market
<adamgreig[m]>
heya, good to see you again!
<adamhott[m]>
thanks I got so swamped for quite some months
<FrreJacques[m]>
<therealprof[m]> "You could have `Vec` by using `..." <- Yeah, found that. But I think I found a way to let the user define the areay and work with that.
<burrbull[m]>
adamgreig[m]: During last month I've closed most of old PRs on `stm32-rs` repo. Also made big refactoring of it, updated source archives to correspond to ST.
<adamgreig[m]>
i saw all the prs going past, good work! would you be interested in publishing new crates? maybe we can chat about it after the meeting
<burrbull[m]>
sure
<adamgreig[m]>
ok, couple of new issues on cortex-m that might warrant some eyeballs if anything jumps out at people: a linker failure on armv6 where the hardfault trampoline is too far from hardfault for a branch instruction, which I thought in principle we already guard against in the linker script so suggests something has gone wrong there (or there's another problem in this setup) https://github.com/rust-embedded/cortex-m/issues/572
<adamgreig[m]>
second is someone flagging that using read/write to LR is troublesome, but I think this is the same as most of the core registers (e.g. SP). we could in principle deprecate these methods now that inline asm is stable, but i'm not sure if there's much practical advantage https://github.com/rust-embedded/cortex-m/issues/570
<therealprof[m]>
Oof, we had the too big jumps in the early days of embedded Rust.
<adamgreig[m]>
and finally someone wanting cortex-m-semihosting to use the same one-char-per-u32 that ST's serial viewer uses, which is much more wasteful of bandwidth, but without which you can't use the st tooling to view the semihosting output https://github.com/rust-embedded/cortex-m/issues/571
jannic[m] has joined #rust-embedded
<jannic[m]>
To debug the out-of-range jumps, it would be nice if we had an example reproducing the issue.
<adamgreig[m]>
jannic: what did you want to talk about with the rustweek unconf?
<jannic[m]>
Mara told me that the guest list for the embedded room should somehow be handled by the wg.
<adamgreig[m]>
ah ok, I hadn't heard about it yet but I have a call with erik tomorrow so will probably figure a bit more out then
<therealprof[m]>
I was about to say: You're ahead of us. 😉
<adamgreig[m]>
so I expect we'll talk about it next meeting, but in the meantime a timely reminder to everyone that there will be another rust unconf this year, details https://rustweek.org/unconf/
<jannic[m]>
That's why I'm mentioning it :-)
<adamgreig[m]>
if you attend you'll get to watch rust 1.87 be released live on stage apparently
<jannic[m]>
What could possibly go wrong?
<adamgreig[m]>
😬
bartmassey[m] has joined #rust-embedded
<bartmassey[m]>
Can only stay a minute because I have a class at noon again this quarter: this is our first meeting. Apologies.
<bartmassey[m]>
There's supposed to be another Discovery Book Sprint in a bit. I'm tempted to put it off, as there's only three people signed up so far last I checked (thank you!) and I'm not really caught up on my end yet.
<bartmassey[m]>
Thoughts?
<adamgreig[m]>
I'm happy to postpone it a bit
<adamgreig[m]>
I can't do the 1st feb (the week directly after) but could do any of the weeks after that
<adamgreig[m]>
in fact it would be kinda convenient for me to postpone it too....
<bartmassey[m]>
Done. I will announce the new time far enough in the future that everybody should be able to get in. I would love to have five or more this time: it makes things much faster. Message me here anytime if you have ideas or concerns.
<jannic[m]>
As you mention 1st feb: Anyone going to FOSDEM?
<adamgreig[m]>
any other points for this meeting?
<adamgreig[m]>
if not let's finish there, hope you are all having a good 2025 and see you next week!
kenny has joined #rust-embedded
<thejpster[m]>
Renesas says I can’t program my board because a bit has been set that protects it from being debugged or flashed.
<thejpster[m]>
I didn’t set that bit. At least, not deliberately.
<jannic[m]>
But I'm just skimming through that manual. I may miss important details. Eg. section 35.6.3 seems to imply that it shouldn't even be possible to write directly to that address. "Flash area protection". I don't understand if this protection always applies or if it can be disabled.
<thejpster[m]>
Oh. Uh. I think I had my flash base address set to zero.
<thejpster[m]>
You’d think connecting under reset would bypass such checks.
crabbedhaloablut has quit []
<thejpster[m]>
Oh no. I wonder if I ticked the config memory box.