ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
<M9names[m]> yeah, but you don't have to calculate them because static linker does it for you.
<M9names[m]> vs storing the placeholders and doing the patches at runtime
<M9names[m]> or you need to use elf and have an elf parser? but i guess that work is already done too...
pbsds has quit [Quit: Ping timeout (120 seconds)]
pbsds has joined #rust-embedded
<M9names[m]> i know thejpster is using elf for neotron:
IlPalazzo-ojiisa has quit [Quit: Leaving.]
AtleoS has joined #rust-embedded
ef has joined #rust-embedded
ef has quit [Client Quit]
AtleoS has quit [Quit: AtleoS]
AtleoS has joined #rust-embedded
cr1901_ has joined #rust-embedded
cr1901 has quit [Read error: Connection reset by peer]
shashankx86[m] has quit [Quit: Idle timeout reached: 172800s]
starblue has quit [Ping timeout: 264 seconds]
starblue has joined #rust-embedded
lehmrob has joined #rust-embedded
ello has quit [Quit: ZNC 1.8.2 -]
ello has joined #rust-embedded
lehmrob has quit [Ping timeout: 246 seconds]
ruabmbua[m] has joined #rust-embedded
<ruabmbua[m]> Yeah was also struggling with RISCv embedded PIC rust code
<ruabmbua[m]> Funny thing was, that only one function seemed to not work in my app,, and I thought it was my fault
ef has joined #rust-embedded
AtleoS has quit [Ping timeout: 272 seconds]
sourcebox[m] has quit [Quit: Idle timeout reached: 172800s]
ef has quit [Quit: ef]
AtleoS has joined #rust-embedded
AtleoS has quit [Changing host]
AtleoS has joined #rust-embedded
jr-oss has quit [Ping timeout: 256 seconds]
jr-oss has joined #rust-embedded
IlPalazzo-ojiis1 has joined #rust-embedded
uliano[m] has joined #rust-embedded
<uliano[m]> The following code works but to me it made a lot more sense to setup the `p.MCO` (which is a clock) within `setup_clocks()` but then I get the error in the comment.
<uliano[m]> I have this very lame question.
<uliano[m]> In general, as p is container for a lot of heterogeneous peripherals is there some way to avoid a huge function that splits it apart and returns a tuple of pieces to be distributed where they are needed?
<dirbaio[m]> the reason it works this way is to check at compile time you're not using the same peripheral twice
<dirbaio[m]> if you could use p.MCO in setup_clocks() and still return the whole Peripherals, you could use p.MCO again from main, breaking things
<uliano[m]> yes I see that
<dirbaio[m]> so yes, you have to split the peripherals into part
<dirbaio[m]> s/part/parts/
<dirbaio[m]> there's macros that make it easier
<uliano[m]> so there is no way around to a large megasplitter function?
<dirbaio[m]> if you really want to
<dirbaio[m]> you can opt-out of the compile-time checking
<dirbaio[m]> with let mco = unsafe { peripherals::MCO::steal() };
<dirbaio[m]> that gives you a MCO from thin air
<dirbaio[m]> then it's on you to make sure you never use the same peripehral multiple times, the compielr can't check it anymore
<uliano[m]> I'm trying to learn, the usual way, not trying to impose my own
<uliano[m]> s/,//
<uliano[m]> my problem is thay examples around are toy programs and I havn't found yet a mature and complex project to predate patterns
<uliano[m]> * predate patterns from
<dirbaio[m]> these are the two ways: either split p into sub-structs (maybe with a macro), or use unsafe steal
<uliano[m]> got it, I choose the macro :-)
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #rust-embedded
haobogu[m] has quit [Quit: Idle timeout reached: 172800s]
badrb[m] has joined #rust-embedded
<badrb[m]> I need to connect an ESP32 to an old machine that speaks a slow serial communication protocol.
<badrb[m]> For various reasons, I cannot use the ESP32's built-in UART0 peripheral, the connection is made through regular GPIO pins.
<badrb[m]> What would be the proper way to implement this?
<JamesMunns[m]> Might be worth asking in, I think some of the esp32's have a pinmux that might help you map a UART to those pins, but bitbanging UART, even at slow speeds, isn't always very reliable.
<badrb[m]> Even at 4800 bauds?
hyphened[m] has quit [Quit: Idle timeout reached: 172800s]
<badrb[m]> Thanks, I'll look into it!
<JamesMunns[m]> at 4800 baud you still need to be reliably sampling at 9600hz (every 100us or so), likely more, which requires fairly tight interrupt control.
<JamesMunns[m]> not saying you can't! just saying it's hard to do reliably
vollbrecht[m] has quit [Quit: Idle timeout reached: 172800s]
david[m] has quit [Quit: Idle timeout reached: 172800s]
GrantM11235[m] has quit [Quit: Idle timeout reached: 172800s]
sajattack[m]1 has quit [Quit: Idle timeout reached: 172800s]
<badrb[m]> Right. The big old hundreds of kW boiler that will be controlled requires reliability 😅.
<badrb[m]> It looks like pinmux is possible on my ESP32, I’ll try that first
<JamesMunns[m]> fwiw, SENDING data by bitbanging is generally pretty easy (at least you only need interrupts at 4.8kHz), RECEIVING data is much much harder.
<JamesMunns[m]> if you can use the pinmux tho - that is 10000% a better idea.
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
kiarie404[m] has joined #rust-embedded
dne has quit [Read error: Connection reset by peer]
dne has joined #rust-embedded
crabbedhaloablut has quit []
crabbedhaloablut has joined #rust-embedded
AtleoS has quit [Quit: AtleoS]