<chrysn[m]>
I realize 20h after sending a PR is short time to ask, but things have been very quiet there for years, and I haven't seen any of the contributors around in quite some time.
<chrysn[m]>
(It'd be a useful tool for the RIOT∪Ariel community, I'd like to do more than just a few fixes, and can probably even find people to review changes, should you decide it is archived – but prefer to work with you on it)
<thejpster[m]>
chrysn: I use it as part of every Embedded Training to program the nRF52840 Dongle, but it works so I haven't had to change it in years.
<thejpster[m]>
It appears I don't have notifications on that repo as I didn't get an email about your PR. Let me fix that.
<chrysn[m]>
Cool; that means there are also test cases around that my generalizations to the ELF could be checked against :-)
<thejpster[m]>
yes, please check it with my example firmware (I'd do it myself but I'm really busy today and tomorrow).
<thejpster[m]>
I think the best solution is that I move it into knurling-rs. It's much easier to accept outside contributions there.
<thejpster[m]>
I'll discuss that internally.
<jason-kairos[m]>
question: code generators vs proc-macros. Most debuggers, especially gdb, seem to do really poorly with proc-macros like write!() or println!() when minimal optimizations are enabled (which is common on MCUs) because there is no expanded source to map the lines/instructions/debug symbols to.
<jason-kairos[m]>
Using a code generator that spits out a rust file into the build directory possibly solves some of that. They are used in a handful of projects. But are limited in what they can do.
<jason-kairos[m]>
Is there anything that can be done to make the generated output of proc-macros more pleasant to debug? (ie. more similar to the experience of debugging the output of a code generator)
<jason-kairos[m]>
FAQ Q8 and license section 3.2 I think
<JamesMunns[m]>
Ah, yes, IF you modify the source, you must include a notice in the user manual that the upstream library was used and modified, and inform them how to obtain your modified version
<JamesMunns[m]>
(maybe you also need to provide that notice if you don't modify it, but you can point to the original location, you don't have to host it)
<jason-kairos[m]>
but if I don't modify it, maybe I don't have to notify? Not sure
<jason-kairos[m]>
nevermind, you addressed it
<JamesMunns[m]>
yeah, I think you nailed it with Q8
<JamesMunns[m]>
> You must inform the recipients where they can get the source for the MPLed code in the executable program or library you are distributing (i.e., you must comply with Section 3.2).
<JamesMunns[m]>
So very similar to MIT/Apache2 if you DON'T modify anything, if you DID you have to say that and also provide a way for recipients to get THAT version of the source.
<JamesMunns[m]>
fwiw, you are getting out of "technical" area and into a "legal" area
<JamesMunns[m]>
"legal" has a higher standard of "good faith dealing"
<JamesMunns[m]>
"WELL TECHNICALLY" doesn't always fly with a judge
<JamesMunns[m]>
but afaik mpl has never been tested in court, so even if you ask a lawyer, you are still only going to get a "reasonable estimate" of how they think the law and agreement would be interpreted.
<JamesMunns[m]>
and ymmv by jurisdiction, etc.
<JamesMunns[m]>
the law is squishier than code
<jason-kairos[m]>
I think you're right - it's a hand-wavy mess. Nearly impossible to reason about or discuss in any depth in most contexts.
<jason-kairos[m]>
Welp, I feel pretty good about my chances of complying so long as I do whatever everyone else is already doing.
<jason-kairos[m]>
(I do worry that my Rust product won't have a physical manual, nor space for a huge disclaimer on the label. We'll have to include it in paperwork and on the website at some point in the process)
<jason-kairos[m]>
Another silly question: does anyone know of real commercial products (without a screen or user interface) using licenses like the MPL?
<jason-kairos[m]>
* real commercial "embedded type" products (, * products (rust or non rust, without a
<jason-kairos[m]>
* Another silly question: does anyone know of any real commercial "embedded type" products (rust or non rust, without a screen or user interface) using licenses like the MPL?
<jason-kairos[m]>
I feel like there are not many "simple" devices like toaster ovens or microwaves that use open source libraries.
<jason-kairos[m]>
* ~~Another silly question: does anyone know of any real commercial "embedded type" products (rust or non rust, without a screen or user interface) using licenses like the MPL?
<jason-kairos[m]>
I feel like there are not many "simple" devices like toaster ovens or microwaves that use open source libraries.~~
RobinMueller[m] has quit [Quit: Idle timeout reached: 172800s]
wassasin[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]>
You need to do the same for MIT licensed items, fwiw
<JamesMunns[m]>
I can't remember if Apache2 requires it, that might be one of the differences
<jason-kairos[m]>
unrelated question:
<jason-kairos[m]>
I've got an syscall handler on Cortex-M0+ that is a mix of rust and asm.
<jason-kairos[m]>
I've noticed that R12 is hard to use with most instruction - but I can't find much documentation of it. Can someone point me to the right ARM document that describes which instructions can be used with R12?
<JamesMunns[m]>
that would probably be the arm arm
<JamesMunns[m]>
Might not be relevant to thumb-only programs tho, not personally familiar
<JamesMunns[m]>
To answer your specific question @jason-kairos:
<JamesMunns[m]>
> Typically, the registers r4-r8, r10 and r11 (v1-v5, v7 and v8) are used to hold the values of a routine’s local variables. Of these, only v1-v4 can be used uniformly by the whole Thumb instruction set, but the AAPCS does not require that Thumb code only use those registers.
<JamesMunns[m]>
but really RISC vs CISC is all fuzzy lines anyway, with architectures like aarch64 and with how microcode works on x86_64
<Koen[m]>
Yeah, but there's easy to use RISC, and there's ARMv6, where half the instructions work with only half the registers
<JamesMunns[m]>
heh, very fair
<jason-kairos[m]>
It's as if R12 can only read from with 1 instruction and never written to. I'm sure it's not true, but it seems that way with most instructions I've looked at.
<jason-kairos[m]>
* can only be read from
<jason-kairos[m]>
actually, I looked at every instruction and I think it's true
<jason-kairos[m]>
maybe push and pop are the only way to write to R12
<jason-kairos[m]>
and move/pop the only way to read R12
<JamesMunns[m]>
(I'm definitely not an expert at arm asm)
<jason-kairos[m]>
hmm... not even push and pop can access R12.
<rafael[m]>
Re escrow: not necessarily a lawyer, there are specialist companies providing that service. Some of our customers (totally different domain than embedded) require us to have that in place.
pcs38 has quit [Quit: leaving]
sroemer has quit [Quit: WeeChat 4.5.2]
pcs38 has joined #rust-embedded
jfsimon has quit [Quit: Leaving]
jfsimon has joined #rust-embedded
EricSeppanen[m] has joined #rust-embedded
<EricSeppanen[m]>
How can I join the unconference at RustWeek? Somehow I missed any signup links.
diondokter[m] has joined #rust-embedded
<diondokter[m]>
EricSeppanen[m]: Pretty much just DM adamgreig