<JomerDev[m]>
adamgreig: Interesting, would that allow for different values per channel or just for one limit? In any case, seems like the stm32g4 I have doesn't have that feature
adamgreig[m] has joined #rust-embedded
<adamgreig[m]>
It definitely does, check section 21.4.28 of the reference manual. Looks like you can have up to three different values to check against, one of them 12bit against first conversion and the other two both 8bit against any/multiple conversions in sequence
<adamgreig[m]>
The g4 has just about the most analogue features of any stm32 I think, it's their latest mixed signal family
<JomerDev[m]>
<adamgreig[m]> "It definitely does, check..." <- Ah, I guess it helps to look at the reference manual instead of the datasheet, it has a lot more info. But sadly three values is not enough for me, I need to be able to set a threshold per channel
sigmaris has joined #rust-embedded
<adamgreig[m]>
Fair enough! Then I think you are best setting up a conversion sequence where the adc automatically samples all relevant channels one after the other, each result is DMAd to a buffer, once the buffer is full you get an interrupt and can process that whole buffer
<adamgreig[m]>
It's probably easier to make that happen as something you trigger each time but you could also set it up with double buffering so it just keeps going in the background too
<JamesMunns[m]>
So the more common way would be to use something like environment variables which can be loaded at compile time, and sorted out in a const context
<JamesMunns[m]>
this is what embassy and defmt do, for example
<JamesMunns[m]>
e.g. if you don't specify DEFMT_LOG, you get some level, but if you specify DEFMT_LOG=warn, you get that log level
<JamesMunns[m]>
My crate is a "hack" because it "guesses" where your main project is, and therefore where the config file is, so it can load it at compile time
<JamesMunns[m]>
It usually works, but if you did something allowed but not usual, like setting a different target dir path, it'd probably break (or get the wrong data!)
<haobogu[m]>
JamesMunns[m]: If I got a quite complex configuration struct, each fields could be a single environment variable, right? missing the structure of configuration
<JamesMunns[m]>
Yes, you could do that!
<haobogu[m]>
JamesMunns[m]: I'm considering migrate your crate to `build.rs`, so we don't need to "guess", just check if the config exists.
<JamesMunns[m]>
I don't think that's possible, if you want to configure your dependencies. If you only want to configure the crate your config file is in - yes that's a much better idea!
<JamesMunns[m]>
Like if you have a library, and users want to configure it, the library is built BEFORE your build-rs is run
<JamesMunns[m]>
So toml cfg actually loads the config file in every library's build.
<JamesMunns[m]>
But if you find a better way to do it please tell me! This was the best I could do.
<haobogu[m]>
Yeah, I'm going to distribute build.rs with a project template, so I suppose all users' build scripts are same, as provided
<haobogu[m]>
JamesMunns[m]: yes, it's quite hard, I've searching solutions for a few days but got nothing, except yours :D
<JamesMunns[m]>
haobogu[m]: Like I said, I don't *think* this will work, but please let me know if I'm wrong.
<JamesMunns[m]>
And if you find a way to make toml cfg less hacky, I'll totally update it!
<JamesMunns[m]>
I made it as a proof of concept but don't really use it.
<JamesMunns[m]>
Ping me if you aren't sure how it works, I should probably improve the docs and someone asking good questions always helps with that.
<haobogu[m]>
I'll definitely try it, thanks a lot!
<JamesMunns[m]>
Tbh, this makes total sense, it is more or less the exact use case - matching functionality of C defines, which I'm sure the esp wifi crate is full of.
<JamesMunns[m]>
I just didn't realize anyone was actually using it.
mabez[m] has joined #rust-embedded
<mabez[m]>
Actually we mainly use it for non-define like parameters actually :D
<JamesMunns[m]>
Nice! I remember that you SOMEHOW have to make sure those consts are used tho. but maybe I wasn't holding it right
<mabez[m]>
We're also discussing using it for more than just esp-wifi, https://github.com/esp-rs/esp-hal/issues/1111, but we'd probably need to expand its functionality or build on top of it
<haobogu[m]>
<JamesMunns[m]> "Like if you have a library..." <- Just had a try, yeah it's impossible to config dependencies without have a `hack_retrigger`, `build.rs` in user's workspace is called only when building the final binary.
<haobogu[m]>
Maybe generating all config consts at user 's workspace and pass all configs to library is a solution with project-template
<JamesMunns[m]>
<mabez[m]> "We're also discussing using it..." <- ah neat! I need to fix my github notifs, at some point I made it stop emailing me completely (lol burnout rage quit), but I need to go and fix that since I totally miss PRs and stuff for a long time.
<JamesMunns[m]>
Fwiw (for anyone here if you ever need me on GH): @ mentions still work, and I don't mind being pinged here in chat (to a reasonable extent)
<JamesMunns[m]>
I'll merge lu-zero's PR, and if anyone from the esp team wants to be a maintainer on toml-cfg I'm happy to grant permissions
<michaeldesilva[m>
<dirbaio[m]> "michael.desilva: you should be..." <- Oh I'm being silly. Missing pub 😅 thanks!
<dirbaio[m]>
(the embassy one exists so embassy-sync stuff like Channels can be generic over the mutex kind)
IlPalazzo-ojiisa has quit [Remote host closed the connection]
Atlas667 has joined #rust-embedded
Atlas667 has quit [Killed (ozone (No Spam))]
Atlas667_1 has joined #rust-embedded
<michaeldesilva[m>
I noted Embassy CI is using teleprobe https://teleprobe.embassy.dev/ any ideas where these are physically hosted? Or are these some virtualised hardware in a VM/cloud target?
<dirbaio[m]>
> though i guess i could just let defmt print to serial and read that via USB - i'd just have to flash + read separately and probably miss the first log entries since the device reboots after flashing and uses the USB port for file transfer during flashing?).
<dirbaio[m]>
you also lose panic messages, because on crash it's hard to keep USB working. so it's NOT great, very not recommended to develop this way.
<barnabyw[m]>
I’ve heard some people here mention that the dedicated pico probe can be flaky or unreliable, idk if that applies to a pico with probe firmware flashed to it
<Ralph[m]>
mabez[m]: ah, perfect. since you're already replying for the esp32c6 😀: i first thought about buying the rust-specific board, but it's out of stock at digikey (they want you to [order a batch of 240 boards](https://www.digikey.ch/short/1hn1pf4z) as a minimum order?!) and the esp32c6 board is a fraction of the price of the rust board anyway
<dirbaio[m]>
the official rpi Debug Probe is exactly the same as a pico with the picoprobe firmware, just different form factor
<dirbaio[m]>
they work equally well
<dirbaio[m]>
I haven't found it unreliable at all, on the contrary, it works quite well
<barnabyw[m]>
even if it is flaky, it’s probably hard to beat a pico probe for the price
<dirbaio[m]>
who said it's flaky? :D
<barnabyw[m]>
can’t remember exactly who, but a few people in one of the embedded rust rooms were discussing it being unreliable in the past days IIRC
<mabez[m]>
Ralph[m]: The rust board has more stuff, like accel sensors and lipo chargers etc which we have some free training materials to go through with. If you have a project in mind go for the devkitC, as you said its much cheaper :D
<Ralph[m]>
mabez[m]: yeah, i saw that it has those things - i just don't think that i currently have a use for it. but i can see that it's nice for playing around! price-wise i think it's fair for what it offers!
<Ralph[m]>
i don't have any specific project in mind... this is more a "i'm looking at digikey and trying to add a useful starterkit of things to play around with to my shopping cart and try not to break the bank at the same time" (those LIDARs sure do look nice... 😅)
<Ralph[m]>
ok, so if i get @dirbaio right i should just get a 2nd RPi Pico (i'll probably grab a Pico WH as it costs marginally more and then i can use that for other things as well in case i need two of them). what about the connector - how are you doing that?
sjm42[m] has joined #rust-embedded
<sjm42[m]>
Just my $0.02 here, I have purchased & received a few dozens of these:
<sjm42[m]>
I like those very much, and WeAct makes nice hardware and pcbs are of good quality and design.
<dirbaio[m]>
I use all the non-H picos, with dupont wires for evertything. works okay
<dirbaio[m]>
but it's becuase I bought them because the H picos existed
<dirbaio[m]>
the custom cable/connector thing on the H and the Debug Probe seems nice if you standardize on that, but it seems annoying if you want to connect to other things...
<sjm42[m]>
Personally I see absolutely no point in H mainly because I can solder stuff and have lots of equipment in my homelab...
<sjm42[m]>
I get that other people frown on soldering anything.
<sjm42[m]>
s/I get that other people frown on soldering anything./I get that some people frown on soldering anything. It's fine. There are alternatives./
<JamesMunns[m]>
as someone who has done teaching: "you need to buy 2x $4 boards" and "you need to buy 2 boards, a soldering iron, and learn how to solder" are very different barriers to entry
<Ralph[m]>
ok, so Pico W (non-H version) and just solder a normal header to the debug port as well?
<JamesMunns[m]>
if you have a soldering iron, I agree it's a little silly.
<Ralph[m]>
JamesMunns[m]: i already have the soldering iron (since a few days, got an old vellemann vtss7) and also have access to a lab with lots of soldering irons if i need to, so that's not an issue 🙂
<JamesMunns[m]>
yup! I wasn't sure if sjm42's point was "there is no point to the H version" and "there is no point to the H version *for him*.
<JamesMunns[m]>
(I wouldn't buy one either! but I have recommended them before :) )
<barnabyw[m]>
in my limited experience, you’ll quickly accumulate a collection of adaptors and cables for probes, so having a prove which it’s easy to plug different/custom things into is an advantage IMO
<sjm42[m]>
James Munns: haha I tried hard to emphasize that it's just my personal view and is not universally true...
<barnabyw[m]>
* in my limited experience, you’ll quickly accumulate a collection of adaptors and cables for probes, so having a probe which it’s easy to plug different/custom things into is an advantage IMO. look for one with clearly labelled pins/outputs!
<sjm42[m]>
But while we are at it, I also think that doing "something embedded" and trying to forever avoid any soldering... well, what kind of analogy should I make?
<sjm42[m]>
Going fishing and hoping you get no fish, or you have touch the slimy fish? 😆
<Ralph[m]>
sjm42[m]: > <@sjm42:matrix.org> But while we are at it, I also think that doing "something embedded" and trying to forever avoid any soldering... well, what kind of analogy should I make?
<Ralph[m]>
> Going fishing and hoping you get no fish, or you have touch the slimy fish? 😆
<Ralph[m]>
to be fair, you can do a lot of embedded things w/o soldering nowadays - you get lots of breakout boards (added benefit: you can re-use all these components rather than soldering them to a board and then throwing that away later (yeah, you could de-solder the things - but who's doing that if they're so cheap?))
<sjm42[m]>
A bit more aggressive comparison would be going to a restaurant for just watching people eat.
<sjm42[m]>
The less work-safe version mentions a brothel...
<JamesMunns[m]>
I mean, maybe more "hello fresh" vs "shopping yourself" 🤦♂️
<sjm42[m]>
Ralph[m]: Yes of course you are right. But you end up soldering something _eventually_ 🙂
<sjm42[m]>
I am using solder and heat shrink + other stuff always with "production" hardware.
<sjm42[m]>
Of course any kind of prototyping or just tinkering is easiest with breadboards and alike.
<sjm42[m]>
Wanna see a "fun" project that included quite a bit of soldering ? 😆
<sjm42[m]>
(and desoldering, and it was actually using embedded Rust on a raspi pico)
WSalmon has quit [Read error: Connection reset by peer]
WSalmon has joined #rust-embedded
<Ralph[m]>
<sjm42[m]> "Wanna see a "fun" project that..." <- sure!
Guest7282 has left #rust-embedded [Error from remote client]
<Ralph[m]>
talking of "fun" DIY projects: do you have a set of "this is useful stuff" hardware (i'm mainly thinking of breakout boards and things like that) which you can recommend for general tinkering / prototyping / etc.? i guess it can't hurt to have a DC motor controller (and some motors to control 😅), an IMU (MPU6050 is not great but cheap, BNO055 is probably better?), a display (classic 128x64 from adafruit w/ SSD1306 controller) and
<sjm42[m]>
Well... this might need a bit of explanation. The beast in pictures is an electronic game that was made by the grandfather of my good friend.
<sjm42[m]>
I then promised him to try fixing it. Things led to another and then another, and I ended up ripping off 95% of all the old wiring, switches and relays and stuff.
<sjm42[m]>
All of that was then replaced with a few IO expander boards that were hooked up to a raspi pico with I2C.
<sjm42[m]>
Those expanders are my own design utilizing PCA9555 chips and optional ULN2003 darlington octo buffers.
<vollbrecht[m]>
this is me, when seeing wtf my boss just taped together again
<sjm42[m]>
Her name is Vappu, 12 years old now. Wrestles with her brother on a daily basis still.
<sjm42[m]>
The thermal camera images are there showing how I was able to find a few lamps that took 300mA while most of them took 50mA per lamp.
<sjm42[m]>
Just looking at the light would not reveal anything. Funny.
<Ralph[m]>
he sometimes looked at my screen like yours looked at your electronics - but with an even more exaggerated "wtf are you doing there? stop that, start petting/feeding/playing with me!"
<Ralph[m]>
sjm42[m]: i loved that photo! 12 is still young! my cat only adopted me when he was 12 years old (sadly he went missing when he was 16.5 😢).
<sjm42[m]>
(of course, in reality, both are just... invaluable and adorable)
<sjm42[m]>
* Well... this might need a bit of explanation. The beast in pictures is an electronic game that was made by the grandfather of my good friend *more than 50 years ago*.
<sjm42[m]>
I then promised him to try fixing it. Things led to another and then another, and I ended up ripping off 95% of all the old wiring, switches and relays and stuff.
<sjm42[m]>
All of that was then replaced with a few IO expander boards that were hooked up to a raspi pico with I2C.
SunClonus has quit [Quit: Leaving]
Guest7282 has joined #rust-embedded
jsolano_ has quit [Quit: leaving]
jsolano has joined #rust-embedded
cr1901_ is now known as cr1901
<cr1901>
Plz to give Vappu and her brother pets for me :3
AmanieudAntras[m has joined #rust-embedded
<AmanieudAntras[m>
Is anyone here interested in getting riscv64gc-unknown-linux-musl promoted to tier 2? I've got a PR ready for adding it to Rust's CI, but I need a second target maintainer for tier 2.
SunClonus has joined #rust-embedded
SunClonus has quit [Remote host closed the connection]
SunClonus has joined #rust-embedded
SunClonus has quit [Remote host closed the connection]
SunClonus has joined #rust-embedded
M9names[m] has joined #rust-embedded
<M9names[m]>
<Ralph[m]> "> <@sjm42:matrix.org> Just my $0..." <- That's not the real price though
SunClonus has quit [Quit: Leaving]
thejpster[m] has joined #rust-embedded
<thejpster[m]>
<AmanieudAntras[m> "Is anyone here interested in..." <- Maybe try Zulip? Might not be many Linux rv people here. You could also see who the maintainers are for the glibc version.