<re_irc>
<@metajack:matrix.org> >>> stm32h7-ac8ecc3dfb39351a.stm32h7.267aa5c4-cgu.0.rcgu.o:(__INTERRUPTS) in archive /Users/jack/src/daisy/target/thumbv7em-none-eabihf/debug/deps/libstm32h7-ac8ecc3dfb39351a.rlib
<re_irc>
<@metajack:matrix.org> Any ideas what would cause:
<re_irc>
<@metajack:matrix.org> >>> referenced by stm32h7.267aa5c4-cgu.0
<re_irc>
<@metajack:matrix.org> I'm converting an example i wrote that worked fine into an rtic app.
<re_irc>
<@newam:matrix.org> * `grep cortex-m-rt Cargo.lock` make sure you have exactly one version, multiple different versions will cause problems
<re_irc>
<@newam:matrix.org> metajack:matrix.org: Usually too much `cortex-m-rt` or not enough `cortex-m-rt`.
<re_irc>
<@newam:matrix.org> * Ensure you enabled the `"rt"` feature in the peripheral access crate.
<re_irc>
<@jamesmunns:matrix.org> Hey korken89, I noticed that `MpMcQueue`, as currently implemented, requires a non-zero initializer, which means it ends up in `.data` instead of `.bss`
<re_irc>
<@jamesmunns:matrix.org> which can be a problem, because it can "infect" structs that contain an MpMcQueue, like my slab allocator, that is like 64KiB large :D
<re_irc>
<@jamesmunns:matrix.org> I'm uh... working around that with some creative usage of `UnsafeCell<MaybeUninit<MpMcQueue>>` at the moment, which isn't great, but isn't terrible
<re_irc>
<@korken89:matrix.org> Is it fixable? I'm not that read into that queue
<re_irc>
<@korken89:matrix.org> If you can fix a PR I'll merge it :)
<re_irc>
<@jamesmunns:matrix.org> Mostly it would involve having it be a bit "lazy", e.g. to keep an init flag, and to do the initialization at runtime, either on an explicit `init`, or on first access
<re_irc>
<@jamesmunns:matrix.org> though that would be potentially non-time-deterministic, and might add a slight cost for the init check on every access
<re_irc>
<@jamesmunns:matrix.org> I figured having a huge MpMcQueue (or an MpMcQueue attached to something huge) is kind of a niche, and it means everyone who doesn't do that will pay for an extra cycle or two on every operation
<re_irc>
<@jamesmunns:matrix.org> But it was making my binary like... 70-80KiB larger than it needed to be (seriously, went from 90KiB -> 9 KiB, so flashing got way faster)
<re_irc>
<@korken89:matrix.org> Maybe worth having a type state wrapper?
<re_irc>
<@korken89:matrix.org> Like you did not or less
<re_irc>
<@jamesmunns:matrix.org> The goal is to store this in a `static`, so type state changes are suboptimal
<re_irc>
<@jamesmunns:matrix.org> (or impossible)
<re_irc>
<@korken89:matrix.org> Right
<re_irc>
<@korken89:matrix.org> Yeah then it's only a wrapper with a flag left I guess
<re_irc>
<@jamesmunns:matrix.org> in the heapless lib itself, it would mainly mean making the "cell indexes" zero at init time, then doing the initialization loop on-demand
<re_irc>
<@jamesmunns:matrix.org> (which I don't understand)
<re_irc>
<@korken89:matrix.org> Yeah, us both then :) the mpmc is from before my time.
<re_irc>
<@korken89:matrix.org> But it sounds like a wrapper with uninit if the most straight forward version
<re_irc>
<@jamesmunns:matrix.org> (needs to be unsafecell + uninit to keep the ability to make the `init` function only take an `&self`)
<re_irc>
<@jamesmunns:matrix.org> or really
<re_irc>
<@jamesmunns:matrix.org> inside of heapless itself
<re_irc>
<@jamesmunns:matrix.org> you don't need any unsafe at all
<re_irc>
<@jamesmunns:matrix.org> just an atomicbool that checks for init, and if not, runs the init loop
<re_irc>
<@jamesmunns:matrix.org> but then on every other interface you need an explicit `self.check_init();` call to do it if needed
<re_irc>
<@jamesmunns:matrix.org> so you're adding (probably after inlining, in the steady state) an atomic load, a check, and a jump
<re_irc>
<@jamesmunns:matrix.org> Since I'm outside, without forking heapless, I need the unsafecell + uninit to simulate this behavior. But it could be done safely, at the cost of a slight perf reduction.
<re_irc>
<@jamesmunns:matrix.org> Anyway, I'll open an issue and write what I find.
<re_irc>
<@jamesmunns:matrix.org> I can do the PR, it's just "is the runtime cost worth the speedup in flashing"
<re_irc>
<@jamesmunns:matrix.org> For me, rapidly iterating? Yes :D
<re_irc>
<@jamesmunns:matrix.org> for prod firmware? ehhhhh probably not
<re_irc>
<@yruama_lairba:matrix.org> hi, who using a nucleo board here ? i did a sketch with but it seems to have difficulties to start when i use a usb power plug instead usb from computer
<re_irc>
<@jamesmunns:matrix.org> I guess I just talked myself out of it :)
<re_irc>
<@jamesmunns:matrix.org> yruama_lairba: are you using something like `semihosting`?
<re_irc>
<@jamesmunns:matrix.org> The semihosting libs will typically block until a debugger is attached
<re_irc>
<@newam:matrix.org> Or RTT with a block-on-full mode?
<re_irc>
<@jamesmunns:matrix.org> which means if you connect it to not-a-computer, your program will never run
<re_irc>
<@yruama_lairba:matrix.org> i use RTT
<re_irc>
<@jamesmunns:matrix.org> Do you have your code somewhere?
<re_irc>
<@yruama_lairba:matrix.org> sometimes my program run
<re_irc>
<@jamesmunns:matrix.org> (like a git repo you can share?)
<re_irc>
<@yruama_lairba:matrix.org> sorry i didn't shared it yet the source is very messy
<re_irc>
<@yruama_lairba:matrix.org> where i can put it for temporary ?
<re_irc>
<@newam:matrix.org> In your RTT setup do you have `BlockIfFull`? You can try changing it to `NoBlockSkip`.
<re_irc>
<@jamesmunns:matrix.org> Though it looks like `NoBlockSkip` is the default?
<re_irc>
<@newam:matrix.org> Oh, hmmm 🤔
<re_irc>
<@newam:matrix.org> Oh, do you perhaps have any RTT _reads_ occuring?
<re_irc>
<@jamesmunns:matrix.org> yruama_lairba:matrix.org: github is a pretty good place :)
<re_irc>
<@yruama_lairba:matrix.org> jamesmunns: not for temporary stuff in my opinion
<re_irc>
<@newam:matrix.org> I have loads of temporary things and hacky repos on my github page :D
<re_irc>
<@jamesmunns:matrix.org> fair enough
<re_irc>
<@yruama_lairba:matrix.org> ok, so wait ~10 min, i prepare this
<re_irc>
<@metajack:matrix.org> newam: thanks, that was indeed it. I updated cortex-m-rt to 0.7 but the hal crate uses 0.6. changing to 0.6 everywhere worked.
DepthDeluxe has joined #rust-embedded
<re_irc>
<@thejpster:matrix.org> Discovery boards have a very strict interpretation of the usb standards
<re_irc>
<@thejpster:matrix.org> If the ST Link cannot negotiate 500 mA, of will not take the CPU out of reset
<re_irc>
<@thejpster:matrix.org> And usb power bricks do not negotiate
<re_irc>
<@thejpster:matrix.org> Nucleo boards may be the same
<re_irc>
<@thejpster:matrix.org> You can inject 5V by other means and bypass the ST Link
<re_irc>
<@jamesmunns:matrix.org> yruama_lairba: I don't see anything immediately bad
<re_irc>
<@jamesmunns:matrix.org> thejpster's advice might be good to try
<re_irc>
<@jamesmunns:matrix.org> The other suggestion I have is to blink an LED at a slow pace in your `idle` loop, so you can always tell if the firmware is running or not
<re_irc>
<@thejpster:matrix.org> There's a bi colour led
<re_irc>
<@thejpster:matrix.org> The user manual for the board will tell you what the colours mean
<re_irc>
<@jamesmunns:matrix.org> usually I turn it ON in the init, so I know the code made it through init, then you know if the led stops blinking, it is stuck somewhere
<re_irc>
<@jamesmunns:matrix.org> ah yeah, the stlink status led will be a good clue too.
<re_irc>
<@thejpster:matrix.org> But one combination is "not running because couldn't negotiate 500 mA"
<re_irc>
<@yruama_lairba:matrix.org> i should add this blinking led, because i'm have a side effect make me thinking it's work while it's not
<re_irc>
<@yruama_lairba:matrix.org> thejpster: checked on datasheet what the tricolor led does, it's just indicate state of communication
<re_irc>
<@yruama_lairba:matrix.org> for now, what i just want to no, can the issue comes from using rtt while not having a computer connected ?
<re_irc>
<@thejpster:matrix.org> Yes and if the st link can't communicate it won't let your code run
<re_irc>
<@thejpster:matrix.org> So you don't exceed the 100 mA USB limit
<re_irc>
<@yruama_lairba:matrix.org> thejpster: so why somtimes my code seems to run anyway ?
<re_irc>
<@yruama_lairba:matrix.org> i mean if i push the reset button on the board, it sometimes work (and don't stop)
<re_irc>
<@thejpster:matrix.org> All parts of the STM32 Nucleo board and shield can be powered from the ST-LINK USB connector CN1 (U5V or VBUS). Note that only the ST-LINK part is power supplied before the USB enumeration as the host PC only provides 100 mA to the board at that time. During the USB enumeration, the STM32 Nucleo board requires 300 mA of current to the host PC. If the host is able to provide the required power, the targeted...
<re_irc>
... STM32 microcontroller is powered and the red LED LD3 is turned ON, thus the STM32 Nucleo board and its shield can consume a maximum of 300 mA current, not more. If the host is not able to provide the required current, the targeted STM32 microcontroller and the MCU part including the extension board are not power supplied. As a consequence, the red LED LD3 remains turned OFF. In such a case it is mandatory to use an external...
<re_irc>
... power supply as explained in the next Section 6.3.2: External power supply inputs: VIN and E5V.
<re_irc>
<@thejpster:matrix.org> I'm afraid I don't know why reset might not work sometimes. I just know that you can't use a dumb USB phone charger.
<re_irc>
<@thejpster:matrix.org> If you are using a PC to power the board and you are still having issues with reset, then that sounds like some different issue.
<re_irc>
<@yruama_lairba:matrix.org> ok, so when i get i it working, it's not suposed to be ?
<re_irc>
<@yruama_lairba:matrix.org> no, i meaned i was hitting reset while beeing powered by a phone charger
<re_irc>
<@thejpster:matrix.org> Is JP1 fitted?
<re_irc>
<@yruama_lairba:matrix.org> don't know, my board is just on default setup
<re_irc>
<@thejpster:matrix.org> If JP1 is not fitted, it might be flapping - it selects a "100 mA limit" mode which allows it to work on phone charger.
<re_irc>
<@thejpster:matrix.org> See the note at the bottom of page 20/68 in the PDF I linked.
<re_irc>
<@thejpster:matrix.org> If JP1 is fitted then you can ignore me - it should work fine on a phone charger and your reset issue is something else.
<re_irc>
<@yruama_lairba:matrix.org> ok, issue is not exactly what i though, my firmware may be wrong
<re_irc>
<@yruama_lairba:matrix.org> in fact it deosn't work too wheen i just connect in my computer
<re_irc>
<@yruama_lairba:matrix.org> it doesn't work too when i just run a rtt session
<re_irc>
<@yruama_lairba:matrix.org> weird, heisen bug, it's behaviour change when i try to observe it
<re_irc>
<@yruama_lairba:matrix.org> now it doesn't work anymore with the exactly same condition as before
dcz_ has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> Does anyone know how to make a `*-ptr`? Ie, with the CMSIS wrapper, imitating this line of C: ` float32_t *inputF32, *outputF32;`
<re_irc>
<@firefrommoonlight:matrix.org> It seems like `inputF32` and `outputF32` would be buffers, but you add floats(?) to them, so I'm pretty confusedd
<re_irc>
<@firefrommoonlight:matrix.org> I'm not sure if they should be initialized like this:
<re_irc>
<@firefrommoonlight:matrix.org> let mut input = 0.;
<re_irc>
<@firefrommoonlight:matrix.org> Although that triggers issues of adding normal data to pointers in `inputF32 + (i as f32 * BLOCK_SIZE as f32)`
<re_irc>
<@firefrommoonlight:matrix.org> I probably just need to read up on pointers; current understanding is magic syntax you copy+paste to make DMA work
<re_irc>
<@firefrommoonlight:matrix.org> Looks like it could use an API-smoothing wrapper, if this is really how you do it
<re_irc>
<@firefrommoonlight:matrix.org> I just changed things around until the compiler stopped throwing errors, which is how I learned Rust
DepthDeluxe has left #rust-embedded [Leaving]
emerent has quit [Ping timeout: 260 seconds]
emerent has joined #rust-embedded
<re_irc>
<@thalesfragoso:matrix.org> You shouldn't add floats to pointers, it doesn't make sense
<re_irc>
<@thalesfragoso:matrix.org> The C lib is probably adding integers to it, not floats
<re_irc>
<@thalesfragoso:matrix.org> It's just how you work with "slices" in C, you pass a pointer to the (first) element and the length, so the function just does pointer arithmetic to access the elements
<re_irc>
<@xiretza:xiretza.xyz> firefrommoonlight:matrix.org: what the hell is that even supposed to do O.o
<re_irc>
<@xiretza:xiretza.xyz> what's the signature of `arm_fir_f32`?
<re_irc>
<@xiretza:xiretza.xyz> maybe you want `&input[i*BLOCK_SIZE..]`/`&output[i*BLOCK_SIZE..]`? but I'm really not sure
<re_irc>
<@firefrommoonlight:matrix.org> Is the C type sig. I'm not sure what the Rust is; figuring it out by adjusting based on compiler messages. I think I'm almost there
<re_irc>
<@xiretza:xiretza.xyz> well it has to come from somewhere, and that somewhere has the function signature...
<re_irc>
<@firefrommoonlight:matrix.org> So, I infer it's common to manipulate arrays in C using pointers vice &mut arrays, or something
<re_irc>
<@firefrommoonlight:matrix.org> I'm not sure how to get the Rus fn sig, which is a big issue
<re_irc>
<@firefrommoonlight:matrix.org> it's made using Bindgen
<re_irc>
<@xiretza:xiretza.xyz> which crate is it from?
<re_irc>
<@thalesfragoso:matrix.org> firefrommoonlight:matrix.org: There are no references in C land
<re_irc>
<@firefrommoonlight:matrix.org> Right now I"m making a translation guide between C type sigs and rusts
<re_irc>
<@firefrommoonlight:matrix.org> Like, when you use the various syntaxes to get certain C type sigs
<re_irc>
<@firefrommoonlight:matrix.org> `.as_ptr()`, `.as_mut_ptr()`, `as *const _ as *const f32,` etc. I have a feeling the right combination of those will make this compile
<re_irc>
<@xiretza:xiretza.xyz> I think you want `input[i*BLOCK_SIZE..].as_ptr()` and `output[i*BLOCK_SIZE..].as_mut_ptr()`
<re_irc>
<@thalesfragoso:matrix.org> You can do a lot of crazy non-sense stuff with raw pointers, just because it compiles it doesn't mean it will work
<re_irc>
<@firefrommoonlight:matrix.org> And overall, I don't intend to use this wrapper directly once I figure out. Will... wrap the wrapper if you will, in the form of simple functions
<re_irc>
<@firefrommoonlight:matrix.org> Valid point
<re_irc>
<@xiretza:xiretza.xyz> xiretza:xiretza.xyz: no unsafe required.
<re_irc>
<@firefrommoonlight:matrix.org> Will give that syntax a shot
<re_irc>
<@firefrommoonlight:matrix.org> I'll add PRs to the lib as required with the helper functions and/or examples without them
<re_irc>
<@firefrommoonlight:matrix.org> jacobrosenthal: Would you prefer this as an add-in to your wrapper crate, or separate, using your crate as a dep?
<re_irc>
<@xiretza:xiretza.xyz> also, if it doesn't work, post actual errors instead of "it throws errors"
<re_irc>
<@firefrommoonlight:matrix.org> Ie a more Rusty API to this bindgen-generated fn calls
<re_irc>
<@firefrommoonlight:matrix.org> I'll work this for a while and post results. really appreciate this
fabic has quit [Ping timeout: 268 seconds]
<re_irc>
<@firefrommoonlight:matrix.org> thalesfragoso:matrix.org: So, could you look at it as, both Rust and C have a 'low-level' pointer API that maps 1:1, eg with bindgen. Rust also has a higher-level API using arrays and refs, which is easier to work with and safer?
<re_irc>
<@firefrommoonlight:matrix.org> And of note, Rust's low level pointer API is substantially more verbose
<re_irc>
<@xiretza:xiretza.xyz> firefrommoonlight:matrix.org: sounds about right to me
<re_irc>
<@xiretza:xiretza.xyz> firefrommoonlight:matrix.org: pretty sure that's intentional - it's very rare that you need to use it, and if you do, you have to write out exactly what you want to do
<re_irc>
<@xiretza:xiretza.xyz> firefrommoonlight:matrix.org: in addition to references and arrays, there are also slices, which are a pointer+length pair (which also comes up all the time in C, but is usually handled using two distinct variables)
tokomak has quit [Ping timeout: 260 seconds]
<re_irc>
<@firefrommoonlight:matrix.org> I really like how they did this - Nice 'high-level' rust API for normal use, and 1:1 mapping for C-compatibility. That had to have been deliberate
<re_irc>
<@firefrommoonlight:matrix.org> I've evidently dodged the pointer API for a while
<re_irc>
<@xiretza:xiretza.xyz> firefrommoonlight:matrix.org: absolutely, Rust was designed as a language that could incrementally replace existing C++ code at mozilla, which necessitates good C interoperability
<re_irc>
<@thalesfragoso:matrix.org> firefrommoonlight:matrix.org: `-sys` crates are usually just the "bindgen" interface
<re_irc>
<@firefrommoonlight:matrix.org> Thanks you. That makes sense; I was wondering about the suffix. I'll make this as a separate crate that pulls in the dep
<re_irc>
<@almindor:matrix.org> I don't understand how the stack size is calculated here, I understand stack "goes up" but the recursive sizing really trips me up
<re_irc>
<@almindor:matrix.org> REGION_STACK is just RAM which is at 8k, does that mean it'll just take 8k - any previous position for the length and pseudo-recursively assign that to _start_stack ?
<re_irc>
<@dirbaio:matrix.org> stack grows downwards, ie when you push something, SP is *decremented*
<re_irc>
<@almindor:matrix.org> yes that part is clear
<re_irc>
<@dirbaio:matrix.org> so stack start/end are "backwards", it's ultra confusing
<re_irc>
<@dirbaio:matrix.org> "stack start" is the starting value of SP, which is the *end* of the stack memory region (highest address)
<re_irc>
<@almindor:matrix.org> oh so when "." "arrives" at the stack declaration it's just taken as _estack and then we jump to complete RAM end and declare it _sstack and that's it
<re_irc>
<@dirbaio:matrix.org> "stack end" is the lowest address the stack can grow to, so the *start* of the memory region 🤣
<re_irc>
<@almindor:matrix.org> yeah
<re_irc>
<@dirbaio:matrix.org> `.` is the "current cursor", when you place stuff such as code/data/bss it gets placed at `.`, and `.` gets incremented
<re_irc>
<@dirbaio:matrix.org> so when you do `_estack = .;`, `.` has the value of the first address after whatever came before, probably data/bss
<re_irc>
<@almindor:matrix.org> yeah ok makes sense now, what really tripped me was the "recursive" REGION_STACK (which is just alias for RAM)
<re_irc>
<@almindor:matrix.org> I was like "how can you do length on this when you're still deciding it later" :D
<re_irc>
<@dirbaio:matrix.org> ORIGIN(REGION_STACK), LENGTH(REGION_STACK) come from the MEMORY declaration, they're known beforehand
<re_irc>
<@almindor:matrix.org> yeah, I didn't realize coz RAM has explicit length, I thought REGION_STACK length would be a separate thing
<re_irc>
<@firefrommoonlight:matrix.org> Sweet. Looks like Lab2 has FIR examples. Will compare and adjust
<re_irc>
<@firefrommoonlight:matrix.org> That MaybeUnit thing looks interesting. If you note in my code I inited the S struct twice with a note about it being awk. I guess MU dodges that
<re_irc>
<@firefrommoonlight:matrix.org> Is there an advantage to using the `extern C` code at the bottom of the examples, and the `cty` `_t` integer types, over using native rust types, and the API produced by BIndgen directly?
<re_irc>
<@jacobrosenthal:matrix.org> Oh I'm sort of considering that a teaching resource so it builds up th abstraction Inside the example then generalizes is
<re_irc>
<@jacobrosenthal:matrix.org> First you would just copy the a file and link it job done. But then you'd want to make it a library and make it support more chips and have a cleaner api
<re_irc>
<@jacobrosenthal:matrix.org> Advantage is not using a library that downloads gigs of data to get the single a file you needed :)
<re_irc>
<@firefrommoonlight:matrix.org> Thank you for your explanation (And your work on this)
<re_irc>
<@firefrommoonlight:matrix.org> I'm working through a lowpass FIR example now based on the official CMSIS one. Not filtering properly yet, but compiling, and passing through the input
<re_irc>
<@firefrommoonlight:matrix.org> Type signature of the wrapper:
<re_irc>
<@firefrommoonlight:matrix.org> thoughts on that API?
<re_irc>
<@firefrommoonlight:matrix.org> My intent is to hide the C-interface stuff so my application code uses normal Rust
<re_irc>
<@firefrommoonlight:matrix.org> I think it's working; I just didn't have a good grasp on how the freq mentioned in the example mapped to a dimensionless array
<re_irc>
<@firefrommoonlight:matrix.org> Got it to kill high freq signals using hte coeffs from the official ARM example
<re_irc>
<@firefrommoonlight:matrix.org> (copy demt output array into python, and plot)