<conplan>
also, another question: as it is, each of the mutexes for my peripherals is a mutex of a type depending upon the configuration of the pin it holds. is there a way to make this dynamically configureable (change the type of a mutex)?
emerent has quit [Ping timeout: 252 seconds]
emerent has joined #rust-embedded
<re_irc>
< (@adamgreig:matrix.org)> you probably want a dynamically configured pin, so the type is the same, which is often provided by a hal
explore has quit [Quit: Connection closed for inactivity]
causal has joined #rust-embedded
conplan has quit [Ping timeout: 255 seconds]
starblue has quit [Ping timeout: 272 seconds]
starblue has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 258 seconds]
<re_irc>
< (@marmrt:matrix.org)> Is there a preferred way to write a panic handler which logs panic messages over a peripheral (I2C in my case)?
<re_irc>
As I understand it I have to do the whole HAL configuration with clocks and gpios in order to get an I2C handle to be able to perform a write operation.
<re_irc>
< (@marmrt:matrix.org)> But the MCU registers at that point are unlikely to be at their reset values, so I can't really guarantee that the configuration will work. Right now I'm making sure to use all the same settings as in the main app to reduce the risk of problems but I still have a hard time trusting the code at that point.
<re_irc>
< (@grantm11235:matrix.org)> One option is to write the panic data to a persistent chunk of ram and then reset, then print the panic data once your firmware reboots
<re_irc>
< (@marmrt:matrix.org)> Oo, nice. I'll look into that.
<re_irc>
< (@grantm11235:matrix.org)> I haven't used it personally, I've just overheard other people talking about it
<re_irc>
< (@marmrt:matrix.org)> What I'm doing is writing the panic message to an external FRAM
<re_irc>
< (@marmrt:matrix.org)> So I could maybe just as well write to internal RAM, provided I don't lose it when I reset
hwj has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
oak- has quit [Quit: Bridge terminating on SIGTERM]
oak- has joined #rust-embedded
<re_irc>
< (@diondokter:matrix.org)> Hey all, anybody got an idea how I can do this?
<re_irc>
I've got a TCP stream implementation for my async nrf-modem library.
<re_irc>
Because it's async, I want to be able to split the stream in a read part and a write part.
<re_irc>
Right now I've got it that both halves just borrow the original stream and this works nicely. Now when both halves are dropped the original stream is dropped as well.
<re_irc>
< (@dirbaio:matrix.org)> you can do a fixed-size global array of "open socket states" where you track which halves are open
<re_irc>
< (@dirbaio:matrix.org)> this puts a fixed upper limit on open sockets but the modem has one already I guess (?)
<re_irc>
< (@dirbaio:matrix.org)> when opening a socket, search for a free index. When splitting, each half gets the index. When dropping mark the half as closed and if both halves are closed then close the socket
conplan has quit [Remote host closed the connection]
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #rust-embedded
hwj has quit [Ping timeout: 260 seconds]
<re_irc>
< (@diondokter:matrix.org)> There is a maximum yes, so that might be an option.
<re_irc>
< (@diondokter:matrix.org)> Thanks!
hwj has joined #rust-embedded
hwj has quit [Ping timeout: 272 seconds]
explore has joined #rust-embedded
causal has quit [Quit: WeeChat 3.6]
crabbedhaloablut has quit [Ping timeout: 258 seconds]
crabbedhaloablut has joined #rust-embedded
<re_irc>
< (@nvxx:matrix.org)> is there a less verbose way of doing this:
<re_irc>
let cmd = [0xBE, 0xEF, num[0], num[1], num[2], num[3]];
<re_irc>
< (@nvxx:matrix.org)> is there a less verbose way of doing this:
<re_irc>
let num = someu32.to_le_bits();
<re_irc>
let cmd = [0xBE, 0xEF, num[0], num[1], num[2], num[3]];
<re_irc>
< (@nvxx:matrix.org)> was hoping something like "[0xBE, 0xEF, num..]" would work, saves having to type out every byte manually (and hope no accidental mistakes are made) - even though the length of num is fixed
<re_irc>
< (@chaosprint:matrix.org)> I got this error with nightly "rustc 1.66.0-nightly (a24a020e6 2022-10-18)" but "1.64 stable" works fine... don't know why
<re_irc>
< (@chaosprint:matrix.org)> I guess "stm32h7" 0.13 changes this API?
<re_irc>
< (@marmrt:matrix.org)> : If you use "heapless::Vec" you can do "cmd.extend_from_slice()"
<re_irc>
< (@nvxx:matrix.org)> I'm assuming that would have runtime overhead vs the code I posted? Was hoping for some syntactic sugar to make my life easier
<re_irc>
< (@nvxx:matrix.org)> (I'm fairly new to rust so wasn't sure if there was a little trick I was missing)
<re_irc>
< (@marmrt:matrix.org)> Not enough runtime overhead to care about
<re_irc>
< (@nvxx:matrix.org)> that might work, but again looks like a runtime thing. will probably just suck it up spelling out the array in full, at least it's only 4 bytes
<re_irc>
<Pratush Rai> I have issue in mircobit rust
<re_irc>
<Pratush Rai> when I run cargo embed
<re_irc>
<Pratush Rai> it always show Error: No supported probe was found
hwj has joined #rust-embedded
hwj2 has joined #rust-embedded
hwj has quit [Remote host closed the connection]
jr-oss_ has quit [Ping timeout: 246 seconds]
jr-oss has joined #rust-embedded
jr-oss_ has joined #rust-embedded
jr-oss has quit [Ping timeout: 260 seconds]
jr-oss has joined #rust-embedded
jr-oss_ has quit [Ping timeout: 255 seconds]
<re_irc>
<Paul Paterson> Hi all! New here but joining to stay on top of news and activity. Also want to say thanks to everyone for hard work! I'm building on top of the rp-hal packages and am very interested in the latest embedded hal alpha releases. Cheers!
jr-oss_ has joined #rust-embedded
jr-oss has quit [Ping timeout: 272 seconds]
Guest2 has joined #rust-embedded
Guest2 has quit [Quit: Client closed]
seer has quit [Quit: quit]
seer has joined #rust-embedded
hwj2 has quit [Ping timeout: 272 seconds]
explore has quit [Quit: Connection closed for inactivity]
crabbedhaloablut has quit [Quit: No Ping reply in 180 seconds.]
crabbedhaloablut has joined #rust-embedded
hwj2 has joined #rust-embedded
<re_irc>
< (@9names:matrix.org)> Pratush Rai: Which os are you running
<re_irc>
< (@adamgreig:matrix.org)> man, thumbv6 does much worse in this example
<re_irc>
< (@jamesmunns:beeper.com)> huh
<re_irc>
< (@jamesmunns:beeper.com)> still no bounds checking
<re_irc>
< (@jamesmunns:beeper.com)> but weird it uses all byte instrs
causal has joined #rust-embedded
<re_irc>
< (@adamgreig:matrix.org)> str.w is v7-only right? and v6 can't do unaligned str either, but v7 can
<re_irc>
< (@jamesmunns:beeper.com)> huh. TIL. If it was something hot, it would make sense to make it a "[u8; 8]", and just slice out the last 5 bytes
<re_irc>
< (@jamesmunns:beeper.com)> but tbh, its 9 register heavy instructions, with no external mem or flash loads
<re_irc>
< (@jamesmunns:beeper.com)> so....
<re_irc>
< (@jamesmunns:beeper.com)> honestly it's probably fine, especially if you have any flash wait states lol
<re_irc>
< (@adamgreig:matrix.org)> [u8; 8] isn't guaranteed to be aligned either, but i guess you could also align it
<re_irc>
< (@jamesmunns:beeper.com)> but if it was a stack var, it probably would be?
<re_irc>
< (@jamesmunns:beeper.com)> but yeah
<re_irc>
< (@adamgreig:matrix.org)> it's so nice that to_le_bytes a) exists b) optimises well, though
<re_irc>
< (@adamgreig:matrix.org)> if it's a stack var the stack frame is likely aligned but if you had another u8 before it then it wouldn't be, and you don't necessarily know what's gonna be allocated on the stack frame or in what order?
<re_irc>
< (@jamesmunns:beeper.com)> honestly, anything w/ indexing also optimizes really well IFF you are doing it on _arrays_ and not _slices_.
<re_irc>
< (@adamgreig:matrix.org)> i used u32::reverse_bits() recently too, another brilliant std lib entry
<re_irc>
< (@adamgreig:matrix.org)> and people say rust's std lib doesn't have much in it, have they _looked_ at the integer methods
<re_irc>
< (@jamesmunns:beeper.com)> it has all the fun bit twiddling ops
<re_irc>
< (@adamgreig:matrix.org)> all the crud you'd have to pull out your vintage "hacker's delight in c" or whatever and implement a table of twiddle factors or whatever
<re_irc>
< (@jamesmunns:beeper.com)> but! a lot of them won't trigger unless you use target-cpu=native (on desktop)
<re_irc>
< (@jamesmunns:beeper.com)> like, popcnt won't trigger in release mode without the right cpu profile
<re_irc>
< (@adamgreig:matrix.org)> need a --really-release lol
<re_irc>
< (@adamgreig:matrix.org)> beautiful hand written popcnt in x86 asm, why would you trade that for calling whatever deep dark magics are invoked by "popcnt"
<re_irc>
< (@jamesmunns:beeper.com)> lol
<re_irc>
< (@jamesmunns:beeper.com)> (it's probably the same, just with microcode)
<re_irc>
< (@adamgreig:matrix.org)> hmm, i wonder
<re_irc>
< (@adamgreig:matrix.org)> seems like it would be pretty cheap to do in hardware
<re_irc>
< (@grantm11235:matrix.org)> Here is how my "generic_const_expr" nightmare compares to james' much simpler version: https://godbolt.org/z/To1c1PshW
<re_irc>
< (@grantm11235:matrix.org)> the armv6 version is identical, but mine is worse on armv7
<re_irc>
< (@adamgreig:matrix.org)> it's got throughput of 1 instruction per cycle on modern x86 processors apparently
<re_irc>
< (@adamgreig:matrix.org)> so probably is hardcoded
<re_irc>
< (@adamgreig:matrix.org)> : incredible
<re_irc>
< (@jamesmunns:beeper.com)> : optimizing compilers are weird.
<re_irc>
< (@adamgreig:matrix.org)> just for fun, try opt-level=0 on yours
<re_irc>
< (@jamesmunns:beeper.com)> Mine becomes optimal at opt-level=1 :p
<re_irc>
< (@grantm11235:matrix.org)> I wonder how much stack mine uses with opt=0, there must be soo many copied of that "[u8; 6]"
<re_irc>
< (@adamgreig:matrix.org)> imagine doing all 2k instructions and ending up with 6 bytes that were practically all lined up before you even started
<re_irc>
< (@adamgreig:matrix.org)> poor cpu
<re_irc>
< (@jamesmunns:beeper.com)> lolol
<re_irc>
< (@jamesmunns:beeper.com)> <core::ops::index_range::IndexRange as core::iter::traits::exact_size::ExactSizeIterator>::len: