<re_irc> <@l​achlansneff:m​atrix.org> Do any of you have experience with wifinina/adafruit-airlift? I'm trying to talk to it over SPI and having a lot of issues with getting even the most basic response.
<re_irc> <@j​acobrosenthal:m​atrix.org> You've found this stuff right https://github.com/fionawhim/wifinina-rs
<re_irc> <@j​acobrosenthal:m​atrix.org> https://github.com/atsamd-rs/atsamd/search?q=wifinina&type=issues
<re_irc> <@l​achlansneff:m​atrix.org> @jacobrosenthal:matrix.org: I hadn't seen the second link.
<re_irc> <@l​achlansneff:m​atrix.org> I honestly think I've narrowed it down to not being able to get SPI to work.
<re_irc> <@l​achlansneff:m​atrix.org> I'm doing something pretty wrong.
<re_irc> <@l​achlansneff:m​atrix.org> I have the SCK line hooked up to my oscilliscope, and there's nothing there that could be called a clock.
<re_irc> <@l​achlansneff:m​atrix.org> Actually, would any of you be willing to sanity check my spi usage? https://github.com/lachlansneff/messing-around-rtic/blob/0c8fbc04c8edbc213f128e3e215d60dd215a63b2/src/main.rs#L44-L71
rjframe has joined #rust-embedded
<re_irc> <@f​irefrommoonlight:m​atrix.org> Could you start by doing a bogus SPI write directly in the code, then recording the data to see if there's still no clock? Eg using your scope or a logic analyser
<re_irc> <@f​irefrommoonlight:m​atrix.org> cs.set_high();
<re_irc> <@f​irefrommoonlight:m​atrix.org> spi.write([1]);
<re_irc> <@f​irefrommoonlight:m​atrix.org> ```rust
<re_irc> <@f​irefrommoonlight:m​atrix.org> So, after you set up the clocks and SPI, something like this:
<re_irc> <@f​irefrommoonlight:m​atrix.org> cs.set_low(); // might not be required
<re_irc> <@f​irefrommoonlight:m​atrix.org> Ie confirm your hypothesis the clock signal isn't working
starblue3 has quit [Ping timeout: 268 seconds]
starblue3 has joined #rust-embedded
<re_irc> <@l​achlansneff:m​atrix.org> firefrommoonlight: Yeah, my scope can't detect anything there.
<re_irc> <@l​achlansneff:m​atrix.org> It has an SPI decoder and can't read anything from it. The SCK output is doing something kind of strange. Let me take a picture of it.
<re_irc> <@l​achlansneff:m​atrix.org> In order of sck, miso, mosi, and cs
<re_irc> <@l​achlansneff:m​atrix.org> I'm unsure if I set up the clocks correctly and if the pins are in the right mode.
<re_irc> <@d​irbaio:m​atrix.org> yellow is sck?
<re_irc> <@d​irbaio:m​atrix.org> that looks whacky as hell lol
<re_irc> <@j​amesmunns:m​atrix.org> The vptp is really low
<re_irc> <@j​amesmunns:m​atrix.org> that looks like a 60hz harmonic
<re_irc> <@j​amesmunns:m​atrix.org> or some switching supply nearby singing at 360hz
<re_irc> <@l​achlansneff:m​atrix.org> It's at 100 hz actually
<re_irc> <@j​amesmunns:m​atrix.org> ah!
<re_irc> <@j​amesmunns:m​atrix.org> are you in a 50hz country?
<re_irc> <@l​achlansneff:m​atrix.org> Which is how often this runs:
<re_irc> <@l​achlansneff:m​atrix.org> cx.resources.spi.write(&[0x42]).unwrap();
<re_irc> <@l​achlansneff:m​atrix.org> cx.resources.cs.set_low().ok();
<re_irc> <@l​achlansneff:m​atrix.org> ```rust
<re_irc> <@l​achlansneff:m​atrix.org> cx.resources.cs.set_high().ok();
<re_irc> <@l​achlansneff:m​atrix.org> Nope, 60 Hz
<re_irc> <@j​amesmunns:m​atrix.org> ahh!
<re_irc> <@d​irbaio:m​atrix.org> no idea what's up with that SPI
<re_irc> <@d​irbaio:m​atrix.org> maybe try blinking the pins with plain GPIO to check they work and you see that on the scope fine?
<re_irc> <@j​amesmunns:m​atrix.org> Looks like you don't init the peripheral clocks: https://github.com/lachlansneff/messing-around-rtic/blob/0c8fbc04c8edbc213f128e3e215d60dd215a63b2/src/main.rs#L44-L46
<re_irc> <@l​achlansneff:m​atrix.org> I tried just setting high and low on the cs pin manually with a delay and that works fine.
<re_irc> <@l​achlansneff:m​atrix.org> @jamesmunns:matrix.org: I thought it might be something like that!
<re_irc> <@l​achlansneff:m​atrix.org> What should I set the peripheral clocks to?
<re_irc> <@j​amesmunns:m​atrix.org> let rcc = board.RCC.constrain();
<re_irc> <@j​amesmunns:m​atrix.org> let clocks = rcc
<re_irc> <@j​amesmunns:m​atrix.org> .use_hse(25.mhz())
<re_irc> <@j​amesmunns:m​atrix.org> .cfgr
<re_irc> <@j​amesmunns:m​atrix.org> from a black pill example I use
<re_irc> <@l​achlansneff:m​atrix.org> Could you explain why those particular numbers?
<re_irc> <@j​amesmunns:m​atrix.org> you probably need one or both of the pclks enabled, whichever feeds the SPI you are using
<re_irc> <@j​amesmunns:m​atrix.org> (those numbers are just what worked for me, on my board)
<re_irc> <@l​achlansneff:m​atrix.org> Trial and error?
<re_irc> <@j​amesmunns:m​atrix.org> I highly recommend using something like the stm32cubemx tool to select your clocks
<re_irc> <@j​amesmunns:m​atrix.org> (that's what I do)
<re_irc> <@l​achlansneff:m​atrix.org> Ah, good idea.
<re_irc> <@j​amesmunns:m​atrix.org> like, just use the big clock table to make sure you have good numbers, then give those numbers to RCC config in rust.
<re_irc> <@d​irbaio:m​atrix.org> wtf, what's the point of all the typestates if you can simply not setup pclks and have it not work?
<re_irc> <@j​amesmunns:m​atrix.org> i dunno, I'm not an stm32-rs maintainer
<re_irc> <@j​amesmunns:m​atrix.org> just an occasional user
<re_irc> <@j​amesmunns:m​atrix.org> What board are you using, Lachlan Sneff?
<re_irc> <@l​achlansneff:m​atrix.org> Blackpill
<re_irc> <@a​damgreig:m​atrix.org> I don't think you can not set those clocks
<re_irc> <@l​achlansneff:m​atrix.org> with an stm32f11ceu6
<re_irc> <@a​damgreig:m​atrix.org> if you don't set a number, it just picks good ones, right?
<re_irc> <@j​amesmunns:m​atrix.org> oh, then those numbers should work for you
<re_irc> <@j​amesmunns:m​atrix.org> (Those numbers are for a black pill)
<re_irc> <@a​damgreig:m​atrix.org> you can't disable all of pclk1/pclk2 etc, only set dividers from sysclk
<re_irc> <@j​amesmunns:m​atrix.org> Yeah, but you could set wackly dividers, I bet.
<re_irc> <@l​achlansneff:m​atrix.org> And that sets the instruction clock to 96 Mhz?
<re_irc> <@j​amesmunns:m​atrix.org> yeah
<re_irc> <@j​amesmunns:m​atrix.org> So you can feed the usb clock at 48mhz
<re_irc> <@a​damgreig:m​atrix.org> if you don't set anything at all, it should pick something that's allowed and sensible, iirc
<re_irc> <@j​amesmunns:m​atrix.org> sensibility is relative
<re_irc> <@a​damgreig:m​atrix.org> sure, it's still possible the clocks were wrong
<re_irc> <@a​damgreig:m​atrix.org> but i'd be a little surprised if that's the only problem
<re_irc> <@a​damgreig:m​atrix.org> it should not allow you to end up with invalid configs
<re_irc> <@l​achlansneff:m​atrix.org> Haha, I'm sure there are other problems with it
<re_irc> <@a​damgreig:m​atrix.org> if you zoom in the scope timebase a bunch do you see anything else? at 2ms/div you might be just totally missing bytes at 8MHz
<re_irc> <@l​achlansneff:m​atrix.org> I didn't see them at a smaller timestep.
<re_irc> <@l​achlansneff:m​atrix.org> I was definitely looking
<re_irc> <@f​irefrommoonlight:m​atrix.org> SEconding jamesmunns: CubeMx has an outstanding clock visualizer
<re_irc> <@f​irefrommoonlight:m​atrix.org> Try changing (lowering) the SPI clock, and trying all 4 moves
<re_irc> <@f​irefrommoonlight:m​atrix.org> *modes
<re_irc> <@j​amesmunns:m​atrix.org> (I actually always use cubemx for pin mapping and clock selection)
rjframe has quit [Ping timeout: 244 seconds]
<re_irc> <@l​achlansneff:m​atrix.org> Wow, this really is quite cool
<re_irc> <@f​irefrommoonlight:m​atrix.org> Usually the max speed is peripheral-dependent, and specified in datasheet. Also note that the way that HAL works, you're not getting exactly 8Mhz; there are only 8 possible divisions of the peripheral clock to get the SPI clock, so if the clock's 100Mhz, it's probably dividing by 16 to get 6.25Mhz
cr19011 has joined #rust-embedded
<re_irc> <@f​irefrommoonlight:m​atrix.org> Same re cube
<re_irc> <@f​irefrommoonlight:m​atrix.org> I have max-speed defaults set up for all the MCUs I've used or am considering using, but still QC everything, esp if using an external oscillator etc
<re_irc> <@a​damgreig:m​atrix.org> and it works fine with the pclks all doing what they should
<re_irc> <@l​achlansneff:m​atrix.org> This is pretty confusing stuff
<re_irc> <@a​damgreig:m​atrix.org> ah, Lachlan Sneff, you have your AF set to AF6
<re_irc> <@a​damgreig:m​atrix.org> but it needs to be AF5 for SPI
cr1901 has quit [Killed (NickServ (GHOST command used by cr19011!~William@2601:8d:8600:911:1457:157d:ca40:1eac))]
<re_irc> <@a​damgreig:m​atrix.org> wait...
<re_irc> <@f​irefrommoonlight:m​atrix.org> AHAH!
<re_irc> <@f​irefrommoonlight:m​atrix.org> That would so do it
<re_irc> <@a​damgreig:m​atrix.org> no, ignore me, jumped the gun
<re_irc> <@f​irefrommoonlight:m​atrix.org> :(
<re_irc> <@l​achlansneff:m​atrix.org> For SPI3, it was af6 :/
<re_irc> <@a​damgreig:m​atrix.org> af6 is fine for spi3
<re_irc> <@a​damgreig:m​atrix.org> (in any event it shouldn't compile if it was wrong)
<re_irc> <@l​achlansneff:m​atrix.org> I don't really mind if the SPI clock is running at 6.25 Mhz instead of 8
<re_irc> <@f​irefrommoonlight:m​atrix.org> Yea - it's probalby not related, but FYI
<re_irc> <@l​achlansneff:m​atrix.org> I'd like the system clock to be has high as possible (which maxes out at 100 Mhz)
<re_irc> <@l​achlansneff:m​atrix.org> But yeah, that's good to know
<re_irc> <@l​achlansneff:m​atrix.org> Should I try a different SPI?
<re_irc> <@f​irefrommoonlight:m​atrix.org> Just make sure you're not exceeding the peripheral's max SPI clock speed once you have this problem sorted, since 8Mhz overspeeds most of the SPI periphs I've used
<re_irc> <@f​irefrommoonlight:m​atrix.org> Sure. This is mysterious, so any data points will help
<re_irc> <@l​achlansneff:m​atrix.org> @firefrommoonlight:matrix.org: I'm using an adafruit airlift, which makes a point of running the spi bus at 8 mhz
<re_irc> <@f​irefrommoonlight:m​atrix.org> Oh nvm then
<re_irc> <@l​achlansneff:m​atrix.org> It's getting pretty late for me, so I'm going to put it down for the night.
<re_irc> <@f​irefrommoonlight:m​atrix.org> jamesmunns: I hadn't considering CubeMx for Pin mapping, but great idea. Had been usign user manuals
<re_irc> <@f​irefrommoonlight:m​atrix.org> It looks like you just click a pin, and it shows all avail alt fns
<re_irc> <@j​amesmunns:m​atrix.org> Ah yeah, here's my full config:
<re_irc> <@j​amesmunns:m​atrix.org> let clocks = rcc
<re_irc> <@j​amesmunns:m​atrix.org> let rcc = board.RCC.constrain();
<re_irc> <@j​amesmunns:m​atrix.org> ```rust
<re_irc> <@j​amesmunns:m​atrix.org> I love that heisenbridge does cut and paste emojis
<re_irc> <@a​damgreig:m​atrix.org> hmm, Lachlan Sneff, I just tried your code on my black pill
<re_irc> <@a​damgreig:m​atrix.org> and it seems to be outputting spi
<re_irc> <@l​achlansneff:m​atrix.org> Huh
<re_irc> <@l​achlansneff:m​atrix.org> That's not good
<re_irc> <@l​achlansneff:m​atrix.org> 1. I don't know how to use my scope (very possible)
<re_irc> <@l​achlansneff:m​atrix.org> Two possibilities:
<re_irc> <@l​achlansneff:m​atrix.org> 2. I burnt out something when soldering the legs on?
<re_irc> <@a​damgreig:m​atrix.org> PB3/4/5/6 are D0/1/2/3
<re_irc> <@a​damgreig:m​atrix.org> running your latest commit, messing-around-rtic binary
<re_irc> <@l​achlansneff:m​atrix.org> Hmm
<re_irc> <@a​damgreig:m​atrix.org> do you have a ground lead connected from a scope probe to a ground pin on your black pill?
<re_irc> <@l​achlansneff:m​atrix.org> Yep
<re_irc> <@a​damgreig:m​atrix.org> might be worth checking nothing is accidentally shorting out
<re_irc> <@a​damgreig:m​atrix.org> and also maybe set the scope timebase to 500ns/s and trigger on CS going low and check you're not just missing it happen
<re_irc> <@a​damgreig:m​atrix.org> it's very very infrequent, so 99% of the time there's no activity
<re_irc> <@a​damgreig:m​atrix.org> or go to bed :P but your code seems ok!
<re_irc> <@a​damgreig:m​atrix.org> these things are surprisingly robust so probably nothing is permanently burnt out, but if there is a short circuit due to soldering or probing you can probably remove it and it will start working
<re_irc> <@l​achlansneff:m​atrix.org> I think I'll probably head to bed
<re_irc> <@l​achlansneff:m​atrix.org> Thank you for all the help everyone!
<re_irc> <@a​damgreig:m​atrix.org> wow, it's definitely trying there!
<re_irc> <@a​damgreig:m​atrix.org> look at it with fresh eyes tomorrow and you'll probably spot the issue immediately
<re_irc> <@l​achlansneff:m​atrix.org> :)
<re_irc> <@l​achlansneff:m​atrix.org> I guess spi is working actually. Weird that it's showing as 0x43, when the mcu is writing 0x42.
<re_irc> <@l​achlansneff:m​atrix.org> And that's all for tonight. Thank you again!
fabic has joined #rust-embedded
Wetmelon has quit [Ping timeout: 240 seconds]
emerent_ has joined #rust-embedded
emerent is now known as Guest4820
emerent_ is now known as emerent
Guest4820 has quit [Killed (mercury.libera.chat (Nickname regained by services))]
fabic has quit [Ping timeout: 244 seconds]
<re_irc> <@t​hejpster:m​atrix.org> As seen on Twitter .. Espressif offer a Rust example!! https://github.com/espressif/rust-esp32-example
gsalazar has joined #rust-embedded
fabic has joined #rust-embedded
neceve has joined #rust-embedded
<re_irc> <@r​uabmbua:m​atrix.org> Cool :D
<re_irc> <@r​uabmbua:m​atrix.org> I want to try using esp32 for the first time in the next few days. Using rust would be an extra 👍️
<re_irc> <@r​uabmbua:m​atrix.org> Hopefully it also works with the ESP32 C3 (RISC-V)?
<Lumpio-> It calls a Rust function to add two numbers from a C main.c
<Lumpio-> So don't expect to write your entire thing in Rust based on just that
<Lumpio-> There are 3rd party projects to make that possible from what I can remember tho
<Lumpio-> But this is probably the first official thing
<re_irc> <@t​hejpster:m​atrix.org> Their scripts seem to support both RISC-V and Xtensa as targets
<re_irc> <@t​hejpster:m​atrix.org> Is Xtensa in tree? Or is it still a fork?
neceve has quit [Ping timeout: 268 seconds]
fabic has quit [Ping timeout: 268 seconds]
fabic has joined #rust-embedded
<re_irc> <@w​assasin:m​atrix.org> `To support the Xtensa instruction set, build and install custom LLVM and Rust toolchains as shown in the Rust On Xtensa guide.`
fabic has quit [Ping timeout: 240 seconds]
rjframe has joined #rust-embedded
cr19011 has quit [Quit: Leaving.]
cr1901 has joined #rust-embedded
<re_irc> <@e​vils.devils:m​atrix.org> is there any way to open an RTT terminal without first flashing firmware?
* re_irc @e​vils.devils:m​atrix.org squints, seems like the internal temperature sensor of the stm32f103 isn't handled by the HAL
rjframe has quit [Remote host closed the connection]
rjframe has joined #rust-embedded
fabic has joined #rust-embedded
gsalazar has quit [Ping timeout: 240 seconds]
fabic has quit [Ping timeout: 264 seconds]
gsalazar has joined #rust-embedded
gsalazar has quit [Remote host closed the connection]
gsalazar has joined #rust-embedded
<re_irc> <@f​irefrommoonlight:m​atrix.org> Add it
<re_irc> <@f​irefrommoonlight:m​atrix.org> `ads.read_temp()` would be a fine API
<re_irc> <@e​vils.devils:m​atrix.org> @firefrommoonlight:matrix.org: on the one hand, wouldn't be the first time i've contributed to a Rust HAL, and this was my first reaction too
<re_irc> <@e​vils.devils:m​atrix.org> on the other hand, i've yet to write and use a Rust function...
<re_irc> <@f​irefrommoonlight:m​atrix.org> Sounds like an excuse to learn
<re_irc> <@f​irefrommoonlight:m​atrix.org> The recipe you'd implement is in the RM, section 11.10: *Reading the temperature*,
gsalazar has quit [Quit: Leaving]
<re_irc> <@e​vils.devils:m​atrix.org> seems like the stm32f1 HAL only does ADC stuff on the pins, and that assumption seems at least somewhat baked in
<re_irc> <@r​yan-summers:m​atrix.org> You can likely reference the F4 hal too. I think that one supports at least some internal channel measurements
<re_irc> <@r​yan-summers:m​atrix.org> Although I don't know if the ADC peripheral is the same on those models
<re_irc> <@e​vils.devils:m​atrix.org> @ryan-summers:matrix.org: oh you mean use it as a reference, not pull it in as a dependency xD
<re_irc> <@f​irefrommoonlight:m​atrix.org> https://github.com/stm32-rs/stm32f1xx-hal/blob/master/src/adc.rs#L475
<re_irc> <@e​vils.devils:m​atrix.org> ah
<re_irc> <@e​vils.devils:m​atrix.org> yea... i stopped looking after looking at this page
<re_irc> <@e​vils.devils:m​atrix.org> @firefrommoonlight:matrix.org: thanks
<re_irc> <@f​irefrommoonlight:m​atrix.org> That's the PAC, not HAL
<re_irc> <@f​irefrommoonlight:m​atrix.org> https://docs.rs/stm32f1xx-hal/0.7.0/stm32f1xx_hal/adc/struct.Adc.html#method.read_temp
<re_irc> <@f​irefrommoonlight:m​atrix.org> And yes - this is confusing and overwhelming at first. I don't know if there's a good getting-started guide to library conventions and layout
<re_irc> <@f​irefrommoonlight:m​atrix.org> PAC allows a nice interface for reg access, where you call reg blocks, regs, and fields by name. HAL builds on top of this to implement steps needed to initialize and use built-in peripherals
fabic has joined #rust-embedded
<re_irc> <@r​yan-summers:m​atrix.org> There's some good talks about the rust ecosystem from Oxidize 2020 on Ferrous's youtube channel that I can recommend
<re_irc> <@e​vils.devils:m​atrix.org> weird, would have thought the thing that provides semantics for the actual pins is build on something providing register access etc
<re_irc> <@r​yan-summers:m​atrix.org> https://www.youtube.com/watch?v=vLYit_HHPaY
<re_irc> <@e​vils.devils:m​atrix.org> cool, this was published after the last time i failed at Rust, thanks
<re_irc> <@e​vils.devils:m​atrix.org> BASTARD!
<re_irc> <@e​vils.devils:m​atrix.org> you explain what GPIO means, but not RCC?
<re_irc> <@e​vils.devils:m​atrix.org> sry, that's a bit of an extreme reaction...
<re_irc> <@r​yan-summers:m​atrix.org> Just read the reference manual for abbreviations like that. RCC is super stm32-specific: https://www.st.com/resource/en/reference_manual/cd00171190-stm32f101xx-stm32f102xx-stm32f103xx-stm32f105xx-and-stm32f107xx-advanced-arm-based-32-bit-mcus-stmicroelectronics.pdf
<re_irc> <@r​yan-summers:m​atrix.org> "Low-, medium-, high- and XL-density reset and clock control (RCC)"
<re_irc> <@e​vils.devils:m​atrix.org> it's not that, it's that explaining GPIO sets an expected level of verbosity of the talk
<re_irc> <@f​irefrommoonlight:m​atrix.org> IMO not a great descriptino there either
<re_irc> <@r​yan-summers:m​atrix.org> Reset and clock control seems pretty straight forward to me tbh
<re_irc> <@f​irefrommoonlight:m​atrix.org> PLL goes higher - MCU goes faster!
<re_irc> <@f​irefrommoonlight:m​atrix.org> If you go past the rated limits, you can add blue LEDs and water cooling
<Windfisch> PLL goes even higher - ALU starts failing
<Windfisch> friends don't let friends overclock stm32, division is one of the first things to break.
<re_irc> <@j​amesmunns:m​atrix.org> A bit off topic, but Mara from the Libs team has put together what is IMO an *excellent* piece that illustrates some hard concepts about how OSS teams, like the Embedded WG, differ from some expectations.
<re_irc> <@j​amesmunns:m​atrix.org> https://blog.m-ou.se/rust-is-not-a-company/
<re_irc> <@j​amesmunns:m​atrix.org> Big CC adamgreig and therealprof, I think this is something that might be helpful to guide communication for folks that are interested in contributing, or ask questions about "when can we do X"
<re_irc> <@j​amesmunns:m​atrix.org> (it matches my experience of my time on the embedded-core team, and I did not have the clarity then to realize it as well as Mara describes it in this post)
<re_irc> <@j​amesmunns:m​atrix.org> I think it does match the flow we've generally dropped into: The embedded wg's job is to provide guidance to people who are interested in showing up and doing something that is important to them, in order to make sure it's useful for everyone.
<re_irc> <@j​amesmunns:m​atrix.org> instead of being a "top down org" that assigns tasks to people.
<re_irc> <@f​irefrommoonlight:m​atrix.org> Very nice article
<re_irc> <@f​irefrommoonlight:m​atrix.org> I think a key thing to consider is what is an individual's motivations and drive. What are they building? Why? You can look at it like drafting and maintaining requirements and specifications, as you would for a hardware project
<re_irc> <@f​irefrommoonlight:m​atrix.org> My motivation is launching a pair of hardware projects, and while doing so, learn the tools, hardware for a set of MCUs (I've chosen Stm32 for now), and be use most of their peripherals with little effort. So, in addition to making my current projects work, I'd like to make my life easier on future...
<re_irc> ... projects.
<re_irc> <@f​irefrommoonlight:m​atrix.org> As a consequence, I've published a library that is decoupled from my specific projects. This allows other people to use it in the naive sense, but also encourages critique, alternative ideas etc, which benefit me later, ie on future projects
<re_irc> <@f​irefrommoonlight:m​atrix.org> It feels like parts of the Rust embedded OSS are in drift mode, ie without concrete goals... Or you could look at it as a slow-roll for an emerging language in a historically slow-to-change field
<re_irc> <@f​irefrommoonlight:m​atrix.org> Waiting for more people to join, more projects to emerge, and the associated additions, fixes etc to grow from the specific issues people run into
<re_irc> <@d​irbaio:m​atrix.org> yeah, REWG projects are rather conservative, the bar for consensus is quite high :)
<re_irc> <@d​irbaio:m​atrix.org> it means they're quite slow moving
<re_irc> <@d​irbaio:m​atrix.org> that may be a good thing for "very foundational" things like embedded-hal and cortex-m though
<re_irc> <@f​irefrommoonlight:m​atrix.org> I agree
<re_irc> <@d​irbaio:m​atrix.org> maybe not so for PACs/HALs (?)
<re_irc> <@j​amesmunns:m​atrix.org> IMO: I do think crate maintainers, like nrf-rs et. al, should be more aggressive in pushing for changes
<re_irc> <@d​irbaio:m​atrix.org> though most pac/hal work is in orgs like stm32-rs, nrf-rs which is not officially part of the REWG?
<re_irc> <@j​amesmunns:m​atrix.org> and rewg should end up tracking "this is the best way we know how to do it so far"
<re_irc> <@d​irbaio:m​atrix.org> though it's mostly the same people anyway
<re_irc> <@j​amesmunns:m​atrix.org> :D
<re_irc> <@j​amesmunns:m​atrix.org> truth.
<re_irc> <@f​irefrommoonlight:m​atrix.org> People like adamgreig are overworked on stm32-rs
<re_irc> <@j​amesmunns:m​atrix.org> We wear different hats in different arenas though.
<re_irc> <@f​irefrommoonlight:m​atrix.org> You can add to that "best way we know" list as people or groups autonomously come up with independent approaches
<re_irc> <@j​amesmunns:m​atrix.org> that being said: A big reason for me stepping back from wg work is that I feel that we also need to push outwards a bit harder
<re_irc> <@j​amesmunns:m​atrix.org> For a while, we looked "inward" to decide the best plans
<re_irc> <@j​amesmunns:m​atrix.org> But we didn't have a large body of examples of different practices in many applications.
<re_irc> <@j​amesmunns:m​atrix.org> (also, Ferrous takes up a LOT of my time)
<re_irc> <@f​irefrommoonlight:m​atrix.org> Btw, you had some very nice and pointed questions in the vid Ryan linked above
<re_irc> <@j​amesmunns:m​atrix.org> IMO, I think the most productive work is to "explode outwards" in terms of trying new things, and then have a more detailed conversation on how that can be collected back to "the commons"
<re_irc> <@j​amesmunns:m​atrix.org> e.g., I think dirbaio's work on Embassy is an exciting application of that
<re_irc> <@f​irefrommoonlight:m​atrix.org> I think Ferrous will provide some of that forward motion by example. Eg: probe-run etc was a game changer. I use your template and tools on all projects
<re_irc> <@j​amesmunns:m​atrix.org> Rather than trying to "get async right" as a collective group: build what you need, and when the time is right, we can find the best ways to generalize things.
<re_irc> <@f​irefrommoonlight:m​atrix.org> Agree - I have no interest in Async, in any language I've used, but I admire his work style and approach
<re_irc> <@f​irefrommoonlight:m​atrix.org> And see the use cases other people have for it
<re_irc> <@d​irbaio:m​atrix.org> some Unpopular Opinion from me: the current PAC/HAL ecosystem has big flaws at the core, and with how nrf-rs/stm32-rs is currently managed (high bar for consensus, slow reviews, unclear leadership) I don't see it fixed anytime soon
<re_irc> <@j​amesmunns:m​atrix.org> totally reasonable
<re_irc> <@f​irefrommoonlight:m​atrix.org> Example - I had an easier time building a new HAL than getting a PR merged.
<re_irc> <@d​irbaio:m​atrix.org> like, hals get "incremental improvements" just fine (fix X, add support for Y following the current structure)
<re_irc> <@d​irbaio:m​atrix.org> but "big changes" are impossible
<re_irc> <@j​amesmunns:m​atrix.org> Honestly:
<re_irc> <@j​amesmunns:m​atrix.org> I think we should be less afraid of "breaking the ecosystem" at the moment.
<re_irc> <@j​amesmunns:m​atrix.org> If forking a hal and making it your way works: do it.
<re_irc> <@f​irefrommoonlight:m​atrix.org> dirbaio you don't need to see it fixed: you're currently working on the fix, right now
<re_irc> <@j​amesmunns:m​atrix.org> esp with hals and pacs, which are usually 1:1 chosen by the application, there is little pain in supporting both, from an ecosystem perspective.
<re_irc> <@j​amesmunns:m​atrix.org> IMO, I'd like to see "eventual merges" happen, like your fork becomes the next major release of the hal/pac
Wetmelon has joined #rust-embedded
<re_irc> <@j​amesmunns:m​atrix.org> but we are throttled by time, and there is no "blessed source" in Rust.
<re_irc> <@r​yan-summers:m​atrix.org> I've actually found myself forking HALs more and more lately just to get what I need out of them
<re_irc> <@r​yan-summers:m​atrix.org> Because yeah, there is a high bar for consensus
<re_irc> <@f​irefrommoonlight:m​atrix.org> What issues do you find with the PACs, other than the split between MCUs? For context, I'm happy with the Stm-32 PACs, other than bugs inherent to Svds, which there are mechanisms for patching
<re_irc> <@d​irbaio:m​atrix.org> and even if "alternative hals" like firefrommoonlight's or embassy have already solved many of these issues, people keep using stm32-rs and nrf-rs becaues they're the "official" ones
<re_irc> <@j​amesmunns:m​atrix.org> Yeah, me too: https://github.com/jamesmunns/nrf-hal/tree/usb-and-spim
<re_irc> <@r​yan-summers:m​atrix.org> I don't think the current approach is bad, but I think we should try to outline the advantages and disadvantages of forking
<re_irc> <@d​irbaio:m​atrix.org> and keep coming to matrix to ask for help about PAC bugs or struggling with free() or extreme generics spam
<re_irc> <@r​yan-summers:m​atrix.org> I think a lot of people are very hesitant to fork
<re_irc> <@r​yan-summers:m​atrix.org> (myself included)
<re_irc> <@j​amesmunns:m​atrix.org> though - partially, I often do this when I implement a driver in a certain way that I know isn't generally applicable, but exactly what I need.
<re_irc> <@f​irefrommoonlight:m​atrix.org> True, re default choices, but... If you've fixed things for your own uses, And made it public, eventually you'll see adoption. I think a key issue is the current community is v small
<re_irc> <@j​amesmunns:m​atrix.org> IMO: forking is a polite part of open source
<re_irc> <@j​amesmunns:m​atrix.org> like, don't say the old one is bad
<re_irc> <@f​irefrommoonlight:m​atrix.org> And it's hard to say what people are doing with rust embedded outside public OSS
<re_irc> <@j​amesmunns:m​atrix.org> just say something like "an experimental new take on X"
<re_irc> <@f​irefrommoonlight:m​atrix.org> I don't care if 0 people use my HAL, as long as it fixes my problems
<re_irc> <@r​icharddodd:m​atrix.org> Yeah being able to fork and experiment is like a major part of what makes OS great.
<re_irc> <@j​amesmunns:m​atrix.org> and I think the goal SHOULD be to eventually re-merge, in one hal or the other
<re_irc> <@j​amesmunns:m​atrix.org> but if they don't, that's cool too.
<re_irc> <@r​icharddodd:m​atrix.org> The way to make re-unification more likely is to write blog posts about what you're doing and why, and talk to the people whose work you forked.
<re_irc> <@j​amesmunns:m​atrix.org> like, one of the hardest things to communicate is "stop waiting for permission to do cool shit"
<re_irc> <@j​amesmunns:m​atrix.org> just... do the cool shit, if you know how.
<re_irc> <@f​irefrommoonlight:m​atrix.org> jamesmunns I'll take a look at that when I start a nrf project. About to start a Bluetooth proj, but am leaning stm32wb currently
<re_irc> <@r​icharddodd:m​atrix.org> I ran a fork of embassy for a while because I wanted things like hal traits that weren't there yet and I was too lazy to implement them properly. I've made PRs for all the stuff I needed and am back on upstream now.
<re_irc> <@f​irefrommoonlight:m​atrix.org> That's ideal
<re_irc> <@f​irefrommoonlight:m​atrix.org> I'm using a stm32 PAC fork now, but hope to go upstream on that soon too, once I fix some bugs, and it gets merged and released
<re_irc> <@r​icharddodd:m​atrix.org> But if you fork you can carry on working while you're getting your improvements upstreamed. It gets a little bit more complicated to manage but worth it to keep yourself working.
<re_irc> <@f​irefrommoonlight:m​atrix.org> That git complexity bites me a lot when I try
<re_irc> <@r​icharddodd:m​atrix.org> firefrommoonlight: I take back all I said about the PAC crates because they are auto-generated and shouldn't need editing
<re_irc> <@r​icharddodd:m​atrix.org> :P
<re_irc> <@f​irefrommoonlight:m​atrix.org> I eventually gave up on trying to maintain more than 1 or 2 branches at once, eg for PRs. One wrong git command and you get in trouble
<re_irc> <@r​icharddodd:m​atrix.org> firefrommoonlight: The way I do it is : have a branch for each PR I want to do, then a branch where I merge all the other branches, then if/when PRs get merged, I rebase on master on my special branch. If I screw up on it it's easy to recreate. Just don't screw up master or the PR branches (even if you do...
<re_irc> ... it's ok because you can download them from github again (other remote repos are available))
<re_irc> <@f​irefrommoonlight:m​atrix.org> That's a great idea - I'll try it
<re_irc> <@f​irefrommoonlight:m​atrix.org> And getting better at git CLI workflow helps too
<re_irc> <@r​icharddodd:m​atrix.org> basically if you ever get in a pickle just delete and recreate your fork branch from the others.
<re_irc> <@a​damgreig:m​atrix.org> Always the interesting discussions while I'm at work :p all I would add is forking can be difficult too, especially if there's a bunch of boring automation and admin stuff to copy, and if the reason you're forking is that upstream hasn't got enough time to deal with things you might be buying yourself the same...
<re_irc> ... trouble :p sometimes asking for maintainer access might be more productive than just forking, depending on the situation
<re_irc> <@r​icharddodd:m​atrix.org> That's a good point - I'm always too shy to ask to be a maintainer.
<re_irc> <@r​yan-summers:m​atrix.org> Yeah, that's what I was alluding to when I mentioned advantages and disadvantages. You can also shoot yourself in the foot forking
<re_irc> <@r​yan-summers:m​atrix.org> If you want changes from upstream but have forked hard enough, you're on your own
<re_irc> <@r​yan-summers:m​atrix.org> But providing that feedback and guidance would be useful. It took me a while to figure out a balance
<re_irc> <@r​yan-summers:m​atrix.org> Because in a very growing ecosystem like what exists now, I think forking is a big part of things
<re_irc> <@d​irbaio:m​atrix.org> being a maintainer or not is not everything. eg I now have maintainer access to nrf-rs but that doesn't mean I can just go and make all the big breaking changes I want to make on my own 🤣
<re_irc> <@r​yan-summers:m​atrix.org> +1 on that one
<re_irc> <@r​yan-summers:m​atrix.org> At least, that's how it feels
<re_irc> <@d​irbaio:m​atrix.org> being a maintainer helps for making "incremental improvements" unstuck
<re_irc> <@a​damgreig:m​atrix.org> Yea, and if what you actually want is to explore a new concept entirely (embassy, your metapac, stm32ral, etc) I think a new project makes total sense too
<re_irc> <@d​irbaio:m​atrix.org> yeah
<re_irc> <@f​irefrommoonlight:m​atrix.org> If it feels like you're waiting too long on someone else to approve something or to convince someone, it's time to try your own experiment
<re_irc> <@d​irbaio:m​atrix.org> althoguh
<re_irc> <@f​irefrommoonlight:m​atrix.org> Then circle back later if you want
<re_irc> <@d​irbaio:m​atrix.org> embassy has "big experimental" things like async or metapac
<re_irc> <@f​irefrommoonlight:m​atrix.org> Like, let's say you're working on a hardware project. You may have delays for spinning new boards after making an error, shipping delays, etc. Waiting on OSS merging should never be part of this
<re_irc> <@d​irbaio:m​atrix.org> but it also has smaller experimental things that are already mostly validated and solve big pain points of the current HALs
<re_irc> <@d​irbaio:m​atrix.org> for example, borrowed peripheral singletons + [typestate-less gpio api](https://github.com/nrf-rs/nrf-hal/pull/301) completely solve the [pains with free()](https://github.com/nrf-rs/nrf-hal/issues/279)
<re_irc> <@t​halesfragoso:m​atrix.org> @dirbaio:matrix.org: This seems like a very known solution to us, but I would think it's very new in general terms and a lot of people don't know about it
<re_irc> <@d​irbaio:m​atrix.org> initially it was an unproven idea, got implemented in embassy, was found to be working, I've validated it's a huge boon for low-power devices and am now shipping devices with 2y+ battery life to real-world customers with it
<re_irc> <@d​irbaio:m​atrix.org> so.. now what
<re_irc> <@d​irbaio:m​atrix.org> what are the next steps?
<re_irc> <@r​icharddodd:m​atrix.org> One interesting question that I think embassy is exploring is exactly what amount of typestate is optimal for e.g. GPIO pins. To me, it's not obvious whether you should model the different states or not. I do find embassy's non-typestated model more ergonomic than the heavily typestated versions though (I'm...
<re_irc> ... forgetting the details). Another is whether you can take RAII to hardware, where constructing a peripheral out of pins also powers that peripheral up (and dropping it powers down). This is really ergonomic, but I'm not yet sure it's flexible enough for all cases.
<re_irc> <@d​irbaio:m​atrix.org> or will nrf-rs be stuck with the current api forever?
<re_irc> <@t​halesfragoso:m​atrix.org> @dirbaio:matrix.org: Get some people to implement it for all HALs....
<re_irc> <@t​halesfragoso:m​atrix.org> Maybe we should put it into a separate crate to start, but not sure
<re_irc> <@d​irbaio:m​atrix.org> already done, that "separate crate" is embassy 🤣
<re_irc> <@r​icharddodd:m​atrix.org> dirbaio: I'd say the typestate-less pin stuff works out really well in practice and I'm sure it should go in the HALs at some point, I guess it's just baking it for a while and then writing up a suggestion (if the change is big) or just doing a PR if its small enough.
<re_irc> <@r​icharddodd:m​atrix.org> The meetings that get organised are a great place for these kind of change proposals as well.
<re_irc> <@t​halesfragoso:m​atrix.org> I mean separate from embassy, I wouldn't expect a HAL to have to depend on nightly to have Unborrow and stuff
<re_irc> <@t​halesfragoso:m​atrix.org> (not sure if the crate Unborrow is right now requires nightly)
<re_irc> <@r​icharddodd:m​atrix.org> I don't think the Unborrow stuff depends on nightly - that's more for the async version of the HAL traits
<re_irc> <@d​irbaio:m​atrix.org> Unborrow could be copypasted into every hal, it's tiny, that's not the issue
<re_irc> <@t​halesfragoso:m​atrix.org> Unborrow doesn't, but maybe the crate it is in does
<re_irc> <@t​halesfragoso:m​atrix.org> @dirbaio:matrix.org: yeah, there's that
<re_irc> <@d​irbaio:m​atrix.org> plus, nrf-hal wouldn't be able to `impl unborrow_crate::Unborrow for pac::UARTE0` because they'd be both foreign types
<re_irc> <@t​halesfragoso:m​atrix.org> yeah, makes sense
<re_irc> <@d​irbaio:m​atrix.org> so either the singletons have to be defined by the HAL, or Unborrow has to be defined by the HAL
<re_irc> <@t​halesfragoso:m​atrix.org> probably Unborrow, singletons should be its own crate
<re_irc> <@f​irefrommoonlight:m​atrix.org> That's a nice API. I may adopt it or parts of it. Currey using a typeststeless API on STM, but it doesn't have a way to block an input pin from being set low, which I'd like
<re_irc> <@f​irefrommoonlight:m​atrix.org> And if you're not using the EH trait, function pin args are hard-coded to the port
<re_irc> <@f​irefrommoonlight:m​atrix.org> Ergonomic, but maybe too far in that direction
<re_irc> <@t​halesfragoso:m​atrix.org> I still think we need way more blogs, but I'm guilty of that one too
<re_irc> <@t​halesfragoso:m​atrix.org> blogs is way better to introduce a idea to a lot of people than a bunch of code
<re_irc> <@f​irefrommoonlight:m​atrix.org> Maybe more published projects. The examples we see are too trivial
<re_irc> <@r​icharddodd:m​atrix.org> Yeah there's some great stuff happening here that would be really useful to other parts of the Rust ecosystem. Finding time to write is hard though.
<re_irc> <@f​irefrommoonlight:m​atrix.org> I may publish firmware, but am hesitant for a few reasons
<re_irc> <@r​yan-summers:m​atrix.org> Have you ever looked at Stabilizer? :)
<re_irc> <@r​yan-summers:m​atrix.org> Very complex project, 100% open
<re_irc> <@r​yan-summers:m​atrix.org> Totally unbias (tm)
<re_irc> <@r​icharddodd:m​atrix.org> ryan-summers: could you link it - I'm struggling to google it specifically enough :P
<re_irc> <@r​yan-summers:m​atrix.org> https://github.com/quartiq/stabilizer
<re_irc> <@f​irefrommoonlight:m​atrix.org> Thats outstanding
<re_irc> <@r​yan-summers:m​atrix.org> MQTT protocol, run time configuration settings, 50Mbps data streams, high speed DMA, etc.
<re_irc> <@f​irefrommoonlight:m​atrix.org> Dude, great
<re_irc> <@r​yan-summers:m​atrix.org> Pretty heavily documented in the code, next steps are adding some more general user manuals
<re_irc> <@r​icharddodd:m​atrix.org> Stabilizer looks really cool!
<re_irc> <@r​yan-summers:m​atrix.org> It's a pretty fun project to work on honestly
<re_irc> <@r​yan-summers:m​atrix.org> Lots of cool embedded aspects - networking, high speed DMA, lots of the fun stuff imo
<re_irc> <@r​yan-summers:m​atrix.org> Might not be a bad idea to PR it into awesome embedded rust
<re_irc> <@r​yan-summers:m​atrix.org> Humble me
<re_irc> <@r​yan-summers:m​atrix.org> Mainly in reference to showing how you can construct large, complex applications
<re_irc> <@d​irbaio:m​atrix.org> also, being completely honest: now that I'm using embassy-nrf instead of nrf-hal, I "care less" about nrf-hal. Probably the same is going on for firefrommoonlight and stm32-rs hals.
<re_irc> <@d​irbaio:m​atrix.org> Like, for me, contributing improvements back to nrf-hal would be "nice to have" but justifying the effort is hard when they're going to require writing long RFCs, discussing it in hours-long meetings, writing the code, PRing it, waiting weeks for review. Plus, I only get the benefits if 100% is merged back, and...
<re_irc> ... async is not likely to get merged anytime soon.
<re_irc> <@d​irbaio:m​atrix.org> This is a big problem with the "everything experimental should go on into a separate project/fork initially". Once that separate project is production-ready most of the incentives to merge back are simply gone.
<re_irc> <@f​irefrommoonlight:m​atrix.org> Yep. I cared when I was waiting for PRs to be merged. Now, it's off my radar
<re_irc> <@d​irbaio:m​atrix.org> ie "fork if you want to do experimental stuff" fragments the ecosystem, and "unfragmenting" it is extremely costly
<re_irc> <@f​irefrommoonlight:m​atrix.org> The PR process is an insurmountable obstacle
<re_irc> <@r​icharddodd:m​atrix.org> dirbaio: I had this issue with another crate (gloo). They wanted to provide a solid foundation for wasm on the web, but I think they were too conservative and as a consequence no one will put in the effort to contribute. I think once people are in production and depending on you you want to offer stability,...
<re_irc> ... but at the beginning you need to move fast and encourage people to participate.
<re_irc> <@t​herealprof:m​atrix.org> @jamesmunns:matrix.org: You like standardisation work? 😅
<re_irc> <@r​yan-summers:m​atrix.org> It's a somewhat necessary process to ensure multiple users of one piece of code
<re_irc> <@r​yan-summers:m​atrix.org> I do think some responsibility needs to be put on the forkee. Some times you do have to kill some time to contribute things backward
<re_irc> <@r​icharddodd:m​atrix.org> I'm actually managing a crate that takes the almost opposite philosphy (called [optimistic merging](http://hintjens.com/blog:106)): https://github.com/linebender/druid-widget-nursery
<re_irc> <@f​irefrommoonlight:m​atrix.org> Hah - I was on the Gloo committee too. Just got cc'ed on an email about it
<re_irc> <@r​icharddodd:m​atrix.org> Optimistic merging couldn't work for software that was used in production (unless you cut and patched releases) but it works really well for that crate: there is minimal effort on my part, and contributors are happy as they see their work going in quickly.
<re_irc> <@f​irefrommoonlight:m​atrix.org> Ultimately realized, after writing a full frontend wasm framework in rust, I'd rather use html, css, And targeted JS only when required!
<re_irc> <@r​yan-summers:m​atrix.org> As a developer of safety critical firmware, this is the antithesis of how I operate
<re_irc> <@t​halesfragoso:m​atrix.org> But just putting the other side in, you can't also blame maintainers for not accepting something half done
<re_irc> <@t​halesfragoso:m​atrix.org> it will be on their back after to maintain that, and that's rough
<re_irc> <@t​herealprof:m​atrix.org> @dirbaio:matrix.org: High bar for consensus in nrf-rs/stm32-rs? I don't remember a single time when we actually tried to reach consensus.
<re_irc> <@r​icharddodd:m​atrix.org> I think there might have to be 2 ecosystems in embedded Rust: one for low power and 1 for mission-critical
<re_irc> <@r​icharddodd:m​atrix.org> they often seem to be incompatible
<re_irc> <@r​yan-summers:m​atrix.org> I've actually had a lot of constructive work with dirbaio on smoltcp work
<re_irc> <@r​icharddodd:m​atrix.org> Like you don't want an unpredictable async scheduler deciding when someone's heart should beat (extreme example)
<re_irc> <@t​halesfragoso:m​atrix.org> I haven't seen much problems on consensus on stm32-rs, but I also haven't see much new things proposed
<re_irc> <@t​halesfragoso:m​atrix.org> don't know about nrf-rs though
<re_irc> <@f​irefrommoonlight:m​atrix.org> Nice article I agree. My threshold for merging a PR is "Is the project better after being merged". If I don't like a code style or doc thing, I'll merge, then commit a patch
<re_irc> <@r​icharddodd:m​atrix.org> On a meta point, it's good if people feel like they can air frustrations they have, even if other people see it differently. It means stuff gets said and solutions get found.
<re_irc> <@r​icharddodd:m​atrix.org> firefrommoonlight: yeah I have even edited other people's patch to run rustfmt etc then merged it.
<re_irc> <@t​halesfragoso:m​atrix.org> Doing that for big projects gets a bit tiresome with time though
<re_irc> <@t​halesfragoso:m​atrix.org> "big"
<re_irc> <@r​icharddodd:m​atrix.org> thalesfragoso: you need more co-maintainers :)
<re_irc> <@t​halesfragoso:m​atrix.org> or not even tiresome, but you really don't get the time to do it
<re_irc> <@t​halesfragoso:m​atrix.org> @richarddodd:matrix.org: sure, but that's a big problem in OSS
<re_irc> <@f​irefrommoonlight:m​atrix.org> richarddodd Anything safety critical etc (medical devices, aerospace etc) involves tossing out general assumptions that are out of context
<re_irc> <@t​herealprof:m​atrix.org> @dirbaio:matrix.org: I disagree forking by default is a good approach. If you don't even try to get something fixed before forking, that's usually a sign that you don't value continuity a lot and people will reach their own conclusion about that.
<re_irc> <@d​irbaio:m​atrix.org> @therealprof:matrix.org: You've been *by far* the most vocally opposed to every change I've proposed in the entire community
<re_irc> <@r​icharddodd:m​atrix.org> I've been in the druid GUI project, and although the domain is different a lot of these same issues come up. For example they re-roll the platform abstraction library (`druid-shell`) rather than use `winit` like everyone else.
<re_irc> <@d​irbaio:m​atrix.org> I find it quite funny that now you're accusing me of not valuing the community
<re_irc> <@r​icharddodd:m​atrix.org> They are common problems that don't always have easy solutions.
<re_irc> <@f​irefrommoonlight:m​atrix.org> Yea - I think I disagree with you on p much every topic, and we have a personality conflict
<re_irc> <@r​icharddodd:m​atrix.org> Everyone who comments on this channel is clearly very capable and I have loads of respect for you all. Just FYI
<re_irc> <@r​icharddodd:m​atrix.org> I have felt like there is a little risk of falling out/fragmentation, and I would say that everyone should try to avoid that at all costs.
<re_irc> <@t​herealprof:m​atrix.org> @dirbaio:matrix.org: Not true.
<re_irc> <@r​icharddodd:m​atrix.org> Because all the work that goes on here is good, although opinions may (and do) differ.
<re_irc> <@t​herealprof:m​atrix.org> At least I don't think it is true. Not sure how much other opposition you get. 😅
<re_irc> <@t​herealprof:m​atrix.org> We're quite often on the same side, e.g. the latest e-h discussions.
<re_irc> <@d​irbaio:m​atrix.org> I worded that too strongly, sorry. Not every change, but many
<re_irc> <@f​irefrommoonlight:m​atrix.org> sorry for being rude - my fault
<re_irc> <@d​irbaio:m​atrix.org> typestate-less gpio for example
<re_irc> <@t​herealprof:m​atrix.org> Well, I do have a different opinion about that? So do a lot of other people, what's the problem with that?
<re_irc> <@t​halesfragoso:m​atrix.org> I think we sometimes frame this a bit wrong though, the type state still exist, but just somewhere else
<re_irc> <@t​halesfragoso:m​atrix.org> ... on the driver
<re_irc> <@d​irbaio:m​atrix.org> No problem with that *per se*, however I hope you understand that after many instances of me proposing something and facing opposition, plus the current management style of "everyone has to agree or it doesn't get in", I stop trying
<re_irc> <@t​halesfragoso:m​atrix.org> I think if we just say typestate-less gpio people will think of completely runtime resolution (like `AnyPin` everywhere)
<re_irc> <@f​irefrommoonlight:m​atrix.org> I've gone full typestste-less. It's wild!
<re_irc> <@d​iondokter:m​atrix.org> @thalesfragoso:matrix.org: Skimming the chat here, I thought that too :P
<re_irc> <@d​irbaio:m​atrix.org> @therealprof:matrix.org: so it's not that I don't value continuity of the community projects as you're implying with that
<re_irc> <@t​herealprof:m​atrix.org> @dirbaio:matrix.org: Not everyone has to agree.
<re_irc> <@d​irbaio:m​atrix.org> I only started embassy *after* the community made it clear that async or typestate-less gpios is not getting in
<re_irc> <@d​irbaio:m​atrix.org> I definitely don't "fork by default"
<re_irc> <@d​irbaio:m​atrix.org> and I have contributed tons of stuff to nrf-hal
<re_irc> <@t​herealprof:m​atrix.org> @dirbaio:matrix.org: I'm not implying anything. I'm pointing out that forking before fixing is frowned upon by a lot of people.
<re_irc> <@d​irbaio:m​atrix.org> I *don't "fork before fixing"*
<re_irc> <@t​halesfragoso:m​atrix.org> Come on, a lot of people love async, nightly-only is that what throws people off a bit
<re_irc> <@t​herealprof:m​atrix.org> People indeed love async.
<re_irc> <@t​herealprof:m​atrix.org> ... and embassy.
<re_irc> <@f​irefrommoonlight:m​atrix.org> I tried fixing, forking etc, and determined it wasn't effective
<re_irc> <@t​herealprof:m​atrix.org> @dirbaio:matrix.org: Not saying you do, but a few others here.
<re_irc> <@d​irbaio:m​atrix.org> I've even *fixed after forking*: discovered mistakes in nrf-hal while implementing something in embassy, and *PR'd a fix to nrf-hal even though I'm zero invested in nrf-hal personally at this point*
<re_irc> <@t​halesfragoso:m​atrix.org> I think embassy was the right move, is something completely different, very far from fork instead of fixing
<re_irc> <@t​herealprof:m​atrix.org> @thalesfragoso:matrix.org: Yes, embassy is definitely not anywhere near that category.
<re_irc> <@f​irefrommoonlight:m​atrix.org> Ok forget it. All you do is throw spears. You don't build anything you're a roadblock.
<re_irc> <@t​herealprof:m​atrix.org> Is it even fork? I didn't think so.
<re_irc> <@t​halesfragoso:m​atrix.org> I for one will be pushing for some changes (that got discovered in embassy) in the overall ecosystem, but unfortunately, I do think it takes a bit of time
<re_irc> <@t​halesfragoso:m​atrix.org> and effort
<re_irc> <@t​halesfragoso:m​atrix.org> because, well, it's work, and not everyone works with this
<re_irc> <@t​halesfragoso:m​atrix.org> including me, so I know why it takes some time to bring things in
<re_irc> <@t​herealprof:m​atrix.org> That's very commendable! I think one of the main benefit of experimentation in a lot of different directions is that the obtained knowledge can be fed back into other projects.
<re_irc> <@t​halesfragoso:m​atrix.org> What blog platform people recommend ? Zola ?
<re_irc> <@t​herealprof:m​atrix.org> Yes.
<re_irc> <@t​halesfragoso:m​atrix.org> okay then, I gonna really try to write about stuff now, maybe that helps
<re_irc> <@r​icharddodd:m​atrix.org> I feel like some of the problems here are communication problems rather than anything more fundamental
<re_irc> <@t​herealprof:m​atrix.org> @thalesfragoso:matrix.org: Let me know if you need help setting that up.
<re_irc> <@r​icharddodd:m​atrix.org> Blogging is definitely a good way of showing people what you're up to.
jasperw has quit [Ping timeout: 252 seconds]
<re_irc> <@r​icharddodd:m​atrix.org> My day job is a researcher (in a non-embedded field) and I hate writing stuff up for journals but you have to do it if you want people to know what you are doing
<re_irc> <@t​herealprof:m​atrix.org> There're a few caveats setting that up if you intend to publish on GH pages.
<re_irc> <@r​icharddodd:m​atrix.org> And blogging is waaaaaaaay better than academic publishing for many reasons
<re_irc> <@r​icharddodd:m​atrix.org> IMO
<re_irc> <@t​halesfragoso:m​atrix.org> @therealprof:matrix.org: That's my intend, thanks for the help, I will reach for you if I get stuck along the way, thanks :)
<re_irc> <@t​halesfragoso:m​atrix.org> And about the communication problems, if someone is having trouble communicating with some part of the ecosystem in specific that I'm part of, I would be glad to try to help
<re_irc> <@t​halesfragoso:m​atrix.org> I think I might be able to help bridging stuff
<re_irc> <@r​icharddodd:m​atrix.org> I mean communication of softer stuff like respect for each others work, which is sometimes thought but not said out loud
<re_irc> <@d​irbaio:m​atrix.org> therealprof: I would like to give you some feedback. You often say things that come across rather clearly as accusations, such as the one above. Please don't do that, it's not constructive and its only outcome is creating animosity.
<re_irc> <@d​irbaio:m​atrix.org> Even if you later backtrack on these, such as with "I didn't mean that" or "yes, but not you", it is a fact that these things you say come across as accusations to others, which is causing harm regardless.
<re_irc> <@d​irbaio:m​atrix.org> ie what really matters is what it comes across as, not what you "really meant" beause people don't have telepathy devices to read your mind to figure out what you really meant
<re_irc> <@j​amesmunns:m​atrix.org> unrelated: if anyone wants help setting up (zola or mdbook) and netlify, I would be happy to show you how to do it. I use it personally, and we use netlify for everything at ferrous.
<re_irc> <@j​amesmunns:m​atrix.org> It is, IMO, a much more reasonable tool than GH pages.
<re_irc> <@j​amesmunns:m​atrix.org> (feel free to DM me, I can point you at written resources, or I can set up a quick zoom call to walk you through it personally)
<re_irc> <@d​iondokter:m​atrix.org> I've got one using Pelican on Netlify, but I don't like it that much. I should look into Zola at some point
<re_irc> <@j​amesmunns:m​atrix.org> Their free tier is more than acceptable for most people. I use netlify (and zola and mdbook) to power jamesmunns.com (my blog) and lab.jamesmunns.com (my public lab notebook)
<re_irc> <@j​amesmunns:m​atrix.org> (also, I highly recommend having both kinds of formats, at some point. I use the blog for more polished/refined commentary, but the lab notebook is great for sharing half-baked ideas and notes before I'm ready to call them "done enough" for a full blog. your mileage my vary, but I found it helps avoid writers...
<re_irc> ... block for me)
<re_irc> <@r​icharddodd:m​atrix.org> Another thing is that people in these chatrooms come from different places with subtly different cultures: my boss at work is very direct and originally I didn't take it well but then I realised he didn't mean it in a bad way, he was just from a country where everyone is direct
<re_irc> <@r​icharddodd:m​atrix.org> Ok I'll shut up now 🙂
<re_irc> <@d​iondokter:m​atrix.org> Dutch? :P
<re_irc> <@j​amesmunns:m​atrix.org> I was guessing German :D
<re_irc> <@d​iondokter:m​atrix.org> Haha Germans are similar yeah
<re_irc> <@f​irefrommoonlight:m​atrix.org> Bookmarked the notebook. Very nice attention to detail. I should really start one, at least a private one. Catalog things I've tried that worked, didn't etc. Could be a good reference for when having problems, and just the act of writing methodically should help workflow
<re_irc> <@f​irefrommoonlight:m​atrix.org> Might start with a handwritten one in OneNote on a tablet etc
<re_irc> <@f​irefrommoonlight:m​atrix.org> You have a good mix of images, text etc
<re_irc> <@j​amesmunns:m​atrix.org> ❤️
<re_irc> <@r​icharddodd:m​atrix.org> You know what he is Dutch
<re_irc> <@r​icharddodd:m​atrix.org> Good guess
<re_irc> <@d​iondokter:m​atrix.org> Haha well, I'm Dutch too
<re_irc> <@r​icharddodd:m​atrix.org> I've come to like his directness
<re_irc> <@r​icharddodd:m​atrix.org> It's easier to get stuff done.
<re_irc> <@d​iondokter:m​atrix.org> And since a year ago where I work we have Portuguese colleagues. They say it takes quite a lot to adjust to it
<re_irc> <@r​icharddodd:m​atrix.org> And he does a mad amount of work.
<re_irc> <@r​icharddodd:m​atrix.org> It would help if people talk about this stuff more
<re_irc> <@d​irbaio:m​atrix.org> my father is dutch =D
<re_irc> <@d​iondokter:m​atrix.org> Yeah, you have a very Dutch last name :P
<re_irc> <@d​irbaio:m​atrix.org> but I don't speak dutch 😭
<re_irc> <@d​iondokter:m​atrix.org> :( ;)
fabic has quit [Ping timeout: 268 seconds]
neceve has joined #rust-embedded
<re_irc> <@t​herealprof:m​atrix.org> @dirbaio:matrix.org: I'm not backtracking on anything. If I had a problem with your actions specifically I would phrase it very clearly that way. I do find it somewhat weird that some people (and that includes you!) very often reflect general observations on themselves in an absurdly negative way. But I take...
<re_irc> ... your point and will try to engage in everything even potentially political even less.
<re_irc> <@f​irefrommoonlight:m​atrix.org> How that reads: Other people misinterpret what you say, and it's their fault. This is consistent with many of your posts: seems polite on the surface, or as constructive criticism, but is manipulative at its core.
<re_irc> <@f​irefrommoonlight:m​atrix.org> I've decided ignoring you isn't the best option, because it's not right to leave your posts unchallenged
<re_irc> <@f​irefrommoonlight:m​atrix.org> It's not Ok
<re_irc> <@f​irefrommoonlight:m​atrix.org> Disagreement and constructive criticism is fine (and welcome) , no matter how direct. (How Dutch??). What you post doesn't fit this. It's consistently manipulative, and underhanded
<re_irc> <@f​irefrommoonlight:m​atrix.org> Dirbaio gave you a perfect opening to smooth over disagreements or demonstrate humility - you didn't take it
Wetmelon has quit [Ping timeout: 240 seconds]
<re_irc> <@c​hris_sk:m​atrix.org> Hello :) is there a usb host example for stm32f4xx i can check for ? the closest i found was the usb-uart echo in the hal GitHub
rjframe has quit [Quit: Leaving]
Wetmelon has joined #rust-embedded
neceve has quit [Ping timeout: 268 seconds]
<re_irc> <@t​halesfragoso:m​atrix.org> @chris_sk:matrix.org: I haven't seen a host implementation for the F4
<re_irc> <@t​halesfragoso:m​atrix.org> I remember seeing something for samd
<re_irc> <@d​khayes117:m​atrix.org> I'm working through the Embedded Rust Discovery Book, and when I modify the 05-led-roulette program as the instructions say, the build fails
<re_irc> <@d​khayes117:m​atrix.org> I get several duplicate symbol errors