<Lumpio->
I wonder if it'd be a good idea to just add that barrier to e.g. rtic, I doubt the performance penalty would be that big
<Darius>
wow
<Darius>
some pretty nice sleuthing there
<re_irc>
<@guenther_rostig:matrix.org> MSP432E401Y Launchpad and tm4c-hal example: After converting this elf-file to an hex-file with "arm-none-eabi-objcopy" I am able to flash it with UniFlash.
<re_irc>
<@pollyglot:pyjam.as> Hey, do y'all know any good open source Rust embedded application projects? I'd like to see how people structure their projects for inspiration/stealing good ideas.
<re_irc>
<@diondokter:matrix.org> We have an open source bootloader for the nrf9160. But it's a bit small and only really does one thing: https://github.com/tweedegolf/dis-bootloader
<re_irc>
<@diondokter:matrix.org> And it uses an ancient version of embassy š
<re_irc>
<@pollyglot:pyjam.as> I was looking at anne-key, but the code is pretty old
<re_irc>
<@jamesmunns:beeper.com> Pinged out on the #embassy-rs:matrix.org (https://matrix.to/#/#embassy-rs:matrix.org) and #rtic:matrix.org (https://matrix.to/#/#rtic:matrix.org) rooms to call for more projects, I'd love to see more on that list, I'll review any PRs opened today later tonight, to make sure they all get merged!
<re_irc>
<@pollyglot:pyjam.as> : What do you think of IDF? Is it nice to work with, does it have weird bugs?
<re_irc>
<@pollyglot:pyjam.as> I'm doing a low power application, so I'm not sure if I want an OS š¤·āļø
<re_irc>
<@crespum:matrix.org> It's pretty stable because it's a wrapper of the battle-tested C IDF, but it's far from being optimized
<re_irc>
<@crespum:matrix.org> There are no_std libraries too, we have not tested them yet
<re_irc>
<@crespum:matrix.org> : Having an OS doesn't mean power consumption is high, there are more important factors
<re_irc>
<@crespum:matrix.org> But that's another discussion!
<re_irc>
<@pollyglot:pyjam.as> cool
<re_irc>
<@2:0x2c.org> esp without idf is a lot of work
<re_irc>
<@pollyglot:pyjam.as> it does seem like that
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc>
<@thejpster:matrix.org> The Infineon PSoC6 dual-core microcontroller has a Cortex-M0+ and a Cortex-M4. TIL that its PAC defines more interrupts than a Cortex-M0+ can handle. So it's impossible use the PAC interrupts on the M0+ core - it complains the vector table is too large.
<re_irc>
<@thejpster:matrix.org> > CM4 has 168 interrupt request lines (IRQ), with the interrupt source ānā directly connected to IRQn. CM0+ has eight interrupts IRQ[7:0] with configurable mapping of one or more interrupt sources to any of the IRQ[7:0]. CM0+ also supports eight internal (software only) interrupts.
<re_irc>
<@thejpster:matrix.org> I suppose if you want to program the CM0 you need a custom SVD that just lists the sixteen actual interrupts?
emerent has quit [Ping timeout: 245 seconds]
emerent has joined #rust-embedded
<re_irc>
<@2:0x2c.org> is there a rust embedded hal for RTOS tasks etc?
dc740 has joined #rust-embedded
<re_irc>
<@diondokter:matrix.org> : Not sure what your question is... Do you mean, is there a commonly shared trait for spawning threads?
<re_irc>
If so, no, not that I'm aware of
<re_irc>
<@thejpster:matrix.org> Ugh. Unpending an interrupt on this chip _immediately_ causes a double fault. The IRQ handler never runs.
<re_irc>
<@thejpster:matrix.org> What do you have to do to make the NVIC not explode on interrupt?!
dc740 has quit [Remote host closed the connection]
<re_irc>
<@halfbit:matrix.org> I understood the cm0 to be programmed with a blob usually to deal with radio stuff
<re_irc>
<@halfbit:matrix.org> do you actually need to program it in this case?
<re_irc>
<@halfbit:matrix.org> I understood the cm0 on the psoc6 to be programmed with a blob usually to deal with radio stuff
<re_irc>
<@adamgreig:matrix.org> @room meeting time again! agenda is https://hackmd.io/Urmwv1-SSQqwcLaxRVnG4Q, please add anything to announce or discuss, we'll start in 5 min
<re_irc>
<@steelph0enix:matrix.org> Hi, i'm back again with another question, this time about "cortex-m-rt" and "critical-section" (and it's integration with "cortex-m" package)
<re_irc>
<@steelph0enix:matrix.org> Let's say i generated a PAC crate. Should i put the "rt" feature in "Cargo.toml" of the PAC crate, along with "device.x" and "build.rs", or should i add it only to the final binary crate that'll use PAC?
<re_irc>
<@steelph0enix:matrix.org> I've noticed that it works find when i add "rt" and "device" features to the PAC crate, but i'm not sure if it's the right way to do it.
<re_irc>
<@steelph0enix:matrix.org> (by "works" i mean "i can make a binary crate and use PAC there, while having only "memory.x" and appropriate "build.rs" for it, while the "device.x" is handled by PAC crate)
<re_irc>
<@steelph0enix:matrix.org> * crate")
<re_irc>
<@adamgreig:matrix.org> generally PACs have an optional "rt" feature which enables cortex-m-rt's own "device" feature
<re_irc>
<@steelph0enix:matrix.org> by "optional" you mean that it should look like that?
<re_irc>
<@adamgreig:matrix.org> if you only want a new rust every year instead of every six weeks and are only building for x86-64 or aarch64 anyway :P
<re_irc>
<@adamgreig:matrix.org> next up, cortex-m and embedded-hal repos moved over to ghmq, the wg docs will certainly need updating to mention it soon
<re_irc>
<@therealprof:matrix.org> Ahh, GNAT, the good old times...
<re_irc>
<@adamgreig:matrix.org> no update on the hardfault trampoline or per-peripheral steal() PR atm
<re_irc>
<@adamgreig:matrix.org> we've had some updates to critical-section's docs that probably warrant a patch release to get them updated on docs.rs, but before we do that we could consider adding some more usage examples and perhaps a list of existing implementations
<re_irc>
<@adamgreig:matrix.org> for embedded-hal, the embedded-io traits have been merged in and so can now be used for serial, which (after a little tidying up) should unblock the last main concern before we are looking at 1.0, I think?
<re_irc>
<@adamgreig:matrix.org> nothing huge, mostly clarifications and fixing some examples
<re_irc>
<@juliand:fehler-in-der-matrix.de> : https://github.com/rust-embedded/wg/issues/383 this page (for me) suggests that there should be a 1.0 release for cortex-m-rt even before the embedded-hal 1.0 release. Is there a specific reason for this? It is explicitly mentioned before the cortex-m and cortex-m semihosting crates.
<re_irc>
<@adamgreig:matrix.org> ah, it's mentioned earlier because it was thought to be closer to being ready for 1.0
<re_irc>
<@adamgreig:matrix.org> but it doesn't block embedded-hal 1.0 coming out, which I think is now both closer to being ready and more useful to get to 1.0 first
<re_irc>
<@juliand:fehler-in-der-matrix.de> I see... embedded-hal getting to 1.0 first makes sense anyway
<re_irc>
<@adamgreig:matrix.org> looks like we're missing most of the HAL people today so probably not much further to discuss there, did anyone else want to talk about anything?
<re_irc>
<@jamesmunns:beeper.com> Ty to for merging PRs, I'm around for the next bit if anyone wants to get theirs in now and have it merged quickly :)
<re_irc>
<@thejpster:matrix.org> I have questions if anyone knows stuff about PSoC 62.
<re_irc>
<@dkhayes117:matrix.org> : I'll have one to share soon, it's not quite ready yet.
<re_irc>
<@adamgreig:matrix.org> if that's all then let's call it here for today, thanks everyone!
<re_irc>
<@jamesmunns:beeper.com> : No rush! it was just looking a little lonely on that list this morning :)
<re_irc>
<@steelph0enix:matrix.org> any news on "cortex-m" 0.8 version?
<re_irc>
<@2:0x2c.org> oh i didn't consider that the vendor library would have "static inline" functions...
<re_irc>
<@nchong-at-aws:matrix.org> : Hi all! Happy to help :-) Sorry I missed the meeting today.
joaj has quit [Quit: WeeChat 4.0.2]
dc740 has quit [Remote host closed the connection]
<re_irc>
<@jamesmunns:beeper.com> Hey , you asked for a postcard release and it totally slipped my mind, postcard v1.0.5 with CRC support (thanks to !) is now released