<jannic[m]>
I'm looking for a DIN rail mountable microcontroller with ethernet. Of course rust programmable :-) but besides that it only needs a single digital input. The things I found on the internet were all totally overpowered and expensive. Any suggestions for an affordable option? https://www.shelly.com/de/products/shop/shelly-pro-1-1 looks promising but I have no idea what it's based on and if it's possible to replace the firmware.
AndreasFischer[m has joined #rust-embedded
<AndreasFischer[m>
Shellys I think, contain an esp32
<jannic[m]>
At least some do, yes, but I'm not sure if it's true for all of them.
<Darius>
I think if you look for "DIN rail mount" you will end up looking at industrial things which are expensive..
<jannic[m]>
It's obvious that I won't get it for a few bucks at aliexpress. But I'd hope it would be possible to get something for like <100€.
marmrt[m] has joined #rust-embedded
<marmrt[m]>
I would look at getting a separate plastic DIN mount, and then find a devboard that roughly fits the mount
<marmrt[m]>
They are of course available in various dimensions from various suppliers
<jannic[m]>
Yes, that could be an option. Or even learn Kicad and build a fitting PCB, which interestingly can be fabricated much cheaper than a custom case :-)
vollbrecht[m] has joined #rust-embedded
<vollbrecht[m]>
I think most shelly's are based on esp32, and if i understand correctly the run a version of Mongoose OS, but i think they are not looked down, e.g you can reflash them. Though you need at least a ftdi adapter like the esp-prog for it since they usually doesn't contain anything onboard for that.
<vollbrecht[m]>
s/the/they/
ivche has quit [Quit: %bye%]
ivche has joined #rust-embedded
<JamesMunns[m]>
Maybe ping jamwaffles, he's been doing some stuff with Ethercat/ethercrab, might have some ideas around this
IlPalazzo-ojiisa has joined #rust-embedded
ryan-summers[m] has joined #rust-embedded
<ryan-summers[m]>
Are there any ethercat peripheral stacks in rust yet out of curiosity?
<ryan-summers[m]>
(Would be generally surprised, its a niche technology)
IlPalazzo-ojiisa has quit [Ping timeout: 240 seconds]
IlPalazzo-ojiisa has joined #rust-embedded
<JamesMunns[m]>
ethercrab is the only ethercat thing I'm aware of (it's a controller/master stack).
<ryan-summers[m]>
Yeah the C ones are all held behind the ETG's licensing terms so I'm unsurprised that one doesn't exist in Rust
<ryan-summers[m]>
* licensing terms and closed source so I'm
<ryan-summers[m]>
It's all oddly secretive
jamwaffles[m] has joined #rust-embedded
<jamwaffles[m]>
IIRC (it's been a while since I looked at the terms) you can write a SubDevice stack but you'd need to use an existing "blessed" ESC (EtherCAT SubDevice Controller) IC like the LAN9252 from Microchip. The licensing is tied to the chip (and its price tag lol) but that opens you up to writing the rest of the SubDevice stack without needing a license
<jamwaffles[m]>
Sponsor me if you want a SubDevice stack 😉
adamhott[m] has joined #rust-embedded
<adamhott[m]>
I'm working with a programmable servo whose protocol is closed source. Is there any way for me to reverse engineer the protocol?
<diondokter[m]>
adamhott[m]: Digital analyzer or oscilloscope is likely the best bet
<adamhott[m]>
I have an Analog Discovery 3, would that be sufficient for this type of thing?
<adamhott[m]>
Or would I need a bench top oscilloscope?
<diondokter[m]>
Depends on the protocol :)
<diondokter[m]>
But I think that one should be fine
<adamhott[m]>
What am I sending over, what I'm a looking for on the oscilloscope?
<diondokter[m]>
Well, what are the signals? You'll need to figure out what they mean
<adamhott[m]>
I just know there's a power, ground, and signal cable haha
<diondokter[m]>
I'm not really familiar with ESP hardware...
<adamhott[m]>
no worries!
<adamhott[m]>
are you more on STM32?
<diondokter[m]>
Yeah
<diondokter[m]>
I could look into the ESP stuff, but I don't have the time right now :P
<adamhott[m]>
No worries, do you know if there are any good examples for PWM for STM32? I could try with my NUCLEO board
<adamhott[m]>
It's a STM32H7
<diondokter[m]>
Embassy probably has one for your chip family
ainedixon[m] has quit [Quit: Idle timeout reached: 172800s]
<diondokter[m]>
Embassy and then the examples folder
<adamhott[m]>
ok thanks!
<adamhott[m]>
found it awesome!
xiretza[cis] has quit [Quit: Idle timeout reached: 172800s]
pronvis has joined #rust-embedded
<pronvis>
I am using RTIC channels to communicate between my structures (need 2 channel - for request and for response). And all fine, but now I need several instances of those structures.
<pronvis>
and RTIC return error on `make_channel!(Request, COMMUNICATOR_CHANNEL_CAPACITY)` saying "call to the same `make_channel` instance twice"
<pronvis>
cause I doing that in Struct constructor
<pronvis>
obv it fails with several instances
<pronvis>
Could you guys advice me what to use for multi producer single(or multi) consumer?
<pronvis>
tried `heapless::mpmc` , but it can not be splitted into producer and consumer. Only `heapless::spsc::Queue` have `split` method, but it is single producer which is not enough
<JamesMunns[m]>
you can use the mpmc, you don't need to split because both sides only use `&self` refs, so you can just stick it in a static.
<pronvis>
but I dont want Static :D
<pronvis>
I create those "channel for communication" in constructor. How could I do it with static?
<JamesMunns[m]>
any reason why?
<JamesMunns[m]>
but yeah I'm not familiar enough with RTIC to know how their current channels work.
<pronvis>
I have TMC2209 communicator. It accept requests via "channel" and send response from tmc2209 driver via another channel.
<pronvis>
Now I have several of those Communicators
<pronvis>
Creating several static queues and access them by some "communicator_index: u8" looks ugly to me
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded
pflanze has quit [Remote host closed the connection]
pflanze has joined #rust-embedded
dirbaio[m] has quit [Quit: Idle timeout reached: 172800s]
<adamhott[m]>
Does anyone know a cost effective way to decode PWM signals to reverse engineer a protocol for a digital servo. My Analog Discovery 3 doesn't have this capability.
<adamhott[m]>
I know I need some kind of tool
<JamesMunns[m]>
usually it's just measuring the pulse width?
<JamesMunns[m]>
(it varies a bit sometimes, but if you can measure the "high time" of your pulses with the discovery, that should be enough
<adamhott[m]>
The P1S servo is programmable but the protocol is closed by our manufacturer. The servo is already tuned to make full use of the potentiometer, that's about 290 degrees. It will have a dead zone due to the nature of the potentiometer. Considering the shifts on the two ends, we mark it as a 270-degree servo. I'm not sure about the resistance of the internal pot.
<JamesMunns[m]>
can you link me to whatever docs you have?
<JamesMunns[m]>
ah jk, you might want to use a larger time than 3ms to start, like 5-20ms instead maybe. Depends on the servo
<vollbrecht[m]>
also depending on mcu you are using for this project you now want to think about if you can utilze special peripheral on that mcu, so you don't have to manual measure via a timer or something, so you dont block the cpui non stop .
<adamhott[m]>
If I did want a tool to decode pwm signals, what would I buy?
<vollbrecht[m]>
With an esp32 you can use the mcpwm peripheral, it has a buildint decoder for pulse with measurements
<vollbrecht[m]>
since you were using an esp in the past ;D
<JamesMunns[m]>
adamhott[m]: There's not much to decode with "PWM" signals, you really can just measure:
<JamesMunns[m]>
* high time/duty cycle
<JamesMunns[m]>
* period (e.g. high time + low time)
<JamesMunns[m]>
servos are just kinda "vibes", there's no fancier protocol to decode there.
<adamhott[m]>
I have code for this test with ESP32 and STM32
<vollbrecht[m]>
yeah no need to buy extra stuff, just have to think about how to do it without blocking the complete mcu :p
<JamesMunns[m]>
vollbrecht[m]: don't most MCUs have "set PWM to X duty cycle at Y period, go forever"?
<vollbrecht[m]>
even interrupts can get expensive with 2 triggers on 500useconds
<JamesMunns[m]>
like, most MCUs I've used are just "go forever"
<adamhott[m]>
vollbrecht[m]: Do I have to send it random signals?
<JamesMunns[m]>
like, if you wanted to do fancy ramping, yeah, you can have cases like that, BUT a lot of PWM cores can also take DMA to do that for you.
<vollbrecht[m]>
ah doesn't he want to capture the motion? generating pwm is trivial
<JamesMunns[m]>
yeah, I think he's driving the PWM/Servo with the MCU, and wants to read it with the Logic Analyzer for confirmation
<vollbrecht[m]>
it can generate a 3phase pwm and also has a capture module all in one
<vollbrecht[m]>
but yeah special stm for sure also have similar hardware, but not everything have dedicated pwm capture hardware. Than you would have to think about alternatives
<vollbrecht[m]>
s/stm/stm32/
<vollbrecht[m]>
but you don't need it its just in the nice to have category if you dont drive anything to crazy
<JamesMunns[m]>
(also, MCPWM handles WAY fancier kinds of motors than servos. you can drive servos with VERY basic PWM control)
<JamesMunns[m]>
Essentially, servos have "internal parts" that do most of the stuff that MCPWM does, in terms of measuring the motor. This is why you can control them with a simple "go to this angle" command.
<adamhott[m]>
Cool!
<adamhott[m]>
I'll check this out!
<Maebli[m]>
General question, does embassy generally support low power modes / tickless idle e.g.stop/ standby on an stm32wlx or l0 or whats best for low power development
<Maebli[m]>
* power development?
<JamesMunns[m]>
Might be worth asking on #embassy-rs:matrix.org, in general it should support low power mode, "tickless" might depend on whether you use `embassy-time`. "stop" mode might entail loss of memory, which can get weird in some cases, but IIRC mameluc was doing that on one of the stm32w targets
<JamesMunns[m]>
in general, async doesn't require "ticks" like an RTOS might, as things are scheduled when they are prompted by an interrupt.
<JamesMunns[m]>
Embassy-time is a little different, depending on how you configure your time resolution and clock source, it has different requirements for how often it has to wake up to keep time.
<JamesMunns[m]>
Embassy time usually needs to wake up every 1/2 of your timer range, so if you have a 32-bit timer at 1mhz, that means it rolls over every 71 minutes, so embassy time would require a wakeup tick every ~35 minutes.
<JamesMunns[m]>
(if you use a different setup, like a 16 bit timer instead of 32-bit, or a 32.768khz clock instead of a 1MHz clock, your mileage may vary)
mameluc[m] has joined #rust-embedded
<mameluc[m]>
JamesMunns[m]: the way I did it was to put anything I want to keep during sleep (stop mode) in to SRAM2 then do sys_reset when it wakes up. So my low power stuff is outside of embassy and I have to re-initialize everything after wake up. The stop modes messes with the clocks and embassy doesn't really support that so this hack made it work for me. By turning of SRAM1 I save some current too.
<JamesMunns[m]>
mameluc[m]: fwiw, this is a very reasonable way to handle low power mode, unless you have a good reason, "reset when you come back from sleep" is a good way to stop from losing your mind chasing things that don't restore right.
<mameluc[m]>
yeah it gives some peace of mind. Also I have a lot of checks on SRAM2 to verify it is allright. For low power in rust embedded you usually need to drop the drivers anyway and embassy is kind of a driver for the mcu anyway so it makes sense
<vollbrecht[m]>
JamesMunns[m]: also called the Microsoft way of doing things, ala "reboot fix everything" :p jokes aside having a blank state is so much simpler.
<mameluc[m]>
Too bad I can't share the code as it is made for work but 800µA with RTC in sleep is achievable this way
<JamesMunns[m]>
vollbrecht[m]: 💯, so much of architecture + design is "constrain the explosion of possible state, so you can actually reason about changes and how things work"
<JamesMunns[m]>
JamesMunns[m]: "reboot" is the biggest and best weapon of "return to a known state" I know of lol
<mameluc[m]>
but is it really reset if you save some state in memory? :D
<JamesMunns[m]>
mameluc[m]: 800uA with radio on? Total sleep at 800uA sounds REALLY high, unless you have other stuff draining it...
<vollbrecht[m]>
mameluc[m]: in esp-land a deep-sleep starts your app from scratch again and you check for the reset reason, while rtc memory still alive ;D Well the CPU was reseted for sure. But yeah thats where the fun part begins, having now different kinds of resets ;D
<vollbrecht[m]>
does anyone uses a nrf power profiler kit 2? the software did look quite nice, and the board is pretty cheap, so was wondering if i should get me one.
<JamesMunns[m]>
sub-10uA is where stuff gets Weird, anyway
<vollbrecht[m]>
* kit 2 and have something positive to say? the
<JamesMunns[m]>
vollbrecht[m]: I've heard great things about the PPK1 and PPK2, I used PPK1 a while back, and got a PPK2, but haven't actually needed to use it
<vollbrecht[m]>
* kit 2 and have something positive to say? the, * pretty cheap for what it does, so
<vollbrecht[m]>
<mameluc[m]> "IMG_20240624_201010.jpg" <- is that a dc only measurement, or in other words what is the sample rate of the measurement here?
<vollbrecht[m]>
you have a two op stages with an adc or something in that package?
<mameluc[m]>
vollbrecht[m]: I don't actually know, whatever the default settings on the current ranger is. Seems to be somewhat stable. I am only interested in a ball park figure. my budget was 3µA anyway
<vollbrecht[m]>
s/a//
<vollbrecht[m]>
* you have two operational amplifier stages with an adc or something in that package?
<Maebli[m]>
Yeah my aim is like 3uA
<mameluc[m]>
but yes, "DC only" if you are only looking at the display. You are supposed to connect it to a scope to see the actual fluctuations. IIRC it was like 450 samples/second
<mameluc[m]>
<Maebli[m]> "But i would like to keep some..." <- you can keep ram intact in stop, I just choose not to as I want to reinitialize embassy_stm32 anyway
<JamesMunns[m]>
Turning off RAM usually saves more power, btw. It's not required, but useful for shaving more power usage off.
JomerDev[m] has joined #rust-embedded
<JomerDev[m]>
Since there was talk about pwm peripherals an hour ago, is anyone aware of any pwms with the ability to count the pulses? My use case is a stepper motor driver (tmc2300) which wants a step signal (a pwm) but I want to move the stepper motor x amount of steps. I guess timing it is an option, though on fast speeds it might not be that accurate
<JomerDev[m]>
* that accurate (especially with ramping up/down)
<JamesMunns[m]>
you mean like "setup PWM at this frequency, do N pulses then stop"?
<JomerDev[m]>
Yes
<JamesMunns[m]>
Nordic definitely has a cool PWM sequencing engine that can do this
<JamesMunns[m]>
many other chips will have some kind of DMA support, so you can build the next N steps in RAM
<mameluc[m]>
<mameluc[m]> "the way I did it was to put..." <- Actually I am running standby mode not stop mode.
sourcebox[m] has joined #rust-embedded
<sourcebox[m]>
It should be possible with STM32 timers also.
<vollbrecht[m]>
JomerDev[m]: esp32 also has a pcnt peripheral "The PCNT (Pulse Counter) module is designed to count the number of rising and/or falling edges of input signals." Its design is used to decode incremental decoder. But yeah if you are not to tight on timing, a fast mcu with a timer can do ;D
<JomerDev[m]>
JamesMunns[m]: Thats a very good point, I didn't really think of that
<JamesMunns[m]>
JomerDev[m]: yep, it's very reasonable to use a tool like `rampmaker`, generate the next N pulse widths of a ramp, then retrigger the next one.
<JamesMunns[m]>
not sure if the embassy drivers support double buffering or something, but I'd be surprised if it wasn't possible in HW
<sourcebox[m]>
On STM32, advanced timers have a repetition counter register, that should be suitable also for such tasks.
<JomerDev[m]>
Oh yeah, I just found `waveform_up` in the embassy docs and `ws2812_pwm.rs` in the examples for the stm32f4.
<JomerDev[m]>
I read through the simple pwm docs a few days ago but somehow totally missed that part
<JomerDev[m]>
Good to know, thank you, but sadly not an option in this case (or rather extremely overkill)
<henrik_alser[m]>
(You could run 6 instances if you have enough GPIO)
<henrik_alser[m]>
(Without CPU intervention)
<henrik_alser[m]>
JomerDev[m]: Overkill how?
<JomerDev[m]>
Fair enough. But in this case I'm looking more for a small single core processor, it only needs to read uart or ws2812 and control the stepper motor accordingly
<JomerDev[m]>
I neither nerds the rp2040s speed nor other perpherals
<JomerDev[m]>
s/nerds/need/
<henrik_alser[m]>
Gotcha (although there aren't so many cheaper options out there than the rp2040)
<JomerDev[m]>
I'm currently thinking one of the stm32g0 series
<henrik_alser[m]>
I see! :) No good options out of the box there peripheral-wise afaik, but you could bit bang it if you don't need the cpu for other things
<JomerDev[m]>
I found the waveform_up method in simplepwm
<JomerDev[m]>
Which should be good enough
<henrik_alser[m]>
Gotcha! I thought it was a classic 5-wire stepper!
<JomerDev[m]>
No, its 4-wire one, and I have a driver in between that does most of the heavy lifting. I just need to provide the steps and direction
<JomerDev[m]>
(But thanks for trying to help!)
firefrommoonligh has quit [Quit: Idle timeout reached: 172800s]