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
<JamesMunns[m]> https://github.com/JoNil/elf2uf2-rs if you need to use the bootloader
<JamesMunns[m]> oh - not sure if that will work with the seeeduino
<JamesMunns[m]> worth a try :)
<adinack[m]> haha thanks i'll give it a shot
<adinack[m]> `Error: "Memory segment 0x000000->0x000100 is outside of valid address range for device"`
<adinack[m]> i have a feeling the whole uf2 thing doesn't make sense for the elf output of embassy
<JamesMunns[m]> you probably need to modify the start address to "avoid" the bootloader
<adinack[m]> oh true, i've only dealt with this stuff on SAMD chips idk how it works on the nrfs
<adinack[m]> i have tried increasing the flash origin address but it still thinks that is invalid
<adinack[m]> wouldn't i need to know what address the bootloader jumps to??
<JamesMunns[m]> gotcha, that elf2uf2-rs project I think is only pico specific for now, you might have to tweak it to work for other chips if their bootloaders live in different places
<adinack[m]> ah i see
<JamesMunns[m]> wait are you on the nrf52?
<adinack[m]> good thing there is a SWD port on the bottom of the seeeduino
<JamesMunns[m]> like is that the xiao nrf52840?
<adinack[m]> yes the nrf52
<adinack[m]> yes it is
<JamesMunns[m]> oh, I've flashed that before, hold up
<JamesMunns[m]> like using the factory bootloader
<adinack[m]> oh!
<adinack[m]> please, do tell
<JamesMunns[m]> ah I used uf2conv
<JamesMunns[m]> this project was meant to actually be flashed using uf2, then replaces the uf2 bootloader with my bootloader: https://github.com/jamesmunns/soupstone/tree/main/experiments/xiao-init-stage-minus-1
<adinack[m]> you know what i think i used this very tool years ago
<JamesMunns[m]> but it's embassy, and the memory.x is right for you, and you can look at https://github.com/jamesmunns/soupstone/blob/main/experiments/xiao-init-stage-minus-1/generate-uf2.sh
<adinack[m]> not yours the microsoft one
<JamesMunns[m]> so: it's definitely possible :)
<adinack[m]> oh this looks great! i'll lyk how it goes, thanks :)
<JamesMunns[m]> that soupstone project was a plan to experiment with "a better rust experience without a debugger", though I got sidetracked. It has a really simple bootloader you can use to poke images into RAM and run them for there (so it takes like 2s to have a running image), then it has a lib that gives you "stdio"
<JamesMunns[m]> can't say I'd recommend it for daily use, but I was specifically using the nrf52 xiao :D
<JamesMunns[m]> glad at least part of the experiment was useful for someone else :D
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded
<firefrommoonligh> From a firmware and hardware design perspective, I am loving the concept of using a CAN bus for most or all IO. (CAN due to the combo of it being a bus, and suitable for running along wires).
<firefrommoonligh> I decided I want to make a sailboat. (Or station-keeping buoy... or a fleet of them...) Rather than design a new PCB or try to rope together some existing hardware and firmware with the right IO, I can set up minimal firmware with CAN pins and hardware, and parsing the CAN messages.
<firefrommoonligh> sensors. Just need an MCU with CAN (and USB).
<firefrommoonligh> The device will need all sorts of things like RF controls, barometric pressure, magnetometer, IMU, AHRS fusion etc, but that's all done on a node I already made. So I plug in the AHRS/GNSS device over CAN, and parse the readings. Minimal; no IO concurrency or memory sharing to deal with. No increase in code complexity due to interactions. Don't even need custom hardware; can run a separate AHRS node without populating the
<adinack[m]> <JamesMunns[m]> "glad at least part of the..." <- it seems to almost work, like i got the uf2 and the bootloader continues to work after i flash it but the program does not appear to run
<firefrommoonligh> * I decided I want to make a sailboat. (Or station-keeping buoy... or a fleet of them...) Rather than design a new PCB and set up a firmware with all the busses, pins, drivers etc, I can set up minimal firmware with CAN pins and hardware, parsing the CAN messages, and business (boating?) logic.
<firefrommoonligh> The device will need all sorts of things like RF controls, barometric pressure, magnetometer, IMU, AHRS fusion etc, but that's all done on a node I already made. So I plug in the AHRS/GNSS device over CAN, and parse the readings. Minimal; no IO concurrency or memory sharing to deal with. No increase in code complexity due to interactions. Don't even need custom hardware; can run a separate AHRS node without populating the
<firefrommoonligh> sensors. Just need an MCU with CAN (and USB).
<firefrommoonligh> * I decided I want to make a sailboat. (Or station-keeping buoy... or a fleet of them...) Rather than design a new PCB and set up a firmware with all the busses, pins, drivers etc, I can set up minimal firmware with CAN pins and hardware, parsing the CAN messages, and business (boating?) logic.
<firefrommoonligh> The device will need all sorts of things like RF controls, barometric pressure, magnetometer, IMU, AHRS fusion etc, but that's done on a pair of nodes I already made. So I plug in the AHRS/GNSS device over CAN, and parse the readings. Minimal; no IO concurrency or memory sharing to deal with. No increase in code complexity due to interactions. Don't even need custom hardware; can run a separate AHRS node without populating the
<firefrommoonligh> sensors. Just need an MCU with CAN (and USB).
<adinack[m]> adinack[m]: i do like the idea of embedded rust not requiring a debugger... although maybe it is for the best that we have to use debuggers so we don't go crazy trying to diagnose things without one XD how do Arduino devs do it!
<firefrommoonligh> I think a key part of this is it decouples different parts of the hardware and software into parts, with the linkage being CAN. Sort of like partitioning code into independent functions that interact over a small, strongly-typed interface (The function signature). But partitioning whole code codes and hardware designs.
<firefrommoonligh> I think another key part of the appeal is it reduces the change of a change in one part of the system affecting another unintentionally; complexity management by partitioning.
<firefrommoonligh> s/change/chance/
ian_rees[m] has joined #rust-embedded
<ian_rees[m]> firefrommoonligh: totally - it's all about managing complexity, and well-defined interfaces are key
M9names[m] has joined #rust-embedded
<M9names[m]> <thejpster[m]> "And ideally off-chip firmware." <- what is "off-chip" firmware in this context?
duderonomy has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
<thejpster[m]> <M9names[m]> "what is "off-chip" firmware in..." <- Putting a very basic thing on the chip and writing the test code externally. Micropython might work, or doing very basic bring up and poking registers using geb’s Python API. Anything to cut down to write-execute loop time whilst you try stuff out.
<thejpster[m]> s/geb/gdb/
IlPalazzo-ojiisa has joined #rust-embedded
corecode[m] has joined #rust-embedded
<corecode[m]> i'm looking for a plaintext logging crate that will write to my arm SWV/SWO. i don't want to deal with binary decoding defmt stuff
<corecode[m]> seems like log doesn't do no_std
<M9names[m]> log works just fine with no_std
<corecode[m]> ah yea, there is a std feature flag
M9names[m]1 has joined #rust-embedded
<M9names[m]1> I did a quick web search found 2 crates that support logging via itm, maybe try one of those?
<corecode[m]> oh maybe that's the term i need to use
<corecode[m]> thanks
emerent has quit [Ping timeout: 245 seconds]
emerent has joined #rust-embedded
justacec[m] has joined #rust-embedded
<justacec[m]> I have an older code that I wrote which used the PIO to generate more-code flashes. It used to compile, but now after a cargo update it is failing with the following:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/MWBKbYQNNNdZcbDppbgfXZyN>)
<justacec[m]> I can post the files in a Gist if needed
<justacec[m]> I have placed the files in a Gist at: https://gist.github.com/justacec/91c4a2b9f529b861f5431b2bead06c8f for easy viewing.
<justacec[m]> Ohh, The world is better, I rechecked the rp2040_local_i2c_init and that is failing with the same error.
<justacec[m]> I will shift this thread of thought over to the dedicated RTIC channel.
ithinuel[m] has joined #rust-embedded
<ithinuel[m]> Use `cargo tree` to identify which crate makes use of an older rp2040-pac
<ithinuel[m]> That's you're issue (as hinted by cargo's error message)
<ithinuel[m]> s/you're/your/
<ithinuel[m]> The issue is because the two crates that are trying to pass to each other a version of the timer that's different.
<ithinuel[m]>  
GenTooMan has quit [Read error: Connection reset by peer]
GenTooMan has joined #rust-embedded
<ithinuel[m]> It is ok to have different versions of a crate at the same time provided that they don't try to interact.
<ithinuel[m]> In your case I think rtic-monotonic rp2040 might be expecting a TIMER from the PAC version 0.4.0 but your main passes in one from rev 0.5.0
<justacec[m]> Yea, this looks to be an issue with RTIC. I have brought it up on their channel. The example from the rtic repo is not compiling after a cargo update.
<justacec[m]> I have manually manip my Cargo.lock file for now as a bandaid.
<ithinuel[m]> For what it's worth, the rp2040 hal implements the rtic monotonic trait
nex8192 has left #rust-embedded [Error from remote client]
IlPalazzo-ojiisa has quit [Remote host closed the connection]
<StephenD[m]> lol wtf? My code works fine if I use the panic-semihosting crate but not the panic-reset crate
Socke has quit [Ping timeout: 250 seconds]
<StephenD[m]> I can reproduce by manually writing a panic handler. Works fine if I run a dbg! in it, and if I don't then my program just crashes basically instantly
crabbedhaloablut has quit []
<StephenD[m]> The panic handler doesn't run in either case
Socke has joined #rust-embedded
Noah[m] has joined #rust-embedded
<Noah[m]> I know that there is a lot of folk that have atempted (and succeeded) to build custom keyboards. has anyone done so for a docking station/kvm switch?
<K900> Not happening
<K900> You need specialized hardware to multiplex DisplayPort/HDMI properly
<K900> For HDMI you'll have to pay a license fee too
<K900> For DP you can probably get away with a gigantic FPGA
<K900> But even that is questionable
<Noah[m]> K900: I know ;)
<Noah[m]> K900: yeah, I despise HDMI, I run on DP only =)
<Noah[m]> K900: yeah I would not mind if it gives me nice HW =)
<Noah[m]> K900: absolutely, but the market of devices in that direction is just not great :/
<Noah[m]> this at least has 2 monitors per KVM end :)
<Noah[m]> and expensive AF, wow :D
<K900> They're basically selling those at ~cost
<K900> So yeah
<Noah[m]> https://www.digitec.ch/de/s1/product/delock-11482-kvm-switch-14562871 I can get 2 of those for basically 66% of the cost but same features? I am not sure what I am missing.
<Noah[m]> Either way, I would have to open up all of them and solder on them to make them useable
<Noah[m]> disgusting case with built in button instead of a proper remote, etc - I don't understand ANY of the design choices. Which is why I wanna build my own in the first place :)
<Noah[m]> (sorry for the strong, negative words - my search is going forever already and it just seems like people don't want nice products)
<Noah[m]> maybe I should just start with USB KVM as my monitors can auto-switch (it's annoying if I wanna switch without putting the other machine to standby). But USB is already crazy convoluted :/
<dirbaio[m]> they suck/expensive because they're a very niche product
<dirbaio[m]> what do you want it for?
<Noah[m]> dirbaio[m]: I just don't believe that :/ all my friends have this issue :/ at least since the pandemic everyone has it
<dirbaio[m]> KVMs are typically for server-y stuff, there you don't need 4k60
<dirbaio[m]> Noah[m]: wut? why do you all have two computers? 🤣
<Noah[m]> I have a PC for gaming, a private macbook for proper work (coding, 3D CAD, etc) and a macbook for my employer which I all want to use with the same monitors, same keyboard, same mouse, etc.
<Noah[m]> dirbaio[m]: PC and employer laptop :)
<dirbaio[m]> ahhh
<Noah[m]> I wish people would make games for macs (how is this hard in 2023) and employers would let you use a proper computer instead of an antivirus infested company one (in my case I can at least use a mac)
<Noah[m]> like I barely have friends that don't have at least one or two homeofice days :)
<dirbaio[m]> > I wish people would make games for macs (how is this hard in 2023)
<dirbaio[m]> Apple hates gamers 🙃
<Noah[m]> dirbaio[m]: > <@dirbaio:matrix.org> > I wish people would make games for macs (how is this hard in 2023)... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/uKqeTPSaZlBYnmeOHueiQczy>)
<Noah[m]> ask the Rust GFX people what they thing of the apple graphic stuff ;) I think it's pretty awesome nowadays :)
<K900> It's actually very hard, lol
<Noah[m]> since a couple years already :)
<K900> Because Apple lives in its own weirdo world
<K900> With their own weirdo APIs for everything including rendering
<dirbaio[m]> devs don't want to target macos because Apple loves to pull the rug from under them with no warning
<K900> And Metal is still missing stuff normal people have had in GL 4.1
<K900> Or DirectX 10
<dirbaio[m]> opengl deprecation, then the 32-bit deprecation
<dirbaio[m]> s/devs/gamedevs/
<K900> In fact here's something specifically from the Rust graphics people about it: https://github.com/gpuweb/gpuweb/discussions/3935
<K900> (and yes, it's a big deal)
<dirbaio[m]> Noah[m]: perhaps use a USB-C dongle/dock and just plug/unplug that. it's only *slightly* more work than pushing a button!
<JamesMunns[m]> make your own "USB-C" switcher, but with a relay for each line :D
<JamesMunns[m]> plus you get a satisfying CLUNK when like 32 relays switch :D
<dirbaio[m]> 10-ghz relays?
<JamesMunns[m]> not like actually switching in real time, just "A or B connected to C at one time"
<dirbaio[m]> yeah but can multi-ghz signals pass through a relay without getting too smooshed?
<JamesMunns[m]> (I'm not seriously suggesting this nor do I think it's practical)
<Noah[m]> <dirbaio[m]> "devs don't want to target..." <- so you think microsoft or sony have better policies? :D
GrantM11235[m] has joined #rust-embedded
<GrantM11235[m]> Make a cute little robot to plug/unplug the usb cable
<JamesMunns[m]> dirbaio[m]: maybe? it's just a metal strip that gets deflected to make/break
<K900> Noah[m]: Yes, actually?
<JamesMunns[m]> better chance a low cost relay works than an actual analog switch (which would be have to be GHz rated)
<K900> Microsoft supports DirectX all the way back to what, 6?
<K900> On all of their platforms
<K900> And yes this includes Xbox
<dirbaio[m]> Noah[m]: at least on Windows you know you can build and publish the game once and it'll work ~forever. you won't have to update+rebuild+republish all your catalog every few years to keep selling it
<JamesMunns[m]> GrantM11235[m]: The relay approach would just be an attempt to emulate this :D
<K900> Sony has the same graphics API on the PS4 and the PS5, and older hardware is completely bespoke so it's in a weird situation to begin with
<K900> But so far they have been consistent after the switch to conventional hardware
<GrantM11235[m]> By the way, there is a standards-compliant gpu ecosystem for macbooks, just install linux 🤣 https://rosenzweig.io/blog/first-conformant-m1-gpu-driver.html
<JamesMunns[m]> GrantM11235[m]: someday soon I hope they support the M2 Max :p
<Noah[m]> <K900> "With their own weirdo APIs for..." <- so you mean it's ok for microsoft to have their proprietary APIs, but not for Apple? :)
<K900> 1) Microsoft platforms also have OpenGL and Vulkan, and games do use those
<dirbaio[m]> Windows at least does support opengl and vulkan
<Noah[m]> <dirbaio[m]> "at least on Windows you know you..." <- yeah and look at the state the OS is in :D
<K900> 2) Microsoft's proprietary API is not terrible
<K900> (usually)
<dirbaio[m]> Noah[m]: windows is a dumpster fire, but so is macos
<Noah[m]> dirbaio[m]: internas yes, but macOS is at least nice to use ...
<Noah[m]> well anyways, endless discussion
<K900> As someone who spent two months trying to fix keyboard layout switching on OSX, gave up and got a Linux laptop from $work instead, I would absolutely not call that experience nise
<K900> s/nise/nice/
<Noah[m]> K900: yeah I mean Linux is known for great keyboard configuration systems XD
<K900> Yes, actually? xkb is unironically very good
<dngrsspookyvisio> K900: did you use karabiner?
<K900> But also, even without xkb, Linux at least did not eat my inputs
<K900> dngrsspookyvisio: I used a whole bunch of things and none of them worked correctly
<K900> And all I wanted was to map Caps Lock to switch keyboard layouts
<K900> At one point, I got a suggestion from a coworker to disable Siri
<K900> Which reduced the rate of dropped inputs by maybe 50%
<dngrsspookyvisio> sounds like you installed some crap that hijacked input
<K900> And was also the point where I decided I am officially not cool enough to understand Apple products
<K900> Nothing of the sort, it was a perfectly clean OS with Firefox, VSCode, Nix and that's about it
<dngrsspookyvisio> anyway, stock macos is pretty meh, but it's surprisingly configurable and with a few free apps I think it can be made rather great. But it's certainly a big amount of knowledge one just "needs to have"
<dngrsspookyvisio> (also I got lots of hate for apple too, no worries)
<K900> I did reinstall it just to confirm, twice
<dngrsspookyvisio> that's not normal
<dngrsspookyvisio> pointless to debug from here but don't pretend that's a typical user experience
<K900> There's a bug report for this on the Apple Radar thingy
<K900> It's been there since 2017
<K900> It may not be a typical user experience
<K900> But it's common enough to have been reported 6 years ago
<dngrsspookyvisio> Apple has no public bug tracker, I guess you mean openradar (where people mirror the bug reports they send to Apple)
<dngrsspookyvisio> anyway, sounds intriguing, if you find the url I'd be interested in reading up on it.
<K900> I really don't want to look it up again
<K900> But the basic issue is that if you have more than one keyboard layout and enable the setting to switch them with Caps Lock, sometimes it just ... doesnt'
<K900> * But the basic issue is that if you have more than one keyboard layout and enable the setting to switch them with Caps Lock, sometimes it just ... doesn't
<K900> It is not in any way consistent
<K900> And somehow turning Siri off makes it happen a lot less often
<K900> That's as much as I can tell you
emerent_ has joined #rust-embedded
emerent has quit [Killed (tungsten.libera.chat (Nickname regained by services))]
emerent_ is now known as emerent
<adinack[m]> this might sound dumb but does anyone know how to set up an embassy project?
<dirbaio[m]> which chip
<dirbaio[m]> * which chip?
<adinack[m]> nrf52840
<adinack[m]> i'm looking at the example toml file and it is looking at local stuff, and i couldn't find it on crates.io
<adinack[m]> like am i supposed to just clone embassy somewhere and just manually write out the path to it in my toml?
<dirbaio[m]> - copy this directory https://github.com/embassy-rs/embassy/tree/main/examples/nrf52840 Make sure to copy ALL files. including `.cargo/config.toml` and `build.rs`.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/EsdLGQSmFKilWjoewACGHVrL>)
<adinack[m]> aaahhh thank you
<adinack[m]> i have the seeeduino hooked up to a debugger and ran it and it worked right away, i have big hopes for embassy!!!
<adinack[m]> ok this is a pretty annoying process tho lol
<adinack[m]> i did exactly what you said, deleted everything and started over, and i still get this error
<adinack[m]> when i build inside the example it works fine i don't understand
<dirbaio[m]> ah sorry, copy this file too into the root of your project https://github.com/embassy-rs/embassy/blob/main/rust-toolchain.toml
<dirbaio[m]> (and you can remove all targets except thumbv7em-none-eabi)
<adinack[m]> sweeeet thanks!
<adinack[m]> (i love probe-rs btw)
<adinack[m]> there should be an embassy-template repo or something eh? make this whole process a lot easier to automate?
<adinack[m]> wow rust-analyzer is not having a good time lol
<dirbaio[m]> try this in `.vscode/settings.json`... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/GzxbIVOvTvZAtKrEaOttCosf>)
<adinack[m]> hm that didn't do anything
<dirbaio[m]> perhaps you need to close and reopen vscode
<adinack[m]> i recall having a similar issue with stm32f0xx-hal and i resolved it somehow let me go check
<adinack[m]> dirbaio[m]: i did of course haha
<dirbaio[m]> what errors are you getting?
<dirbaio[m]> that looks like your target is set to thumbv6 somewhere
<adinack[m]> omg you know what
<adinack[m]> maybe that's what my fix was for the other hal
nex8192 has joined #rust-embedded
<dirbaio[m]> nrf is thumbv7em-none-eabi
<adinack[m]> i like forced rust analyzer to think the target was thmbv6 and accidentally made it a global setting 🤦‍♂️
<dirbaio[m]> (or -eabihf if you want floating point)
<adinack[m]> ok no i don't see it anywhere
<adinack[m]> every file in my project says "thumbv7em-none-eabi"
<adinack[m]> well at least it compiles i can try and get rust analyzer to work later, thanks dirbaio
<dirbaio[m]> try F1 -> Open user settings (JSON)
<adinack[m]> yeah there's nothing in there, and the workspace settings take priority anyway
<adinack[m]> oh wait something did happen
<adinack[m]> now it's only one error
<adinack[m]> uugh i remember fixing this in the other HAL i just can't remember how 🤣
<adinack[m]> in Cargo.toml