jr-oss_ has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
jr-oss has joined #rust-embedded
firefrommoonligh has quit [Quit: Idle timeout reached: 172800s]
ian_rees[m] has quit [Quit: Idle timeout reached: 172800s]
emerent has quit [Ping timeout: 240 seconds]
emerent has joined #rust-embedded
starblue has quit [Ping timeout: 246 seconds]
starblue has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
ian_rees[m] has joined #rust-embedded
<ian_rees[m]>
<gussius[m]> "Hi All, Just wondering if..." <- > <@gussius:matrix.org> Hi All, Just wondering if someone could help me understand *Interrupt Service lines*, and what they are for... From the datasheet...
<ian_rees[m]>
> > Each interrupt can be individually enabled by writing ‘1’ or disabled by writing ‘0’ to the corresponding bit in the interrupt enable register (IE). Each interrupt flag can be assigned to one of two interrupt service lines.
<ian_rees[m]>
On ATSAMD parts at least, a peripheral might have less interrupt lines to the CPU, than the number of conditions that it can be configured to interrupt for. For instance, a SERCOM might have one line but be able to interrupt for transmit or receive complete, or bus error. Since the CPU only has one bit of data saying that the SERCOM interrupt fired, in the ISR for the SERCOM, the program needs to check registers to see what
<ian_rees[m]>
caused the interrupt
IlPalazzo-ojiisa has joined #rust-embedded
IlPalazzo-ojiisa has quit [Ping timeout: 255 seconds]
IlPalazzo-ojiisa has joined #rust-embedded
<ian_rees[m]>
* On ATSAMD parts at least, a peripheral might have less interrupt lines to the CPU, than the number of conditions that it can be configured to interrupt for. For instance, a SERCOM might have one line but be able to interrupt for transmit complete, receive complete, or bus error. Since the CPU only has one bit of data saying that the SERCOM interrupt fired, in the ISR for the SERCOM, the program needs to check registers to see
<ian_rees[m]>
what caused the interrupt
<gussius[m]>
<ian_rees[m]> "> <@gussius:matrix.org> Hi All..." <- Thanks ian_rees , There are two interrupt lines available on the chip (ATSAMC21G17A) I am using. I have setup my CAN bus Rx interrupts on line 0, and all works ok. Like you say, the ISR checks which of the many flags are set.
<gussius[m]>
I can assign any of the interrupts to one of the two lines with the ILS (Interrupt Line Select register). But still not sure why we need two interrupt service lines for CAN. (Does this have something to do with the two instances of the peripheral CAN0, adn CAN1?)
<gussius[m]>
The datasheet doesn't really explain it. So I might throw a question at Microchip.
<ian_rees[m]>
gussius[m]: I'd assume it's a line per peripheral, it's been a while but I have vague memory of the datasheet for SAMD21 not covering that very well
<ian_rees[m]>
ian_rees[m]: with the NVIC, the separate lines can be handy to allow setting different priorities
<ian_rees[m]>
ian_rees[m]: tbh, I'd typically figure this sort of thing out using the ASF (or whatever they're calling it lately) config/example thing
<ian_rees[m]>
* tbh, I'd typically figure this sort of thing out by taking apart output from the ASF (or whatever they're calling it lately) config/example thing
nex8192 has left #rust-embedded [Error from remote client]
thejpster[m] has quit [Quit: Idle timeout reached: 172800s]
notgull has quit [Ping timeout: 260 seconds]
starblue has quit [Ping timeout: 248 seconds]
notgull has joined #rust-embedded
starblue has joined #rust-embedded
M9names[m] has quit [Quit: Idle timeout reached: 172800s]
corecode[m] has quit [Quit: Idle timeout reached: 172800s]
<diondokter[m]>
I noticed you guys started using it in some ESP example. (Went looking when I saw the downloads skyrocketing :P)
nex8192 has joined #rust-embedded
jessebraham[m] has joined #rust-embedded
<jessebraham[m]>
<diondokter[m]> "Hey jessebraham I saw you forked..." <- > <@diondokter:matrix.org> Hey jessebraham I saw you forked my lis3dh fork to update it to eh-1.0-rc1. https://github.com/jessebraham/lis3dh-rs-async/tree/feature/eh-rc1 Do you want this merged and released?
<jessebraham[m]>
> I noticed you guys started using it in some ESP example. (Went looking when I saw the downloads skyrocketing :P)
<jessebraham[m]>
@diondokter If you're able to that'd be great. It's a dev depenedency so not the end of the world, but I just like using published releases when able :)
<jessebraham[m]>
Not sure if you missed the notificaiton but I did open a PR on your repo already 😀
<diondokter[m]>
<jessebraham[m]> "Not sure if you missed the..." <- Really? Yeah I missed that
<jessebraham[m]>
Haha no worries, it happens 😁
justacec[m] has quit [Quit: Idle timeout reached: 172800s]
ithinuel[m] has quit [Quit: Idle timeout reached: 172800s]
nex8192 has left #rust-embedded [Error from remote client]
nex8192 has joined #rust-embedded
IlPalazzo-ojiisa has quit [Quit: Leaving.]
IlPalazzo-ojiisa has joined #rust-embedded
IlPalazzo-ojiisa has quit [Client Quit]
IlPalazzo-ojiisa has joined #rust-embedded
adamgreig[m] has joined #rust-embedded
<adamgreig[m]>
hi @room, meeting time again! agenda is https://hackmd.io/AJG0Bd2dRFS8WEqjb5Wy9g, add anything you want to announce or discuss, and we'll start in a few mins
<diondokter[m]>
Not really something for a discussion, but a short announcement. It seems we at Tweede golf will have some time to spend on the good of the embedded Rust community. If there's something you think could be improved with some time and effort, please let me know! DM or here (Though I can't promise anything right now)
<JamesMunns[m]>
Talking to Mara about the "code size" wg thing might be fun
<diondokter[m]>
Yep, that's on the list of possibilities!
<JamesMunns[m]>
solving panic/fmt bloat would be the absolute neatest :D
<diondokter[m]>
JamesMunns[m]: Yep, we're thinking in the same direction :P
<adamgreig[m]>
sounds great, thanks!
<adamgreig[m]>
i don't have any announcements this week, anyone have anything else?
therealprof[m] has joined #rust-embedded
<therealprof[m]>
Not me. I'm back but all the travel takes its toll. 😅
<adamgreig[m]>
OK, let's go on to the agenda then
<adamgreig[m]>
first up, burrbull suggested moving svdtools (https://github.com/stm32-rs/svdtools) to the wg tools team, it fits in fairly neatly alongside (and uses) the svd parser/generator crates
<adamgreig[m]>
and is already maintained by two tools team members 😅
<adamgreig[m]>
dunno if emilgardis, reitermarkus are around? thejpster, therealprof any thoughts?
<cr1901>
I'm definitely all for this. It's definitely not STM32 specific; STM is _hardly_ the only vendor w/ bad SVDs :P
<adamgreig[m]>
exactly, it started from an stm32-specific need but it's quite widely used I believe
<adamgreig[m]>
it's already been ported to rust
thejpster[m] has joined #rust-embedded
* thejpster[m]
sighs loudly
<thejpster[m]>
Does it have to be python?
<adamgreig[m]>
part of the move could involve deprecating or removing the python version
<thejpster[m]>
what's the difference between the python and the rust version?
<cr1901>
I've only used the Python version, but converting to the Rust version would be a good msp430 maintenance task
micro[m] has joined #rust-embedded
<micro[m]>
Can anyone point me towards docs, a blog post, or a more appropriate room for trying to cross compile a rust cli program for the pi zero w? I tried rustup target add arm-unknown-linux-gnueabi and cargo build --release --target=arm-unknown-linux-gnueabi but I am getting openssl-sys linking/compilation errors. Trying to compile this: https://github.com/jdx/rtx which Cargo.toml shows openssl as optional, but not sure what next steps
<micro[m]>
I should try.
<thejpster[m]>
I am broadly in favour though, and I've done a lot of Python in my time. I'm just being an ass.
<jessebraham[m]>
In ESP-land at least we've been using the Rust version for quite some time now
<adamgreig[m]>
in principle there's no difference
<adamgreig[m]>
the rust version gets more maintenance love now, too
<therealprof[m]>
Interesting. Didn't know about the Rust version.
<adamgreig[m]>
when the rust version was introduced it generated functionally identical output to the python version, up to xml formatting
<adamgreig[m]>
since then I fear there's been one or two divergences where the rust version got features the python one did not
<therealprof[m]>
I'm not opposed to moving it over.
<therealprof[m]>
I would say anything SVD is wg business, especially since other vendors poached the officially ARM exclusive business a long time ago.
<cr1901>
I thought I remembered reading that SVD is supposed to be CPU neutral anyway
<adamgreig[m]>
not sure about intent, but in any event the schema and software etc is permissively licensed
<thejpster[m]>
It is the Common Microcontroller Software Interface Standard System View Description format
<adamgreig[m]>
yea but CMSIS is pretty ARM centric despite the name, right?
<adamgreig[m]>
anyway, I'll prepare an issue for voting on a move and then sort the transfer
<adamgreig[m]>
thanks for the comments everyone
<cr1901>
Yea CMSIS is ARM, but the schema itself is nominally CPU neutral
<adamgreig[m]>
next up, nchong-at-aws hoped to be here to discuss this but couldn't make it in the end: in aarch64-cpu https://github.com/rust-embedded/aarch64-cpu/issues/19 the question is whether it makes sense to re-export the tock-registers crate that's used to generate the register definitions, since consumers of aarch64-cpu need to use tock-registers to consume those descriptions
<adamgreig[m]>
and, if so, whether to make that a minor version bump
jannic[m] has joined #rust-embedded
<jannic[m]>
rp2040-pac changed to use the rust version of svdtools by default, as well.
<adamgreig[m]>
I think most people are using the rust version now
emilgardis[m] has joined #rust-embedded
<emilgardis[m]>
Missed the ping, I'm all for moving svdtools
<emilgardis[m]>
a vote sounds good 👍️
<cr1901>
adamgreig[m]: I'm not using the Rust version, but that's not for any good reason. I'll transition at some point soon
<adamgreig[m]>
it should be an easy transition I hope
<cr1901>
Will let you know if it's not :P
<adamgreig[m]>
I'll mention the possibility of deprecating or removing the python version in the issue thread
<thejpster[m]>
hmm. I'd prefer not to rely on a third-party groups register traits.
eldruin[m] has joined #rust-embedded
<eldruin[m]>
hi there, does the svdtools repo contain svds provided by the vendors?
<adamgreig[m]>
eldruin[m]: no, it's just the patching etc tools
<therealprof[m]>
I find the idea of using tock stuff somewhat curious, too.
<adamgreig[m]>
adamgreig[m]: technically it does contain one stm32l4x2.svd file as part of the example
burrbull[m] has joined #rust-embedded
<burrbull[m]>
<thejpster[m]> "what's the difference between..." <- Python version modifies xml directly. Rust version parses and works with svd device structure.
<eldruin[m]>
adamgreig[m]: I'm just wondering about licenses and copyright stuff, since inside the wg would change the "liability entity"
<micro[m]>
I don't know how to write this, but want to see if there's room on the agenda for an item "can anyone share an example of looking at a USB device description doc and implementing it using embassy or other rust stack?"
<micro[m]>
or is this more internal facing than user facing meeting?
<dirbaio[m]>
internal facing
<adamgreig[m]>
ST explicitly permit redistribution of their SVDs, but I think some newer ones (not the one in the repo currently) are more explicitly open licensed too, will check
<dirbaio[m]>
if you have "how to do X" questions you can ask them on this channel any time, not on the meeting
<adamgreig[m]>
<thejpster[m]> "hmm. I'd prefer not to rely on a..." <- it's historic and how the aarch64 (née cortex-a) stuff was previously done, but I think not fundamentally different to svd2rust relying on eg volatile-register
<adamgreig[m]>
but regardless: the current version exports an API that uses tock_register types, so it seems like it makes sense to also re-export the used version of tock_register, rather than having to say in the README that you must depend on exactly so-and-so a tock-register version yourself
<thejpster[m]>
yeah I suppose that's fair
<thejpster[m]>
and I agree, it should re-export
<adamgreig[m]>
and I think fair to call that a minor version bump, 9.3.1->9.4.0, though could probably get away with a patch even
<adamgreig[m]>
OK, next up, I think rmja / lulf wanted to chat about the WriteAllError in embedded-io?
<adamgreig[m]>
if they're around 😅
rmja[m] has joined #rust-embedded
<rmja[m]>
Hi, yes.
<rmja[m]>
It is about the new introduction of the WriteAllError/WriteFmtError enums
<rmja[m]>
I have raised a concern about the current implementation, because it seems to make it somewhat difficult to make Read/Write middleware that forwards calls across the api.
<rmja[m]>
For example, some middleware implementing flush() calling e.g. write_all(), is now forced to handle this new intermediate error type.
<rmja[m]>
Maybe the concern is because I am doing stuff wrong.
<rmja[m]>
Alternatives that I have been recommended is to add a custom new generic error type, so that I can propagate the error somehow.
<rmja[m]>
Don't know if that makes sense at all?
<adamgreig[m]>
I guess dirbaio is best placed to have thoughts?
<dirbaio[m]>
yea
<dirbaio[m]>
so, the root of the issue is write() allows returning Ok(0) to indicate "no error, but I can't accept more data"
<dirbaio[m]>
sort of like an EOF but for writes
<dirbaio[m]>
(this is from std::io)
<dirbaio[m]>
so write_all, which calls write() in a loop, has to handle it osmehow
<dirbaio[m]>
* so write_all, which calls write() in a loop, has to handle it somehow
<dirbaio[m]>
if it simply retries when write() returns Ok(0), it'll most likely hang
<dirbaio[m]>
so instead it returns WriteAllError::WriteZero
<dirbaio[m]>
this means it can't return `Self::Error`, it has to return a wrapper enum `WriteAllError<Self::Error>`, to be able to add the `WriteZero` case
<dirbaio[m]>
(this is still same as std::io. write_all there also returns a WriteZero in this case)
<dirbaio[m]>
in std::io it works fine because `std::io::Error` internally has `Box<dyn ...>`, so `write_all` can simply create a new `std::io::Error` with `WriteZero` kind.
<dirbaio[m]>
in our case, the error is an associated type, so the actual type is unknown for write_all. so it can't actually create one. hence the need for the wrapping.
<rmja[m]>
I understand the reason why the error types were added, namely to handle the Ok(0) case and also the issue with being unable to allocate a new error directly in write_all. The reason why I am flagging this, is because I think we may make it unnecessarily complex to call write_all() which is kind of a shame, since that is most likely the actual desired way a user should actually write.
<dirbaio[m]>
so
<dirbaio[m]>
it's all a logical consequence of "replicate std::io" plus "use associated error types" plus "no panics"
<dirbaio[m]>
if we want to fix this, one of these 3 has to give
<dirbaio[m]>
remove "no panics" is what 0.4 did
<dirbaio[m]>
* give up on "no panics" is what 0.4 did
<dirbaio[m]>
give up on "use associated error types" is what std::io does
<dirbaio[m]>
the 3rd option is to deviate from std::io
<dirbaio[m]>
for example, forbid write() from returning Ok(0)
<dirbaio[m]>
instead "can't accept more bytes" should be signaled through an error
<rmja[m]>
Another (probably even worse option) would be to have some kind of error factory on ErrorType such that we allow for creating an error with a custom kind.
IlPalazzo-ojiisa has quit [Remote host closed the connection]
<rmja[m]>
Such as T::Error::make_me_an_write_all_error()
<dirbaio[m]>
requiring T::Error::make_me_an_write_all_error() forbids impls with type Error = Infallible
<rmja[m]>
Okay. Maybe it is all good - I just had to check that it was actually what we wanted before aligning libs to this, because it seems to be unnecessarily complex.
<dirbaio[m]>
yeah I don't like it either
<dirbaio[m]>
had to update a bunch of code, I agree it's annoying
<dirbaio[m]>
but the only way out I see is "forbid write() from returning Ok(0)"
<adamgreig[m]>
is it something that should be documented more in the write_all docs?
<dirbaio[m]>
which means it deviates from std::io
<rmja[m]>
The thing is. It is recommended to actually call write_all, but that may be an error if someone actually implements Write in this way.
<cr1901>
If std::io was not made w/ this use case in mind then we should deviate from it IMO
<rmja[m]>
It kind of forces everybody to not use write_all, as it does not support this case.
<rmja[m]>
so: you should use write_all(), except when someone implements write() according to spec in a way where it returns 0. Then you should not, and you need to handle the write_all logic yourself.
<rmja[m]>
It seems wrong.
<rmja[m]>
Like if the api wants to do two things at once.
<dirbaio[m]>
write() returning Ok(0) means the stream can't accept more bytes
<dirbaio[m]>
in that case it's OK to error out
<dirbaio[m]>
* in that case you probably want to error out anyway
<dirbaio[m]>
and write_all() does just that, error out
<dirbaio[m]>
so in most cases it's OK to always use write_all even in streams that make write return Ok(0)
<adamgreig[m]>
yea, it doesn't really help to call write() instead, once you get Ok(0) back you have to error anyway
<adamgreig[m]>
and then the middleware is back to having to have its own error type
<dirbaio[m]>
exactly
<adamgreig[m]>
<rmja[m]> "Alternatives that I have been..." <- can't middleware return the same WriteAllZero<T> error?
<adamgreig[m]>
s/WriteAllZero/WriteAllError/
<rmja[m]>
No, not if they do the write_all() from a different function.
<rmja[m]>
For example, I do it in flush()
<adamgreig[m]>
what does your flush() return?
<dirbaio[m]>
the annoyance is that stacking middlewares stacks error wrappers
<dirbaio[m]>
ideally stacking middlewares would still leave the same error associated type
<dirbaio[m]>
for example, `Uart::Error` should be the same as `BufferedWrite<Uart>::Error`
<dirbaio[m]>
but with the current design it can't
<dirbaio[m]>
you have to do `BufferedWrite<Uart>::Error = SomeWrapperEnum<Uart::Error>`
<rmja[m]>
Year, that, or the current hack I that made which is kind of unusable, namely to have the `T::Error: From<WriteAllError<T::Error>>` constraint.
<rmja[m]>
That does not propagate well.
<dirbaio[m]>
I think maybe forbidding write from returning Ok(0) is the way to go
<adamgreig[m]>
how do you wrap std::io consumers in that case?
<dirbaio[m]>
you convert Ok(0) to an error
<adamgreig[m]>
which error?
<dirbaio[m]>
std::io::Error::new(....)
<dirbaio[m]>
the adapters set type Error = std::io::Error;
<dirbaio[m]>
so you can just create one
<dirbaio[m]>
this is for adapting from std::io to embedded-io
<dirbaio[m]>
did you mean the other way, adapting from embedded-io to std::io?
<dirbaio[m]>
in that case it'd stay as an error, yes
<rmja[m]>
Could we have some kind of a requirement that `ErrorType::Error` must implement `From<WriteAllError<Error>>`? How would that work?
<dirbaio[m]>
rmja[m]: still rules out `Error=Infallible`.
<rmja[m]>
Okay
<adamgreig[m]>
so we say "please don't return Ok(0)", and then write_all gets to assume it won't so is allowed to just block forever if it keeps getting that, people implementing write return an error that means "no error as such but i can't take any more bytes", and people wrapping std::io::write convert Ok(0) into a std::io::Error with I guess a WriteZero errorkind?
<dirbaio[m]>
> then write_all gets to assume it won't so is allowed to just block forever if it keeps getting that
<dirbaio[m]>
or it could panic. IMO panicking is fine if the impl did something that's explicitly forbidden.
<adamgreig[m]>
any downside besides the philosophical one of being different to std::io?
<dirbaio[m]>
no...
<dirbaio[m]>
also I think it's super rare for write to return Ok(0)
<dirbaio[m]>
I can't think of any impl that does that
<adamgreig[m]>
does read_exact have the same problem?
<dirbaio[m]>
kinda, but it's rarer for a middleware to want to impl read with read_exact
<adamgreig[m]>
is it weird to keep read() -> Ok(0) meaning EOF, but write() -> Ok(0) not being allowed?
<adamgreig[m]>
seems kinda inconsistent vs read() -> Err::EOF or something
<dirbaio[m]>
it is
<dirbaio[m]>
kinda
<dirbaio[m]>
I think EOF is more "obviously" not an error
<rmja[m]>
Are there drivers around that returns read() -> Ok(0). It seems like that is actually some kind of timeout error
<dirbaio[m]>
rmja[m]: no, read zero is EOF. Timeouts should be reported as errors, not Ok(0).
<adamgreig[m]>
timeout could be an actual error, Ok(0) is "that's the end of the thing you're reading, there can never be more to read"
<dirbaio[m]>
like
<rmja[m]>
Year, okay.
<adamgreig[m]>
I feel like if you say write should return err on "can't write any more", then read should too, or otherwise both use Ok(0), but meh
<dirbaio[m]>
if you model a read stream as "a finite sequence of bytes" then EOF is not an error
<dirbaio[m]>
vs for writing, the caller is the source of the sequence of bytes
<adamgreig[m]>
but you're modelling a potentially-finite sink for bytes
<dirbaio[m]>
while the Write impl is supposed to be a sink, period
<dirbaio[m]>
the "finite sink" concept feels odd to me 🤣
<dirbaio[m]>
like
<dirbaio[m]>
a sink is supposed to sink data
<dirbaio[m]>
if it can't sink the data I want it to sink, then that's an error
<dirbaio[m]>
something underneath broke, and the sink can't sink anymore
<dirbaio[m]>
for example, when writing to a file and the filesystem is full, that's an error
<adamgreig[m]>
is it an error to fill up a finite sink? 🤔
<dirbaio[m]>
the filesystem is a finite sink
<adamgreig[m]>
I guess it's weird to think of it as "also it won't ever be empty again"
<dirbaio[m]>
yet ENOSPACE is an error, not Ok(0)
<adamgreig[m]>
obviously if it was a fifo or queue or something you can happily block
<dirbaio[m]>
it's inconsistent that writing to a full slice returns Ok(0), but writing to a full filesystem returns ENOSPACE
crabbedhaloablut has quit []
<thejpster[m]>
what would writing to an NFS filesystem suffering bandwidth limitations return?
<dirbaio[m]>
it'd block
<adamgreig[m]>
it would just wait for the data to get through?
<adamgreig[m]>
it sounds like just changing write() to forbid Ok(0) might be reasonably consistent and useful then, shall we return to it next meeting?
<adamgreig[m]>
or maybe start a pr in the meantime and ponder it
<dirbaio[m]>
yeah I'd prefer for this to not take 3 months :D
<adamgreig[m]>
yea, but we're also >20min over time :P
<dirbaio[m]>
i'm personally OK with forbidding Ok(0) write
<rmja[m]>
If you decide to change this, then I think it should be done rather fast, before everyone start to align to the just introduced, new error types...
<dirbaio[m]>
s/write/writes/
<adamgreig[m]>
yea, but still I think worth having opportunity for more users to think about it and discuss
<adamgreig[m]>
no reason not to open a pr as a place for that to happen though
<dirbaio[m]>
also: WriteZero didn't exist for all embedded-io history and nobody complained
<dirbaio[m]>
no impls do WriteZero
<adamgreig[m]>
I guess not many sinks return Ok(0) anyway, heh
<dirbaio[m]>
* in practice no impls
<adamgreig[m]>
I have to run, thanks for your participation everyone!
<adamgreig[m]>
good thing we used the old guidance to justify updating svd2rust and add a lock file before it changed :P
danielb[m] has joined #rust-embedded
<danielb[m]>
ah, the good old passive-agressive "we don't care what you do but we also don't like the old way"
StephenD[m] has quit [Quit: Idle timeout reached: 172800s]
<danielb[m]>
I have to keep reminding myself that Semver only requires API compatibility, it says nothing about minor stuff like the code actually compiling
<dirbaio[m]>
so replacing all my function bodies with panic!("lol") is not semver-breaking, gotcha
<dirbaio[m]>
🙈
<danielb[m]>
well I'm more referring to bumping the MSRV but .... technically?
<danielb[m]>
* .... technically? maybe?
<danielb[m]>
* .... technically? maybe? on the other hand, a panic isn't a compile error, it's a behavior change
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 248 seconds]
nic-starke[m] has joined #rust-embedded
<nic-starke[m]>
Hi everyone
Noah[m] has quit [Quit: Idle timeout reached: 172800s]
dngrsspookyvisio has quit [Quit: Idle timeout reached: 172800s]