ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
IlPalazzo-ojiisa has quit [Quit: Leaving.]
dc740 has quit [Remote host closed the connection]
starblue1 has quit [Ping timeout: 252 seconds]
starblue1 has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
<wes_> Lumpio-: i've got a 'custom' usb device up and running. awesome. i'm thrilled. i've been fumbling around a little trying to add a cdc-acm interface. i took your advice and copied the iface, endpt, descriptors of the CdcAcmClass struct in cdc_acm.rs. is there a way that i can use this struct directly (ie use it's new() method) instead of having to copy the interface, endpoint creation to my
<wes_> own TestClass::new() method?
<wes_> oh forgot to mention. with my hacky approach of copying over all of the interface and enpoint allocations, my host system does recognize and load the cdc-acm drivers for my device. so it is working. i'm just looking for a cleaner way to accomplish the same thing. like reusing existing code instead of copying the logic to my program like an ape.
DepthDeluxe has joined #rust-embedded
DepthDeluxe_ has joined #rust-embedded
DepthDeluxe has quit [Ping timeout: 255 seconds]
<Lumpio-> wes_: Rust doesn't really allow "inheritance" so it takes some manual work, bub it's possible to have an usbd_serial::CdcAcmClass instance as a field in your own class, and delegate methods calls that you don't have to it.
<Lumpio-> but*
<Lumpio-> I think I was thinking of an "UsbClassWrapper" type at some point that would delegate automatically
<wes_> Lumpio-: ah, okay. it definitely felt like i needed to do some manual implementation, but i also felt like i was reinventing the wheel a little too much. thanks for the tip. i'll see about adding an instance of usbd_serial::CdcAcmClass to my TestClass
DepthDeluxe_ has quit [Ping timeout: 252 seconds]
DepthDeluxe_ has joined #rust-embedded
DepthDeluxe__ has joined #rust-embedded
DepthDeluxe_ has quit [Ping timeout: 260 seconds]
seer has quit [Quit: quit]
seer has joined #rust-embedded
IlPalazzo-ojiisa has quit [Remote host closed the connection]
<re_irc> < (@ubik:matrix.org)> anyone know what would be the newest firmware for an STM32F103C8T6-based CMSIS-DAP probe? I can only find this (https://github.com/wuxx/nanoDAP/tree/master/firmware/v2.3/CMSIS-DAP)
<re_irc> < (@ubik:matrix.org)> * knows
<re_irc> < (@9names:matrix.org)> assuming your c8t6's actually have 128KB of flash, you could install the latest release of upstream daplink
<re_irc> < (@9names:matrix.org)> or build it yourself, of course
<re_irc> < (@ubik:matrix.org)> nope, only 64kb
<re_irc> < (@ubik:matrix.org)> i tried to install that already, but it seems to be meant for 128kb probes
<re_irc> < (@9names:matrix.org)> i know they only report as having 64KB, but they often(always?) have 128KB on board, if you tell the tools to ignore the size it often works Just Fine™
<re_irc> < (@9names:matrix.org)> you can probably get daplink to fit in 64KB anyway, it's the UF2 bootloader that takes up most of the space
<re_irc> < (@ubik:matrix.org)> the chip datasheet says 64kb
<re_irc> < (@9names:matrix.org)> the chip datasheet is a lie
<re_irc> < (@ubik:matrix.org)> and flashing it fails
<re_irc> < (@9names:matrix.org)> okay :)
<re_irc> < (@ubik:matrix.org)> plus, DAPlink sources only mention stm32f103xb, not stm32f103x8
<re_irc> < (@ubik:matrix.org)> unless the only difference between those two is the size of the flash
<re_irc> < (@9names:matrix.org)> that is the only difference, yes
<re_irc> < (@ubik:matrix.org)> ok... and do you happen to know how I can disable UF2 in the firmware? can't find any config flags
<re_irc> < (@ubik:matrix.org)> oh, maybe in "projects.yaml"?
<re_irc> < (@9names:matrix.org)> you would probably want to replace the original bootloader with something that only jumps to the debug firmware.
<re_irc> or set up the debug firmware to be placed at the start address and maybe adjust the init code to match.
<re_irc> < (@9names:matrix.org)> might be easier to use something like https://github.com/devanlai/dap42 though
<re_irc> < (@ubik:matrix.org)> that's a but old, though
<re_irc> < (@ubik:matrix.org)> * bit
<re_irc> < (@9names:matrix.org)> very. it's only cmsis-dap v1, pretty slow but it works.
<re_irc> < (@9names:matrix.org)> *on my machine
<re_irc> < (@ubik:matrix.org)> i had tried flashing a 48k version of daplink I found somewhere but the probe wouldn't be detected by the computer and there would be a red LED blinking
<re_irc> < (@ubik:matrix.org)> : this doesn't seem to work either
<re_irc> < (@9names:matrix.org)> maybe your macos is cursed? 🤷
<re_irc> < (@ubik:matrix.org)> possible
<re_irc> < (@ubik:matrix.org)> but in this case the probe isn't detected
<re_irc> < (@ubik:matrix.org)> with the default firmware, at least it's detected
<re_irc> < (@ubik:matrix.org)> plus, i can use the picoprobe just fine
<re_irc> < (@9names:matrix.org)> so... why are we going to all this effort if you've already got a working probe?
<re_irc> < (@ubik:matrix.org)> because I'd like to program the pico, not use it as a probe :)