<NiaLinaLunaStorm>
wait that stuff wants me to clone parts of the repo? I can't just like write little things into the Cargo.tomp and am fine?
<barnabyw[m]>
if you’re talking about embassy, you can include it in your project as a dependency in Cargo.toml
<GrantM11235[m]>
<barnabyw[m]> "what operating system are you..." <- Kubuntu also, but I don't remember if it was the flatpak. I think at some point I got it to run, but then I couldn't download the data pack for the chip I was using because I needed to sign in or something. I just gave up and went back to reading the datasheet
<NiaLinaLunaStorm>
taken their toml file, that did that, it specifies paths
<barnabyw[m]>
yep, that’s because it’s an example file in a monorepo so it can import the other crates locally
<GrantM11235[m]>
Now that everything is published on crates.io, I think you can just get rid of all the paths
<barnabyw[m]>
you should be able to just remove the path parts to install via crates
<barnabyw[m]>
GrantM11235[m]: interesting, maybe they improved the packaging recently? although now I look at it, the “latest” version in discover is from exactly a year ago
<barnabyw[m]>
* you should be able to just remove the path parts to install via crates.io
<NiaLinaLunaStorm>
> the package `embassy-stm32f1-examples` depends on `embassy-stm32`, with features: `stm32f103ret6` but `embassy-stm32` does not have these features.
<NiaLinaLunaStorm>
okay, so it just dislikes the full version and just wants part of it
<NiaLinaLunaStorm>
it's building...
<NiaLinaLunaStorm>
and it throws a bunch of errors despite basically using the unmodified example (apart form the frequency stuff)
<barnabyw[m]>
what exactly did you do to get to this point? could you put your whole project folder on github? would be much easier to figure out what the problem is if we can see all the files involved
<GrantM11235[m]>
That's weird, try cargo clean
<NiaLinaLunaStorm>
barnabyw[m]: download the cargo.toml and the example, change the frequencies and removed the path, `rm -r target` und `cargo run`
<NiaLinaLunaStorm>
I don't trust github with my code anymore and my own git server is down (cause DNS issue)
<barnabyw[m]>
try it with those, they’re necessary to tell cargo how to build the project
<barnabyw[m]>
there’s a guide to creating a new embassy project based on an example, which is slightly out of date, but IIRC is still valid other than the dependency pinning part https://embassy.dev/book/dev/new_project.html
<NiaLinaLunaStorm>
iirc stm32 hal thingy asked me to write into the .cargo something file for configuring some of the debugger stuff?
<Lister_>
does anyone here know some tips on debugging I2C? I'm trying to get a BME280 to work, and I keep getting I2c (acCheckFailed)
<barnabyw[m]>
oh and rust_toolchain, which is only necessary if you want to use nightly rust (which can be very useful for embassy if you’re using async stuff so that you don’t have to worry about the task arena, but cross that bridge when you get to it)
<GrantM11235[m]>
Do you still get exactly the same "found invalid metadata files" after cargo clean?
<NiaLinaLunaStorm>
NiaLinaLunaStorm: yep, this one uses probe-rs which I didn't get to work here, despite people helping
<NiaLinaLunaStorm>
GrantM11235[m]: did this and the steps barnabyw suggested, will see
<NiaLinaLunaStorm>
and yes, get still the same error
<GrantM11235[m]>
Maybe there is something wrong with your installation of cargo/rustc? It's a really weird error
<GrantM11235[m]>
Did you install it with rustup?
<NiaLinaLunaStorm>
yes
<barnabyw[m]>
I’d assume cargo+rustc are okay given that you were almost building your stm32f1xx_hal project, with no weird errors like this
<GrantM11235[m]>
Yeah, but I don't understand how switching to embassy-stm32 could cause a problem like this
<GrantM11235[m]>
Maybe try deleting Cargo.lock and cargo clean again?
<barnabyw[m]>
<NiaLinaLunaStorm> "okay, so it just dislikes the..." <- also wonder if whatever changes this is referring to might have something to do with it – can you paste your Cargo.toml (if Grant’s last suggestion doesn’t fix it)
<NiaLinaLunaStorm>
GrantM11235[m]: still the same error
<GrantM11235[m]>
What version of cargo do you have? (cargo --version) Do you have any rustup overrides? (rustup override list)
<NiaLinaLunaStorm>
cargo 1.73.0, no overrides
<GrantM11235[m]>
Try updating everything with rustup update. IDK if it will help, but I don't have any other ideas 🤷
Lister_ has quit [Quit: WeeChat 4.2.1]
<NiaLinaLunaStorm>
nope 😔
<NiaLinaLunaStorm>
this feels like last time where someone suggested using probe-rs and then nothing works and I had to go back to openocd
Lister has joined #rust-embedded
<barnabyw[m]>
error[E0412]: cannot find type Result in this scope really looks like a target mismatch or something, where rustc can’t find core? but if you copied and adjusted .cargo/config.toml and could build stm32f1xx_hal projects then that seems unlikely
<barnabyw[m]>
* error[E0412]: cannot find type Result in this scope really looks like a target mismatch or something, where rustc can’t find core? but if you copied and adjusted .cargo/config.toml and could build stm32f1xx_hal projects then that seems unlikely
<barnabyw[m]>
* error[E0412]: cannot find type Result in this scope really looks like a target mismatch or something, where rustc can’t find core for that platform? but if you copied and adjusted .cargo/config.toml and could build stm32f1xx_hal projects then that seems unlikely
<barnabyw[m]>
never seen rustc say mommy knows you're feeling down, but you'll get through it~ ❤️ before 👀
<NiaLinaLunaStorm>
starting to hope that I didn't completely break the stuff and can go back to my old stm32-hal thing without trouble, if we don't get anywhere
<barnabyw[m]>
I guess you already tried running rustup target add thumbv7m-none-eabi again?
<adamgreig[m]>
is the target only installed for one toolchain and not the one being used?
<NiaLinaLunaStorm>
there's also cargo mommy for cargo which kinda does the same :D
<NiaLinaLunaStorm>
barnabyw[m]: yes
<adamgreig[m]>
like a rust-toolchain.toml setting a nightly toolchain but thumbv7m-none-eabi only installed for stable
<NiaLinaLunaStorm>
don't see such a toml file in here
<barnabyw[m]>
in this case they’re trying to run embassy examples from the embassy repo, so there shouldn’t be any overrides
<barnabyw[m]>
since the switch to stable by default in embassy
<NiaLinaLunaStorm>
is there any chance or should I go to the pin type mess of the stm32 hal?
<adamgreig[m]>
is RUSTFLAGS set in your env?
<adamgreig[m]>
it's sure a weird problem
<NiaLinaLunaStorm>
I didn't set it, let me check anyways
<NiaLinaLunaStorm>
nope
<NiaLinaLunaStorm>
not set
<adamgreig[m]>
:/
<NiaLinaLunaStorm>
rolled back my code and now this doesn't work anymore either 😭
<NiaLinaLunaStorm>
and I thought I might fix this tonight but now it's 2 am and all wasted time cause I thought this was easier...
<NiaLinaLunaStorm>
100% like when tried to use probe-rs
<NiaLinaLunaStorm>
this sucls
<NiaLinaLunaStorm>
* this sucks
<NiaLinaLunaStorm>
now I can't even fix my other code cause rust broken 😭
<adamgreig[m]>
what OS are you on?
<adamgreig[m]>
this does suck :( usually this experience is one of the best parts, it typically works way better and more easily than usual C toolchains and stuff like openocd
<adamgreig[m]>
but this seems extremely weird and inexplicable so it's presumably something really weird and/or cursed
<adamgreig[m]>
you could just try deleting ~/.rustup and ~/.cargo and starting fresh...
<barnabyw[m]>
or trying the good ol’ “reboot the computer and see if that clears some transient error” technique
<NiaLinaLunaStorm>
that aren't Nix paths, should be fine
<NiaLinaLunaStorm>
just found out that my other stuff used to run nightly
<NiaLinaLunaStorm>
knew there was something about the nightly thing
<NiaLinaLunaStorm>
oki, somehow managed to get it back
<NiaLinaLunaStorm>
which means I'm back at my initial question, just wasted 3h of good motivation (rare that I have that at all) and sleep
f0rte[m] has joined #rust-embedded
<f0rte[m]>
Hey guys, I'm using embassy with the esp-idf-hal, the whole tedium of passing peripherals between tasks has me rethinking if I should even be using rust, is there any way to forego the Option(peripheral) bit with the mutex by using static cell in a way that allows reuse? Or am I doomed to hoping I remember curly braces?
<NiaLinaLunaStorm>
I rolled EVERYTHING back and now I'm back at my stm32 hal code and the issue 2 messages above
<f0rte[m]>
if you've got access to github CI or can try a build on a docker host, it's the easiest way I've found to determine "has my level of mutilating my OS for personal preference screwed me out of expected functionality" or not. Boring as it is, a vanilla ubuntu stable container with rustup could help eliminate variables.
<NiaLinaLunaStorm>
don't have that
<NiaLinaLunaStorm>
but cargo builds again
<NiaLinaLunaStorm>
I've thrown away that embassy crap which wasted my time, I want my code I had before this waste to work
<f0rte[m]>
<NiaLinaLunaStorm> "I've thrown away that embassy..." <- that's what git branches are for
<adamgreig[m]>
your specific error seems to be saying "you've made an AnalogPin but you're passing it to somethign that wants a (digital) InputPin, and it's not that"
<adamgreig[m]>
but it's hard to say more without a bit more context
<NiaLinaLunaStorm>
f0rte[m]: why would I keep a branch for shit that doesn't work and is just a copy of an example anyways?
<NiaLinaLunaStorm>
adamgreig[m]: yes, been that far. I want an analog pin in this case but I can't get the right type for the array
<adamgreig[m]>
so you can spell it out as stm32f1xx_hal::gpio::ErasedPin or you can use stm32f1xx_hal::gpio::ErasedPin and then write it as ErasedPin in the array type
<NiaLinaLunaStorm>
adamgreig[m]: that's are different docs than which got than with the initial suggestion
<adamgreig[m]>
if you click the ErasedPin link in the return type from that function, you get the link I sent
<NiaLinaLunaStorm>
I don't really understand rust docs yet
<adamgreig[m]>
in stm32f1xx-hal, the pin number is encoded in the type, which means it can be carried around as a compile-time constant and takes no memory, but makes types less convenient for things like passing to functions and putting in arrays. in embassy, the pin number is stored in the pin struct at runtime, so it's potentially a bit less efficient but makes the types simpler to use
<adamgreig[m]>
you don't need `&dyn` because ErasedPin is a specific type, not a trait
dngrs[m] has joined #rust-embedded
<dngrs[m]>
don't use dyn
<f0rte[m]>
adamgreig[m]: Does that hal offer a downgrade option on a peripheral? Could be an idea.
<dngrs[m]>
(I mean, use it when you know you need it, but on embedded it will probably cause you mostly pain)
<adamgreig[m]>
f0rte: yes, the erase() method we're talking about
<NiaLinaLunaStorm>
okay, that fixes this
<adamgreig[m]>
InputPin from before is a trait from the embedded-hal crate, an "interface" that lots of different types implement to make them all have the same common "gpio input" methods, but the array needs to be generic over exactly what type, so you can say "&dyn" to mean "resolve it at runtime using a vtable" basically
<NiaLinaLunaStorm>
dngrs[m]: idk if I need it (or even what it does) I just took it from the example code
<dngrs[m]>
NiaLinaLunaStorm: which example code?
<adamgreig[m]>
but since ErasedPin is an actual type, you don't need vtables or anything, you can just store them in the array directly
<dngrs[m]>
ah, ok. Yeah, I can see how it's not obvious that you need to remove the keyword then
<f0rte[m]>
<f0rte[m]> "Hey guys, I'm using embassy with..." <- If anyone has insight I'd be grateful :)
<f0rte[m]>
Open to other suggestions as well, e.g. should I use static_cell on the peripheral then create a driver inside each task? Or should I put the driver in the static_cell? Should I stop trying to use static_cell and just use the mutexes directly despite the wonkyness?
<f0rte[m]>
> <@f0rte:matrix.org> Hey guys, I'm using embassy with the esp-idf-hal, the whole tedium of passing peripherals between tasks has me rethinking if I should even be using rust, is there any way to forego the `Option(peripheral)` bit with the mutex by using static cell in a way that allows reuse? Or am I doomed to hoping I remember curly braces?
<f0rte[m]>
* If anyone has insight I'd be grateful :)
<f0rte[m]>
Open to other suggestions as well, e.g. should I use static\_cell on the peripheral then create a Pindriver inside each task? Or should I put the driver in the static\_cell? Should I stop trying to use static\_cell and just use the mutexes directly despite the wonkyness?
<f0rte[m]>
dngrs[m]: I did see that, but in their example it looks like they re-defined every pin function, I'd rather not have to do that as embedded-hal has done a pretty good job of that already haha.
<f0rte[m]>
* pin function used, I'd
<f0rte[m]>
With the channel example, I'd be limited to functions defined in that enum right? (in the example, just toggle)
<dngrs[m]>
f0rte[m]: yes, you're mapping enum variants to function calls, so you need to spell them out
<adamgreig[m]>
f0rte: depends what you need to share between tasks, I usually find I can avoid sharing any peripherals between tasks and instead having tasks that communicate at a high level
<dngrs[m]>
yeah, that's a good point
<f0rte[m]>
Hey happy to add bookmarks for later reading, thanks. But I'm basically just trying to be able to use "peripheral A" in different tasks based on what the user has selected. I know rust is trying to be safe and not fight over access to a single resource, but I'm never running a peripheral-consuming task alongside another task that consumes the same peripheral.
<dngrs[m]>
you could send your entire peripheral over then
<f0rte[m]>
yeah, like the mutex example right? Which brings us full-circle
<dngrs[m]>
no, that's not what I meant
<f0rte[m]>
I just really hate having to use Some() haha, I'd rather use static_cell if possible to get something a little more intuitive.
<f0rte[m]>
dngrs[m]: Ah? If you don't mind elaborating, would love to learn more.
<dngrs[m]>
wait, let me dream up some example
<f0rte[m]>
or do you mean the underlying peripheral from the take but not the peripheral as it is "driven"?
<adamgreig[m]>
or only start the task that you're using?
<adamgreig[m]>
spawn the task and pass in the peripheral, when that task is done it can return the peripheral and you can give it to the next task
<dngrs[m]>
adamgreig[m]: yeah that's what I was going for
<dngrs[m]>
too tired to write a quick example tho
<f0rte[m]>
adamgreig[m]: can embassy do that? If it can, I lack the know-how to do it. In esp-idf-hal it's not quite "reference embedded-hal" they separate the pindriver from the underlying peripheral
<f0rte[m]>
adamgreig[m]: ah... duh. Haha you mean make the the task function spit the peripheral back out when it exits like a Result? That's a little odd but I can try it.
<adamgreig[m]>
sure. doesn't need to be in a result but it could be
<adamgreig[m]>
you can think of it as just taking it for a bit and then giving it back
<adamgreig[m]>
if the lifetimes were simpler to track across tasks you could give it a &mut and then when the task finished you could re-lend the peripheral, but I think that might not work, so better to pass it entirely in and then get it back afterwards
<f0rte[m]>
I understand the concept at a high level, but not really sure how this is better than the embassy-mutex route. I did try the &mut route, unfortunately it complained about lifetimes. Using static_cell let the first task take the peripheral, but I couldn't wrestle it back from the task after it took it.
<f0rte[m]>
adamgreig[m]: I'll give this a try. Thanks :)
<adamgreig[m]>
but you're using an STM32F1 microcontroller and the stm32f1xx-hal crate, which is a completely different library and doesn't happen to have a method called count_down
<adamgreig[m]>
f0rte: there's no runtime checking or locking or static variables or anything, you just pass around ownership of the peripheral, so the compiler can easily see it's never used in two places at once
<adamgreig[m]>
seems worth a go anyway
Lister has quit [Ping timeout: 256 seconds]
<f0rte[m]>
adamgreig[m]: I don't want to abuse your generosity, but if you had a 3 line pseudocode example it would save my liver some abuse :P
<adamgreig[m]>
Nia / Lina / Luna / Storm / Lexi: it looks like you could probably do without the delay anyway though, so maybe just have the loop run all the time without waiting as a simple alternative
<f0rte[m]>
adamgreig[m]: so taking this route, I'd be using static_cell but _not_ the embassy mutex right?
<dngrs[m]>
you'd just pass around the peripheral, no need for a cell
<dngrs[m]>
like
<dngrs[m]>
on a very abstract level:
<adamgreig[m]>
I'm trying to check if you can actually return the peripheral from the task 🥲
<adamgreig[m]>
yea, you can just do it using async fns in the same task, so unless you need literal concurrency due to running in different InterruptExecutors that should be OK?
<adamgreig[m]>
though if it's just async fns and not tasks, this is silly and you can just pass &mut led to each fn instead
<NiaLinaLunaStorm>
NiaLinaLunaStorm: thanks, it shows up as USB HID device
<NiaLinaLunaStorm>
now I need to figure out that report
<f0rte[m]>
adamgreig[m]: in my situation, I have my primary thread awaiting an interrupt while my task runs blink patterns, so unless I'm mistaken, I do need the concurrency.
<f0rte[m]>
If I need the mutex like the docs say, I need the mutex. Is there a way I can avoid the Some() though? I was able to make the mutex inside the static_cell fine and avoided the Some() but I couldn't get the peripheral back after the task used it, but might be just because I am missing something basic. If I'm not mistaken, the only reason I would need Some is because the mutex needs something when it is defined as a static, so
<f0rte[m]>
None is used, but if I use static_cell, I can avoid having a value in the static right away.
<adamgreig[m]>
I think in principle that's still fine, you can await multiple async fns at a time using select for example, but perhaps there's some other architecture for your problem which will work better
<adamgreig[m]>
do you have some code where you have the static_cell mutex and can't get the peripheral back after the task used it?
<f0rte[m]>
I could whip up a stripped down example if that would help
<f0rte[m]>
yeah give me a sec
<adamgreig[m]>
if you use the Option you can literally put the peripheral back after the task is finished with it which might work out for you, if you have the static_cell I'm not sure how you're ever taking it out to begin with
<f0rte[m]>
adamgreig[m]: `magic`
Lister has joined #rust-embedded
<NiaLinaLunaStorm>
<NiaLinaLunaStorm> "now I need to figure out that..." <- not sure how to do that with analog inputs. there's joystick report which I could use for now BUT... it has only 2 axis which is enough for this little test with only 2 pots hooked up but I will need a different solution for the future cause I need more than just those 2 axis
<NiaLinaLunaStorm>
also it's only i8 so a 16th of the resolution of what the stm32 is capable off
<f0rte[m]>
I feel like I'm probably missing something basic with rust ownership.
<f0rte[m]>
ah, I missed this in the example, but the "toggle" in main would not happen until the mytask exited, I have a bunch of other stuff going on but that thread is blocked.
<adamgreig[m]>
fundamentally the problem is you don't have any synchronisation here to ensure that you aren't calling toggle twice at the same time, so the compiler has to reject this one way or another
<f0rte[m]>
Ha. I miss C. Just trust me bro.
<adamgreig[m]>
once the task is spawned, it's off running in its own world, there's no link to you later waiting for something else
<f0rte[m]>
the await in main is on a signal that is triggered by mytask.
<adamgreig[m]>
what error did you get with this though?
<f0rte[m]>
that's the funny part. No errors.
<f0rte[m]>
It compiles and the first loop runs in hardware just fine. It just refuses to re-invoke the task. Some kind of silent failure I am guessing with owning the peripheral a second time.
<adamgreig[m]>
my gut feeling is you should try for a different architecture, and that embassy+async does make reasoning about some of this sharing a bit different to how you might do it elsewhere, but failing that a mutex+option lets you take the peripheral out in the task, use it, then put it back into the option, and later you can take it out in main too. because option might be none, you're forced to handle the case where the peripheral
<adamgreig[m]>
wasn't present to be taken out, and thus the option is providing the synchronisation
<adamgreig[m]>
uh, that's pretty odd. I guess you have a debugger hooked up so would see panic messages? are you sure this is even the problem?
<f0rte[m]>
Yeah, I'm running with debug enabled, no errors. In fact my other tasks that aren't trying to re-use peripherals still exit after the "bugged" situation as well. It doesn't crash. That task and that peripheral just stop working.
<adamgreig[m]>
I think something might be a bit wrong in your example because `led` in `mytask` has type `Mutex<PinDriver<...>>` and that doesn't implement `toggle()`
<f0rte[m]>
The underlying PinDriver does though.
<adamgreig[m]>
so perhaps what's missing from your code above is actually locking the Mutex, and you're ending up in a deadlock or something like that
<adamgreig[m]>
could you paste the actual example that hangs?
<f0rte[m]>
adamgreig[m]: That could be it. But the rest of the loop does seem to function. In my actual code I'm not toggling in main, I'm using actually the same task but invoked in a different context with the same peripheral, and watching the hardware, the light doesn't blink. But the other pins/buttons attached to other tasks/and debug messages I have defined still behave just fine.
<f0rte[m]>
It doesn't hang. The led just stops behaving as expected :P It's just that peripheral.
<adamgreig[m]>
it sounds like something's hanging. are you running the same task twice then?
<f0rte[m]>
Yes I am. But not concurrently.
<adamgreig[m]>
after you call lock() on the mutex the first time, any future calls to lock() will wait until the result of the first lock is dropped
<adamgreig[m]>
you could use try_lock and print an error to show you when it's hitting that condition
<f0rte[m]>
adamgreig[m]: does a task finishing not drop a lock?
<adamgreig[m]>
but if you're having it wait forever on lock(), that suggests something has not released the lock
<f0rte[m]>
I'm also going to get rid of the .ok on my spawner. That's probably not helping either
<f0rte[m]>
Thanks a ton for the insight so far Adam, I'll try some due diligence for now. Thanks again!
<adamgreig[m]>
yea, if the spawn is returning an error (did you use #[task(pool_size=2)] if you're ever spawning it concurrently?) that could also cause confusion
<adamgreig[m]>
Nia / Lina / Luna / Storm / Lexi: hm, annoyingly it looks like stm32f1xx-hal doesn't support doing an ADC read on an ErasedPin, only doing digital read/write
<adamgreig[m]>
you might find it easier to make a struct that contains all the pin types you're using and pass that to the function, then at least it's only written in one place and it's easy to update
Lister has quit [Ping timeout: 264 seconds]
<f0rte[m]>
FOUND IT!
<NiaLinaLunaStorm>
adamgreig[m]: how do I do that (am completely new to rust, never written my own struct)
<f0rte[m]>
It had to do with how I was handling signals. So I guess PSA, using a while on a signal.signaled() does not clear the signal.
<adamgreig[m]>
<f0rte[m]> "Ha. I miss C. Just trust me bro...." <- 🫡
<adamgreig[m]>
that could be clearer in the docs, heh. I think you want to use try_take or wait
<f0rte[m]>
* It had to do with how I was handling signals. So I guess PSA, using a while on a signal.signaled() does not clear the signal. I tossed a signal.reset() in the end of my task and it behaves correctly now.
<adamgreig[m]>
Nia / Lina / Luna / Storm / Lexi: `struct MyPins { pa0: gpio::Pin<'A', 0, Analog>, pa1: gpio::Pin<'A', 1, Analog> }` and `let pins = MyPins { pa0, pa1 };` and then `fn my_thing(pins: Pins)` and then `adc1.read(&mut pins.pa0)`
<adamgreig[m]>
or something along those lines
<adamgreig[m]>
bedtime here, good luck both!
<NiaLinaLunaStorm>
thanks for your help
<f0rte[m]>
adamgreig[m]: ah yeah, the thing is that in this case I'm using the signal both in a blocking and a non-blocking way inside the task, since the LED is blinking codes, the led blinking correctly is more important than catching the signal quickly, so I have my led functions inside a simple while `signal.signaled() == false` loop, but when that loop exits when I get the signal, the signal in the static is not cleared, so the second
<f0rte[m]>
invocation of the task exits immediately forever.
<adamgreig[m]>
you can while let None = signal.try_take() if you don't actually care about the value being signalled
<f0rte[m]>
ooooooh
<f0rte[m]>
I'll give that a look, thanks again!
<adamgreig[m]>
or otherwise something like `loop { match signal.try_take() { Some(_) => break; None => do LED stuff }}`
<adamgreig[m]>
but the first one is a bit shorter
<f0rte[m]>
that somehow looks more convoluted than my (already convoluted) code is though >_< I have the memory of a goldfish, so code I can come back to and infer the function of is a lifesaver >_<
<adamgreig[m]>
or just while signal.try_take().is_none() lol
<f0rte[m]>
ah now there's a gentleman's solution
<f0rte[m]>
while signal.try_take().is_none() it is.
<f0rte[m]>
could that also be a == None?
<dngrs[m]>
<NiaLinaLunaStorm> "how do I do that (am completely..." <- I would suggest learning a bit more Rust first, diving straight into embedded is probably going to cause a lot of frustration otherwise. I recommend the [interactive book](https://rust-book.cs.brown.edu/)
<f0rte[m]>
Ah darn, that actually won't work because I am using dummy enums as my placeholder signals, so they aren't None, I've got some cleanup to do, but solutions finally! Thanks again.
<NiaLinaLunaStorm>
<dngrs[m]> "I would suggest learning a bit..." <- don't like such books, always need an application I'm interested in else I loose interest in a matter of minutes (was the same with the PCB design... went straight for a more complex with with microcontroller and all its support for it on board instead of using like one which can just be added via a pin header)
<dngrs[m]>
I totally get the "need interesting application" part, I'm the same
<dngrs[m]>
but Rust is gonna be hard to learn with just that
<dngrs[m]>
anyway, whatever floats your goat
<NiaLinaLunaStorm>
I need to convert u16 to i8 but it says its not implemented, I've found this crate: https://crates.io/crates/checked_int_cast which seems to do what I want but it doesn't build, presumably cause it uses std... any idea how to get that cast working?
<f0rte[m]>
NiaLinaLunaStorm: That's a pretty lossy conversion. Obligatory "are you sure that the u16 number will always fit inside an i8 one?" The max values between those two types are quite different.
<NiaLinaLunaStorm>
I get max 4096 from the adc and I devide it by 16 so max 256 which is 2^8
<NiaLinaLunaStorm>
and ik it's lossy and I want a different way but for that I've gotta figure out more HID stuff, rn I'm just using the JoystickReport which expects an i8
<f0rte[m]>
and that 256 is with pos/neg values as a range, only goes 128 one direction.
<dngrs[m]>
your_u16 as i8
<NiaLinaLunaStorm>
f0rte[m]: oh, crap so divide by 32 it is
<f0rte[m]>
uhhh
<f0rte[m]>
it really depends on what you're trying to do haha
<dngrs[m]>
totally
<dngrs[m]>
2s complement etc yadda yadda
<f0rte[m]>
don't forget, bitshifting is cheaper than dividing ;P
<NiaLinaLunaStorm>
I try to get potentiometer position into an i8 so it can get transmitted via USB joystick thing
<dngrs[m]>
f0rte[m]: the optimizer really should catch that, at least gcc was smart enough when I tried it in 2003
<f0rte[m]>
NiaLinaLunaStorm: this is for something like setting volume?
<f0rte[m]>
like what result are you trying to get? a percentage of a position of the pot?
<NiaLinaLunaStorm>
rn is the goal to learn this stuff
<NiaLinaLunaStorm>
goal in total is to have it report its position so I can then map it to cockpit controls in flightgear
<NiaLinaLunaStorm>
the joystick thing is just a stop gap to at least have a little success this night
<f0rte[m]>
do you know the precision of the pot signal? like how many positions/unique readings can you get from the pot that are distinct along the range of it's available positions?
<NiaLinaLunaStorm>
cause I can't figure out the other HID mode where I can send stuff with higher precision
<NiaLinaLunaStorm>
f0rte[m]: the adc in the stm32 can do 4096
<NiaLinaLunaStorm>
but I don't care about loss in precision rn, I just want it to report SOMETHING!
<f0rte[m]>
simplest would be a match on values through the range, if you just want something like "high, medium, low" as a proof of concept
<f0rte[m]>
or just printing the value with a println.
<NiaLinaLunaStorm>
don't get debug prints here unless I do the serial print again
<NiaLinaLunaStorm>
that did work
<NiaLinaLunaStorm>
kinda, not well but enough to have it control the sim but that was as well just a test and HID was always planed
<f0rte[m]>
if you don't need the precision in the first place, might be able to just read it as whatever type you're trying to work with
<f0rte[m]>
I'd use an unsigned type though for sure though
<NiaLinaLunaStorm>
I can't use unsigned cause this thing expects signed!
<f0rte[m]>
right but you don't want to (and probably can't) read the pot as a signed value
<NiaLinaLunaStorm>
and idk how to make it read it as such, it complained about things if I was like var: I8 = read()...
<f0rte[m]>
so you'd want to read it as double the signed value and as unsigned
<NiaLinaLunaStorm>
confused
<f0rte[m]>
so what is a pot? it's just a variable resistor right?
<f0rte[m]>
the values your chip are reading are all positive and in a range between the pot's minimum position and maximum position.
<NiaLinaLunaStorm>
f0rte[m]: yes
<f0rte[m]>
You ultimately want an i8, I assume that this is for the joystick to have a neutral position somewhere in the "middle" of the pot, with negative (down) values and positive (up) values?
<NiaLinaLunaStorm>
I don't care if I use just half the range!
<NiaLinaLunaStorm>
it's just temporary anyways to have some SUCCESS!
<dngrs[m]>
as i8
<NiaLinaLunaStorm>
yes
<NiaLinaLunaStorm>
am further
<NiaLinaLunaStorm>
but things still complain at me
<dngrs[m]>
at least send us the error message then
<NiaLinaLunaStorm>
dngrs[m]: ik, I've been following it step by step and I don't know what it's exactly telling me in many cases but I've followed the suggestions and then it was happy and gave the next error... but here idk what to do
<dngrs[m]>
the error has nothing to do with numeric conversion
<NiaLinaLunaStorm>
ik
<NiaLinaLunaStorm>
I've got past that already
<NiaLinaLunaStorm>
with its help.... eventually
<NiaLinaLunaStorm>
which is why how this monstrosity came to be
<dngrs[m]>
<NiaLinaLunaStorm> "and idk how to make it read it..." <- that was a very misleading message then
<dngrs[m]>
anyway, _embedded_hal_adc_OneShot is not something you should use (the leading underscore is a hint that this is internal stuff)
<NiaLinaLunaStorm>
thats what the compiler told me!
<NiaLinaLunaStorm>
I've got exactly 0 clue what I'm doing here!
<NiaLinaLunaStorm>
and I'm really tired cause it's 5am... just want this to work so I have some success
<dngrs[m]>
sorry to be blunt but you really need to learn more Rust if you want to get this to run
<dngrs[m]>
the actual problem you're facing is that the compiler has no idea what Word is in that context
<NiaLinaLunaStorm>
ik
<NiaLinaLunaStorm>
dngrs[m]: but I can't make that happen tonight! I'm already feeling really shit and need success
<NiaLinaLunaStorm>
dngrs[m]: yes, but idk how to tell it that
<NiaLinaLunaStorm>
when something like this came up in the past it was always a missing use
<dngrs[m]>
and absolutely get some form of logging going, otherwise: endlessly more frustration
<NiaLinaLunaStorm>
dngrs[m]: already did that! in connection with PWM control... and with usb serial!
<dngrs[m]>
the example I linked uses hprintln which is pretty slow, the general consensus is that defmt is the go to solution, but setting it up is kinda involved, so stick to hprintln for now I'd say
<NiaLinaLunaStorm>
dngrs[m]: that was just a few hours wasted time too, getting probe-rs to run... ik how to debug this thing without text output
<NiaLinaLunaStorm>
rn I'm using openocd with swd interface
<dngrs[m]>
my suggestion would be to sit with the frustration and go to bed
<dngrs[m]>
it's what I'm doing anyway, since 5am here too
<NiaLinaLunaStorm>
inacceptable!
<dngrs[m]>
ok, but at this point you're accepting others to do the work for you
<dngrs[m]>
I'm tapping out.
<NiaLinaLunaStorm>
what ever, I am how I am... with all my illnesses, nothing I can do about... you do you and I do what ever the fuck my Autism dictates
gienah has quit [Quit: Lost terminal]
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 268 seconds]
oneDragon[m] has quit [Quit: Idle timeout reached: 172800s]
kenny has quit [Ping timeout: 268 seconds]
kenny has joined #rust-embedded
kenny has quit [Ping timeout: 255 seconds]
kenny has joined #rust-embedded
Ralph[m]1 has joined #rust-embedded
<Ralph[m]1>
is there a HAL which supports the Arduino Nano 33 IoT (with the SAMD21G18A MCU)? this isn't the normal Nano (with the ATmega328P) which would be supported by `avr-hal`. i don't see the Nano 33 listed on `avr-hal` and the only HAL [i can find on crates.io](https://crates.io/search?q=SAMD21G18A) is 5 years old 😐️
<JamesMunns[m]>
btw I didn't see it mentioned but may have missed it: with all the target shenanigans stuff, that DOESN'T rebuild the stdlib unless you do build-std, right?
<thejpster[m]>
They call out 8.1, but not 7E
<thejpster[m]>
correct, the libcore rlib is just linked as-is
<JamesMunns[m]>
7E is probably more like "plus target options"
<JamesMunns[m]>
like, that was when there was only one major target option I guess, so we just made a different target for it?
* thejpster[m]
is reading
<thejpster[m]>
Armv8.1-M adds FP16, and MVE (Helium), "low-overhead loops", and "gather-load, scatter-store"
<JamesMunns[m]>
but tbh: I think we'll want to have this discussion anyway, with riscv getting more common I think it's going to be more likely to need to be able to tweak the target cpu and target options
<thejpster[m]>
I saw Joseph Yiu give a talk about those loop instructions.
<thejpster[m]>
the real answer is "let the standard library be recompiled on stable"
<JamesMunns[m]>
arm is actually LESS varied than riscv (tho more popular for now), but I think the discussion is going to have to happen, and yeah I don't think we can manage combinatorial target explosion
<JamesMunns[m]>
thejpster[m]: agreed
<thejpster[m]>
aka legalise bootstrap crimes
<thejpster[m]>
it's not fair that the project get to compile libcore on stable but I don't
<JamesMunns[m]>
tbh I don't think they care other than avoiding accidental stabilizations
jsolano has quit [Remote host closed the connection]
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #rust-embedded
_whitelogger_ has joined #rust-embedded
Noah[m]12 has quit [*.net *.split]
mabez[m] has quit [*.net *.split]
M9names[m] has quit [*.net *.split]
_whitelogger has quit [*.net *.split]
Noah[m]12 has joined #rust-embedded
M9names[m] has joined #rust-embedded
mabez[m] has joined #rust-embedded
RoyBuitenhuis[m] has quit [Quit: Idle timeout reached: 172800s]
gauteh[m] has joined #rust-embedded
<gauteh[m]>
Hi. Does anyone have an example of a driver requiring IoPin (eh-0.2)? I don't manage to set up the where clauses for it.. always get TInput and TOutput unconstrained by ...
<dirbaio[m]>
I don't think it got much use, and it's removed in eh1.0 due to it being too hard to use with cursed type issues
<dirbaio[m]>
* type issues like the one you're having 😅
<gauteh[m]>
seems like my device requires me to change the pin direction to make it work with onewire
<dirbaio[m]>
onewire is opendrain, you shouldn't need to change direction
<dirbaio[m]>
you should be able to configure it as opendrain output permanently
<dirbaio[m]>
HALs should impl both InputPin and OutputPin at the same time for opendrain outputs
<dirbaio[m]>
so in the driver you can do where T: InputPin + OutputPin
<gauteh[m]>
Ok... hm.. couldn't make it work. but maybe I configured it as something else. will double check that first
<gauteh[m]>
was looking at the arduino driver and they change the mode. seems like things are a bit fragile and needs to have slightly tweaked delays etc
<gauteh[m]>
I see I have push-pull, will try to set it to open-drain first
<dirbaio[m]>
with opendrain, the MCU either drives the pin low, or never drives it at all (it never drives it high), so when you .set_high() you can .is_low()/.is_high() to read whether the other device is driving it low
<JamesMunns[m]>
I think the atmege328p doesn't have an explicit open drain mode, they "cheat" by swapping between push-pull-ouput-low and input (hi-z)
<JamesMunns[m]>
so, if your chip has a real open-drain mode, you don't need to do that hack.
<dirbaio[m]>
ah that may be why. it's the same in rp2040 :PP
<dirbaio[m]>
s/PP/P/
<dirbaio[m]>
and the bus is supposed to have a pullup resistor so that when no one drives it low, it is consistently high
<JamesMunns[m]>
oh no, TIL
<dirbaio[m]>
yeah embassy-rp OutputOpenDrain emulates it by setting it low, and enabling/disabling OE (Output Enable) on set_low/set_high 😬
<dirbaio[m]>
at least you can do that atomically
<JamesMunns[m]>
ah, neat, I was going to ask if anyone had checked that for glitches
<gauteh[m]>
nice, that explains things!
WSalmon has quit [Ping timeout: 255 seconds]
WSalmon_ has joined #rust-embedded
vollbrecht[m] has quit [Quit: Idle timeout reached: 172800s]
<Ecco>
dirbaio[m]: Remember this conversation about SpiDevice's API that *has* to use an array? I wonder why the API wasn't built using closures? Like my_device.transaction(|read_function, write_function| { do_what_i_want })
<JamesMunns[m]>
<dirbaio[m]> "> <@dirbaio:matrix.org> - some..." <- Hey dirbaio, gentle poke to make a "DESIGN" file in e-h to answer questions like "why is it like this", same reasons as the embassy FAQ
<dirbaio[m]>
well this particular thing could be in the docs even
<JamesMunns[m]>
I think it's reasonable for people to ask - they weren't there, and chat isn't a suitable medium for knowledge capture, but you might save yourself some hassle in the future
<dirbaio[m]>
because the follow-up question is "what do I do if SpiDevice thing doens't fit my usecase"
<dirbaio[m]>
* question is always "what do
<dirbaio[m]>
so some guidance would be helpful
<JamesMunns[m]>
yeah, fair, SOMEWHERE linkable is good for me, and design docs can be a useful way to get over "why should I document what this code ISN'T" (tho IMO that's just as important as what it IS)
<dirbaio[m]>
the "impl your own thing on top of &RefCell, &Mutex, etc so you can still share with embedded-hal-bus SpiDevice impls"
<Ecco>
honestly, I think the docs would be a good location
<Ecco>
here's my perspective as a newcomer:
<JamesMunns[m]>
anyway, just a poke because you write really good chat replies to good questions, and it is obnoxious to not be able to link to that when I see someone ask the same question.
<Ecco>
the doc clearly made me understand that SpiDevice > SpiBus
<Ecco>
So I really want to use SpiDevice in my driver
<Ecco>
*however*, clearly using SpiDevice is either impossible (I'm not sure my device supports CS being toggled during a command)
<Ecco>
or at least it's not optimal (because I need to allocate a buffer)
<JamesMunns[m]>
just a quick question - are you writing a portable driver that needs to do those things? or just something for you own specific application?
<Ecco>
and so… I'm kind of stuck. I'd like to do things right, and the doc doesn't really provide me with any reassuring answer. Yes, I know I can use SpiBus, but it feels "wrong"
<Ecco>
Well, it's a driver for an LCD display
<Ecco>
most of the time those live alone on their SPI bus
<Ecco>
(because it's a performance bottleneck)
<Ecco>
So using SpiBus isn't terrible
<JamesMunns[m]>
gotcha, and are you trying to do something like toggle command/data lines?
<Ecco>
not really. This is a bona fide SPI bus. However I'm not sure the device supports toggling the CS bit at random times
<Ecco>
In theory it should just ignore everything when CS is low
<JamesMunns[m]>
(CS is usually active low, but not always)
<Ecco>
(yeah, sorry, you got what I meant. CS or /CS whatever :) )
<JamesMunns[m]>
some displays are active high, which is maddening anyway lol
<JamesMunns[m]>
and when do you need to strobe CS?
<JamesMunns[m]>
every byte? or every N bytes or something?
<Ecco>
Well, I don't need to
<Ecco>
I don't even want to
<Ecco>
It's just that using SpiDevice the CS bit will be toggled back and forth
<dirbaio[m]>
Ecco: have you *actually tried it*? SPI displays usually do allow toggling CS anytime
<Ecco>
dirbaio[m]: I have not indeed
<Ecco>
I will
<dirbaio[m]>
display-interface updated to embedded-hal 1.0 just uses SpiDevice doing extra CS toggles, and it seems to work fine for people
AdamHorden has quit [Quit: Adam Horden | adam.horden.me]
AdamHorden has joined #rust-embedded
IlPalazzo-ojiisa has quit [Quit: Leaving.]
jsolano has joined #rust-embedded
<f0rte[m]>
<adamgreig[m]> "you can while let None = signal..." <- Hey Adam, not sure if you're around but just curious if this function requires any specific embassy-sync features? I'm on 0.5.0 but rustc/rust-analyzer are telling me it doesn't exist. I see it in the docs online though. Weird.
<adamgreig[m]>
try_take()? don't think so, what errors are you getting?
avery71[m] has joined #rust-embedded
<avery71[m]>
does returning a `&[u8]` that you create inside a function cause a copy?
<adamgreig[m]>
it's 3 months old but not feature-gated
<f0rte[m]>
adamgreig[m]: errors that would indicate that function doesn't exist.
<adamgreig[m]>
specifically?
<f0rte[m]>
SIGNAL.try_take() == None { ■ no method named `try_take` found for struct `embassy_sync::signal::Signal` in the current scope method not found in `Signal<CriticalSectionRawMutex, bool>
<f0rte[m]>
is it because my signal is bool? My SIGNAL can have .signal() .signaled() and reset() called on it without complaint
<adamgreig[m]>
are you using embassy-sync from crates.io or from git?
<adamgreig[m]>
try_take was 3 months ago and the crates.io release 4 months ago so that might be it
<f0rte[m]>
crates.io, just cargo added it
<f0rte[m]>
ah...
<f0rte[m]>
weird though, it's in the 0.5.0 docs, and cargo says I am running that version
<f0rte[m]>
But on the page it thinks it is 0.5.0, guessing they maybe didn't bump the version number in git yet?
<f0rte[m]>
dirbaio[m]: Ah beat me to it, this exactly.
<f0rte[m]>
Is there a good way to switch to the git version without cloning down the entire repo? I'm not used to working with multi-crate single repos in Cargo.toml
<f0rte[m]>
* git version of embassy-sync without cloning
<f0rte[m]>
* Is there a good way to switch to the git version of embassy-sync without cloning down the entire embassyrepo? I'm not used to working with multi-crate single repos in Cargo.toml
<f0rte[m]>
* git version of embassy-sync without cloning, * the entire embassy repo? I'm