<re_irc>
<dkhayes117> I'm working with the nrf9160-hal and I'm trying to get a timer but it is looking for a marker on the "TIMER0_NS" Struct. Not sure what it wants.
<re_irc>
25 | let timer = Timer::new(TIMER0_NS);
<re_irc>
| ^^^^^^^^^ help: use struct literal syntax instead: `TIMER0_NS { _marker: val }`
starblue has quit [Ping timeout: 240 seconds]
starblue has joined #rust-embedded
<re_irc>
<dkhayes117> Never mind, stupid mistake. I was trying to pull in "TIMER0_NS" directly from the pac instead of through my peripherals after "Peripherals::take().unwrap()"
fabic_ has joined #rust-embedded
<re_irc>
<firefrommoonlight> The nRF HAL doesn't really have a timer API
<re_irc>
<firefrommoonlight> *unless it changed
<re_irc>
<firefrommoonlight> I created one from a fork
<re_irc>
<firefrommoonlight> It basically uses teh PAC directly
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
bjc has left #rust-embedded [ERC 5.4 (IRC client for GNU Emacs 28.1)]
kuzuy has joined #rust-embedded
fabic_ has quit [Ping timeout: 256 seconds]
GenTooMan has quit [Ping timeout: 244 seconds]
GenTooMan has joined #rust-embedded
<re_irc>
<vulpine_smelts> Hi sorry, super simple question which I can't seem to find the answer to... how can I convert an f32 value to a heapless string?
<re_irc>
When I tried String::<10>::from(float_value), I got the trait bound "String<10_usize>: From<f32>" is not satisfied
<re_irc>
<burrbull> write!
<re_irc>
<vulpine_smelts> Ok! something like... this? let mut val_buff: heapless::String<10> = heapless::String::new(); write!(&mut val_buff, "{:08.3}\0", ambient).expect("f32 to str");
<re_irc>
<vulpine_smelts> Thanks, that works :)
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
fabic_ has joined #rust-embedded
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded
bjoto has joined #rust-embedded
GenTooMan has quit [Remote host closed the connection]
GenTooMan has joined #rust-embedded
berkowski has quit [Remote host closed the connection]
causal has quit [Quit: WeeChat 3.5]
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
GenTooMan has quit [Ping timeout: 244 seconds]
GenTooMan has joined #rust-embedded
kuzuy has quit [Quit: WeeChat 3.0]
<re_irc>
<silvergasp> I'm working on fuzzed implementations for the 1.0.0 alpha release on embedded-hal. As there are many breaking changes between '0.2.x' and '1.0.0' I'm going to assume that there will be some lag between when '1.0.0' is released and when most HAL crates implement the new interface. If I'm realistic, I would like to keep my fuzzed-hal tracking '0.2.x' as that interface matches the 'real' hal crates I'm using. But I'd...
<re_irc>
... also like to maintain a '1.0.0' version of the fuzzed implementation so that I'm ready to transition over to the new interface. I'm somewhat of a newb when it comes to packaging/versioning and could do with some guidance. Are there any maintainers of HAL/drivers that have a concrete migration plan? Preferably some kind of step-by-step guide as to how to manage an incremental migration between drivers/hals/apps. Or is the...
<re_irc>
... migration intended to be more of an ecosystem-wide step change?
<re_irc>
<dirbaio> "embedded-hal-compat" has adapters for 0.2 <-> 1.0
<re_irc>
<silvergasp> oh brilliant, I'll take a look
<re_irc>
<dirbaio> it's on alpha7 though, needs update for alpha8
<re_irc>
<dirbaio> but with that you can in theory write the fuzzer once (probably for 1.0) and then use it to fuzz 0.2 drivers with the adapter
<re_irc>
<dirbaio> there could be edge cases you can only reach with a native 0.2 fuzzer, maybe around errors though, dunno
<re_irc>
<silvergasp> I guess I'll find out. In any case, the compat crate should save me some time
<re_irc>
<Mehmet Ali> Hi all, are there any crates that would aid me in making me manage my FLASH?
<re_irc>
<Mehmet Ali> I mean, I am talking to others about this, and we are about to create a system that we consecutively write measurement data to flash.
<re_irc>
<silvergasp> maybe tickv or littlefs2 crates
<re_irc>
<silvergasp> both are pretty minimal filesystems tickv is native rust. littlefs is written in c but has rust bindings. Both support wear levelling.
<re_irc>
<Mehmet Ali> warm to tickv
<re_irc>
<Mehmet Ali> I have a NOR flash therefore not much to level
<re_irc>
<Mehmet Ali> but still.
<re_irc>
<Mehmet Ali> does tick require tickos?
<re_irc>
<Mehmet Ali> We were just about to come up with something homebrew, like, an idea popped up to manage which flash pages are available and which are not, and then an allocator idea and I though whether we are going diwnhill
<re_irc>
<Mehmet Ali> * downhill
<re_irc>
<dirbaio> you definitely need wear leveling in NOR flash...
<re_irc>
<Mehmet Ali> dirbaio: Oh, I was relaxed about the fact that it can withstand 100000 cycles
<re_irc>
<silvergasp> Mehmet Ali: I don't think so, it's been a while since I used it so it might have changed
<re_irc>
<Mehmet Ali> Was wondering today that there must be a simpler way
<re_irc>
<James Munns> Mehmet Ali: Depends on how much you are writing in each message, how often you do it, and how much total space you are using
<re_irc>
<dirbaio> that means each page can be erased 100k times, if you always erase the same one you'll reach end-of-life much much faster (one page worn down, rest are fresh) than if you spread the wear (all pages worn down)
<re_irc>
<Mehmet Ali> Oh yes, my assumption was a circular write
<re_irc>
<James Munns> For example, if you write 1K of data every minute, and the flash has 100K erase cycles, and you want to run for 10 years:
<re_irc>
>>> 100000 / (60 * 24 * 365)
<re_irc>
0.1902587519025875
<re_irc>
52.56
<re_irc>
>>> 10 / _
<re_irc>
<James Munns> You'd need 53x 1K pages to make it possible
<re_irc>
<James Munns> If you do it every second, and want it to last a year, you need 316 1K pages
<re_irc>
<Mehmet Ali> dirbaio: Ah yes, sorry. Forgot to mention that we are writing in a circular fashion
<re_irc>
<silvergasp> Mehmet Ali: As long as you are consistently writing data in 'page sized' increments as a circular buffer you are effectively wear levelling anyway. It's only when you need to store data in chunks more/less than the page size that some kind of wear-levelling system is necessary.
<re_irc>
<James Munns> I know you're looking for something off the shelf, but I've written a really simple flash logging backend that just sticks a sequence number in each log page
<re_irc>
<James Munns> at boot, it looks for the first invalid block in the range, or where it goes from a higher seq number to a lower seq num, and resumes writing there.
<re_irc>
<James Munns> (sorry, I should say, "for a previous client in another language I wrote that", but it should be easy to write in Rust as well)
dc740 has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
dc740 has joined #rust-embedded
<re_irc>
<firefrommoonlight> Mehmet Ali: Low level stuff, or reading/writing data from firmware?
<re_irc>
<firefrommoonlight> *seems like the latter
<re_irc>
<Mehmet Ali> not a driver.
<re_irc>
<firefrommoonlight> I feel like something clever to cycle pages based on wear would be nice
<re_irc>
<Mehmet Ali> but something that might be useful to remember what data is written to where
<re_irc>
<Mehmet Ali> and on deletion of that data
<re_irc>
<Mehmet Ali> That would be the basis, yes.
<re_irc>
<firefrommoonlight> I've been using a fixed page for config/state data, but this has wear considerations
<re_irc>
<firefrommoonlight> I haven't heard of anything that does this, but GL! I'm interested
<re_irc>
<Mehmet Ali> Thanks!
<re_irc>
<Mehmet Ali> James Munns: Thanks, James, I missed this.
<re_irc>
<firefrommoonlight> Also, I've been picking pages near the end since I'm never sure where my program memory ends, and obviously it can increase over time
<re_irc>
<Mehmet Ali> IT might be useful, maybe it will be inspiring if you can open the code.
<re_irc>
<firefrommoonlight> Something that handles that would be cool. I don't need control over what page is used other than it's not used by my program itseld
<re_irc>
<Mehmet Ali> firefrommoonlight: So what I have is large amounts of measurement data, each a dozen page
<re_irc>
<firefrommoonlight> Btw, you could use offboard too
<re_irc>
<Mehmet Ali> Another kind of data which is 3 pages
<re_irc>
<firefrommoonlight> Qspi flash is cheap/available, and fast
<re_irc>
<Mehmet Ali> and metadata, which is small and might link to either kinds of data or not
<re_irc>
<thejpster> James Munns: I too have written this … probably three times over at this point. Because there’s what happens in a language with no package manager.
dc740 has quit [Remote host closed the connection]