<re_irc>
< (@dkhayes117:matrix.org)> what's the easiest way to toggle between defmt logging levels? Right now I have use "[env]" in .cargo/config.toml; however, this requires me running cargo clean between changes in order for it to take effect.
<re_irc>
[env]
<re_irc>
DEFMT_LOG = "info"
<re_irc>
<dngrs (spookyvision@{github,cohost})> I supply it on the command line like "DEFMT_LOG=xxx cargo rrb theapp"
<re_irc>
<dngrs (spookyvision@{github,cohost})> you can put the entire invocation in a shell script
<re_irc>
< (@jamesmunns:beeper.com)> add a build-rs script that looks at the "DEFMT_LOG" var?
<re_irc>
<dngrs (spookyvision@{github,cohost})> you might also want something around "cargo watch" where you put the actual log level in a specific file that then gets sourced
<re_irc>
< (@jamesmunns:beeper.com)> dngrs (spookyvision@{github,cohost}) I think the problem is that a changing env var doesn't trigger a rebuild of components (anything affected by the env change)
<re_irc>
< (@jamesmunns:beeper.com)> so the bash script (or the use of env in the config) isn't "cache busting" the way dkhayes wants.
<re_irc>
<dngrs (spookyvision@{github,cohost})> : it should though? it certainly does for me.. ok, maybe if logging is called in a dependency
<re_irc>
< (@jamesmunns:beeper.com)> as a note, adding that to the "binary crate" build-rs probably isn't enough to recompile deps with the new settings
<re_irc>
< (@jamesmunns:beeper.com)> honestly - defmt itself should probably have that in it's build.rs
<re_irc>
<dngrs (spookyvision@{github,cohost})> I'd say it's unnecessary in the binary crate, as I do get binary rebuilds for free when I just change the env var
<re_irc>
< (@dkhayes117:matrix.org)> It's not that big of a deal, I was just curious to see if I was making it harder than it could be.
<re_irc>
< (@jamesmunns:beeper.com)> I think you can cargo clean a single package, maybe try "cargo clean -p defmt"?
<re_irc>
< (@jamesmunns:beeper.com)> should trigger a rebuild of all downstream deps, unless cargo is too clever
<re_irc>
< (@dkhayes117:matrix.org)> let me try
<re_irc>
< (@jamesmunns:beeper.com)> it WILL rebuild anything that actually uses defmt (if it does what I think), but maybe not some of the more expensive components like the pac and hal
<re_irc>
< (@dkhayes117:matrix.org)> That worked and was much faster, cool!
<re_irc>
< (@jamesmunns:beeper.com)> so... no idea?
<re_irc>
< (@dirbaio:matrix.org)> dkhayes117 (Daniel): this is a bug in cargo. changing an envvar in "[env]" in ".cargo/config.toml" doesn't trigger a rebuild even if the crate is using "cargo:rerun-if-env-changed=NAME" (which defmt is). Only changing "real" envvar does.
<re_irc>
< (@jamesmunns:beeper.com)> maybe specifying the env in the cargo config doesn't play nice with that check?
<re_irc>
< (@jamesmunns:beeper.com)> op
<re_irc>
< (@jamesmunns:beeper.com)> that'll do it lol
<re_irc>
< (@dirbaio:matrix.org)> dunno if there's an issue
<re_irc>
< (@jamesmunns:beeper.com)> that's a Fun Fact.
<re_irc>
< (@dirbaio:matrix.org)> but imo cargo should definitely rebuild
<re_irc>
<dkhayes117 (Daniel)> I thought I had read earlier that the packages using the env variable was supposed to rebuild when changed. I see that it isn't working 🙈
<re_irc>
< (@jamesmunns:beeper.com)> "cargo watch -x 'clean -p defmt' -x check" will probably do it :p
<re_irc>
< (@jamesmunns:beeper.com)> (you can sequence commands with cargo watch)
<re_irc>
< (@jamesmunns:beeper.com)> it turns that into "cargo clean -p defmt && cargo check" on every save
<re_irc>
<dngrs (spookyvision@{github,cohost})> TIL
IlPalazzo-ojiisa has quit [Quit: Leaving.]
vancz has quit [Remote host closed the connection]
vancz has joined #rust-embedded
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #rust-embedded
cr1901_ has joined #rust-embedded
madb_ has quit [*.net *.split]
emerent has quit [*.net *.split]
inara` has quit [*.net *.split]
cr1901 has quit [*.net *.split]
emerent has joined #rust-embedded
inara` has joined #rust-embedded
madb_ has joined #rust-embedded
madb_ has quit [Max SendQ exceeded]
madb_ has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
lehmrob has joined #rust-embedded
madb_ has quit [Remote host closed the connection]
madb_ has joined #rust-embedded
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #rust-embedded
<re_irc>
< (@chrysn:matrix.org)> I'm probably not telling anyone news here, but let it be said: Atomics are hard, especially when there are more than two parties working on a data structure.
<re_irc>
(I should probably buy The Book...)
<re_irc>
< (@9names:matrix.org)> my copy turned up today. it has been hard to not read the free online version while waiting.
<re_irc>
< (@monacoprinsen:matrix.org)> : What book are you referring to? 😊
<re_irc>
< (@chrysn:matrix.org)> The Book on atomics ;-)
<re_irc>
< (@jamesmunns:beeper.com)> might know more :)
<re_irc>
< (@9names:matrix.org)> i've been working on scraping register data out of the SDK for PAC use. the official pac is using a hand-written SVD which is still missing a lot of registers, some of which i wanted to use.
<re_irc>
other than that, i've got basic rust blinky's up and going on the MCU and MPU cores, and a C blinky I hacked together running on the RV32E LP core as of about 30 minutes ago.
<re_irc>
haven't seen anyone else running Rust on this thing, but maybe they're just not talking about it...
<re_irc>
< (@9names:matrix.org)> luojia has been on holiday i think, due to CNY
<re_irc>
Would surely be interesting to have a HAL.
<re_irc>
As far as I have found there is nothing more than the PAC and as you said it seems that some things are missing.
<re_irc>
Let me know if and how I can help.
<re_irc>
< (@9names:matrix.org)> you can do a lot with just a PAC, as long as it's complete+correct.
<re_irc>
help on the peripheral/register extraction side would be most welcome, as would tooling to combine this with the parts that are already handwritten in the existing SVD.
<re_irc>
if you really wanted to you could port drivers from bl602-hal/bl702-hal to the new chip but I'd rather work on something that covers all the parts, not just this particular one.
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc>
< (@monacoprinsen:matrix.org)> : I have both the 64Mb and the 128Mb versions.
<re_irc>
DM me on how to proceed and I will gladly help!
<re_irc>
Ah so you would rather have something like a BL-HAL?
madb_ has quit [Quit: Leaving]
<re_irc>
< (@jamesmunns:beeper.com)> Hey y'all, for anyone that uses the "postcard" crate, and has ever wanted/struggled with postcard NOT being a "self describing" format, could you please give https://github.com/jamesmunns/postcard/issues/92 a read, and comment if you can share any specific details?
<re_irc>
< (@jamesmunns:beeper.com)> (definition of terms and explanation of the problem at the issue!)
<re_irc>
< (@jamesmunns:beeper.com)> Also if you are not sure your "I wish postcard could..." thoughts are relevant, please comment! In the worst case, I'll move it to another issue to track or discuss.
lehmrob has quit [Quit: Konversation terminated!]
emerent has quit [Ping timeout: 248 seconds]
emerent has joined #rust-embedded
cr1901_ is now known as cr1901
<re_irc>
< (@vitaly.codes:matrix.org)> I use postcard for storing simple objects to eeprom and I'm totally happy with that. Only one edge case I can remember for my usage is changing schema on the fly. Really rare event, and for now I forced to use two different versions of object.
<re_irc>
I'm not sure this is possible with current postcard design, but probably we can do optional fields, or even asymmetric fields, like 'typical' has.
<re_irc>
<dkhayes117 (Daniel)> : I'm using "serde::{Serialize, Deserialize}" and "serde-json". Would there be any benefit of trying to use/adapt postcard in this situation. (I'm fairly new to serialization type stuff)
<re_irc>
<apache8080> is anyone working on an opensource rust flight controller? looks like RustyFlight from Galois has been dead for the past 3 years. Related is there any good EKF/state estimation work thats been done in rust?
<re_irc>
< (@firefrommoonlight:matrix.org)> No
<re_irc>
< (@firefrommoonlight:matrix.org)> Closed source for now, but the hardware interface lib is open source
<re_irc>
< (@firefrommoonlight:matrix.org)> Of note, I currently don't use EKF, but may in the future. Using a modified Madgwick for the attitude platform
<re_irc>
< (@firefrommoonlight:matrix.org)> (Mainly since it's good enough for now and easy to impl)
<re_irc>
< (@firefrommoonlight:matrix.org)> I've been focused more on FC hardware design recent (In a hopefully endgame sprint on releasing a pair of FCs), then will focus more on firmware. Will use Betaflight, iNav etc until then
<re_irc>
< (@firefrommoonlight:matrix.org)> I currently have the main systems working (CRSF Rx controls/link stats, DSHOT motor output and RPM reception, PWM servos, IMU, baro, USB PC preflight interface working
<re_irc>
< (@firefrommoonlight:matrix.org)> But the FC logic isn't working. I am doing something exotic that doesn't use PIDs
<re_irc>
< (@firefrommoonlight:matrix.org)> Happy to chat
brazuca has quit [Quit: Client closed]
<re_irc>
< (@firefrommoonlight:matrix.org)> I currently have the main systems working (CRSF Rx controls/link stats, DSHOT motor output and RPM reception, PWM servos, IMU, baro, USB PC preflight interface)
<re_irc>
< (@firefrommoonlight:matrix.org)> I currently have the main systems working (CRSF Rx controls/link stats, DSHOT motor output and RPM reception, PWM servos, IMU, baro, USB PC preflight interface, Display port OSD)
<re_irc>
<apache8080> do you have a link to the hw interface lib?
<re_irc>
<mr_trester> I'm compiling for avr microcontroller and a crate in tree needs "alloc", so I created a dummy one and am no longer getting rust compiler errors but this instead:
<re_irc>
error: linking with `avr-gcc` failed: exit status: 1
<re_irc>
<apache8080> lol classic, I was looking at the hubris RTOS from oxide a few months back. Nice foundation to potentially build from
brazuca has joined #rust-embedded
<re_irc>
< (@jamesmunns:beeper.com)> dkhayes117 (Daniel): So, postcard generally is a "drop in" replacement for any other serde backend (like serde_json). It will almost certainly be faster to serialize and deserialize, and without a doubt produce smaller messages on the wire. It produces binary messages (e.g. an array of bytes), instead of string-y messages.
<re_irc>
The downside is that it is NOT a self describing format, which means both ends must know "ahead of time" the schema/type of a message, in order to correctly deserialize it.
<re_irc>
It also has some handy ways to customize the format of data on the wire, like adding COBS framing or CRC checksums to every message.
<re_irc>
< (@firefrommoonlight:matrix.org)> Yea I concur and am excited to see where that goes
<re_irc>
< (@firefrommoonlight:matrix.org)> We'll see if I eventually have to switch to a software scheduler or RTOS...
<re_irc>
At least right now - I hope/plan/am looking into having the schema "on the side", so you don't need to send it in every message. This means having fields that "aren't understood" by one of the parties is a little harder, at the cost of the "just the data" payload being smaller (and back-compat to "regular" postcard).
<re_irc>
< (@jamesmunns:beeper.com)> : Interesting - this looks closer to protobufs (from a first look).
<re_irc>
<dkhayes117 (Daniel)> : I'm currently sending data to Golioth which is expecting JSON/CBOR objects or a single value, so I don't think they would be able to deserialize postcard?
<re_irc>
< (@jamesmunns:beeper.com)> nope, generally postcard is "rust only", so that's also something to consider.
<re_irc>
< (@jamesmunns:beeper.com)> (some of these schema plans will likely make it easier/feasible to have non-rust clients as well. it's sooooooorta possible today, but it'd be a lot of work)
<re_irc>
< (@jwagen:matrix.org)> mr_trester: I think it might be this issue
<re_irc>
< (@jamesmunns:beeper.com)> (it likely won't be AS fast as serde itself, but for many use cases, "does work" is way more important than speed, and I have a gut feeling "postcard + schema" might be smaller than just JSON for non-trivial objects, and MIGHT be faster even with a "schema interpreter" in various languages)
<re_irc>
< (@jamesmunns:beeper.com)> but again - having schema info "on the side" means you can ignore it when you already have mutually-agreed "native" ser/de. No worries if this part doesn't make sense, but also happy to explain it :)
<re_irc>
<riskable> Generic rust question: Is there a way I can specify that a "--bin" option is _mandatory_ when running "cargo build" or "cargo run"? So it doesn't try to build five zillion different directories inside "src/bin" if someone forgets to specify the one they want to build with "--bin"
<re_irc>
< (@jamesmunns:beeper.com)> I don't think theres a "default bin", no
<re_irc>
< (@jamesmunns:beeper.com)> you maybe could do some hacks with features (each bin requires a feature, the lib checks at least one of the features is set), and fail a build faster that way
<re_irc>
< (@jamesmunns:beeper.com)> (or all the bins just require "bin_is_selected" as a feature or something)
<re_irc>
<mr_trester> : I'm using an older rustc version, this shouldn't be happening according to this issue
<re_irc>
< (@jamesmunns:beeper.com)> dkhayes117 (Daniel): That being said, if you wanna intro me to to golioth folks, and they might be interested in supporting another format, I'm more than happy to chat :D
<re_irc>
< (@jamesmunns:beeper.com)> (but again, they'd need the actual message schema, sorta like ".proto" files in protobuf to be able to decode any messages. At least until I add this "schema on the side" stuff)
<re_irc>
<dkhayes117 (Daniel)> riskable: you can add alias commands in ".cargo/config.toml", but that may not exactly useful for you in this situation.
<re_irc>
rb = "run --bin"
<re_irc>
[alias]
<re_irc>
rrb = "run --release --bin"
<re_irc>
cargo rrb app
<re_irc>
< (@jamesmunns:beeper.com)> oh, maybe I'm full of crap?
<re_irc>
< (@jamesmunns:beeper.com)> that doesn't make THEM specify a bin, but at least you can pick the one you want to build when they don't (instead of "all"?)
<re_irc>
<dkhayes117 (Daniel)> TIL
<re_irc>
< (@jamesmunns:beeper.com)> : Looking at https://github.com/stepchowfun/typical#summary-of-what-kinds-of-schema-changes-are-safe as a reference, at least what I plan right now, all of those should be supported on std targets (tho I haven't defined "optional" or "asymmetric" fields - they'd probably be interpreted as "impls Default"), and I don't _think_ I could support reordering fields on no-std targets, but maybe.
<re_irc>
< (@jamesmunns:beeper.com)> (this is because I don't have the concept of "field indicies")
<re_irc>
<dkhayes117 (Daniel)> : I don't know them very well yet. I'm porting Lachlan's test rust lib, golioth-rs, to use "Embassy" and "nrf-modem". I'll be submitting the PR soon, so I can plant that seed afterwards :)
<re_irc>
< (@jamesmunns:beeper.com)> as the data is expected to appear in the order it was specified in the struct itself.
<re_irc>
< (@jamesmunns:beeper.com)> also that distinction between "optional" and "asymmetric" is neat.
<re_irc>
< (@jamesmunns:beeper.com)> (I might totally steal+cite that)
<re_irc>
< (@jamesmunns:beeper.com)> having a defined order is a huge gain for performance, you can guarantee to ser/de in a single pass with no "scroll back".
<re_irc>
< (@jamesmunns:beeper.com)> which also makes things WAY easier with no heap.
<re_irc>
<riskable> dkhayes117 (Daniel): Ooh this is an interesting option!
<re_irc>
<riskable> What I'm probably going to end up doing is make a "build.sh" or "build.py" script that acts as a sort of wizard that lets the user select which board they want to build for
<re_irc>
<riskable> I just thought of a different one, actually... I'm already using a "build.rs". I bet I can just do a command line arguments check in there and have it exit out if the user didn't specify a "--bin" option
<re_irc>
<riskable> I have an stm32f4xx_hal firmware that I recently updated to the latest & greatest of all dependencies (RTIC, stm32f4xx_hal, etc) _but now it doesn't work in Windows_ (only just noticed this). Works fine in Linux though! Anyone have any clues as to what might cause this or what to look for?
<re_irc>
< (@datdenkikniet:matrix.org)> can you define "doesn't work"?
<re_irc>
< (@datdenkikniet:matrix.org)> * work" a bit more?
<re_irc>
<riskable> : No keystrokes show up and in fact, the whole keyboard seems to hang if I press a single key (meaning: it seems to hang when trying to send a Keyboard HID report)
<re_irc>
<riskable> I set a debug statement to print every time it tries to send the keyboard report and that seems to be right where it hangs (or maybe when calling the "usb_dev.poll()" function)
<re_irc>
<riskable> This is the specific line it hangs on:
<re_irc>
while let Ok(0) = usb_keyboard.write(report.as_bytes()) {}
<re_irc>
<riskable> (and "usb_keyboard" is " &mut HidClass<UsbBus<USB>, Keyboard<()>>")
<re_irc>
<riskable> I discovered something... I added a check, "if usb_key_dev.state() == usb_device::device::UsbDeviceState::Configured { <send keyboard report here> }" and it looks like when I plug the keyboard into windows that check never succeeds. Meaning, the keyboard is never getting "Configured" properly in Windows. Maybe someone can give clues as to what could cause that? 🥺
<corecode>
riskable: do you look at the USB packet trace?
<re_irc>
< (@chemicstry:matrix.org)> Does your keyboard show up as HID device in windows device manager?
<corecode>
riskable: it could be that windows doesn't like one of the descriptors or expects a transaction to succeed that doesn't
<re_irc>
<riskable> : That's a good question. I've only been testing at the login prompt (gotta go plug in a separate keyboard I guess hehe)
<re_irc>
< (@chemicstry:matrix.org)> there is a useful usbview tool in windows sdk to debug descriptor problems
<re_irc>
< (@chemicstry:matrix.org)> it's in "C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\usbview.exe" if you have windows sdk installed
<re_irc>
<riskable> Windows Device Manager says, "A device which does not exist was specified"
<re_irc>
<riskable> Maybe it doesn't like my VID/PID? idVendor=16c0, idProduct=27db
<re_irc>
<riskable> Aha! I figured it out while blankly staring at the code and a bit of intuition. The problem is with this:
<re_irc>
let usb_key_dev = UsbDeviceBuilder::new(unsafe { USB_BUS.as_ref().unwrap() }, usb_vid_pid)
<re_irc>
< (@jamesmunns:beeper.com)> Utf8 text in a descriptor field instead of urf16?
<re_irc>
< (@jamesmunns:beeper.com)> * utf16?
<re_irc>
< (@dirbaio:matrix.org)> oh no ☠️
<re_irc>
<riskable> : It's the use of 🖮 (unicode keyboard character) in the serial number string
<re_irc>
< (@jamesmunns:beeper.com)> I don't have the font for that on my phone, so I just see a box with an X lol
<re_irc>
<riskable> The spec just says the serial number just needs to be a unicode string (not sure the encoding). The spec for mass storage devices is more specific and says the last 12 characters can only be 0-9 and A-F (which is wacky)
<re_irc>
<riskable> Interestingly, I can't find a max length anywhere in the USB spec 🤷
<re_irc>
< (@jamesmunns:beeper.com)> I thiiiiink some USB stuff is ucs-2, not even utf16?
<re_irc>
< (@jamesmunns:beeper.com)> Can't cite that at the moment tho. Wouldn't be surprised if Linux tried to detect encoding (or ignored it?) When windows is just stubborn?
<re_irc>
< (@jamesmunns:beeper.com)> Length being even makes sense for ucs-2, every char is 16 bits
<re_irc>
<thejpster> If it's UCS-2, even number of _bytes_ makes sense.
<re_irc>
<thejpster> I think it's a bit more useful now - decoding PS/2 bitstreams, processing Scan Codes into KeyEvents and decoding KeyEvents according to your current layout are now all different types.
<re_irc>
<riskable> Can't have commas. The Unicode space Microsoft allows is 0x20-0x7F
<re_irc>
< (@dirbaio:matrix.org)> so, no unicode :P
<re_irc>
< (@dirbaio:matrix.org)> * unicode?
<re_irc>
< (@dirbaio:matrix.org)> just ascii 🤪
<re_irc>
< (@dirbaio:matrix.org)> but as utf16 because they love their 0x00 bytes