crabbedhaloablut has quit [Quit: No Ping reply in 180 seconds.]
crabbedhaloablut has joined #rust-embedded
<re_irc>
< (@imrank03:matrix.org)> : : Thank you.
<re_irc>
<Félix | Totem> Can I get channels in a stm32? I get some bytes inside my Class, and I'd like to send them to the Device. Do you have any advice'
<re_irc>
<Félix | Totem> * advice?
<re_irc>
<Félix | Totem> * UsbClass, and I'd like to send them to the UsbDevice to be consumed later.
<re_irc>
<Félix | Totem> Unless my architecture isn't right. I still have a hard time understanding what I'm supposed to de.
<re_irc>
<Félix | Totem> * do.
<re_irc>
<Félix | Totem> * do to communicate through USB.
<re_irc>
< (@k900:0upti.me)> You can implement both on the same struct and buffer data inside
<re_irc>
<Félix | Totem> Unless I'm mistaken, I create the class struct myself, then I implement the "UsbClass" trait, but "UsbDevice" is a concrete type. Do you advice me to have it inside my class type? Is it normal conceptually that the class “owns” the device?
<re_irc>
<Félix | Totem> : It looks like it should flow the other way around: a device has a class, not the opposite.
starblue has quit [Ping timeout: 265 seconds]
starblue has joined #rust-embedded
<re_irc>
< (@jamesmunns:beeper.com)> pointed out to me that supporting unaligned access is optional in the cortex-m spec!
<re_irc>
I've definitely seen targets that WILL hard fault, but I admit to not testing every one :D
<re_irc>
< (@jamesmunns:beeper.com)> That being said, I think it's still ub to use a reference to access unaligned data, as rust references are guaranteed to be well aligned
<re_irc>
<Félix | Totem> That would be cool to have a generic HID library in Rust, but it's a huuuge thing. There is a ton of stuff in the spec, even in the Report Descriptor only.
<re_irc>
< (@jamesmunns:beeper.com)> Usually crates compatible with the usb-device traits will start with "usbd"
<re_irc>
<Félix | Totem> : Oh, that's nice! It's a very small subset of the spec, but it's useful to me nevertheless.
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc>
< (@jamesmunns:beeper.com)> Might be a start! There are often quite a few "just enough for X use case" crates in embedded rust, but being able to contribute (or fork and extend, most crates are mit/apache2), is a great place to start :)
<re_irc>
< (@korken89:matrix.org)> Punches have been thrown our way :D
<re_irc>
< (@k900:0upti.me)> Wow, this is A Take
<re_irc>
< (@k900:0upti.me)> Like, they just went from "Look at the silly Rust people rewriting things in Rust because they're scared of C! I'll do the smart thing and bind Rust to existing C code instead!" to "I just wrote 1k lines of binding code and the toolchain sucks! Why would the Rust people do that to me?"
<re_irc>
< (@k900:0upti.me)> And it never clicked
<re_irc>
< (@ryan-summers:matrix.org)> Also, no one is claiming that these old, mature C projects are actually good and stable... They have tons of bugs
<re_irc>
<thejpster> > RTIC is “a pseudo scheduler that relies on async/wait and makes thing looks like magic there
<re_irc>
<thejpster> Wut
<re_irc>
< (@k900:0upti.me)> At least for that case I can understand "we've been running this in prod for years and nothing exploded"
<re_irc>
< (@k900:0upti.me)> Like sure there's probably bugs and there's probably more of them, but having real experience with a thing _is_ valuable and old school embedded people care about this a lot
<re_irc>
< (@ryan-summers:matrix.org)> I've been running these "unproven" rust crates in production for years and nothing exploded either. They just wrote something off as "new and untested"
<re_irc>
< (@k900:0upti.me)> I mean I'm not saying they're 100% right
<re_irc>
< (@k900:0upti.me)> But I am saying there's a point to that and that point alone wouldn't have made me dunk on them
<re_irc>
<Félix | Totem> I'm writing a (non-trivial) firmware with no experience with embedded development; I don't use a debugger; and I can move forward pretty well. There is no crash, no weird shenanigan.
<re_irc>
I think that only Rust allows to do that today.
<re_irc>
< (@k900:0upti.me)> That point is at least _debatable_
<re_irc>
< (@k900:0upti.me)> As in we can actually have conversations about this
<re_irc>
< (@k900:0upti.me)> That are useful
<re_irc>
< (@ryan-summers:matrix.org)> This really sounds like someone who wanted to continue using zephyr at all costs, but hates C/C++
dc740 has joined #rust-embedded
<re_irc>
< (@dirbaio:matrix.org)> he either got a time machine or is confusing rtic with embassy?
<re_irc>
< (@luojia65:matrix.org)> I'm looking for some chips to adapt RustSBI onto it
<re_irc>
< (@korken89:matrix.org)> : I think he is a bit, at least HALs 😅
dc740 has quit [Remote host closed the connection]
dc740 has joined #rust-embedded
<cr1901>
ryan-summers: Aside from the RTIC gaffe, I'm not sure I see the issue with the observation "the Rust ppl like to do things from scratch, and not everyone shares that sentiment"
<cr1901>
But I also think while corrosion is cool, bindgen is a PITA, and writing C bindings manually is also a PITA :P
<re_irc>
< (@jamesmunns:beeper.com)> Honestly: using multiple languages _is_ harder than using just one. FFI is a "least bad" choice, not a "first" choice, IMO.
<re_irc>
< (@jamesmunns:beeper.com)> Any time you are using two languages, you HAVE to be an expert at both at the boundaries. You can do a good job of keeping those boundaries small and strict, but this isn't always the simplest/easiest thing to do.
<re_irc>
< (@jamesmunns:beeper.com)> For some projects, where there is a HUGE amount of existing code (that is good, and worth saving), FFI is a reasonable choice. For relatively small projects? It's really not a good idea.
dc740 has quit [Remote host closed the connection]
<re_irc>
<Félix | Totem> I try and use the usbd-serial crate to communicate with the host, but the line where I create the port crashes the program:
<re_irc>
let usb_device = UsbDeviceBuilder::new(usb_bus, UsbVidPid(0x16c0, 0x27dd))
<re_irc>
< (@chemicstry:matrix.org)> is it a hardfault or a panic? what are you using to run program? most tools should give a panic message
<re_irc>
<Félix | Totem> : The issue is that I use no debugger, only the manufacturer tool to flash the keyboard. I use a led system to know which line crashes.
<re_irc>
Yeah, I know, maybe I should use a proper tool…
<re_irc>
< (@chemicstry:matrix.org)> oof, yeah that's hard. What kind of MCU is that? It could be that USB buffer is too small (if driver uses it) or something similar
<re_irc>
<Félix | Totem> : Oh, that may explain why… The program is very picky with the order I setup things.
<re_irc>
< (@chemicstry:matrix.org)> speaking of bindings topic, has anyone found a solution that works for complex C++ libraries with a lot of templates? I tried bindgen, cxx, but it was impossible to generate anything. Ended up writing a C wrapper, which could be parsed by bindgen, so it was C++ -> C -> Rust. Most of the C adapter is interfacing with STL containers. Any other options?
<re_irc>
< (@k900:0upti.me)> MappingSTL containers to Rust directly will be _extremely_ painful
<re_irc>
< (@k900:0upti.me)> * Mapping STL
<re_irc>
< (@k900:0upti.me)> Would definitely not recommend trying
<re_irc>
< (@chemicstry:matrix.org)> yeah.. but the lib uses them extensively (libcamera)
<re_irc>
<Félix | Totem> : It worked, thanks! It feels so random, in an example I was reading, the order is different…
<re_irc>
<Félix | Totem> Is there an overview somewhere where I can understand the big picture of USB communication? From what I understand:
<re_irc>
There are controls, which mean communication between host & device (the code must be in the impl of "UsbClass" trait):
<re_irc>
- “control out” is from the host to the device: at that moment, I must read what the host wants to communicate. For a keyboard, for example, it tells me to turn a led on/off because the state of a modifier has changed (_e.g._ num lock).
<re_irc>
- “control in” is from the device to the host. I must then take the events I have registered (_e.g._ keypresses), and send them to the host. I do that with "xfer.accept_with(my_bytes)".
<re_irc>
The problem is: what does “accept_with” really mean? The doc says “Accepts the transfer with the supplied buffer.” which isn't really clear. Also, am I not supposed to write in the serial port? Why are there 2 places where it looks like I can write to the host?
<re_irc>
< (@adamgreig:matrix.org)> for USB itself, https://beyondlogic.org/usbnutshell/usb1.shtml chapters 4 and 5 might provide some useful background about what control transfers are and what gets initiated by the host and stuff, though it has more detail than you'll really want
<re_irc>
< (@adamgreig:matrix.org)> for "accept_with", you've got a ControlIn transfer that's been received from the host, and you have to decide whether to STALL it (which tells the host you can't reply right now), or ACK it with some response data, which is why it's called "accept_with"
<re_irc>
<Félix | Totem> : Does the host get the data at that moment?
<re_irc>
< (@adamgreig:matrix.org)> you're accepting instead of rejecting the transfer, and "with" means "with this provided buffer of response data" (other options are plain "accept" to have a callback instead, or "accept_with_static" if you have a static buffer)
<re_irc>
< (@adamgreig:matrix.org)> it will get it shortly after you call accept_with, yea, though I guess the exact timing depends on the implementation
<re_irc>
<Félix | Totem> : So what's the serial stuff is used for? Am I keeping this variable "let usb_serial = usbd_serial::SerialPort::new(usb_bus);" for nothing?
<re_irc>
<Félix | Totem> +around
<re_irc>
< (@adamgreig:matrix.org)> control transfers are at a raw USB level, just sending raw packets back and forth
<re_irc>
< (@adamgreig:matrix.org)> there's no concept of a "usb serial port" or anything else there, the computer would need some sort of driver to make sense of the data, or you need to write formatted packets for whatever protocol you've already set up, like HID or CDC ACM for serial
<re_irc>
< (@adamgreig:matrix.org)> the usbd_serial crate implements the standard protocol for putting a "serial port" through usb
<re_irc>
<Félix | Totem> : It's HID
<re_irc>
< (@adamgreig:matrix.org)> so it will call accept_with internally to handle the transfer (though in practice I think it will be using bulk transfers for the actual data)
<re_irc>
< (@adamgreig:matrix.org)> well the usb_serial isn't HID
<re_irc>
< (@adamgreig:matrix.org)> but the keyboard part will be - if you're implementing HID yourself you need to call accept_with and supply it a HID format packet to respond with
<re_irc>
<Félix | Totem> : Ahah, that explains why it doesn't work 😅
<re_irc>
<Félix | Totem> : That's what I do
<re_irc>
< (@adamgreig:matrix.org)> aah, so usb_serial is for devices that simulate a serial port, like COM0 or /dev/ttyUSB0 etc
<re_irc>
< (@adamgreig:matrix.org)> you can eventually send data back and forth and on the computer your software just treats it like a serial port, so it's a popular and easy way to talk to devices, although there's no built-in way to delimit packets etc
<re_irc>
<Félix | Totem> : So I can ditch this part, it's not useful for my HID implementation
<re_irc>
< (@adamgreig:matrix.org)> HID is a totally separate protocol for things like keyboards and mice, I thought there was probably a crate to do that for you to but maybe you want to implement it yourself
<re_irc>
< (@adamgreig:matrix.org)> oh, room, meeting time again! first of 2023 🎉 agenda is https://hackmd.io/-decNcthQjGtTSUUq-g7jQ, please add anything you'd like to announce or discuss and we'll start in a few mins :)
<re_irc>
< (@adamgreig:matrix.org)> in which case that "usb in a nutshell" page might be worth going through in a bit more detail, though I don't think it quite covers HID itself?
<re_irc>
< (@adamgreig:matrix.org)> hopefully you have the HID spec open
<re_irc>
< (@dkhayes117:matrix.org)> EmbeddedNoob on Twitter
<re_irc>
< (@jamesmunns:beeper.com)> : Always happy to chat :)
<re_irc>
< (@dkhayes117:matrix.org)> : Definately
<re_irc>
< (@dkhayes117:matrix.org)> Daniel Mangum expressed interest in being a co-host
<re_irc>
< (@therealprof:matrix.org)> Your channel is a bit desserted... 😬
<re_irc>
< (@adamgreig:matrix.org)> I have a couple of brief release announcements, svd2rust 0.28 is out with some tweaks to atomic access generation using the experimental "--atomics" flag, and aarch64-cpu has a couple of releases with some small tweaks
<re_irc>
< (@dkhayes117:matrix.org)> : I haven't started yet :)
<re_irc>
< (@adamgreig:matrix.org)> thanks everyone who posted some updates in the this-year-in-embedded-rust 2022 issue thread, I've been meaning to collate them and wg updates into one post but haven't managed yet, should get a pr together for that soon
<re_irc>
< (@adamgreig:matrix.org)> there's also the new social media policy pr in https://github.com/rust-embedded/wg/pull/651 which I think is probably good to go, I'll post a comment there reminding people to comment/vote on it after the meeting
<re_irc>
< (@adamgreig:matrix.org)> oh, and cortex-m 0.7.7 was released with just a documentation fix to talk about the critical-section-single-core feature flag
<re_irc>
< (@adamgreig:matrix.org)> any other announcements?
<re_irc>
< (@jamesmunns:beeper.com)> There's gonna be a rust point release to fix a cargo vuln
<re_irc>
< (@jamesmunns:beeper.com)> (git deps not checking host names or something like that, might want to apply it once it drops)
<re_irc>
< (@therealprof:matrix.org)> : Needs an update re mastodon
<re_irc>
< (@jamesmunns:beeper.com)> Btw, misc lowprio question, would there be any reason not to have svd2rust add non_exhaustive to the generated Peripherals struct?
<re_irc>
< (@adamgreig:matrix.org)> cargo doesn't check host ssh certs when cloning git over ssh
<re_irc>
< (@jamesmunns:beeper.com)> Someone noted adding fields is a technically breaking change
<re_irc>
< (@therealprof:matrix.org)> : BTW: This happened to break the micro:bit crate CI. It's fixed now but I guess I should do a release.
<re_irc>
< (@adamgreig:matrix.org)> wow, how did it break it?
<re_irc>
< (@adamgreig:matrix.org)> the only change was to the docstring...
<re_irc>
< (@adamgreig:matrix.org)> : I don't see why it couldn't, although pretty much every change to a pac is probably a breaking change anyway...
<re_irc>
< (@adamgreig:matrix.org)> I guess that's not fair, but a lot of them are 😅
<re_irc>
< (@therealprof:matrix.org)> : Not the docs, the flag. Not exactly sure how but it seems some of the magic exploded.
<re_irc>
< (@adamgreig:matrix.org)> the flag's been there since 0.7.6 in august, was it that one that broke the ci or 0.7.7?
<re_irc>
< (@adamgreig:matrix.org)> or are you actually getting the break because of using something that requires critical-section impl and didn't have one enabled?
<re_irc>
< (@therealprof:matrix.org)> I don't know when exactly it broke. It's not exactly high frequency so CI might not have been run for a while.
<re_irc>
< (@therealprof:matrix.org)> : I guess that might have been it.
<re_irc>
< (@jamesmunns:beeper.com)> : Yeah, this would in the case of adding a whole peripheral that was missing from the SVD (app protect on the nrf52)
<re_irc>
< (@grantm11235:matrix.org)> In other news, I just finished reading Mara Bos's new book about atomics. I highly recommend it, it is available for free on her website https://marabos.nl/atomics/
<re_irc>
< (@therealprof:matrix.org)> Was a bit annoying to fix since I had to multiple places and then ran into a macOS specific linker issue again...
<re_irc>
< (@therealprof:matrix.org)> +in
<re_irc>
< (@adamgreig:matrix.org)> got a link to the fix? if it was the missing flag then we definitely did a poor job of that breaking change given how many people _in the cortex-m team_ hit it unexpectedly 😅
<re_irc>
< (@therealprof:matrix.org)> Just wanted to say, the greatest annoyance we envisioned might happen, did happen. 😉
<re_irc>
< (@adamgreig:matrix.org)> well, at least 0.7.7 includes that flag in the docs, I guess!
<re_irc>
< (@adamgreig:matrix.org)> in other c-m news, the c-m-rt PR to add zero-initialising the whole RAM section has been updated in https://github.com/rust-embedded/cortex-m/pull/455 if anyone wants to have a look
<re_irc>
< (@jamesmunns:beeper.com)> Misc note, is that zeroing bss twice then?
<re_irc>
< (@adamgreig:matrix.org)> final c-m question is whether the newly renamed embedded-alloc (previously alloc-cortex-m) crate should continue to be maintained by the cortex-m team or instead by the hal team, since it's now generally applicable
<re_irc>
< (@adamgreig:matrix.org)> yea, it will be
<re_irc>
< (@adamgreig:matrix.org)> seems quite annoying to avoid in general since bss is a hole in the middle of the whole section
<cr1901>
Startup latency is prob negligible
<re_irc>
< (@adamgreig:matrix.org)> for writing the entire RAM? idk...
<re_irc>
< (@adamgreig:matrix.org)> it's possible this should actually be moved to after the call to pre_init
<re_irc>
< (@jamesmunns:beeper.com)> Also, misc note that I've run into before, if you have a LOT of ram, you might end up running into wdt problems
<re_irc>
< (@therealprof:matrix.org)> cr1901: Only in release mode. 🤪
<re_irc>
< (@adamgreig:matrix.org)> yea
<re_irc>
< (@adamgreig:matrix.org)> or "ram not being power gated yet" problems
<cr1901>
ahhh right
<re_irc>
< (@adamgreig:matrix.org)> : this is all in hand written assembly, rustc doesn't come into it?
<re_irc>
< (@jamesmunns:beeper.com)> I had that (tho with ram self test) in a product befpre
<cr1901>
ram not being power gated problems?
<re_irc>
< (@jamesmunns:beeper.com)> * before
<re_irc>
< (@adamgreig:matrix.org)> the downside is that a pre_init function might need to access ram and then fault if it hasn't already been zeroed, heh
<re_irc>
< (@therealprof:matrix.org)> : Oh rights, sorry, was thinking of the traditional startup code.
<re_irc>
< (@therealprof:matrix.org)> * right,
<re_irc>
< (@adamgreig:matrix.org)> cr1901: as in, the "RAM" section in the linker script which this feature would initialise, might not be accessible before pre_init runs to configure it/turn it on/whatever
<re_irc>
< (@jamesmunns:beeper.com)> 32M -> 64M ram, device now boot loops because wdt kicks 3/4 the way through the self test :p
<re_irc>
< (@adamgreig:matrix.org)> all the startup code is in hand written assembly now
<re_irc>
< (@adamgreig:matrix.org)> so yea, idk, it would be annoying to need two separate pre_init methods though
<cr1901>
Ahhh
<re_irc>
< (@adamgreig:matrix.org)> and so the quadratic interplay of the optional features starts to bite, heh
<cr1901>
pre_init/pre_init2
<re_irc>
< (@jamesmunns:beeper.com)> Anyway, always edge cases, this seems like a reasonable option, pre init hook is always still there.
<cr1901>
it worked just fine for the GNU ppl
<re_irc>
< (@adamgreig:matrix.org)> it's there but it's after the memory all gets zeroed, so if that does take too long and the wdt triggers you're stuffedish
<re_irc>
< (@adamgreig:matrix.org)> I mean you can fork c-m-rt or whatever
<re_irc>
< (@jamesmunns:beeper.com)> If you really care, forking cmrt is probably pretty reasonable
<re_irc>
< (@jamesmunns:beeper.com)> Yeah
<re_irc>
< (@adamgreig:matrix.org)> or use a bootloader
<re_irc>
< (@adamgreig:matrix.org)> the other consideration is that people sometimes like to configure clocks before initialising memory to speed it up, but again, eh
<re_irc>
< (@jamesmunns:beeper.com)> Some day we'll get weak symbols so you can just linker smash certain asm bits away
<re_irc>
< (@therealprof:matrix.org)> : Bootloader disables the watchdog?
<re_irc>
< (@adamgreig:matrix.org)> or bootloader zeros the ram, I don't mind either way :P
emerent has quit [Ping timeout: 248 seconds]
<cr1901>
jamesmunns: Idk how weak symbols helps here, but msp430 binutils has special linker/assembler directives to remove startup code if you don't use .data/.bss
<re_irc>
< (@jamesmunns:beeper.com)> I'll add a comment about maybe not doing the bss zero step if the all zeros flag is set.
<re_irc>
< (@therealprof:matrix.org)> Write a 0xffffffff into the last address to indicate the zeroing has already been done. 😉
<re_irc>
< (@adamgreig:matrix.org)> oh huh, yea, we could just skip it
<re_irc>
< (@adamgreig:matrix.org)> : the code that does the bss zeroing is in the same assembly block as the code that zeroes all the ram, so it can be configured by the same feature flags
<re_irc>
< (@adamgreig:matrix.org)> (i.e. statically at compile-time)
<re_irc>
< (@therealprof:matrix.org)> Sure.
<re_irc>
< (@adamgreig:matrix.org)> right now "bss" is necessarily inside RAM right?
<re_irc>
< (@jamesmunns:beeper.com)> uhhh, unless you have funky non-contiguous ram, which I don't think we support anyway
<re_irc>
< (@jamesmunns:beeper.com)> bss is a ram thing tho
<re_irc>
< (@adamgreig:matrix.org)> you can configure extra sections in memory.x and place variables inside them, but everything that c-m-rt initialises in bss will always be in the RAM section, which is the same as what's getting zeroed here
<re_irc>
< (@adamgreig:matrix.org)> (it's a long standing feature request that it would be nice to have the bss/data loader initialise other sections too, since otherwise it's sort of UBy to use link_section to put a static in some other section that's not initialised...)
<re_irc>
< (@adamgreig:matrix.org)> (but we don't do that at the moment, so it should be safe to skip zeroing bss here)
<re_irc>
< (@therealprof:matrix.org)> Just saying, the point is to overwrite all memory with a sane value; typically it doesn't matter what you do afterwards so you might as well write a different sentinel value which could be used by later running code to determine that everything is a-ok.
<re_irc>
< (@adamgreig:matrix.org)> on this point, my feeling is that since it's not a trait, it's just an actual utility library for linking into your program, it's not an obvious fit for the hal team, but obviously it's now more applicable than the cortex-m team alone and we don't have a team that covers such things really
<re_irc>
< (@therealprof:matrix.org)> Either works for me.
<re_irc>
< (@adamgreig:matrix.org)> huh, the message I was replying to vanished, it was this
<re_irc>
< (@adamgreig:matrix.org)> I guess let's leave it for the time being then.
<re_irc>
< (@adamgreig:matrix.org)> I don't seem to be making any headway there though so if anyone else has thoughts about it (including potentially just keeping what we have...) that'd be welcome
<re_irc>
<riskable> I broke something in some old code and now I'm getting errors about the various "mhz()" calls everywhere like this:
<re_irc>
no method named `mhz` found for type `{integer}` in the current scope
<re_irc>
I completely forget how to fix this
<re_irc>
<riskable> It's an stm32f4xx_hal project
<re_irc>
< (@newam:matrix.org)> Need to find the trait and add a "use ...;" for the trait
<re_irc>
< (@jamesmunns:beeper.com)> (might want to save that question until after the meeting riskable)
<re_irc>
< (@adamgreig:matrix.org)> I think probably it's fugit's trait in latest stm32f4xx-hal?
<re_irc>
< (@adamgreig:matrix.org)> since we're near the end of the hour and not many HAL team people are here, now's probably not the best time to discuss it in a meeting, but it would be good to get it on the issue thread I think
<re_irc>
< (@jamesmunns:beeper.com)> (focusing on "can atomically load/store" instead of "has atomic ops")
<re_irc>
< (@grantm11235:matrix.org)> : Sounds good. If anyone wants to discuss it after the meeting, let me know
<re_irc>
< (@jamesmunns:beeper.com)> CAS operations are an LLVM polyfill anyway.
<re_irc>
< (@adamgreig:matrix.org)> I think the issue is mostly a terminology confusion, ARM talk about atomic access only in the sense that thumbv6 and thumbv7 both have, and the ldrex stuff is all about exclusive, but the person opening the issue considers atomics only in the C++ sort of sense, and doesn't want to say CAS either
<re_irc>
< (@adamgreig:matrix.org)> rust of course uses atomic to mean both load/store and the CAS-etc operations that require exclusive instructions on arm
<re_irc>
< (@jamesmunns:beeper.com)> Yeah, we include CAS there mostly to introduce the terminology since it's used elsewhere
<re_irc>
< (@adamgreig:matrix.org)> thanks for adding the comment anyway :)
<re_irc>
< (@adamgreig:matrix.org)> anything else anyone wants to discuss in the last few minutes?
<re_irc>
< (@jamesmunns:beeper.com)> oh, I wrote this
<re_irc>
< (@jamesmunns:beeper.com)> blame me anyway, I guess :)
<re_irc>
<Félix | Totem> riskable: BTW, it's really weird that hz, khz, mhz are distinct types. It doesn't really make a lot of sense.
<re_irc>
< (@adamgreig:matrix.org)> yea, I linked to that PR in my first comment in the thread :P
<re_irc>
< (@jamesmunns:beeper.com)> oops :D
<re_irc>
< (@adamgreig:matrix.org)> I don't think your PR is wrong though...
<re_irc>
< (@jamesmunns:beeper.com)> I was like "this feels _really_ familiar" when I was editing the suggestion
<re_irc>
< (@adamgreig:matrix.org)> but I guess I can see how saying it provides CAS "instructions" blurs the lines a bit
<re_irc>
< (@adamgreig:matrix.org)> hehe
<re_irc>
< (@adamgreig:matrix.org)> Félix | Totem: they're not different types, at least in the fugit library that stm32f4xx-hal uses now: they're methods that get added onto u32 as a convenience, so you can write "32.MHz()" to get a "fugit::Rate" type at that frequency
<re_irc>
<Félix | Totem> : I wonder which one I used, but I got an error like: expected Mhz, got Hz
<re_irc>
< (@jamesmunns:beeper.com)> : Yeah, tbh rust doesn't distinguish between "has an instruction for" and "can perform". thumbv7 is all llvm intrinsics based on ldrex/strex, while on x86 it might be a single op, or on armv5te it might be a kernel stub.
<re_irc>
< (@jamesmunns:beeper.com)> Now I need a shirt/bumper sticker that just says "Ask me about my Atomic Capabilities" :p
<re_irc>
< (@grantm11235:matrix.org)> The new atomics book has a whole chapter about what instructions the compiler uses for different atomic operations https://marabos.nl/atomics/hardware.html
<re_irc>
< (@adamgreig:matrix.org)> for ARM64, which actually has specific CAS instructions, lol
<re_irc>
< (@adamgreig:matrix.org)> ldrex/strex are thumb-only and don't appear in arm64 iirc?
<re_irc>
< (@grantm11235:matrix.org)> With a nifty cheatsheet at the end
<re_irc>
< (@adamgreig:matrix.org)> anyway, that's it for this meeting, thanks everyone!
<re_irc>
<Félix | Totem> : That's some Matrix shit right there. The guy is looking at the signal on the oscilloscope, and he knows which packet is sent.
<re_irc>
<Félix | Totem> * Matrix-level
<re_irc>
< (@therealprof:matrix.org)> Félix | Totem: Some people try what they want to present before hitting record so they can anticipate things happening. 😉
<re_irc>
< (@jamesmunns:beeper.com)> : Example with thumb polyfilled loops:
<re_irc>
BTW, this hardware is incredibly cool, especially compared to the primitive stuff I used back in school.
<re_irc>
<Félix | Totem> I'm still impressed 🤯
<re_irc>
<Félix | Totem> > Some people try what they want to present before hitting record so they can anticipate things happening. 😉
<re_irc>
I'm still impressed 🤯
<re_irc>
BTW, this hardware is incredibly cool, especially compared to the primitive stuff I used back in school.
<re_irc>
<Ralph> riskable: at some point with some update it changed to "MHz" (instead of "mhz"). same for other such methods ("hz"-> "Hz", etc.)
<re_irc>
<Félix | Totem> Ralph: Do you know why? It's not standard Rust format. A bit surprising.
<re_irc>
< (@jamesmunns:beeper.com)> Before all the hals had their own (copy/pasted) integer-to-frequency types, then the fugit crate came around, so the impls could be shared
<re_irc>
<Ralph> not the slightest clue. i just know that now it's "MHz" and have seen builds breaking in older projects (not mine) when upgrading, thus i know that this changed at some point
<re_irc>
< (@jamesmunns:beeper.com)> (at least, all the stm32 crates, I don't think the nrf52 ever had types like that)
* re_irc
(@evils:nixos.dev) hopes it's to distinguish MHz from mHz
<re_irc>
< (@jamesmunns:beeper.com)> this is like when someone complains that used the wrong s/S for seconds/Siemens
<re_irc>
< (@evils:nixos.dev)> hey, my multimeter can do up to 0.1MS... (not megasamples)
<re_irc>
< (@grantm11235:matrix.org)> Also, it looks like embedded_time supports kibihertz lol
<re_irc>
< (@korken89:matrix.org)> Félix | Totem: I made the change and it's quite trivial why
<re_irc>
< (@korken89:matrix.org)> Follow SI units
<re_irc>
< (@korken89:matrix.org)> mhz vis MHz
<re_irc>
< (@korken89:matrix.org)> milli hertz? mega hertz?
<re_irc>
< (@korken89:matrix.org)> Etc
<re_irc>
< (@korken89:matrix.org)> So just use that the entire scientific community uses :)
<re_irc>
< (@evils:nixos.dev)> * 0.1mS...
<re_irc>
< (@korken89:matrix.org)> No chance for misunderstandings
<re_irc>
< (@jamesmunns:beeper.com)> (extension traits are the devil and it should have been "Megahertz::from(10u32)" anyway :D )
<re_irc>
< (@korken89:matrix.org)> Those exist as well
<re_irc>
< (@korken89:matrix.org)> The extension traits only call those
<re_irc>
<Félix | Totem> Makes sense. So, do you know why Hertz, Kilohertz, etc. are distinct types?
<re_irc>
< (@korken89:matrix.org)> They are not
<re_irc>
< (@grantm11235:matrix.org)> : I'll go one further: "Hertz::mhz(10)"
<re_irc>
< (@korken89:matrix.org)> A "fugit" type is defined as "Duration<STORAGE, NUMERATOR, DENOMINATOR>" so it represents "N/D * 1 second" for example
<re_irc>
<Félix | Totem> : It means fly away in latin
<re_irc>
< (@korken89:matrix.org)> "tempus" was taken
<re_irc>
< (@korken89:matrix.org)> Soooo
<re_irc>
< (@korken89:matrix.org)> "fugit" it is
<re_irc>
< (@korken89:matrix.org)> :)
<re_irc>
< (@jamesmunns:beeper.com)> at least in american english, "fuggit" is a pretty common variant of "fuck it". Use like, "oh, fuggit."
<re_irc>
< (@k900:0upti.me)> I think it's pronounced "foo-git"?
<re_irc>
< (@jamesmunns:beeper.com)> In latin? probably. The slang was my first thought, not latin tho lol
<re_irc>
< (@k900:0upti.me)> (obligatory we don't know how to pronounce Latin correctly anyway)
<re_irc>
< (@korken89:matrix.org)> Haha
<re_irc>
< (@korken89:matrix.org)> Well, at least it's crazy efficient
<re_irc>
< (@dkhayes117:matrix.org)> or "few-jit" ?
<re_irc>
<Félix | Totem> : In restored pronunciation, yes, but there are a ton of different pronunciations of Latin
<re_irc>
< (@korken89:matrix.org)> All conversions are optimized at compile time
<re_irc>
< (@korken89:matrix.org)> So I'm quite sure it's the most efficient (for embedded at least) time library there is
<re_irc>
<Félix | Totem> : That would be in Italian/Church Latin
<re_irc>
< (@korken89:matrix.org)> The only thing you pay is a bit of type complexity, but there are alias types so one does not need to define the numerator/denominator manually
<re_irc>
< (@korken89:matrix.org)> So I see it as solved
<re_irc>
< (@jamesmunns:beeper.com)> : just a bit :D
<re_irc>
< (@korken89:matrix.org)> Anyone that's worked with C++'s "Duration" will also feel like home :)
<re_irc>
< (@korken89:matrix.org)> As it's more or less a compile time copy of that
<re_irc>
< (@korken89:matrix.org)> And finally, the implementation is very small - it's easy to check if something is weird :)
<re_irc>
<Félix | Totem> : I used to work with C++ after leaving my programming school, but I really want to forget that time, especially now that Rust is mainstream.
<re_irc>
<Félix | Totem> That's more a torture device than a language.
<re_irc>
< (@korken89:matrix.org)> "fugit" is doing alright :D "224,650 Downloads" over 7 months
<re_irc>
<Félix | Totem> I hope that "stm32f3xx-hal" plans to move to it.
<re_irc>
< (@burrbull:matrix.org)> Félix | Totem: Don't hope. Make PR.
<re_irc>
<Félix | Totem> : I discovered embedded programming a week ago, it's maybe a bit too early for me to contribute to this kind of stuff 😅 Let me understand how to use the crate first.
<re_irc>
< (@korken89:matrix.org)> Naaaah
<re_irc>
< (@korken89:matrix.org)> Jump in the deep end!
<re_irc>
<Félix | Totem> Also, it's there some parts automatically generated from the PAC?
<re_irc>
<Félix | Totem> * aren't
<re_irc>
< (@korken89:matrix.org)> Not sure what you are referring to :)
<re_irc>
< (@korken89:matrix.org)> Not for "fugit" at least
<re_irc>
< (@dirbaio:matrix.org)> the macros 👻
<re_irc>
<Félix | Totem> : I'm talking about the HAL crates. There's no way that everything is written by hand. There must be some parts generated from the spec.
<re_irc>
< (@korken89:matrix.org)> Ah yes
<re_irc>
< (@korken89:matrix.org)> All is generated from SVD files using "svd2rust"
<re_irc>
< (@korken89:matrix.org)> I think for "embassy" "chiptool" is used?
<re_irc>
< (@korken89:matrix.org)> But it's a fork of "svd2rust"
<re_irc>
< (@korken89:matrix.org)> If I remember correctly
<re_irc>
< (@korken89:matrix.org)> But in the end SVD in, PAC out
<re_irc>
< (@dirbaio:matrix.org)> the PACs are generated from the SVD files
<re_irc>
<Félix | Totem> : So, to use fugit, I'd have to mess up with that tool…
<re_irc>
< (@dirbaio:matrix.org)> the HALs are handwritten
<re_irc>
<Félix | Totem> : Oh
<re_irc>
< (@korken89:matrix.org)> Félix | Totem: No
<re_irc>
< (@dirbaio:matrix.org)> often using a lot of macros to generate code, especially in the stm32 hals from the "stm32-rs" project
<re_irc>
< (@korken89:matrix.org)> What said :)
<re_irc>
< (@burrbull:matrix.org)> some peripherals have its own crates. like bxcan, usb-otg
<re_irc>
< (@dirbaio:matrix.org)> embassy's stm32 hal ("embassy-stm32") does generate code automatically from the PAC (for peripherals, pins, dma channel mappings)
<re_irc>
< (@dirbaio:matrix.org)> because it wasn't viable to make a single hal for all stm32 families otherwise (it's a single hal, unlike "stm32-rs" which has a different hal per family)
<re_irc>
<Félix | Totem> : What' the differences with the other HALs?
<re_irc>
< (@dirbaio:matrix.org)> - embassy-stm32 is a single hal for all families, which makes porting code between families easier, and allows less popular families get better support thanks to sharing code
<re_irc>
< (@dirbaio:matrix.org)> and stm32-rs has been around for longer, so it's more complete for the more popular families
<re_irc>
<Félix | Totem> : So, should I rewrite my code using it instead of "stm32f3xx-hal"?
<re_irc>
<Félix | Totem> I'm not sure which advantages/disadvantages are important.
<re_irc>
<Félix | Totem> I guess that since I don't care about my code being portable, "stm32f3xx-hal" is fine
<re_irc>
< (@dirbaio:matrix.org)> it depends what you want to do, I guess
<re_irc>
< (@dirbaio:matrix.org)> async is great for doing complex IO, networky things, multitasking
<re_irc>
< (@dirbaio:matrix.org)> if you don't need these then it doesn't make that much of a difference
<re_irc>
< (@grantm11235:matrix.org)> I believe they are interested in USB
<re_irc>
<Félix | Totem> Yes, I write a keyboard firmware
<re_irc>
< (@dirbaio:matrix.org)> if you want to do RTIC-style interrupt-driven state machine stuff then stm32f3xx-hal is better
<re_irc>
<Félix | Totem> : I've been satisfied with it so far. Isn't there an equivalent framework in embassy?
<re_irc>
< (@k900:0upti.me)> Embassy has a really nice USB API
<re_irc>
< (@k900:0upti.me)> It's just a bit more high level than usbd
<re_irc>
<Félix | Totem> : That part is really hard for me to grasp with "stm32f3xx-hal", but I suspect it's due to me, not the crate :D
<re_irc>
< (@k900:0upti.me)> But the abstraction is nice
<re_irc>
< (@dirbaio:matrix.org)> the equivalent would kinda be rust's async + embassy-executor
<re_irc>
< (@dirbaio:matrix.org)> I say "kinda" because they're quite different, but in the end they allow you to do the same things
<re_irc>
< (@dirbaio:matrix.org)> async is more abstracted, it is internally interrupt-driven, but you never write an interrupt handler directly, you ".await" things
<re_irc>
< (@dirbaio:matrix.org)> yeah you "give" the interrupt to the USB driver
<re_irc>
< (@dirbaio:matrix.org)> then the "usb.run()" future does all the USB stuff internally, when the interrupt fires, as needed
<re_irc>
<Félix | Totem> : This feels much higher level, but I wonder where all the HID stuff is (report descriptor, etc.)
<re_irc>
< (@k900:0upti.me)> That's what "MouseReport" is
<re_irc>
< (@dirbaio:matrix.org)> it's actually reusing "usbd_hid" for the report stuff, so that should work the same
<re_irc>
< (@dirbaio:matrix.org)> there's the builtin ones, or you can write your own I think? I've never dug deep into it
<re_irc>
<Félix | Totem> I'm tempted to rewrite my project using embassy now 😆
<re_irc>
<Félix | Totem> : That's what I did, but there is a lot of boring stuff
<re_irc>
< (@dirbaio:matrix.org)> yeah...
<re_irc>
< (@dirbaio:matrix.org)> well that's how USB HID is
<re_irc>
< (@dirbaio:matrix.org)> boring :D
<re_irc>
< (@dirbaio:matrix.org)> and complex
<re_irc>
<Félix | Totem> If I don't have to write the class, device etc. in embassy, maybe it's worth it :P
<re_irc>
< (@grantm11235:matrix.org)> How common is it to use a pwm with full 16 bit resolution? (setting the timer to count 0..=u16::MAX aka 0..2^16)
IlPalazzo-ojiisa has quit [Quit: Leaving.]
<re_irc>
< (@adamgreig:matrix.org)> I think "rare", bordering on very rare
<re_irc>
< (@adamgreig:matrix.org)> with a common 48MHz timer clock, you'd get 730Hz PWM
<re_irc>
< (@adamgreig:matrix.org)> I feel like it's common to pick a pwm frequency and hope you get "enough" resolution, rather than picking a resolution and not caring so much about the frequency, but in some cases you do want absolutely maximum resolution and you pay the price in frequency
<re_irc>
< (@grantm11235:matrix.org)> The reason I ask is because the 16 bit version of my pwm trait doesn't support it. It would need to report the max duty as 2^16, aka "u16::MAX + 1"
<re_irc>
< (@adamgreig:matrix.org)> ah, yea, we had this annoying issue of needing one more count than the range so that you can encode fully-off and fully-on
<re_irc>
< (@adamgreig:matrix.org)> it would be nice to avoid needing those 64-bit calculations though
<cr1901>
64-bit calculations?
<re_irc>
< (@grantm11235:matrix.org)> you need to use 64 bits to multiply two u32s, otherwise you will get overflows
<cr1901>
But the PWM trait is 16-bits?
<re_irc>
< (@grantm11235:matrix.org)> I had suggested an alternative that was 32 bit, mostly just to allow values of "u16::MAX + 1"
<cr1901>
Actually, now that I think about it, where do you need a multiply for PWM (freq divided by divider)?
<cr1901>
clock freq/divider = pwm freq*
<re_irc>
< (@grantm11235:matrix.org)> For example if you want to set the duty cycle as a percent, you need to multiply the percent by the duty that represents 100%, then divide by 100
<cr1901>
ahhhh
<re_irc>
< (@therealprof:matrix.org)> : Like fugit(ive)? 😉