<cgc17[m]>
<firefrommoonligh> "The rust embedded open source..." <- it's interesting to me that although it's small, it was very easy to find the embedded rust community. i was pleasantly surprised how easy it was to find rust groups for support.
IlPalazzo-ojiisa has quit [Quit: Leaving.]
<cgc17[m]>
i've done similar searches for C embedded before and didn't find the same environment with so many examples and such compiled in a single place (outside of arduino). I don't program in C though so i probably just don't know how to look for it properly.
notgull has quit [Ping timeout: 260 seconds]
<khionu[m]>
I've got some docs that say "a pulse is emitted", would that then be a short-but-high signal?
crabbedhaloablut has quit [Ping timeout: 240 seconds]
crabbedhaloablut has joined #rust-embedded
michaeldesilva[m has joined #rust-embedded
<michaeldesilva[m>
Hi all, I'm trying to compile a very basic `stm32h7xx_hal` blinky example to get started with my Ardunio GIGA Wifi R1 board (it has a Cortex M4/M7 chip STM32H747XI, same as the Portenta H7).
<SimonJohansson[m>
Hello! I'm pretty new to embedded Rust, and wondered if there are any tools to measure CPU and/or memory usage of an embedded Rust application on CortexM0? I've heard about orbuculum, but has anyone gotten it working with Rust?
<JamesMunns[m]>
* Re: CPU usage, there are a couple techniques that have been documented, mostly measuring time in an idle task, it depends a bit if you are using RTIC, Embassy, etc. how exactly to implement it
<JamesMunns[m]>
* Re: Static memory usage, tools like `cargo size` and `cargo nm` can tell you one side of it
<JamesMunns[m]>
* Re: Max stack usage, there are tools like `cargo-call-stack` that can give you a decent estimate, as long as you don't use certain features like recursion or too many function pointers
<JamesMunns[m]>
For heap allocators, most will tell you the current free space.
<JamesMunns[m]>
Additionally, I know `probe-run` had a "stack painting" tool that would let you see the max stack used in a given program run, not sure if that's been ported over to `probe-rs-cli`, which is today's recommended tool for flashing and getting logs (that most people use)
<JamesMunns[m]>
https://blog.japaric.io/cpu-monitor/ is the CPU usage post, it's fairly outdated in the implementation details today, but the overall approach is still correct
<SimonJohansson[m>
Great, thanks for your help! Appreciate it a lot :) will look into those
bpye has quit [Ping timeout: 260 seconds]
sjm42[m] has joined #rust-embedded
<sjm42[m]>
Once I made a "hardware" cpu measurement tool. Dedicated one pin for measurements, and then just put into start of all tasks a line to set that pin high, and to idle task a line to set that pin to low.
<sjm42[m]>
Then examine the results on an oscilloscope. It was quite enlightening to see how it behaves.
Lumpio[m] has joined #rust-embedded
<Lumpio[m]>
I once saw somebody do that with an analog multimeter
<Lumpio[m]>
Very oldschool
<sjm42[m]>
Something like that could perhaps be easily included right into RTIC itself, I guess. Then it would be very easy to enable and disable it
<sjm42[m]>
Haha yeah, that output pin can be seen as a distorted pwm output and then smoothed out with a capacitor and boom you have your cpu busy percentage as a voltage...
<JamesMunns[m]>
Lumpio[m]: also seen a pulse counter used to measure how many times an interrupt triggered
bpye has joined #rust-embedded
<sjm42[m]>
Yeah, also output pin could be used for "does my debounce thing inside interrupt handler really work"... then just use a storage scope to check it.
<sjm42[m]>
The possibilities are numerous (:
<sjm42[m]>
pffffft... my esp32 project 🙄'
<sjm42[m]>
it says could not allocate 262144 bytes of memory... just wondering how on earth it suddenly needs to allocate 256KiB in the middle of the program
<johannes[m]>
<adamgreig[m]> "then https://github.com/probe-rs..."; <- I got it to work by copying this function and making some changes. Thank you for your help!
<johannes[m]>
* I got it to work by copying this function and making some changes. Thank you for your help!
<johannes[m]>
I am extracting the binary from an elf to later flash it using the stm32 spi bootloader.
<johannes[m]>
* I got it to work by copying this function and making some changes. Thank you for your help!
<johannes[m]>
I am extracting the binary from an elf to later flash it via the stm32 spi bootloader.
Guest7282 has joined #rust-embedded
<sjm42[m]>
Should esp-storage work on Xtensa cpu i.e. esp32s hardware? :o
<JamesMunns[m]>
(probably better to ask that in #esp-rs:matrix.org)
<ragarnoy[m]>
Hey, I'm attempting to flash one of the i2c examples onto a XE125 development kit, which incorporates the XM125 module. This module integrates an A121 antenna with a STM32L431CBY6 microcontroller, but when I run the example, nothing happens after the flashing...
<ragarnoy[m]>
When using the proprietary software for the flashing, it is asked of the user to hold the DFU and RESET button in a certain order before it launches the flashing procedure, i've tried doing that but to no avail.
<ragarnoy[m]>
I'm not having any errors or whatnot, it finishes flashing after 4 seconds and then nothing happens. Any clue as to what I could do ?
<ragarnoy[m]>
and the XM125 datasheet because why not
<ragarnoy[m]>
* run the i2c embassy example, nothing
<khionu[m]>
Still playing with this st25dv04k, and I'm not getting the event I'm expecting. I've gotten other events that I've enabled but not FIELD_CHANGE. It's on by default, as is the GPO pin. I've checked for all the conditions under which I might not receive the event according to the datasheet, and... I'm just at a loss now.
<khionu[m]>
Should happen before and after every interaction :/
<JamesMunns[m]>
Any chance there's existing C code to see if you're missing some setup/config step that's necessary for the radio or the interrupt or something?
IlPalazzo-ojiisa has joined #rust-embedded
<khionu[m]>
<JamesMunns[m]> "Any chance there's existing C..." <- I found some C++, but my eyes started glossing after several minutes, lol. I don't _think_ they were doing anything I'm not.
<JamesMunns[m]>
but your dfu-util command seems to place it at 0x0804_0000
<michaeldesilva[m>
Ahhh...
<JamesMunns[m]>
you should probably change one of them to agree with the other.
<JamesMunns[m]>
If it's the hardware DFU boot loader, then you can probably change the dfu command, as the bootloader "lives somewhere else" in ROM.
<JamesMunns[m]>
If you are using the software arduino bootloader, I'm not sure how that is supposed to work, but you can probably try changing the memory.x to at least start at the 0x0804_0000 location.
<JamesMunns[m]>
If there *isn't* a software bootloader at 0x0800_0000, then the hardware won't know to "jump to" the other address.
<JamesMunns[m]>
You will also need to do a rebuild if you touched the memory.x, and may need to do a clean and rebuild (if you don't have a build-rs file that detects changes to that file)
<michaeldesilva[m>
JamesMunns[m]: Yes, I did a clean.
<michaeldesilva[m>
<JamesMunns[m]> "If there *isn't* a software..." <- You mean flash to 0x0800_0000?
<michaeldesilva[m>
> <@jamesmunns:beeper.com> If there *isn't* a software bootloader at 0x0800_0000, then the hardware won't know to "jump to" the other address.
<michaeldesilva[m>
* You mean flash to 0x0800\_0000? and update memory.x to the same
<michaeldesilva[m>
That may wipe the bootloader?
<JamesMunns[m]>
And change the linker script back
<michaeldesilva[m>
Will try!
<JamesMunns[m]>
michaeldesilva[m: If it's the hardware one: no. If the software one: I'd hope not
<michaeldesilva[m>
which places it in bootloader flash mode
<michaeldesilva[m>
It exposes Found DFU: [0483:df11] ver=0200, devnum=1, cfg=1, intf=0, path="0-1", alt=0, name="@Internal Flash /0x08000000/16*128Kg",
<michaeldesilva[m>
* It exposes Found DFU: \[0483:df11\] ver=0200, devnum=1, cfg=1, intf=0, path="0-1", alt=0, name="@Internal Flash /0x08000000/16\*128Kg",
<michaeldesilva[m>
So.. why doesn't it boot with the bootloader?
<michaeldesilva[m>
I mean its job is to just boot whatever sits at 0x0804_0000
<michaeldesilva[m>
My memory.x works though at 0x08000000 and replacing the bootloader. Curious!!
<michaeldesilva[m>
Thanks so much James Munns
<michaeldesilva[m>
At least I have a basic blinky...!!
FreeKill[m] has quit [Quit: Idle timeout reached: 172800s]
<michaeldesilva[m>
James Munns: I found an oddity though. If I replace the original bootloader, switch to bootloader flashing mode, upload the blinky, hit reset - the BLUE led blinks.
<michaeldesilva[m>
If I power cycle the board, it does nothing even if I RST the board
<michaeldesilva[m>
Even if I place it back in bootloader flashing mode, it plays "dead"
<michaeldesilva[m>
the only way to get it back, was to repeat the above cycle.
<michaeldesilva[m>
* above cycle. As soon as I power cycle, it plays dead.
<JamesMunns[m]>
I've never used that board, I have no idea, sorry
<michaeldesilva[m>
JamesMunns[m]: Yeah, it's not exactly common, but the chip is the same (as in other boards); I'll keep reading around this.
limpkin has quit [Ping timeout: 252 seconds]
limpkin has joined #rust-embedded
<cr1901>
adamgreig[m]: I sent a privmsg when you get the chance (nothing bad, just won't be here for meeting)
<ragarnoy[m]>
<ragarnoy[m]> "Hey, I'm attempting to flash one..." <- dirbaio: does this make any sense to you ? please
<dirbaio[m]>
<ragarnoy[m]> "dirbaio: does this make any..." <- with the proprietary flashing tool you'll have to ask *them* for help, I don't know anything about it
<dirbaio[m]>
dirbaio[m]: have you tried using something non-proprietary?
<dirbaio[m]>
dirbaio[m]: usually you'd connect SWDIO, SWCLK and GND from the board to a debug probe (like an stlink) and then use `probe-rs run`
bpye has quit [Quit: Ping timeout (120 seconds)]
bpye has joined #rust-embedded
<ragarnoy[m]>
dirbaio[m]: yeah that's what I did
<ragarnoy[m]>
ragarnoy[m]: their proprietary flash is over usb, but the dev kit still has the necessary pins
<ragarnoy[m]>
ragarnoy[m]: the behaviour i'm getting is the one i have using a nanodap debug probe
<ragarnoy[m]>
ragarnoy[m]: i mean the one i described is the one using probe-rs + debug probe
<dirbaio[m]>
ragarnoy[m]: okay so when you say "nothing happens", what do you mean
<dirbaio[m]>
dirbaio[m]: you do `cargo run` and then what
<dirbaio[m]>
dirbaio[m]: an error, or no output?
<ragarnoy[m]>
<dirbaio[m]> "an error, or no output?" <- no output, nothing
<ragarnoy[m]>
<dirbaio[m]> "an error, or no output?" <- it hangs
<ragarnoy[m]>
ragarnoy[m]: but doesn't hand me back the control of the terminal
<ragarnoy[m]>
<ragarnoy[m]> "but doesn't hand me back the..." <- i think it might be hanging when trying to attach to rtt
<dirbaio[m]>
<ragarnoy[m]> "i think it might be hanging when..." <- are you running with DEFMT_LOG=trace?
<dirbaio[m]>
dirbaio[m]: also check the chip feature for embassy-stm32 in Cargo.toml is correct
<dirbaio[m]>
dirbaio[m]: also, please don't ping individual people for help, it's considered bad form
<adamgreig[m]>
@room meeting time! agenda is https://hackmd.io/Om5EpBaWSbaYtp1jDGrapg, please add anything you'd like to announce or discuss and we'll start in a few mins
<adamgreig[m]>
hm, it didn't pill the at-room but i assume it still triggered the notification
<JamesMunns[m]>
was notified :)
HannoBraun[m] has joined #rust-embedded
<HannoBraun[m]>
adamgreig[m]: Did for me!
therealprof[m] has joined #rust-embedded
<therealprof[m]>
Not for me. ;)
<JamesMunns[m]>
(or rather: I got a bubble, idk if I got like a phone notif)
<adamgreig[m]>
matrix 🤷
<JamesMunns[m]>
btw I was talking about "in band signalling" to someone this week, and explained how there used to be a way to make someone elses modem hang up if you sent an IRC message with a special AT command in plaintext, and the response was "what is IRC"
<JamesMunns[m]>
and I realized just how old that IRC is and how recently we were using it :D
danielb[m] has joined #rust-embedded
<danielb[m]>
what is a modem
<JamesMunns[m]>
danielb[m]: someone old enough to remember dial up but wasn't technical enough back then to have encountered IRC
<JamesMunns[m]>
> It was also used on IRC to disconnect people using dial-up Internet access by sending ICMP ECHO REQUEST containing the string +++ATH0 and thus the modem hanging up when the victims' computer sent back the ICMP payload in the reply.
<therealprof[m]>
adamgreig[m]: funny, I actually had to explain on-hook and off-hook a few dozen times already.
<JamesMunns[m]>
:D
<ragarnoy[m]>
<dirbaio[m]> "also, please don't ping individu..." <- sorry, i didn't know anyone else who could help, i wont do it again, turns out the stm32 feature was wrong, now it does display thing but it instantly crashes
<JamesMunns[m]>
This was my way of explaining why using in-band signaling (specifically for message framing) Might Be A Bad Idea.
<ragarnoy[m]>
ragarnoy[m]: i mean i did ask around before asking you and no one knew
<vollbrecht[m]>
so i can send an unproteced icmp to disconnect someone else remotely?
<JamesMunns[m]>
vollbrecht[m]: anyone using an early generation dialup/AT modem, yep
<JamesMunns[m]>
you will sever their 2400 baud connection :(
<adamgreig[m]>
these days even irc is TLS, rip
<therealprof[m]>
They became a lot smarter though. ;)
<adamgreig[m]>
anyway, let's begin
<adamgreig[m]>
just one announcement from me; the planned embedded workshop at RustNL is still expecting to go ahead, the dates and details are a bit firmer
<adamgreig[m]>
https://2024.rustnl.org/ has details on the conference itself, currently the plan is to have two days immediately afterwards for embedded stuff, something like 20-30 people
<adamgreig[m]>
exactly what is worked on is still up for discussion, so it would be great to collect some ideas
<adamgreig[m]>
depending on numbers, the organisers said it should be possible to help some people with travel/accommodation, too
<adamgreig[m]>
in principle the goal is primarily to focus on developing the rewg and related projects, so the target audience is more or less existing and potential contributors
<jannic[m]>
Small announcement from rp-rs: rp2040-hal 0.9.2 was released with embedded-hal 1.0 support. Still under the same feature flag as before for the alpha/rc releases. Full support will come with rp2040-hal 0.10.0.
<adamgreig[m]>
we'd also like to get some more names on the list, so if you didn't already express interest when we mentioned this a few weeks back, please do so soon! either here or to me is fine
<JamesMunns[m]>
adamgreig[m]: +1 for me, will definitely be at the conf
<therealprof[m]>
As @adamgreig:matrix.org said, details are still developing. Planned price of admission is free, but it would be good to have a reading of who's interested to come.
bartmassey[m] has joined #rust-embedded
<bartmassey[m]>
I don't know what the teaching documentation will be like by May, but I definitely want to talk with folks about on-ramp for new embedded developers at RustNL Embedded. I'm planning to be there.
<adamgreig[m]>
some possible topics we thought about included getting a new cortex-m release out at last, and maybe pushing through the various changes to the pac system that have been discussed at length
<adamgreig[m]>
and yea, another topic was the continued revamp of the discovery book that you're already talking about on that issue
<adamgreig[m]>
ah yes I should have said, no cost to join the workshop! though if your company might be interested in sponsoring to help allow everyone to attend, please get in touch 👀
<adamgreig[m]>
korken89[m]: nice!!
<adamgreig[m]>
oh wow it does the confetti even if you reply to a message with the emoji huh
<adamgreig[m]>
therealprof: anything else you wanted to mention about the rustnl workshop?
<therealprof[m]>
adamgreig[m]: mac? :D
<adamgreig[m]>
we'll discuss it more in future meetings I think, to try and work out a more detailed list of who's coming and what we want to work on
<adamgreig[m]>
there's also scope for developing things like probe-rs, rtic, or embassy
<therealprof[m]>
Nope, I think we've covered everything we know so far. It would be good to have a rough estimate of people willing to come. And if you'd like to come but have troubles doing so, please get in touch so we can find a solution.
<adamgreig[m]>
cool, well hopefully see lots of you there!
<adamgreig[m]>
thanks jannic and korken89 for the rp2040-hal and rtic announcements, sounds good!
<adamgreig[m]>
otherwise just two agenda items today, one is the followup PR after last week's meeting about how to handle failures in CS pins in embedded-hal-bus, https://github.com/rust-embedded/embedded-hal/pull/574
<adamgreig[m]>
GrantM11235, did you have anything to discuss about that or just waiting for review etc?
<GrantM11235[m]>
I think #574 looks good, I can add some documentation if there is some consensus that it is the right way to go
<adamgreig[m]>
I feel like once upon a time if your .text didn't fit in flash you got an error from the linker saying it overflowed the section, rather than this error from c-m-rt which I think was meant to target a different problem
<adamgreig[m]>
in any event it's bad if we're giving these very confusing errors when flash is too full
<adamgreig[m]>
though perhaps it just depends on exactly what's overflowing, but rodata and data come after text in flash so I'd have thought text being too big would cause the linker's own overflow message instead, dunno
<therealprof[m]>
I think better error messages would be nice. However it's not quite clear how benefitial it is to simply be more verbose without adding any additional information, or worse, giving from information.
<adamgreig[m]>
yea, but if this check is now the first thing that catches "too much code, doesn't fit in flash", we should mention the possibility in the error
<adamgreig[m]>
the error makes it sound like "you screwed up your memory.x by custom placing _stext outside of flash", but the actual problem is "you had too much code"
<adamgreig[m]>
seemingly, anyway
<therealprof[m]>
Do our flashing tools warn when flashing more data into the supposedly available amount of flash?
<GrantM11235[m]>
yeah, I would argue that the current error is giving wrong information
<adamgreig[m]>
probe-rs does, but rust errors out before producing such an elf anyway
<adamgreig[m]>
the error happens before the flashing tools get it
<therealprof[m]>
adamgreig[m]: The problem is: there might be enough flash but memory.x is wrong.
<adamgreig[m]>
(of course, if your memory.x said you had 100MB of flash, it would shut the linker up, and then probe-rs would separately check based on which chip you told it you have)
<therealprof[m]>
We can't say that though because it might be correct and the program really is too large to fit.
<adamgreig[m]>
ah, that's true indeed
<adamgreig[m]>
so the error is "too much .text for the flash you said you had", but maybe they said the wrong amount of flash instead of had too much code
<therealprof[m]>
adamgreig[m]: I get that. I was just wondering what would happen if the solution is: increase the flash size in memory.x so the linker won't complain anymore.
<adamgreig[m]>
yea, probe-rs or other tools would eventually catch it when you come to program it
<jannic[m]>
I just added a giant static to some porgram and got = note: rust-lld: error: section '.rodata' will not fit in region 'FLASH': overflowed by 8397184 bytes. That's not bad, IMHO. Is it known what exactly triggers the bad error message from the ticket?
<adamgreig[m]>
the current error seems unhelpful either way, so it should probably be updated one way or another
<adamgreig[m]>
huh, that's the error I remember seeing
<bartmassey[m]>
I want this to be a compile-time error so that you can find out your program won't fit even when there's no device available to try it.
<jannic[m]>
* I just added a giant static to some program and got = note: rust-lld: error: section '.rodata' will not fit in region 'FLASH': overflowed by 8397184 bytes. That's not bad, IMHO. Is it known what exactly triggers the bad error message from the ticket?
<bartmassey[m]>
(link time, but same deal)
<adamgreig[m]>
interesting. I wonder if rodata causes FLASH to overflow, but the linker script checks happen first and catch only text overflowing
<adamgreig[m]>
bartmassey: yea definitely, and it is always going to be a compile-time error (so long as your memory.x has the correct flash size)
<adamgreig[m]>
just that the current error you sometimes get is very unhelpful at pointing you in the right direction
<therealprof[m]>
adamgreig[m]: That might also depend on the used linker though.
<adamgreig[m]>
we can check for the small set of linkers we support, at least
<adamgreig[m]>
our linker script doesn't check that rodata is inside flash, only text
<adamgreig[m]>
so I think the answer is "our errors trigger first, and linker built in overflow errors trigger later"
<adamgreig[m]>
we could just delete our check on .text and I think you'd then get the normal linker overflow, which at least tells you how many bytes you overflowed by
<therealprof[m]>
Hm, would be good to figure out the reason why we added that in the first place.
<JamesMunns[m]>
It gave that error for ram, but not flash
<JamesMunns[m]>
I was wondering if asserts get checked before overflow errors
<bartmassey[m]>
The larger problem here is that the current methods of providing `memory.x` are kind of marginal.
<bartmassey[m]>
For Microbit there's a common`memory.x` in the `microbit` crate that as far as I know isn't used, which isn't great since its sizes are for the much smaller Microbit v1.
<bartmassey[m]>
The `memory.x` for Microbit is actually provided by `nrf52833-hal`, which is probably fine. But if I had some other board with that chipset plus a big extra flash or ram chip, I'd probably be stuck with a build script or something to make sure I got the right `memory.x`?
<adamgreig[m]>
therealprof: I _think_ the error was added to catch people manually defining _stext to somewhere outside of FLASH
<adamgreig[m]>
for simple chips you just need to somehow say how big ram and flash are, and what address they start at, and I think a lot of hals support supplying the right memory.x based on you picking a feature flag in the hal with the right part number
<adamgreig[m]>
when the chip gets more complicated there's a lot of fiddly details the end user might want to customise, though...
<adamgreig[m]>
the fact that the linker search path is a bit magical doesn't help. the directory that cargo.toml is in is searched first, then the OUT_DIR, so a build script can place things there, but they can also just go in the crate root. unless you're using a workspace...
<JamesMunns[m]>
adamgreig[m]: This was with embassy-stm32 and the memory-x feature, iirc
<adamgreig[m]>
I don't think there's anything wrong or special about embassy's memory.x here
<adamgreig[m]>
JamesMunns[m]: I think it's just this
<therealprof[m]>
adamgreig[m]: They do? That's a huge pity because all of a sudden you have to worry about gnarly details which are often not at hand (like the exact chip model).
<adamgreig[m]>
we only have one assert that smells like "check thing was small enough to fit" really
<JamesMunns[m]>
Yeah, just saying it was a good memory x
lockna has quit [Client Quit]
<bartmassey[m]>
therealprof[m]: Absolutely makes sense. But I don't think that `memory.x` gets used anyway? It depends on the search order vs the one in `nrf52833-hal`. I will poke at this with you at some point. I wrote a build script for `microbit`, but then got sidetracked.
<adamgreig[m]>
but I think the assert was meant to check someone wasn't doing a weird customisation, it wasn't intended to detect over-sized .text
lockna has joined #rust-embedded
<adamgreig[m]>
so possibly it should just be removed entirely -- we do document that you can override _stext, so it's there to check you didn't override it badly -- but if it's primarily now catching people where .text is too big, that's a bad error
<therealprof[m]>
bartmassey[m]: As @adamgreig:matrix.org said: the linker script is looked for in multiple locations. I can't tell off hand which one is really going to be used under what circumstances.
<adamgreig[m]>
maybe we should change the assert from `ASSERT(_stext + SIZEOF(.text) < ORIGIN(FLASH) + LENGTH(FLASH), "` to `ASSERT(_stext > ORIGIN(FLASH) && _stext < ORIGIN(FLASH) + LENGTH(FLASH)`
<adamgreig[m]>
which won't trigger on text overflow any more, that'd get caught by the linker as normal
<adamgreig[m]>
and if you did put .stext too close to the end of FLASH, it would still get the right overflow error
<adamgreig[m]>
but if you put _stext outside of FLASH entirely, it would hit this assert instead
<therealprof[m]>
We could try that.
<therealprof[m]>
But as you said, we should have a look at various linkers. I'm actually not sure which ones we officially support. I'm pretty sure I used a variety of linkers in the past.
<adamgreig[m]>
next you'll ask where we say that, which, dunno. but those are what we test and CI with
<therealprof[m]>
Fair.
<adamgreig[m]>
specifically those three, not gcc or binutils in general
<therealprof[m]>
Well, that's where they come from. 😅
bpye has quit [Quit: Ping timeout (120 seconds)]
<adamgreig[m]>
sure, but we don't test with like plain lld
<adamgreig[m]>
or gcc/ld outside of the "ARM gcc compiler" distribution
bpye has joined #rust-embedded
<therealprof[m]>
Yeah, doesn't matter though. They're all the same. As long as no one starts experimenting with gold or other fancy linkers...
<thejpster[m]>
Gcc isn’t a linker. It’s a linker driver that just passes args to the real like
<thejpster[m]>
s/like/linker/
<thejpster[m]>
Fyi
<adamgreig[m]>
sure, yea
<adamgreig[m]>
but you can tell rust to use it as a linker and the resulting behaviour is different to arm-none-eabi-ld
<adamgreig[m]>
specifically useful when linking with C or C++ code
<thejpster[m]>
Only on that it passes extra arguments to ld
<thejpster[m]>
It has no idea if your binary is too big
<adamgreig[m]>
doesn't it?
<adamgreig[m]>
it does, the same as rust-lld etc knows: because the linker script has a FLASH region with a size, and you told it what to put in there, and it will error if it can't fit them
<therealprof[m]>
thejpster[m]: Funny enough, it could be using either binutils, llvm, gold or mold as actual linker.
<adamgreig[m]>
not mold on armv7m at least :P not sure if gold supports it either
<therealprof[m]>
I've no idea, just saying: whatever magic it is doing, it could produce completely different (or no) results.
<adamgreig[m]>
more specifically I don't think arm-none-eabi-gcc will be using gold or mold as the linker, afaik that's always arm-none-eabi-ld?
<adamgreig[m]>
I guess if you specifically ask it to use something else it will try to 😅
<thejpster[m]>
It’ll call any ld in the path, or in the -B path, or it’ll call ld.lld if you pass -fuse-ld=lld.
<adamgreig[m]>
it (the arm gcc compiler distribution arm-none-eabi-gcc) will call its own ld from that distribution, rather than the ld in your path
<thejpster[m]>
Not really relevant here, just wanted people to note gcc isn’t a linker, only a linker driver.
<adamgreig[m]>
afaik
<adamgreig[m]>
anyway yea we're a bit in the weeds
<adamgreig[m]>
anything else anyone wanted to mention before the end of the meeting?
<therealprof[m]>
`arm-none-eabi-gcc` is only the name of the binary compiled for arm-non-eabi... there's no relation (other than the name) with the binaries distributed by ARM.
<therealprof[m]>
Gotta jump... bbl.
AdamHott[m] has joined #rust-embedded
<AdamHott[m]>
just wanted to mention that I haven't given up on the tooling documentation, I just ran into a bad rp2040 board to test, long story short now I have to solder some 402s on a stm32 board before I can do more probe-rs tests.
<thejpster[m]>
adamgreig[m]: Fair. It’ll have a few places to look before the system path.
<adamgreig[m]>
ok, thanks everyone! same time next week
<AdamHott[m]>
I'm guessing it's the IC2 Frequency, this line here, but not sure. let i2c = Twim::new(peripherals.TWIM0, i2c_pins, microbit::hal::twim::Frequency::K100);
<AdamHott[m]>
* I'm guessing it's the IC2 Frequency, this line here, but not sure.
<AdamHott[m]>
let i2c = Twim::new(peripherals.TWIM0, i2c_pins, microbit::hal::twim::Frequency::K100);
<GrantM11235[m]>
p0_00 is connected to the speaker, and you are also using it for sda
<AdamHott[m]>
ah I needed p1_00
<AdamHott[m]>
thanks I'll try this now
<AdamHott[m]>
<GrantM11235[m]> "p0_00 is connected to the..." <- solved, thanks so much!