<re_irc>
< (@jamesmunns:beeper.com)> A lot of the core problem is:
<re_irc>
- Rust assumes certain things are ALWAYS true (there is never aliasing access to variables)
<re_irc>
- Rust assumes certain things about the world before it starts (e.g. statics are initialized)
<re_irc>
- Therefore: you can't initialize your own program from within your own program, because it would break one or both of the above statements
<re_irc>
< (@jamesmunns:beeper.com)> This is _also_ true in C/C++, for the record
<re_irc>
< (@jamesmunns:beeper.com)> so, you COULD write that code in Rust, it just CAN'T be the same "program". e.g. a bootloader could do that initialization for the program it loads, but the program cannot do it itself
<re_irc>
< (@jamesmunns:beeper.com)> the reason we usually "fall back" to ASM for this is that ASM has essentially no "environment rules", e.g. there are no invariants to violate, therefore there can be no undefined behavior (i'm sure this statement could be lawyered, but you get the point)
<Darius>
isn't that what we have crt0 for?
<Darius>
I mean that's what does it for C/C++
<re_irc>
< (@jamesmunns:beeper.com)> yes
<re_irc>
< (@jamesmunns:beeper.com)> in the old days, we wrote "crt0" in Rust
<re_irc>
< (@jamesmunns:beeper.com)> it was decided that this was (at least theoretically) a bad idea
<re_irc>
< (@jamesmunns:beeper.com)> now we use inline asm
<re_irc>
< (@jamesmunns:beeper.com)> (or global asm? Not sure exactly. But asm inits the world before we get to rust)
<re_irc>
< (@jamesmunns:beeper.com)> it's also not uncommon (in C/C++ embedded) projects to see a "startup_$PLATFORM.s" file in the build directories
<Darius>
righto
<re_irc>
< (@adamgreig:matrix.org)> currently the cortex_m_rt reset vector is a bastardised global_asm, hopefully soon a naked_fn
explore has quit [Quit: Connection closed for inactivity]
dc740 has quit [Remote host closed the connection]
<re_irc>
< (@adamgreig:matrix.org)> there was some hope they'd land the same time as new asm!() but there are various unresolved issues
<re_irc>
< (@adamgreig:matrix.org)> the current hope is to stabilise what used to be constrained_naked_fn only, where the only permitted body is a single asm!() call, but that's also not stable yet
darknighte has quit [Read error: Connection reset by peer]
stephe has quit [Read error: Connection reset by peer]
dreamcat4 has quit [Read error: Connection reset by peer]
stephe has joined #rust-embedded
darknighte has joined #rust-embedded
dreamcat4 has joined #rust-embedded
darknighte has quit [Changing host]
darknighte has joined #rust-embedded
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
conplan has left #rust-embedded [Leaving.]
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #rust-embedded
<re_irc>
<ilpalazzo-ojiisan> Beg pardon; is there any explanation anywhere regarding what functions are considered “naked”?
causal has quit [Quit: WeeChat 3.7.1]
<re_irc>
< (@emilgardis:matrix.org)> : good job on all the triaging!
conplan has joined #rust-embedded
<re_irc>
< (@adamgreig:matrix.org)> ilpalazzo-ojiisan: currently you can't make a naked function in stable rust, it's a proposed new feature. in general a "naked function" is one that is generated with no preamble or postamble instructions, whereas usually the compiler would add a preamble to e.g. save certain registers to the stack and maybe advance the stack pointer to allocate a stack frame for this function's local variables etc, and...
<re_irc>
... undo that on exit as required
<re_irc>
< (@adamgreig:matrix.org)> it's useful to be able to write these for very specific circumstances, like interrupt handlers on some platforms (but not on arm where the interrupt handlers expect a normal C ABI function), or in our case the reset vector
<re_irc>
< (@adamgreig:matrix.org)> but because there's no preamble, these functions can't e.g. use local variables, so they're very very limited in what they can safely do
<re_irc>
< (@rhedgeco:matrix.org)> Hey all. I am having some issues with SPI on an stm32f401. I am trying to write a continuous stream of data over SPI but it seems that there is a gap in the clock cycle every 16 bits, and it drags out one bit for longer. I found a reference to this on the STM forums, but I dont know how to fix this in rust. Any help would be appreciated.
<re_irc>
< (@jamesmunns:beeper.com)> the stm32f4 is a little different than the f0 you posted about, seems to be related to "TI mode", still looking...
<re_irc>
< (@jamesmunns:beeper.com)> Seems to be controlled by the FRF bit in CR2...
<re_irc>
< (@jamesmunns:beeper.com)> ...which defaults to "motorola" mode, and the HAL has no way of setting this to TI mode
<re_irc>
- Are you using the HAL? Or writing on the PAC yourself?
<re_irc>
< (@jamesmunns:beeper.com)> couple of questions:
<re_irc>
- Are you running in release mode?
<re_irc>
- Are you using DMA? Or how are you sending the chunks of bytes?
<re_irc>
< (@rhedgeco:matrix.org)> I am using the hal.
<re_irc>
< (@jamesmunns:beeper.com)> Gotta run, but my guess is:
<re_irc>
- it's not actually the TI mode here
<re_irc>
- DMA'ing a "block" instead of word at a time will likely fix this
<re_irc>
- this could be because you are in debug mode (VERY slow in Rust), or the SPI clock is too fast
<re_irc>
- it's probably just the software not able to "keep up" with the line rate of the hardware
<re_irc>
< (@jamesmunns:beeper.com)> that being said, if you're in release mode (at 64MHz), and only sending at 1MHz, it FEELS like that should be able to keep up
conplan has quit [Ping timeout: 260 seconds]
<re_irc>
< (@jamesmunns:beeper.com)> that being said that being said, the HAL is blocking until the send is complete before sending the next byte, so there might just be enough delay to make this apparent (e.g. it is waiting for it to be totally done, instead of ready for the next word)
<re_irc>
< (@rhedgeco:matrix.org)> it definitely improves the issue
<re_irc>
< (@rhedgeco:matrix.org)> but its still present when I pump the pclk1 to mak speed
hwj has joined #rust-embedded
<re_irc>
< (@rhedgeco:matrix.org)> each bit is 1us and the gap bits are 1.5us
conplan has quit [Quit: Leaving.]
<re_irc>
< (@rhedgeco:matrix.org)> aaaaand it seems like if I set the hclk to its max speed and pclk back to 2MHz the problem is gone. weird but ill take it
<re_irc>
< (@rhedgeco:matrix.org)> and I have to switch to BIDI mode
conplan has joined #rust-embedded
<re_irc>
< (@jamesmunns:beeper.com)> : Yeah, I suspect with a little bit of better pipelining, you could probably get rid of the gap
<re_irc>
< (@grantm11235:matrix.org)> I think it is already pipelining. As soon as it sees TXE, it writes the data and starts trying to send the next word. It never actually waits for a word to finish being send on the line
<re_irc>
fn new<T>(token: T) where T: InterruptToken<Func1> + InterruptToken<Func2> {..}
<re_irc>
< (@dirbaio:matrix.org)> interrupt functions are sometimes separate sometimes not
<re_irc>
< (@dirbaio:matrix.org)> across different chips in the same family even
<re_irc>
< (@dirbaio:matrix.org)> or in different instances of the same peripheral (stm32 timers >_>)
<re_irc>
< (@dirbaio:matrix.org)> if you can put N interrupts in the same token then the 1st case works for all chips
<re_irc>
< (@dirbaio:matrix.org)> * signature
<re_irc>
< (@korken89:matrix.org)> I pushed the fixed one
<re_irc>
< (@korken89:matrix.org)> I need to try the multi chip one more
<re_irc>
< (@korken89:matrix.org)> I'll give it a go tomorrow :)
<re_irc>
< (@korken89:matrix.org)> But looking at it, it should be fine
<re_irc>
< (@korken89:matrix.org)> coma separated list -> comma separated list
<re_irc>
< (@korken89:matrix.org)> Instead of path -> comma separated list as I have now
<re_irc>
< (@dirbaio:matrix.org)> mmm maybe more like "list of (irq -> function list)"
<re_irc>
< (@korken89:matrix.org)> Could also be done :)
<re_irc>
< (@korken89:matrix.org)> But now sleep, talk more later!
<re_irc>
< (@korken89:matrix.org)> :D
<re_irc>
< (@dirbaio:matrix.org)> and this is more of a philosophical one, but
hwj has quit [Remote host closed the connection]
hwj has joined #rust-embedded
hwj2 has joined #rust-embedded
hwj has quit [Ping timeout: 252 seconds]
<re_irc>
< (@dirbaio:matrix.org)> lol I forgot to write
<re_irc>
< (@dirbaio:matrix.org)> stm32 needs this "irq function" stuff, but other chips don't
<re_irc>
< (@dirbaio:matrix.org)> so adding support for it makes it harder to use for the chips that don't
<re_irc>
< (@dirbaio:matrix.org)> but perhaps we should just take it
<re_irc>
< (@firefrommoonlight:matrix.org)> Ralph: Depends on the details, but if the data is an unknown size, you might use Uart interrupts without DMA interrupt. Example: enable idle and char match interrupts (or rxne if you don't know start char) If char match flag is set, start the xfer and disable that interrupt. If idle is set, stop transfer, handle the data, And re enable char match
<re_irc>
< (@firefrommoonlight:matrix.org)> You can only rely on TC if you know the message len, which some serial protocols don't have
<re_irc>
< (@firefrommoonlight:matrix.org)> Depends on the details, but if the data is an unknown size, you might use Uart interrupts without DMA interrupt. Example: enable idle and char match interrupts (or rxne if you don't know start char) If char match flag is set, start the DMA xfer and disable that interrupt. If idle is set, stop transfer, handle the data, And re enable char match
conplan has quit [Ping timeout: 260 seconds]
conplan has joined #rust-embedded
hwj2 has quit [Ping timeout: 252 seconds]
conplan has quit [Quit: Leaving.]
dc740 has joined #rust-embedded
<re_irc>
< (@grantm11235:matrix.org)> : Is the user expected to call "register_interrupt!" manually for each interrupt, or can this be done inside the HAL?
<re_irc>
<Ralph> : thanks for the hint! the start char is "!" as in the linked protocol specification. but the length then depends on the second character. i think for now my setup (using DMA and line idle interrupt in combination) works fine - this isn't some large-scale production code, it's just a small tinkering project; as long as i reliably (enough) get my messages that's just fine