adamgreig[m] has quit [Quit: Idle timeout reached: 172800s]
nex8192 has joined #rust-embedded
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 246 seconds]
<yandrik[m]>
<dngrsspookyvisio> "do ping me if you remember the..." <- Will do
cr1901_ is now known as cr1901
nex8192 has left #rust-embedded [Error from remote client]
cr1901 has quit [Ping timeout: 248 seconds]
<bpye>
Has anyone here tried adding support for a new device to the usb-device trait? I'm having a nightmare getting enumeration to work. I've gotten to the point that the device gets an address, the host queries 8 bytes of the descriptor okay and then attempts to query the full 18 bytes of the device descriptor, but that seems to fail
<bpye>
The device writes the response in 3 packets (8+8+2) but the macOS dmesg suggests only 8 or 16 bytes are received
<ian_rees[m]>
<thiskappaisgrey[> "Hello. I'm relatively new to..." <- Hi thiskappaisgrey - I'm not too familiar with RP2040 specifically, but would say that there are quite a few moving parts involved in that functionality. In Circuitpython, folks have put those pieces together in a way that they're easy to use, but I wouldn't be surprised if you'd need to assemble some/all of them in a Rust context. Offhand, you'd need to find/write code to
<ian_rees[m]>
provide a USB mass storage device, maybe could use https://crates.io/crates/usbd_mass_storage for instance (I've not personally used that crate, but found it through search at crates.io ), and hook that up with what's often called a HAL - Hardware Abstraction Layer - that provides USB device support on RP2040 (I assume this exists already), and you'll need some sort of filesystem support to handle the file that the host OS creates,
<ian_rees[m]>
finally a parser to read the file contents and interpret your settings. Not impossible by any stretch, but perhaps a big project to start with
<ian_rees[m]>
Without any idea about the wider project you're working on - my suggestion would be to start by hard-coding your settings in the Rust source code, maybe by stubbing out a set of functions like `fn get_foo_setting() -> usize { 5 }` and working on the rest of the functionality first. You'd need to recompile a binary for each settings change, but then could move on to adding the USB or filesystem, etc
<ian_rees[m]>
<bpye> "Has anyone here tried adding..." <- I've spent a bit of time with the ATSAMD USB support - IME some sort of bus analyzer is more-or-less mandatory
<ian_rees[m]>
On Linux, wireshark can capture USB at a rather low level. Not sure offhand if that will work on MacOS, but might be worth investigating
<ian_rees[m]>
USB Complete is a pretty good book on the topic
<bpye>
ian_rees[m] I have tried capturing the bus with pulseview, but haven't been able to really figure out what the issue is... The USB decoding in PuleView works but probably isn't the greatest
<ian_rees[m]>
do you have a dev board with some other micro that has working USB support, to compare against?
<bpye>
Yeah I think I probably do
<ian_rees[m]>
can also be quite helpful to set up some sort of out-of-band debugging, like over RTT or whatever, but you do have to be quite careful that the debugging code doesn't take too much time and get in the way of the USB
<bpye>
Hah yeah I noticed that with serial, though I can apparently get away with it at a high enough baud rate
<bpye>
Or at least, it doesn't make anything worse...
cr1901 has joined #rust-embedded
GenTooMan has quit [Ping timeout: 246 seconds]
<thiskappaisgrey[>
<ian_rees[m]> "Hi thiskappaisgrey - I'm not too..." <- Oh, thanks! Your comment really helped out a lot, since now I know what I need for the project.
GenTooMan has joined #rust-embedded
<ian_rees[m]>
<thiskappaisgrey[> "Oh, thanks! Your comment..." <- Cool! Have you used Rust before this project?
<bpye>
Ah actually I think the issue with the hardware capture is that my sample rate is marginal for USB - I might give usbmon another try with Wireshark though, I have a linux device I can try on. I had tried before but at that point was failing pre set address which I apparently couldn't see in Wireshark
<ian_rees[m]>
yeah, USB is tricky. There's also a Rust USB room, not sure offhand if it has an IRC bridge https://matrix.to/#/#usb-rs:matrix.org
<bpye>
I do have a Matrix account as well - just never found a client I was a huge fan of...
eldruin[m] has quit [Quit: Idle timeout reached: 172800s]
nex8192 has left #rust-embedded [Error from remote client]
corecode[m] has joined #rust-embedded
<corecode[m]>
i am linking my embedded rust binary with a vendor lib and libc, etc. all of the C libraries are built in a cargo lib crate that the binary depends on. my problem is that without +whole-archive in cargo:rustc-link-lib= the link fails due to missing symbols (probably not in the right order?); but with +whole-archive, it links all objects, including those that are not needed, and then I run out of memory. I think i need a
<corecode[m]>
--start-group/--end-group around the library, but I don't know how to do that. Any ideas?
FreeKill[m] has joined #rust-embedded
<FreeKill[m]>
I'm surprised you run out of memory - I thought rust discarded unused sections by default
<corecode[m]>
but whole archive is passed to the linker
<FreeKill[m]>
Sure, but that's not a problem. The linker can discard things down to the resolution of single functions.
<FreeKill[m]>
I'm saying that from a C perspective, maybe things have different defaults in the rust link
<corecode[m]>
yea I think I need to use a group instead of whole archive
<FreeKill[m]>
Hm you may be right, I think I'd misunderstood the behaviour of whole archive.
<FreeKill[m]>
You can also link the library more than once, that's pretty standard for circular deps in C projects
<FreeKill[m]>
So if a and b mutually depend on each other you link with
<FreeKill[m]>
`-la -lb -la`. Maybe that's easier for you to make happen?
<corecode[m]>
I don't know how to tell the rust linker to link the crate library twice
nex8192 has joined #rust-embedded
<FreeKill[m]>
<corecode[m]> "I don't know how to tell the..." <- Did you say you have one single rust lib crate containing all of your native libs? I wonder if you made one crate per native lib and got the dependencies right in cargo, if it would just link it correctly
<corecode[m]>
it's one set of vendor object files which I pack into a static lib.
<FreeKill[m]>
Hmmmmmm if it's just object files then I'm not sure I know how it can end up missing symbols. Object file order doesn't matter right (?)
nex8192 has left #rust-embedded [Error from remote client]
IlPalazzo-ojiisa has quit [Remote host closed the connection]
<corecode[m]>
yes, object file order doesn't matter, they act like a --start-group --end-group around them
starblue has quit [Ping timeout: 246 seconds]
<FreeKill[m]>
So it seems very weird that you'd have missing symbols. Because the internal references in that archive should all sort themselves out
<corecode[m]>
ok i changed my build.rs for the binary and manually did a cargo:rustc-link-arg=-Wl,--start-group/-lmylib-sys/-Wl,--end-group
<corecode[m]>
no, static libs don't work that way
<corecode[m]>
you need to put start-group/end-group around them
<corecode[m]>
maybe i could add this as a GROUP() command to the linker script itself
<FreeKill[m]>
I didn't think start group and end group did anything unless the group contained more than one archive... But fair enough
<corecode[m]>
nono, it does
<corecode[m]>
you need a group for a static library if there are internal references
<FreeKill[m]>
Okay so I just wrote some simple C to check if that's the case and I'm fairly sure it's not
<FreeKill[m]>
If you have foo.c bar.c baz.c and they each call functions defined in one another
<FreeKill[m]>
you can put them all into a static library, then link against that library and build an executable no issue
<FreeKill[m]>
without a group
<corecode[m]>
hm, why is it happening then
<FreeKill[m]>
well indeed!
<corecode[m]>
oh it's a related but different problem
<corecode[m]>
there are several shared libraries
<corecode[m]>
s/shared/static/
<corecode[m]>
and they depend on each other
<corecode[m]>
so that's the thing: LIBS += $(GROUP_START) $(PROJECT_LIBS) $(GROUP_END)
starblue has joined #rust-embedded
<corecode[m]>
maybe i could build one big static library
<FreeKill[m]>
Yeah when it's lots of static libraries that's when you get the problem
<FreeKill[m]>
you could either put all the object files into one big library, or like I said you could try putting each static library into its own cargo project
<FreeKill[m]>
s/cargo project/crate/
<FreeKill[m]>
Then I expect cargo would correctly link it
<corecode[m]>
oh yea that worked, adding the other static libraries into one
<corecode[m]>
i just changed my line to $(ECHO)$(AR) rcsT $@ @$(OUTPUT_DIR)/linker_objs $(filter %.a, $(PROJECT_LIBS))
<corecode[m]>
add T to the command and add the filter part
<corecode[m]>
nice
029AAKWJ6 has joined #rust-embedded
<corecode[m]>
ah no this broke something, now my stack is nonexistent -_-
<FreeKill[m]>
why are you adding T? Is that thin archiving?
<corecode[m]>
yea it seems to unpack the archives inside
<corecode[m]>
yea somehow this doesn't work well
<FreeKill[m]>
I wouldnt presume you want a thin archive
<FreeKill[m]>
Though I dont know exactly how rust links them
<corecode[m]>
oh, now i know why i needed --whole-archive. because otherwise the vector table doesn't get linked
<corecode[m]>
no that's not right
<FreeKill[m]>
ah
<corecode[m]>
the stack doesn't get linked
<corecode[m]>
wat
<corecode[m]>
KEEP() time i guess
<FreeKill[m]>
Yes you absolutely need keep for the vector table, at least
<corecode[m]>
it's there, but there is no stack
<FreeKill[m]>
I'm only very well versed with cortex-M, is that what this is?
<FreeKill[m]>
And is your stack an actual array that you've defined somewhere, or is it just a symbol provided by the linker?
<corecode[m]>
cortex m33
029AAKWJ6 has quit [Quit: Leaving]
<corecode[m]>
i need to see how that vendor lib does it
<FreeKill[m]>
Generally, the stack is either a literal array linked into the final binary
<FreeKill[m]>
or it's just a symbol that's put sufficiently far into the RAM
leon_on9527 has joined #rust-embedded
leon_on9527 has quit [Remote host closed the connection]
<corecode[m]>
KEEP(*(.stack*))
<corecode[m]>
. = ALIGN(4);
<corecode[m]>
__StackTop = .;
<corecode[m]>
there is my __StackTop symbol -_-
<corecode[m]>
why doesn't this keep the stack tho
<FreeKill[m]>
What do you mean by "keep the stack"
<FreeKill[m]>
what is missing?
<corecode[m]>
without whole-archive, it seems that the linker just discards the object file with the stack section
<FreeKill[m]>
And you think that because you've looked at the linker map?
<FreeKill[m]>
And seen that the section is discarded?
<corecode[m]>
the object member of the archive isn't even mentioned
<FreeKill[m]>
isn't even mentioned?
dhylands[m] has joined #rust-embedded
<dhylands[m]>
If you put a LONG(0) I think that prevents the linker from discarding it
<FreeKill[m]>
Well the linker isn't discarding it if its not even mentioned in the map, right
<corecode[m]>
FreeKill: not even mentioned
<FreeKill[m]>
that means it's just never a candidate for the link
<corecode[m]>
so do i need whole-archive, and maybe the vendor library makes everything already overflow?
<corecode[m]>
i mean, what else is it not linking
<dhylands[m]>
Normally the startup code references a symbol in the stack section (at least in C land)
<FreeKill[m]>
I do not think you should need whole-archive
<FreeKill[m]>
dhylands[m]: In this case it probably references __Stacktop
<corecode[m]>
the vector references __StackTop, but that's created in the linker script
<dhylands[m]>
Usually it’s the other end of the stack, since that’s what the stack pointer gets initialize to.
<FreeKill[m]>
Wow you're right, objects that don't provide needed symbols are discarded
<corecode[m]>
that's why they put that KEEP there
<corecode[m]>
why it doesn't work for archives is beyond me
<FreeKill[m]>
because
<FreeKill[m]>
KEEP works once a symbol is in the link
<FreeKill[m]>
But without whole-archive, it seems that an object file that contains no required definitions (IE doesnt provide unresolved symbols) /doesn't even make it into the link/
<dhylands[m]>
FreeKill[m]: That sounds like “expected” linker behaviour
<FreeKill[m]>
So perhaps you do need --whole-archive. But in that case I would hope that --gc-sections would still work
<FreeKill[m]>
IE "include it all in the link, but still discard stuff that's not reachable or explicitly kept"
<corecode[m]>
maybe their code is so bad that it uses all the memory by default
<FreeKill[m]>
alternatively what you could do, is provide an undefined symbol to the linker
<FreeKill[m]>
which i think is -U ?
<FreeKill[m]>
That it will find in the object library that is currently being discarded. That will make sure it gets into the link
<dhylands[m]>
In my C based linker scripts I give my stack section a minimum size so that I get a linker error if I run out of space including my minimum sized stack
<FreeKill[m]>
dhylands[m]: This is also what I do
<FreeKill[m]>
FreeKill[m]: Yeah `-u`
<corecode[m]>
what is -u?
<FreeKill[m]>
It injects an undefined symbol into the link
<FreeKill[m]>
So lets say your stack.o file defines uin8_t lovely_stack[1024];
<FreeKill[m]>
But currently that .o file is being discarded because it isn't required to resolve any undefined symbols
<dhylands[m]>
From the GNU linker docs: https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html Pretend the symbol symbol is undefined, to force linking of library modules to define it. You can use -u multiple times with different symbols to force loading of additional library modules.
<FreeKill[m]>
You can add -ulovely_stack to the args and it will then say "Well I need to find an object file somewhere that provides lovely_stack"
<corecode[m]>
is it possible that the vendor libraries are using 14KB just without anything else?
<FreeKill[m]>
Yes, easily
<corecode[m]>
for a 16KB part?
<corecode[m]>
uhg rough
<FreeKill[m]>
Oh. then probably not
<dhylands[m]>
If you produce a linker map, you can see how much is being used from a successful link.
<corecode[m]>
ah no it is a 32KB part
<corecode[m]>
where is my memory being squandered?
<corecode[m]>
yea i'm looking at the map
<FreeKill[m]>
puncover is a fun tool for this
<dhylands[m]>
I think cargo bloat can help there as well
<FreeKill[m]>
14K for vendor bits n bobs is not wild though. Printf implementations can easily be ~6-10K on their own depending on what they implement!
<corecode[m]>
cargo bloat seems to operate only on text?
<corecode[m]>
oh the 14KB are RAM, not flash
nex8192 has joined #rust-embedded
GenTooMan has quit [Ping timeout: 246 seconds]
GenTooMan has joined #rust-embedded
GenTooMan has quit [Excess Flood]
GenTooMan has joined #rust-embedded
<corecode[m]>
yea it's the vendor config/code. maybe they expect you to use mostly heap?
<FreeKill[m]>
Why would heap help?
<corecode[m]>
because there is a lot of memory reserved for heap
<corecode[m]>
hey, i wouldn't have designed it that way
<FreeKill[m]>
Presumably you can change that in the linker script?
<corecode[m]>
yea but it looks like the rest of the system uses almost all that memory -_-
<corecode[m]>
vendor code, gah
<FreeKill[m]>
The rest of the system uses a huge heap allocation?!??
<corecode[m]>
i saw >7KB being allocated
<corecode[m]>
in buffers and thread stacks
<corecode[m]>
oh man what a bummer
<FreeKill[m]>
Well okay that's not completely insane...
<corecode[m]>
so maybe i'll have 4KB to myself
<FreeKill[m]>
Does that task stack include the user task?
<corecode[m]>
those 7KB are in addition to the 14KB the system uses statically
<corecode[m]>
don't get me started on user stack -_-
<corecode[m]>
their OSInit() requires a separate kernel scheduler/interrupt stack
<corecode[m]>
and it lets the initial reset stack just lay there
<corecode[m]>
never to be used again
<FreeKill[m]>
That's a very bizarre choice
<corecode[m]>
yes
<corecode[m]>
silabs micrium
<corecode[m]>
can fix it only by changing their code
<FreeKill[m]>
Is it doing a lot of protocol stuff or something?
<FreeKill[m]>
BT, TCP?
<corecode[m]>
ble and proprietary RF
<FreeKill[m]>
Eh then 7k of heap allocation isn't absurd
<FreeKill[m]>
Still it's hard to imagine implementing much application code in 4k of ram
<corecode[m]>
yea it's bizarre
likewise[m] has quit [Quit: Idle timeout reached: 172800s]
nex8192 has left #rust-embedded [Error from remote client]
<corecode[m]>
is there a trick to accessing rust types in embedded gdb?
<corecode[m]>
they're all mangled
alianunnaki[m] has quit [Quit: Idle timeout reached: 172800s]