<re_irc>
<@xabra:matrix.org> I am using serde-json-core.
<re_irc>
serde = { version = "1.0.145", default-features = false, features = ["derive"] }
<re_irc>
serde-json-core = "0.4.0"
<re_irc>
The docs for 0.4.0 and 0.5.0 do not include floats in the list of current features, but it seems to work. Am I misunderstanding something or do docs need updating?
<re_irc>
<@jamesmunns:beeper.com> Got it! Are you comfortable editing markdown? Since those are the "top level" docs, they typically come from the "lib.rs" file for the crate. You can find a link to the crate from the top menu of that page you linked. Where it says "serde-json-core" (with a box logo), there's a "repository" link
<re_irc>
<@jamesmunns:beeper.com> Do you have a github account?
<re_irc>
<@xabra:matrix.org> Github, yes. Markdown, yes. GIve me a little time to read what you sent and see if i can figure it out
<re_irc>
<@jamesmunns:beeper.com> From there, you can either edit it online (there's a pencil icon on the top right of the source, that will open up an editor), or you can fork the repo, clone it locally, make + commit your changes, push it back to your fork, and open a PR.
<re_irc>
<@jamesmunns:beeper.com> If you get stuck, feel free to ask again here! Lots of folks can help :)
<re_irc>
<@xabra:matrix.org> OK, thank you. Chance for me to learn something new.
<re_irc>
<@jamesmunns:beeper.com> Yeah! Perfect opportunity. Thanks for helping out!
fabic has joined #rust-embedded
IlPalazzo-ojiisa has quit [Remote host closed the connection]
bjc has quit [Remote host closed the connection]
fabic has quit [Ping timeout: 246 seconds]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 260 seconds]
fooker has quit [Ping timeout: 252 seconds]
fooker has joined #rust-embedded
fooker has quit [Ping timeout: 252 seconds]
fabic has joined #rust-embedded
fooker has joined #rust-embedded
rardiol has joined #rust-embedded
bjc has joined #rust-embedded
starblue has quit [Ping timeout: 250 seconds]
starblue has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc>
<@2:0x2c.org> heh, with this gecko SDK and RTOS, the initial stack is not used after the kernel starts. what a waste of memory
dreamcat4 has quit [Ping timeout: 250 seconds]
dreamcat4 has joined #rust-embedded
dnm_ has quit [Ping timeout: 250 seconds]
dnm_ has joined #rust-embedded
emerent has quit [Ping timeout: 246 seconds]
emerent has joined #rust-embedded
<re_irc>
<@yatekii:matrix.org> Is it ok to make a for profit announcement here? :/
<re_irc>
<@jamesmunns:beeper.com> Yep! Occasional announcements are allowed :D
<re_irc>
<@jamesmunns:beeper.com> Not that one, I've seen some work with the pine time, which might be roughly similar. Embassy should work with that, and you can use the softdevice for BLE
<re_irc>
<@yatekii:matrix.org> Okay, valued Rust embedded community, here it comes:
<re_irc>
and I are building factory tooling at https://forged.dev. Over the past year we have set out to build a service & factory client to automatically provision your devices. You design & engineer a cool device including firmware but struggle to automate your factory process? We've got you covered :)
<re_irc>
If you have feedback, ideas or would be interested in using it, please come talk to us :)
<re_irc>
<@thejpster:matrix.org> Neat!
<re_irc>
<@thejpster:matrix.org> I wrote some Python to drive an Mplab icd and the factory was go grateful because they were using an xp machine with custom software that needed four mouse clicks to program each board on the panel
<re_irc>
<@thejpster:matrix.org> * so
<re_irc>
<@thejpster:matrix.org> This was like, two years ago.
<re_irc>
<@ryan-summers:matrix.org> Yeah, have dealt with those kind of shenanigans _far_ too often for a lot of my clients
<re_irc>
<@yatekii:matrix.org> Yup same here, I had to build this for https://zigfred.ch for our factory lines :)
genpaku has quit [Read error: Connection reset by peer]
<re_irc>
<@ianrmhill:matrix.org> Hello folks! I've been really interested in trying to use Rust embedded for a hardware project I'm working on as part of my thesis but am currently struggling to set up a USB device endpoint for my chip due to an ARM double fault issue I'm running into. Is it okay to solicit a quick bit of technical help in this chat? Would be happy to repay by helping out the community wherever it is needed on hardware or documentation...
<re_irc>
... topics.
<re_irc>
<@yatekii:matrix.org> Ian Hill: You can just ask :) Everyone here s super friendly and eager to help :)
<re_irc>
<@ianrmhill:matrix.org> Okay thanks so much! Basically the UsbBus implementation in thumbv6m is crashing the ATSAMD21G17D MCU I'm using during setup. The main challenge is that I can't get effective info on the error because the double fault can't be caught by a handler and the backtrace gets corrupted. I've attached some details as a text file to avoid huge blocks of text in the chat.
<re_irc>
<@ryan-summers:matrix.org> Is the error happening during system init? Do you have a debugger attached? It indeed looks like an allocation issue to me
<re_irc>
<@jamesmunns:beeper.com> Also: just to double check, are you running with --release?
<re_irc>
<@ryan-summers:matrix.org> I thought we fixed all the --release bugs in usb-device
<re_irc>
<@ryan-summers:matrix.org> Although I guess an old version could still hit them
<re_irc>
<@jamesmunns:beeper.com> (I meant NOT running release can often cause issues)
<re_irc>
<@ryan-summers:matrix.org> That's what I mean, sorry, I PRd some fixes like last year to resolve what I believe was causing that
<re_irc>
<@ianrmhill:matrix.org> It's occurring during my main setup execution but prior to my core system loop. Yes I have the SAM D21 Curiosity Nano nEDBG CMSIS DAP debugger used through OpenOCD then GDB
<re_irc>
<@ianrmhill:matrix.org> Oh no I'm not, that would be embarrassing
<re_irc>
<@ryan-summers:matrix.org> What usb-device version is this?
<re_irc>
<@ianrmhill:matrix.org> 0.2.9 according to my Cargo.lock
<re_irc>
<@ryan-summers:matrix.org> Hmm okay then I don't expect this to be --debug vs --release, but _definitely_ try out release
<re_irc>
<@ianrmhill:matrix.org> It works with cargo run --release 😆
<re_irc>
<@ianrmhill:matrix.org> Wow, I'd be really interested to understand how the hardware interactions change when running in debug vs. release
<re_irc>
<@ryan-summers:matrix.org> Can you please open an issue in usb-device to track this then?
<re_irc>
<@ianrmhill:matrix.org> One thing of interest, although usb-device is 0.2.9 it's still using the obsolete bare-metal crate because cortex-m still lists it as a dependency in 0.7.7, though I can see the current repo of cortex-m moves away from that package
<re_irc>
<@ianrmhill:matrix.org> Absolutely!
<re_irc>
<@ryan-summers:matrix.org> Nice call :P
<re_irc>
<@dngrs:matrix.org> can you use probe-run on this platform?
<re_irc>
<@dngrs:matrix.org> (not related to your problem but it might enable more comfortable running + faster logging through integrated defmt)
<re_irc>
<@jamesmunns:beeper.com> I'm _guessing_ using debug mode makes it run way slower, and use way more ram, either of which can cause spooky weird errors.
<re_irc>
<@jamesmunns:beeper.com> the hardware interactions themselves won't be a problem, but if you run out of RAM (stack overflow), or end up in an "interrupt storm" because your interrupt handler isn't fast enough to keep up, it can manifest in really hard to debug kind of ways
<re_irc>
<@jamesmunns:beeper.com> (release mode can be on the order of 10-100x faster, and use significantly less ram. Rust's "zero cost abstractions" are really expensive if you don't have optimizations turned on :D )
<re_irc>
<@ianrmhill:matrix.org> Fascinating! That would potentially make sense as my OpenOCD has been occasionally throwing keep-alive timeout warnings, but my Google searches had mainly resulted in suggestions to ignore those warnings
<re_irc>
<@ianrmhill:matrix.org> : I will give it a try! Thanks for the suggestion, I had just been following along with the embedded book so far
<re_irc>
<@ryan-summers:matrix.org> FYI - definitely use probe-run or probe-rs (not maintained by the same people) for flashing/debugging
<re_irc>
<@ryan-summers:matrix.org> Openocd is a nightmare
<re_irc>
<@dngrs:matrix.org> maybe the book needs updating
<re_irc>
<@jamesmunns:beeper.com> Having chapters for "probe-rs[-cli]" and "probe-run" would be a huge improvement IMO. Especially now that probe-rs-cli can act as a GDB server (like OpenOCD), I'd say it's a better default in all cases.
<re_irc>
<@ianrmhill:matrix.org> Yeah perhaps the book could emphasize the differences between debug and release, I thought release mode would make my life more challenging in terms of inspecting at execution time
<re_irc>
<@ryan-summers:matrix.org> It will
<re_irc>
<@ryan-summers:matrix.org> You can tune the level of optimization for debug configs to make debugging easier
<re_irc>
<@jamesmunns:beeper.com> Honestly I know probe-run has docs + items that can be copied from the Ferrous training steps, and I'm sure probe-rs-cli has docs too. It might not be bad to just steal those as a first pass.
<re_irc>
<@ryan-summers:matrix.org> But at --release levels, you will get a whole lot of <optimized out>
<re_irc>
<@jamesmunns:beeper.com> (and if you have LTO turned on, it tends to make GDB segfault a lot)
<re_irc>
<@dngrs:matrix.org> Ian Hill: ah, I meant mostly the book should mention probe-run :D but yeah, the debug vs release thing too, I guess
<re_irc>
<@dngrs:matrix.org> : it can? Ooooooooh
<re_irc>
<@dngrs:matrix.org> does that have any implications for blackmagic probes?
<re_irc>
<@ryan-summers:matrix.org> Yeah was added like a year ago
<re_irc>
<@jamesmunns:beeper.com> : BMPs provide their own GDB server
<re_irc>
<@jamesmunns:beeper.com> like, over the UART
<re_irc>
<@jamesmunns:beeper.com> so they work differently than things like DAPlink/stlink/jlink
<re_irc>
<@ryan-summers:matrix.org> Don't think so? BMP does the GDB stub on-probe doesnt it?
<re_irc>
<@jamesmunns:beeper.com> (that being said, I've never really used BMPs, so someone else might know more)
<re_irc>
<@dngrs:matrix.org> ah yeah the wrong way round then
<re_irc>
<@jamesmunns:beeper.com> ah, maybe it's just the stub on probe, not the whole server
<re_irc>
<@jamesmunns:beeper.com> maybe don't listen to me 😅
<re_irc>
<@ianrmhill:matrix.org> Yeah I was going to ask that actually, I bought a BMP and was planning on using it once my custom boards come in and I assemble them
<re_irc>
<@dngrs:matrix.org> last I checked you couldn't use them with probe-run
<re_irc>
<@dngrs:matrix.org> but that was also > 1 year ago
<re_irc>
<@ryan-summers:matrix.org> It's not a communication protocol supported by probe-rs currently. It could be added, but I don't _think_ its in?
<re_irc>
<@ryan-summers:matrix.org> Not sure what most people use for ATSAM devices though. Been a long time since I dev'd for one
<re_irc>
<@ryan-summers:matrix.org> I guess most people would use jlink
<re_irc>
<@ianrmhill:matrix.org> Also thanks so much to all of you for the help :) Once I get comfortable with embedded Rust hopefully I can provide some value to the community!
<re_irc>
<@jamesmunns:beeper.com> "big picture" for Ian Hill, instead of your current flow where you:
<re_irc>
- run openocd in the background
<re_irc>
- build the elf file
<re_irc>
- run gdb to connect and debug
<re_irc>
you usually just use "cargo run --release", with either probe-run or probe-rs-cli as your "runner", and they handle attaching the debugger, flashing the image, and then either starting a gdb server or opening a logging window
<re_irc>
<@dngrs:matrix.org> on that note - with gdb it seems possible to run the code from ram. probe-run doesn't support this, right?
<re_irc>
<@jamesmunns:beeper.com> : I ran into that recently too. I think it's hard coded (in probe-rs) to use the flash algorithms to load code
<re_irc>
<@jamesmunns:beeper.com> I don't think it's possible to do today, but could totally be possible. you'd need a separate "flash to ram" thing, but that's totally within the low level capabilities of probe-rs.
<re_irc>
<@ryan-summers:matrix.org> You need to configure your link to link code into RAM. But AFAIK used probe-rs to "flash" firmware to RAM
<re_irc>
<@dngrs:matrix.org> nice!
<re_irc>
<@jamesmunns:beeper.com> : Ah gotcha. Yeah, I have an image that is totally in RAM, and probe-run threw up a probe-rs error when I tried to load it. Could be it just isn't using the right probe-rs bits.
<re_irc>
<@jamesmunns:beeper.com> (writing a RAM loader atm, so very topical for me :D)
<re_irc>
<@ryan-summers:matrix.org> Maybe you need at least a little flash, IDK
<re_irc>
<@jamesmunns:beeper.com> nah, it just didn't like that the ".text" section was outside the target-specific flash region
<re_irc>
Error: A core architecture specific error occurred
<re_irc>
Unsupported address 0x20004e72 for HW breakpoint. Breakpoint must be at address < 0x2000_0000.
<re_irc>
<@jamesmunns:beeper.com> because probe-run sets breakpoints for stuff (I forget exactly what)
<re_irc>
<@dngrs:matrix.org> panic?
<re_irc>
<@jamesmunns:beeper.com> yeah, something like that, or maybe before main to make sure rtt is connected so it can reconfigure it? Honestly don't remember.
<re_irc>
<@dngrs:matrix.org> ah yeah rtt init
<re_irc>
<@jamesmunns:beeper.com> (in soupstone I have a ramloader in flash, so normally I push "app" images over USB, but I accidentally did "cargo run" instead with probe-run configured and saw that error like... this weekend)
<re_irc>
<@jamesmunns:beeper.com> this is not a thing that can be easily worked around, I think. hw breakpoints are usually only for flash/rom
<re_irc>
<@jamesmunns:beeper.com> I think the only other option would be either hot-patching the code in RAM (e.g. sticking a bkpt instruction where real code used to be, then putting it back before resuming), or polling the PC (likely to not stop exactly there, just kinda close)
<re_irc>
<@jamesmunns:beeper.com> both are much more complicated than the current hw breakpoint usage.
<re_irc>
<@jamesmunns:beeper.com> (AFAIK, which, is very likely incomplete)
<re_irc>
<@jamesmunns:beeper.com> Oh interesting, apparently FPBv2 can also do RAM regions (maybe?), no idea how widely v1 vs v2 is in practice, good post from the Interrupt blog: https://interrupt.memfault.com/blog/cortex-m-breakpoints
Foxyloxy_ has joined #rust-embedded
<re_irc>
<@jamesmunns:beeper.com> fwiw, just booted my nrf52840 on a debugger and printed the control register, which reports using FPBv1 (the datasheet mentioned the fpb, but no details)
Foxyloxy has quit [Ping timeout: 255 seconds]
<re_irc>
<@jamesmunns:beeper.com> Also was very confused why JLinkGDBServer wouldn't connect to my nrf52840-dk, until I remembered I flashed the DAPLink image to it, because it does (or did, a few years back) RTT comms faster than the JLink probe image :D
fabic has quit [Ping timeout: 276 seconds]
Dr_Who has quit [Read error: Connection reset by peer]
<re_irc>
<@dlaw:matrix.org> I would like to call "core::mem::size_of" on an instance instead of a type. I couldn't find a core function which does this. I figured out how to define my own "size_of" function, but I'm wondering if there is a more idiomatic way to express this?