IlPalazzo-ojiisa has quit [Ping timeout: 248 seconds]
crabbedhaloablut has joined #rust-embedded
RobertJrdens[m] has quit [Quit: Idle timeout reached: 172800s]
Socke has quit [Quit: WeeChat 3.8]
Socke has joined #rust-embedded
Socke has quit [Client Quit]
ni has quit [Remote host closed the connection]
ni has joined #rust-embedded
Guest7221 has joined #rust-embedded
Socke has joined #rust-embedded
IsaBang[m] has quit [Quit: Idle timeout reached: 172800s]
<ryan-summers[m]>
Is it possible for a USB serial device to detect when it gets opened on the PC side? Can only imagine yes, but not sure how
<ryan-summers[m]>
I want to trigger a user menu to get printed when the serial port gets opened, but detecting entrance to the Configured state doesn't seem to be it, that just detects hot-plugging
<dirbaio[m]>
linux sets DTR on port open, clears it on close
<dirbaio[m]>
Windows doesn't, at least not with the serialport crate. not sure if serial terminal programs like putty do
<dirbaio[m]>
I don't think it's doable in the general case
<ryan-summers[m]>
Eh that's probably good enough, thanks for the suggestion
Guest7221 has left #rust-embedded [Error from remote client]
<dirbaio[m]>
maybe you can print menu when dtr goes low->high so you get good UX in the OSs/programs that do, and print menu again when user presses some key as a fallback
<ryan-summers[m]>
Yeah that's the plan. In any case a user probably is going to mash enter if things are weird and that will show them the prompt
<ryan-summers[m]>
Trying to use thejpster 's menu crate for this. It's a nice replacement for my homebrew impl
<ryan-summers[m]>
Hmm even using python -m serial COM14 --dtr 1 didn't seem to make it trigger properly...
<ryan-summers[m]>
Meh I may fuss with this later, thanks for the input, that seems like the right general path
Guest7221 has joined #rust-embedded
<Lumpio->
I really wish there was a way to have like a end-user usable configuration interface for a device over USB
<Lumpio->
Given how things work these days it'd probably have to be a web server or something...
<Lumpio->
There's technically WebUSB but it requires an internet server which may eventually die, and some absolute mad lads have ran an Ethernet over USB interface just to run a config interface
<Lumpio->
For programmer type people a serial config interface is probably the next best thing
<ryan-summers[m]>
Yeah you read well into what I need. But the USB is used more than just for config in this. Also used for maintaining service info and/or device reset / reset to DFU
<ryan-summers[m]>
Trying to figure out a generic way to make it usable across devices
<Lumpio->
Yeah of course it wouldn't take over the entire USB bus
<Lumpio->
I was thinking of something like a descriptor that advertises "hey I have a config interface" and then you could do HTTP over control transfers or something dumb like that
<Lumpio->
I mean it would be web, meh, but what else can do a cross platform user interface these days...
<Lumpio->
I mean _technically_ it would be possible to do that with WebUSB, and then have like a single HTML page that can be used for any device incase the URL it points to is dead
<Lumpio->
hmm
<tamme[m]>
I wonder if you could provide that HTML file by emulating mass storage over USB to give the user the HTML file, so you could still use it even when the "big server" is no longer available
<Lumpio->
Potentially
<Lumpio->
Not sure if browsers let you do WebUSB from file:// URLs
andres[m] has quit [Quit: Idle timeout reached: 172800s]
<Lumpio->
From what I remember the binaries are there because inline assembly is (was?) not in stable
<dirbaio[m]>
yep, that was the reason
<dirbaio[m]>
and inline asm is stable now, and latest cortex-m already doesn't use prebuilts
<jannic[m]>
Yes, I noticed. Not yet released though, right?
<dirbaio[m]>
cortex-m-rt v0.7.2, released november 2022
<jannic[m]>
Ah sorry - it was an old Cargo.lock pointing to cortex-m-rt v0.7.1, in combination with the repository link on crates.io pointing to cortex-m (not cortex-m-rt), and me clicking too quickly on CHANGELOG.md without noticing the cortex-m-rt subdirectory. And the cortex-m changelog lists "Inline assembly is now always used, requiring Rust 1.59." as an unreleased change, so I draw the wrong conclustions.
<jannic[m]>
* I get failures with `defmt-test` based test cases when using probe-rs instead of probe-run. It first prints `all tests passed!`, but followed by a stack trace and `Error: CPU halted unexpectedly.`, `error: test failed, to rerun pass \`--test dma\_m2m\_u8\``. Do I need to change more than just replacing `probe-run` by `probe-rs run`?
<jannic[m]>
* I get failures with defmt-test based test cases when using probe-rs instead of probe-run. It first prints all tests passed!, but followed by a stack trace and Error: CPU halted unexpectedly., error: test failed, to rerun pass \--test dma_m2m_u8`. Do I need to change more than just replacing probe-runbyprobe-rs run` ?
<jannic[m]>
(And I hate error messages containing backticks :-) )
IlPalazzo-ojiisa has quit [Remote host closed the connection]
<firefrommoonligh>
What does this mean for a knurling-app-template workflow?
<firefrommoonligh>
I lean pretty heavily on it
<firefrommoonligh>
I guess the Migration Steps has some info
Foxyloxy has joined #rust-embedded
<JamesMunns[m]>
firefrommoonligh: IMO if they haven't changed the app template to use probe-rs, I'd guess they'd appreciate a PR to change it
<firefrommoonligh>
Can I just keep up business as usual?
<firefrommoonligh>
This has been a rock-solid foundation
<firefrommoonligh>
Where I'm not like "Oh great looking forward to new features!" more like it's great as is so I'm anxious about changes
JonathanDickinso has quit [Quit: Idle timeout reached: 172800s]
therealprof[m] has quit [Quit: Idle timeout reached: 172800s]
<firefrommoonligh>
I do like the idea of getting rid of thin wrappers in favor of using the underlying tool. Ie if there's an issue, I'm not confused about which to look at. Probably generates false positives for the tool maintainers too, ie issues that are really for the other tool
<firefrommoonligh>
We'll see
<firefrommoonligh>
So, it looks like it's just one per-project line change, and one per-system one?
IlPalazzo-ojiisa has joined #rust-embedded
<firefrommoonligh>
s/?/./
Farooq has quit [Quit: Idle timeout reached: 172800s]
kenny has quit [Ping timeout: 255 seconds]
kenny has joined #rust-embedded
sourcebox[m] has joined #rust-embedded
<sourcebox[m]>
Regarding probe-rs, could this also be used with C/C++ project or does it rely on some specific code layout used by Rust?
<sourcebox[m]>
s/project/projects/
<sourcebox[m]>
I remember that I tried it long ago with some C++ project and it didn't work. Don't ask me about details.
<Urhengulas[m]>
jannic: I will look into the defmt-test problem
_whitelogger has joined #rust-embedded
Noah[m] has joined #rust-embedded
<Noah[m]>
<sourcebox[m]> "Regarding probe-rs, could this..." <- probe-rs itself is 100% agnostic :)
<sourcebox[m]>
That sounds good. defmt obviously will not work then. With RTT, is there some requirement for the control block to be placed?
<Noah[m]>
sourcebox[m]: no, if you name the symbol correctly(according to RTT spec (I think its just SEGGER_RTT)) probe-rs will be able to find it :)
<sourcebox[m]>
Ok, I think I remember what wasn't working as a tried it a while ago: I flashed a firmware along an already present bootloader. But then the bootloader was also erased.
<Noah[m]>
sourcebox[m]: there is a flag to restore existing bytes if it has to erase a sector of the bootloader (should not happen tho if your ELF is correct)
<sourcebox[m]>
I have to try it again, there's a good chance that's now working.
dav1d has joined #rust-embedded
<JamesMunns[m]>
<Noah[m]> "no, if you name the symbol..." <- I still think you should use a different magic value, like `PROBEDOTRS` just to avoid potential legal shenanigans
<JamesMunns[m]>
and leave a back door that allows users to replace the string if they want in case they need compat with Segger tools or whatever.
duderonomy has joined #rust-embedded
<Noah[m]>
probably. I wonder how openocd is doing this. generally I am not afraid of someone patenting two ringbuffers, especially not when im in europe. ofc here is a company name involved so thats a bit different. we can def investigate what our options are wrt changing this :)
<JamesMunns[m]>
yeah IMO this "smells like" using a trademark to get around compat issues, like the nintendo logo check on a gameboy cart.
<JamesMunns[m]>
(the hardware loads the nintendo boot image, and refuses to boot if the checksum of the image isn't right, but if you include that image in a custom cart its trademark infringement). No idea if that approach has been legal'd away in practice :D
<dirbaio[m]>
there's precedent from the nintendo logo stuff that you can't "abuse" trademark law like that to control technical interoperability
<dirbaio[m]>
so there's no point in changing the header magic string
<dirbaio[m]>
that string isn't even shown to users at all, so it's even more debatable that it's subject to trademarks at all
<dirbaio[m]>
that's why the gameboy showed the nintendo logo from the cart on-screen, so they could accuse unlicensed makers of falsely telling the user that their product is a nintendo product
<thejpster[m]>
See also the Sega Trade Mark Security System - although that actually puts the logo on the TV.
<FlixtheNewbie[m]>
I'm using `usb-device` to create a keyboard firmware. The keyboard works correctly (I'm typing with it rn) but for some reason, when I try and use `usbhid-dump` to debug the reports, the tool fails to do it. I don't know how to spot the mistake I wrote in the code. Any advice?
<FlixtheNewbie[m]>
I think that an example using this crate could help me.
<sourcebox[m]>
Segger wants to sell the J-Link and other tools. To make them work, the user code has to use that specific magic number. It would be completely stupid to take legal action against the use.
WSalmon has quit [Remote host closed the connection]
GenTooMan has joined #rust-embedded
WSalmon has joined #rust-embedded
<dirbaio[m]>
atomic-polyfill just doesn't want to die 🥲
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded
<dirbaio[m]>
I could file a "this crate is unmaintained" in these security advisory database things and watch the world burn lol
<Urhengulas[m]>
jannic: I just released `defmt-test v0.3.1` which fixes the issue. Thank you for discovering it.
<dirbaio[m]>
it somehow made its way as a dep to once-cell lol
<sourcebox[m]>
But even static_cell is dependent on it.
<dirbaio[m]>
ah yeah I should update it
<FlixtheNewbie[m]>
<FlixtheNewbie[m]> "I'm using `usb-device` to create..." <- > <@boiethios:matrix.org> I'm using `usb-device` to create a keyboard firmware. The keyboard works correctly (I'm typing with it rn) but for some reason, when I try and use `usbhid-dump` to debug the reports, the tool fails to do it. I don't know how to spot the mistake I wrote in the code. Any advice?
<FlixtheNewbie[m]>
> I think that an example using this crate could help me.
<JamesMunns[m]>
just a guess, does the usbhid-dump tool hit this path, or some other "edge case" path, that causes it to lock up by not accepting the request or something?
<JamesMunns[m]>
Are you still using a board where you don't have a debugger attached?
<FlixtheNewbie[m]>
Yes, you remember me? :D I moved to a different country, a different job, etc. so I couldn't pursue my project for 6 months, but you still remember the detail.
<FlixtheNewbie[m]>
I can debug with LEDs, though, so I'll follow your lead. Thanks for the help
<FlixtheNewbie[m]>
I wasn't IDLE, though, I wrote a full hardware-agnostic library to write keyboard firmwares, and I'll publish the first alpha soon
<FlixtheNewbie[m]>
s/IDLE/idle/
<JamesMunns[m]>
I remember a weird assortment of things. Rarely things that really help, but an odd collection of details :)
<JamesMunns[m]>
But yeah, I'd PROBABLY guess that you're hitting some edge case. IMO using `todo!()` or other panic macros are a good idea for this, so things "fail loudly". Especially early in the dev process.
<FlixtheNewbie[m]>
My wife is like that, she remember dates. She remember the birthday of random people she met 10 years ago
<JamesMunns[m]>
Yeah, never names and dates for me. Intricate details of some protocol, or spec, or debugging steps I made 10 years ago? Crystal clear.
<FlixtheNewbie[m]>
That's actually useful
<FlixtheNewbie[m]>
JamesMunns[m]: Hm, but do I want to panic when I don't match one of those patterns? I'm not sure. The host could ask something I'm not interested in
<JamesMunns[m]>
Just my $0.02. At least then YOU'RE the one that trips over the panic and notices it early. You can always figure out what it did and add "ignore" branches for things you care about.
<FlixtheNewbie[m]>
I then need to turn some LEDs on or something to show that I went a wrong path
<JamesMunns[m]>
But yeah, I usually add pretty aggressive panics/asserts early in the dev process, so you DO hit the weird cases, or know what or what isn't actually weird, instead of silently dropping some thing
<dirbaio[m]>
no, you need to get a debug probe 😅
<JamesMunns[m]>
FlixtheNewbie[m]: A UART or a debugger would make this a lot easier, yeah :D
<JamesMunns[m]>
Or, write a panic handler that prints the file + line in morse code, I guess :)
<FlixtheNewbie[m]>
I opened the keyboard case, but the debugging pins are not accessible directly, and I don't want to break the board
<JamesMunns[m]>
JamesMunns[m]: (this wasn't a joke, btw, I've done something about like this before)
<dirbaio[m]>
emit the panic message in smoke signals, turning on and off the magic smoke valve
<JamesMunns[m]>
FlixtheNewbie[m]: It's also pretty common to use a dev board for early dev, so you can access these things
<JamesMunns[m]>
can't test everything, but if the dev board has USB and one button, you could make a pretty good "usb and one key" test rig.
<JamesMunns[m]>
or: it's pretty possible to show up as a USB keyboard AND a serial port over one USB connection (with two endpoints), and then you have a way of printing that you could shove data out of when you panic.
<FlixtheNewbie[m]>
It's a commercial keyboard that I paid for a high price.
<FlixtheNewbie[m]>
I'm building my own keyboard, that I'll be able to debug correctly, but I'm extremely bad with a soldering iron, so I still couldn't figure out where the short is
<JamesMunns[m]>
FlixtheNewbie[m]: > <@boiethios:matrix.org> It's a commercial keyboard that I paid for a high price.
<JamesMunns[m]>
> I'm building my own keyboard, that I'll be able to debug correctly, but I'm extremely bad with a soldering iron, so I still couldn't figure out where the short is
<JamesMunns[m]>
yeah, I meant "buy a second dev board with the same main CPU"
<FlixtheNewbie[m]>
JamesMunns[m]: Oh, that's a good idea :D
<JamesMunns[m]>
like some STM32Fxxx Nucleo board or something
<dirbaio[m]>
trying to keep usb alive on panic is hard tho
<dirbaio[m]>
usb logging works great, except when you pnaic
<dirbaio[m]>
s/pnaic/panic, which is when you need it the most/
<JamesMunns[m]>
dirbaio[m]: yeah, agreed. You could log and not panic tho
<FlixtheNewbie[m]>
dirbaio[m]: I can just print something before the panic, or do it in the panic handler
<JamesMunns[m]>
FlixtheNewbie[m]: yeah, the issue is servicing the USB interrupts while panicking
<JamesMunns[m]>
it's... sketch to do.
<dirbaio[m]>
yea
<dirbaio[m]>
just enqueuing the data won't do it, you need to actually service the usb interrupts/polling for it to get sent
<JamesMunns[m]>
but, still, you could do something like:
<JamesMunns[m]>
* enqueue a serial log message
<JamesMunns[m]>
* stop petting the watchdog/start a timer to panic in 10s or something
<JamesMunns[m]>
(I'm giving vague "it depends" advice, I'd probably personally suggest "debug the usb stuff on a nucleo dev board" as my preferred option)
<FlixtheNewbie[m]>
As said earlier, I don't even need to panic, I can just log that I went an unexpected branch
<JamesMunns[m]>
IF that unexpected branch doesn't make your whole USB stack lock up :)
<FlixtheNewbie[m]>
That's not the case: the keyboard works correctly. It's something non fatal happening.
<JamesMunns[m]>
Cool! Then it seems like that is still an option then :)
<jannic[m]>
<Urhengulas[m]> "jannic: I just released `defmt-..." <- Just tried it out, the fixed version works for me. Thank you!
<sourcebox[m]>
If you already have a working keyboard, then let it just type the log message ;-)
wassasin[m] has quit [Quit: Idle timeout reached: 172800s]
WSalmon has quit [Ping timeout: 240 seconds]
<FlixtheNewbie[m]>
James Munns: You were right, I hit the match's empty branch. Now I just need to understand what that means exactly, and I'm good.
WSalmon has joined #rust-embedded
<FlixtheNewbie[m]>
Do you have an example of a serial communication? I remember there were a repo with examples
FreeKill[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]>
<FlixtheNewbie[m]> "Do you have an example of a..." <- Not off the top of my head that does two endpoints. Otherwise there was a cdc-acm crate somewhere.
<FlixtheNewbie[m]>
Well, I may not need it anyway, I think I'll just get rid of some check (I have one report descriptor, so no need to check the device, interface, etc.)
<JamesMunns[m]>
I mean, my guess is that the stack EXPECTS you to either ACK or NAK a request (or accept or refuse it or something), and you did nothing :D
<JamesMunns[m]>
you PROBABLY don't want to respond with keyboard (or whatever) data if that's not what the host asked for
<JamesMunns[m]>
Just a guess tho.
<dav1d>
What's the equivalent to pinMode(.., OUTPUT) digitalWrite(.., HIGH); in Rust with the esp32-hal?
<dav1d>
ah nvm
<dav1d>
my problem is I was setting it to high instead of low
Guest7221 has left #rust-embedded [Error from remote client]
vollbrecht[m] has quit [Quit: Idle timeout reached: 172800s]