<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 #embassy-rs:matrix.org (https://matrix.to/#/#embassy-rs:matrix.org) (for async) or #rust-embedded-graphics:matrix.org (https://matrix.to/#/#rust-embedded-graphics:matrix.org) (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>
<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 https://crates.io/crates/dht-sensor 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>
<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>
<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> 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>
<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> 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>
<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