<barafael[m]>
The HALs used to have more type state in them iirc. Did anybody write about what that was like, the problems it caused, and how it is now?
Socke has quit [Ping timeout: 252 seconds]
AtleoS has quit [Ping timeout: 264 seconds]
BrassPin88 has joined #rust-embedded
henrik_alser[m] has quit [Quit: Idle timeout reached: 172800s]
M9names[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]>
Maebli[m]: Are you using a specific chip, or HAL for running it? Or how are you trying to run your crate?
<JamesMunns[m]>
JamesMunns[m]: Or: can you share your code as a github project? That way we can see all the files in one place (instead of trying to copy and paste here)
<JamesMunns[m]>
and does it print anything? if you add a `hprintln!("Hello!")` to the top, do you see THAT output, just to rule out the setup of your code?
<Maebli[m]>
actually that code works
<Maebli[m]>
but i just pushed again, and now, in the same file (if you refresh) you will see my none function code
<Maebli[m]>
it contains more parsing,
<Maebli[m]>
i tried to debug, but debugging wasnt working
<JamesMunns[m]>
you have a lot of panics in your `try_from` code - I'm not sure why you aren't getting your panic message, but it's probably panicking and crashing.
<Maebli[m]>
That was the first assumption yes, but there is a panic handler that doesn't get called
<JamesMunns[m]>
Also, anywhere you do input[10] can crash, btw. For example, you index up to 13 or so bytes, but your example input only has like 10 bytes
<Maebli[m]>
* get called. And I'm using a payload that works on the host
<Maebli[m]>
yes its clear, there are some potential panics, but it should not panic, as it does not panic on my host
<Maebli[m]>
and the panic handler does not get called
<Maebli[m]>
if I add " panic!("This is a panic!");" in main.rs and run the panic handler works and emits "Oh noes, panic PanicInfo { message: This is a panic!, location: Location { file: "src/main.rs", line: 29, col: 5 }, can_unwind: true, force_no_backtrace: false } :("
<JamesMunns[m]>
Also your DataRecords type can hold 117 instances of DataRecord, which seems to not be very tiny, is it possible you are causing a stack overflow by creating a very huge item on the stack?
<JamesMunns[m]>
yeah, you have a total memory of 64K, are you running in debug mode?
<JamesMunns[m]>
so, it's almost certainly overflowing your stack, if you are using debug mode
<Maebli[m]>
no im not running in debug
<Maebli[m]>
can i just increase memory in memory.x
<JamesMunns[m]>
because when Rust "returns by value", you create one "slot" in the return position, and one "slot" in the called function
<JamesMunns[m]>
Maebli[m]: idk how the qemu target works
<Maebli[m]>
ok sure
<JamesMunns[m]>
maybe test by shrinking that 117 number to like... 32?
<JamesMunns[m]>
In general though, having that large of an object on the stack is not generally a good idea.
<Maebli[m]>
ok
Foxyloxy_ has joined #rust-embedded
<Maebli[m]>
ok any tipps debugging this?
<JamesMunns[m]>
you can try using flip-link, which might cause a louder fault if it's indeed a stack overflow
<JamesMunns[m]>
or like I said, try just turning the size down as a test, like to 32 items, to see if you get a real panic message and not just a corrupted stack.
<JamesMunns[m]>
If you don't make the changes in interrupts, eh, its probably fine, but definitely not safe, and you open yourself to something that works today, for you, but could break later, for someone else, if they use it differently.
<pronvis>
actually that codes executes in TIM2 interrupt with the highest priprity
<pronvis>
so, looks like in that particular case I can avoid using critical session, but in the same time be careful with changing this task priority
<pronvis>
btw, how "costly" is using critical session?
<JamesMunns[m]>
pronvis: Generally the CS itself is not, it's like <10 cycles total.
<JamesMunns[m]>
If you do "long" things INSIDE a CS, it can introduce things like interrupt delay/jitter. But one RMW is still gonna be like 10-15 cycles even with a CS
<pronvis>
ok, thanks, will wrap it into CS
<JamesMunns[m]>
pronvis: In that case, you should make your function unsafe, to note that there's a chance for corruption if people aren't "careful" how they use it.
spinfast[m] has quit [Quit: Idle timeout reached: 172800s]
phycrax[m] has joined #rust-embedded
<phycrax[m]>
I'm new to matrix and it's a bit unrelated but I want to ask what android client do you guys use? I kinda have some problems like I can't see the reply messages from James Munns sometimes
<JamesMunns[m]>
I use `beeper` on a different homeserver, I think beeper and matrix sometimes don't agree on how threads/replies work. You're not the only one.
<JamesMunns[m]>
For some people, it shows up correctly later
tamme[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]>
Reported it to Beeper, thanks for the screenshot!
<JamesMunns[m]>
phycrax I just got this response from Beeper:
<JamesMunns[m]>
> Hey, James - Talked with the Team about this. Turns out that the users that are seeing this behavior is due to legacy Element on Android not supporting replies correctly. Their recommendation is to switch to some other matrix client like SchildiChat, which is the closest to legacy element android since it's a fork, Element X or SchildiChat Next. - Beeper Support
therealprof[m] has quit [Quit: Idle timeout reached: 172800s]
adamhott[m] has quit [Quit: Idle timeout reached: 172800s]
<Maebli[m]>
<JamesMunns[m]> "flip link: https://github.com/..."; <- A big thanks for your quick help James! 🚀🚀
<diondokter[m]>
Ah, makes sense
<JamesMunns[m]>
JamesMunns[m]: the e-h-bus one doesn't support async, I think? Or it is weird in some way I can't remember?
<diondokter[m]>
It does
<diondokter[m]>
Behind a feature flag
<takkaryx[m]>
I think that's my problem, I think I've been trying to use both hals somehow, and the API's are confusing me
<takkaryx[m]>
gah
<takkaryx[m]>
Thanks all, I'll read through some more docs
<diondokter[m]>
JamesMunns[m]: Ah hmmm, true shared devices aren't async no. It's only async for the exclusive device
oneDragon[m] has joined #rust-embedded
<oneDragon[m]>
I'm a freshman, I was wondering if a bare-metal applications run on common embedded board could be use as a kind of driver board of elink ?