crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
fabic_ has quit [Ping timeout: 276 seconds]
fabic_ has joined #rust-embedded
<re_irc>
<@mehmet:grusbv.com> : It seems that Apple limits the amount of RAM that you can have wrt to the CPU
<re_irc>
<@mehmet:grusbv.com> What is the RAM that you feel comfortable with?
<re_irc>
<@mehmet:grusbv.com> My Windows is a RAM hog, but maybe not Macs
<re_irc>
<@thejpster:matrix.org> The company were paying so I put 32GB in this machine. On my personal machine, I've had an 8GB computer since 2016 and don't often feel the need for more.
<re_irc>
<@ryan-summers:matrix.org> Building my most recent rust project, I actually had to upgrade my 16GB to 32GB
<re_irc>
<@ryan-summers:matrix.org> But it's a full stack server, so much more intensive than embedded
<re_irc>
<@jamesmunns:beeper.com> The new macs also are much better/faster at "swapping", which makes less ram less painful, but can put some extra wear and tear on the SSD, especially if you have a smaller one so there is less to wear level.
lehmrob has joined #rust-embedded
<re_irc>
<@therealprof:matrix.org> I also have 32GB but more as a future proofing rather than actually requiring it.
<Lumpio->
Luckily if your SSD wears out you can just pop in a new one
<Lumpio->
Oh wait...
starblue has quit [Ping timeout: 276 seconds]
starblue has joined #rust-embedded
<re_irc>
<@thejpster:matrix.org> This laptop is liable to die for other reasons before that's an issue. Yes I'm still cross about my iBook G3 where the GPU would disconnect itself from the PCB.
<re_irc>
<@dngrs:matrix.org> : iirc someone did the numbers and it's not a concern for any lifespan that's not "computer museum"
ni has quit [Quit: WeeChat 3.0]
ni has joined #rust-embedded
rardiol has joined #rust-embedded
rardiol has quit [Client Quit]
<re_irc>
<@riskable:matrix.org> Just noticed something kinda funny this morning: You know you're on the right track when your browser starts auto-completing "docs" to "docs.rs" instead of "docs.google.com" 😄
<re_irc>
I guess there are options such as recompressing memory (not sure this any sense on MCUs) or run an application GC, but I suppose these can all be done in the allocator instead.
<re_irc>
<@chrysn:matrix.org> What other options than panic are there that you'd choose?
<re_irc>
<@adamgreig:matrix.org> I think the best thing would be the unstable "fallible allocation" APIs but that's sort of a different question :P
<re_irc>
<@chrysn:matrix.org> But isn't that just up to the application? I mean, what's gained if the application uses try_reserve and unwraps it, compared to the application just using reserve?
<re_irc>
<@chrysn:matrix.org> If all code just uses fallible allocation, and core is rebuilt and LTO is used, the code that leads to a panic should not even be emitted anyway. (Sure it'd be nice to enforce that, but that's probably a different issue)
<re_irc>
<@chrysn:matrix.org> Or, asked differently: What could an OOM handler (ie. not the default one) do to contribute to fallible allocations?
<re_irc>
<@adamgreig:matrix.org> say you are allocating in response to a request received over a uart, and the allocation fails, maybe you can now reply with an error code on the uart saying "sorry, try again later/go away"
<re_irc>
<@adamgreig:matrix.org> but if you panic, there's no context or meaningful local recovery
<re_irc>
<@adamgreig:matrix.org> if it just unwraps then yea there's no point :P
<re_irc>
<@chrysn:matrix.org> But the panic only happens because "Vec::reserve" or similar was called -- so the application has to use "Vec::try_reserve". Can't it do that just as well without a non-default OOM handler?
<re_irc>
> This makes the company the first major semiconductor manufacturer to officially support Rust for its microcontrollers.
<re_irc>
> The PACs are generated with the svd2rust tool and follow the same API standard for peripheral access.
<re_irc>
<@thejpster:matrix.org> holy smokes
<re_irc>
<@thejpster:matrix.org> (also, Infineon doesn't think Espressif is "major")
<re_irc>
<@adamgreig:matrix.org> I don't think all the fallible alloc APIs are stable though? or maybe they are by now 🙈
<re_irc>
<@adamgreig:matrix.org> but I just meant having oom panic and then using try_* where you need something else seems much more useful than a custom oom which doesn't have the context to do much, usually
<re_irc>
<@adamgreig:matrix.org> (the TRAVEO ones are cortex-m and normal rustc, the AURIX are "tricore"??? and need this special proprietary rust compiler)
<re_irc>
<@thejpster:matrix.org> I suspect it's a bespoke LLVM backend and a rustc fork, like you need for Xtensa
<re_irc>
> To evaluate our new Rust Development Platform fill in the registration form at Request of Evaluation Key and select:
<re_irc>
<@chrysn:matrix.org> Well ... gcc said that'd happen with LLVM.
<re_irc>
<@sourcebox:matrix.org> The most scary part is the "Eclipse-based" one.
<re_irc>
<@thejpster:matrix.org> : I've had plenty of licence locked copies of GCC
<re_irc>
<@thejpster:matrix.org> I mean, I can at least ask for the compiler source so I can patch out the licence check, but still.
<re_irc>
<@thejpster:matrix.org> (plenty = at least two - CodeSourcery, and Lynx)
<re_irc>
<@sourcebox:matrix.org> Are these TriCore chips of broader public interest?
<re_irc>
<@jamesmunns:beeper.com> : In _vaguely_ no-std use cases, you might be able to ask your OS to map you in more pages. Not if you are totally bare metal, or the OS already gave you everything available
<re_irc>
<@jamesmunns:beeper.com> : Generally these are only used in automotive or maybe adjacent safety critical industries. They aren't typically used in anything "consumer".
<re_irc>
<@jamesmunns:beeper.com> they are super widely used in automotive tho.
<re_irc>
<@jamesmunns:beeper.com> they are much closer to Cortex-R chips than Cortex-M or Cortex-A, for reference.
<re_irc>
<@sourcebox:matrix.org> So effectively a niche product where the manufacturer also has no interest to make them used in more domains.
<re_irc>
<@jamesmunns:beeper.com> Yeah, ish. They are really designed and sold to safety critical industries that need lots of paperwork for documented electrical failure cases and stuff, and need things like lock step operation for mitigating failures of a single core.
<re_irc>
<@jamesmunns:beeper.com> optimizing for a very different problem and market than consumer parts, for sure.
<re_irc>
<@jamesmunns:beeper.com> they would not be cost or feature competitive with like... anything.
<re_irc>
<@sourcebox:matrix.org> So there wouldn't be much community support anyway.
<re_irc>
<@jamesmunns:beeper.com> but like, if you need a measured quantity from a reputable vendor with very specific guarantees, they are a solid option, and worth the extra cost.
<re_irc>
<@jamesmunns:beeper.com> the fact they use svd2rust tho is somehow hilarious and mind blowing to me.
<re_irc>
<@thejpster:matrix.org> : we had no idea back in 2018
<re_irc>
<@sourcebox:matrix.org> So overall having a fully open backend would be nice but not be used widely.
<re_irc>
<@thejpster:matrix.org> "let's build common abstractions to avoid those awful walled gardens that the vendors love to build in C." And the silicon vendors came anyway.
<re_irc>
<@thejpster:matrix.org> I'm fairly sure that where one leads, the others will have to follow. Otherwise it makes the sales team look bad. "Oh, you don't have Rust support yet? Infineon do..."
<re_irc>
<@sourcebox:matrix.org> I wonder why Microchip isn't in the boat with things like dsPIC.
<re_irc>
<@thejpster:matrix.org> Yeah, I have no desire to push Infineon to open the LLVM backend. I'm just glad they didn't fork the frontend, and didn't build a bunch of custom stuff.
<re_irc>
<@thejpster:matrix.org> Well, they _did_ fork the frontend. But let's hope they don't diverge too far.
<re_irc>
<@adamgreig:matrix.org> yea, at least the tricore stuff will be mostly used by commercial entities, who can ask hightec to add support for the new rust features
<re_irc>
<@adamgreig:matrix.org> so that when svd2rust uses some new rust feature that's not in the hightec compiler, they hopefully know who to direct their complaints at
<re_irc>
<@thejpster:matrix.org> Or pay us to maintain LTS branches of the tools
<re_irc>
<@adamgreig:matrix.org> pay who?
<re_irc>
<@thejpster:matrix.org> _points_ literally any one of us running Rust based consultancies
<re_irc>
<@jamesmunns:beeper.com> Someone willing to do the work. Ferrous. Tweede Golf, me, Hanno, etc
<re_irc>
<@dirbaio:matrix.org> the Rust Embedded Consulting WG :P
<re_irc>
<@chrysn:matrix.org> : Isn't that something the allocator will do, call sbrk or whatever?
<re_irc>
<@jamesmunns:beeper.com> : This is honestly a thought I've had before. WG might not be the right term, but there's room for collaboration tbqh.
<re_irc>
<@jamesmunns:beeper.com> : Could! I dunno where these things "traditionally" were handled.
<re_irc>
<@jamesmunns:beeper.com> (or: ask folks like hitec to provide someone to consistently lend a hand with maintenance of relevant tools, etc.)
<re_irc>
<@adamgreig:matrix.org> ideally they could keep their compiler up-to-date :P
<re_irc>
<@adamgreig:matrix.org> (I know, I know, certification, etc)
<re_irc>
<@jamesmunns:beeper.com> Always some customer willing to pay 10x to keep the old version up to date rather than updating lol
<re_irc>
<@jamesmunns:beeper.com> But yeah. So it goes :)
<re_irc>
<@jamesmunns:beeper.com> Honestly more happy than anything that traction is happening. Always papercuts, but "it'll never happen" is less true year over year.
<re_irc>
<@sourcebox:matrix.org> It definitely has gained momentum in the last months and that's a good thing.
<re_irc>
<@sourcebox:matrix.org> Btw. is there any manufacturer other than Espressif having paid devs working on the HALs?
<re_irc>
<@jamesmunns:beeper.com> : Bouffalo labs
<re_irc>
<@jamesmunns:beeper.com> Dunno if I've seen anyone else publicly lately
<cr1901>
Bouffalo labs? I'll be watching that w/ interest
<re_irc>
<@sourcebox:matrix.org> I've seen BL has PACs, but not HALs.
<re_irc>
<@jamesmunns:beeper.com> Yup. Haven't seen a public hal, I assume with no actually knowledge it's happening behind the scenes, but the PAC still has activity.
<cr1901>
I'm still waiting on info on how to access the LP core
<re_irc>
<@sourcebox:matrix.org> Is the PAC done manually? I always thought they are just created by svd2rust or so.
<re_irc>
<@jamesmunns:beeper.com> I assume the work is "write the SVD file".
<cr1901>
.oO (svdtools should've been called "fixsvds", as a nod to gcc's "fixincludes")
<re_irc>
<@jamesmunns:beeper.com> SVD is an arm concept, so I assume they are wrangling internal docs to write/produce the SVD in some way, then feeding that through svd2rust.
<cr1901>
SVD is CPU neutral- even ARM admits as much
<re_irc>
<@jamesmunns:beeper.com> cr1901: AFAIK that wasn't true originally, but might be today?
<re_irc>
<@jamesmunns:beeper.com> It's a weird format that was mostly used for debuggers originally, iirc
<cr1901>
Oh well, if so, my mistake. SVD nowadays supports different bus sizes and has a <cpu> field.
<cr1901>
The MSP430 SVDs violate the spec slightly (been meaning to fix this), but not in a way that matters to svd2rust
<re_irc>
<@jessebraham:matrix.org> It's pretty much agnostic, I guess you could argue that stuff like "nvicBits" in the "cpu" block are ARM-specific, but overall I've had no issues creating SVDs for RISC-V/Xtensa devices
<cr1901>
(hence why I haven't bothered)
<cr1901>
Yea, and not all CPUs have interrupt controllers that work like ARM (basically ARM and RISCV if the spec is followed?)
<re_irc>
<@sourcebox:matrix.org> : Did you use any tools to create them or is it just a lot of manual work?
<re_irc>
<@jessebraham:matrix.org> We basically have some internal format for register descriptions, and then I've written a simple tool which parses those and generates an SVD. There's a fair bit of work glueing things all together, but mostly automated at this point.
<re_irc>
<@sourcebox:matrix.org> I was also wondering how ARM did originally did it because there's surely some common work with having the docs etc.
<re_irc>
<@jamesmunns:beeper.com> : Interns and spreadsheets, I assume.
<re_irc>
<@sourcebox:matrix.org> Error-prone.
<re_irc>
<@jamesmunns:beeper.com> Datasheets, vendor headers, and SVD files rarely agree 100% in practice. I assume the process is not as automated or ideal as we'd like to imagine it is, or as nice as espressif's is
<re_irc>
<@jamesmunns:beeper.com> : There are in fact often lots of errors.
<cr1901>
Also of SVDs just plain suck
<cr1901>
A lot*
<re_irc>
<@jessebraham:matrix.org> There are still a number of disparities between our SVDs and TRMs, I'm working on improving this but yeah it's tough
<re_irc>
<@jessebraham:matrix.org> Especially with different teams on different continents
<re_irc>
<@jamesmunns:beeper.com> Single source of truth from HDL when? :p
<re_irc>
<@jessebraham:matrix.org> What a dream that would be haha
<re_irc>
<@jessebraham:matrix.org> I did just rope in one our interns to help me this week, so hopefully we can continue to make progress on this front!
<re_irc>
<@sourcebox:matrix.org> I'm already surprised how many people at Espressif work for the Rust support.
<re_irc>
<@jessebraham:matrix.org> Yeah we have quite a large team! It's really nice, we've been able to make really good progress over the last ~1.5 years because of it
<re_irc>
<@sourcebox:matrix.org> But do you have a team that's exclusively doing Rust or is it also shared with regular IDF development?
<re_irc>
<@jessebraham:matrix.org> Nope we're exclusively the Rust team 😄
<re_irc>
<@sourcebox:matrix.org> That's great.
<re_irc>
<@jessebraham:matrix.org> I agree! 😄
<re_irc>
<@sourcebox:matrix.org> But surely there are some challenges to master to keep esp-idf-hal in sync. I'm specifically thinking about such things as the component manager with it's own versioning.
<re_irc>
<@jessebraham:matrix.org> Yeah definitely. I'm not really involved with that project though haha, mostly bare-metal and tooling for me
<re_irc>
<@sourcebox:matrix.org> For the other manufacturers it will be interesting to see how that goes on. E.g. ST is putting out more and more series, I guess it will be hard for the few volunteers in the community to support them all in a comprehensive way.
<re_irc>
<@sourcebox:matrix.org> Maybe they surprise us with a new release of CubeMX that spits out Rust code.
<re_irc>
<@dirbaio:matrix.org> embassy reads the cubemx xml files and generates Rust from them, so it's been quite easy to add support for the new series (U5, C0)
<re_irc>
<@sourcebox:matrix.org> Interesting.
<re_irc>
<@sourcebox:matrix.org> Is this what's used for the stm32-data repo?
<re_irc>
<@dirbaio:matrix.org> yeah
<re_irc>
<@dirbaio:matrix.org> the register yamls are extracted from the SVDs and then manually cleaned up
<re_irc>
<@dirbaio:matrix.org> and then the embassy-stm32 HALgenerates Rust code from that
<re_irc>
<@2:0x2c.org> i'm trying to link a C crate that contains all of the vendor code, startup, vectors, etc, but i'm struggling with the linker file - somehow the linker file doesn't see the symbols defined in the static library. maybe i need some special KEEP()?
<re_irc>
<@2:0x2c.org> of course the vendor code originally linked object files, not an archive containing those object files
<re_irc>
<@2:0x2c.org> it seems to work if i manually use --whole-archive
lehmrob has quit [Quit: Konversation terminated!]
<re_irc>
<@2:0x2c.org> oh i guess i don't understand how C crates are integrated into the build
<re_irc>
<@2:0x2c.org> does everything always get linked into a .rlib?
<re_irc>
<@thejpster:matrix.org> You can specify the crate type
<re_irc>
<@thejpster:matrix.org> Or if your question is does an rlib contain everything I assume the answer is yes.
<re_irc>
<@thejpster:matrix.org> The final link will do garbage collection. An rlib is an archive of object files and processed source code for compiling generic stuff once you know what T is.
<re_irc>
<@2:0x2c.org> so i have a bunch of object files and several archive files that come from the vendor source build, and it's not clear to me how i can stuff those into a rlib
<re_irc>
<@thejpster:matrix.org> You don’t? You tell cargo to include the C libraries in your Rust binary
<re_irc>
<@thejpster:matrix.org> Or you tell cargo to make a C compatible static lib and use make or Cmake to link that into a C binary