<re_irc>
<@disasm-ewg:matrix.org> U007D: I'm going to test PLL today with this new info. PLL lock worked strange for me: sometimes it locked, sometimes not, but one thing didn't change: after all the setup and clock switches I still got 26MHz.
dcz has joined #rust-embedded
<re_irc>
<@u007d:matrix.org> disasm-ewg:matrix.org: Wow, so odd! I've never seen a lock here. But getting a lock and still being at 26Mhz is really surprising. The clocks are woefully underdocumented, IMHO.
<re_irc>
<@disasm-ewg:matrix.org> u007d:matrix.org: Also looks ok to me, I don't understand why it's opposite
<re_irc>
<@u007d:matrix.org> disasm-ewg:matrix.org: Lightbulb from the thread Jim referenced was pretty explicit:
<re_irc>
<@u007d:matrix.org> So that
<re_irc>
<@u007d:matrix.org> >Now you can set PLLBYPASS which powers down the PLL.
<re_irc>
<@u007d:matrix.org> Clear PLLBYPASS. This starts up the PLL again and it will try to acheive lock.
<re_irc>
<@u007d:matrix.org> Change the PLL R, F, and Q factors as desired, see pages 29 and 30.
<re_irc>
<@disasm-ewg:matrix.org> FE310 also has an output divider bypass bit, which I don't use. Maybe it can fix the problem
<re_irc>
<@u007d:matrix.org> u007d:matrix.org: Actually, I copied the wrong tab. It was the "wait for the pll to stabilize before testing for lock" logic that you also pointed out. And why wou
<re_irc>
<@disasm-ewg:matrix.org> u007d:matrix.org: I don't see any reason why active lock polling would not work
emerent has quit [Ping timeout: 252 seconds]
<re_irc>
<@disasm-ewg:matrix.org> Except for maybe if it doesn't work at all
emerent has joined #rust-embedded
<re_irc>
<@disasm-ewg:matrix.org> Maybe that's why U-boot just sleeps for a while
<re_irc>
<@u007d:matrix.org> Looked to me like `u-boot` just waits 70us and "damn the torpedoes" moves on. I couldn't find a single lock check in the whole repo
<re_irc>
<@disasm-ewg:matrix.org> Yep
<re_irc>
<@u007d:matrix.org> Ugh. I don't want my code to be like that
<re_irc>
<@u007d:matrix.org> Well, I'll take a closer look at the `fe310` sdk code tomorrow and see if a more literal port from their code gives better results. Will keep you posted!
<re_irc>
<@u007d:matrix.org> Good night!
dcz has quit [Ping timeout: 256 seconds]
fabic has joined #rust-embedded
dcz has joined #rust-embedded
fabic has quit [Ping timeout: 256 seconds]
GenTooMan has quit [Ping timeout: 252 seconds]
GenTooMan has joined #rust-embedded
<re_irc>
<@disasm-ewg:matrix.org> U007D: damn, PLL works actually, it's a peripheral clock that goes through a completely different PLL and isn't changed with the coreclk frequency. I'm too addicted to STM32 clocking to realize that peripheral clocks are not necessary derived from the core clock :D
<re_irc>
<@u007d:matrix.org> disasm: good morning! awesome news! any code snippets you can share?
<re_irc>
<@disasm-ewg:matrix.org> u007d:matrix.org: Working on a PR
<re_irc>
<@u007d:matrix.org> I've been traipsing through `freedom-metal` this AM, and some definitions (e.g. `__metal_driver_sifive_fe310_g000_pll_init_rate`) are used but just not defined anywhere. Turns out that this repo is included by [`freedom-e-sdk`](https://github.com/sifive/freedom-e-sdk), where the things I couldn't find are defined.
<re_irc>
<@u007d:matrix.org> Also I came to realize I was confusing two tabs last night (both on the Freedom SDK; your interpretation of PLL *bypass* being enabled or disabled is exactly right, and is consistent between Lightbulb's post and the SDK.
<re_irc>
<@u007d:matrix.org> Ok, I'll hold on until I can take a look at what you've discovered.
<re_irc>
<@disasm-ewg:matrix.org> I also found a "product brief" for the PLL likely used in the chip. It shows a bypass mux which basically switches between PLL output and input
<re_irc>
<@disasm-ewg:matrix.org> Another similar PLL pdf can be found on one of the CN websites, it also tells that during bypass PLL is down
<re_irc>
<@disasm-ewg:matrix.org> Also both show the meaning of FSE bypass, which is in line with U-boot code comments. External feedback is not used so this bypass should be enabled all the time.
<re_irc>
<@disasm-ewg:matrix.org> I love this throttling/turboboost feature of the chip when you can switch core clock between two different PLLs without an additional delay
fabic has joined #rust-embedded
loki_val has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 276 seconds]
fabic has quit [Ping timeout: 252 seconds]
<re_irc>
<@yatekii:matrix.org> Do we have a policy for joining this channel with conduit based accounts?
<re_irc>
<@yatekii:matrix.org> maybe adamgreig ?
<re_irc>
<@adamgreig:matrix.org> Do they still warn about it maybe breaking channels? I thought it had just got into beta
<re_irc>
<@adamgreig:matrix.org> Yea, it seems like it should be fine, afaict they don't even have that warning any more?
starblue has joined #rust-embedded
<re_irc>
<@yatekii:matrix.org> I was sure they still had the warning on which is why I asked
<re_irc>
<@yatekii:matrix.org> but I can't find it now
<re_irc>
<@yatekii:matrix.org> I know they are in beta now, which is good enough for me :)
<re_irc>
<@yatekii:matrix.org> I just do not want to break any bigger channels
<re_irc>
<@yatekii:matrix.org> but no way I am running Synapse for my own homeserver :)
<re_irc>
<@u007d:matrix.org> disasm: may I have permission to push to riscv-rust/fu740-hal? I have a PR for you
<re_irc>
<@u007d:matrix.org> disasm-ewg:matrix.org: yep, I'm defintely going to be spoiled by that :)
<re_irc>
<@disasm-ewg:matrix.org> u007d:matrix.org: Check your inbox!
<re_irc>
<@disasm-ewg:matrix.org> Meanwhile I implemented peripheral PLL configuration
<re_irc>
<@disasm-ewg:matrix.org> Now all the other clocks can be added easily
<re_irc>
<@u007d:matrix.org> schweeet!
<re_irc>
<@u007d:matrix.org> I just pushed a PR which did away with the assumption that the `hfxclk` was enabled. No idea what would happen if we switched to it and it wasn't enabled, but that won't happen now. Also, if we changed its state, that is restored after use. Trying to minimize surprises/side-effects...
<re_irc>
<@disasm-ewg:matrix.org> I think it's quite a good assumption, because otherwise nothing would work
starblue has quit [Quit: WeeChat 3.0]
<re_irc>
<@u007d:matrix.org> disasm-ewg:matrix.org: Could be... I just don't have enough context yet to know all the scenarios the crate will run into...
<re_irc>
<@disasm-ewg:matrix.org> u007d:matrix.org: hfxosc cannot be disabled in this chip I think. Or can be, but it will be a kill-switch.
<re_irc>
<@u007d:matrix.org> Also, looks like we should include a `rustfmt.toml` with the repo so that the ci is happy with the formatting.
<re_irc>
<@disasm-ewg:matrix.org> u007d:matrix.org: Huh? rustfmt is already executed without `rustfmt.toml`
<re_irc>
<@u007d:matrix.org> not sure my my PR is failing then; I assume there were some non-default settings
<re_irc>
<@disasm-ewg:matrix.org> No, it uses defaults
<re_irc>
<@disasm-ewg:matrix.org> Maybe you have a local `rustfmt.toml` which overrides settings for you?
<re_irc>
<@u007d:matrix.org> nvm, that was me; I thought I had my environment set to reformat the crate, but it was set to file; false alarm! :)
<re_irc>
<@u007d:matrix.org> Do you want me to yank the HFXCLK changes then?
<re_irc>
<@disasm-ewg:matrix.org> Dunno, they look strange anyway. If CPU is running, then HFXCLK is already present, there are no internal clock sources. And this code tries to do something unrelated.
<re_irc>
<@u007d:matrix.org> disasm-ewg:matrix.org: eggsellent; I will be working on ddrclock next
<re_irc>
<@u007d:matrix.org> disasm-ewg:matrix.org: Not a problem; I
<re_irc>
<@disasm-ewg:matrix.org> All the other changes are ok, but I'd replace magic numbers with pac changes instead :)
<re_irc>
<@u007d:matrix.org> disasm-ewg:matrix.org: Oh, I agree--I just don't know how to do that yet LOL!
<re_irc>
<@disasm-ewg:matrix.org> Of course it involves solving the most complex problem of software development: we need names for these bits
<re_irc>
<@u007d:matrix.org> :) Nothing is harder than that!
<re_irc>
<@u007d:matrix.org> Ok, HFXOSCEN code removed, PR merged. Thank you for this! I'll try incorporating it into my project now to see if it works on a *2nd* board ;)
<re_irc>
<@disasm-ewg:matrix.org> TIL that I will not be able to blink LED 1.5GHz
<re_irc>
<@disasm-ewg:matrix.org> Sad day :D
<re_irc>
<@disasm-ewg:matrix.org> Peripheral clock is max 125MHz
<re_irc>
<@u007d:matrix.org> disasm-ewg:matrix.org: No billion-fps strobe photography for you! :)
<re_irc>
<@u007d:matrix.org> disasm-ewg:matrix.org: I see how to add registers, but how to add a value or a `const`?
<re_irc>
<@disasm-ewg:matrix.org> # A field in this register, matches an SVD <field> tag
<re_irc>
<@jorgeig:matrix.org> if I specify a target thumbv7em-none-eabi it breaks with fireworks including hundreds of warnings
<re_irc>
<@jorgeig:matrix.org> only to end saying it can't find stdint.h
<re_irc>
<@jorgeig:matrix.org> if I compile it for my working platform (aarch64 or x86_64), it's OK
<re_irc>
<@disasm-ewg:matrix.org> It uses C code inside, probably this is the reason
<re_irc>
<@jorgeig:matrix.org> yes
<re_irc>
<@jorgeig:matrix.org> I don't know how to specify the options for the C compiler that runs somewhere in there though
<re_irc>
<@jorgeig:matrix.org> I feel I need to tell it where the C headers are
<re_irc>
<@jorgeig:matrix.org> but if I go in Cmake and give it include_directories
<re_irc>
<@disasm-ewg:matrix.org> At least it should be possible to replace it with pure-rust libs
<re_irc>
<@jorgeig:matrix.org> nothing changes
<re_irc>
<@jorgeig:matrix.org> that's the step after I actually make lorawan work on my board haha
<re_irc>
<@newam:matrix.org> you might be able to avoid the issue entirely and use native-rust AES libraries.
<re_irc>
<@newam:matrix.org> Most of the rust-crypto stuff is no_std friendly.
<re_irc>
<@disasm-ewg:matrix.org> u007d:matrix.org: Hmm it's not that simple, but I figured out how to do this. If you want to do it yourself -- go ahead, otherwise I can push an update
<re_irc>
<@jorgeig:matrix.org> newam:matrix.org: I'm so close, and it's 3am here - I was hoping to compile, join the network, and go to sleep XDD
<re_irc>
<@jorgeig:matrix.org> so I guess it'll be a problem for the Jorge of tomorrow haha
<re_irc>
<@newam:matrix.org> That's the spirit! 😀
<re_irc>
<@disasm-ewg:matrix.org> jorgeig:matrix.org: Lots of errors (yet not all) disappeared after I installed `arm-none-eabi-newlib`
<re_irc>
<@u007d:matrix.org> disasm-ewg:matrix.org: I would be happy to see how you did it.
<re_irc>
<@u007d:matrix.org> Also, with the hal, `PRCI::setup()` consumes the peripheral. I still need `Peripheral` (and `PRCI` for that matter) for other things; I remember seeing a `split()` or something in the `e-h` ecosystem... Am I on the right track?
<re_irc>
<@jorgeig:matrix.org> disasm-ewg:matrix.org: thanks, already have it 😢
<re_irc>
<@jorgeig:matrix.org> I'm seeing you all might be right and it's probably easier to just do it native
<re_irc>
<@disasm-ewg:matrix.org> u007d:matrix.org: `split` is useful when you can do something with a peripheral from different parts of the firmware. But I can't imagine what you can do (safely) with PRCI this way.
<re_irc>
<@jorgeig:matrix.org> disasm-ewg:matrix.org: by now I have more toolchains installed than the number of atoms in the universe
<re_irc>
<@jorgeig:matrix.org> gonna have to do some serious cleanup after this 😅
<re_irc>
<@jorgeig:matrix.org> thanks for giving it a try!
<re_irc>
<@disasm-ewg:matrix.org> They still consume less space then your `target` dir I guess
<re_irc>
<@jorgeig:matrix.org> but yeah, I was looking at what the lora device implementation needs, and it's simply encrypt/decrypt, so probably even better to use the hardware module in the mcu
<re_irc>
<@newam:matrix.org> jorgeig:matrix.org: Just pushed a fix for that FYI; I wasn't disabling setting the keysize before writing the key which made it fail all 256-bit NIST vectors 😳
<re_irc>
<@newam:matrix.org> I added all the NIST to the on-target CI now, so should stay fixed.
<re_irc>
<@u007d:matrix.org> disSo what is the recommended practice if I have one function to set up my core clock, one to set up my ddr clock, another for ethernet and a fourth for the remaining peripherals? My bootloader has consumed `Peripherals` just to set the `PRCI` peripherals. How then should my application access, PWM0, for example?
<re_irc>
<@disasm-ewg:matrix.org> u007d:matrix.org: Good question. Probably since it was a bootloader, you can pretend it released Peripherals and then use Peripherals again however you like
<re_irc>
<@disasm-ewg:matrix.org> Since clock tree allows that, you can split PRCI into multiple parts (one for each clock subtree) and configure them independently, but you can do the same in one function like it's implemented currently
<re_irc>
<@u007d:matrix.org> I see. So the current `PRCI` API is not designed to support the use case I outlined, correct?
<re_irc>
<@disasm-ewg:matrix.org> u007d:matrix.org: I'm not sure I fully understand your use case
<re_irc>
<@u007d:matrix.org> disasm-ewg:matrix.org: Independent initialization of the 4 different clock trees (separation of concerns). But I think I can work around that for now. In terms of "releasing" the peripherals and picking them up again in the app--do you just mean call `Peripherals::steal()`, or did you have something else in mind?
<re_irc>
<@disasm-ewg:matrix.org> u007d:matrix.org: Current API doesn't allow independent initialization, yes.
<re_irc>
<@disasm-ewg:matrix.org> Your app will have it's own Peripherals and `Peripherals::take` should return `Some()` as usual
<re_irc>
<@u007d:matrix.org> Great, thank you for the insights--they are really helpful!