starblue3 has quit [Ping timeout: 250 seconds]
starblue3 has joined #rust-embedded
fabic has quit [Ping timeout: 252 seconds]
edm has quit [Ping timeout: 248 seconds]
dreamcat4 has quit [Ping timeout: 250 seconds]
edm has joined #rust-embedded
dreamcat4 has joined #rust-embedded
<re_irc> <> OK. Got the H7 Nucleo to play tones on my headphones by setting a timer that toggles the DAC output between a fixed value and 0. Next up: Sin waves, which from a google search, I think are done via LUTs for performance reasons
<re_irc> <> Probably using a timer to identify how far you are in a given cycle
edm has quit [Ping timeout: 250 seconds]
darknighte has quit [Read error: Connection reset by peer]
SanchayanMaity has quit [Read error: Connection reset by peer]
dreamcat4 has quit [Ping timeout: 250 seconds]
SanchayanMaity has joined #rust-embedded
darknighte has joined #rust-embedded
edm has joined #rust-embedded
dreamcat4 has joined #rust-embedded
fabic has joined #rust-embedded
_whitelogger has joined #rust-embedded
nohit has joined #rust-embedded
richardeoin has quit [*.net *.split]
jasperw has quit [*.net *.split]
jasperw has joined #rust-embedded
richardeoin has joined #rust-embedded
emerent has quit [Ping timeout: 250 seconds]
emerent_ has joined #rust-embedded
emerent_ is now known as emerent
ni has quit [Quit: WeeChat 2.8]
ni has joined #rust-embedded
GenTooMan has quit [Ping timeout: 250 seconds]
ni has quit [Client Quit]
ni has joined #rust-embedded
<re_irc> <> What is the easiest way to move the stack pointer back to a valid location in a Hardfault handler, when using flip-link and encountering a stack-overflow, in order to do a panic/log before rebooting? And is it possible without nightly?
<re_irc> <> the easiest way is to write to `msp` directly but am assuming the problem is figuring out a valid location with flip-link turned-on
<re_irc> <> as with flip-link turned-on the stack's upper bound is random
<Lumpio-> Is it not available as a linker symbol?
<re_irc> <> Couldn't i just put it anywhere within my valid stack, if my only goal is to do a log + system reset, and i no longer care about any other contents of the stack?
<Lumpio-> If you never plan to return again, you could probably do that.
<re_irc> <> That would be the plan
<Darius> doing that means you would probably destroy your stack trace
<re_irc> <> i am using panic_persist, so the plan would be to just move the stack pointer to a valid location, and call an explicit panic
<Darius> you could reserve some memory for an emergency stack
<re_irc> <> Hi, something I've been working on (at work) -
<re_irc> <> We're finally ready to go public with `rustBoot`. I think we have the design hashed-out but its still early days and there's a lengthy roadmap ahead. I'd love to hear your thoughts. Feel free to chime-in on the repo if you're interested in security.
dcz has joined #rust-embedded
GenTooMan has joined #rust-embedded
fabic has quit [Ping timeout: 252 seconds]
<re_irc> <> Congrats! One question though: "GPL2 or MIT" seems like a pretty big spread, license wise. Is it possible to use rustBoot without the GPL2 components?
<re_irc> <> (usually when I see "OR" in the license text, the user is free to choose either, but if core parts of the bootloader are GPL2, then I don't think it's possible for the user to choose MIT without violating the terms of GPL2)
emerent has quit [Read error: Connection reset by peer]
emerent has joined #rust-embedded
<re_irc> <> afaik, we can, I managed to contain (pretty much) all of the derived work that rustBoot depends on in the `rustBoot_update` crate. So, barring that crate everything else shouldn't have conflicts if the user chooses to go either way.
<re_irc> <> but I'm no expert on licensing, is it better to avoid the dual-license option and pick one in this case (i.e. just go with GNU GPL v2.0)?
<re_irc> <> one more point - as MIT doesn't require modifications be open sourced whereas the GPL does - I thought I'd leave the option say if a user wants a way out
<re_irc> <> If you have it split out by crate like that, you can make the top level crate MIT, but the rustboot_update crate GPL.
<re_irc> <> that way if you have it as a transitive dependency, you'd know you definitely have GPL code
<re_irc> <> and it would be clear to the user they would have to rewrite/replace that crate if they wanted to avoid the gpl2 dependency.
<re_irc> <> In general: Once you link in gpl2 code into your binary: the whole binary is now gpl2 licensed.
<re_irc> <> I thiiiiiiink gpl2 has the dynamic linking exception? (maybe that's just lgpl2), which means if your bootloader is gpl2, and your app isn't, that's probably okay.
<re_irc> <> yeah the mix is somewhat weird, it means the whole can only be used under the GPL, unless you rewrite the GPL parts
<re_irc> <> but the bootloader itself would definitely by gpl2
<re_irc> <> dynamic linking exception is only LGPL yup
<re_irc> <> Does a GPL bootloader make the application GPL too?
<re_irc> <> if you ship them together as one binary.
<re_irc> <> (iirc)
<re_irc> <> it comes down to "distribution"
<re_irc> <> but honestly, not a lawyer here
<re_irc> <> MIT is Gpl compatible, so others can use the code as Gpl if they want as long as they also comply with MIT, which just means they provide the licence text and attribution
<re_irc> <> but I definitely know if you statically compile a gpl2 component into a binary (like a bootloader), then the whole binary is definitely gpl2.
<re_irc> <> and if that's a non-optional component of rustboot, rustboot should probably be gpl2. Though as I said, you could mark that by just making the crate component gpl2, and people should know if they have ANY transitive deps with gpl2 code, their binary should be gpl2
<re_irc> <> (you might get some grumpy people who only look at the top level deps and see MIT tho, but that's kind of on them, IMO)
<re_irc> <> If it's on a feature flag though, for example, and you note in the readme/features section that "activating the update feature includes gpl2 code", then that's pretty much the best you can do.
<re_irc> <> btw looking at GPL code and then implementing the same thing from scratch on your own doesn't make your code GPL
<re_irc> <> Now we are into opinions that are out of my pay grade :D
<re_irc> <> hmm, that's what I did
<re_irc> <> so if it's indeed written from scratch, "inspired by" some other code then you can just say it's MIT
<re_irc> <> but I always assumed that ports were considered derived works and the same licenses apply. If I understand you correctly, that's not true
<re_irc> <> 1:1 port into a new lang would be considered derived works, IIRC.
<re_irc> <> hmm
<re_irc> <> if it's c2rust-ed or something similar, sure
<re_irc> <> (dropping out, I'm just full of guesses now)
<re_irc> <> if it's new code from scratch implementing the same "algorithm" then no
<re_irc> <> an "algorithm" or "idea" can't be copyrighted, it can only be patented
<re_irc> <> if it's "ported" by having both programs open side by side and "translating" stuff manually then uhhhhh... grey area maybe??
<re_irc> <> it was the former, the `update logic` is functionally the same but its design is actually different (i.e. includes many of rust's ideas compile-time state-transition checks, sealed states etc. )
<re_irc> <> thats pretty safe then
<re_irc> <> yeah
<re_irc> <> honestly, there's very little likelyhood of enforcement action here anyway, but you do want to keep the lawyers away where possible
<re_irc> <> ok, that great news. yeah, I'd like to err on the side of caution. I'll have a chat internally and switch to the MIT license as that's what we were aiming for in first place.
<re_irc> <> - is there any language that I should include as a note in the repo to highlight this point - you know just in-case.
<re_irc> <> easy to confirm with a quick google of "algorithms copyright"
<re_irc> <> for example
<re_irc> <> > Section 102 of the Copyright Act (title 17 of the U.S. Code) clearly expresses this principle: β€œIn no case does copyright protection for an original work ofauthorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.”
<re_irc> <> ie copyright (thus the GPL) applies to a particular piece of code, not to the algorithm/idea behind it
<re_irc> <> and anyway the "idea" of "let's have 2 flash partitions with some header to describe what's in each" is soooo widespread that you could've as well learned it from somewhere else
<re_irc> <> :D
<re_irc> <> there's certainly enough prior art that you could defeat a patent, but that's not the same as copyright law
<re_irc> <> well, I learnt something today. thanks! got to go be a lawyer for sometime πŸ˜‡
<re_irc> <> IANAL though :D
<re_irc> <> i yeah i am definitely not a lawyer either, you should definitely talk to one if you need legal advice
<re_irc> <> was just kidding. yep, will do but thank you for the info.
<re_irc> <> Could anyone confirm, that this would indeed be a viable solution?
<re_irc> <> My naive idea would be something along the lines of
<re_irc> <> ```rust
<re_irc> <> #[exception]
<re_irc> <> that looks quite scary, the compiler might put code before the `rewind_stackpointer()` call
<re_irc> <> like the function preamble, or maybe reordering stuff
<re_irc> <> it's probably UB
<re_irc> <> i'd do it with a naked fn + inline asm, it's nightly-only though
<re_irc> <> have the asm rewind SP, then call a rust fn that does the rest
<re_irc> <> or in stable you can put it in a .s file then link it in with the `cc` crate, no longer pure rust though
<re_irc> <> That sounds like one way. And what would my asm be then? :p
<re_irc> <> ```rust
<re_irc> <> #[naked]
<re_irc> <> #[no_mangle]
<re_irc> <> #[cfg_attr(target_os = "none", link_section = ".HardFault.user")]
<re_irc> <> that'll set SP to 0x12345678
<re_irc> <> based on a similar thing I have on my firmware that does work, but the SP thing is untested
<re_irc> <> maybe you can get it to use the `_stack_start` from the linker script with something like `ldr sp, =_stack_start` or something, dunno the exact syntax
<re_irc> <> why the `#[cfg_attr(target_os = "none", link_section = ".HardFault.user")]`?
<re_irc> <> that's what the CMRT macros do
<re_irc> <> dunno, maybe it's so that it builds fine for non-embedded
<re_irc> <> if you don't care about that then maybe just `#[link_section = ".HardFault.user"]` will work
<re_irc> <> Ahh, okay.. cool
fabic has joined #rust-embedded
<re_irc> <> Is there any way to bring along the `frame: &::cortex_m_rt::ExceptionFrame` from the hardfault to `RealHardFault'?
<re_irc> <> Yes, just copy what the macro does
<re_irc> <> I think it's a ptr to the top of the stack or something
<re_irc> <> I don't know what happens to the frame if it's a stack overflow though
<re_irc> <> The HW will fail to push it
GenTooMan has quit [Ping timeout: 250 seconds]
GenTooMan has joined #rust-embedded
<re_irc> <> I have again a question about a device crate: I try to use interrupts from the device crate ( ). I use the syntax mentioned in the documentation ( ) but i get the following error: ```
<re_irc> <> | ^^^^^^^^^---------
<re_irc> <> 11 | use mkl25z4::interrupt;
<re_irc> <> | | |
<re_irc> <> If i import the Interrupt module it still does not wor
<re_irc> <> Is there anything out of date?
<re_irc> <> > Re-exports
<re_irc> <> > `pub use self::Interrupt as interrupt;`
<re_irc> <>
<re_irc> <> Seems strange…
<re_irc> <> Can the enumeration replace the macro in a way?
<re_irc> <> It seems the `interrupt` you want is equivalent to `cortex_m_rt::interrupt`
<re_irc> <> yes but in the doc it says "NOTE: This attribute is exposed by cortex-m-rt only when the device feature is enabled. However, that export is not meant to be used directly -- using it will result in a compilation error. You should instead use the device crate (usually generated using svd2rust) re-export of that attribute. You need to use the re-export to have the compiler check that...
<re_irc> ... the interrupt exists on the target device."
<re_irc> <> Have you enabled the feature `rt` in your `Cargo.toml` for `mkl25z4`?
starblue3 has quit [Ping timeout: 250 seconds]
<re_irc> <> you mean with [dependencies.mkl25z4]
<re_irc> <> ```toml
<re_irc> <> [dependencies]
<re_irc> <> mkl25z4 = { version = "...", features = ["rs"] }
<re_irc> <> Maybe?
<re_irc> <> ah i see i will try that thank you
<re_irc> <> No problem, if it does not work I apologize I am still a begineer ^^
<re_irc> <> ah sadly it does not, but I will try to enable it somehow :) that might be a good hit, thank you
GenTooMan has quit [Ping timeout: 240 seconds]
<re_irc> <> 😩 Sorry, tell me when you manage to make it work, I want to know the solution! πŸ˜„
GenTooMan has joined #rust-embedded
<re_irc> <> how are you using it? do you have some code?
<re_irc> <> jorgeig: Hey, I'm looking into using rust-lorawan with stm32wl55 (though eventually in the context of using embassy as the PAC/HAL). newam mentioned you might already be working on something similar. Just wanted to check if you had started something already or if you're planning to.
<re_irc> <> I'm planning to, either at the end of this week or next week
<re_irc> <> will try with this:
<re_irc> <> it looks like it has the basics down, which is already a lot
<re_irc> <> Cool... I've been integrating that with sx127x earlier: - its working nicely on the stm32l0 lora-discovery. I've been wanting to bring it to wl55 as well
<re_irc> <> And the wl55 has more ram, so it will be even easier πŸ˜…
<re_irc> <> jorgeig: Anyway, let me know if you'd like to share the burden :)
<re_irc> <> sure! as soon as I start working on it I'll let you know
fabic has quit [Ping timeout: 250 seconds]
<re_irc> <> yes, here it is:
<re_irc> <> Could it be that there is no dependecy to the rt feature in this crate? The crate is a year old and could be deprecated in cause of some cahnges
<re_irc> <> do you have a full git repo? makes it a little easier to try things out
<re_irc> <> give me a second.
starblue has joined #rust-embedded
<re_irc> <> here it is.
<re_irc> <> 404? is it private
<re_irc> <> ah wait
<re_irc> <> now it should work
<re_irc> <> Got it to compile with `cargo build --target thumbv7em-none-eabihf`
<re_irc> <> ```console
<re_irc> <> $ cargo --version
<re_irc> <> cargo 1.54.0 (5ae8d74b3 2021-06-22)
<re_irc> <> rustfmt went a little crazy on the file; but all the real (non whitespace) changes occured at the bottom
<re_irc> <> ```rs
<re_irc> <> use mkl25z4::interrupt;
<re_irc> <> #[interrupt]
<re_irc> <> the processor i want to work it on is a m0+, does that still work with that target?
<re_irc> <> Compiles with `cargo build --target thumbv6m-none-eabi` as well, I just made a (bad) assumption about the target πŸ˜‡
<re_irc> <> Just note it does not compile if you just do `cargo build` since it tries to link symbols that `x86_64- ...` doesn't like.
<re_irc> <> You can change the default build target in `.cargo/config.toml` if you would like.
<re_irc> <> ah i see, thank you very much!
<re_irc> <> no problem, glad I could help! The compiler messages for that problem are difficult to sort out.
fabic has joined #rust-embedded
<re_irc> <> absolute noob question coming now: i can merge that now by pull request?
<re_irc> <> It is possible without a pull-request, but it is a bit annoying when working with two separate.
<re_irc> <> I'll open a pull request so you can do that.
<re_irc> <> There you go, merge it in the UI there then you should be able to do a `git pull` and see the changes in your local copy.
<re_irc> <> nice that worked :)
<re_irc> <> For reference, the way to do that without a pull request is `git pull` which is roughly equivalent to a `git merge <branch>` but using a different repository instead of a different branch.
fabic has quit [Ping timeout: 244 seconds]
<re_irc> <> ah i see
SomeWeirdAnon has joined #rust-embedded
dcz has quit [Ping timeout: 250 seconds]
<re_irc> <> I am getting linker errors with this cargo workspace... I feel like I have seen that before, but I can't solve it myself. Anyone could take a look?
<re_irc> <>
<re_irc> <> the last error line I have is "cannot find linker script memory.x"
<re_irc> <> I think for a workspace the `.cargo/config.toml` must go in the root (I am not sure about that - I may be wrong).
<re_irc> <> if you need separate `memory.x`'s I think you have to use `` scripts.
<re_irc> <> Though it looks like they are different targets, so you may be able to get away with `.cargo/config.toml` with condition `memory.x's` for each target
<re_irc> <> same targets, just one crate is a lib
<re_irc> <> gotcha, yeah, just moving `.cargo/config.toml` to the root should make it work then (I hope)
<re_irc> <> nope, don't think so
<re_irc> <> oh, and the `memory.x` would have to be in the root too then
<re_irc> <> ah ok, perhaps I should move the lib project out of the workspace? I am starting to think this doesn't need to be a workspace anyway
<re_irc> <> moving the memory.x to top made it compile - nice, thanks!
<re_irc> <> Generally I would say keep it in a workspace, it allows you for flexibility when it comes to testing.
<re_irc> <> workspaces are handy, they're just a big difficult to work with for embedded.
<re_irc> <> argh, one project uses defmt + rtt + rtic, but that needs a different linker file. Don't know...
<re_irc> <> You can include `defmt` and use the features to disable the logging so that linking `defmt.x` works for all targets.
<re_irc> <> hmm, nice
<re_irc> <> thanks for your help!
GenTooMan has quit [Ping timeout: 252 seconds]
<re_irc> <> no problem!
GenTooMan has joined #rust-embedded
GenTooMan has quit [Ping timeout: 240 seconds]
GenTooMan has joined #rust-embedded
GenTooMan has quit [Ping timeout: 250 seconds]
GenTooMan has joined #rust-embedded