Foxyloxy has quit [Read error: Connection reset by peer]
ivche has quit [Read error: Connection reset by peer]
ivche has joined #rust-embedded
sroemer has joined #rust-embedded
<burrbull[m]>
<mux3dup[m]> "Hello, new here!..." <- I'm afraid that I don't understand what you want to do and what you mean under "collection". Is it `array` or `cluster` or some else? Could you show how it looks like?
<therealprof[m]>
<jsjuel> "I am aware I need those things..." <- Usually the examples are critiqued for being way to simple. 🤣
<JamesMunns[m]>
Has anyone here tried (or was interested in) making postcard work on Python, JavaScript, C, or C++?
omniscient_[m] has joined #rust-embedded
<omniscient_[m]>
Potentially C. I started experimenting with postcard-rpc yesterday to send msg from my host PC to a Rpi Pico that will act as a test environment harness and coordinate a couple of other devices then spy on an RS485 bus and for that I started testing it with postcard-rpc, but the actual devices are written in C. Could be interesting to directly control the test devices using postcard as well over a debug UART.
<omniscient_[m]>
* Potentially C. I started experimenting with postcard-rpc yesterday to send msg from my host PC to a Rpi Pico that will act as a test environment harness and coordinate a couple of other devices then spy on an RS485 bus for debugging and integration testing and for that I started testing `postcard-rpc`, but the actual devices are written in C. Could be interesting to directly control the test devices using postcard as well
<omniscient_[m]>
over a debug UART.
<JamesMunns[m]>
Context: I started to work on an idl for postcard, with the hope of making it possible to do codegen for other languages: https://github.com/jamesmunns/postcard-idl
<omniscient_[m]>
Awesome.
pcs38 has quit [Quit: leaving]
Ralph[m] has quit [Quit: Idle timeout reached: 172800s]
<diondokter[m]>
<JamesMunns[m]> "Has anyone here tried (or was..." <- A couple of years ago we would've used a javascript postcard library (but we didn't make that, instead we used an awful webassembly solution)
danielb[m] has quit [Quit: Idle timeout reached: 172800s]
SEGFAULT[m] has quit [Quit: Idle timeout reached: 172800s]
ckrenslehner[m] has quit [Quit: Idle timeout reached: 172800s]
TomB[m] has quit [Quit: Idle timeout reached: 172800s]
M9names[m] has quit [Quit: Idle timeout reached: 172800s]
richardeoin has quit [Quit: WeeChat 4.1.1]
richardeoin has joined #rust-embedded
korbin[m] has quit [Quit: Idle timeout reached: 172800s]
Ralph[m] has joined #rust-embedded
<Ralph[m]>
<JamesMunns[m]> "Context: I started to work on an..." <- nice! i think you're missing an "f" in the GitHub repo description though: `Interace`... not sure where you're racing to? 😉
<Ralph[m]>
i actually think that this would be a really nice replacement for people stuck with [ROS 1 serial](https://wiki.ros.org/rosserial) applications - somebody could write a "ROS 2 -> postcard" tool which magically maps ROS messages posted to ROS topics to postcard messages sent on postcard channels. so you'd have a ROS node - let's say written in Rust; no reason not to do that 🙂 - which you configure with the information of which
<Ralph[m]>
postcard device to connect to and which ROS topics with which types to map/forward (and in which direction) and the embedded part could be written in C, C++, micropython - which is what they've been using with ROS 1 already and currently don't have an upgrade path because there's no equivalent in ROS 2 (yet). this would help those which are not ready to learn rust and switch to that for their embedded code
<JamesMunns[m]>
Ralph[m]: I know very little about either version of ROS, but if there's something I can do to help with that, happy to chat with anyone about it :D
gdamjan[m]1 has quit [Quit: Idle timeout reached: 172800s]
<Ralph[m]>
(did i just write that wall of text?! that small textbox with a scrollbar was deceiving me, i thought i wrote half of that - sorry for the monologue 😅)
<mux3dup[m]>
* Ok for example how do you reference SPI0_PWREN in this peripheral?
dirbaio[m] has joined #rust-embedded
<dirbaio[m]>
<AlexandervanSaas> "Hi everyone, I got nerdsniped by..." <- been discussed before, the conclusion was kinda it's too tricky to add support for
<dirbaio[m]>
my recommendation is don't use SpiDevice, make your own trait "SdcardDevice" or something
<dirbaio[m]>
and write impls for it for `(OutputPin, RefCell<SpiBus>)`, `(OutputPin, Mutex<SpiBus>)` etc
<dirbaio[m]>
that do "lock mutex, CS low, send bytes, CS high, send dummy byte, unlock mutex"
<dirbaio[m]>
taking a 2nd dummy SpiDevice to do the dummy byte won't work, there's no way to guarantee another task won't grab the bus in between
<dirbaio[m]>
with your custom interface trait you can do custom stuff with that guarantee
<dirbaio[m]>
* been discussed before, the conclusion was kinda it's too tricky to add support for
<dirbaio[m]>
my recommendation is don't use SpiDevice, make your own trait "SdcardDevice" or something
<dirbaio[m]>
and write impls for it for `(OutputPin, &RefCell<SpiBus>)`, `(OutputPin, &Mutex<SpiBus>)` etc
<dirbaio[m]>
and you can still share the bus with "regular" spi devices. just share the `&RefCell<SpiBus>`.
<AlexandervanSaas>
<dirbaio[m]> "been discussed before, the..." <- Yeah I figured the solution would be rather involved. I guess the question to thejpster is if you're open to adding this stuff to the crate to support an async api. IIUC for the blocking API all this isn't necessary because there's no await points where other other tasks get a chance to run between the regular communication and the dummy byte.
<dirbaio[m]>
> IIUC for the blocking API all this isn't necessary because there's no await points where other other tasks get a chance to run between the regular communication and the dummy byte.
<dirbaio[m]>
you can have preemption in the blocking world if you use CriticalSectionDevice
<mux3dup[m]>
dirbaio[m]: No! That would've been real nice have found, thanks for the pointer!
<AlexandervanSaas>
Is there anywhere where I can read back the discussion on adding support for this in embedded-hal? I'd think it doesn't have to be that complex but I don't want to repeat a discussion that's been had before.
i509vcb[m] has quit [Quit: Idle timeout reached: 172800s]
<i509vcb[m]>
<mux3dup[m]> "No! That would've been real nice..." <- Hi, SPI I haven't gotten around to yet for mspm0
<dirbaio[m]>
also you might want to join #mspm0-rs:matrix.org
<mux3dup[m]>
<i509vcb[m]> "Hi, SPI I haven't gotten..." <- I'm more working on figuring out how things work in the Rust world, so mostly been poking around with svd2rust and getting things set up and building and debugged. But if there's a way I can help happy to help.
<dirbaio[m]>
the whole problem here is sdcards don't conform to the standard SPI protocol (need to clock bytes while CS is DEasserted) , so it can't use SpiDevice
<be[m]>
not sure if that would work out, just a sketch of a thought
<be[m]>
dirbaio[m]: right, the SD card library wouldn't take an SpiDevice as input, but take the whole SpiBus, then to keep other devices on the bus functional, the SD card library could give out its own SpiDevices that the caller could pass into other libraries
<dirbaio[m]>
if every device that needs "special SPI" did this
<dirbaio[m]>
you wouldn't be able to use two different drivers that both need "special SPI" together
<be[m]>
yeah... I don't see any way out of that besides "don't use libraries"
<be[m]>
If two devices need weird nonstandard things on the same bus, that seems like an unsolvable problem with generic libraries
<dirbaio[m]>
??? it's solvable with the solution I gave, take `&RefCell<SpiBus>`, `&Mutex<SpiBus>` etc
<be[m]>
ah I follow what you're saying more now
<dirbaio[m]>
that allows generic libraries and multiple special devices on the same bus
<be[m]>
I suppose there's nothing precluding a library that takes a `&RefCell<SpiBus>` or `&Mutex<SpiBus>` from also doing my idea of handing out impls of SpiDevice?
<dirbaio[m]>
yeah but why would it, it'd essentially be reinventing embedded-hal-bus
<be[m]>
ah right, if the caller could still pass the SpiBus to embedded-hal-bus, there would be no point
DominicFischer[m has quit [Quit: Idle timeout reached: 172800s]
RobinMueller[m] has quit [Quit: Idle timeout reached: 172800s]
dngrs[m] has quit [Quit: Idle timeout reached: 172800s]
<ivmarkov[m]>
ah, how so not convenient... (* changing 500 log lines now)
<dirbaio[m]>
but hey it's 1.0
<dirbaio[m]>
* but hey at least it's 1.0
<ivmarkov[m]>
yeah...
<dirbaio[m]>
big number good
<ivmarkov[m]>
:D
* dirbaio[m]
releases embassy-executor v9001.0.0
<dirbaio[m]>
jokes aside, I wonder if there's an issue about it?
<dirbaio[m]>
I think it's doable backwards-compatibly
<ivmarkov[m]>
you mean, to support it? hope they could in future, yes. weird that i couldn't find a single issue about this rfc in the defmt repo. i assumed i'm not the first one to hit this
<ivmarkov[m]>
* future, yes (in a backwards compatible way). weird
<ivmarkov[m]>
{:x?} also not supported. have to come up with something on my own
<ivmarkov[m]>
ah, now i probably understand your Bytes (shot in the dark)
<ivmarkov[m]>
<dirbaio[m]> "yeah that's https://github.com/..."; <- BTW any bloat-related issue as to why most crates take the pesky "either-or" "log" or "defmt" w.r.t. features (and error out when both are enabled, which likely does not cope well with IDEs auto-checking with `--all-features`)? why not always a non-optional dependency on `log` and then if `defmt` is enabled, re-route everything to `defmt`, but still have `log` as a dep just
<ivmarkov[m]>
hanging out there and waiting for the linker or whatever to erase it from the binary?
<ivmarkov[m]>
* from the ELF binary?
<dirbaio[m]>
it's probably not a bloat issue
<dirbaio[m]>
I think it's bad to silently not log if the user explicitly enabled log and then something else accidentally enables defmt
<dirbaio[m]>
that would cause bloat if you use log but don't want every single crate to log to it
<dirbaio[m]>
or if you don't use log at all
<dirbaio[m]>
* or if you don't use log or defmt at all
<ivmarkov[m]>
the first case I think i understand - a trick to "suppress" crates that log and you rather want them not to log at all (and thus not cause bloat) even if the price is that you can't debug them. But the second case I don't get - if you don't want any logging, then you just don't attach a logger, and enable the release-logging-off feature on the log crate (or however it was called)
<ivmarkov[m]>
I think release-logging-off is supposed to turn the log macros into noops
<ivmarkov[m]>
in fact this is what i used to turn off any logging when doing my rs-matter bloat estimations for the nrf52 earlier today
<dirbaio[m]>
ah yeah with that it shouldn't bloat
<dirbaio[m]>
still, I really don't like that you get bloat by default
<dirbaio[m]>
and you have to add a dep on a crate you don't even want to use to remove the bloat
<ivmarkov[m]>
right but i in the meantime really dislike exclusive features so not sure which one is the lesser evil
<dirbaio[m]>
yeah...
<dirbaio[m]>
well that shil has sailed ages ago for embedded rust
<ivmarkov[m]>
not using exclusive features?
<ivmarkov[m]>
yeah, i guess so...
<dirbaio[m]>
try --all-features on embassy-stm32 :D
<ivmarkov[m]>
right and i suspect everything else like task-arena- (not that it is still a thing) and i guess embassy time features, esp32... right...
<dirbaio[m]>
I can see it being a pain with the matter stack tho, where most features could be additive
<dirbaio[m]>
idk
<dirbaio[m]>
if additive features is something you value you can just document that enabling both gives priority to defmt
<ivmarkov[m]>
well... rustcrypto vs openssl vs mbedtls is not exactly additive, but if you introduce "priorities" when > 1 is added, you kind of get it, but it is still a bit horrible
<dirbaio[m]>
or just log to both? :P
<ivmarkov[m]>
actually... yes. with the release-logging-off trick that could actually wortk
<ivmarkov[m]>
s/wortk/work/
<dirbaio[m]>
I mean still have defmt and log features, and log to both if both features are enabled
<dirbaio[m]>
logging to both seems a nice way to ensure the crate still builds when enabling just defmt or just log
<dirbaio[m]>
so in the real world users don't enable both, just one or the other or none