<t-moe[m]>
I'm pretty sure there must be a solution with `global_asm!`. Because as soon as I add a `use esp_hal::prelude::*` to my code, without adding the linkerfile `linkall.x`, the linking will fail because of the missing exception handlers.
<t-moe[m]>
I need something similar. A nice big linking error, preferably with a symbol name I control ( `undefinde reference to _please_add_those_damn_linkerfiles` ) ;)
<t-moe[m]>
* I'm pretty sure there must be a solution with `global_asm!`. Because as soon as I add a `use esp_hal::prelude::*` to my code, without adding the linkerfile `linkall.x`, the linking will fail because of the missing exception handlers.
<t-moe[m]>
I need something similar. A nice big linker error, preferably with a symbol name I control ( `undefined reference to _please_add_those_damn_linkerfiles` ) 🤪
<diondokter[m]>
The reset vector is force kept, and then it will reference main in a normal embedded application. So the linker sees that main is used through the reset vector
Kaspar[m] has quit [Quit: Idle timeout reached: 172800s]
M9names[m] has quit [Quit: Idle timeout reached: 172800s]
<t-moe[m]>
<diondokter[m]> "You may need to stick this in a..." <- Yes, I use KEEP already in my linker script (embedded-test.x). But the problem arises when the user does NOT include my linker script....
<t-moe[m]>
Not sure why the linker decides to discard main.... 🤔
<JamesMunns[m]>
<diondokter[m]> "You may need to stick this in a..." <- specifically, I think you use `no_main`, which means "main" is not special, only `_start` (IIRC?) is. Main is only special "by convention".
<JamesMunns[m]>
<diondokter[m]> "You may need to stick this in a..." <- also also you might need to make it `pub extern "C" fn ...` for it to be kept, I forget all the heuristics that go into this.
<jannic[m]>
The question how to show a meaningful error message if the user forgot the linker script is still unsolved AFAIK.
<AshconMohseninia>
question, I'm using usb-device to implement my first class. I see this in Windows, it appears Windows asks the USB device for iSerialNumber (Index 2 in my case), but the device never replies. I checked that my classes get_string function is infact never called. I set the Serial number of the device in the UsbDevice strings function
<AshconMohseninia>
Windows is asking for any Language ID (0x00) for the descriptors, I'm using StringDescriptors::default().manufacture("xxx").product("yyy").serial_number("zzz"). So why could my device not be replying
AdamHorden has joined #rust-embedded
<jason-kairos[m]>
suppose you wanted to have a function that you could trigger when the debugger is attached (ie. the function only exists for that purpose)
<jason-kairos[m]>
is there a good reliable way of doing that?
<jason-kairos[m]>
I guess something like what rtt does, special memory regions that get polled by the program periodically?
<jason-kairos[m]>
(in my case, the function I want to run is "turn on the serial port part of the program so that I can send it factory configuration commands after it has already been configured")
AdamHorden has quit [Quit: Adam Horden | adam.horden.me]
AdamHorden has joined #rust-embedded
Lumpio[m] has joined #rust-embedded
<Lumpio[m]>
Ashcon Mohseninia (RAND_ASH) Language ID 0 means "return list of supported languages", not "any language ID". The standard istrings (manufacturer/product/serial_number) are directly handled by UsbDevice so your class doesn't see the requests for those via get_string (they're part of the "device", not the class)
<diondokter[m]>
But I don't know if it's 100% reliable
<jason-kairos[m]>
if I recall correctly, the reabability of C_DEBUGEN might be implementation defined, and not readable on STM32. (there was a long comment in the hubris OS kernel bemoaning the unreadability of the debug registers)
<jason-kairos[m]>
* if I recall correctly, the reabability of C_DEBUGEN might be implementation defined, and not readable on STM32. (there was a long comment in the hubris OS kernel bemoaning the unreadability of the debug registers on the particular CPU they targeted)
<diondokter[m]>
You could actively set a bool to true using the debugger. In the firmware you would poll it
<diondokter[m]>
Well, maybe just set a number to not 0. That's less UB-prone :)
<vollbrecht[m]>
instead of polling you could also just sprincle in checks to "enable" that feature, e.g when you run __start, and maybe in your panic handler. That would i think cover most of it, while not have any big overhead.
<JamesMunns[m]>
Fun fact, if you set your `DEFMT_LOG` level to "INFO" and not "info", it'll just not print anything
dngrs[m] has joined #rust-embedded
<dngrs[m]>
capital letters were a mistake
<thejpster[m]>
I’ll take a PR to reject it at compile time
<vollbrecht[m]>
in rust code i today hat something similar, though the compiler was "smart enough".
<vollbrecht[m]>
E.g have a Enum that contains a `Error` variant. Than have a impl with a associated type Error that also uses Self::Error return types; So your return type colides with the enum variant type.
<JamesMunns[m]>
JamesMunns[m]: oh no CI is failing because the new stable has new clippy lints 🙃
<thejpster[m]>
Apparently you can just tell clippy to not do that