<cr1901>
dirbaio[m]: You've given me several examples over the years of "things you can't do in Rust traits/embedded Rust because they break once you recursively call them"
<cr1901>
It's in my logs _somewhere_ but I can't be arsed to look for them :P
<dirbaio[m]>
Static mut or unsafecell stuff that's unsound when called reentrantly?
<cr1901>
probably that, but I seem to recall there was something about traits involved too
<cr1901>
I'll do a grep for "recusive" and "dirbaio" later
<JamesMunns[m]>
<thejpster[m]> "cs should have a MutexCell..." <- Check out the `mutex` crate, I made that
cr1901 has quit [Read error: Connection reset by peer]
lehmrob has joined #rust-embedded
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
<braincode[m]>
<dirbaio[m]> "it used to be possible wit..." <- What would it take for the Rust team to reconsider TAIT the way it was good for embassy? I stopped working on a small project because of this (didn’t like any of the workarounds) and after reading your discussions on the relevant GH issues… I thought it’d be reconsidered and fixed in the mid/near future but the discussion seems to have stalled?
<braincode[m]>
> <@dirbaio:matrix.org> it used to be possible wit TAIT but they nerfed it a bit
<braincode[m]>
* What would it take for the Rust team to reconsider TAIT the way it was good for embassy? I stopped working on a small project because of this (didn’t like any of the workarounds) and after reading your discussions on the relevant GH issues… I thought it’d be reconsidered and fixed in the mid/near future but the discussion seems to have stalled?
<burrbull[m]>
<thejpster[m]> "has anyone ever tried svd2rust..." <- For what?
<burrbull[m]>
Some custom CPU architecture?
lehmrob has quit [Quit: Konversation terminated!]
lehmrob has joined #rust-embedded
<thejpster[m]>
No, it’s a normal CPU. I think the SVD author was just confusing register size with field size and this register only has 24 useful bits in it.
<M9names[m]>
<braincode[m]> "What would it take for the..." <- I'm not an insider, but I assume everyone is busy finalising rust 2024 edition (we're only 2 releases away).
<M9names[m]>
Given the vibes in said issues, i also wouldn't hold my breath for a change of approach to TAIT any time soon
JomerDev[m] has quit [Quit: Idle timeout reached: 172800s]
<Mark[m]>
What would be considered good practice for error handling in production? I mean, there is panic-persist which is great for panics because it lets you recover debug info, and I think I saw an example somewhere where the exception handler would do some magic (well, magic for someone like me who doesn't know too much about ARM registers) and call panic. But what about HardFault? Should you just reset?
<JamesMunns[m]>
This is a pretty big "it depends" kinda question, mostly around "what can you do about it?"
<JamesMunns[m]>
Rebooting is a pretty good default, imo: it gets you back to a "known good" configuration in most cases
<JamesMunns[m]>
If you have a network or storage, it might be worth collecting the panic reason or logs, to help report diagnostics. Often a good trick is doing this in uninit ram, like panic persist does, so you aren't trying to send data after you start panicking, but instead on the next "clean" boot
<JamesMunns[m]>
But if you don't have that, then it might only be useful during development
<JamesMunns[m]>
If you're controlling something like a big heater or motor, you might want to stop that in the panic handler, or make sure that's the first thing you do on startup, for example
<JamesMunns[m]>
It depends on how "easy" it is, if it's some gpios, probably easy in the panic handler. If it needs canbus? Might be better to restart, you don't know what you were in the middle of before panicking
<thejpster[m]>
It has both two Cortex-M33 and two Hazard3 in the silicon but they share a bus interface
<JamesMunns[m]>
yep, JP's support repo seems to agree :)
<thejpster[m]>
My demo program runs five seconds of arm blinky and then reboots into risc-v for five seconds of risc-v blinky.
<thejpster[m]>
It also runs Neotron OS in Arm mode (really fricking fast) but I can't take that to the pub
<mabez[m]>
Oh damn, that's neat!
<ryan-summers[m]>
Interesting. I would have expected that to increase the cost substantially because from what I understand, price point is directly a result of silicon die area. I guess the CPU cores themselves are probably a small part of the overall area then
<thejpster[m]>
the ROM supports partitions, firmware signing and hashing, loads of stuff
<thejpster[m]>
Hazard3 is particularly small I hear
<thejpster[m]>
especially compared to 512K of SRAM
<ryan-summers[m]>
Yeah memory is a huge cost driver
<thejpster[m]>
you can run one arm and one hazard3 at the same time if you are weird like that
<JamesMunns[m]>
Still USB FS, but I guess you can't get everything in one update :D
<thejpster[m]>
that is the one downside I observed. There was a reason, but I forget.
<thejpster[m]>
You'll have to console yourself with a double-pumped hardware TMDS serialiser than can do 252 mega symbols per second on a 126 MHz clock
<tamme[m]>
oh looks like a nice chip to try Trustzone on, do you know if they did something special for the attribution units or just used the normal one provided by ARM?
<tamme[m]>
or rather how many regions does the SAU have?
<tamme[m]>
oh nice :) thanks!
<thejpster[m]>
says it's PMSA compliant. Plus there's a redundancy co-processor that can you feed stuff into, for TPM-style state attestation. And a glitch detector
<tamme[m]>
woah the datasheet is much bigger then the one for the RP2040 :)
danielb[m] has joined #rust-embedded
<danielb[m]>
hey look, that's the first 4-core* embedded MCU I've seen so far
<danielb[m]>
*: from probe-rs's perspective I think this would be the most straight-forward thing to think
<thejpster[m]>
when probe-rs connects it has no idea if the RISC-V core is running or the Arm core. And they both sit on ARM Debug Interface v6 which probe-rs doesn't support.
<thejpster[m]>
tamme[m]: I've spent so so so long trying to read it. And they kept changing it on me.
<danielb[m]>
probe-rs has a concept of "disabled" cores now, thanks fto some Xtensa mess
<danielb[m]>
so it'll be able to poll those and pick up a working core... once we get to that part
<thejpster[m]>
there's probably a register you can read to work out which one is up
<danielb[m]>
well, fun times ahead
<tamme[m]>
thejpster[m]: would you say the datasheet is nicely written? From what I remember the RP2040 datasheet stood out to me as very approachable
<thejpster[m]>
same approach, for sure
pacarito[m] has joined #rust-embedded
<pacarito[m]>
Is there any public online articles that speaks to Rust's large embedded workforce? I'm writing a short article and need a reference.
<JamesMunns[m]>
pacarito[m]: there's the 2023 rust survey
<JamesMunns[m]>
we're planning on running our own shortly
<dirbaio[m]>
says size zero but it does tkae up space
<dirbaio[m]>
s/tkae/take/
<dirbaio[m]>
typically stuff in .data can be adjusted so the initial value is all zero/uninit so it ends up in .bss instead and doesn't waste flash space
<dirbaio[m]>
but hard to do if I have no idea what it is
<JamesMunns[m]>
does addr2line give anything?
<JamesMunns[m]>
not sure if that works for data defs
<cbjamo[m]>
The QMI also has address translation, which is very cool.
<thejpster[m]>
Pretty sure I can a UNIX for it with two address windows for the kernel and two for the currently running process. There’s notes on it in my blog.
<thejpster[m]>
* I can write a UNIX
M-jik-[m] has joined #rust-embedded
<M-jik-[m]>
👋
<M-jik-[m]>
Hi everybody, good any time of day
<thejpster[m]>
Also worth noting it has two QSPI chip selects and each has a 16MB window (actually four 4MB windows) and either can be PSRAM or Flash. So if you can boot from UART or OTP you can have 32MB of PSRAM. I wonder if you can load a sector from SD using just the 8KiB of OTP.
<cbjamo[m]>
The possibilities for an OTP bootloader are pretty interesting to me. An SD bootloader is probably the most interesting.
<cbjamo[m]>
I also wonder if you could do some crimes with a flash to boot, then mux over to another psram.
<dirbaio[m]>
you can make the rom jump to otp and run it at code? :o
<dirbaio[m]>
s/at/as/
<cbjamo[m]>
Yeah
<dirbaio[m]>
huh
<cbjamo[m]>
I believe the canonical use would be a bootloader that loads an encrypted firmware to run in ram.
<dirbaio[m]>
very neat. and 8k seems big enough to do interesting things
<pacarito[m]>
James, did you mean to indicate there would be another survey soon for 2024?
<JamesMunns[m]>
I need to finalize the question list, submit the PR, and coordinate when we'll run it. I'd hope we have the results in the next month or so?
<JamesMunns[m]>
pacarito ^
<pacarito[m]>
JamesMunns[m]: Ok great. I'll probably write another article later about this. Also, I'll post my article when I publish it next week so you can take a look. Its a short section on embedded Rust .
<JamesMunns[m]>
Feel free to ping me if you need review for anything, where are you writing the article for?