<davidmpye[m]>
It ain't really a micro processor is it?
<sourcebox[m]>
The 0.4mm pitch is a bit challenging.
i509vcb[m] has joined #rust-embedded
<i509vcb[m]>
There are 0.8mm pitch options for us plebians at least
<JamesMunns[m]>
davidmpye[m]: These days it's "everything but the MMU" :p
<sourcebox[m]>
During chip shortage 2 years ago, we could get some STM32 variants with 0.4mm pitch, but the board manufacturer was not able to handle it in the standard process.
mchodzikiewicz[m has joined #rust-embedded
<mchodzikiewicz[m>
what is it for really? realtime CV?
<mchodzikiewicz[m>
like glass bottle washing lines etc? 😅
<sourcebox[m]>
The SIMD extension and the RAM is something that's welcome to people like us doing audio dsp.
<sourcebox[m]>
But we don't need any of these AI accelerator units.
<i509vcb[m]>
A bottle washing line CV system with UCPD?
<i509vcb[m]>
Man everything uses type C these days lol
<Darius>
MCUs have had vector instructions for a long time
<Darius>
a lot also have MPUs - not really an MMU because it doesn't do mapping but can enforce access
<Darius>
I wonder how many thousand pages reference manual is 😭
<Darius>
4692 pages! lmao
<mchodzikiewicz[m>
No, but really, this edge ai optimisations screams video object recognition in very fast paced scenario
<Darius>
wow has a h264 and JPEG encoder..
<Darius>
TIL about MDIOS
<Darius>
monster chip, I think mounting it on a board is only where your trouble starts :D
<sourcebox[m]>
Even the H7 is not easy to handle anymore.
<sourcebox[m]>
Speaking in terms of pcb design.
JamesLogan[m] has joined #rust-embedded
<JamesLogan[m]>
they could fix a lot of that for the h7 with a slightly less unhinged pinout. simply do not put the RMII pins on opposite sides of the chip 🤷♂️
<i509vcb[m]>
What do you mean that I shouldn't have the crystal and built-in switching regulator flanking the RF antennas?
<JamesLogan[m]>
... and the crystal right in the middle of the ADC pins
<Darius>
that is a bit mind boggling
<adamgreig[m]>
the h7 pinouts are a bit less annoying in bga instead of lqfp at least but it's still really all over the shop
<adamgreig[m]>
woe awaits if you want to use 32 bit wide external memory bus lol
netcreature has quit [Ping timeout: 248 seconds]
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 276 seconds]
rainingmessages5 has joined #rust-embedded
rainingmessages has quit [Ping timeout: 276 seconds]
<Kaspar[m]>
full 1., Ariel is what we'd call a "library os".
<Kaspar[m]>
Basically the idea is to collect and curate what you'd end up with when using embassy-* and all the other nice building blocks in the ecosystem to build some application, and make that accessible and re-usable with minimal boilerplate
<thejpster[m]>
does it have a story for writing custom interrupt handlers?
<thejpster[m]>
or is that just a task awaiting some change / event?
<Kaspar[m]>
thejpster[m]: I guess the story is the same as it would be on bare-metal, or with embassy
<Kaspar[m]>
Ariel really has Embassy at its heart, it is just also handling a lot of boilerplate, and tries to provide higher level building blocks.
<Kaspar[m]>
For example, there's embedded-storage, and sequential-storage, and the flash implementations, and some examples, and serialization, ... So with some hours of work, everyone can combine those for the next application to store some values on flash. Ariel does that, and provides a simple storage::get(K, V), on all MCUs that (it supports and) provide the necessary implementations.
<JamesMunns[m]>
Something to be said about covering "an embedded environment as a distribution, with off the shelf, integrated options", vs "make all the decisions and integrate in every project"
<Kaspar[m]>
Yeah. The difficulty is to keep the escape hatches open, so embedded Rust doesn't turn into Gnome. :)
<Kaspar[m]>
* For example, there's embedded-storage, and sequential-storage, and the flash implementations, and some examples, and serialization, ... So with some hours of work, everyone can combine those for the next application to store some values on flash. Ariel does that, and provides a simple storage::put(K, V) / storage::get(K), on all MCUs that (it supports and) provide the necessary implementations.
<Koen[m]>
One of noticeable differences is that embassy has the examples per target board, where the examples with Ariel work without modification for any target with the required hardware
<diondokter[m]>
<Kaspar[m]> "For example, there's embedded-..." <- Oh cool, from this I thought you had implemented your own thing. But it's actually using sequential-storage. Sweet!
<diondokter[m]>
If there's anything you're running into you're always free to ask me here or in an issue
<RyanSlawson[m]>
Is there a general consensus on how crates should allow users to define handlers for things like interrupt/exception handlers? riscv-rt is seeming to do something different from what I've seen a lot of other crates do. The most common pattern I've seen is having something marked with #[export_name = "DefaultExportHandler"] or similar and then doing PROVIDE(ExportHandler = DefaultExportHandler) in the linker script. But
<RyanSlawson[m]>
riscv-rt instead defines its own ExportHandler but as a .weak symbol. The first method allows for LTO and such, but tends to leave unused symbols in the final binary. The second one doesn't leave unused symbols, but I'm having a pretty tough time getting LTO to work. Is there a consensus on whether one pattern is better than the other?
cr1901__ has joined #rust-embedded
<thejpster[m]>
I don't know we have consensus here. There's cortex-m-rt and riscv-rt and I believe they are still different. It came up in Delft earlier in the year, but I don't know what changes have happened since.
<ragarnoy[m]>
Hey, odd question but is there a way to use the include_str macro in no std context? As in, to include the content of a file on the host? Since the end result is a static str shouldn't this be possible?
<i509vcb[m]>
Although my Linux experience does have me a little concerned that Qualcomm being involved means terrible if not no documentation for how to talk to the module
<JamesMunns[m]>
i509vcb[m]: "here's the linux kernel driver. do you like this? is this good documentation?"
<i509vcb[m]>
Well your product might be unable to use GPL code
<i509vcb[m]>
For an MP1/2 product sure it's probably no issue since you need to deal with Linux already
<i509vcb[m]>
And userspace isolates you from that
<diondokter[m]>
<i509vcb[m]> "Although my Linux experience..." <- Can't be much worse than the nrf7002 😅
<JamesMunns[m]>
<diondokter[m]> "Can't be much worse than the nrf..." <- "you were supposed to be the chosen one!" dot gif
<i509vcb[m]>
I'm working on it. Very slowly
bogdan[m] has quit [Quit: Idle timeout reached: 172800s]
cinemaSundays has joined #rust-embedded
M762spr[m] has joined #rust-embedded
<M762spr[m]>
What's the best way to do math operations on a f64 in no_std? I'm using num-traits crate right now, but curious if that's the best approach. Using a stm32 H7 with double precision FPU
rault[m] has quit [Quit: Idle timeout reached: 172800s]
<Kaspar[m]>
Is there a deeper story behind this question?
<M762spr[m]>
nope, just curious. Haven't had the need to use f64 in a project before this one and want to do it "right"