<re_irc>
I am working on Tiva C series "tm4c123gxl" board, I am writting flash driver for this board, Here i wnat to make erase/write "sector-by-sector". So how do i create sector in it?
<re_irc>
<Udayakumar Hidakal> Hello
<re_irc>
I am working on Tiva C series "tm4c123gxl" board, I am writing flash driver for this board, Here i want to make erase/write "sector-by-sector". So how do i create sector in it?
starblue has quit [Ping timeout: 272 seconds]
starblue has joined #rust-embedded
xnor has quit [Remote host closed the connection]
xnor has joined #rust-embedded
emerent has quit [Ping timeout: 260 seconds]
emerent has joined #rust-embedded
explore has joined #rust-embedded
emerent has quit [Remote host closed the connection]
emerent has joined #rust-embedded
<re_irc>
<timbod7> I'm working on a device using stm32f4xx-hal and rtic. I've got several peripherals requiring short delays (via the Delay trait). Is there a way to create multiple Delay values based upon a single underlying hardware timer?
<re_irc>
<burrbull> I know only 1 way to share Delay between devices. Take mutable reference on each access instead of owning of it
<re_irc>
<timbod7> Yes, though that's only an option if the driver writer has implemented the API that way.
lowq has quit [Ping timeout: 272 seconds]
explore has quit [Quit: Connection closed for inactivity]
<re_irc>
<gauteh> I see that clocks.freeze() is present in some hals, otherwise setup of i2c and whatnot will also be flawed. Re-configuring the clocks is not really possible at HAL level, why can't Delay be cloneable then?
<re_irc>
<firefrommoonlight> timbod7: The best approach depends on use case. Ie, are multiple ones running concurrently?
<re_irc>
<firefrommoonlight> I had to repurpose a timer for 2 things on a nRF chip since I ran out of timers. Worked, but made the code more complicated
<re_irc>
<firefrommoonlight> In some cases, if they're all running continuously, you can use different channels that have different timeout values
<re_irc>
<firefrommoonlight> depends on hardware and use case
<re_irc>
<firefrommoonlight> In some cases, if they're all running continuously, you can use different channels that have different timeout values, but start/stop together
<re_irc>
<firefrommoonlight> gauteh: Re-configuring clocks is possible at the HAL level
<re_irc>
<firefrommoonlight> That's a limitation of those APIs that treat clock state as unchangeable
<re_irc>
<marmrt> timbod7: Maybe rtic Monotonics would work? splitting thee peripherals between tasks and using spawn_after(xx.micros()) for the delays
<re_irc>
<marmrt> If Delay trait is really needed that won't work though
<re_irc>
<ryan-summers> Eh, that looks to be for "embedded-time" support, sorry
<re_irc>
<ryan-summers> But the concept still holds pretty well
m5zs7k has quit [Read error: Connection reset by peer]
m5zs7k_ has joined #rust-embedded
m5zs7k_ is now known as m5zs7k
<re_irc>
<gauteh> firefrommoonlight: Yeah, I know. But that means that since the clocks don't change you can make other assumptions. That is the main reason that it is frozen.
<re_irc>
<gauteh> The problem is still that all drivers etc need to support non-clonable Delay or it will be severely limited.
<re_irc>
<firefrommoonlight> What have y'all been using systick delay for? My main use case is in initialization of some periphs and ICs, run once per power-on
<re_irc>
<firefrommoonlight> In general, I have a lot of confusion of what use cases and project requirements these APIs were built for
lowq has joined #rust-embedded
<re_irc>
<mutantbob> Ugh. I've been digging into arduino progmem. The "#[cfg_attr(target_arch = "avr", link_section = ".progmem.data")]" directive does not seem to work with strings.
<re_irc>
<Kiran Shila> Has anyone had to deal with wonky I2C stuff before? I'm writing a driver crate for this power sensor and I don't think I can recreate their protocol with the standard embedded hal read/write