<dirbaio[m]1>
so I'm not sure how big are the gaps to fill until you can connect it to a thread network
<dirbaio[m]1>
probably big
<AndoThorNando[m]>
So if I was to not use thread specifically I would need some alternative way of bridging between my server that sits on Ethernet/Wi-Fi and the device which wouldn’t have either available?
crabbedhaloablut has joined #rust-embedded
inara` has quit [Quit: Leaving]
inara has joined #rust-embedded
nex8192 has left #rust-embedded [Error from remote client]
<dirbaio[m]1>
huh, that's a nice improvement indeed!
<dirbaio[m]1>
i've always felt the svd2rust generated code is a bit heavy on typelevel stuff though, with the RegisterSpec stuff and the read/write proxies
<thejpster[m]1>
I don't know enough about it to know why they are there or if it can be done better.
<thejpster[m]1>
I think I do still buy the "represent a SoC peripheral" with a singleton in principle, even if you do sometimes have to duplicate them to make TX/RX work.
<dirbaio[m]1>
haha the singletons are their own deep rabbit hole 🥲
<thejpster[m]1>
Although I was speaking with "big silicon vendor" the other day, and they said they were using chiptool...
<dirbaio[m]1>
oh? which one
<thejpster[m]1>
can't say
<thejpster[m]1>
but I did a whole six afternoon course on Rust, PACs, HALs, cortex-m and cortex-m-rt.
<diondokter[m]>
6! Quite a lot. Most I did was 4 haha
<thejpster[m]1>
I mean I couldn't possibly comment.
<thejpster[m]1>
In other news, has anyone played with a PSoC6 recently? Fascinating thing. A Cortex-M0+ and a Cortex-M4 sharing the same Flash and RAM.
<likewise[m]>
Why the M0+, for ultra low power??
<thejpster[m]1>
Yeah, lower power, smaller number of gates. You typically boot the M0+ first, run a secure bootloader on it, and let it boot the M4 when it's happy. I can either deep sleep, or stick around providing services.
<thejpster[m]1>
diondokter: all our trainings are six blocks of four hours. Much better than three days of 8 hours per day! That's exhausting.
<diondokter[m]>
thejpster[m]1: Yeah, the company we did it for wanted two full 8 hour days on location (2h drive for me).
<diondokter[m]>
I required a week to recover :P
<thejpster[m]1>
The interesting thing about using two cores with different architectures, is you generally end up compiling two binaries (probably sitting in separate flash erase blocks).
<thejpster[m]1>
While on the RP2040 you just say "hey core 1, execute function core1_main" and it's all in a single image.
<thejpster[m]1>
So on RP2040 you need a spinlock critical-section but on a PSoC6 with two images blocking interrupts is enough - provided your applications don't try and access the same IP blocks at the same time.
<thejpster[m]1>
Rust can't help if you have two entirely separate binaries racing on the same memory address.
<dirbaio[m]1>
I think rp2040 is the outlier there. nrf53, stm32 also seem designed so you build 2 independent firmwares one for each core.
<diondokter[m]>
thejpster[m]1: Can't you get away with letting the M4 run the same armv6m code?
<diondokter[m]>
Though I guess they have separate vector tables...
<likewise[m]>
Similar challenge to STM32MP1 I assume, with the M and A core?
<thejpster[m]1>
The M4 has 240 interrupts, which doesn't even fit in the ARMv6-M spec for a vector table.
<dirbaio[m]1>
nrf53 even has separate ram/flash
<dirbaio[m]1>
* separate ram/flash for each core
<dirbaio[m]1>
* separate ram/flash/peripherals for each core
<diondokter[m]>
dirbaio[m]1: But (some) of the ram can be shared
<dirbaio[m]1>
* separate ram/flash/peripherals for each core, it's almost like two SoCs glued together
<thejpster[m]1>
hence, svd2rust PACs not actually working in rt mode on the M0+ side. The M0+ actually only has 16 interrupts which are on a multiplexer, but the SVD file doesn't know about this.
<dirbaio[m]1>
net core can acess app core's bus (flash, ram, periphs) at a performance cost. so you're supposed to do that for IPC only, at least that's what Nordic does
<thejpster[m]1>
I'm guessing an nRF53 is a lot like an nRF9160, except on the 9160 the second core is super secret and you cannot touch it or know anything about it, and must use their APIs on the first core to talk to it.
<diondokter[m]>
thejpster[m]1: Looks like it yeah, even with the usage of the IPC peripheral
<dirbaio[m]1>
the nrf53 is even designed so you can load a blob on the net core and lock it, leaving only the app core for the usre
<dirbaio[m]1>
s/usre/user/
<dirbaio[m]1>
if you wrote your own proprietary BLE stack and wanted to sell it by the unit, for example
<diondokter[m]>
dirbaio[m]1: Yeah and most importantly leave a core open for use by the customer
* thejpster[m]1
goes back to working on his Cortex-M OS where user apps don't even run in Thread mode ;)
<dirbaio[m]1>
🙃
<thejpster[m]1>
It was good enough for the billion dollar IBM PC compatible industry
<JamesMunns[m]>
Neotron doesn't have a separated "kernel" or "supervisor context", right?
<thejpster[m]1>
correct. It's all running on the Main Stack Pointer.
<JamesMunns[m]>
(one really neat trick on cortex-m is using pendsv as your scheduler, and having apps in thread mode, since interrupts are ALWAYS. with MSP, and you can make it so pendsv runs on exit from any interrupt(s))
<JamesMunns[m]>
it's actually a really pleasant way to make a lightly partitioned OS kernel. That's what I did for the old nrf52 mnemos
<thejpster[m]1>
I suppose thinking about it, apps are in thread mode that's NOT(handler mode). But they are definitely on the MSP not the PSP.
<thejpster[m]1>
* thread mode as that's NOT(handler
<thejpster[m]1>
James Munns: I mean, that's how RTIC works, right?
<JamesMunns[m]>
It does mean you don't have to do an "interrupt stack and unstack trampoline" when you go to the kernel, since interrupts are always msp
<JamesMunns[m]>
thejpster[m]1: I don't think I've seen any rtic code use msp/psp switching, maybe they implicitly use pendsv, but I didn't think so.
<thejpster[m]1>
ah, interesting
<JamesMunns[m]>
well, mnemos 0.1 WAS based on rtic lol, so I guess that did, but I haven't seen anyone else use the msp/psp split
<JamesMunns[m]>
if you were doing pre-emptive multitasking, you could always do it "on the way out" of interrupts for free, and it'd also be the right place to update mpu rules if you wanted app partitioning
<JamesMunns[m]>
the nvic really is a very neat bit of kit
<thejpster[m]1>
I might end up introducing privilege separation for applications, if only to find some way of catching panics in user apps without needing a reboot. Or I might just leave it as-is. I used to reboot my 386 all the time, and the Neotron boots much much faster.
<JamesMunns[m]>
User apps are compiled separately, right? they could impl panic handler by doing an svcall or something
<JamesMunns[m]>
you'd have to handle recovering any shared resources or whatever tho
<thejpster[m]1>
yes user apps are separate binaries, loaded into and executed from RAM.
<thejpster[m]1>
the OS just jumps to their entry point.
<thejpster[m]1>
which is why it is very hard to recover. You'd need to store a bunch of state (all the registers) and then unsafely restore all that after the fact.
<JamesMunns[m]>
jannic no, the bridge for this room was formerly run by adam, and is now run by catherine (the same person that runs the irc log history we use), so we're good!
crabbedhaloablut has quit []
Mebus[m] has joined #rust-embedded
<Mebus[m]>
Hi,
<Mebus[m]>
i am new to rust embedded. I have got a STM32 NUCLEO-H745ZI-Q and found some example projects, but I am not shure if I am using the correct memory.x file. How can I get it?