<vrakaslabs[m]>
<ryan-summers[m]> "vrakaslabs: Hmm perhaps my..." <- okay, so your receive() actually reads the packet, wraps it in the RxToken, and the consume just feeds it into the network stack. transmit() takes the opposite approach and wraps the entire mac, and all of the transmit logic lives in the consume.
<vrakaslabs[m]>
<vrakaslabs[m]> "okay, so your receive() actually..." <- Thanks for the reference point. I feel like I've got a pretty good grasp on how the interface is supposed to work, but my assumption was that the goal of the token-style interface was go provide some rudimentary exception-handling (by way of the None() return).
<vrakaslabs[m]>
I think to be correct, the Device needs to count how many tokens it's minted and how many still exist, sort of like an ARC, and enforce a limit based on the available buffers in the MAC, or in the limit, only allow a single token to exist any time. It's not clear to me if smoltcp will ever actually try to have more than one token.
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #rust-embedded
lehmrob has joined #rust-embedded
emerent has quit [Ping timeout: 255 seconds]
emerent has joined #rust-embedded
<ryan-summers[m]>
<vrakaslabs[m]> "Thanks for the reference point..." <- I don't believe smoltcp ever hangs on to tokens currently. It creates and immediately consumes if present
<diondokter[m]>
Ok, does anybody here think reading and writing BCD values is simpler than just binary? Or is it just me?
<diondokter[m]>
* Ok, does anybody here think reading and writing BCD values is actually more complex than just binary? Or is it just me?
<M9names[m]>
I guess it depends on your application whether it's easier or harder
s7rul[m] has joined #rust-embedded
<s7rul[m]>
Depend on what I want to do with the values, print them directly to a LCD then BCD is simpler. For most other thinks it is more complex imo
<diondokter[m]>
s7rul[m]: You mean so you only have to string format single digits?
<diondokter[m]>
Yeah I guess
<M9names[m]>
if by "string format" you mean add a constant to each digit, then yeah
<diondokter[m]>
That's what I mean yeah
<M9names[m]>
string formatting is not the easiest thing for beginners
<diondokter[m]>
Well, in our driver we need to actually 'know' the value, so we need to convert it to a binary number every time. Very annoying
<ryan-summers[m]>
It's pretty common in RTCs to have BCD for some reason. I think it has to do with minimizing the number of internal registers to conserve power
<diondokter[m]>
It uses more bits though
<ryan-summers[m]>
Yeah but you have to align registers to word boundaries anyways
<ryan-summers[m]>
So you can often fit i.e. secs/mins/hours days/months/years into less than 6 words
<ryan-summers[m]>
It might have to do with the silicon state machine in the actual RTC too
<diondokter[m]>
Idk. Seems like you could do that in binary too
<ryan-summers[m]>
Yeah idk, but I see the same thing in an RTC on one of the products I built a few years ago
<ryan-summers[m]>
Its weird but not very hard to decode
<diondokter[m]>
But so far every RTC I've worked with 'feels' old. Not sure why
<ryan-summers[m]>
I think its because they make a lot of compromises to have super low power operation
<diondokter[m]>
No, it's not hard. It's just annoying :P
<ryan-summers[m]>
They also can maintain oscillation at absurd voltages. I did a test and our RTC was staying alive even after VCC had collapsed to 0.2V for a few seconds
<diondokter[m]>
Oh lol haha
<ryan-summers[m]>
Had to wait for like 20 seconds for the oscillator to actually fall over and the time to be lost even after voltage was removed
<diondokter[m]>
Well, our RTC doesn't start immediately so we needed to add a loop just reading a random register until it doesn't nack anymore to know it has booted :P
<ryan-summers[m]>
Yeah that's also relatively common. The oscillator also takes a while to startup. I think the one we use spec'd up to 20 seconds for turn on
<ryan-summers[m]>
Seems likely to have a long loop lock that doesn't fall out of lock very easily
<diondokter[m]>
Oh lol. Ours is 200ms - 2s according to the spec (though usually it's faster)
<ryan-summers[m]>
Maybe ours was 2s as well and I'm misremembering
IlPalazzo-ojiisa has joined #rust-embedded
<dirbaio[m]>
<ryan-summers[m]> "I don't believe smoltcp ever..." <- the lifetimes in the api enforce only one txtoken and one rxtoken exist at a time
<dirbaio[m]>
dirbaio[m]: the tokens borrow the device, so you can't create more tokens without either using or dropping the previous ones
<codec_abc[m]>
But from the description it seems I have to map 16 bits integer on 10 bit range. The crate PackedStruct does not seems to enable this. Do you have anything to recommend here ?
<K900>
Where are you getting that from?
<codec_abc[m]>
Sorry, what do you mean by that?
<K900>
About mapping 16 bits to a 10 bit range
<codec_abc[m]>
The second link. If you look at the C structure
<codec_abc[m]>
GD_GamePAdZ is a 10 bit uint16_t with value going from 0 to 1023
<K900>
It's not really a "10 bit uint16_t"
<K900>
It's just a 10 bit value
<K900>
But C has no "10 bit integer" type
<K900>
Nothing is "packed", it's just a value of 10 bits
<codec_abc[m]>
Indeed. I just realized sicne there is padding if I normalize the value I might be able to get away with this
<K900>
There's nothing to normalize or "get away" with
<K900>
You just write 10 bits
<codec_abc[m]>
Still. on the general case, nothing is prevented to have a packed structure of a 10 bits integer, and a 6 bits integer
<timokrgr[m]>
have a look at the resources section of the readme :) theres quite a lot information about it in public
<codec_abc[m]>
timokrgr[m]: yeah I know but I hope that If I use a similar descriptor it will works on most game. With the example code my gamepad is detected by Windows and input seems to work but games refuse to use it
<codec_abc[m]>
K900: Looks cool. Thanks
<K900>
codec_abc[m]: It won't
<K900>
XInput is an entirely different set of interfaces
<K900>
Weirdly
<codec_abc[m]>
But I do think games engine have support for gamepad made of HID class.
<K900>
Not all
<K900>
Especially these days
<timokrgr[m]>
yeah you just have to map the buttons for every game :P because there is no real standard for them
<codec_abc[m]>
I mean some cheap controller do the same and (sometimes) are usable in some game no?
<K900>
Most cheap controllers pretend to be Xbox
<K900>
So they are picked up by XInput as generic Microsoft ones
<K900>
Not doing that is actually a feature on some more expensive controllers
<M9names[m]>
if you have the option of using xinput, i would recommend it.
<M9names[m]>
nothing ever maps HID the right way
<codec_abc[m]>
Yeah it make sense but it seems a bit out of reach for my knowledge and Rust level. My gamepad is made for myself and aim to be mostly used for one game (namely Rocket League)
<codec_abc[m]>
So if it works for a while the "dirty" way, I am OK with that
<K900>
In that case it might be easier to use HID and something like Steam Input to map it to a virtual XInput device
<codec_abc[m]>
Plus last time I checked there was no gamepad example. Now there is. By the time I will took again there might a off the shelve solution
<timokrgr[m]>
I tried to create HID gamepad descriptor from scratch and found it very difficult
<codec_abc[m]>
K900: Well at beginning I use Vigem client on the host computer as well as a custom communication over a serial port. Ugly as hell but worked great. It just cumbersome to use so I hope I can get a easier solution to test the thing. I still have to do the hardware part. So far only the PCB is done as well as the choice of buttons and stick
<timokrgr[m]>
(eventually I gave up and just used XInput)
<codec_abc[m]>
s/use/used/
<timokrgr[m]>
codec_abc[m]: omg I did the same thing at one point :D but vigem was not very realieable when sending a lot of plug and unplug events
<codec_abc[m]>
Yeah that is the reason what I want to change
<codec_abc[m]>
For info, what's was difficult regarding having HID gamepad descriptor ?
<codec_abc[m]>
s///
<codec_abc[m]>
Also did you manage to make your gamepad recognized as an Xinput compatible one?
<timokrgr[m]>
parsing the spec especially which combinations of usage pages and usage codes are allowed
<timokrgr[m]>
and the order of entries in the descriptooor
<timokrgr[m]>
took me some time to figure out that most operating system interpret "hat switches" as dpad
<codec_abc[m]>
Well in anyway if you have something to share or make progress in the futur, don't hesistate to ping me. No need to say that's I am intersted
<timokrgr[m]>
which MCU do you use btw?
<codec_abc[m]>
I use the STM32F3 board
lehmrob has quit [Ping timeout: 245 seconds]
lehmrob has joined #rust-embedded
lehmrob has quit [Ping timeout: 245 seconds]
jasperw has quit [Server closed connection]
jasperw has joined #rust-embedded
GenTooMan has quit [Ping timeout: 246 seconds]
GenTooMan has joined #rust-embedded
starblue has quit [Ping timeout: 246 seconds]
sirhcel[m] has joined #rust-embedded
<sirhcel[m]>
Regarding your last comment on [#5](https://github.com/serialport/serialport-rs/issues/5#issuecomment-1715172115), eldruin: I like `Read` and `Write` from embedded-io as the new read and write traits for serial devices, especially from the perspective of an application which usually wants to write more than a single word at a time. And on the other hand it looks like trait support for reading and writing word sizes other than `u8`
<sirhcel[m]>
has been dropped. Did i get this right? Are there other traits for reading or writing other word sizes planned? Or is this left to the hal implementations now?
<sirhcel[m]>
I have never used a word size larger than 8 data bits. So i don't miss anything here.
<dirbaio[m]>
> support for reading and writing word sizes other than u8 has been dropped.
<dirbaio[m]>
yes, it's just `u8` now. it's a port of `std::io` traits which is also only u8
<dirbaio[m]>
reasoning is embedded-io intends to be traits for io in general, not just uart
<dirbaio[m]>
and pretty much all io is u8: files, pipes, sockets
<sirhcel[m]>
Thank you! This will make adding support for the embedded-io traits to serialport-rs even more straight forward. :)
<dirbaio[m]>
also
<dirbaio[m]>
- for u7 and lower uart, you can pack it into u8's (linux does this)
<dirbaio[m]>
- non-u8 uart is super rare, especially u9 and higher
<dirbaio[m]>
and
<dirbaio[m]>
the previous embedded-hal trait didn't standardize any word types anyway (other than u8), so HALs ended up each defining their own U7, U9.. types, so it wasn't usable from HAL-agnostic drivers anyway
<dirbaio[m]>
I think that's what linux does if you ask it for a 7bit serial port
<dirbaio[m]>
what does it do for 9bit? probably return 2 bytes per word?
<thejpster[m]>
9-bit UARTs are useful if you want to use the 9th bit to distinguish between commands (or addresses) and data. But yeah, it's rare and I think it's fine to not support that in the HAL.
<sirhcel[m]>
dirbaio[m]: This is a good point. I have not thought about using `u7` and other "odd"-sized type and just about `u16` for more than 9 data bist.
<sirhcel[m]>
thejpster[m]: Another good point! Thank you. Though as you mentioned it: i have not come across this scheme in the wild (yet).
<sirhcel[m]>
dirbaio[m]: That's what i'm used to from stm32 c hals.
<dirbaio[m]>
sirhcel[m]: the point of `trait Serial<Word>` was that the driver would be able to ask for a `Serial<u9>` to make sure it's in exactly the u9 mode, or it'd fail to compile
<dirbaio[m]>
if you do `Serial<u16>` for u9, the driver doesn't know whether it's in u9, u10, whatever mode
<dirbaio[m]>
but yeah some HALs implemented it with `Serial<u16>` iirc
<dirbaio[m]>
so that also defeats the point of the Word generic 🤪
<sirhcel[m]>
dirbaio[m]: A good one indeed. I was too much of a blockhead when looking at this initially. 😀
<dirbaio[m]>
:D
<dirbaio[m]>
i'm open to discussing it if someone feels strongly that we should add `<Word>` back, since iirc it wasn't discussed much when we decided to remove the serial traits in favor of embedded-io
<dirbaio[m]>
but if no one feels strongly, I'd prefer to stick with just u8
<sirhcel[m]>
When arbitrary sized integers get introduced/stablized, it might be worth to start this discussion again. But in the meantime it looks to me that just u8 serves well according to pareto.
<sirhcel[m]>
Thank you!
<sirhcel[m]>
And thank you all for constantly putting all the effort in bringing embedded-hal and friends forward. <§
<sirhcel[m]>
s/<§/<3/
jsolano has quit [Quit: leaving]
jsolano has joined #rust-embedded
starblue has joined #rust-embedded
Shell has joined #rust-embedded
limpkin has quit [Ping timeout: 240 seconds]
nex8192 has joined #rust-embedded
nex8192 is now known as Guest7221
brazuca has joined #rust-embedded
<adamgreig[m]>
hi @room, it's meeting time again! agenda is https://hackmd.io/XJ-N70dCQieNcL6Pc4TvYQ though I'm just about to write it, please add anything you'd like to announce or discuss and we'll start in a few mins
<thejpster[m]>
yo
<thejpster[m]>
I have bandwidth for y'all this week. But I'm also watching the Apple launch ....
<adamgreig[m]>
i hadn't seen anything about it really, is it a new iphone.. with a usb c port
<adamgreig[m]>
anyway, let's start then, only quick announcement from me is the new gpio-cdev release for linux gpio: https://crates.io/crates/gpio-cdev
<adamgreig[m]>
any other announcements?
<adamgreig[m]>
oh, I guess it's an annoucement too, svdtools is now part of the wg under the tools team
<adamgreig[m]>
should people get in touch with you directly if they have any nominations?
<thejpster[m]>
yes
<adamgreig[m]>
so, the main carryover from last week is around this embedded_io WriteAllError, I opened a thread https://github.com/rust-embedded/embedded-hal/issues/501 but I guess the question is whether we want a PR to change that or not
<thejpster[m]>
> The candidate gathering process will be open until September 15, at which point each team's Council Representative will share their team's nominations and reasoning with the whole Leadership Council
<dirbaio[m]>
I think consensus was that we do want the PR
<dirbaio[m]>
also someone pointed out in the issue that it's already documented that impls should not return Ok(0) 🤣
<dirbaio[m]>
I forgot I had documented it like that
<adamgreig[m]>
oh lol, huh
<adamgreig[m]>
I didn't see that in the original comment since it only got added as an edit
<adamgreig[m]>
panic rather than returning a new error variant?
<adamgreig[m]>
I guess it cna't construct one so...
<adamgreig[m]>
panic rather than loop forever
<adamgreig[m]>
does seem nicer
therealprof[m] has joined #rust-embedded
<therealprof[m]>
Urgh... panic paths are pretty much always expensive.
<dirbaio[m]>
they're not that expensive in recent rusts
<dirbaio[m]>
and they're just 1 instruction with panic_immediate_abort (nightly-only)
<adamgreig[m]>
I don't think we can assume lots of people are using panic_immediate_abort, but maybe it's fair to imagine that people who are caring about getting binary size down will be
<adamgreig[m]>
wonder if the compiler has a chance to see that the panic won't ever happen if the thing being written to can't ever return Ok(0)
<therealprof[m]>
Well, if you cheat, yes. If you're on normal rust, they're quite expensive.
<therealprof[m]>
adamgreig[m]: It's possible to do hard but really hard to guarantee.
<therealprof[m]>
s/hard/that/
<dirbaio[m]>
they're not expensive if you don't print the panic message from the panic handler
<dirbaio[m]>
what's expensive is core::fmt, not the panic itself
<adamgreig[m]>
it seems a shame to make our implementation bad to accommodate something rust will hopefully continue to get better at
<adamgreig[m]>
but I suppose in some sense it doesn't matter because we could change it later if we really wanted >_>
<thejpster[m]>
Ok(NonZeroUsize(x)) ?
<adamgreig[m]>
still I feel like a panic is probably the right answer, and in most cases also not a serious additional cost?
<dirbaio[m]>
the compiler optimizes out almost everything
<therealprof[m]>
Even if you panic with a static string, it's not super cheap. And if you compile with full optimisations and the panic is inline, you're paying multiple times since it includes the location information.
<adamgreig[m]>
much rather hit a panic than have the code loop forever in a library on a logic error
<dirbaio[m]>
therealprof[m]: have you *actually looked* at the ASM of a panic in recent rustc output?
<dirbaio[m]>
I have
<dirbaio[m]>
it's NOT that bad
<dirbaio[m]>
* that bad anymore
<therealprof[m]>
dirbaio[m]: Funny you would ask that, I'm still running my year old experiment where I'm comparing the generated binaries and ASM of all Rust versions.
<dirbaio[m]>
are you building with LTO=fat opt-level=s or z?
<therealprof[m]>
It is avoidable with tricks, but out of the box it is bad and that's what counts.
<therealprof[m]>
dirbaio[m]: opt-level=s, regular LTO with single compilation units.
<therealprof[m]>
Oh... and without optimisation, too... For shits and giggles.
<adamgreig[m]>
I don't think code size without optimisation should affect our decision here at all, we're well past that point
<therealprof[m]>
adamgreig[m]: Fair.
<adamgreig[m]>
and even so, it still seems like panicking due to a detected implementation error is better than silently looping forever?
<therealprof[m]>
Honestly, if we could detect an implementation error using const_assert, that would be great. Panicking at runtime is pretty much always crap.
<dirbaio[m]>
the compiler sees panic-halt doesn't use the panic format args and optimizes them out
<adamgreig[m]>
thejpster[m]: I guess the usual downside here is how unergonomic such interfaces often end up being, but I guess it would solve the compiler optimisation issue
<dirbaio[m]>
thejpster[m]: you'd likely need the panic/unwrap *inside* the impl anyway to convert from usize to NonZeroUsize.
<thejpster[m]>
new(len).ok_or(Error::BufferFull) ... or something like that?
<thejpster[m]>
* NonZeroUsize::new(len).ok_or(Error::BufferFull) ... or something like that?
<thejpster[m]>
Huh, I got that right first try. I normally struggle with Option/Result conversions.
<adamgreig[m]>
how bad is swapping to NonZeroUsize return from write() for all the other use cases, besides write_all, I wonder?
<adamgreig[m]>
for write_all it seems nicer, but I wonder if it ends up being more annoying in other situations? I'd have thought for most consumers it's OK as it's pretty quick and easy to get the inner usize from a nonzerousize
<adamgreig[m]>
it adds a bit of nuisance to implementations, that either need an unwrap or an unsafe or to return an error
<thejpster[m]>
NonZeroUsize -> usize is trivial. usize -> Option<NonZeroUsize> is very easy.
<adamgreig[m]>
if it means lots more implementations having a panic path to save one in a rare write_all, maybe it's not totally worth it
<adamgreig[m]>
yea, but impls need to go usize -> NonZeroUsize, so either unsafe/panic/return error
<thejpster[m]>
why panic? because they didn't add an error case for ut>?
<thejpster[m]>
s/ut>?/it?/
<adamgreig[m]>
because they call .unwrap()
<adamgreig[m]>
(eg they know it won't ever be 0 but don't want unsafe{})
<adamgreig[m]>
or they "know" it will never be 0 🤪
<thejpster[m]>
but why would they unwrap the Option when the function returns Result? Sorry, I'm being slow.
<adamgreig[m]>
sorry, I mean an implementation of write() over something that's generating a usize for them, e.g. the ring buffer in dirbaio's example
<adamgreig[m]>
so they have a usize and need to return Result<NonZeroUsize, Error>
<adamgreig[m]>
and don't want an error variant for 0 because they know it "won't happen"...
<adamgreig[m]>
so either unwrap and panic and hope the compiler optimises it out, or unsafe
<thejpster[m]>
yeah, sure. Or add the variant. It's got to happen somewhere. And they have more context than write_all does.
<thejpster[m]>
this just seems less bad than writing "Don't return Ok(0)" in the docs, which people won't read and if they read it they won't remember it when it's patched two years later.
<thejpster[m]>
a panic in write_all for "impl didn't read the instructions" just seems worse than "impl chooses to panic if impossible thing happens"
<thejpster[m]>
I think you'll always want the variant because you might get given &[] as an argument.
<thejpster[m]>
Unless there's some NonZeroLenSlice type.
<dirbaio[m]>
ah
<dirbaio[m]>
if you get `&[]` you *must* return `Ok(0)`
<dirbaio[m]>
it's only forbidden to return Ok(0) if the slice length is nonzero
<therealprof[m]>
LOL
<dirbaio[m]>
this is all from std::Io
<adamgreig[m]>
oh what, lol
<thejpster[m]>
but we're not std::io
<adamgreig[m]>
and write_all?
<dirbaio[m]>
we're a port of std::io
<thejpster[m]>
I'm OK with not following std::io to the letter, because we're typically on a constrained platform.
<adamgreig[m]>
still, what do we expect people to return for writing an empty slice, and what does write_all do?
<adamgreig[m]>
so in conclusion we would continue allowing Write impls to return Ok(0) when given an empty slice, say to not return it otherwise, have write_all panic if it gets it because it will never give an empty slice to the impl?
<thejpster[m]>
So we get to write in the docs "Don't call this with an empty slice", or, "when implementing this, never return Ok(0), unless you were given an empty slice".
<thejpster[m]>
I don't like either tbf.
<adamgreig[m]>
if you did make Write return Result<NonZeroUsize, Error> you require all Errors have a variant for "you gave me an empty slice", which isn't really an error condition anyway
<dirbaio[m]>
and writing zero bytes should not be an error
<dirbaio[m]>
it makes calling code more complex
<dirbaio[m]>
for no reason
<dirbaio[m]>
adamgreig[m]: yeah that's what I'd do
<thejpster[m]>
ok, we tried! panic it is.
<adamgreig[m]>
yea, passing an empty slice seems like it has to be permissible
<thejpster[m]>
along with a big note explaining why panic is the least bad option here.
<adamgreig[m]>
good try though, thanks thejpster!
<adamgreig[m]>
I was convinced on nonzerousize until this final blow
<dirbaio[m]>
lol
<adamgreig[m]>
sorry, I have to run for dinner, and that's all the time we have for the meeting, but sounds like we have a reasonable conclusion at least
<thejpster[m]>
or `-> Result<(), E> where E: From<BufferFullError>` ...
<adamgreig[m]>
thanks everyone!
<thejpster[m]>
ttfn
<dirbaio[m]>
thejpster[m]: there was a proposal that was kinda like this the other day
<dirbaio[m]>
the prbelm is it rules out doing E = Infallible
<dirbaio[m]>
which is nice to do if you're writing to e.g a ringbuffer/pipe
<thejpster[m]>
damn
<thejpster[m]>
is that stable?
<dirbaio[m]>
core::convert::Infallible, yes
<thejpster[m]>
I tried Result<usize, !> and it shouted at me
<dirbaio[m]>
or you can always make an empty enum: enum Infallible {}
<dirbaio[m]>
I don't get why don't they just stabilize ! already
GrantM11235[m] has joined #rust-embedded
<GrantM11235[m]>
There were some problems with type coercion or something
dreamcat4 has quit [Quit: Connection closed for inactivity]
cyrozap_ has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
cyrozap has joined #rust-embedded
<ilpalazzo-ojiis4>
I do recall seeing “We were too hasty in stabilising it without checking things verrrry carefully, and we're not going to make the same mistake again” somewhere.
<ilpalazzo-ojiis4>
Think it was Niko Matsakis who said it.
crabbedhaloablut has quit []
<ilpalazzo-ojiis4>
Plus, it fuels the joke that “‘never’ is named after its stabilisation date”.
chrysn[m] has joined #rust-embedded
<chrysn[m]>
<dirbaio[m]> "the prbelm is it rules out doing..." <- Why? It'd only require that BufferFullError is implemented for Infallible, which the crate defining BufferFullError can do
<chrysn[m]>
(Possibly also for !, but crates that implement something both for Infallible and for ! might be one of the reasons ! is so hard to stabilize).
<chrysn[m]>
My bad, I misread BufferFullError's intentions. Sorry for the noise.
<ilpalazzo-ojiis4>
A bit unrelated, but: What are the main differences between ufmt and fmt? In particular, why can't the panic handler use ufmt to print messages?
<dirbaio[m]>
fmt is built into the stdlib, ufmt is a third-party crate
<dirbaio[m]>
the stdlib panic handler is defined to use std::fmt
<dirbaio[m]>
* so the stdlib panic handler is defined to use the stdlib's fmt
<dirbaio[m]>
no way to change it
<dirbaio[m]>
what you can do is make your own panic! macro that prints the panic message using ufmt and then calls std's panic macro
<ilpalazzo-ojiis4>
Ooooooooh, interesting… but that wouldn't work for unwrap and things like that.
<ilpalazzo-ojiis4>
Still, worth a look! Is defmt a crate?
<dirbaio[m]>
yep
lehmrob has quit [Ping timeout: 245 seconds]
<dirbaio[m]>
for unwrap, instead of doing val.unwrap() you do defmt::unwrap!(val)
<chrysn[m]>
pretty fancy thing, that defmt; do have a look!
brazuca has quit [Ping timeout: 245 seconds]
<dirbaio[m]>
it still leaves out panics from other crates and stuff like array indexing
<dirbaio[m]>
for these you just see "oops something has panicked"
<dirbaio[m]>
but you can leave fmt in while developing, only take it out in release builds
<chrysn[m]>
i suppose there's not much going on around doing anything better there, for that'd depend on getting anything better than Arguments out of the PanicInfo, which'd need language support, right?
<dirbaio[m]>
yes..
<dirbaio[m]>
or somehow patch core/std
<dirbaio[m]>
like, inject your panic macro into the global prelude and build the world with it
<ilpalazzo-ojiis4>
I hope to see that some day.
<ilpalazzo-ojiis4>
Meanwhile, I'm a bit time-constrained, and something tells me that getting defmt to work with AVRs isn't going to be a two-hour job, so I'll pass for now.
<chrysn[m]>
instead of a custom panic macro i'd also take a core::fmt::Arguments that can be overridden; then we would also hook into println! for free.
brazuca has joined #rust-embedded
starblue has quit [Ping timeout: 240 seconds]
fuse117[m] has joined #rust-embedded
<fuse117[m]>
i apologize if what follows is a dumb question, but it is tripping me up. i am trying to use shared_bus::new_cortexm to share an I2C bus across multiple tasks, but running into partial move errors with my bsp, because many components don't implement copy (e.g. gpio Output). is using a bsp in a multi-task embedded app a decent design approach? or rather, is instantiating the board (bsp) in a main task and then passing
<fuse117[m]>
components to sub-tasks a bad idea?
<dirbaio[m]>
you have to pass individual peripherals (ie one gpio pin) to tasks, not the entire "peripherals" struct
GenTooMan has quit [Ping timeout: 246 seconds]
mameluc[m] has quit [Quit: Idle timeout reached: 172800s]
<codec_abc[m]>
<K900> "In that case it might be..." <- Just wanted to know that the route I have taken. I tried to use some xbox 360 report descriptor online but it wasn't great. On the other hand, the steam generic controller support is golden. Works like a charm.
<PhilMarkgraf[m]>
If no such driver is already available, is there an ADC driver you would recommend to use as an example? If I need to build this, I'd like to make the interface something that is expected and versatile (and ultimately, open source.)