<re_irc>
<@ryan-summers:matrix.org> Thanks for handling that release :) was going to handle it as I got into the office this morning and you beat me to it
<re_irc>
<@ryan-summers:matrix.org> Hope to do some more work on the API a bit and clean it up in the future
<re_irc>
<@crespum:matrix.org> Isn't that similar to what Espressif is trying to do with embedded-svc (https://crates.io/crates/embedded-svc) (at least regarding wifi?
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc>
<@regexident:matrix.org> Is there a reliable (yet possibly "unsafe") way to obtain the raw numerical port/pin values of an HAL's "Pin" value?
<re_irc>
For a bit-banging implementation I need to perform (AVR) ASM ops directly on the register to achieve the precise timing required by the protocol. I could of course just pass in the raw register address and pin bitmask as it is done outside of Rust but I'd like my code to be nice and safe and also work with embedded-hal/avr-hal.
<re_irc>
I so far haven't been able to find such an API escape hatch for either of them. I can't be the first person with such a need though.
<re_irc>
<@ryan-summers:matrix.org> : No clue! I' originally started elevating the NAL to enable things like MQTT clients that use hardware-agnostic network stacks (e.g. either hardware-based ones like the W5500 or smoltcp)
<re_irc>
<@eldruin:matrix.org> regexident: There is no standardized way of doing that. It seems to me like the kind of thing that HAL implementations are meant to hide. However, your HAL implementation may provide (or be interested in providing) such information.
<re_irc>
<@regexident:matrix.org> : I see. I'm not just blind then.
<re_irc>
Totally with you on the whole point behind HALs being to hide such things. But if it means that one cannot write ASM code with raw register ops, then that's rather limiting when it comes to optimizing for efficiency/performance/time-precision. And having such escape hatch, but only on a per-HAL basis would also be somewhat prohibitive for writing generally applicable crates. 🙁
<re_irc>
<@diondokter:matrix.org> regexident: Do check the performance first. Many HALs have a type per pin. And as such the compiler is very capable in optimizing the instructions
<re_irc>
<@dirbaio:matrix.org> hand-written asm is not generally applicable anyway :P
<re_irc>
<@dirbaio:matrix.org> so a HAL-specific API for getting pin numbers would work equally well for you than an embedded-hal trait for that
<re_irc>
<@regexident:matrix.org> : The implementation, yeah. But having such access from a trait would allow to hide it as an implementation detail (e.g. behind "#[cfg(target_arch = "avr")]") and provide a high-level API on top of whatever you're implementing.
<re_irc>
<@jamesmunns:beeper.com> so, for example, the nrf-rs crate does expose what you're asking for
<re_irc>
<@jamesmunns:beeper.com> so if you are writing something FOR THAT PLATFORM, there's a way to handle that
<re_irc>
<@jamesmunns:beeper.com> but that's a lot different than embedded-hal and portability - different chips use pretty wildly different ways of identifying ports and pins!
<re_irc>
<@jamesmunns:beeper.com> for example on the nrf52, there can be port 0/1, each with 0..32 pins
<re_irc>
<@dirbaio:matrix.org> if you're already using cfg's, you can make them choose either "take an avr-hal pin, use asm" or "take an embedded-hal OutputPin, use its API"
<re_irc>
<@jamesmunns:beeper.com> so avr-hal could provide that, but embedded-hal probably couldn't/shouldn't.
<re_irc>
<@dirbaio:matrix.org> "take an embedded-hal OutputPin+GetPinNumber, use asm" is a weird "hal-independent but not really" middle groupd
<re_irc>
<@dirbaio:matrix.org> * ground
<re_irc>
<@dirbaio:matrix.org> if you're already using cfg's, you can make them choose either "take an avr-hal pin, use asm" or "take an embedded-hal OutputPin, use set_high/set_low"
<re_irc>
<@dirbaio:matrix.org> that doesn't gain you anything
<re_irc>
<@regexident:matrix.org> /: those are some very fair points indeed. I guess I should look into opening an issue/pr on "avr-hal" then, mentioning the "nrf-rs" crate as prior art. 🤔
emerent has quit [Ping timeout: 256 seconds]
emerent has joined #rust-embedded
Foxyloxy has joined #rust-embedded
duderonomy_ has quit [Remote host closed the connection]
<re_irc>
<@whitequark:matrix.org> : so it looks like I misremembered some details and in ARMv7-M, the location of IVT at reset is _IMPLEMENTATION DEFINED_, and the behavior where stuff is aliased at address 0 is how ST implemented it
<re_irc>
<@whitequark:matrix.org> in probe-run, the right way to do this would be to read the IVT address from VTOR, which will work even if you have a bootloader, though it could break if your firmware is doing something really weird with the IVT
<re_irc>
<@whitequark:matrix.org> and the answer to your question is "it is dependent on the MCU family, but the way to do it properly is to have the reset vector be pointed at by a symbol defined in cortex-m-rt as a part of its ABI"
<re_irc>
<@pacarito:mozilla.org> Is ESP32 a good board to learn on?
<re_irc>
<@k900:conduit.0upti.me> Depends on the flavor of ESP32 I think
<re_irc>
<@k900:conduit.0upti.me> The Xtensa variants still need a custom build of rustc which gets slightly messy
<re_irc>
<@pacarito:mozilla.org> How does one go about writing unit-tests for an embedded project? Is it common to try to simulate the environment and run there?
IlPalazzo-ojiisa has quit [Quit: Leaving.]
<re_irc>
<@k900:conduit.0upti.me> You can do testing in something like QEMU, but it's definitely not "unit"
<re_irc>
<@k900:conduit.0upti.me> +at that point
<re_irc>
<@pacarito:mozilla.org> Yea, I see some conversations about separating hardware-independent code so you can test that on dev-host as unit, and hardware on emulators as functional/integration.
<re_irc>
<@pacarito:mozilla.org> +I see why that its so important to keep as much of that code as platform-independent now.
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc>
<@pacarito:mozilla.org> Are any of the old Alix boards able to run embedded Rust? https://pcengines.ch/alix.htm ?
<re_irc>
<@jamesmunns:beeper.com> I've seen some relativle older x86 stuff running rust
<re_irc>
<@jamesmunns:beeper.com> So I'd prooooobably guess "yes, they could", but with no idea what it would take :D
<re_irc>
<@jamesmunns:beeper.com> I've seen some relatively older x86 stuff running rust
<re_irc>
<@jamesmunns:beeper.com> There are some x86 bare metal os stuff, like Phil opps blog os
<re_irc>
<@k900:conduit.0upti.me> Bare metal x86 is extremely not fun
<re_irc>
<@k900:conduit.0upti.me> Would not recommend
<re_irc>
<@jamesmunns:beeper.com> Looks to be pentium 2 ish?
<re_irc>
<@k900:conduit.0upti.me> Especially pre-UEFI bare metal x86
<re_irc>
<@jamesmunns:beeper.com> Yeah, the harder part will probably be "how to start running your code" is going to be harder than compiling the code. Finding a bootloader and getting the image in the right format
<re_irc>
<@k900:conduit.0upti.me> Those things aren't even AMD cores
<re_irc>
<@k900:conduit.0upti.me> They're Geode LX, which is rebranded prehistorical Cyrix IP
<re_irc>
<@jamesmunns:beeper.com> I honestly have no idea if that is a problem or just a weird llvm target spec
<re_irc>
<@k900:conduit.0upti.me> It's definitely going to be a weird target
<re_irc>
<@k900:conduit.0upti.me> I'm not sure what features those actually support
<re_irc>
<@k900:conduit.0upti.me> But they're probably at best i486
<re_irc>
<@jamesmunns:beeper.com> I think I saw someone target 386 or 486 windows in rust recently?
<re_irc>
<@k900:conduit.0upti.me> But they do supposedly have 3DNow
<re_irc>
<@jamesmunns:beeper.com> I'm working from memory tho lol
<re_irc>
<@k900:conduit.0upti.me> With those old 486 knockoffs you never know, they might support, like, all of i486 except one weird addressing mode
<re_irc>
<@k900:conduit.0upti.me> And then you have to massage LLVM to make it stop generating that
<re_irc>
<@k900:conduit.0upti.me> Or something
<re_irc>
<@k900:conduit.0upti.me> Also good luck finding anything on how to do I/O on those
<re_irc>
<@firefrommoonlight:matrix.org> Whatup guys?! What sorts of speed impacts do you get from "opt-level="s"" as opposed to 3 etc? I am using a 128-kb MCU (G431), and had to set this to get "nalgebra" working. I usually do matrix and lin alg in general with my own streamlined lib, but this involves some large matrices and inverses. It currently compiles with "s", and everything seems fine.
<re_irc>
Of note, I'm also underclocking it from 170Mhz to 160Mhz to make the CAN clock more compatible with common FD timings.
<re_irc>
So far seems fine, but want to make sure I'm not missing anything.
<re_irc>
I'm suspicious CMSIS-DSP FFI is also causing the binary to bloat, but like nalgebra, I don't have any good alternatives
<re_irc>
<@firefrommoonlight:matrix.org> (Z doesn't offer noticible size savings over S. 2 is somewhere between 3 and S. S is about 2/3 the size of 3
<re_irc>
<@jamesmunns:beeper.com> tbh the answer is "benchmark it if you are worried about it"
<re_irc>
<@firefrommoonlight:matrix.org> FYSA I have no idea how this stuff works or what inlining is
<re_irc>
<@firefrommoonlight:matrix.org> Hah good pt
<re_irc>
<@jamesmunns:beeper.com> the answer super depends on your flash access patterns and wait states and stuff
<re_irc>
<@jamesmunns:beeper.com> esp with external/slow flash (or very high cpu clock speed) opt level s can end up faster, if the code is smaller
<re_irc>
<@firefrommoonlight:matrix.org> Very interesting! (Using onboard flash here for both program and config storage)
<re_irc>
<@jamesmunns:beeper.com> but also at the same time if it makes your code branchier because not as much is inlined, it can really slow thngs down
<re_irc>
<@firefrommoonlight:matrix.org> Also fun fact: If your program gets too big and hits your flash config storage page, writing/erasing that page will cause very surprisign things to happen! (My I2C init code triggered a bad timing error because it somehow 0ed out my clock timing struct)
<re_irc>
<@firefrommoonlight:matrix.org> -somehow
<re_irc>
<@jamesmunns:beeper.com> you can add a linker section to that so it becomes a compile error
<re_irc>
<@jamesmunns:beeper.com> like, notch out the section you use for non-program storage
<re_irc>
<@firefrommoonlight:matrix.org> (Also of note, yes, I am being cheap by using a 128kb MCU. It's fantastic at this price point though. Very cheap compared to the higher-flash variants and still loads of I/O and power)
<re_irc>
<@firefrommoonlight:matrix.org> That's a good point. memory.x stuff?
<re_irc>
<@jamesmunns:beeper.com> just shrink the FLASH section and add a CONFIG or STORAGE section, yeah, in memory.x
<re_irc>
<@firefrommoonlight:matrix.org> For now I'm happy just monitoring the bin size, but given I'm close to the end, this is definitely in teh real of UB etc if I accidentally spill program memory into the config page (which is at the end)
<re_irc>
<@jamesmunns:beeper.com> : I use STM32G0s all the time with 8KiB of RAM and 32-64KiB of flash :)
<re_irc>
<@firefrommoonlight:matrix.org> Your approach is probably safer
<re_irc>
<@firefrommoonlight:matrix.org> Hah!
<re_irc>
<@jamesmunns:beeper.com> : yeah there's no reason that shouldn't be caught at link time.
<re_irc>
<@firefrommoonlight:matrix.org> I think the culprits here are CMSIS-DSP and nalgebra
<re_irc>
<@firefrommoonlight:matrix.org> But I need them :/
<re_irc>
<@firefrommoonlight:matrix.org> To catch overflowing into storage page at link time, would I do this in memory.x?:
<re_irc>
Where it actually has 128k, but the last 2k is the config page?
<re_irc>
<@jamesmunns:beeper.com> yes, if your config page is the last page
<re_irc>
<@firefrommoonlight:matrix.org> Thanks!
<re_irc>
<@jamesmunns:beeper.com> make sure that you can erase a 2K page tho, and it doesn't need to be 4K or something
<re_irc>
<@firefrommoonlight:matrix.org> Set
<re_irc>
<@firefrommoonlight:matrix.org> It's 2k
<re_irc>
<@firefrommoonlight:matrix.org> These are currently <$2 USD at JLC, and the higher-flash ones are multiples of that
<re_irc>
<@firefrommoonlight:matrix.org> So, keeping this size is great
<re_irc>
<@firefrommoonlight:matrix.org> * helps
<re_irc>
<@firefrommoonlight:matrix.org> I appreciate all the info here!
<re_irc>
<@jamesmunns:beeper.com> yeah, the stm32g03x family gets sub-$0.50 in ~100s
<re_irc>
<@firefrommoonlight:matrix.org> Yea - would love to use those on a future project
<re_irc>
<@firefrommoonlight:matrix.org> This one has a lot going on, so I think G4 is the play. Multiple sensors, lots of filtering/sensor fusion, and lots of floating point ops
<re_irc>
<@firefrommoonlight:matrix.org> I have a different CAN node where I could probably get away with a G0 though
<re_irc>
<@firefrommoonlight:matrix.org> So another interesting thing - even the "half" lib was bloating my bin. I saved a few kb by copy+pasting the basics to convert to/from f32 and bytes vice importing the lib
<re_irc>
<@firefrommoonlight:matrix.org> I'm usually (As y'all probably know...) paranoid about dependencies, but I thought I was safe here
<re_irc>
<@firefrommoonlight:matrix.org> +adding
<re_irc>
<@firefrommoonlight:matrix.org> (Could definitely go for a builtin rust f16 type...)