fabic has joined #rust-embedded
fabic has quit [Remote host closed the connection]
fabic has joined #rust-embedded
starblue3 has joined #rust-embedded
starblue2 has quit [Ping timeout: 240 seconds]
<re_irc> <@u​007d:m​atrix.org> The RISC-V [fu740 manual](https://sifive.cdn.prismic.io/sifive/de1491e5-077c-461d-9605-e8a0ce57337d_fu740-c000-manual-v1p3.pdf) does not appear to document the DDR controller and PHY Control register options very extensively (section 23.2.2, p.198).
<re_irc> <@u​007d:m​atrix.org> Thinking I could clone working settings, I have a copy of `u-boot` and the Freedom SDK, but cannot find where SiFive sets these registers on boot. If anyone knows the proper settings for the Unleashed board, or where I can find them documented or implemented in source, I'd very much appreciate it. (I am working...
<re_irc> ... on Step 3 of section 23.3 on page 200.)
<re_irc> <@f​irefrommoonlight:m​atrix.org> Bros. I really think Rust is a nicer lang than C/++ for embedded. We can build the future
<re_irc> <@f​irefrommoonlight:m​atrix.org> We can do it, and share our progress together. Just. Please, stop with the excess abstractions
<re_irc> <@f​irefrommoonlight:m​atrix.org> I want to be on the same team, but everything we build must be towards a concrete goal
<re_irc> <@f​irefrommoonlight:m​atrix.org> I dont' want to be the weird guy who reinvents wheels. I want to work together
dcz has joined #rust-embedded
<re_irc> <@f​irefrommoonlight:m​atrix.org> Just do the reg writes and wrap them in an appropriately named and documented function/method/class
<re_irc> <@f​irefrommoonlight:m​atrix.org> Don't wrap them in layers of `Sealed<Instance<PushPull<AF5<GPIO69>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>`
<re_irc> <@f​irefrommoonlight:m​atrix.org> thx
emerent has quit [Remote host closed the connection]
emerent has joined #rust-embedded
<re_irc> <@j​orgeig:m​atrix.org> I can see where the frustration comes from, I was there too, but after a few weeks I realized those abstractions are what is keeping things sane - otherwise you end up with the hodgepodge of C HALs
<re_irc> <@j​orgeig:m​atrix.org> Some things can be improved, and particularly on GPIOs I've often thought about how it can be done better (e.g. not having one type per pin while ensuring that only the appropriate pins are used for each periph), but throwing away the types is not what will help
<re_irc> <@j​orgeig:m​atrix.org> you can always use the PAC only if the HALs are frustrating at first!
<re_irc> <@9​names:m​atrix.org> firefrommoonlight: I hate to break it to you, but we aren't Bros
<re_irc> <@d​isasm-ewg:m​atrix.org> U007D: I think U-boot should have this. After their previous board (HiFive Unmatched) release SiFive tried to avoid publishing DRAM initialization code, and only after pressure from the community published a blob of dwords for this without any documentation.
<re_irc> <@d​isasm-ewg:m​atrix.org> Ethernet controller they use is quite polular (at least there are drivers in Linux kernel for it), so I hope the DDR controller is popular too and should be known to U-boot
fabic has quit [Ping timeout: 240 seconds]
<re_irc> <@b​igfive:m​atrix.org> adamgreig: I would like to implement a hardware independent protocol layer against a already existing interface. So I do not have to fight with a new embedded toolchain and my lacking knowledge in Rust but rather one at a time. What are the rules for a 3 years old dead crate (like...
<re_irc> ... https://crates.io/crates/canopen)? I have looked in to it and it would be good to use some or all of it to start.
<re_irc> <@b​igfive:m​atrix.org> adamgreig: Meant to answer to this
<re_irc> <@b​igfive:m​atrix.org> And not the no-std post
<re_irc> <@b​igfive:m​atrix.org> Never worked with open source but when I am looking at MIT license it should not be problem to copy the code and use this as the starting point of a new repo
<re_irc> <@e​ldruin:m​atrix.org> reusing/copying it is fine, just make sure to follow the license/s. In the case of MIT, just keep the original author's copyright
<re_irc> <@x​iretza:x​iretza.xyz> jorgeig: stm32f1xx-hal switched to const generics for GPIO pins recently, so that's nice
<re_irc> <@c​ome_744:c​onverser.eu> Have you seen stm32-hal2? It seems more simple for declaring GPIOs? What do you think about it?
<re_irc> <@c​ome_744:c​onverser.eu> (But I am not sure if it guarantees that a pin is owned only once…)
<re_irc> <@j​orgeig:m​atrix.org> I haven't worked with it but I don't think it does. It leaves it to you to configure pins properly. Which is a trade off I could take to make binaries smaller (cause no generics).
<re_irc> <@d​irbaio:m​atrix.org> gpio generics hardly cause bloat. gpio operations are typically a single register write, the code for that is the same size as for a function call
<re_irc> <@d​irbaio:m​atrix.org> generics on the "fatter" things does
<re_irc> <@d​irbaio:m​atrix.org> like usart, i2c..
<re_irc> <@j​orgeig:m​atrix.org> absolutely
<re_irc> <@j​orgeig:m​atrix.org> it's just that my use case makes me paranoid about bloat
<re_irc> <@j​orgeig:m​atrix.org> because I pay ~$30 for ~20KB of traffic for an OTA update haha
<re_irc> <@j​orgeig:m​atrix.org> so if I can shave 1K, I will!
<re_irc> <@d​irbaio:m​atrix.org> wtf, so expensive
<re_irc> <@j​orgeig:m​atrix.org> satellitesss
<re_irc> <@j​orgeig:m​atrix.org> hopefully we can bring that down soon
<re_irc> <@j​orgeig:m​atrix.org> but right now that's what it is
<re_irc> <@d​irbaio:m​atrix.org> are you compressing? :D
<re_irc> <@j​orgeig:m​atrix.org> for the normal messages we send, yes
<re_irc> <@d​irbaio:m​atrix.org> even good old deflate compresses thumb code a lot, I see like 2x compression ratio in my OTAs
<re_irc> <@j​orgeig:m​atrix.org> for OTAs haven't looked at it yet
<re_irc> <@9​names:m​atrix.org> differential updates would probably be the most effective, if you have secondary storage and the binary doesn't move around much
<re_irc> <@d​irbaio:m​atrix.org> and something more hardcore like zstd probably even more
<re_irc> <@j​orgeig:m​atrix.org> it's a problem at the bottom of our problem pile atm
<re_irc> <@j​orgeig:m​atrix.org> :D
<re_irc> <@d​irbaio:m​atrix.org> damn problem piles :D
<re_irc> <@j​orgeig:m​atrix.org> 9names: yes, when I used to do this on satellites, we just uploaded a patch - this was when we used C and linked everything statically, but I haven't gone that deep in Rust yet
<re_irc> <@j​orgeig:m​atrix.org> but yeah ideally I'd love differential
<re_irc> <@j​orgeig:m​atrix.org> or even RAM functions to test new stuff
<re_irc> <@j​orgeig:m​atrix.org> I'm sure it's doable, just haven't had the time to get there yet
fabic has joined #rust-embedded
<re_irc> <@r​icharddodd:m​atrix.org> I'm trying to debug why my program locks up during an SPI write and I'm at my wit's end.
<re_irc> <@r​icharddodd:m​atrix.org> I'm doing lots of writes batched up into 256 blocks for the DMA, and the program hangs after about 400 writes (exact number different ever time)
<re_irc> <@r​icharddodd:m​atrix.org> using embassy
<re_irc> <@r​icharddodd:m​atrix.org> I also sometimes get an error in probe-rs about an rtt error
<re_irc> <@r​icharddodd:m​atrix.org> could it be hardware failure?
<re_irc> <@r​icharddodd:m​atrix.org> gdb backtrace shows I'm in wfe. Maybe there is some race condition in the interrupt handler. I'll try to dive in
<re_irc> <@r​icharddodd:m​atrix.org> more info: adding a delay between SPI writes fixes the problem.
<re_irc> <@d​irbaio:m​atrix.org> Definitely sounds like a race yop..
<re_irc> <@c​ome_744:c​onverser.eu> adamgreig: What do you think about this one? https://docs.rs/plotters/0.3.1/plotters/index.html
<re_irc> <@a​damgreig:m​atrix.org> It's very cool! I checked it out a while back and I guess it wasn't as developed then, but on the whole it was still more work than matplotlib+inline_python for quickly getting an interactive chart on screen from some vec of points
<re_irc> <@a​damgreig:m​atrix.org> Good solution for actually generating charts when that's what your software needs to do though, where it's totally worth the extra few lines of code and anyway a python dependency wouldn't work
<re_irc> <@c​ome_744:c​onverser.eu> Finished dev [unoptimized + debuginfo] target(s) in 0.17s
<re_irc> <@c​ome_744:c​onverser.eu> % cargo run --bin=blinky
<re_irc> <@c​ome_744:c​onverser.eu> Running `/home/come/Development/probe-run/target/debug/probe-run --chip STM32F407VGTx target/thumbv7em-none-eabi/debug/blinky`
<re_irc> <@c​ome_744:c​onverser.eu> Info: Jtag cannot find a connected device.
<re_irc> <@c​ome_744:c​onverser.eu> Do you think this error message is explicit enough?
<re_irc> <@c​ome_744:c​onverser.eu> And is it okay to tell things this way?
<re_irc> <@r​icharddodd:m​atrix.org> richarddodd: I think now that the code continues to work, but rtt stops working. I've no idea why. It's not like I'm logging out loads of stuff.
fabic has quit [Ping timeout: 252 seconds]
Darius has quit [Ping timeout: 252 seconds]
Darius has joined #rust-embedded
GenTooMan has quit [Ping timeout: 250 seconds]
GenTooMan has joined #rust-embedded
<re_irc> <@u​007d:m​atrix.org> disasm: Yep. I spent a bit of time looking through the code, but couldn't find anything applicable. I asked on the SiFive forum as well and a couple of helpful souls informed me that they are loading tables of data (there are like 1500+ registers (!)). Probably why I couldn't find it because I was looking for...
<re_irc> ... source code, not data tables. Hopefully that tip gets my SDRAM issues sorted (it's only step 3 of 11 in the manual, though, so I'm guessing there are more speed bumps ahead...)
DepthDeluxe has joined #rust-embedded
<re_irc> <@u​007d:m​atrix.org> disasm: Any idea why they tried to avoid publishing DRAM initialization code? That seems weird...
GenTooMan has quit [Ping timeout: 240 seconds]
GenTooMan has joined #rust-embedded
<re_irc> <@f​irefrommoonlight:m​atrix.org> jorgeig: As dirbaio pointed out, it won't make your binaries smaller. If anything, it might make them bigger (?) due to storing u8s for the port and pin number of each `Pin` struct. The intent is a cleaner API
<re_irc> <@j​orgeig:m​atrix.org> definitely not, the binaries are smaller without the generics (in my case ~1K), whether that's worth it for most people, I guess it's not
<re_irc> <@j​orgeig:m​atrix.org> I'm not sure why you don't find the current API clean?
<re_irc> <@j​orgeig:m​atrix.org> something concrete would help - I don't develop HALs but I'm sure the people who do don't enjoy being told that they did a shitty job without suggestions!
<re_irc> <@f​irefrommoonlight:m​atrix.org> I didn't realize GPIO generics increased binary size. I mainly don't like how they complicate type signatures
<re_irc> <@a​damgreig:m​atrix.org> generics typically cause monomorphisation so you end up with duplicate code for each generic function that's called with different types
<re_irc> <@f​irefrommoonlight:m​atrix.org> For example:
<re_irc> <@f​irefrommoonlight:m​atrix.org> ```rust
<re_irc> <@f​irefrommoonlight:m​atrix.org> enable.set_high();
<re_irc> <@f​irefrommoonlight:m​atrix.org> pub fn do_thing(enable: &mut Pin) {
<re_irc> <@j​orgeig:m​atrix.org> what the second one is doing is making sure that you can use set_high on that pin
fabic has joined #rust-embedded
<re_irc> <@9​names:m​atrix.org> U007D: DDR training is a lot more complicated than you might imagine. Some of it might be IP related that they aren't keen to share, but there will be some calculations that will be done ahead of time using expensive software, and other parts that will be done by the controller itself using the instructions laid...
<re_irc> ... out in the registers.
<re_irc> <@f​irefrommoonlight:m​atrix.org> static I2C: Mutex<RefCell<Spi<SPI1>> = // ...
<re_irc> <@f​irefrommoonlight:m​atrix.org> Or:
<re_irc> <@f​irefrommoonlight:m​atrix.org> ```rust
<re_irc> <@f​irefrommoonlight:m​atrix.org> vice
fabic has quit [Ping timeout: 250 seconds]
<re_irc> <@f​irefrommoonlight:m​atrix.org> `<P: OutputPin>`, and `.unwrap()` could be viewed as syntactic noise that hurts readability and writeability, at the value of the check you pointed out
<re_irc> <@j​orgeig:m​atrix.org> it's a pretty important check 😅
<re_irc> <@f​irefrommoonlight:m​atrix.org> You could also set arbitrary values wrong, and have your code do teh wrong thing
<re_irc> <@f​irefrommoonlight:m​atrix.org> So, the check in this case would stop you from mixing up, let's say, an `is_ready` input pin, and an `opamp_enable` output pin. But they wouldn't stop you from mixing up `opamp_enable`, and `dac_enable`, for example
<re_irc> <@f​irefrommoonlight:m​atrix.org> So it's a question of "Why are these checks worth cluttering up large parts of teh program", when there are many similar errors you can make that don't have a check
re_irc has quit [Remote host closed the connection]
re_irc has joined #rust-embedded
<re_irc> <@adamgreig:matrix.org> (bumped the irc bridge, sorry for noise)
<re_irc> <@newam:matrix.org> firefrommoonlight:matrix.org: I wonder if it would be possible to get an `infallible_unwrap()` added to the language that can only be called on `Result<T, Infallible>`. 🤔
<re_irc> <@newam:matrix.org> Would help a lot with traits that can be implemented error-free.
<re_irc> <@newam:matrix.org> it doesn't help with the noise, but it does make the intent more expressive.
re_irc has quit [Remote host closed the connection]
re_irc has joined #rust-embedded
<re_irc> <@grantm11235:matrix.org> newam:matrix.org: https://github.com/rust-lang/rust/issues/61695
<re_irc> <@newam:matrix.org> Great minds think alike 🤣
<Lumpio-> I wonder if Infallible can be replaced with ! eventually
re_irc has quit [Remote host closed the connection]
re_irc has joined #rust-embedded
<agg> testing...
re_irc has quit [Remote host closed the connection]
DepthDeluxe has quit [Ping timeout: 240 seconds]
re_irc has joined #rust-embedded
<agg> ugh,
re_irc has quit [Remote host closed the connection]
re_irc has joined #rust-embedded
<agg> (testing again...)
<re_irc> <@adamgreig:matrix.org> (ok, irc bridge is seemingly back in action)
<re_irc> <@thalesfragoso:matrix.org> firefrommoonlight:matrix.org: One problem is that you need to dispatch that a runtime, and sometimes you need to set/clear pins very fast
<re_irc> <@thalesfragoso:matrix.org> Having to perform calculations through a u8 (etc) has its costs
<re_irc> <@come_744:converser.eu> come_744:converser.eu: PR submitted
DepthDeluxe has joined #rust-embedded
<re_irc> <@firefrommoonlight:matrix.org> That makes sense, re performance penalty
<re_irc> <@thalesfragoso:matrix.org> Also, more RAM, since usually the pins are ZST
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
GenTooMan has quit [Ping timeout: 240 seconds]
GenTooMan has joined #rust-embedded
<re_irc> <@newam:matrix.org> Looking for debug ideas:
<re_irc> <@newam:matrix.org> On the STM32WL when I change the sysclk to MSI 100KHz the CPU dies. Not a hard fault or an assert, it simply ceases to function.
<re_irc> <@newam:matrix.org> This _only_ occurs when switching to MSI 100KHz (from any clock source). Every other permutation of switching to/from MSI/HSI/HSE clocks works.
<re_irc> <@newam:matrix.org> Very specifically it dies on the write to `msirgsel` which sets the clock source.
<re_irc> <@newam:matrix.org> My current suspicion is that I am not respecting some sort of minimum clock frequency.
<re_irc> <@newam:matrix.org> There are a few places in the reference manual that say "The system clock frequency can be up to 64 MHz" in contradiction to the 48MHz maximum in the datasheet, I wouldn't be surprised if there was something similar going on for the minimum clock frequency. 🤔
<re_irc> <@timokrgr:matrix.org> can you select MSI as clock source when it is configured with a higher clock speed?
<re_irc> <@newam:matrix.org> Yup, I have a test that looks like this:
<re_irc> <@newam:matrix.org> SysClkSrc::Hsi,
<re_irc> <@newam:matrix.org> const CLKS: [SysClkSrc; 15] = [
<re_irc> <@newam:matrix.org> SysClkSrc::Hse(Vos::V1_0),
<re_irc> <@newam:matrix.org> There is an erratum with voltage drops when switching from low MSI clock ranges to high MSI clock ranges which can result in a `HardFault` which is why I am doing an exhaustive test in the first place; but that should be unrelated to this issue.
<re_irc> <@timokrgr:matrix.org> that is indeed very strange
<re_irc> <@timokrgr:matrix.org> ready (MSION = 1 and MSIRDY = 0)." you probably have seen and checked this already
<re_irc> <@timokrgr:matrix.org> "Warning: MSIRANGE can be modified when MSI is OFF (MSION = 0) or when MSI is
<re_irc> <@timokrgr:matrix.org> ready (MSIRDY = 1). MSIRANGE must NOT be modified when MSI is ON and NOT
<re_irc> <@timokrgr:matrix.org> ohh you so you always have to set MSIRGSEL after writing to MSIRANGE
<re_irc> <@newam:matrix.org> Yup I have that part taken care of, code in question if you want to take a look: https://github.com/newAM/stm32wl-hal/blob/rcc-debug/hal/src/rcc.rs#L503
<re_irc> <@newam:matrix.org> oh wait
<re_irc> <@newam:matrix.org> oh, nah, I got that right. MSIRGSEL is only set when MSI is on and ready.
<re_irc> <@timokrgr:matrix.org> setting MSI freq is more complicated than I though … I now realize there are MSISRANGE fields in multiple regs
<re_irc> <@newam:matrix.org> yeah 😀 just to make life more interesting
<re_irc> <@newam:matrix.org> One of them is the MSI range after exiting low power mode with fewer variants.
<re_irc> <@firefrommoonlight:matrix.org> Could you please post your relevant clock dividers?
<re_irc> <@firefrommoonlight:matrix.org> NVM you effectively did with that code chunk
<re_irc> <@newam:matrix.org> Basically that
<re_irc> <@firefrommoonlight:matrix.org> Thanks
<re_irc> <@timokrgr:matrix.org> code looks good to me
<re_irc> <@timokrgr:matrix.org> wild guess: try to swap those lines https://github.com/newAM/stm32wl-hal/blob/rcc-debug/hal/src/rcc.rs#L520-L523
<re_irc> <@timokrgr:matrix.org> does the execution now stop at when setting msirange() ?
<re_irc> <@newam:matrix.org> Yeah, it's either if I do MSIRGSEL then set CR to use that range, or set CR to use the MSIRGSEL range then set MSIRGSEL to 100k.
<re_irc> <@newam:matrix.org> That _should_ be one write (if this code was working), one write is fine for all the other MSI ranges.
<re_irc> <@firefrommoonlight:matrix.org> I can confirm from Cube that your image is a valid config
<re_irc> <@timokrgr:matrix.org> CubeMX also does not complain about any downstream peripherals that required a minimum clock
<re_irc> <@timokrgr:matrix.org> found a silicon bug after all?… maybe they just copied the specs from stm32wb devices
<re_irc> <@timokrgr:matrix.org> the wording in ref manual is the same
<re_irc> <@newam:matrix.org> CubeMX can do that? 🤯
<re_irc> <@newam:matrix.org> Huh.
<re_irc> <@firefrommoonlight:matrix.org> Oh my...
<re_irc> <@firefrommoonlight:matrix.org> It's wonderful for this use case
<re_irc> <@firefrommoonlight:matrix.org> That would show red boxes where you mouseover and it tells you what's wrong, if that was an invalid config. Much nicer than the static diagrams
<re_irc> <@newam:matrix.org> OHHHHHH.
<re_irc> <@newam:matrix.org> The STM32WL5 (dual core edition) does not work with 100k (I just tried a second unit, both are like this).
<re_irc> <@newam:matrix.org> Now this is interesting.
<re_irc> <@newam:matrix.org> I tried a STM32WLE5 (single core edition), it works with 100k.
<re_irc> <@newam:matrix.org> My money is on silicon bug now, yay!
<re_irc> <@timokrgr:matrix.org> how did they manage not to detect this?
<re_irc> <@timokrgr:matrix.org> when you have an errara like "Voltage drop on the 1.2 V regulated supply when switching MSI to 48 MHz"
<re_irc> <@newam:matrix.org> it could be they did find it; but released the product anyway.
<re_irc> <@newam:matrix.org> pre-silicon validation is difficult for analog stuff, and doing another silicon revision is usually double-digit millions (depends on process node)
<re_irc> <@firefrommoonlight:matrix.org> Frustrating
<re_irc> <@firefrommoonlight:matrix.org> For your use case, is 200Khz MSI freq ok?
dcz has quit [Ping timeout: 252 seconds]
<re_irc> <@timokrgr:matrix.org> I mean an entry in the errata would be enough if they are aware
<re_irc> <@timokrgr:matrix.org> Has anybody contacted ST regarding bugs/errata?
<re_irc> <@timokrgr:matrix.org> I can imagine it takes some time to get an errata manual updated
<re_irc> <@newam:matrix.org> timokrgr:matrix.org: For hobby stuff they said to use their forum, I am going on 6 months with unanswered Q's
DepthDeluxe has quit [Ping timeout: 250 seconds]
<re_irc> <@newam:matrix.org> Hmm. Not a silicon bug. This is a weird interaction between the nucleo's on-board STLink and the micro-controller when the clock changes. That's why it worked for the single-core version, I was using a different probe since that board doesn't have an on-board STLink.
<re_irc> <@newam:matrix.org> The test works if I don't use the on-board STLink v3.
<re_irc> <@firefrommoonlight:matrix.org> Good find
<re_irc> <@adamgreig:matrix.org> I wonder if the frequency constraint is between the swd clock and the core clock or something?
<re_irc> <@adamgreig:matrix.org> If nothing else if the core is slow the swd transactions will WAIT for ages
<re_irc> <@newam:matrix.org> Thanks so much for your help firefrommoonlight and timokrgr, I really appreciate the debug help 😀
agg has quit [Ping timeout: 240 seconds]
agg has joined #rust-embedded
<re_irc> <@u007d:matrix.org> 9names: Interesting... Thank you!
DepthDeluxe has joined #rust-embedded
DepthDeluxe has left #rust-embedded [#rust-embedded]
fabic has joined #rust-embedded
<re_irc> <@firefrommoonlight:matrix.org> On the topic of STM32 clock config, H7 clock and power cfg is evidently kind of complex compared to the others