mameluc[m] has quit [Quit: Idle timeout reached: 172800s]
<AdamHott[m]>
I have a project in mind, I think I remember dirbaio pointing out to me that I can connect a ESP32-C3-DevKit-RUST-1 to a B-L475E-IOT01A2 STM32 Discovery Kit, so that I don't have to deal with the AT wifi stuff. Is it correct that I'd use SPI to send serial data between the ESP32 and the STM32 to enable shared communication via the wifi module on the ESP32?
<AdamHott[m]>
Although if I can configure 2 I²C interfaces on the ESP32 and use Embassy to handle the Wifi communication, then I'd only need the ESP32 and just use that board. Does anyone know if it's possible to configure 2 2 I²C interfaces on ESP32-C3-DevKit-RUST-1?
<AdamHott[m]>
s/2//
<AdamHott[m]>
It says in the docs for the ESP32-C3 that there is 1 I²C interface, I'm not sure if its possible to configure additional I²C interfaces using available GPIO Pins.
<AdamHott[m]>
I'm trying to control 2 sets of servo motors, that's the need for 2 I²C interfaces.
<JamesMunns[m]>
do the servo motors have the same address? if not you can have two devices on the same i2c bus
<AdamHott[m]>
I planned on linking 4 of the servo motors to drive the robot forward, and 2 servo motors to do something else, not sure what just yet but they would be linked and share the same PWM line.
<AdamHott[m]>
Actually now that I think about it, maybe I'm confused
<AdamHott[m]>
Maybe I just need GPIO Pins to send PWM signals.
barnabyw[m] has joined #rust-embedded
<barnabyw[m]>
yeah most servos are controlled via PWM, which is completely different from I2C. either the ESP32-C3 has some PWM peripherals which you can use to make waveforms to control the servos, or you’ll need to “bit-bang” your own in software
<AdamHott[m]>
Okay thanks, I think for the purpose of the project I can keep it simple and just use PWM, and for that I'd just need available GPIO Pins. Is that correct?
<AdamHott[m]>
That's great news to be able to just use the ESP32 since it's small and doesn't take too much space!
<barnabyw[m]>
(that example uses freertos, you’ll have to modify it slightly to work with embassy)
<AdamHott[m]>
oh this is completely awesome!
<AdamHott[m]>
thank you so much, this is going to get me ahead of the game and I'm pumped!
vollbrecht[m] has joined #rust-embedded
<vollbrecht[m]>
all esp's have the led controller that is a classical pwm simple pwm controller backed by a 52bit timer. Though if you want to do motor controll with feedback, there are some esp's that also have the mcpwm peripheral that is more sophisticated ( e.g allows for feedback integration and modulation) and also this devices have pcnt peripheral ( pulse counter) that can be used with rotary encoders.
<vollbrecht[m]>
s/pwm//
<barnabyw[m]>
is there any advantage to using mcpwm with a servo, or is it intended for regular motors?
<barnabyw[m]>
(also whyyy did they call it ”LED control” rather than “PWM” 🙄)
<vollbrecht[m]>
barnabyw[m]: thats a good question :D
<AdamHott[m]>
vollbrecht[m]: this is great, I was wondering how to control servos with more precision!
<vollbrecht[m]>
you only need to be aware that the esp is a 3.3 volt device, e.g the pwm will have 3.3 volt peak to peak. So whatever you are feeding it needs to be ok with that
<barnabyw[m]>
it seems a bit hard to find a datasheet for the SG90 servos (the datasheet links from that mouser page are broken 🙄) but it looks like the input is 3.3v-compatible
<AdamHott[m]>
The voltage for to power the servo is 5V, so I bought a 7.4 volt battery and a step-down voltage regulator, terminal block to split the cables to all the servos. I think it will work.
<AdamHott[m]>
The voltage to power the servo is actually 4.8-6.0V
<AdamHott[m]>
So the step-down voltage regulator should work I think
<AdamHott[m]>
I'm not too concerned about the capabilities of the robot actually, as long as it does "something"
<barnabyw[m]>
robots are fun even if they just roll around and bump into things
<AdamHott[m]>
haha true!
sjm42[m] has quit [Quit: Idle timeout reached: 172800s]
SunClonus has joined #rust-embedded
SunClonus has quit [Quit: Leaving.]
<thejpster[m]>
Ugh, MSRVs and cargo do not get along.
<thejpster[m]>
The CI pipeline failed because they’ve pinned Rust to version 1.61 and cargo resolved the semantic versions in the dependency tree to include some concrete version of a crate that only builds on 1.63. So the project build just broke by itself due to external factors.
<thejpster[m]>
But I don’t know what the answer is. Encourage crates to specify their rust-version and change the resolver to ignore anything with too high a rust-version?
<dirbaio[m]>
Exactly that happening soon, hopefully
SunClonus has joined #rust-embedded
<firefrommoonligh>
<barnabyw[m]> "(also whyyy did they call it ”..." <- I thought you might be talking about Nordic! They use no-std names for diff periphs
danielb[m] has joined #rust-embedded
<danielb[m]>
<barnabyw[m]> "(also whyyy did they call it ”..." <- why did they call their whole low-power system RTC? don't question Espressif's naming, you'll just lose your sanity 😅
<JamesMunns[m]>
<danielb[m]> "why did they call their whole..." <- Even more fun:
<JamesMunns[m]>
* ESP32: LEDC means PWM
<JamesMunns[m]>
* Allwinner: LEDC means WS2812B control
<barnabyw[m]>
also, who decided that all peripheral names have to be acronyms
<barnabyw[m]>
and where are the devrel people who we can complain about this stuff to 😁
korken89[m] has quit [Quit: Idle timeout reached: 172800s]
<danielb[m]>
<barnabyw[m]> "and where are the devrel..." <- burnt out from all our complaints already? 🙃
thumbcore[m] has joined #rust-embedded
<thumbcore[m]>
Says DevRel instead of Developer Relations in a complaint about short names. 😆
<thumbcore[m]>
* names. 😆 (I'm trolling, I know what you mean...)
fuse117[m] has quit [Quit: Idle timeout reached: 172800s]
tiwalun[m] has quit [Quit: Idle timeout reached: 172800s]
therealprof[m] has quit [Quit: Idle timeout reached: 172800s]
<barafael[m]>
it simply defines an Array that implements core::fmt::Write so that I can use write! without a heap. I believe it is an improvement over a solution somewhere on stack overflow. But is there a crate that does this? Or should there be? On the one hand it's kinda simple, on the other hand very reusable. Or is this entirely unnecessary. What do you think?
<dirbaio[m]>
or, next release will have a format! macro that creates the string for you. (it's available on git now)
<barafael[m]>
And format determines the output size dynamically but on the stack? Fancy
<dirbaio[m]>
not dynamically, it either infers it from the LHS type or you tell it.
<dirbaio[m]>
but there's still a fixed max set at compile-time.
<barafael[m]>
sweet!!!
<barafael[m]>
anecdote/question that came up today. My EE friend asked how bad would it be to talk both I2C and SPI on the same data/clk lines. Assuming we can make the pullups work, how bad would it be? The CS line tells the SPI device not to care, and an I2C start condition + address is "relatively unlikely". But still it seems like a very bad move
<barafael[m]>
* to care (while doing I2C), and, * "relatively unlikely" (while doing SPI). But
<dirbaio[m]>
I wouldn't do it, no 🤣
<barafael[m]>
he was like "can we just try it" and there I sat having to bend over backwards to make the compiler accept this bogus program :D didn't try it yet but also don't want to :D
<dirbaio[m]>
anyone familiar with cursed atomics stuff?