<re_irc>
<@jamesmunns:beeper.com> if thats the whole proto, I'd be tempted to hack a one off for it. Or hack prost to not use box
starblue1 has joined #rust-embedded
_whitelogger has joined #rust-embedded
_whitelogger has quit [Ping timeout: 240 seconds]
cr1901_ has quit [Ping timeout: 240 seconds]
_whitelogger_ has joined #rust-embedded
_whitelogger_ has quit [Ping timeout: 240 seconds]
_whitelogger has joined #rust-embedded
hmw has joined #rust-embedded
hmw has joined #rust-embedded
hmw has quit [Changing host]
starblue1 has joined #rust-embedded
jasperw has joined #rust-embedded
inara has joined #rust-embedded
cr1901_ has joined #rust-embedded
emerent has joined #rust-embedded
duderonomy has joined #rust-embedded
mrtazz has joined #rust-embedded
corecode has joined #rust-embedded
m5zs7k has joined #rust-embedded
cr1901_ is now known as cr1901
jasperw has quit [Ping timeout: 255 seconds]
jasperw has joined #rust-embedded
m5zs7k_ has joined #rust-embedded
mrtazz has quit [Ping timeout: 255 seconds]
m5zs7k has quit [Quit: m5zs7k]
duderonomy has quit [Ping timeout: 255 seconds]
emerent has quit [Ping timeout: 255 seconds]
emerent has joined #rust-embedded
duderonomy has joined #rust-embedded
mrtazz has joined #rust-embedded
jasperw has quit [Ping timeout: 255 seconds]
jasperw has joined #rust-embedded
m5zs7k_ is now known as m5zs7k
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
radens has joined #rust-embedded
re_irc has quit [Server closed connection]
re_irc has joined #rust-embedded
emerent has quit [Ping timeout: 255 seconds]
emerent has joined #rust-embedded
crabbedhaloablut has quit [Server closed connection]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<@sparky:matrix.possumlodge.me> probably just barely on topic to ask but... anyone have books, videos, whatever they recommend if i want to learn how to design PCBs and make them work with "bare" devices like sensors, processors, etc? i know theres things to take into account like voltage regulation, capacitors, etc but i doubt thats anywhere near enough to make things function safely. would be very interested in somewhere i can go to learn what...
<re_irc>
... im missing on that front
<re_irc>
<@sparky:matrix.possumlodge.me> just tired of everything being a mass of daughterboards and wires i try and vaugely stuff into a container... would like to try and finally get to the next step
<re_irc>
Most of his newer stuff is with Altium now that they sponsor him, I'd recommend to watch one of the Kicad videos.
<re_irc>
<@korken89:matrix.org> : I'm not actively maintaining it anymore, we moved our products to nRF52s and since then I did not have time to help there anymore.
<re_irc>
<@korken89:matrix.org> +during the chip-shortage
radens has quit [Quit: Connection closed for inactivity]
<re_irc>
<@jaxter184:matrix.org> is there anything special I have to do to get ADC functionality on a custom board? I'm using an stm32h723, and all my ADC reads are returning the maximum value (changes depending on bit depth configuration). Using the pin as a regular digital GPIO works as expected; goes high when the analog value is close to 3.3, and low when its close to 0. My suspicion is that it's something to do with vref, and I didn't see any...
<re_irc>
... configuration options for it in "stm32h7xx-hal", and it seems that the hal configures the ADC to use the internal voltage reference. Am I maybe understanding how the internal reference works? I currently have my external vref pin floating, was I supposed to connect it to something?
<re_irc>
<@adamgreig:matrix.org> Do you have a dev board or anything to try the code on? Probably a lot of things could cause this but the hal should take care of most of them for you. I think usually if vref is unused you want to decouple it to ground but the datasheet will say for surr
<re_irc>
<@jaxter184:matrix.org> I do, and the dev board also works fine
<re_irc>
<@jaxter184:matrix.org> the main example that im testing is just the basic adc example
<re_irc>
<@jaxter184:matrix.org> I'll take another look at the datasheet though
<re_irc>
<@adamgreig:matrix.org> Does the Dev board have vref hooked up to 3v3 or something like that?
<re_irc>
<@adamgreig:matrix.org> When the h7 hal talks about "vrefint" I think it's talking about the internal ADC channel used to read the internal reference voltage, not about configuring the adc to be referenced to it, but I don't have my computer handy to actually check the hal or the reference manual
<re_irc>
<@jaxter184:matrix.org> : hard to tell, but it might be? I'll try shorting it on my board
<re_irc>
<@adamgreig:matrix.org> Yea, I think you have to connect vref+ and it must then be used for the reference
<re_irc>
<@jaxter184:matrix.org> yep, that fixed it
<re_irc>
<@adamgreig:matrix.org> I think I was wrong and you can use the vrefbuf peripheral when vref isn't externally connected?
<re_irc>
<@adamgreig:matrix.org> But maybe not in the current hal, might have to configure it manually
<re_irc>
<@adamgreig:matrix.org> Section 27 in rm0433
<re_irc>
<@firefrommoonlight:matrix.org> Of note, I think this has more to due to with-pin packages than H7 specificially
<re_irc>
<@juliand:fehler-in-der-matrix.de> : Someone with matrix handle "RandomExplosion" talking about how shorting stuff makes em shiver does seem a little ironic... is there more to it?
<re_irc>
<@adamgreig:matrix.org> Some packages don't have vref+ and then it's bonded to vdda internally and then the vrefbuf can't be used, but yea I think the general setup is more or less the same across most of the newer families
<re_irc>
<@randomexplosion:matrix.org> : Lol, I've popped a few capacitors in my time, most of my time but the real trauma is from frying things after incorrectly guessing which 4 unlabelled pins on a smart device were the debug UART
<re_irc>
<@randomexplosion:matrix.org> -most of my time
<re_irc>
<@randomexplosion:matrix.org> all of which were because i was too impatient to brute force with my multimeter
<re_irc>
<@randomexplosion:matrix.org> none of them were too expensive tho, mostly just cheap stuff
<re_irc>
<@juliand:fehler-in-der-matrix.de> : True haha, I will make sure to not simply short pins on my boards in the future ;)
<re_irc>
<@adamgreig:matrix.org> ( jaxter184 )
<re_irc>
<@adamgreig:matrix.org> * jaxter184:
<re_irc>
<@jaxter184:matrix.org> oh, i see, so i need to manually configure this vref peripheral if i leave the pin floating?
<re_irc>
<@jaxter184:matrix.org> a good alternative option to shorting pins, thanks!
starblue1 has quit [Ping timeout: 240 seconds]
starblue1 has joined #rust-embedded
richardeoin has quit [Ping timeout: 268 seconds]
richardeoin has joined #rust-embedded
emerent has quit [Ping timeout: 240 seconds]
emerent has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
Michael[m]123415 has quit [Read error: Connection reset by peer]
Michael[m] has joined #rust-embedded
<re_irc>
> I haven't had time to read into any of these discussions.
<re_irc>
> that being said, I'd think is wise to follow what the UCG team says as it's likely that what they say is UB or not will eventually get implemented in the compiler optimization passes.
<re_irc>
> regarding singletons, they play no role in memory safety as one pretty much cannot trigger UB with unsynchronized register access since all registers are in strongly-ordered memory (at least that's the case for Cortex-M devices) and pretty much behave like atomics with load and store but no CAS operations. I have no concerns with using a different mechanism to ensure exclusive access and/or guarantee non-leaky abstractions; even if one chooses...
<re_irc>
... the C way and makes all registers globally visible and modifiable by anyone that won't result in UB.
<re_irc>
<@thejpster:matrix.org> Sounds like agreement with the general sentiment here.
<re_irc>
<@thejpster:matrix.org> : ^^
<re_irc>
<@dirbaio:matrix.org> what about the "steal() sets the taken flag" thing?
<re_irc>
<@jamesmunns:beeper.com> which _should_ also show up as a warning in the output, like "these look similar, but are different. are you using two versions of the same crate", but maybe it isn't applied everywhere that can show up
<re_irc>
<@dirbaio:matrix.org> it could be that the funcs differ in lifetimes
<re_irc>
<@dirbaio:matrix.org> compiler errors with these get pretty bad e
<re_irc>
<@dirbaio:matrix.org> -e
<re_irc>
<@dirbaio:matrix.org> especially with RPITIT which is pretty new
<re_irc>
<@dirbaio:matrix.org> if you could file a Rust issue with a self-contained repro, i'm sure the Rust folks will appreciate it
<re_irc>
<@bugadani:matrix.org> : no way, StorageError is local. It's me trying to blanket-impl an async trait
<re_irc>
<@jamesmunns:beeper.com> Oh, even more fun :D
<re_irc>
<@jamesmunns:beeper.com> Definitely open an issue then! That stuff gets fixed reasonably quickly and is so good
<re_irc>
<@bugadani:matrix.org> I'll do my best if it repros on godbolt
<re_irc>
<@dirbaio:matrix.org> oh it's with AFIT? what
<re_irc>
<@jamesmunns:beeper.com> We reported a diagnostic nit on day two of a training, and by the end of the 6 day training, it was already fixed in nightly
<re_irc>
<@dirbaio:matrix.org> "impl<B: Foo> Foo for B" is a "tautological circular impl" tho
<re_irc>
<@dirbaio:matrix.org> "impl Foo for B if Foo is impl'd for B"
<re_irc>
<@bugadani:matrix.org> that's true lol
<re_irc>
<@bugadani:matrix.org> wasn't thinking, but it's not necessary
<re_irc>
<@jamesmunns:beeper.com> (still should give a better error tho)
<re_irc>
<@dirbaio:matrix.org> for non-async fns it's allowed
<re_irc>
<@dirbaio:matrix.org> though Rust considers that impl to apply to no type
<re_irc>
<@dirbaio:matrix.org> but to conflict with an impl for every time :D
<re_irc>
<@bugadani:matrix.org> I'm playing with flash storage, where my higher level code works with byte-aligned data, but the lower level driver is whatever alignment. I have some generic-ish "alignment-middleware". The idea was, that drivers that only support word-aligned operations would implement "AlignedDriver: Driver", and byte-aligned drivers would implement "Driver". Then, the blanket impl would provide the magic that aligns the...
<re_irc>
- a driver that implements "Driver" is usable as both "AlignedDriver" and "Driver"
<re_irc>
- a driver that implements "AlignedDriver" is usable as both "AlignedDriver" and "Driver"
<re_irc>
?
<re_irc>
<@bugadani:matrix.org> AlignedDriver would have been just an implementation helper, and every operation is done with a Driver
<re_irc>
<@dirbaio:matrix.org> ah okay so
<re_irc>
or
<re_irc>
<@dirbaio:matrix.org> a driver can implement AlignedDriver, and then get the Driver impl automatically
<re_irc>
a driver can implement Driver directly
<re_irc>
<@dirbaio:matrix.org> ?
<re_irc>
<@bugadani:matrix.org> correct
<re_irc>
trait AlignedDriver {..}
<re_irc>
impl<T: AlignedDriver> Driver for T {..}
<re_irc>
trait Driver {..}
<re_irc>
<@dirbaio:matrix.org> that would be
<re_irc>
<@dirbaio:matrix.org> with no supertraits I think
<re_irc>
<@bugadani:matrix.org> oh come on
<re_irc>
<@bugadani:matrix.org> that is seriously stupidly obvious, thank you
<re_irc>
<@dirbaio:matrix.org> the downside is you can't use a "Driver" as an "AlignedDriver"
<re_irc>
<@dirbaio:matrix.org> users always have to use "Driver"
<re_irc>
<@bugadani:matrix.org> that's okay
<re_irc>
<@dirbaio:matrix.org> I don't think that's possible to do, you'd need blanket impls in both directions which would conflict
<re_irc>
<@bugadani:matrix.org> no matter, it wasn't intended anyway
Darius has quit [Server closed connection]
Darius has joined #rust-embedded
<re_irc>
Generally speaking, is disabling interrupts safe and enabling them unsafe?
<re_irc>
<@romancardenas:matrix.org> Hi folks! I'm here with safety questions again 😅
<re_irc>
<@adamgreig:matrix.org> Generally speaking, no interaction with safety
<re_irc>
<@adamgreig:matrix.org> It only comes about because of specific guarantees c-m tries to uphold
<re_irc>
<@adamgreig:matrix.org> In particular, it means if you're in an interrupt-free critical section, you can rely on interrupts not getting re-enabled halfway through, without which it's super super hard to write sound unsafe code
<re_irc>
<@adamgreig:matrix.org> So for example the cortex-m provided implementation of the critical-section trait, it disables all interrupts, runs the closure, then re-enables... if safe code could enable interrupts in the middle, the code in the closure would no longer actually be in a critical section
<re_irc>
<@adamgreig:matrix.org> Loads of other code needs those guarantees to exist in order to be sound, so cortex-m makes it unsafe to enable interrupts
<re_irc>
<@romancardenas:matrix.org> Yes, I think I like enabling interrupts/changing priorities being unsafe. But I was thinking about leaving disable-like functions safe, as I don't see potential issues with critical sections. What do you think?
<re_irc>
<@adamgreig:matrix.org> Indeed, disabling can be safe without issue, it is in cortex-m too
<re_irc>
<@romancardenas:matrix.org> Great, I'll follow this approach then. Thank you!
losglow has joined #rust-embedded
IlPalazzo-ojiisa has quit [Quit: Leaving.]
starblue1 has joined #rust-embedded
dc740 has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
dc740 has joined #rust-embedded
<re_irc>
<@fuse117:matrix.org> why is there a "Write" trait for "embedded_hal::serial", but not a "Read" trait anymore?
<re_irc>
<@dirbaio:matrix.org> oh boi
<re_irc>
<@dirbaio:matrix.org> tldr is "nobody agreeson what it should look like"
<re_irc>
<@dirbaio:matrix.org> * agrees on
starblue1 has quit [Quit: WeeChat 3.8]
losglow has quit [Quit: WeeChat 3.8]
<re_irc>
<@fuse117:matrix.org> what is a good way to read an unknown number of bytes on a UART interface?
dc740 has quit [Remote host closed the connection]
<re_irc>
<@mvirkkunen:matrix.org> fuse117 With embedded-hal? You read byte by byte until you get the bytes you're looking for. But the actually efficient way depends on your hardware.
<re_irc>
<@mvirkkunen:matrix.org> * hardware and the way you determine how many bytes to read.
<re_irc>
<@mvirkkunen:matrix.org> One example of an efficient way would framing with a unique byte, and using a circular DMA transfer combined with a character match interrupt. But the availability of those things depends on your specific chip.
<re_irc>
<@firefrommoonlight:matrix.org> fuse117: Use an idle interrupt to end the xfer
<re_irc>
<@firefrommoonlight:matrix.org> And as Lumpio said, a char match interrupt is a great place to start the xfer, assuming the protocol starts with a known byte
<re_irc>
<@firefrommoonlight:matrix.org> This is, as you guess, more complicated than reading a message of known size, but isn't so bad
<re_irc>
<@firefrommoonlight:matrix.org> At least it wasn't ushart
<re_irc>
<@dirbaio:matrix.org> at
<re_irc>
<@dirbaio:matrix.org> * wat
<re_irc>
<@mvirkkunen:matrix.org> : You can also use it with a continuously running circular DMA and process data whenever the interrupt comes in!
<re_irc>
<@firefrommoonlight:matrix.org> Valid. I've done that as well
<re_irc>
<@firefrommoonlight:matrix.org> I think I switched because I'm not sure what sort of load that puts on the DMA controller re if it adds latency on other transfers etc. Do you know?
<re_irc>
<@firefrommoonlight:matrix.org> And you have to shift the result around to align it. But I guess it reduces your chance of missing a byte, which is nice
<re_irc>
<@firefrommoonlight:matrix.org> * it reduces the
<re_irc>
<@firefrommoonlight:matrix.org> Either way, you need to disable the char match once a message starts, and re-enable once it ends