cr1901 has quit [Quit: Leaving.]
fabic has joined #rust-embedded
cr1901 has joined #rust-embedded
neceve has quit [Ping timeout: 255 seconds]
starblue3 has joined #rust-embedded
starblue2 has quit [Ping timeout: 272 seconds]
<re_irc> <@r​ahix:m​> josfemova: avr-hal has explicit support for the pro micro board (but yes, it is very similar to the Leonardo, just some pins are different)
<re_irc> <@r​ahix:m​> but there is absolutely no USB support yet so you'll either need to link some existing C library or write your own for the time being...
dkm has quit [*.net *.split]
agg has quit [*.net *.split]
jasperw has quit [*.net *.split]
aquijoule__ has quit [*.net *.split]
bpye has quit [*.net *.split]
aquijoule__ has joined #rust-embedded
agg has joined #rust-embedded
bpye has joined #rust-embedded
jasperw has joined #rust-embedded
dkm has joined #rust-embedded
<re_irc> <@h​untc:m​> I've begun using thejpster 's lovely [Menu]( crate for configuration. Its really nice and I end up with a very nice approach to configuration. Here's my WIP which also documents what I think is a decent approach to the configuration of devices in general:...
fabic has quit [Ping timeout: 246 seconds]
neceve has joined #rust-embedded
fabic has joined #rust-embedded
<re_irc> <@t​hejpster:m​> Nice.
<re_irc> <@n​ewam:m​> are there any decent ways to write async code on embedded without running into the coloring issue?
<re_irc> <@n​ewam:m​> I know in std you can just throw an async functions into non-async with an executor on a new thread; but that's really heavy for embedded. Just curious if there are any other escape hatches.
<re_irc> <@n​ewam:m​> Basically I want to write code something like this; but without writing the same function twice each for sync/async.
<re_irc> <@n​ewam:m​> ```rs
<re_irc> <@t​halesfragoso:m​> newam futures has a `block_on` function
<re_irc> <@j​amesmunns:m​> I'm gunna place a digikey order, and need a couple extra things to hit the minimum free shipping. What fun/cool/interesting stuff should I add?
<re_irc> <@k​orken89:m​> I ordered tweezers for like 25 euros last time :D
<re_irc> <@k​orken89:m​> And they are now my favourite as well
<re_irc> <@k​orken89:m​> jamesmunns ^
<re_irc> <@j​amesmunns:m​> oh nice! I recently got a set of 8 or so, they definitely make things easier
<re_irc> <@j​amesmunns:m​> maybe I should order a scalpel...
<re_irc> <@k​orken89:m​> A tweezer*
<re_irc> <@k​orken89:m​> It had like a padded grip as well
<re_irc> <@k​orken89:m​> Super nice
<re_irc> <@k​orken89:m​> Also it seems like flux does not stain it
<re_irc> <@j​amesmunns:m​> ohhhh, I should order some more flux
<re_irc> <@j​amesmunns:m​> that's a good call
<re_irc> <@j​amesmunns:m​> I have a jank syringe, but it's old, and probably time to cycle out.
<re_irc> <@k​orken89:m​> Can never have too much!
<re_irc> <@j​amesmunns:m​> Does anyone have any rotary encoders they like that would be at home on a small-ish panel?
<re_irc> <@j​amesmunns:m​> nothing super tiny, but a nice little selection wheel?
<re_irc> <@t​herealprof:m​> Might as well get some desolddering alloy (e.g. Chip Quik or SRA).
<re_irc> <@b​urrbull:m​> therealprof: Canyou look at #336, #337 and #339 in f4xx-hal?
<re_irc> <@t​herealprof:m​> burrbull: looking...
<re_irc> <@b​urrbull:m​> This is generic pins for f1 with similar API:
<re_irc> <@t​herealprof:m​> burrbull: Looks good to me. I'd be interested in the opinion of thezoq2 about it. Did you find out what clippy doesn't like about the PR, couldn't see it in a pinch.
<re_irc> <@b​urrbull:m​> Clippy issues are not in the PR. They were before.
<re_irc> <@t​herealprof:m​> Fair enough. I left a comment.
<re_irc> <@h​uegene:m​> Hi guys, I hope it is a not to frequent question but I just build the usb-serial example from the stm32-rs/stm32f1xx-hal and I end up with ~85kb size.
<re_irc> <@h​uegene:m​> this seems like an exorbitant size for such a small example and I am wondering about the state of usb support for such small devices as the stm32f103.
<re_irc> <@h​uegene:m​> I am also wondering what it is, that takes up so much space and which parts can be dropped or (on the bright side) what features are included, that I would not have to reimplement my self.
<re_irc> <@h​uegene:m​> Is that a fringe basket case or is that something that is currently beeing worked on?
<re_irc> <@d​irbaio:m​> Are you building with --release.
<re_irc> <@h​uegene:m​> dirbaio: I dont think XD thanx Ill try that right away
<re_irc> <@t​halesfragoso:m​> Try compiling with release and
<re_irc> <@t​halesfragoso:m​> opt-level = "s"
<re_irc> <@t​halesfragoso:m​> [profile.release]
<re_irc> <@t​halesfragoso:m​> lto = true
<re_irc> <@n​ewam:m​> huegene: You can set the `dev` profile to do more optimization by default so you don't always have to do `--release`
<re_irc> <@h​uegene:m​> wow!
<re_irc> <@h​uegene:m​> XD
<re_irc> <@h​uegene:m​> 19kb
<re_irc> <@h​uegene:m​> I'll try to run it quickly to verify that I didn't mess up on the way, but that makes me wonder, what did I just optimize out?
<re_irc> <@d​irbaio:m​> in theory nothing
<re_irc> <@d​irbaio:m​> compiling with optimizations generates faster and smaller code that does the same
<re_irc> <@d​irbaio:m​> the downsides is it compiles slower, and debugging (breakpoints, single stepping, etc) works worse or not at all
<re_irc> <@t​herealprof:m​> Yeah, but USB won't work at all in `dev` mode, so it's the only way to go anyway.
<re_irc> <@h​uegene:m​> therealprof: how come?
<re_irc> <@t​herealprof:m​> The code runs too slow to accomplish the timing requirements for USB operation. Not sure anyone has analyzed exactly what the culprit is.
<re_irc> <@h​uegene:m​> huegene: oohh so it would work in dev (the more optimized) mode? or have I just confused everything?
<re_irc> <@t​herealprof:m​> `dev` mode is the default and disables all optimisation.
<re_irc> <@t​herealprof:m​> That's what `--release` changes in the quick way.
<re_irc> <@h​uegene:m​> Aaaahhhh! OK yeah that makes more sense now
<re_irc> <@t​herealprof:m​> It's also possible to tweak `dev` mode to enable optimisation or do what thalesfragoso suggested and tweak `--release` mode to improve debuggability.
loki_val has joined #rust-embedded
<re_irc> <@h​uegene:m​> well, operation confimed, works like a charm.
crabbedhaloablut has quit [Ping timeout: 244 seconds]
fabic has quit [Ping timeout: 255 seconds]
<re_irc> <@h​uegene:m​> thalesfragoso: actually, are there any huge implications with codegen-units = 1?
<re_irc> <@a​damgreig:m​> You could also incremental=false, or is that now the default again,
<re_irc> <@a​damgreig:m​> +?
<re_irc> <@h​uegene:m​> well my repo is from April so my information is outdated but I had incremental in
<re_irc> <@t​halesfragoso:m​> huegene: Probably not huge
<re_irc> <@n​ewam:m​> if any `stm32-rs` or `svd2rust` folks are here; is there a way to represent non-continuous fields?
<re_irc> <@a​damgreig:m​> newam: not as far as I know
<re_irc> <@n​ewam:m​> Are there any established idioms for handling that?
<re_irc> <@a​damgreig:m​> it does seem like it would be nice for svd2rust to have, but I don't _think_ there's any way to express it inside the SVD?
<re_irc> <@a​damgreig:m​> no, so far I think you just have two fields for the two contiguous parts, it's not entirely satisfactory
<re_irc> <@n​ewam:m​> gotcha, works for me!
<re_irc> <@a​damgreig:m​> yea, just checked and an SVD field has to be continuous, so there's no way for svdtools/stm32-rs to modify the svds to represent them, and there's no way for svd2rust to know to combine them either
<re_irc> <@a​damgreig:m​> a missing feature in the svd spec i guess
<re_irc> <@a​damgreig:m​> newam: that PR is very beefy, thank you for checking it over!
<re_irc> <@a​damgreig:m​> once you're both happy with it I'm happy to merge it, just say the word
<re_irc> <@n​ewam:m​> No problem 🙂 jorgeig-space did all the hard work
GenTooMan has quit [Ping timeout: 256 seconds]
GenTooMan has joined #rust-embedded