<i509vcb[m]>
<korbin[m]> "60mbit JTAG (limited largely..." <- Where did the 60mbit number come from? I'm seeing in the datasheet that the input transition time is 25ns, which seems to compute to a 40 MHz max?
<i509vcb[m]>
i509vcb[m]: I'm not seeing where the extra speed is coming from
<i509vcb[m]>
* is 25ns (treating it as a period), which
<i509vcb[m]>
* is 25ns (treating it as a period), which, * MHz max for the most conservative margin?
<korbin[m]>
<i509vcb[m]> "image.png" <- experience and actual testing, i never looked at this
<korbin[m]>
korbin[m]: the IMXRT1064 will clock almost to 1GHz reliably - the manual won't tell you this
<korbin[m]>
korbin[m]: and that's the *max* rated time for *input* transition - for your one-way trace data output, you pay the ~1.15ns transition time
<korbin[m]>
korbin[m]: which on one pin is well beyond USB HS
<i509vcb[m]>
<korbin[m]> "which on one pin is well..." <- This is 1101 datasheet for reference
<i509vcb[m]>
s/1101/1011/
<i509vcb[m]>
i509vcb[m]: Input only in my case, I'm trying to see how practical it would be for ARM ETM trace pins
<i509vcb[m]>
* trace pins (input on MCU)
ivche_ has joined #rust-embedded
ivche has quit [Ping timeout: 272 seconds]
ivche_ is now known as ivche
<i509vcb[m]>
<i509vcb[m]> "* Input only in my case, I'm..." <- The 1064's AC parameters pretty much match for 3.3V mode
<korbin[m]>
i509vcb[m]: what about 1.8V mode
<korbin[m]>
korbin[m]: these chips far outperform their advertised specs
<i509vcb[m]>
<korbin[m]> "these chips far outperform their..." <- Although at 60MBit you've gotten most of the way through the theoretical USB HS bandwidth
<korbin[m]>
<i509vcb[m]> "Although at 60MBit you've gotten..." <- 60/480?
<i509vcb[m]>
korbin[m]: Ah right off by 8x
<i509vcb[m]>
i509vcb[m]: Probably closer to 5x for the extra overhead
<korbin[m]>
<i509vcb[m]> "Probably closer to 5x for the..." <- yeah you can definitely do at least 400 in reality
kenny has quit [Ping timeout: 248 seconds]
kenny has joined #rust-embedded
dygear[m] has quit [Quit: Idle timeout reached: 172800s]
chrysn[m] has joined #rust-embedded
<chrysn[m]>
In case this goes in the "a bunch of people fork it to maintain an up-to-date version", what are the rough criteria for this to become something to be maintained under the rust-embedded group?
<chrysn[m]>
Some old discussion flared up in switch-hal again: That crate used to provide a thin wrapper between embedded-hal's GPIO voltage levels and semantic on/off levels. Things became odd when embedded-hal grew fallibility and exclusive ownership of input pins, so things are not zero-cost any more unless that crate changes API (and IIUC the maintainer intended it more as a proof-of-concept and less as a building block to be maintained
<RobinMueller[m]>
Does anyone have experience with the bisync crate? (https://github.com/JM4ier/bisync) I am wondering how to deal with trait bounds.. I have an existing API for a blocking driver, and I want to extend it to be asynchronous. 90 % of the API would be identitcal, with only async and await keywords added, which is why I looked at proc macros. However, I am not sure how to best deal with the different trait bound, e.g.
<RobinMueller[m]>
embedded_hal::spi::SpiBus vs. embedded_hal_async::spi::SpiBus
<adamgreig[m]>
there is the rust-embedded-community org which does a lot of shared maintenance of useful crates
<thejpster[m]>
the rust-embedded-community org on Github exists as a place for things to live if they don't have an owner. It's unaffiliated with the EDWG.
<thejpster[m]>
why doesn't matrix have exclusive locks on opinions?
<adamgreig[m]>
hah
<adamgreig[m]>
someone would take all the good opinions and hold the locks, can you imagine
<adamgreig[m]>
"oops sorry my client de-synced, no one say anything good about rust for a bit"
<thejpster[m]>
You could make an argument for that being in the EDGW.
<thejpster[m]>
s/EDGW/EDWG/
<RobinMueller[m]>
it needs some more examples
ivmarkov[m] has joined #rust-embedded
<ivmarkov[m]>
<dngrs[m]> "word of warning, Matter is..." <- This only matters if you plan to certify your device (which you should of course, for a commercial offering). But for test and hobby projects, you can just go with a "test" VID & PID and in the meantime, all of google/alexa/apple work fine with these devices. Putting aside a "this device is not certified" warning, that is. I.e. blockchains matter only in the cert process, I guess...
<ivmarkov[m]>
And I think the Rust-based Matter echosystem is still far from offering anything commerically viable, it is "test" and "hobby" for now...
<RobinMueller[m]>
i'm happy with the result of bisync. I really need some newer sensors though 😀
<JamesMunns[m]>
Does bisync have any way of addressing cancellation?
* chrysn[m]
waves at ckrenslehner who might be involved too
<chrysn[m]>
<adamgreig[m]> "there is the rust-embedded-..." <- Thank you and thejpster, that sounds like a good place.
<ivmarkov[m]>
<gdamjan[m]1> "how do I search for Rust Thread..." <- `rs-matter-embassy`
Foxyloxy has quit [Read error: Connection reset by peer]
<RobinMueller[m]>
has anyone ever wrapped FreeRTOS with Rust? I am wondering how viable it would be to allow using async code with FreeRTOS. Would it be possible to write a custom executor, which runs async code inside a FreeRTOS task?
<diondokter[m]>
RobinMueller[m]: That's definitely possible! Just run an embassy threadmode executor in a thread and do async there
<JamesMunns[m]>
RobinMueller[m]: I mean the ESP-IDF is mostly FreeRTOS under the hood, right?
<vollbrecht[m]>
RobinMueller[m]: esp-idf-* rust crates are basically that, you run ontop of freertos + rust std support. You can spawn threads via the rust std api and then run your execturo in there, from embassy to tokio its all possoble. At elast on esp32
<vollbrecht[m]>
s/-*/-\*/, s/execturo/executor/
<JamesMunns[m]>
It's worth noting though that *tasks* and *threads* are not exactly the same, and freertos has *threads*. This means you may have (slightly) higher synchronization costs.
<vollbrecht[m]>
* esp-idf-* rust crates are basically that, you run ontop of freertos + rust std support. You can spawn threads via the rust std api and then run your executor in there, from embassy to tokio its all possible. At least on esp32
<diondokter[m]>
I guess there could be an async executor that is better at signaling its sleep intent to the freertos kernel...
<diondokter[m]>
Unless... Can FreeRTOS detect a WFE in one of its threads?
<RobinMueller[m]>
in that case, i wouldn´t want embassy to do anthing with WFE/SEV for the first variant... I guess I could do that with the spinning executor?
<JamesMunns[m]>
<diondokter[m]> "I guess there could be an..." <- I think there's a yield_now hint?
<dirbaio[m]>
arch-* features are only suitable for bare-metal
<dirbaio[m]>
(maybe you can remove the atomic as well, if xTaskNotify can "store" the notification to cause a later xTaskNotifyWait to return immediately similarly to SEV/WFE. I'm not sure if the freertos notificatiosn do that or not)
jakzale has quit [Remote host closed the connection]
jakzale has joined #rust-embedded
<RobinMueller[m]>
dirbaio: that sounds very promising :)
<dirbaio[m]>
and maybe you want xTaskNotifyGiveFromISR, xTaskNotifyTake instead
<dirbaio[m]>
seems that one does "stick" like sev/wfe?
<dirbaio[m]>
no idea
<danielb[m]>
thejpster: how hard-coded is the `defmt(Debug2Format)` attribute, can we inject custom Format-implementing wrapper types?
MartinSivk[m] has joined #rust-embedded
<MartinSivk[m]>
<chrysn[m]> "Some old discussion flared up in..." <- Yeah, I was rewriting some of my personal stuff to embedded-hal 1.0 and realized (again) that switch-hal has not moved :)
<danielb[m]>
* thejpster: how hard-coded is the `defmt(Debug2Format)` attribute, can we inject custom Format-implementing wrapper types?
<MartinSivk[m]>
chrysn: I think it can still be the zero cost thin wrapper if it embraces the &mut gpio access and starts returning the errors. I might even try in a fork once I cleanup the rest of my code (to check it compiles..). But kids and taxes are currently higher on my todo list... so it can be this week or next month, who knows. But even if I manage to fix the code, I can't maintain it long term myself.
<chrysn[m]>
Quite similar here on both priorities :-)
<chrysn[m]>
Yes, once it embraces the current embedded-io concepts it'll be as zero-cost as it always was. Just needs a cool name, some idea of where to scope it (probably as with switch-hal: "read and write on-and-off state traits, with the trivial active-high and active-low wrappers for embedded-hal"), and the (almost mechanical) changes for it.
JamesMunns[m] has quit [Ping timeout: 252 seconds]
wassasin[m] has quit [Quit: Idle timeout reached: 172800s]
<Ralph[m]>
as another complication: i need the `Drop` of the client to run (it has to make sure that the hardware is stopped again - don't want to keep the lights on (or motors spinning, or... you get the point) after the tests are done). with `thread_local` i get that, with a normal `static` i don't (as per [the docs](https://doc.rust-lang.org/reference/items/static-items.html#r-items.static.lifetime))
<JamesMunns[m]>
I'd probably use a lockfile, and make sure your test code acquires it before interacting with the hardware
<Ralph[m]>
hm, i'm not familiar with `nextest`, but from skimming the issue i would presume that this setup/teardown will anyway not be executed within the same process as the rest of the tests (since it talks about referencing `.rs` files), so i don't think that it'll help that much?
<Ralph[m]>
i guess i could just make a small "reset everything to base state" kind of binary, create a wrapper shellscript (`./test.sh`) which triggers `cargo test` _and_ the teardown at the end? for CI that certainly works, for manual testing it's a bit annoying (no IDE integration) - but then again, this is kind-of CI focused, so it might be enough
<MartinSivk[m]>
Hmm, chrysn am I looking right that embedded-io has ReadReady / WriteReady as an alternative to the old nb::Result which could return WouldBlock, but Write::flush lost this alternative? There is no try_flush / is_idle that would return immediately and just report whether all was sent.
<MartinSivk[m]>
Oh, embedded-hal-nb has the nonblocking calls
<MartinSivk[m]>
But not for serial...
FreeKill[m] has quit [Quit: Idle timeout reached: 172800s]
<ckrenslehner[m]>
<MartinSivk[m]> "Yeah, I was rewriting some of my..." <- I like the idea of switch-hal to encode the hardware specifics of the gpio into the type (active high / active low). What I am not sure about is the separate trait which is introduced. It's nice that the separate trait clearly signals that it's an output which already includes the hardware knowledge (so e.g. high is actually high as voltage level), but it's another
<ckrenslehner[m]>
separate trait to the already existing embedded-hal traits. If you would implement a driver crate for a module with a power pin, would you then use the switch-hal trait or the embedded-hal trait?
bartmassey[m] has quit [Quit: Idle timeout reached: 172800s]
<chrysn[m]>
That depends. If it's really the power to a piece of hardware that is turned on or off, I'd use the switch-hal on/off traits. Like, on a board whose BSP exposes different power domains, they might be on or off. (Quite possibly they are even behind an active-low driver GPIO). But those are not typically part of a driver implementation. A driver implementation may optionally have a GPIO that is connected to something like the driven
<chrysn[m]>
chip's nRESET line (which may also double as a built-in power pin), and that goes right to a GPIO and thus uses high/GND semantics. So I wouldn't expect switch-hal to be used in a driver impl, more in an application eg. one that does morse decoding or encoding.
<ckrenslehner[m]>
Okay my concrete example is the pwr_key pin of a BG95 modem. There is a recommendation to switch it via an external transistor so it's active low. In this case I think it's not obvious which trait is more appropriate.
<ckrenslehner[m]>
For application internal use the on/off of the switch-hal trait makes more sense :-)
<jsjuel[m]>
<therealprof[m]> "You will always need a Cargo...." <- I am aware I need those things. I just am saying the examples I have found include way more stuff than I need for just a basic working example of blinky. I have tried cherry picking things with not much luck. I didn't know if someone had just like the most basic example for a working blinky or not. Seems like I am just going to have to keep trying to figure it out on my own.
<chrysn[m]>
<ckrenslehner[m]> "Okay my concrete example is..." <- That's a tricky one indeed. I'd probably lean towards the driver having 3 ways to populate the power pin in its builder: .with_power_direct(gpio), .with_power_inverted(gpio) and .with_power_switch(switch), but expect the former two to be what most drivers provide.
<ckrenslehner[m]>
Thanks!
<MartinSivk[m]>
ckrenslehner: Yeah, as a driver developer you do not know in advance how the final pcb is wired. So hardcoding a specific gpio direction will prevent some uses.
Kaspar[m] has joined #rust-embedded
<Kaspar[m]>
<jsjuel[m]> "I am aware I need those things..." <- Do you mean simple as in "minimal amount of total code" or simple as in "minimal amount of user code not counting abstractions / deps"? The [Ariel OS](https://github.com/ariel-os/ariel-os/blob/main/examples/blinky/src/main.rs) is fairly simple if the latter, and it runs on the pico2 as is.
rmsyn[m] has quit [Quit: Idle timeout reached: 172800s]
<TomB[m]>
<thejpster[m]> "Do you wanna build a ~~snowman~~..." <- is the out of tree support pretty good now? I know when I had looked a good while back there wasn't any clear answer to how to go about it
<TomB[m]>
* about it. Your docs look like this is the case...
PhilMarkgraf[m] has joined #rust-embedded
<PhilMarkgraf[m]>
Where are there good channels for Embedded Rust jobseekers?
<PhilMarkgraf[m]>
(I am in the market, if any of y'all have recommendations!)
<TomB[m]>
* about it. Your docs look like this is the case... but I'm curious how this works out as .ko's are ELFs that are loaded and linked... which I think implies some form of ABI?
<TomB[m]>
* about it. Your docs look like this is the case... but I'm curious how this works out as .ko's are ELFs that are loaded and linked... which I think implies some form of ABI being needed? How does that work with Rust?
<thejpster[m]>
I'm pretty sure they use a custom target, and the kernel's Rust macros generate all the extern "C" ABI shims requred.
<thejpster[m]>
s/requred/required/
<TomB[m]>
Interesting… I guess in the end this shim is a potential point of weakness and loss of information
<TomB[m]>
its not like there's a simple header file to include the rust wrappers in the kernel either is there? Like if you wanted to use one of the existing wrappers for say DMA or whatever is there now, is that even possible with an out of tree rust module?
Elias[m] has quit [Quit: Idle timeout reached: 172800s]