ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
<cr1901_> Nope, I'm done for today. The HAL changed too much between 6 and 8. It's not a one or two hour task to modify even an existing app.
cr1901_ is now known as cr1901
<re_irc> <dirbaio> cr1901: I guess "wait()" would wait until the timer's hardware "overflowed" flag is set, then clear it?
<re_irc> <dirbaio> it's very underspecified though
<re_irc> <dirbaio> what does wait() do if the flag is already set when you call it, return immediately or wait for the next one?
<re_irc> <dirbaio> no idea
<re_irc> <dirbaio> I've never used it or impld it
<cr1901> Fair, and Idk either. Just frustrated that once again something I wanted to be done in 2 hours is going to take 10 or more
<cr1901> Ahhh, hmmm. The code is infinitely stuck in my int handler. Hmmm
emerent has quit [Ping timeout: 260 seconds]
emerent has joined #rust-embedded
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #rust-embedded
fabic has joined #rust-embedded
<re_irc> <Yashwanth SINGH M> robtsuk: It is in nightly version , i have taken the example code from the stm32f4xx-hal git, same cargo.toml so same version.
fabic has quit [Ping timeout: 246 seconds]
fabic has joined #rust-embedded
dreamcat4 has quit [Quit: Connection closed for inactivity]
<re_irc> <dcz> most no-std crates are synchronous. Is there a typical way to make them async? E.g. in embedded-graphics, the time sent sending buffer data might be used for something else
<re_irc> <jamwaffles> e-g doesn't handle the buffering side of things, so you might be able to use/create/modify the display driver to be async
<re_irc> <dcz> that only works if I use an intermediate buffer, doesn't it?
fabic has quit [Ping timeout: 248 seconds]
<re_irc> <ejpcmac> Hello, what is the current recommended naming for crates generated by svd2rust?
<re_irc> <burrbull> ejpcmac: usually it is chip name or chip name with "-pac" suffix
<re_irc> <jamwaffles> dcz: I’m not sure what you mean tbh but yes you’d probably have to do something like collect a number of items from an e-g iterator and send it with e.g. DMA. Whilst it’s transmitting you can continue reading the iterator
<re_irc> <ejpcmac> burrbull: Wasn't there a discussion about -ral as in Register Access Level?
<re_irc> <jamwaffles> dcz: you might want to jump over to ( (for async) or ( (for e-g related stuff) if you haven't already found them 🙂
<re_irc> <dcz> okay, I see. But if I want to return an error on a transmission error, I can't do that without proper async
<re_irc> <dcz> thanks. I'm just checking, probably going to use threads anyway
<re_irc> <burrbull> ejpcmac: "ral" is usually for crates generated with
<re_irc> <firefrommoonlight> dcz: Assuming you're using an SPI display or similar, DMA
<re_irc> <dcz> yes
<re_irc> <ejpcmac> burrbull: Oh, OK, it's clearer now :) Thank you!
<re_irc> <TimSmall> I see github will be mandating 2FA in future - - might be a good time to order a Rust-based hardware key: !
<re_irc> <Robert Jördens> TimSmall: 👍️ Will the Solokeys V2 be shipping before end of 2023? 😉
<re_irc> <TimSmall> I thought they'd already started shipping the V2, but are constrained by component supply (BICBW).
<re_irc> <Robert Jördens> Yeah, we are in the same boat. Just trolling a bit.
<re_irc> <yruama_lairba> i have big trouble here, i reoponed old project and there is no way to rprint with them
<re_irc> <yruama_lairba> ok, i don't know how to debug it, i have an incorretly retrieved value inside a register field
fabic has joined #rust-embedded
<re_irc> <holo> Hello, please can someone look at it what am i doing wrong?
<re_irc> <holo> what i checked right now additionally it is not working with 3,3 power too DHT22 (what i know should work on both 3,3 and 5v?)
fabic has quit [Ping timeout: 252 seconds]
nort has quit [Ping timeout: 250 seconds]
<re_irc> <ryan-summers> Have you tried using instead? It seems likely your bit-banged GPIO implementation may not be reliable
<re_irc> <ryan-summers> Also, have you hooked up the digital output to a scope to see if it's outputting anything?
fabic has joined #rust-embedded
starblue has quit [Ping timeout: 276 seconds]
starblue has joined #rust-embedded
<re_irc> <holo> ryan-summers: i checked my pin with diod and with switch and they its working corectly, same when i use multimeter and connected ping to gnd/vcc i could read pin status change
<re_irc> <ryan-summers> Then you are very likely not sampling the digital signal properly - I'd highly recommend using the dht-sensor crate to handle it for you, it looks like the sensor is quite timing sensitive
<re_irc> <holo> * LED and with switch and its working correctly,
<re_irc> <holo> is it posible to use this crate with risc-v/hifive1 rev b board?
<re_irc> <holo> i looked for some crate for this board but i found only arduino and some ARMs
<re_irc> <ryan-summers> The crate can be used with anything supporting the embedded-hal, which is the standard for embedded support
<re_irc> <ryan-summers> I'd be surprised if the hifive1 didn't have e-h support
<re_irc> <holo> im using this one:
<re_irc> <holo> sorry if those are stupid questions but im "weekend programer" and wanted to try something new
<re_irc> <holo> for now i only use C and atmega/arduino for simple prjects but there is lot of examples and tutorials and ready to use libs
<re_irc> <holo> sadly not for this bord (at least for now)
<re_irc> <ryan-summers> Take a look at, although the example is for an STM. You'll need to get a "Delay" and an "Input/Output" pin implementation from the hifive1 HAL:
<re_irc> <ryan-summers> Other than that, I unfortunately don't have time to help guide you through it - about to head off for the evening
<re_irc> <ryan-summers> The gist is that you just need a pin that can operate as an input and an output, and then you need to have some type of delay. Once you get those working, you just hand them to the library and it does the heavy lifting
<re_irc> <holo> hmm i think there are such things in that lib:
<re_irc> <ryan-summers> I'm certain they are - the embedded-hal traits are widely implemented
<re_irc> <ryan-summers> But also, take a double check at your circuit schematic and compare against the C/arduino tutorials
<re_irc> <ryan-summers> If you're not comfortable with electronics, it's easy to get something misconnect. Heck, it's easy to do even if you are comfortable
<re_irc> <ryan-summers> * misconnected.
<re_irc> <holo> im using bread board and checked it with few examples with resistor and without it there are only 3 wires so i think connections are ok
<re_irc> <ryan-summers> You'll definitely need the resistor - I believe the output is an open-drain config
<re_irc> <holo> oo in that library i can not find such thing
<re_irc> <ryan-summers> Anyways, I have to head out for the evening. Feel free to ping me tomorrow if you're still hitting snags and I can help if I have time
<re_irc> <holo> is that "floating" input same what open-drain?
<re_irc> <ryan-summers> Not exactly
<re_irc> <holo> ok so maybe im missing that open-drain but i can not find anything like this when configuring input/output
<re_irc> <ryan-summers> They're two different sides. Open-drain is the output type of the sensor, floating input is your MCU input pin configuration
<re_irc> <holo> thats all posibilites what i have
<re_irc> <holo> is there open-drain just missing and thats why it wont work with it?
<re_irc> <K900> Open drain is for outputs, not inputs
<re_irc> <K900> There is no such thing as an open drain input
<re_irc> <holo> if im not seeing "open-drain" on that tips is it possible it is not exist with that library?
<re_irc> <K900> It is not physically possible
<re_irc> <K900> It's not a library problem
<re_irc> <K900> An open drain input cannot possibly exist
<re_irc> <holo> but im asking about that output, right now there on that screenshot i have only outputs posible "into_output()" and "into_output_drive" and into_inverted_output()" and "into_inverted_outpu_drive"
<re_irc> <jannic> It may be that the HAL doesn't implement an open drain output.
<re_irc> <K900> It looks like your HAL does not implement open drain outputs etiher
<re_irc> <almindor> holo: that's a cool looking desktop, what's the setup? :D
<re_irc> <K900> Actually looking at the documentation, your chip just doesn't have the wiring for open drain operation
<re_irc> <holo> almindor: wayland/sway with base16 pdh colors themes
<re_irc> <holo> K900: so i can not use it with dht :/
<re_irc> <holo> so need to go back to arduino but will try anyway handle my task with rust, so probably will came back :)
<re_irc> <K900> You may be able to use it if you switch the modes fast enough, but that's not going to be fun
<re_irc> <K900> But honestly that protocol looks kind of insane and you might be better off with an I2C or SPI sensor
<re_irc> <holo> thank K900 i was looking for solution more than week but its just do not exists
<re_irc> <holo> but yes maybe changing sensor for some i2c/spi will be solution too
<re_irc> <holo> now i know where the problem is
<re_irc> <K900> If you specifically need to talk to that sensor from that SoC, you're going to need external hardware
<re_irc> <holo> K900: like i said im "weekend programer" so it probably will be out of my skills scope :)
<re_irc> <K900> Well it depends on how deep you're willing to dig
<re_irc> <K900> But it is up to you
<re_irc> <holo> K900: no its not necessary i just wanted to use this board to my new project - weather station, right now i know it wont be so fun with it like it should be to play with :)
<re_irc> <holo> i saw there are i2c dht22 sensors too so maybe i will try to look for them in meantime i will try embeded rust on arduino
<re_irc> <holo> thank your very much for helping
<re_irc> <holo> * you
<re_irc> <almindor> holo: cool, same setup but i didn't spruce it up on the looks yet. will check it out
<re_irc> <holo> almindor: on arch AUR there is base16-manger which will setup for you altracitty (console) and swaywm colors, but oss code and firefox you need to install base16 thems plugins
<re_irc> <holo> waybar you will need to setup manually each color
<re_irc> <jannic> K900: Are you sure? "The GPIO can be configured on a bitwise fashion to represent inputs and/or outputs, as set by
<re_irc> the input_en and output_en registers."
<re_irc> → The "and" between inputs and outputs suggests that it's allowed to enable both at the same time.
<re_irc> And the mode "output with weak pull-up" looks like the one needed to connect an dht22.
<re_irc> <K900> The schematic might be wrong then?
<re_irc> <K900> Huh
<re_irc> <K900> This one has a switch for the pullup
<re_irc> <K900> But I have no idea what they're trying to say with that
<re_irc> <holo> so it could be possible?
<re_irc> <K900> It will definitely require changes to the library
<re_irc> <K900> And I am still not sure how to interpret that schematic
<re_irc> <holo> so out of my scope :/ will try to create issue on github and will see what i will get from author
<re_irc> <holo> jannic: my board is rev b:
<re_irc> <jannic> holo: I think this trick could work here, as well:
<re_irc> <jannic> That's basically what K900 meant with "switch the modes fast enough", I guess.
<re_irc> <jannic> At a lower level, you could set input_en=1, output_val=0, pue=1 and then set output_en=1 to actively pull the line down, output_en=0 to pull it up using the weak pull-up resistor, and read input_val to read back the DHT response. But it seems like that mode is not implemented by the HAL. (Same situation as with the RP2040 and its HAL)
<re_irc> <holo> patching libs for first embedded rust (and basically one of first) projects is out of my scope ;)
<re_irc> <holo> think better will be to start with arduino and rust and create issue on github maybe author will add it
<re_irc> <holo> patching libs for first embedded (and basically one of first) rust projects is out of my scope ;)
<re_irc> <almindor> what do you use for the status bar?
<re_irc> <holo> almindor: waybar
fabic has quit [Ping timeout: 256 seconds]
gsalazar_ has quit [Ping timeout: 248 seconds]
nort has joined #rust-embedded
Rondom has quit [Remote host closed the connection]
<re_irc> <yruama_lairba> are trigonometric opertion defined with no_std ?
<re_irc> <yruama_lairba> i have "method not found" error message. i don't understand why because trigonomtric operation are supposed to be primitive
<re_irc> <James Munns> Nope, "libm" is not linked in by default
<re_irc> <James Munns> you'll need to add the "libm" crate, or something like "micromath" that provides them
<re_irc> <James Munns> "libm" implements everything, is very accurate, but is relatively slower, "micromath" is generally faster, but less accurate
<re_irc> <James Munns> (where "less accurate" is like "good to a couple of decimals", the docs discuss the specific limitations)
<re_irc> <James Munns> Or, you can be silly like me, and do your own fixed point versions:
<re_irc> <yruama_lairba> there is already some crate for fixed math
<re_irc> <James Munns> Yup,
<re_irc> <James Munns> it also doesn't provide trig functions tho
<re_irc> <yruama_lairba> thank for the link, it's exaxtly what i'm doing, embedded audio :)
<re_irc> <James Munns> (and the CORDIC algorithm was much slower than my implementation, YMMV)
<re_irc> <yruama_lairba> lol, already lost with "phase accumulator"
<re_irc> <James Munns> That's basically "where are you in the range between -PI and +PI"
<re_irc> <James Munns> or - "what percentage of the way through a single full sine wave are you"
<re_irc> <James Munns> since a signed number rolls over at the max range, it acts exactly like the "unit circle"
<re_irc> <James Munns> once you exceed PI, you "go back" to -PI
<re_irc> <yruama_lairba> so the input is a percentage of a full rotation ?
<re_irc> <James Munns> sort of
<re_irc> <James Munns> the "incr" is how far you move through the sine in each sample
<re_irc> <James Munns> so at 441hz, at 44100 samples/sec, you move through a whole sine wave every 100 samples
<re_irc> <James Munns> so each time you add "incr", you advance 1% of the way through the sine wave
<re_irc> <James Munns> this is basically your "phase offset" into the sine wave
<re_irc> <James Munns> and when you "accumulate" all of these "incr" additions together: you have a "phase accumulator"!
<re_irc> <yruama_lairba> i have found another way to generate sinewave. i don' t understand very well the algorythm, but it look close to a second order iir filter
<re_irc> <James Munns> Ah yeah, there are lots of ways to do it :)
<re_irc> <yruama_lairba> i don't know how it would behave with fixed point, on the orginal code there is a note about instability rick when using low precision calculation
<re_irc> <yruama_lairba> in fact, i just need a quick to implement processing to show i process the sample
<re_irc> <yruama_lairba> it's just for example pupose
<re_irc> <yruama_lairba> i'm trying to implment a decent i2s HAL for thestm32f4xx-hal crate
<re_irc> <firefrommoonlight> yruama_lairba: LMK if you run into issues. I have a bit of embedded Rust audio code as well, on a paused project
<re_irc> <firefrommoonlight> Uses a microphone array for DF and beamforming
<re_irc> <firefrommoonlight> Uses STM32, SAI periph, and a few AD PDM-to-PCM converters
<re_irc> <firefrommoonlight> And an I2S codec for output
<re_irc> <yruama_lairba> DF ?
<re_irc> <firefrommoonlight> Direction-finding
<re_irc> <firefrommoonlight> i'm using the CMSIS-DSP lib for FIR and IIR filters on the audio
<re_irc> <yruama_lairba> and beamforming ? what is it ?
<re_irc> <firefrommoonlight> Adding signals with different phases at different weights, to form an interference pattern
<re_irc> <firefrommoonlight> In this case, it lets you focus on sound from a specific direction, and attentuates sound from other directions. With some subtleties/caveats re freq response
<re_irc> <yruama_lairba> you did you own hal for I2s/SAI ?
<re_irc> <firefrommoonlight> Yes
<re_irc> <firefrommoonlight> Uses teh SAI periph (although with I2S _protocol_ support)
<re_irc> <firefrommoonlight> Does not support F4's I2S-over-SPI peripheral
<re_irc> <firefrommoonlight> Also have DFSDM set up, which is another way to receive audio from PDM mics, although you need to use software filtering at the last step for good quality audio
<re_irc> <yruama_lairba> i don't have PDM mics anyway
<re_irc> <yruama_lairba> everything pass trought th F4 I2S-over-SPI peripheral
<re_irc> <firefrommoonlight> Btw, the SAI peripheral is quite complicated! Since it supports so many diff protocol variants
<re_irc> <firefrommoonlight> Eg, here's teh config -
<re_irc> <firefrommoonlight> I had to add several presets for various modes like I2S, TDM etc, although even then it's likely you'd need to customize settings
<re_irc> <firefrommoonlight> In the use case I have, I'm linking together 4 blocks on 2 SAI periphs for input, and one for output. TDM input, I2S output
<re_irc> <firefrommoonlight> Circular, double-buffered DMA for both in and out
<re_irc> <yruama_lairba> lol, i did it more dirty on a POC project, circular single buffered DMA shared between in and out
<re_irc> <yruama_lairba> it appear to work, but the way i implmented it is clearly unsound
<re_irc> <firefrommoonlight> Interesting!