crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
cr1901_ has joined #rust-embedded
cr1901 has quit [Read error: Connection reset by peer]
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<lichtfeind> Hi is there a known way to get print debugging in no_std libs on an embedded target without SWD/JTAG? Like i crate with a static no_mangle ring buffer implementing Write or something where i can plug in a serial driver?
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
dc740 has joined #rust-embedded
<re_irc>
<lichtfeind> henrik_alser: ah yes that looks to exactly what i need thanks
explore has quit [Quit: Connection closed for inactivity]
dc740 has quit [Ping timeout: 268 seconds]
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #rust-embedded
genpaku has quit [Remote host closed the connection]
genpaku has joined #rust-embedded
Amadiro has joined #rust-embedded
gsalazar has quit [Remote host closed the connection]
gsalazar has joined #rust-embedded
Guest14 has joined #rust-embedded
Guest14 is now known as brazuca
brazuca has quit [Quit: Client closed]
brazuca has joined #rust-embedded
gsalazar has quit [Ping timeout: 252 seconds]
gsalazar has joined #rust-embedded
dc740 has joined #rust-embedded
<re_irc>
<chemicstry> how do you write a device driver (e.g. i2c temp sensor) so it would support both embedded-hal and embedded-hal-async? Implementing both results in a lot of code duplication, maybe there is some trick? I've seen people use proc macros such as https://lib.rs/crates/maybe-async-cfg but it has too much blackbox magic for my liking. Is it common to just implement async verrsion and let people use an i2c async adapter for...
<re_irc>
... blocking operation?
xnor_ is now known as xnor
<re_irc>
<mabez> chemicstry: My conclusion was either:
<re_irc>
2. async first, blocking just runs the futures in a hot loop
<re_irc>
1. maybe-async-cfg
<re_irc>
3. wait for keyword generics
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Write error: Connection reset by peer]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<mabez> FYI forced atomic option for armv6 & RISC-V non A targets is now merged in LLVM! š
<re_irc>
<adamgreig> anyhow, meeting time room ! agenda is https://hackmd.io/QVzFFhk5THmBrCMvLg8Zcw, please add anything you'd like to announce or discuss and we'll start in 5 mins
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<adamgreig> OK, let's start! no announcements from me I don't think
<re_irc>
<adamgreig> rust 1.63 out this thursday but I didn't notice anything particularly relevant to embedded in the release notes
<re_irc>
<adamgreig> still not quite got naked functions stable ;(
<re_irc>
<adamgreig> the PR to remove IoPin from e-h 1.0 is merged, so I think that just leaves the new i2c traits PR and the removing nb and CAN PR
<re_irc>
<adamgreig> does anyone have anything further to discuss on those two? we've already discussed them at the last couple of meetings, I don't know if any new concepts have emerged
brazuca has quit [Quit: Client closed]
<re_irc>
<therealprof> adamgreig: A number of copy functions are now const, maybe that helps with avoiding excessive generation of generic functions. I haven't checked the impact though.
<re_irc>
<dirbaio> re i2c: haven't had time to update some hals/drivers yet
<re_irc>
<eldruin> from a first review, it seemed fine to me
<re_irc>
<dirbaio> re the crate split: iirc the conclusion was to split can to a separate repo, right? if so I'll update the PR after the meeting
<re_irc>
<adamgreig> I can't remember if we decided on separate repo or just separate crate inside the same repo
<re_irc>
<adamgreig> and called embedded-can
<re_irc>
<eldruin> IIRC, we discussed reviving the original embedded-can crate
<re_irc>
<eldruin> the original author even commented here
<re_irc>
<dirbaio> yeah
<re_irc>
<dirbaio> so all it's misisng is updating the PR to not add the "embedded-hal-can" crate
<re_irc>
<adamgreig> we did, but we'd want to restart the crate with the traits from embedded-hal, and inside the working group org
<re_irc>
<adamgreig> (the e-h traits are updated compared to the last release of embedded-can)
<re_irc>
<eldruin> yeah exactly
<re_irc>
<adamgreig> I think the PR could just rename the embedded-hal-can directory to embedded-can
<re_irc>
<eldruin> we could take it over and just say that it will stay like that as a separate repo
<re_irc>
<adamgreig> but depends if you want it in the same repo or not, I'm not fussed
<re_irc>
<adamgreig> it's still an embedded hal trait, so maybe same repo makes sense? less CI etc to manage
<re_irc>
<eldruin> ah ok
<re_irc>
<eldruin> I guess, yeah
<re_irc>
<eldruin> we can do that
<re_irc>
<eldruin> just need the original author to add the e-h team to crates io so we can take it over
<re_irc>
<adamgreig> I can do that
<re_irc>
<Lachlan> Iām probably missing some context, but why not put can in embedded-hal?
<re_irc>
<adamgreig> the conclusion is that it's just complicated enough that the current design might not be final, and it's not as commonly used as spi/uart/i2c, so to give more room to refine the design and potentially do a breaking change without having to do embedded-hal 2.0, it can live in embedded-can
<re_irc>
<adamgreig> it's still "official" and a working group maintained crate
<re_irc>
<Lachlan> Ah, that makes sense
<re_irc>
<adamgreig> but without coupling the versions to the core traits
<re_irc>
<adamgreig> I have done that
<re_irc>
<David Cabanis> I don't know if you can help me? I have been banging my head for the last hour or so with a strange linker error. I can get it to link by doing the wrong thing but I can't get it to link by doing the right thing...
<re_irc>
<adamgreig> David Cabanis: this is the right place to ask, but the wrong time, we're in the middle of the weekly meeting, could you wait til it's done (at the end of this hour if not sooner)?
<re_irc>
<David Cabanis> oh yes for sure funnily I am looking at your github page at the moment..
<re_irc>
<adamgreig> so for splitting nb, we end up with "embedded-hal" just doing blocking, "embedded-hal-async" just doing async, and "embedded-hal-nb" doing the nb variants
<re_irc>
<adamgreig> is that our final answer š
<re_irc>
<eldruin> yes
<re_irc>
<eldruin> +(from me)
<re_irc>
<dirbaio> šļø
<re_irc>
<adamgreig> and... should embedded-can contain blocking and nb and async traits?
<re_irc>
<therealprof> SGTM
<re_irc>
<eldruin> adamgreig: yes, I would say so
<re_irc>
<adamgreig> cool
<re_irc>
<adamgreig> for embedded-can maybe the PR should set the next version to 0.4?
<re_irc>
<adamgreig> (currently 0.3 is on crates.io)
<re_irc>
<eldruin> yep, there were a couple of breaking changes IIRC
<re_irc>
<adamgreig> yea, and probably not ready for 1.0 yet
<re_irc>
<eldruin> probably, no idea though
<re_irc>
<adamgreig> what version for e-h-nb?
<re_irc>
<adamgreig> I feel like hopefully it can be 1.0 alongside e-h?
<re_irc>
<eldruin> maybe we should go over the issues in the original repo
<re_irc>
<dirbaio> 1.0 SGTM, if we don't plan breaking changes
<re_irc>
<eldruin> there is not much left in there anyway, right? (-nb)
<re_irc>
<dirbaio> nb SPI isn't updated for bus/device traits, not sure if it's worth doing it
<cr1901>
+1 from me (sorry distracted)
<re_irc>
<adamgreig> it seems like it would be nice to have it align with blocking?
<re_irc>
<eldruin> hmm, yeah, it would be weird to offer "just an nb flavor of e-h" but it has a completely different aPI
<re_irc>
<eldruin> * API
<re_irc>
<dirbaio> thing is SpiDevice::transaction has to block to acquire the lock
<re_irc>
<dirbaio> we could make an nb variant that returns nb "can't acquire lock yet"
<re_irc>
<dirbaio> but for example a "disable all irqs" impl will still be "kindof blocking" as in it blocks irqs
<re_irc>
<eldruin> hmm, maybe not ready for 1.0 after all, huh
<re_irc>
<dirbaio> doesn't matter if you're not blocking the main thread if you block irqs
<re_irc>
<eldruin> adding can't acquire lock variant would kind of break nb
<re_irc>
<eldruin> way too specific information for nb I would say
<re_irc>
<dirbaio> no, "can't acquire lock yet" would be the WouldBlock error
<re_irc>
<dirbaio> so you spin waiting to acquire the lock
<re_irc>
<eldruin> can you explain >we could make an nb variant that returns nb "can't acquire lock yet"
<re_irc>
<dirbaio> sorry, poor wording, meant "we could make a SpiDevice trait variant that uses nb"
<re_irc>
<eldruin> dirbaio: that sounds good. and you meant that we return WouldBlock if the lock could not be acquired, right?
<re_irc>
<dirbaio> yeah
<re_irc>
<dirbaio> but it has a few problems
<re_irc>
<dirbaio> 1. impls like "disable all irqs" would still be quite bad
<re_irc>
<dirbaio> 2. the closure-based transaction API doesn't work, because you can't "yield" out of the closure without returning from it, which would release the transaction
<re_irc>
<eldruin> hmm, if a 1:1 translation is not possible, maybe we can still figure out a somewhat similar API
<re_irc>
<dirbaio> yeah, but IMO investing effort in it is not worth it
<re_irc>
<eldruin> but we can publish a < 1.0 version first and take it from there
<re_irc>
<dirbaio> how many drivers use nb SPI?
<re_irc>
<dirbaio> and out of these, how many use it "really nonblocking" (ie without "nb::block!")?
<re_irc>
<therealprof> If anyone, then eldruin should be able to tell. I haven't seen any.
<re_irc>
<eldruin> I have never used an nb spi in a driver
<re_irc>
<eldruin> not sure about some devices with high performance / lots of data
<re_irc>
<dirbaio> and out of these, how many want bus sharing? :P
<re_irc>
<dirbaio> anyway this is not blocking for EH1.0
<re_irc>
<adamgreig> that's basically the same argument for "should we even have e-h-nb" I guess, which I think we concluded "yes, it's still worth having"
<re_irc>
<dirbaio> I propose: split "-nb" to a separate crate, create a separate tracking issue for e-h-nb 1.0, carry on with e-h 1.0 in the meantime
<re_irc>
<adamgreig> yea, e-h-nb doesn't need to release 1.0 the same day as e-h 1.0, just hopefully it does get released one day :P
<re_irc>
<skylardive1> Hello. Any recommendations on how to convert a string to a number similar to "atoi()" in a no_std env?
<re_irc>
<K900> Handroll it
<re_irc>
<skylardive1> ...
<re_irc>
<adamgreig> you can use from_str on u32, u8, etc types
<re_irc>
<adamgreig> how widely used is 0.2? if the hacks are at all annoying I'd be tempted to just make a clean break and push for 1.0 adoption asap
<re_irc>
<adamgreig> I see you've already answered on the thread
<re_irc>
<adamgreig> I think release 0.2.8 with links key set, have links key in 1.0, if anyone adds a new dependency that brings in cs 1.0 hopefully they also update the old cs to 0.2.8 to get the error?
<re_irc>
<adamgreig> at least the links key works going forward and doesn't impact the 1.0 release at all
<re_irc>
<dirbaio> problem with links key is it's fine to mix 0.2 and 1.0 (as long as you have impls for both and they're compatible)
<re_irc>
<dirbaio> so if a HAL wants to choose supporting both, it can
<re_irc>
<dirbaio> with the links key you sabotage that
<re_irc>
<adamgreig> but do we want to encourage/support HALs supporting both?
<re_irc>
<adamgreig> and is a links key helpful for future releases...
<re_irc>
<adamgreig> could you have a 0.2.8 that disabled the auto-provided impls?
<re_irc>
<dirbaio> adamgreig: that'd be breaking..
<re_irc>
<dirbaio> jannic (who's proposing compat in that thread) is an rp-hal maintainer, so at least there's some desire for compat in HAL authors
<re_irc>
<dirbaio> rp-hal is the only affected HAL really, because multicore
<re_irc>
<adamgreig> so your feeling is basically do nothing, leave c-s 0.2.7 alive and allowed, publish 1.0, hope no one uses both with incompatible impls?
<re_irc>
<skylardive1> adamgreig: Yeah, I found that method too. I just need to go about removing a \n.
<re_irc>
<dirbaio> yeah
<re_irc>
<dirbaio> it's not ideal but at least it doesn't force carrying legacy in 1.0 forever
<re_irc>
<dirbaio> the alternatives aren't better imo
<re_irc>
<adamgreig> do you think 1.0 should have a "links" key set anyway (even without adding it to a 0.2.8)? or do the symbol names serve that purpose?
<re_irc>
<dirbaio> hmm preemptively adding one just in case wouldn't hurt
<re_irc>
<dirbaio> * "links"
<re_irc>
<dirbaio> if only 1.0 has it, it's as if it wasn't htere
<re_irc>
<adamgreig> I guess you can always delete it from 2.0 if you realised it was bad
<re_irc>
<adamgreig> let's chat about the other points briefly
<re_irc>
<adamgreig> for "which team", it's not clear to me, on bare-metal we said "well just all the arch teams" and it's quite inconvenient
<re_irc>
<adamgreig> if we had basically a "traits team" they could have embedded-mutex, critical-section, bare-metal, ...... but that's sort of "the hal team"
<re_irc>
<dirbaio> perhaps the closest precedent is bare-metal
<re_irc>
<dirbaio> which is "developed and maintained by the Cortex-A, Cortex-M, Cortex-R, MSP430, and RISCV teams." š
<re_irc>
<dirbaio> so, everyone š
<re_irc>
<adamgreig> yea, as I said it's not been very convenient
<re_irc>
<adamgreig> doesn't c-s use the bare-metal CriticalSection type?
<re_irc>
<adamgreig> ah, not any more I see
<re_irc>
<dirbaio> that was the next point, i've copied CriticalSection and Mutex into c-s
<re_irc>
<dirbaio> i think it's the best, but it's not a definitive decision
<re_irc>
<adamgreig> i.e. the entirety of bare-metal lol
<re_irc>
<adamgreig> if we did that I'd be inclined to release bare-metal 1.1 (or 1.0.1?) that re-exports c-s's CriticalSection and Mutex, if they're written the same
<re_irc>
- copy CriticalSection, Mutex into c-s, deprecate bare-metal
<re_irc>
<dirbaio> options we have
<re_irc>
- reexport bare-metal CriticalSection, Mutex from c-s
<re_irc>
- copy CriticalSection, Mutex into c-s, publish a new bare-metal version reexporting them from c-s
<re_irc>
<adamgreig> (and then deprecate it, sure)
<re_irc>
<dirbaio> I think 2nd is best
<re_irc>
<adamgreig> why not 2+1?
<re_irc>
<adamgreig> no point anyone using bare-metal any more after that, right?
<re_irc>
<dirbaio> ah yeah, SGTM
<re_irc>
<adamgreig> just a more complicated way to use c-s
<re_irc>
<adamgreig> at least by publishing the new b-m people depending on it may hopefully find it easier to be compatible with things already using the CS type
<re_irc>
<adamgreig> probably say "critical-section is the successor to the bare-metal crate" in the readme or something too
<re_irc>
<dirbaio> so
<re_irc>
<therealprof> šļø
<re_irc>
<dirbaio> - c-s is maintained by the HAL team?
<re_irc>
<adamgreig> I'm still not 100% on HAL team, what do you think eldruin and therealprof?
<re_irc>
<adamgreig> it might be the closest fit but it's quite a different responsibility to the embedded-hal crate
<re_irc>
<therealprof> Okay for me.
<re_irc>
<dirbaio> IMO it's "sort of" a trait
<re_irc>
<adamgreig> it's spiritually a trait for sure
<re_irc>
<therealprof> C-S is pretty much a HAL thing. š
<re_irc>
<eldruin> fine for me
<re_irc>
<dirbaio> cool! ā
<re_irc>
<adamgreig> OK, let's go with HAL team then
<re_irc>
<dirbaio> and re bare-metal:
<re_irc>
- copy CriticalSection, Mutex into c-s
<re_irc>
- publish a new bare-metal version reexporting them from c-s, update docs to direct users to use c-s directly
<re_irc>
any objections? :D
<re_irc>
<adamgreig> fine with me
<re_irc>
<dirbaio> cool
<re_irc>
<dirbaio> so I'll do the readme etc updates to transfer the repo to the WG
<re_irc>
<adamgreig> you should be able to do the transfer yourself too I believe, but remember to add the team to the crate owners on crates.io
<re_irc>
<Lumpio> "if let Some(x) = my_arr.iter_mut().find(|x| *x == 55) { *x = 0; }" or something
<re_irc>
<wucke13> Lumpio: removeing from an array -> impossible, the size of the array won't change -> use the right abstraction for the right job -> tinyvec?
<re_irc>
<Lumpio> N.b. if you want to iterate through an array with indexes the nicer way is: "for (i, x) in my_arr.iter().enumerate()"
<re_irc>
<skylardive1> are these methods heavy?
<re_irc>
<Lumpio> wucke13: Well I said move the rest up :) Assuming that the "tail" is where the zeros are. Could also have a separate length variable.
<re_irc>
<wucke13> skylardive1: is the array heavy?
<re_irc>
<Lumpio> skylardive1: With optimizations, simple iterator code tends to compile to exactly the same thing as a manul loop if not better.
<re_irc>
<Lumpio> * manual
<re_irc>
<wucke13> Still this would be a linear search, which if all elements are zero, could potentially take O(n) where n is the length of the array.
<re_irc>
<Lumpio> I think that's already undestood.
<re_irc>
<Lumpio> * understood.
<re_irc>
<wucke13> One could optimize this drastically by using binary search assuming that the offending tail symbol (0 in this case) never occurs before the tailsection.
<re_irc>
<Lumpio> ...and assuming that the rest of the values are sorted
<re_irc>
<Lumpio> +always
<re_irc>
<skylardive1> It's just that this didn't work...
<re_irc>
<K900> Well, for one, Rust doesn't have "++" synta
<re_irc>
<K900> * syntax
<re_irc>
<wucke13> Lumpio: Not relevant for finding the one section of zeros at the end, when there are no zeros anywhere else?
<re_irc>
<skylardive1> Yeah, I changed it up for a +=
<re_irc>
<skylardive1> Still did not work...
<re_irc>
<Lumpio> And second you run into aliasing references problems. You have both a reference &x to the array and you're trying to mutate it. If you want to loop using indexes, use "enumerate", or get rid of the "for" loop altogether and use an index with "while".
<re_irc>
<K900> You need to be more specific
<re_irc>
<K900> At least include the compile error
<re_irc>
<skylardive1> There isn't a error. The index just wasn't modified.
<re_irc>
<Lumpio> wucke13: Is that still not O(n) in computer science terms if you intend to do a linear search afterward anyways?
<re_irc>
<K900> You can also just use "iter_mut":
<re_irc>
let mut my_arr = [1,2,3,4,5,6,55,0,0,0,0,0,0];
<re_irc>
<Lumpio> skylardive1: Ooh you are right. I think this might be due to "IntoIterator" on arrays š¤
<re_irc>
<Lumpio> It just makes a copy and iterater over that. With a slice instead of an array you'd run into the reference problem.
<re_irc>
<wucke13> Lumpio: No, I'd argue it is possible to do in O(log(n)).
<re_irc>
We just guess that the start of the tail section (where everything is 0) is in the middle. If we find a zero in the middle, we assume its exactly at the border between the first and the second quart. If you continue this strategy, you can find the beginning of the zeros section in log_2(n) where n is the length of the arrray. If you know the position of the first 0 of the 0 tail, then you also implicitly know the position of the...
<re_irc>
... last symbol before the zeros
<re_irc>
<wucke13> No, I'd argue it is possible to do in O(log(n)).
<re_irc>
(Though of course this then does not contain linear search, but binary search)
<re_irc>
We just guess that the start of the tail section (where everything is 0) is in the middle. If we find a zero in the middle, we assume its exactly at the border between the first and the second quart. If you continue this strategy, you can find the beginning of the zeros section in log_2(n) where n is the length of the arrray. If you know the position of the first 0 of the 0 tail, then you also implicitly know the position of the...
<re_irc>
... last symbol before the zeros
<re_irc>
<Lumpio> wucke13: Yes, finding the end of the zeros should be the same as a binary search. But after that, unless the values are sorted, the non-zero values will still have to be linearly searched.
<re_irc>
<Lumpio> * non-zero values are sorted, the non-zero values will still have to be linearly searched for the 55.
<re_irc>
<Lumpio> * start
<re_irc>
<skylardive1> K900: Nice, it works perfectly. Thanks K900.
<re_irc>
<Lumpio> My math isn't good enough to combine the O numbers of a binary search followed by a partial linear search.
<re_irc>
You assume, that we still have to _find_ 55, or whatever may be the value we want to eliminate.
<re_irc>
<wucke13> Lumpio: Ah I see our mistake know.
<re_irc>
I just assumed that whichever value is the last value before the zeros is the one we want to truncate. So, you are right of course
<re_irc>
<Lumpio> Ah
<re_irc>
<Lumpio> I was wondering why your code got "the last value" out of the array
<re_irc>
<wucke13> Lumpio: It's just the linear term, IMHO -- because the linear term dominates the logarithmic term.
<re_irc>
<Lumpio> This was my assumption yes
<re_irc>
<wucke13> Lumpio: A clear example of _If the requirements ain't tight, ..._ š
<re_irc>
<GrantM11235> skylardive1: Do you need the stuff after the 55, or just the elements before it?
<re_irc>
<skylardive1> I liked the solution K900 provided more. It feels simpler and more "C"-like
<re_irc>
<K900> C-like is not really what you should aim for in Rust
<re_irc>
<skylardive1> Well, I am still learning here and there.
<re_irc>
<K900> So you shouldn't be learning antipatterns
<re_irc>
<skylardive1> What should I do then? Where can I find good Rust code?
<re_irc>
<K900> Not in no_std environments with random libc bits pulled in, that's for sure
<re_irc>
<skylardive1> :(
<re_irc>
<David Cabanis> Hi chaps, I hope you can help me, I am scratching my head about a strange linking problem. I am building with this config file: [target = "thumbv7em-none-eabi"
<re_irc>
<GrantM11235> Native rust strings and arrays are different than in C. In rust a string/array is a pointer and a length, whereas in C it is just a pointer to null-terminated data. When using rust, you should just use native strings/arrays and don't try to null-terminate them
<re_irc>
<David Cabanis> Hi chaps, I hope you can help me, I am scratching my head about a strange linking problem. I am building with this config file: *[target = "thumbv7em-none-eabi"] rustflags = [ "-C", "Link-arg=Tlink.x", ]* when I run cargo build with this target I get an error: *rust-lld: error: ERROR(cortex-m-rt): The interrupt vectors are missing.* but when I do not use the rustflags it builds fine. Does this mean anything to one...
<re_irc>
... of you?
<re_irc>
<GrantM11235> David Cabanis: You probably need to enable the "rt" feature in whatever HAL you are using
<re_irc>
<David Cabanis> I thought it was enabled by default
<re_irc>
<GrantM11235> What HAL are you using?
<re_irc>
<David Cabanis> microbit-v2, cortex-m-rt
<re_irc>
<skylardive1> How should I substitute for NULL in Rust LIBC?
<re_irc>
<K900> std::ptr::null()
<re_irc>
<David Cabanis> The strange thing is that it builds fine without the "-C" , "link-arg=Tlink.x" as a rust flag
<re_irc>
<K900> But also please don't?
<re_irc>
<James Munns> core::PTR::null_mut()
<re_irc>
<James Munns> * core::ptr::null_mut()
<re_irc>
<James Munns> David Cabanis: That's because the sanity checks are included in link.x
<re_irc>
<James Munns> So it's sort of a "the tests pass if I don't include the tests" sort of situation :)
<re_irc>
<David Cabanis> ah so not good news then
<re_irc>
<James Munns> Unfortunately no :/
<re_irc>
<skylardive1> James Munns: It doesn't work in libc, instead i have to put 0 as *mut libc::c_void
<re_irc>
<James Munns> Glad you got it figured out.
<re_irc>
<skylardive1> Any idea why though?
<re_irc>
<skylardive1> Nevermind, it works as long as i cast to *mut c_void
<re_irc>
<skylardive1> This however is a little problematic: "u32::from_str(&str::from_utf8(&data).unwrap())"
<re_irc>
<David Cabanis> I though cortex-m-rt included the essential fault handler definitions and yet rustldd is indicating that the vectors are missing
<re_irc>
<David Cabanis> I thought there must have been a better way..
<re_irc>
<GrantM11235> Yeah, it is easier than trying to fight with the markdown formatting
<re_irc>
<David Cabanis> The toolchain works fine for the discovery microbit-v2 labs, I should have all that is needed to build a bare-bone project I would have thought
<re_irc>
<GrantM11235> Did you copy the build script?
<re_irc>
<David Cabanis> interestingly I have just recreated the original project using the NRF51 and I get the exact same linking error: *rust-lld: error:
<re_irc>
ERROR(cortex-m-rt): The interrupt vectors are missing.*
<re_irc>
<adamgreig> I think you need to include a PAC/HAL, like microbit-v2
<re_irc>
<adamgreig> your main.rs is not actually using it, so it's not included in the build and you don't get any vectors
<re_irc>
<adamgreig> it probably suffices to just "use microbit_v2 as _" at the top of main.rs
<re_irc>
<David Cabanis> okay let me try
causal has joined #rust-embedded
<re_irc>
<skylardive1> Does anyone know of a lighter method of doing "trim_end_matches("\00")"?
<re_irc>
<skylardive1> Rather, is it possible to remove elements from a fixed size array?
<re_irc>
<skylardive1> Nevermind, It seems that It's in fact core::u32 and core::str adding the size.
cr1901 has quit [Ping timeout: 244 seconds]
bjc`` has quit [Ping timeout: 252 seconds]
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<David Cabanis> adamgreig: Your solution seems to have done the trick, thank you Adam
cr1901 has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
cr1901 has quit [Ping timeout: 252 seconds]
cr1901 has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
explore has quit [Quit: Connection closed for inactivity]
loki_val has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 268 seconds]
cr1901 has quit [Read error: Connection reset by peer]