frdem has quit [Read error: Connection reset by peer]
frdem has joined #rust-embedded
frdem has left #rust-embedded [#rust-embedded]
frdem has joined #rust-embedded
frdem has quit [Read error: Connection reset by peer]
starblue has quit [Ping timeout: 240 seconds]
starblue has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
frdem has joined #rust-embedded
emerent has quit [Ping timeout: 248 seconds]
emerent has joined #rust-embedded
dc740 has joined #rust-embedded
nadja has quit [Quit: bye!]
nadja has joined #rust-embedded
<re_irc>
<@fuse117:matrix.org> howdy all. new to the channel and new to embedded rust.
dc740 has quit [Remote host closed the connection]
dc740 has joined #rust-embedded
<re_irc>
<@fuse117:matrix.org> can anyone point me to a project that interfaces with multiple i2c sensors robustly? by robust, i mean that if the sensors are faulty or disconnected, i want the code to continue to run.. read and report on what is available and flag what is not. i am working on such a project right now and unsure about my approach, and thus interested in studying what others have done.
<re_irc>
<@mameluc:matrix.org> I don't know if it is the right way but Id look at the select! like this one
<re_irc>
<@mameluc:matrix.org> so await on a delay and on the i2c read.
<re_irc>
<@dirbaio:matrix.org> i2c reads typically fail with a "NACK" error when the device is simply gone (unplugged)
<re_irc>
<@dirbaio:matrix.org> so you can handle the errors
<re_irc>
<@dirbaio:matrix.org> and, say the sensor returned a "i32" reading, you can return a "Option<i32>" instead, returning None if reading failed
<re_irc>
<@dirbaio:matrix.org> or "Result<i32, SomeErrorEnum>" if you want to track the cause of the failure too
<re_irc>
<@dirbaio:matrix.org> (devices malfunctioning can also cause hangs, so it's nice to have timeouts ,too yes)
<re_irc>
<@dirbaio:matrix.org> * too,
<re_irc>
<@mameluc:matrix.org> maybe obvious but do it in steps, first read a sensor, then try to read many, then try to implement timeout
<re_irc>
<@fuse117:matrix.org> many of the device drivers i am using check a device id during construction. if the check passes, the constructor returns Ok, otherwise, Err. i am currently converting such Results to Options to indicate if the device is present or not. all future interactions with the device have to check if the option is Some or None. is such an approach reasonable? it feels bloated.
frdem has quit [Read error: Network is unreachable]
<re_irc>
<@thejpster:matrix.org> If it's unreasonable to operate without the device being present, you can panic or go into an error handler instead.
frdem has joined #rust-embedded
frdem has quit [Read error: Connection reset by peer]
frdem has joined #rust-embedded
frdem has left #rust-embedded [#rust-embedded]
IlPalazzo-ojiisa has quit [Quit: Leaving.]
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc>
<@explodingwaffle101:matrix.org> fuse117: how exactly are you checking it? i feel like ‘if let’ wouldn’t be too bad
<re_irc>
<@yruama_lairba:matrix.org> hi, i need help, i'm tryind to edit a svdtool patch file from stm32-rs, but i get an error i don't understand at all when running make :
<re_irc>
2023-05-24T20:15:46Z ERROR svdtools::cli] by svdtools (0.3.0)
<re_irc>
0: Processing device `STM32F413`
<re_irc>
2: peripheral UART4 not found
<re_irc>
1: Deriving peripheral `UART5` from `String("UART4")`
<re_irc>
Caused by:
<re_irc>
<@yruama_lairba:matrix.org> here is the file https://pastebin.com/6MmZjz1E . i just added line from 262 to 267
<re_irc>
<@adamgreig:matrix.org> did it work without your change?
<re_irc>
<@yruama_lairba:matrix.org> yes, running make before change works
<re_irc>
<@adamgreig:matrix.org> : you need to add your new bit to the existing "_copy" key on L218
<re_irc>
<@yruama_lairba:matrix.org> it's not possible to have several _copy section? weird
<re_irc>
<@adamgreig:matrix.org> it's a yaml file
<re_irc>
<@adamgreig:matrix.org> so if you redefine a key, only the second definition counts
<re_irc>
<@adamgreig:matrix.org> I think you might then need to copy I2S3ext from I2S2ext, not from the f412 yaml
<re_irc>
<@yruama_lairba:matrix.org> i don't know yaml
<re_irc>
<@yruama_lairba:matrix.org> admagreig, there I2S3ext and I2S2ext are missing, that why i pick them from f412 yaml
<re_irc>
<@yruama_lairba:matrix.org> crap "Could not find `I2S3ext:CR1"
<re_irc>
<@adamgreig:matrix.org> That's what I'm saying, change 3 to copy from 2 instead
<re_irc>
<@adamgreig:matrix.org> I haven't looked at the f412 i2sext3, maybe it's missing cr1 or otherwise troublesome?
<re_irc>
<@yruama_lairba:matrix.org> i changed the chip i take the i2s ext from
<re_irc>
<@yruama_lairba:matrix.org> it's make les modification
<re_irc>
<@yruama_lairba:matrix.org> : i don't undesrtand a thing, if cr1 is just missing from f412 i2ext3, it should build anyway ?
<re_irc>
<@adamgreig:matrix.org> I expect it's later trying to patch cr1 and then can't find it
<re_irc>
<@yruama_lairba:matrix.org> is it possible to select several chip with feature when building a pac ?
<re_irc>
<@yruama_lairba:matrix.org> weird, now stmf413 have module i2s2ext and i2s3ext defining register content, while other chip reuse the spi1 module
<re_irc>
<@walstib-alex:matrix.org> : Are you setting up a coprocessor or something? Why do you need several chips?
<re_irc>
<@yruama_lairba:matrix.org> I just want to use documentation to compare chip to see if my svd patch is correct
<re_irc>
<@yruama_lairba:matrix.org> i don't understand the importance of "interrupt" associated with a peripheral ? i ther a way to check that in documentation ?
<re_irc>
<@walstib-alex:matrix.org> Not afaik, but a few years ago you needed to have a peripheral associated with all interrupts placed in Interrupt
<re_irc>
<@walstib-alex:matrix.org> +Edit: I made a dummy peripheral for my interrupt and it just worked
<re_irc>
<@yruama_lairba:matrix.org> so no need to fix interrupt if it's wrong ?
<re_irc>
<@walstib-alex:matrix.org> No idea, I need more context of what's wrong with said interrupt.
<re_irc>
If you want to compare chips you can probably run cargo doc with different features on the PAC
<re_irc>
<@walstib-alex:matrix.org> +source
<re_irc>
<@yruama_lairba:matrix.org> > If you want to compare chips you can probably run cargo doc with different features on the PAC source
<re_irc>
> this is what i do !
<re_irc>
<@yruama_lairba:matrix.org> > If you want to compare chips you can probably run cargo doc with different features on the PAC source
<re_irc>
> this is what i do !
<re_irc>
<@yruama_lairba:matrix.org> > If you want to compare chips you can probably run cargo doc with different features on the PAC source
<re_irc>
> this is what i do !
<re_irc>
<@yruama_lairba:matrix.org> ->
<re_irc>
<@walstib-alex:matrix.org> As long as you rebuild the pacs (svd2rust) between I think it should be valid
<re_irc>
<@yruama_lairba:matrix.org> however, i don't see a link between interrupt and peripheral in documentation
<re_irc>
<@walstib-alex:matrix.org> +edits
<re_irc>
<@walstib-alex:matrix.org> I don't recall finding that in the docs either, but at some point it did?
<re_irc>
Is this what you're having a problem with?
<re_irc>
<@walstib-alex:matrix.org> * did matter?
<re_irc>
<@yruama_lairba:matrix.org> no, in svd file, i think the interrupt defined in peripheral is wrong
<re_irc>
<@walstib-alex:matrix.org> Ah, now I get you 👍
<re_irc>
<@walstib-alex:matrix.org> So it's linking up to some invalid (or no) nvic line?
<re_irc>
<@walstib-alex:matrix.org> Ah, now I think I get you 👍
<re_irc>
<@yruama_lairba:matrix.org> i just don't know how it affect the generated pac
<re_irc>
<@walstib-alex:matrix.org> Did you link a pastebin or somesuch already? Also feel free to dm me, we're flooding the channel I think
<re_irc>
<@walstib-alex:matrix.org> +for the svd
<re_irc>
<@adamgreig:matrix.org> : you can run "svdtools interrupts svd/stm32f413.yaml.patched" to see a list of all the interrupts in the patched svd
<re_irc>
<@walstib-alex:matrix.org> : Do you happen to know if there is a strict dependence on a defined peripheral for each interrupt?
<re_irc>
<@adamgreig:matrix.org> the interrupt tags live inside a peripheral tag, but there isn't otherwise any relation
<re_irc>
<@adamgreig:matrix.org> ie the uart peripheral could contain the entire chip's interrupts
<re_irc>
<@adamgreig:matrix.org> ideally each peripheral would only contain the interrupts relevant to it
<re_irc>
<@walstib-alex:matrix.org> Alright, I'll probably have another look at that for the lpc43xx then :)
<re_irc>
<@yruama_lairba:matrix.org> adamgreig: i confirm, interrupt is wrong... on the chip i picked up the the peripheral definiton
<re_irc>
<@yruama_lairba:matrix.org> however, the interrupt is correct in the pac
<re_irc>
<@yruama_lairba:matrix.org> lol, in fact many stm32interrupt have the correct comment but are defined in the wrong peripheral. When generating pac, the perpipheral where it's defined seems irrelevant, so the pac is correct
dc740 has quit [Remote host closed the connection]