ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
loki_val has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 258 seconds]
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #rust-embedded
<re_irc> < (@xiugaze:matrix.org)> : yeah it's a play on shoegaze and the band xiu xiu
<re_irc> < (@xiugaze:matrix.org)> : so the problem I'm running in to then is the whole idea of peripheral singletons
<re_irc> < (@xiugaze:matrix.org)> if I'm writing two different drivers that both use pins on GPIOC, then I'm kind of stuck because there can only be one instance of GPIOC
<re_irc> < (@xiugaze:matrix.org)> Like in the thing I've been working on, I'm writing to an LCD that has an 8-pin data bus, and I can't figure out how to treat that bus as a single abstraction, so I think I have to manually write to the odr or bsrr to write data to the display
<re_irc> < (@xiugaze:matrix.org)> but my control pins for another peripheral are on GPIOC, and if I can only have one instance of GPIOC, how do I do everything I need to appropriately within the ownership system
<re_irc> < (@orclev:matrix.org)> Typically you can use that single instance of GPIOC to create multiple Pins and you'd pass the Pins to the drivers, not all of GPIOC
<re_irc> < (@orclev:matrix.org)> if you need shared access to a resource you need to wrap it in a lock to allow safe access to it from multiple places
<re_irc> < (@orclev:matrix.org)> As an example of how to abstract multiple pins you can see how the stm32f4xx-hal crate has abstracted the I2C bus: https://docs.rs/stm32f4xx-hal/0.13.2/stm32f4xx_hal/i2c/trait.Pins.html
<re_irc> It exposes a Pins trait that's defined for a tuple of Pins (SCL, SDA). These Pin instances are then passed into the I2C struct: https://docs.rs/stm32f4xx-hal/0.13.2/stm32f4xx_hal/i2c/struct.I2c.html
<re_irc> There are I'm sure many other ways to accomplish this, but that's one way.
<re_irc> < (@dkhayes117:matrix.org)> What's the best way to get an Error enum variant with "#[derive(Debug)]" into bytes to send over uart?
<re_irc> < (@grantm11235:matrix.org)> I think you can just do "write!(&mut uart, "{:?}", error).unwrap()"
<re_irc> < (@grantm11235:matrix.org)> https://doc.rust-lang.org/core/macro.write.html
<re_irc> < (@dkhayes117:matrix.org)> I'm aware or the write macro, but I'm getting errors.
<re_irc> < (@grantm11235:matrix.org)> does your uart implement "embedded_hal::serial::Write"?
<re_irc> < (@grantm11235:matrix.org)> This is the blanket impl that allows you to use a uart with the write macro https://github.com/rust-embedded/embedded-hal/blob/v0.2.x/src/fmt.rs
<re_irc> < (@dkhayes117:matrix.org)> using embassy_nrf
<re_irc> < (@grantm11235:matrix.org)> Ah, then it probably doesn't impl the old nonblocking serial trait
<re_irc> < (@grantm11235:matrix.org)> I'm not sure if there are already any adapters that you can use, but it would be super easy to write one
<re_irc> < (@grantm11235:matrix.org)> Just wrap you uart in a newtype, and impl this trait for it https://doc.rust-lang.org/core/fmt/trait.Write.html
<re_irc> < (@dkhayes117:matrix.org)> write!(&mut s_buf, "{:?}", e).unwrap();
<re_irc> error[E0599]: no method named `write_fmt` found for mutable reference `&mut [{integer}; 1024]` in the current scope
<re_irc> uart.write(&s_buf);
<re_irc> --> src/bin/app.rs:169:17
<re_irc> < (@grantm11235:matrix.org)> You can't write to an array because it doesn't impl "core::fmt::Write"
<re_irc> < (@grantm11235:matrix.org)> You can write to a "heapless::String" though
<re_irc> < (@firefrommoonlight:matrix.org)> : So, pretty much every rust lib that deals with this (ie HALs) ditches the ideal of reg-block-signleton for GPIO pins (on hardware that eg divides it into ports like thsi)
<re_irc> < (@firefrommoonlight:matrix.org)> For the reason you say
<re_irc> < (@firefrommoonlight:matrix.org)> Ie pin abstractions are more common. They don't buy you any of the race-condition-prevention periph singletons intend to stop, but are more ergonomic
<re_irc> < (@firefrommoonlight:matrix.org)> Or, you could use a free function or something and skip ownership entirely
<re_irc> < (@dkhayes117:matrix.org)> : i tried that too, same error
<re_irc> < (@firefrommoonlight:matrix.org)> I generally go pin abstraction if it makes sense, and free function if the ownership (eg between ISRs etc) gets messy
<re_irc> < (@firefrommoonlight:matrix.org)> So, pretty much every rust lib that deals with this (ie HALs) ditches the ideal of reg-block-singleton for GPIO ports
<re_irc> < (@grantm11235:matrix.org)> : Can you paste that error
<re_irc> < (@dkhayes117:matrix.org)> I just got it to build. I didn't have
<re_irc> use core::fmt::Write
<re_irc> < (@dkhayes117:matrix.org)> Thanks !
<re_irc> < (@grantm11235:matrix.org)> Huh, that's really weird that you need to import a trait to use a macro, but it looks like it is intentional so that you can choose between using "core::fmt::Write" and "std::io::Write"
causal has joined #rust-embedded
hwj has joined #rust-embedded
<re_irc> < (@marmrt:matrix.org)> Having to import traits gets me everytime
<Lumpio-> I really wish there was a way to implement something both as a trait and an inherent method at the same time
<Lumpio-> Because there are so many objects where the only methods are trait methods and they do literally nothing without. Might as well spare people from the trouble.
m5zs7k has quit [Ping timeout: 244 seconds]
m5zs7k has joined #rust-embedded
hwj has quit [Ping timeout: 240 seconds]
<re_irc> < (@nvxx:matrix.org)> From what I can tell "#[link_section = ".data"]" will let you define a specific function to be run from ram rather than flash, which is particularly useful on the RP2040 with it's relatively slow external flash. From testing a simple aes encrypt operation, the first time I called it took over 500us, while the second time was under 100us - which I'm guessing the speedup the second time around is due to the...
<re_irc> ... XIP cache. Naturally I'm after this 100us performance all the time, but the problem is I can't annotate the functions as they're in an external package. Is there a way to force eg the whole aes package code to be run from ram rather than flash?
<re_irc> <AviiNL> : nope, nothing yet, i tried to do literally everything manually with sending the initialization sequence of commands the same way they do it in the c sources, still not able to draw anything
<re_irc> <AviiNL> either the spi just isn't communicating with the device, or i'm still missing something
<re_irc> <AviiNL> the c sources do a "spi_end();" and "spi_begin();" which does a "CS_H;" and "CS_L;" respectively, which resolves to a giant mess of compiler conditions, but i think in my case it eventually resolves to
<re_irc> #define CS_L \
<re_irc> GPIO.out_w1tc = (1 << TFT_CS); \
<re_irc> GPIO.out_w1tc = (1 << TFT_CS)
<re_irc> #define CS_H GPIO.out_w1ts = (1 << TFT_CS)
<re_irc> <AviiNL> there is a "out_w1tc" on "peripherals.GPIO" but im not able to use it, because im also splitting the gpio pins, not sure how to access it in a way that satisfies the borrow checker
hwj has joined #rust-embedded
starblue has quit [Ping timeout: 272 seconds]
starblue has joined #rust-embedded
explore has joined #rust-embedded
<re_irc> < (@marmrt:matrix.org)> "unsafe{pac::peripherals::steal()}" 😎
<re_irc> <AviiNL> huh, neat, thanks, still nothing on screen though 😅
loki_val has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
hwj has quit [Ping timeout: 264 seconds]
tafama has quit [Quit: ZNC - https://znc.in]
tafa has joined #rust-embedded
<re_irc> < (@almindor:matrix.org)> AviiNL: did you check the display spec for what SPI mode is expected? The mode is configured in the "Config" of the SPI in your case (default of MODE0 is usually correct though)
<re_irc> <AviiNL> yeah it should take mode0
<re_irc> <AviiNL> "SPI.beginTransaction(SPISettings(SPI_FREQUENCY, MSBFIRST, SPI_MODE0));"
<re_irc> <AviiNL> as per the c code
<re_irc> < (@almindor:matrix.org)> and the C code works?
<re_irc> <AviiNL> i've used it before in the past
<re_irc> <AviiNL> it's a giant mess with a lot of compiler conditionals though for different devices
<re_irc> <AviiNL> as far as i remember from back then, it was bog-slow because it didnt use (or supported) parallalization and/or transactions
<re_irc> < (@almindor:matrix.org)> hmm, coz one thing you can try if you have a logical analyzer and a working code for it is to find a diff on the absolute basics
<re_irc> < (@almindor:matrix.org)> it could be a single bit in some MADCTL value or such. Sadly I can't help here as this is the only model I don't have :D
<re_irc> <AviiNL> am not that fancy unfortunately 😛
<re_irc> < (@almindor:matrix.org)> do you use a reset hw pin?
<re_irc> <AviiNL> no afaik
<re_irc> <AviiNL> this is the device im using
<re_irc> <AviiNL> as per the pinout, reset, backlight and power is controlled via a AXP192
<re_irc> < (@almindor:matrix.org)> reset should be given to the display in .init
<re_irc> < (@almindor:matrix.org)> otherwise you might not be lowering it right (it needs to stay set)
<re_irc> <AviiNL> yeah with SWRESET
explore has quit [Quit: Connection closed for inactivity]
<re_irc> <AviiNL> probably not the cleanest of code, but it's what im currently testing with
<re_irc> < (@jessebraham:matrix.org)> Sorry I missed the earlier conversation, you are aware there is "ili9342c" support in "mipidsi" already right?
<re_irc> < (@jessebraham:matrix.org)> I'm using that display in an "esp-hal" project already which is why I ask haha
<re_irc> <AviiNL> yes, but it's not working, which is what im investigating
<re_irc> < (@rfuest:matrix.org)> Can you measure if the HW reset pin is high? The AXP192 might pull it to 0V
<re_irc> < (@jessebraham:matrix.org)> Oh okay haha makes sense
<re_irc> < (@jessebraham:matrix.org)> Odd that it's not working for you
<re_irc> <AviiNL> : it's an enclosed box, i cant access the internals, and i dont wanna break it by prying it open
<re_irc> < (@jessebraham:matrix.org)> Is it the ESP32-S3-BOX?
<re_irc> <AviiNL> m5core2
<re_irc> < (@jessebraham:matrix.org)> Ahh okay
<re_irc> < (@jessebraham:matrix.org)> This is the minimal setup required for the BOX, assume the pins will change. This works for me though (all the drawing code as been removed in this gist)
<re_irc> < (@rfuest:matrix.org)> Did you try to set the GPIO4 pin to high using the I2C interface? According to the Chinese datasheet and Google translator it might default to be a low output.
<re_irc> <AviiNL> gpio4?
<re_irc> < (@rfuest:matrix.org)> GPIO4 on the AXP192 controls LCD_RST
<re_irc> <AviiNL> 🤔 not sure how
<re_irc> <AviiNL> think i found it, and yes, i am
<re_irc> < (@rfuest:matrix.org)> If you initialized GPIO4 correctly I would try to toggle it to execute an HW reset. I've never tried to use a ILI9xxx based display without using the HW reset. The Arduino firmware for your module also toggles the reset pin.
<re_irc> <AviiNL> yeah it's in the axp192s initialization
<re_irc> < (@rfuest:matrix.org)> Do you just initialize the pin or do you explicitly drive it low and then high again after some delay?
<re_irc> < (@rfuest:matrix.org)> That seems to be OK. Did you try a lower SPI clock rate for the display? 40 MHz is pretty high and is outside the spec for the ILI9342.
<re_irc> <AviiNL> i've tried everything from 20 to 40 and in between
<re_irc> <AviiNL> testing 20 again now
<re_irc> <AviiNL> 20 is a no go, 26 does nothing
<re_irc> < (@rfuest:matrix.org)> The max. according to the datasheet is 10 MHz. I would use something low, like 1 MHz, until it is working. Just to make sure this isn't a problem.
<re_irc> <AviiNL> thats interesting, the m5core2 library in c uses:
<re_irc> #define SPI_FREQUENCY 40000000
<re_irc> <AviiNL> +#define SPI_READ_FREQUENCY 16000000
<re_irc> <AviiNL> using a smaller main again now
<re_irc> <AviiNL> as per jesses (working) sample
<re_irc> < (@jessebraham:matrix.org)> I've run the ILI9342C at 48MHz without issues
Foxyloxy has joined #rust-embedded
<re_irc> < (@rfuest:matrix.org)> It will work with faster SPI clock rates, but it is technically an overclock.
<re_irc> < (@jessebraham:matrix.org)> Going much higher seemed to cause it to stop working
<re_irc> < (@jessebraham:matrix.org)> Oh yeah I'm just saying, you can usually push these way beyond their ratings haha
<re_irc> <AviiNL> lol
Foxyloxy has quit [Read error: Connection reset by peer]
<re_irc> < (@rfuest:matrix.org)> One difference between yours and jesses code is the handling of the CS pin. You could try to use `Spi::new_no_cs` and drive CS low manually. But at this point I'm just guessing.
dc740 has joined #rust-embedded
<re_irc> <alvela> : +1 to this
<re_irc> < (@firefrommoonlight:matrix.org)> : Yea; but I think this is probably unfixable for the duration fo the lang
<re_irc> < (@firefrommoonlight:matrix.org)> *Or maybe not
<re_irc> < (@firefrommoonlight:matrix.org)> But yea - super annoying
<re_irc> < (@firefrommoonlight:matrix.org)> -super
<re_irc> < (@firefrommoonlight:matrix.org)> Lumpio-: While you're probably looking for a terse syntax, I handle this by implementing natively, then calling the native fn from the trait
<re_irc> < (@firefrommoonlight:matrix.org)> You sometimes have to use "Struct::method(self" syntax to be explicit if they have the same name
<Lumpio-> I know you can do it, but it's cumbersome and many libraries don't do it.
<Lumpio-> if it was like one extra keyword in your impl, maybe more libraries would do it.
<re_irc> < (@almindor:matrix.org)> AviiNL: Sorry I was in a meeting. the hardware RST pin if it's connected to the display needs to be given to the display driver (or driven correctly). If you set it low during operation the display will NOT work
<re_irc> <AviiNL> the reset pin is controlled by the axp192, which toggles it during its init
<re_irc> < (@almindor:matrix.org)> but does it stay high?
<re_irc> < (@almindor:matrix.org)> it needs to stay high
<re_irc> <AviiNL> i can't say with 100% certainty, but i would assume so
<re_irc> < (@almindor:matrix.org)> I'd give it to the display in .init(&mut Ets, Some(RST))
<re_irc> <AviiNL> im doing the exact same thing in rust as the m5core2 sources in c do
<re_irc> < (@almindor:matrix.org)> just to be sure that's not the problem
<re_irc> <AviiNL> but what is RST then
<re_irc> <AviiNL> i dont have an exposed pin to give
<re_irc> < (@almindor:matrix.org)> it's the output pin connected to the RESET pin on the display
<re_irc> < (@almindor:matrix.org)> so the display has no RESET input pin?
<re_irc> < (@almindor:matrix.org)> if it doesn't then I guess it's ok, if it does though it needs to be kept high
<re_irc> <AviiNL> as far as im aware, the displays reset is connected to the axp192 chip
<re_irc> <AviiNL> which sets it high during init
<re_irc> <AviiNL> as per https://matrix.to/#/!BHcierreUuwCMxVqOf:matrix.org/$G3GCYTcUOeL9k0k7sQEGEn3GjU-JWWXsGls98NV1aRM?via=matrix.org&via=psion.agg.io&via=tchncs.de
<re_irc> < (@almindor:matrix.org)> this is just SW though you're sending data
<re_irc> <AviiNL> yeah im telling the axp192 chip to toggle its gpio4 pin, which is connected to the lcds reset
<re_irc> < (@almindor:matrix.org)> aaah I see
<re_irc> < (@almindor:matrix.org)> your mcu connects to a separate chip and that's connected to the display?
<re_irc> <AviiNL> at least, i assume that thats how it works based on the schematics and datasheets
<re_irc> <AviiNL> yush
<re_irc> < (@almindor:matrix.org)> coz usually it's MCU[SPI] => Display alongside with MCU[BacklightGPIO] => Display and MCU[RESETGPIO] => Display
<re_irc> <AviiNL> yea so here the BL and RST go _through_ the axp192
<re_irc> < (@almindor:matrix.org)> hmm so the main issue here could be if the axp192 drops the RESET Pin from high for some reason, it'd explain why it doesn't do anything (if the RST input isn't high the display is basically off)
<re_irc> < (@almindor:matrix.org)> you could check that with a basic multimeter though I guess
<re_irc> < (@almindor:matrix.org)> let it run its course and see if its still +3v
<re_irc> <AviiNL> yeah i dont really have access to its internals though ☚ī¸
<re_irc> < (@almindor:matrix.org)> the display is built in huh?
<re_irc> <AviiNL> yeah
<re_irc> <AviiNL> it a box
<re_irc> < (@almindor:matrix.org)> heh the worst kind :D
<re_irc> <AviiNL> i can try to open it, but i really dont wanna damage it
<re_irc> < (@almindor:matrix.org)> ah so your MCU is at the bottom and this hting has axp192 to help drive the display
<re_irc> < (@almindor:matrix.org)> so the axp192 handles backlight and reset, but the SPI is "passthrough" ?
<re_irc> <AviiNL> i guess?
<re_irc> < (@almindor:matrix.org)> ah I see now, i2c is used to drive the axp192 which drives the other pins, and SPI is passthrough to the display directly
<re_irc> < (@almindor:matrix.org)> that's an odd setup :D
<re_irc> < (@almindor:matrix.org)> i guess it's coz of all the other peripherals
<re_irc> < (@almindor:matrix.org)> yeah hard to debug the issue here :(
<re_irc> <AviiNL> yeah, it's got a bunch 😛
<re_irc> < (@almindor:matrix.org)> you could technically try to get a "expected bytes" out of the C driver (you can just sort of write them out) and try to SPI directly without mipidsi to see if init/1 pixel write kind of thing works
<re_irc> <AviiNL> not sure how capable matrix is, but on discord it'd jump in a voice channel with screenshare and a camera pointing at the thing if you want 😜
<re_irc> <AviiNL> if that helps
<re_irc> <AviiNL> : i tried that
<re_irc> < (@almindor:matrix.org)> and it worked?
<re_irc> <AviiNL> nope
<re_irc> < (@almindor:matrix.org)> dang
<re_irc> < (@almindor:matrix.org)> then we're on the SPI level issue
<re_irc> < (@almindor:matrix.org)> is this display read/write? (does it have MISO?)
<re_irc> <AviiNL> MISO and MOSI
<re_irc> < (@almindor:matrix.org)> good, try reading the id of it or such
<re_irc> < (@almindor:matrix.org)> there are read instructions, see if you get something valid back
<re_irc> < (@almindor:matrix.org)> if not there's something wrong with the SPI line
<re_irc> < (@almindor:matrix.org)> you need to do it as a transfer(command, readbytes) kind of thing
<re_irc> < (@almindor:matrix.org)> let me find the docs
<re_irc> < (@almindor:matrix.org)> you should get 4 bytes back last 3 of which indicate the manufacturer etc.
<re_irc> < (@almindor:matrix.org)> so you'd do something like "spi.transfer_in_place(&mut buf)" where "let mut buf = [0x04u8, 0, 0, 0, 0];"
<re_irc> < (@almindor:matrix.org)> we expect the last 3 bytes to be > 0 and consistent when repeated
<re_irc> < (@almindor:matrix.org)> IIRC this should work even without an init
<re_irc> <AviiNL> i dont see a transfer_in_place method 🤔
<re_irc> <AviiNL> oh it's just transfer
<re_irc> < (@almindor:matrix.org)> ah sorry that's the "new" (alpha versions v1.0 pending hal) name :D
<re_irc> < (@almindor:matrix.org)> yeah just tranfer in v0.2.7
<re_irc> <AviiNL> let mut buffer = [0x4u8, 0, 0, 0, 0];
<re_irc> Ok(res) => {
<re_irc> let result = match spi.transfer(&mut buffer) {
<re_irc> println!("SPI transfer ok");
<re_irc> <AviiNL> "Result: [255, 255, 255, 255, 255]"
<re_irc> < (@almindor:matrix.org)> o.O
<re_irc> <AviiNL> am i doing something wrong? đŸ¤Ŗ
<re_irc> < (@almindor:matrix.org)> i thought this would work and the i2c/chip would be the problem tbh :D
<re_irc> < (@almindor:matrix.org)> you're getting all 1s back
<re_irc> <AviiNL> i mean, the axp192 works, i can control the backlight and the attached led just fone
<re_irc> <AviiNL> * fine
<re_irc> < (@almindor:matrix.org)> hmm this seems like the SPI is not corrently setup but what the issue might be i have no idea
<re_irc> < (@almindor:matrix.org)> do you have any other module that uses SPI that could be tested?
<re_irc> <AviiNL> as in, a board?
<re_irc> <AviiNL> got a m5stick c plus
<re_irc> < (@almindor:matrix.org)> i mean something else that you can connect from M5 that uses SPI
<re_irc> <AviiNL> i dont
<re_irc> <AviiNL> only have the 2
<re_irc> < (@almindor:matrix.org)> you can then check if that'd work (at least the basics) as to eliminate SPI/hal implementation issue
<re_irc> < (@almindor:matrix.org)> coz if the C code worked and we're getting jibberish on SPI back here, it seems the hal could be the culprit
<re_irc> <AviiNL> the way the C code writes a byte is like this
<re_irc> #define tft_Write_8(C) \
<re_irc> WRITE_PERI_REG(SPI_MOSI_DLEN_REG(SPI_PORT), 8 - 1); \
<re_irc> // Write 8 bits
<re_irc> <AviiNL> i think anyway
<re_irc> <AviiNL> there;s so many ifdefs here that makes spagetti neatly organized
<re_irc> <AviiNL> +look
<re_irc> < (@almindor:matrix.org)> i suspect it's more of an issue of the init/config of SPI itself
<re_irc> < (@almindor:matrix.org)> maybe ask around the folk who implemented the hal, I'm afraid I can't help much more in this
<re_irc> <AviiNL> wouldnt more people have issues with SPI then?
<re_irc> < (@almindor:matrix.org)> i don't know, are you sure about all the pins with " let spi = Spi::new( peripherals.SPI2, pins.gpio18.into_push_pull_output(), pins.gpio23.into_push_pull_output(), pins.gpio38.into_floating_input(), pins.gpio5.into_push_pull_output(), 40u32.MHz(), SpiMode::Mode0, &mut p_clock_control, &clocks, );" (e.g. their states and numbers) ? also try going super slow speed something like 100Khz just to...
<re_irc> ... eliminitate speed problems
<re_irc> < (@almindor:matrix.org)> I'm not familiar with the MCU, on mine for example the SPI is HW controlled and the pins need to be in "iof" function mode
<re_irc> <AviiNL> it's just an esp32 afaik 🤷♂ī¸
<re_irc> < (@almindor:matrix.org)> maybe someone else here who has that could help. If you do get past the SPI part and it turns out to be something with the display driver I'm happy to help of course :)
<re_irc> < (@almindor:matrix.org)> why do you use the esp_hal_common crate? shouldn't the Spi et.al be taken from esp32_hal directly? (as per ```This crate should not be used directly; you should use one of the device-specific HAL crates instead:
<re_irc> esp32-hal
<re_irc> esp32c3-hal
<re_irc> esp32s3-hal```
<re_irc> esp32s2-hal
<re_irc> < (@almindor:matrix.org)> why do you use the esp_hal_common crate? shouldn't the Spi et.al be taken from esp32_hal directly?
<re_irc> < (@almindor:matrix.org)> they mention that in https://crates.io/crates/esp-hal-common
<re_irc> < (@almindor:matrix.org)> looking at https://docs.rs/esp32-hal/0.5.0/esp32_hal/spi/index.html they don't seem to set the pins state beforehand
<re_irc> <AviiNL> isnt that just a re-export?
<re_irc> < (@almindor:matrix.org)> oh wait that's using the latest e-h alpha.9
<re_irc> < (@almindor:matrix.org)> still they use different pins for it
<re_irc> <AviiNL> not using common doesn't seem to make a difference
<re_irc> < (@almindor:matrix.org)> i guess that depends on the board? but that's a bit odd chips usually have same numberings
<re_irc> <AviiNL> usage of gpio pins depends on what you attach to them though, right? 😛
<re_irc> < (@almindor:matrix.org)> yeah :)
<re_irc> < (@jessebraham:matrix.org)> : Nobody seems to listen to that for whatever reason haha, I tried
<re_irc> < (@almindor:matrix.org)> : what's the implication though if they use the hal?
<re_irc> <AviiNL> i am using esp32_hal though
<re_irc> < (@jessebraham:matrix.org)> You just need to make sure you have all the right features enabled I guess, it's possible to really muck things up if you don't
<re_irc> < (@almindor:matrix.org)> AviiNL: from m5stack pinout I see GPIO23, 19, 18 if I read this correctly (as labeled on the bus)
<re_irc> <AviiNL> orage is moved, blue is m5stack only ,light blue is m5core2
<re_irc> <AviiNL> so 19 became 38
<re_irc> <AviiNL> it's the outer pins on the bus image
<re_irc> <AviiNL> orange is moved, blue is m5stack only ,light blue is m5core2
<re_irc> < (@almindor:matrix.org)> aaah different thing then, sorry I'm not at home with their variants, I just have an old m5stack pinout coz I used their USB module (without their MCU just directly)
<re_irc> <AviiNL> ah fair
<re_irc> < (@hendrik:henku.de)> After a bit of searching the internet I'm still not sure if there is a better way to implement device drivers that need the blocking implementation of 'Delay' than to pass a reference of the delay to every driver API call.
<re_irc> < (@almindor:matrix.org)> : I think HALs could solve this by always providing a callback mechanism for delay (as one solution). This would be compatible with async too. So instead of just blocking Delay there should be a "Delay::after<T>(us: u32, cb: Fn(T))" (where T is anything you can pass in and get back)
<re_irc> < (@almindor:matrix.org)> this should of course be a clonable instance
<re_irc> < (@hendrik:henku.de)> : Does this mean that with the current HAL implementations passing a reference to delay is the only way?
<re_irc> < (@almindor:matrix.org)> : if you need multiple delays (as in more than 1 driver in use for the delay at the "same" time) then yeah, unless your hal happens to make them clone-able
<re_irc> < (@almindor:matrix.org)> most drivers only use them very short term init-only but I guess there can be those that need to delay during runtime
<re_irc> < (@almindor:matrix.org)> another solution that could work is to provide a "Delay::borrow" kind of mechanism that gives a separate reftype that's "Delay" and can be used only when needed using a locking mechanism (again clonable)
<re_irc> < (@almindor:matrix.org)> or just make "Delay" clonable with borrow mechanisms built in
<re_irc> < (@hendrik:henku.de)> I have a HD44780 implementation from the pre HAL era that is intended to provide a higher abstraction to get rid of the different RAM states and addressing stuff. By using the reference passing solution I would end up with a lot of internal forwarding of the delay reference, because the HD44780 communication needs delays everywhere.
<re_irc> < (@orclev:matrix.org)> Thinking about the problem with Delay makes me feel like it shares a lot of overlap with the problem of how to handle allocators. It's something that you potentially need in random places all over which makes it painful to pass around, but it also is hardware dependent and needs runtime configuration in order to get it into the proper state to use it (also depending on what you're trying to do you may...
<re_irc> ... want to configure it in a variety of different ways).
conplan has joined #rust-embedded
conplan has left #rust-embedded [#rust-embedded]
emerent is now known as Guest9042
emerent_ has joined #rust-embedded
Guest9042 has quit [Killed (zirconium.libera.chat (Nickname regained by services))]
emerent_ is now known as emerent
gth has joined #rust-embedded
conplan has joined #rust-embedded
conplan has quit [Remote host closed the connection]
conplan has joined #rust-embedded
dc740 has quit [Remote host closed the connection]