<re_irc>
I installed the "protobuf-compiler" "version 3.6.1" in my ubuntu machine, while compiling i am getting some errors regarding "protoc", So How do I need to downgrade the "protobuf version"?
causal has quit [Quit: WeeChat 3.6]
emerent_ has joined #rust-embedded
emerent_ is now known as emerent
emerent has quit [Killed (zirconium.libera.chat (Nickname regained by services))]
explore has joined #rust-embedded
m5zs7k has quit [Ping timeout: 252 seconds]
m5zs7k has joined #rust-embedded
explore has quit [Quit: Connection closed for inactivity]
vancz has quit []
vancz has joined #rust-embedded
starblue has quit [Ping timeout: 264 seconds]
starblue has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<Christof Petig> James Munns: You might be able to find a SVD (although named .xml) in the official SDK as it is often used by debuggers. I found one for NXP's S32G in a jar file ...
<re_irc>
<hartan> How does one best handle inverting an I/O line? In particular, I've stumbled upon a SPI device that has its CS line inverted. That's pretty unfortunate, because my HAL implements the e-h "SpiDevice" by means of asserting ("set_high") and deasserting ("set_low") the CS lines.
<re_irc>
My particular MCU has the ability to invert the I/O lines via registers internally, but its HAL currently doesn't implement that.
<re_irc>
Another way I see to approach this would be to require the CS in the "SpiDevice" implementation to be "ToggleableOutputPin" and then rely on the user to initiate the CS line in deasserted state (Whatever that means for this particular device) and use "toggle" to handle the addressing.
<re_irc>
But what's best here? And how common are SPI devices with an inverted CS line in the first place? Is this something that should be handled on a broader scale?
<re_irc>
<dirbaio> make a struct wrapping a pin, implement OutputPin for it "the wrong way around", then build the SpiDevice with that
<re_irc>
<dirbaio> which HAL is it?
<re_irc>
<dirbaio> HALs shouldn't implement SpiDevice, only SpiBus
<re_irc>
<adamgreig> dirbaio: unless they use hardware cs, right? or probably e.g. linux with the spidev stuff...
<re_irc>
<dirbaio> yeah
dc740 has joined #rust-embedded
<re_irc>
<dirbaio> if the HAL is using plain old GPIO for CS there's no advantage in the HAL impling SpiDevice, it's better to leave it to the user to choose which SpiDevice impl to use (exclusive or shared, which kind of mutex for sharing...)
<re_irc>
<dirbaio> if it's something like linux spidev where the kernel already takes care of sharing and CS then yes, the HAL should impl SpiDevice, not SpiBus
<re_irc>
<dirbaio> because the spidev represents a spi device on a bus indeed :D
<re_irc>
<dirbaio> will i2c have the same problem?
<re_irc>
<eldruin> it would be somewhat less dramatic because of the lack of CS but whether the kernel could interleave messages for other devices, could be. I have not looked into the kernel part of it
<re_irc>
<eldruin> if that happens, it would be breaking the contract as well
GenTooMan has quit [Ping timeout: 255 seconds]
GenTooMan has joined #rust-embedded
neceve has joined #rust-embedded
sknebel has quit [*.net *.split]
jasperw has quit [*.net *.split]
sknebel has joined #rust-embedded
jasperw has joined #rust-embedded
causal has joined #rust-embedded
<re_irc>
<ostenning> I'm looking at my stm32 release binary with a hex editor, I've noticed some strings in the binary and I'm wondering how i can exclude them, they dont seem relevant to me, e.g:
<re_irc>
�"/Users/ostenning/.cargo/registry/src/github.com-1ecc6299db9ec823/embedded-graphics-core-0.3.3/src/geometry/point.rs ������������attempt to divide with overflow�"
<re_irc>
Is it normal to have entire file paths like this in a binary?
<re_irc>
<James Munns> Yes, because they could be produced in "panic!()" messages
<re_irc>
<ostenning> hmmmm, yeah I see
<re_irc>
<James Munns> How to remove them - typically by using a panic handler that doesn't format that, such as defmt, or using the unstable "panic_immediately_abort" feature.
<re_irc>
<James Munns> (defmt doesn't ALWAYS remove them, but you could also try things like "panic_reset" instead, which doesn't format in the panic handler, sometimes that is enough)
<re_irc>
<ostenning> Hmm I'm using a custom panic handler, I basically pull the PanicInfo path line and column fields and dump them only
<re_irc>
<ostenning> I dont use the message property
<re_irc>
<James Munns> The first part of your string is the path line, I'm guessing LTO wasn't "smart" enough in this case to notice you also weren't using the message field unfortunately.
<re_irc>
<James Munns> You might try "incremental = false" (usually helps a bit with code size), but no guarantees :p
<re_irc>
<adamgreig> are you looking at the elf file or a dumped binary with the hex editor?
<re_irc>
[unstable]
<re_irc>
<dirbaio> ostenning: if you want to get rid of panic message fmt bloat, add this to ".cargo/config.toml"
<re_irc>
<dirbaio> but that has a MASSIVE impact on binary size, I often see -30% .. -40%
<re_irc>
<dirbaio> (and yes, without these flags even LTO is not smart enough to optimize fmt bloat, even if the panic handler doesn't actually print the panic message)
<re_irc>
<adamgreig> I don't think the paths should be present, panic messages aside
<re_irc>
<adamgreig> they are in the elf, but not in the binary that's flashed to the chip
<re_irc>
<adamgreig> so it might be you're mostly seeing debug info in your hex editor
<re_irc>
<adamgreig> like, my firmware has "attempt to divide by zero" strings in it, but it doesn't have paths, which are in the elf
<re_irc>
<dirbaio> ahh they're hexdumping the .elf? 😅
<re_irc>
<adamgreig> maybe? ostenning, try "cargo install cargo-binutils" if you haven't already, then "cargo objcopy --release -- -O binary fw.bin" and then open "fw.bin" in the hex editor, that's what actually gets loaded to the chip
<re_irc>
<adamgreig> (you may as well leave debug=true in cargo.toml for release, the info is only in the elf)
<re_irc>
<ostenning> Ill double check but im almost certain its not the elf file
<re_irc>
<adamgreig> how are you generating it? the file in "target/thumbvblabla/release/myproject" is elf, you'd need to specifically dump the binary with objcopy or similar to get a raw bin
<re_irc>
<ostenning> Ill check my scripts when I get home, I think it is generated. I end up using it to flash my device with my custom bootloader
GenTooMan has quit [Ping timeout: 244 seconds]
<re_irc>
<ostenning> Yeah its not the ELF. I'm using "arm-none-eabi-objcopy" to build the binary
GenTooMan has joined #rust-embedded
<re_irc>
<ostenning> The ELF is massive and is full of strings, the binary isnt, but there are a couple of panic strings in there which looked abit strange to me
<re_irc>
<ostenning> but I suppose it makes sense
<re_irc>
<adamgreig> I'm surprised it's got the paths, but not so surprised by the strings
<re_irc>
<adamgreig> wonder if that's to do with the panic handler or what
<re_irc>
fn panic(info: &PanicInfo) -> ! {
<re_irc>
<ostenning> #[panic_handler]
<re_irc>
let mut str: heapless::String<FAULT_BUFFER_LEN> = heapless::String::new();
<re_irc>
<jannic> For something having "implementers of SpiDevice guarantee ..." in it's soundness conditions to be sound, SpiDevice would have to be an unsafe trait.
<re_irc>
<jannic> Looks reasonable. But I'm far from being an expert on macro soundness.
<re_irc>
<GrantM11235> Are macros always exported to the root of the crate? I would rather export it as "embedded_hal_async::spi::transaction_helper" if that is possible
dc740 has quit [Remote host closed the connection]
dc740 has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 258 seconds]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<burrbull> GrantM11235: You don't need to use 'macro_export' at all. Instead since edition2018 you can add "pub use macroname as macroname" in module where it is defined and then import macro as simple function.