<re_irc>
< (@fragadaleta:matrix.org)> yeah i think i need at least a cortex-m1
<re_irc>
<skye> something STM32-based?
<re_irc>
< (@fragadaleta:matrix.org)> even better what is on a Rpi 0 as i already cross-compiled and i know my stuff can run thre
<re_irc>
< (@fragadaleta:matrix.org)> *there
<re_irc>
< (@fragadaleta:matrix.org)> A53 i think
<re_irc>
< (@jamesmunns:beeper.com)> skye: ESP32 (and S2 and S3) use the Xtensa architecture, ESP-Cx boards use RISC-V
<re_irc>
< (@jamesmunns:beeper.com)> : So, an ESP32 will be >= powerful than most (not all) Cortex-M0, M3, and M4 devices, and maybe a bit less than the high end M7 (or M23/33) devices.
<re_irc>
< (@jamesmunns:beeper.com)> But you can run Rust on bare metal microprocessors, like the 32-bit one on the RPi 0/1, as well as the 64-bit one on the newer RPis
<re_irc>
< (@fragadaleta:matrix.org)> oh yeah? what framework can i use? I'd love to go with embassy
<re_irc>
< (@jamesmunns:beeper.com)> Though, most micro_processors_ (like on the RPi) won't be as well supported as micro_controllers_ (like the Cortex-M and ESP32)
<re_irc>
< (@fragadaleta:matrix.org)> : you are right, the biggest problem on these boards is RAM is too small
<re_irc>
< (@jamesmunns:beeper.com)> AFAIK, there's not any super well supported microprocessors. There is some support for the RPi, as well as newer RISC-V parts, but the support is pretty basic, and none of them support Embassy out of the box
<re_irc>
< (@jamesmunns:beeper.com)> You could definitely make it work! But it would be a challenge.
<re_irc>
< (@fragadaleta:matrix.org)> so what would be the way to go, if
<re_irc>
1. i need a relatively powerful processor/controller
<re_irc>
2. i need some RAM 🙂
<re_irc>
<skye> how much RAM do you mean by "some RAM"
<re_irc>
< (@jamesmunns:beeper.com)> I'm personally working on the Allwinner D1 processor, like the Sipeed Lichee RV, or the Mango Pi MQR, which is a single core, 1GHz processor, with 512MB-1GiB of RAM
<re_irc>
< (@fragadaleta:matrix.org)> from benchmarks in "std" i see peaks at 50MB RAM
<re_irc>
< (@jamesmunns:beeper.com)> You _might_ be able to fit that in something like an STM32H7 (very high end Cortex-M7), if it has external RAM
<re_irc>
< (@jamesmunns:beeper.com)> but outside of that, you're typically talking about microprocessors, yeah.
<re_irc>
< (@jamesmunns:beeper.com)> I don't know any processors that have more than proof-of-concept/demo support though.
<re_irc>
< (@k900:0upti.me)> I feel like the important question that hasn't been asked is "why not Linux"
<re_irc>
< (@fragadaleta:matrix.org)> because i need real-time and battery optimization is quite critical
<re_irc>
< (@jamesmunns:beeper.com)> How "real time"? and how much battery?
<re_irc>
< (@jamesmunns:beeper.com)> you can usually get in the 10s-100s of mA on microprocessors, and depending on your definition of real time, linux can pretty reliably hit sub-1ms timing deadlines.
<re_irc>
< (@fragadaleta:matrix.org)> swapping from the OS would be a tragedy and running an entire OS would drain battery
<re_irc>
< (@fragadaleta:matrix.org)> 1-5 ms and battery is very small due to limited payload
<re_irc>
< (@k900:0upti.me)> 1-5ms what to what
<re_irc>
< (@jamesmunns:beeper.com)> Yeah, if you have certain battery mAh numbers (e.g. what will fit in your payload), and expected runtime (in hours/days), that'd be interesting to know!
<re_irc>
< (@k900:0upti.me)> How many watt-hours is "very small"
<re_irc>
< (@fragadaleta:matrix.org)> i receive a message from a sensor. I process. I make that result available to another sub-module
<re_irc>
< (@k900:0upti.me)> I should probably elaborate
<re_irc>
< (@k900:0upti.me)> The reason we're asking all of this is that the exact thing you're asking for doesn't exist
<re_irc>
< (@fragadaleta:matrix.org)> this has to be done for "infinite time" wrt the application that uses the MCU. That is at least 10h
<re_irc>
< (@k900:0upti.me)> So something _will_ have to give
<re_irc>
< (@k900:0upti.me)> Unless you're very good friends with a silicon vendor and can afford to wait a couple years, I guess
<re_irc>
< (@fragadaleta:matrix.org)> 🙂
<re_irc>
< (@jamesmunns:beeper.com)> I guess stepping back a bit:
<re_irc>
< (@fragadaleta:matrix.org)> i dont ☹️
<re_irc>
< (@jamesmunns:beeper.com)> Systems with that much RAM (MCU and MPU!) tend to be pretty (relatively) power hungry, you are likely to be hard pressed to do better than 10-100mA, unless you spend a lot of time working with power states, etc. DRAM is sorta mean like that
<re_irc>
< (@jamesmunns:beeper.com)> What _might_ help is figuring out if you really need 50MiB of RAM. "read a sensor and send to something else" is usually more in the 10-100KB range, even with a few drivers, an async runtime, and a network driver (eth/wifi)
<re_irc>
< (@fragadaleta:matrix.org)> it does much more than that. It implements message queues, QoS, and other processing on sensor data
<re_irc>
< (@fragadaleta:matrix.org)> and yes there is a network driver eth too
<re_irc>
< (@jamesmunns:beeper.com)> Totally fair! Though again, there are projects like Stabilizer: https://github.com/quartiq/stabilizer, which run on an STM32, which do similar things.
<re_irc>
< (@jamesmunns:beeper.com)> but if you have a bunch of software written already for all of your things and don't want to rewrite that, then it can be a challenge! But it might be worth trying something like the Allwinner D1 with linux first - with a 500-1000mAh battery you could likely get 10 hours, though maybe not with much wifi.
<re_irc>
< (@jamesmunns:beeper.com)> If linux isn't cutting it (speed, battery life), you might be able to give bare metal a try, though you'll have a bit of work to do to get it going.
<re_irc>
< (@fragadaleta:matrix.org)> interesting. So i guess i just have to try and recompile with "no-std" and maybe remove some fluffiness from my code 😕
<re_irc>
< (@fragadaleta:matrix.org)> i dont have wifi. i have eth
<re_irc>
< (@jamesmunns:beeper.com)> Dumb question: Is passive/active PoE an option for you?
<re_irc>
< (@boondocker:matrix.org)> If you’re on Ethernet can you power it with PoE or mains?
<re_irc>
< (@jamesmunns:beeper.com)> if you're running a cable already, you might be able to have a bigger battery somewhere else.
<re_irc>
< (@fragadaleta:matrix.org)> if i want to go the STM32 way, i can start from a dev board. What if it works and i need to "miniaturize" and print a board for production?
<re_irc>
< (@jamesmunns:beeper.com)> : If you can find one off the shelf, then you are good to go! You can look in formats like the adafruit feather, which gets pretty small
<re_irc>
< (@jamesmunns:beeper.com)> otherwise yeah, you'll need to design some custom hardware.
<re_irc>
< (@jamesmunns:beeper.com)> (this will again be MUCH easier for an MCU, than it will be for an MPU)
<re_irc>
< (@fragadaleta:matrix.org)> ah ok indeed i can check adafruit... nice!
<re_irc>
and i could stay on embassy-rs that would save me a lot of time
<re_irc>
< (@jamesmunns:beeper.com)> For example, the https://www.electro-smith.com/daisy/daisy is pretty high end, and I think it actually even has 64MiB of SDRAM for you already
<re_irc>
< (@fragadaleta:matrix.org)> oh wow
<re_irc>
< (@jamesmunns:beeper.com)> I don't remember exactly which STM32 that uses, but I think I've seen some people working on it in Rust, and Embassy should support most STM32 boards pretty well.
<re_irc>
< (@fragadaleta:matrix.org)> ok other constraint 😛
<re_irc>
I need to program it in Rust (the entire codebase is Rust) preferably embassy
<re_irc>
<skye> : it says H7 when I zoom in on the product image
<re_irc>
< (@jamesmunns:beeper.com)> skye: Yeah, there are a lot of variants of the H7 though. I meant the full 7xx CPU number :)
<re_irc>
< (@jamesmunns:beeper.com)> But yeah, the only "higher end" MCU boards that I know of than the STM32H7 boards are the i.mxrt boards from NXP
<re_irc>
< (@jamesmunns:beeper.com)> The newest Teensys use the mid-range of that processor, but there are even more complex high end ones
<re_irc>
< (@jamesmunns:beeper.com)> The teensy boards are a little harder to work with in Rust though, since they don't break out the debugger pins, and tbh the imxrt is a REALLY complicated chip)
<re_irc>
< (@fragadaleta:matrix.org)> this was really great guys, thank you so much. I have a better idea now and some more research to do. But you put me on the right path.
<re_irc>
< (@jamesmunns:beeper.com)> But that daisy is probably a great place to start.
<re_irc>
<henrik_alser> : IME you can accomplish quite a lot using both cores of an rp2040 (don’t know how heavy your data processing is or what else drives you towards the higher end of micros…)
<re_irc>
There’s the W5500-EVB-PICO with ethernet if it could be an option?
<re_irc>
<henrik_alser> (and quite well supported by embassy these days :))
<re_irc>
<henrik_alser> (You can also overclock it by quite a bit if needed)
<re_irc>
<henrik_alser> But maybe your use case is totally in another dimension, then nevermind :)
<re_irc>
< (@ryan-summers:matrix.org)> Also to add more info on stabilizer, we have really high data throughput (tens of Mbps processed + streamed over ethernet) on the H7. It's a pretty beefy processor with lots of memory. I would seriously analyze why you think you need 50MB of RAM
<re_irc>
< (@ryan-summers:matrix.org)> Unless you need something like UI frame buffers and image storage, that's a _lot_ of memory for an embedded system
<re_irc>
< (@ryan-summers:matrix.org)> Esp. for a battery powered device
<re_irc>
< (@ryan-summers:matrix.org)> Generally when I've had projects like that, it was because image storage and/or video was required. In that case, we streamed the video data to an external eMMC with a few GB embedded flash
<re_irc>
< (@fragadaleta:matrix.org)> yeah i am currently based on DDS which i will replace with my no-std minimal implementation
<re_irc>
< (@fragadaleta:matrix.org)> essentially i have reimplemented a pub/sub with QoS, without the fluffiness
<re_irc>
< (@fragadaleta:matrix.org)> and without the network stack
<re_irc>
< (@fragadaleta:matrix.org)> so i believe when that is done, even 40KB RAM would be ok
<re_irc>
< (@ryan-summers:matrix.org)> Stabilizer has MQTT + a full network stack, and it only uses like 400KB of flash total
<re_irc>
< (@fragadaleta:matrix.org)> wow
<re_irc>
< (@fragadaleta:matrix.org)> how much RAM ?
<re_irc>
< (@ryan-summers:matrix.org)> You can also take a look at Booster, which is almost identical, but with an F4
<re_irc>
< (@ryan-summers:matrix.org)> I don't recall, I haven't profiled RAM usage. Most of it is just stack from what I recall
<re_irc>
< (@fragadaleta:matrix.org)> : what i need is something that is supported by embassy
<re_irc>
< (@ryan-summers:matrix.org)> I'd be very surprised if the H7 isn't supported in embassy? It's really commonly used
<re_irc>
< (@ryan-summers:matrix.org)> Yeah I think it supports nordic + stm32 parts
<re_irc>
<henrik_alser> H7 is supported yes!
<re_irc>
I guess i need something like stabilizer. Only thing is to make it a small format factor
<re_irc>
< (@fragadaleta:matrix.org)> sure thing
<re_irc>
< (@ryan-summers:matrix.org)> Not sure what the memory footprint looks like with embassy, but I'd be super surprised if it was significantly different from RTIC-based apps
<re_irc>
< (@fragadaleta:matrix.org)> but i guess even there i have options
<re_irc>
< (@ryan-summers:matrix.org)> Honestly, H7 may even be overkill. If you're looking for low power and you don't have too high data throughput, you might be able to use an nRF52. Those things can get down into the nA in sleep mode
<re_irc>
< (@fragadaleta:matrix.org)> yeah i have thought of nrf52
<re_irc>
< (@ryan-summers:matrix.org)> There's lots of designs you could go for, i.e. some embedded, low power device that wirelessly forwards data to some central, power hungry setup
<re_irc>
< (@fragadaleta:matrix.org)> what i am building is taking and sending data to eth
<re_irc>
< (@ryan-summers:matrix.org)> Ethernet isn't too big IMO. Especially with smoltcp
<re_irc>
< (@ryan-summers:matrix.org)> And you can use external PHYs, like the W5500
<re_irc>
< (@ryan-summers:matrix.org)> So even if you don't have an ETH peripheral, you can add one to your board
<re_irc>
< (@fragadaleta:matrix.org)> henrik_alser: eh this looks cool 😛
<re_irc>
< (@ryan-summers:matrix.org)> Take a look at https://github.com/quartiq/booster, it's an RF power amplifier with an STM32F4 and an external W5500 that communicates via SPI, also has full MQTT pub/sup support
<re_irc>
< (@ryan-summers:matrix.org)> Also, beware dual core approaches, they can become much more complicated from an embedded design perspective. I did a bare metal raspberry pi 2 setup for sonar localization, and it took a lot of care to get right
<re_irc>
< (@ryan-summers:matrix.org)> Inter-core communication and resource sharing can be finicky
<re_irc>
< (@ryan-summers:matrix.org)> Generally they can be used in safety critical systems where the UI and safety functions need to be separate (for redundancy), but there's a hard partitioning of which core gets what peripherals in those cases
<re_irc>
< (@fragadaleta:matrix.org)> very valuable points
<re_irc>
<henrik_alser> In embassy you’d use the embassy-sync primitives with ”CriticalSectionRawMutex” (that is a multithread impl based on hardware spinlocks) to share resources between cores
<re_irc>
<henrik_alser> Just beware of flash operations that need to be called on core0 (core1 execution is paused during flash operations)
<re_irc>
< (@jamesmunns:beeper.com)> : Usually (not sure about this one specifically), but usually one or both of:
<re_irc>
- Handling the loading process (e.g. reboot to bootloader, which overwrites the application)
<re_irc>
- Handling primary/secondary fallback/"rollback", for example if a CRC/validity check fails, or if the device crashes on first boot
<re_irc>
< (@jamesmunns:beeper.com)> Sometimes (not always) it's the first stage of the boot process, similar to uboot, but usually is much more focused on "loading new image(s)", rather than setting up the environment, like on more desktop-style bootloaders
<re_irc>
< (@luojia65:matrix.org)> If my firmware works without bootloader, should I modify it to have it started with a bootloader?
<re_irc>
< (@luojia65:matrix.org)> : Thanks! :)
<re_irc>
< (@jamesmunns:beeper.com)> Depends on the bootloader! Not sure about this one.
<re_irc>
For many bootloaders, the app "doesn't know" the bootloader even exists. For some bootloaders, they will want the app to "acknowledge" or "confirm" the boot. Sometimes they also provide an API for metadata.
<re_irc>
< (@luojia65:matrix.org)> I understand now, thanks :)
<re_irc>
< (@jamesmunns:beeper.com)> For the first group, the only modification you need to make is usually just moving the application base address, instead of the default location. For example, moving to 0x0000_4000 instead of 0x0000_0000, since the bootloader "lives" at 0x0000_0000 now.
<re_irc>
< (@jamesmunns:beeper.com)> The need for bootloaders in embedded is usually that you don't have much room for multiple firmware images, and you can't really erase the image you are actively running from. So your options are usually either:
<re_irc>
- Boot to another application, like a bootloader, that won't be erased
<re_irc>
- Move the "code" into RAM which won't be erased (this is bad if you erase all your firmware, and lose power!)
<re_irc>
<pinkforest-rust> There is a RFC that has gone in FCP in rust-lang: https://github.com/rust-lang/rfcs/pull/2832 - About adding Internet Protocol type stuff into core.
<re_irc>
It is proposing to turn core into more std library type and IMO it is making whole lot of assumptions what will happen now and in future.
<re_irc>
If you have strong opinions either way, it's in its final comment period. Does anyone enen have clear definition what core means ?
<re_irc>
< (@adamgreig:matrix.org)> I don't think you need to worry, it doesn't depend on LTO to avoid adding stuff to your build
<re_irc>
< (@adamgreig:matrix.org)> core already has a whole ton of things you probably aren't using and won't be paying for
<re_irc>
< (@k900:0upti.me)> pinkforest-rust: "Core" is basically just "everything that isn't OS specific"
<re_irc>
< (@k900:0upti.me)> I don't think IpAddr types are OS specific?
<re_irc>
<pinkforest-rust> I just would like to see these things clarified in RFC and intende dgoals so they can be turned into tests.
<re_irc>
< (@adamgreig:matrix.org)> "and doesn't require an alloc" :P
<re_irc>
<pinkforest-rust> IpAddr very much is target specific
<re_irc>
< (@adamgreig:matrix.org)> how so?
<re_irc>
< (@k900:0upti.me)> : Alloc is OS specific
<re_irc>
< (@mabez:matrix.org)> pinkforest-rust: Imo core just assumes nothing about its execution environment, _not_ what you might do in said environment. I've been using no_std almost exclusively with networking devices so for me this move doesn't feel awkward at all
<re_irc>
< (@adamgreig:matrix.org)> this RFC about moving IpAddr into core doesn't seem to me to be the right place to talk about "what should be in core" or "should we have tests to track the binary size of no_std applications", though
<re_irc>
<pinkforest-rust> alloc is it's separate crate
<re_irc>
<pinkforest-rust> from core
<re_irc>
< (@dirbaio:matrix.org)> adding stuff to core doesn't make binaries bigger if they don't use the new stuff
<re_irc>
< (@adamgreig:matrix.org)> how is IpAddr different between wasm32 and thumbv7em?
<re_irc>
< (@dirbaio:matrix.org)> there's literally zero downside from the "bloat" perspective
<re_irc>
< (@k900:0upti.me)> I don't think binary size is the concern here
<re_irc>
<pinkforest-rust> My concern is assumptions
<re_irc>
< (@k900:0upti.me)> What assumptions is "IpAddr" making that you don't agree with?
<re_irc>
<pinkforest-rust> it's easy to be naive about assumptions for now and in future. People keep changing.
<re_irc>
<pinkforest-rust> My assumption is about RFC making assumptions, not about specific assumptions about types.
<re_irc>
< (@dirbaio:matrix.org)> an ipv4 address is _defined_ to be a "[u8;4]" by the IETF RFCs
<re_irc>
< (@adamgreig:matrix.org)> (they have left this room)
<re_irc>
< (@dirbaio:matrix.org)> oh
<re_irc>
< (@dirbaio:matrix.org)> yay ragequit :D
<re_irc>
< (@jamesmunns:beeper.com)> (edit: person has left, still worth writing up):
<re_irc>
As other folks have stated, anything that doesn't make assumptions about the environment, which specifically refers to things like:
<re_irc>
Will often be included in core. Sometimes, like in the IpAddr case, this can be good even if there is no actual TCP/IP stack included in "core", so that alternate implementations (like smoltcp dirbaio linked) can use the same fundamental datatypes (or traits, etc), for better compatibility.
<re_irc>
- What (if any) allocator will be used
<re_irc>
- What (if any) network stack, filesystem, etc. will be used.
<re_irc>
< (@adamgreig:matrix.org)> and the RFC doesn't need to justify including things on the basis of bloat/increasing application size, because it won't increase application size
<re_irc>
< (@adamgreig:matrix.org)> you could say "why not leave IpAddr to an external crate, why have it in core?" but that's because "std" already requires such a type so it has to exist at least there; the rfc is just about also allowing it to exist in "core" now that that's possible
<re_irc>
< (@adamgreig:matrix.org)> I can't tell if their bigger concern is binary size increase and that the rfc should therefore justify the increase or include tests against it or something (but that's not for the rfc to worry about), or that core is somehow not appropriate for such a type
<re_irc>
< (@adamgreig:matrix.org)> (but I don't think this will actually affect the FCP?)
<re_irc>
< (@jamesmunns:beeper.com)> I _was_ intending to be humorous with the lebowski quote, but probably wrong time/place :/
<re_irc>
< (@ryan-summers:matrix.org)> The same argument could be made about u64 and u128 being in core. We don't use those in embedded (mostly)
<re_irc>
< (@ryan-summers:matrix.org)> Weird opinion to have imo. I love that it's getting added personally
<re_irc>
< (@matoushybl:matrix.org)> : I just skimmed the slides, was there any mention of Rust there? It'd be cool if there was.
<re_irc>
< (@ivii:matrix.org)> unfortunately not
<re_irc>
< (@jamesmunns:beeper.com)> In the future - it would probably be good to explain/give some context before dropping links here, so they don't get marked as spam/deleted.
<re_irc>
< (@matoushybl:matrix.org)> Fun fact, a few months ago a spoke with a Rimac engineer and upon mentioning Rust, he immediately mentioned RTIC.
<re_irc>
< (@matoushybl:matrix.org)> Seems like more people are getting to know things developed here.
<re_irc>
< (@jamesmunns:beeper.com)> At Ferrous and in solo consulting, I'm always surprised when people mention crates by name, especially when they aren't already doing (much/any) rust. I've had both RTIC and Embassy mentioned as "maybe we want to use these specifically"
<re_irc>
< (@jamesmunns:beeper.com)> this was the main driver of me proposing the change away from RTFM - I got tired of explaining it doesn't mean "read the fucking manual" in customer call :D
<re_irc>
< (@jamesmunns:beeper.com)> * the RTFM name
<re_irc>
< (@jamesmunns:beeper.com)> (sure: a lot of that is CI, but it's still a sustained 5-10k downloads/day)
<re_irc>
< (@adamgreig:matrix.org)> imagine how I feel when I "cargo publish" a new cortex-m lol
<re_irc>
< (@jamesmunns:beeper.com)> (the point I'm making is that there are actually a lot of people using it, even more than the 1.4k+ people we have here :D )
<re_irc>
< (@adamgreig:matrix.org)> and that's not even the biggest of the stm32-rs pacs 😬
<re_irc>
< (@adamgreig:matrix.org)> oh, wait, it's h7, yes it is the biggest
<re_irc>
< (@halfbit:matrix.org)> yeah see... this is exactly why imxrt-rs _doesn't_ use that stuff :-)
<re_irc>
< (@halfbit:matrix.org)> the new version of the ral uses a nice hacked up chiptool Ian did, which is super cool
<re_irc>
< (@halfbit:matrix.org)> I used a hacked up chiptool myself to generate register access for a PCI device with bar's mmaped into userspace, was really nice
<re_irc>
< (@dirbaio:matrix.org)> glad to see chiptool getting some use 🤩
<re_irc>
< (@dirbaio:matrix.org)> I also have used a hacked-up chiptool for writing drivers for i2c stuff myself (u8 address, so not memory mapped at all)
<re_irc>
< (@dirbaio:matrix.org)> I wonder how to better support these use cases, maybe allow some customization on which "address" type to use (not always a pointer)?
<re_irc>
< (@dirbaio:matrix.org)> but anyway, the issue with the stm32-rs pacs is not chiptool vs svd2rust. svd2rust generates output "only" ~3x bigger and slower to compile than chiptool
<re_irc>
< (@dirbaio:matrix.org)> the issue is the SVDs don't use arrays for a lot of stuff that should. for example it has separate registers and bits for each gpio port and pin
<re_irc>
< (@dirbaio:matrix.org)> * they have
<re_irc>
< (@dirbaio:matrix.org)> that's easily ~50x bloat, not just ~3x :D
<re_irc>
< (@halfbit:matrix.org)> in the imxrt-rs case the output is closer to what 's ral scripts did, as that's what was being used previously
<re_irc>
< (@halfbit:matrix.org)> in effect the imxrt-ral has no code to compile, its more like a bunch of C #define's
<re_irc>
< (@halfbit:matrix.org)> prior usage of the svd2rust tool generated a 1mloc+ crate that took significant amounts of time to build
<re_irc>
< (@adamgreig:matrix.org)> and svd2rust can't combine multiple devices, so each stm32-rs pac might be like ten pacs, though this doesn't affect compile times especially since it's just one at a time
<re_irc>
< (@adamgreig:matrix.org)> I thought imxrt used to use basically stm32ral.py for codegen and just recently swapped to the forked chiptool?
<re_irc>
< (@halfbit:matrix.org)> that's correct
<re_irc>
< (@dirbaio:matrix.org)> oh so you forked it _hard_ then :D
<re_irc>
< (@halfbit:matrix.org)> Ian did yes, the output generator is completely different
<re_irc>
< (@adamgreig:matrix.org)> did imxrt-rs ever use svd2rust?
<re_irc>
< (@halfbit:matrix.org)> but the internals are the same as I understood it
<re_irc>
< (@halfbit:matrix.org)> like svd + yaml -> internal representation -> ral-like instead of svd2rust-like output
<re_irc>
< (@adamgreig:matrix.org)> aiui it still uses (ral-registers)[https://crates.io/crates/ral-registers] for the types, and raltool just does the codegen
<re_irc>
< (@adamgreig:matrix.org)> hmm, so much for markdown
<re_irc>
< (@halfbit:matrix.org)> imxrt-rs started off with svd2rust, and was quickly abandoned (I started it with svd2rust), found that it was horrible for this case, connected with Ian (teensy4-rs author) and we combined efforts for the initial push
<re_irc>
< (@adamgreig:matrix.org)> aiui it still uses ral-registers (https://crates.io/crates/ral-registers) for the types, and raltool just does the codegen
<re_irc>
< (@adamgreig:matrix.org)> aah got it
<re_irc>
< (@halfbit:matrix.org)> Ian is now the predominate author for sure
<re_irc>
< (@adamgreig:matrix.org)> so svd2rust -> imxrtral.py based on stm32ral.py -> raltool based on chiptool based on svd2rust
<re_irc>
< (@halfbit:matrix.org)> indeed
<re_irc>
< (@halfbit:matrix.org)> its a big convoluted party of tooling
<re_irc>
< (@adamgreig:matrix.org)> :D
<re_irc>
< (@halfbit:matrix.org)> would love see chiptool become the defacto thing, and include maybe the ral-like output generator
<re_irc>
< (@dirbaio:matrix.org)> :D
<re_irc>
< (@halfbit:matrix.org)> but that would mean effort is involved
<re_irc>
< (@halfbit:matrix.org)> and we all know how that goes
<re_irc>
< (@adamgreig:matrix.org)> there's been a lot of recent work on svd2rust since the chiptool fork too 🤔
<re_irc>
< (@dirbaio:matrix.org)> but if it did then everyone would want to add their own pet feature to it, then it'd also become bloated
<re_irc>
< (@halfbit:matrix.org)> make the core svd+yaml stuff plus internal representation a crate of its own?
<re_irc>
< (@dirbaio:matrix.org)> +become the defacto thing,
<re_irc>
< (@halfbit:matrix.org)> the generation parts can take that internal representation and generate whatever then
<re_irc>
< (@adamgreig:matrix.org)> does chiptool use the svd crate?
<re_irc>
< (@halfbit:matrix.org)> I really liked the structures chiptool enables describing, it makes a lot of sense
<re_irc>
< (@dirbaio:matrix.org)> : svd_parser, yes. but only when ingesting SVDs. it uses its own IR structs for everything
<re_irc>
< (@dirbaio:matrix.org)> +after that
<re_irc>
< (@halfbit:matrix.org)> right, I could imagine a chiptool to generate a low level spi/i2c device driver even...
<re_irc>
< (@halfbit:matrix.org)> as you said :-)
<re_irc>
< (@halfbit:matrix.org)> I can vouche it works on linux with pci devices being mmaped
<re_irc>
< (@halfbit:matrix.org)> right, I could imagine a chiptool to generate a low level spi/i2c device register crate, on which a driver could be built
WSalmon has quit [Remote host closed the connection]
WSalmon has joined #rust-embedded
<re_irc>
<Colin Mikolajczak> Hi together, unfortunately I had to switch from Rust job to a C++ job and now I'm looking for a side project where I can spend a lot of my time and keep my Rust skills up to date. Are there any of you that need help maintaining a crate or have an idea for a new one? I hope this is the place for such a question, and I'm sorry if its not
<re_irc>
<Andrew Gazelka> Colin Mikolajczak: just curious, was this bc of the job market? I find most Rust jobs to be in very speculative fields such as blockchain/crypto
<re_irc>
<Andrew Gazelka> this is while at the same time hearing from employers that it is hard for them to find proficient Rust developers
<re_irc>
<Colin Mikolajczak> No it was due to the company and decisions the leadership made etc..