<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]>
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
<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 #esp-rs:matrix.org, 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.
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.