01:06 <re_irc> unsafe {

01:06 <re_irc> tim.psc.modify(|_, w| w.psc().bits(500));

01:06 <re_irc> <Stephen D> fn setup_timer(clocks: &Clocks, tim: &pac::TIM3) {

01:06 <re_irc> // set clock prescaler

01:06 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/glhIDUxYLxE2wj7MWrfXhxiSkrPjGSI3 (18 lines)

01:07 <re_irc> <Stephen D> Not too concerned on the frequency - will sort that out once I get it running at all. The CNT register isn't budging from 0

01:15 <re_irc> <rjmp> Stephen D: did you enable the clock?

01:16 <re_irc> <rjmp> To verify that, are the config registers reading back the way you set them?

02:07 <re_irc> <Stephen D> rjmp: I have my clocks set up like this:

02:07 <re_irc> rcc.cfgr

02:07 <re_irc> .hclk(48u32.MHz())

02:07 <re_irc> .sysclk(48.MHz())

02:07 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/iUBOY1IUGVhmumsrtdLQON6z3Ov41okd (7 lines)

02:07 <re_irc> <Stephen D> rjmp: I don't think they are. I thought they might be write-only registers

02:11 <re_irc> <rjmp> Stephen D: Nope. You should be able to read back the value, and if you cannot, this usually means you have fallen victim to what I suspect is one of the most common STM32 problems of all time :).

02:11 <re_irc> <rjmp> You've got to enable clocks on a per-peripheral basis, generally speaking. You probably need something like: "rcc.apb1enr.modify(|_, w| w.tim3en().set_bit());"

02:16 <re_irc> <Dlaw> I am actually using the same stm32f411 peripheral right now (well, TIM4 instead of TIM3), and I ended up using the HAL to handle the clock enabling before dropping down to the PAC for register configuration. Not sure if this is useful at all, but here you go:

02:16 <re_irc> let _ = Timer::new(ctx.device.TIM4, &clocks); // use HAL to enable and reset

02:16 <re_irc> let timer: TIM4 = unsafe {

02:16 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/fgmZt1VaKH0iJTL28ZBine0h0Uzpugj2 (10 lines)

02:16 <re_irc> // Okay to steal because we just dropped our Timer(TIM4) reference

02:39 <re_irc> <Dlaw> (I should also add that I am new to Rust and I have no idea if this is considered the "right" way to do things)

02:51 <re_irc> < (@nihal.pasham:matrix.org)> question - do rust docs support permalinking (to specific line of text)?

02:51 <re_irc> < (@nihal.pasham:matrix.org)> I guess not but just wanted to check

03:32 <re_irc> <Stephen D> rjmp: Thanks! It's getting late but I'll try this out tomorrow

11:52 <re_irc> <Stephen D> Dlaw: Thanks, this seems to work! My ADC still isn't getting triggered so I have more to look into but the timer "cnt" register is clearly getting incremented now

12:02 <Darius> Stephen: make sure the ADC clock is also on :D

12:13 <re_irc> <Stephen D> Darius: let mut adc = Adc::adc1(

12:13 <re_irc> true,

12:13 <re_irc> AdcConfig::default()

12:13 <re_irc> adc,

12:13 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/hNkGdXiABqf9VTvSrwrZ6Y852FFINuRf (9 lines)

12:33 <Darius> I haven't used it on Rust so not sure, but make sure the ADC clock is enabled in teh RCC block

12:52 <re_irc> <Stephen D> Darius: According to the docs the Adc::adc1 method will enable the clock

12:56 <Darius> OK

13:05 <re_irc> <Dlaw> I was confused about how Adc::adc1 enables the ADC clock without &Clocks being passed in. Turns out it does it with an unsafe pointer to the RCC.

13:05 <re_irc> https://docs.rs/stm32f4xx-hal/latest/src/stm32f4xx_hal/adc.rs.html#721

13:07 <re_irc> <Dlaw> I'm confused about why the ADC HAL and timer HAL handle initialization differently ("Adc::adc1()" vs "Timer::new(TIM4, &clocks)")

13:08 <re_irc> <Dlaw> i.e. why not "Timer::tim4()" or "Adc::new(ADC1, &clocks)"

13:09 <re_irc> <Dlaw> So now I'm confused about why the ADC HAL and timer HAL handle initialization differently ("Adc::adc1()" vs "Timer::new(TIM4, &clocks)")

13:23 <re_irc> < (@adamgreig:matrix.org)> I think timer needs clocks to know what frequencies the various clock domains are so that you can configure a timer in terms of frequency

13:23 <re_irc> < (@adamgreig:matrix.org)> It can't read that from registers because it often depends on an external clock freq

13:24 <re_irc> <Dlaw> Ah, that makes sense. ADC sidesteps it by configuring its sample time in cycles rather than seconds. https://docs.rs/stm32f4xx-hal/latest/stm32f4xx_hal/adc/config/enum.SampleTime.html

13:25 <re_irc> <Dlaw> Clocks aside, is there a meaningful difference between Thing::new(INSTANCE) vs Thing::instance()?

13:39 <re_irc> < (@marmrt:matrix.org)> Yes, Thing::new(INSTANCE) consumes INSTANCE and ensures that INSTANCE cannot be used safely elsewere

13:39 <re_irc> < (@marmrt:matrix.org)> the Adc::adc1() method also consumes ADC1

13:42 <re_irc> < (@marmrt:matrix.org)> To clarify, there is no difference between Thing::new(INSTANCE) and Thing::instance(INSTANCE)

13:43 <re_irc> <Dlaw> Ah, I see, thanks. I misread a call to Adc::adc1() and didn't see ADC1 being passed in.

16:09 <steew> Hello, I am hitting a wall here.

16:10 <steew> I'm trying to make a weak symbol for some function, lets call it extern "C" fn GPIO_interrupt();

16:10 <steew> I am using a linker script where I do PROVIDE(GPIO_interrupt, somefunction);, where somefunction is defined as a pub fn

16:11 <steew> lld is complaining that it cannot find a reference to GPIO_interrupt, but it supposedly should be replacing it with somefunction if it is not defined, right?

16:12 <steew> I am pretty sure I am doing it exactly the same as cortex-m-rt here: https://github.com/rust-embedded/cortex-m-rt/blob/master/link.x.in

18:03 <re_irc> < (@adamgreig:matrix.org)> steew: Is it also no_mangle?

18:14 <steew> Yes, It is

18:15 <steew> I have to note, i finally found a fix

18:15 <steew> I think I'm doing something wrong when adding the linker scripts to cargo's path, for some reason it was not being caught, and renaming it to link.x overrides the one in riscv-rt's

18:16 <steew> I did some temp hack to import my script in other .x file and it worked now

18:16 <steew> I really have to clarify how does cargo look for linker scripts

22:14 <re_irc> < (@Ericson2314:matrix.org)> Does anyone know about getting debug info to work with ARM rwpi?

22:14 <re_irc> < (@Ericson2314:matrix.org)> I am getting link errors from invalid relocations in ".debug_info" sections, which is annoying as those sections are not actually loaded

22:17 <re_irc> < (@Ericson2314:matrix.org)> "(.debug_info+0x35): has non-ABS relocation R_ARM_SBREL32 against symbol" errors like that

22:26 <re_irc> < (@Ericson2314:matrix.org)> the issue might be that we are using "--emit-relocs"]

22:26 <re_irc> < (@Ericson2314:matrix.org)> * "--emit-relocs"\

22:26 <re_irc> < (@Ericson2314:matrix.org)> * "--emit-relocs"

22:46 <re_irc> < (@chrysn:matrix.org)> As much as I prefer working without alloc, I'm suffering a family of dependencies I can't make no_alloc in reasonable time. Is there any alloc implementation worth recommending for bare metal systems? (The awesome list has none).

22:51 <re_irc> < (@adamgreig:matrix.org)> there's https://github.com/rust-embedded/alloc-cortex-m which is a wrapper around https://crates.io/crates/linked_list_allocator, I understand some more modern alternatives include things like https://github.com/FluenTech/tlsf

22:54 <re_irc> < (@chrysn:matrix.org)> Thanks, I'll have looks at those.

22:56 <re_irc> < (@dirbaio:matrix.org)> : I don't think ropi/rwpi is supported in Rust right now. see https://github.com/rust-embedded/cortex-m-rt/issues/320