dreamcat4 has quit [Quit: Connection closed for inactivity]
<re_irc>
<@korken89:matrix.org> As a general question to all embedded consultants out there, does anyone have a overview of pricing models for drivers that a customer can buy? E.g. we have a driver for a radio chip that a customer wants to use instead of the manufacturer supplied one, but we have no idea on how to price it or how it's usually done in the industry. Does anyone have a hint on how this is usually done?
<re_irc>
<@jordens:matrix.org> korken89: (a) analyze the work to be done, write a roadmap, estimate hours it'll take you, multiply by fudge factor and margin, hand out quote or (b) hand out estimate as such and ask for partial payment based on hours at go/no-go points or monthly along the way or (c) estimate the amount of code, multiply by your cost per line of code based on past projects and multiply by fudge factor and by margin
<re_irc>
<@korken89:matrix.org> Thanks for the tip!
<re_irc>
<@jordens:matrix.org> But yeah. It's hard and you will likely underestimate the cost. Hourly helps you with that and in turn go/no-go helps the customer manage the uncertainty.
<re_irc>
<@korken89:matrix.org> Yeah
<re_irc>
<@korken89:matrix.org> We more or less are thinking that the hourly rate to "rewrite" the driver for them should be >> single cost of finished driver
<re_irc>
<@korken89:matrix.org> Or something like that
<re_irc>
<@korken89:matrix.org> Difficult...,
<re_irc>
<@jordens:matrix.org> Depending on customer background, writing the specification together with them may already be the hardest part. 😉
<re_irc>
<@korken89:matrix.org> Especially since we usually don't do consultancy (we are a product company)
<re_irc>
<@korken89:matrix.org> But only we have implemented features for the chip that a customer wants (plus that it will be compatible with our infrastructure)
<re_irc>
<@korken89:matrix.org> So we are in the deep end of "not our normal sale" xD
<re_irc>
<@korken89:matrix.org> But thanks for the tips! I have more insight now :)
<re_irc>
<@thejpster:matrix.org> There is Time and Materials, and there is Fixed Price. The latter must be a bigger amount than the former, as you must allow some contingency (in case you estimate too low) - but at least the customer knows what they will pay. The first option is usually cheaper, but to your customer it feels like they are writing a blank cheque. So you just have regular milestones and updates.
<re_irc>
<@huntc:matrix.org> korken89:matrix.org: T&M in general where there is discovery to be made... they'll want a budget though. In the end, it is worth what the market is willing to pay. I advise asking the customer what they are willing to pay.
<re_irc>
<@thejpster:matrix.org> If there is pre-existing IP you wish to sell, then your time is already lost and all you can do is try and get as much money as you can.
<re_irc>
<@thejpster:matrix.org> Hah, yes.
<re_irc>
<@korken89:matrix.org> thejpster:matrix.org: This is what we have
<re_irc>
<@korken89:matrix.org> Super, thanks!
<re_irc>
<@thejpster:matrix.org> Also, exclusive IP is worth more than non- exclusive. No one will pay full price (i.e. cost to replace) for non-exclusive if you're just going to sell it to their competitor next week.
<re_irc>
<@korken89:matrix.org> Yeah makes sense
<re_irc>
<@korken89:matrix.org> I appreciate the feedback! Now I have some idea on how to assist in the estimate :D
<re_irc>
<@ryan-summers:matrix.org> Yeah, I'm much more in the wagon of hour-based accounting. It allows you to be infinitely more flexible. Projects _never_ go according to plan and there's always things that pop up that someone wants investigation into. If you work on fixed price, you're discouraged from helping your client outside of exactly what the contract is for, which typically isn't ideal for anyone involved imo
<re_irc>
<@ryan-summers:matrix.org> Honestly I'd probably be more in the market of offering them the IP as part of a consulting package. You help them support and integrate it, extend features on it, etc.
<re_irc>
<@korken89:matrix.org> ryan-summers:matrix.org: I think this is what we will do, and use the IP to reduce total hours
<re_irc>
<@ryan-summers:matrix.org> Yeah, I've often developed internal tools for consulting firms that they in turn use for various clients, but just keep all the tooling in-house
<re_irc>
<@korken89:matrix.org> Nice, makes sense
<re_irc>
<@ryan-summers:matrix.org> And that tooling then goes to the value proposition of the firm to their clients. They can now claim to have the tooling that makes them way more efficient than others, which can result in higher rates
<re_irc>
<@korken89:matrix.org> Ah
<re_irc>
<@korken89:matrix.org> Nice way to differentiate for them
xnor has quit [Ping timeout: 265 seconds]
xnor has joined #rust-embedded
<re_irc>
<@mehmet:grusbv.com> (crossposting from #rust:matrix.org )
<re_irc>
<@mehmet:grusbv.com> Hi! I am trying to put a very long array to a different file to be imported. The array definition will be used for test purposes, but must be compiled and ran.
<re_irc>
<@mehmet:grusbv.com> I was doing sth like this: (simplified)
<re_irc>
<@adamgreig:matrix.org> hi room! meeting time again, agenda is https://hackmd.io/PQeCCugFQiK9-HW4Q-Vmrw, please add anything you'd like to talk about! we'll start in 5min
<re_irc>
<@timokrgr:matrix.org> 👋
<re_irc>
<@dirbaio:matrix.org> 👋
<re_irc>
<@adamgreig:matrix.org> 👋
<re_irc>
<@adamgreig:matrix.org> ok, let's start! couple quick announcements, first a reminder that rust 1.56 is out, including 2021 edition!
<re_irc>
<@adamgreig:matrix.org> ...and including adding linker scripts via build.rs which we should look into for c-m-rt sometime 👀
<re_irc>
<@adamgreig:matrix.org> and, berlin leaves daylight saving time this sunday, so our meetings will remain 8pm berlin time but this may shift for people in other countries
<re_irc>
<@adamgreig:matrix.org> that's all I've got, any announcements from anyone else?
<re_irc>
<@adamgreig:matrix.org> I don't think there's much outstanding/new discussion after last week, just still a desire to see them implemented to check they work as well as we think they will
<re_irc>
<@adamgreig:matrix.org> I guess you can save the announcement for when it's done :P nice, though!
<re_irc>
<@thejpster:matrix.org> I have a quick announcement
<re_irc>
<@adamgreig:matrix.org> such a pernicious bug
<re_irc>
<@adamgreig:matrix.org> go for it thejpster
<re_irc>
<@thejpster:matrix.org> I was doing a bunch of Raspberry Silicon RP2040 stuff as paid work. But that has come to abrupt end because I'm leaving that job. Lots more Rust to come when I start my new job though, so hopefully only a hiatus for a couple of weeks.
<re_irc>
<@adamgreig:matrix.org> 👍️ good luck with the new job!
<re_irc>
<@thejpster:matrix.org> Also, if you can ever get paid or otherwise find time to do a whole day on a project, it's way more efficient! :)
<re_irc>
<@adamgreig:matrix.org> funnily enough that's what my day job thinks too :P
<re_irc>
<@timokrgr:matrix.org> yeah, marked the constructors as `unsafe` again
<re_irc>
<@adamgreig:matrix.org> there was some recent chat about whether its `new_unchecked` methods for IDs should be unsafe which I think is probably resolved now, though if anyone has opinions please have a quick look
<re_irc>
<@timokrgr:matrix.org> good that the inconsistency was spotted
<re_irc>
<@adamgreig:matrix.org> yea, definitely would have been bad to have it different for std/extended
<re_irc>
<@timokrgr:matrix.org> there was the request for unit tests, they would mostly just test constants
<re_irc>
<@therealprof:matrix.org> I have not left a note yet but briefly talked with eldruin about it earlier today. This seems ready to land.
<re_irc>
<@therealprof:matrix.org> ... or very close to. Seems like eldruin had something with unittests in mind. I'll let them have the final word.
<re_irc>
<@adamgreig:matrix.org> cool
<re_irc>
<@adamgreig:matrix.org> I think let's move to thejpster's agenda items and revisit the i2c nack errors after if there's time, as I don't think much has changed since the discussion last week
<re_irc>
<@timokrgr:matrix.org> I can add the unit tests in the next days, shouldn’t be too much effort
<re_irc>
<@adamgreig:matrix.org> thejpster, want to go ahead with yours?
<re_irc>
<@thejpster:matrix.org> OK, hang on let me see what was first
<re_irc>
<@thejpster:matrix.org> Right, MSRV
<re_irc>
<@thejpster:matrix.org> All the crates in the cortex-m repo seem to set MSRV randomly
<re_irc>
<@thejpster:matrix.org> Somewhere between 1.31 and 1.38
<re_irc>
<@thejpster:matrix.org> And we want to get on Rust 2021 soonish, because of the quality of life improvements
<re_irc>
<@thejpster:matrix.org> Who would get upset it we bumped the MSRV to 1.56 in 12 weeks' time? (i.e. it would be oldoldstable at that point)
<re_irc>
<@adamgreig:matrix.org> hmm
<re_irc>
<@adamgreig:matrix.org> our msrv policy is we bump it whenever we need to, to no newer than oldoldstable
<re_irc>
<@adamgreig:matrix.org> but is there any particular need to bump it for those crates for its own sake?
<re_irc>
<@adamgreig:matrix.org> I could be quickly convinced for c-m-rt because of the linker script business
<re_irc>
<@therealprof:matrix.org> Are there any concrete QoL improvements you had in mind?
<re_irc>
<@thejpster:matrix.org> well we need to bump it to make .cargo/config.toml go away.
<re_irc>
<@thejpster:matrix.org> Or at least the obscure way we set the linker script for thumbvX
<re_irc>
<@adamgreig:matrix.org> that's only for cortex-m-rt though, right?
<re_irc>
<@dirbaio:matrix.org> cmrt doesn't set the linker script, just copies it to out_dir
<re_irc>
<@dirbaio:matrix.org> it's the end user's crate that has the -Tlink.x
<re_irc>
<@thejpster:matrix.org> But we could fix that
<re_irc>
<@thejpster:matrix.org> Because the cmrt build.rs could set the linker script
<re_irc>
<@thejpster:matrix.org> But anyway, the point it MSRVs
<re_irc>
<@thejpster:matrix.org> This is all moot if we're stuck at 1.30-something
<re_irc>
<@dirbaio:matrix.org> a crate can't set the linker script for bins from another crate
<re_irc>
<@thejpster:matrix.org> Who would get upset it we bumped the MSRV to 1.56 in 12 weeks' time? (i.e. it would be oldoldstable at that point)
<re_irc>
<@therealprof:matrix.org> thejpster:matrix.org: The irony... .cargo/config.toml was only introduced in 1.39, before it only supported it without .toml
<re_irc>
<@therealprof:matrix.org> No objections as long as there's a crystal clear benefit.
<re_irc>
<@adamgreig:matrix.org> it's not a problem to bump the msrv, but as part of a PR that does something that needs it, not just for its own sake
<re_irc>
<@thejpster:matrix.org> OK, great.
<re_irc>
<@thejpster:matrix.org> As long as someone isn't sitting on a rustc fork that's stuck in time
<re_irc>
<@dirbaio:matrix.org> the user chooses whether they set the linker script with .cargo/config.toml or build.rs in their crate
<re_irc>
<@thejpster:matrix.org> Or desperately needing to build with the rustc shipped with debian or something
<re_irc>
<@dirbaio:matrix.org> they can decide to stick to a new rust and use build.rs, no changes needed in cmrt
<re_irc>
<@adamgreig:matrix.org> ah great, yea i hadn't thought that through dirbaio
<re_irc>
<@dirbaio:matrix.org> you can already do that today, I am fwiw
<cr1901>
Basically, this doesn't remove the rt dance of copying linker fragments to create a full script
<cr1901>
just allows you to set the script in build.rs
<cr1901>
correct?
<re_irc>
<@adamgreig:matrix.org> thejpster: our standing policy is "must build on today's stable", we don't have a policy that we have to stick to an old msrv for some particular reason, https://github.com/rust-embedded/wg/blob/master/ops/msrv.md
<re_irc>
<@thejpster:matrix.org> OK cool, but there's quickstart and other things to think about. Anyway, I'm fine with this.
<re_irc>
<@thejpster:matrix.org> Let's move on!
<re_irc>
<@dirbaio:matrix.org> quickstart's "msrv" can be bumped, it doesn't need bumping cm or cmrt's
<re_irc>
<@thejpster:matrix.org> My second item was around software simulation of arm chips
<re_irc>
<@thejpster:matrix.org> You can emulate some Arm systems (a weird Luminary Micro Cortex-M3 that no-one uses) in QEMU, but we hear that it's a bit ... non-deterministic.
<re_irc>
<@thejpster:matrix.org> Which was looking at doing testing on real hardware
<re_irc>
<@adamgreig:matrix.org> there's a bunch of other machines available for qemu, including some stm32s and so forth
<re_irc>
<@adamgreig:matrix.org> quality of simulation is definitely variable
<re_irc>
<@adamgreig:matrix.org> though the luminary one ships with stock qemu which does have some appeal, I think RTIC has tests using that?
<re_irc>
<@thejpster:matrix.org> I found out that Arm have a good (and much better than qemu) but not cycle accurate, simulator called a "Fast Model"
<re_irc>
<@thejpster:matrix.org> And you can get the Fast Model for the Cortex-M55 as part of a "Fixed Virtual Platform", as a download with no licence click-through required.
<re_irc>
<@thejpster:matrix.org> Which is good, because normally a Fast Model is about $1000 a person
<re_irc>
<@adamgreig:matrix.org> I expect many of those tests are things we don't do in cortex-m so might not be so bad for us
<re_irc>
<@adamgreig:matrix.org> but it would be interesting to know if their tests fare any better on arm's fast model
<re_irc>
<@thejpster:matrix.org> Oh and thanks to newam for offering to host real hardware!
<re_irc>
<@thejpster:matrix.org> I like testing on real hardware. I am perhaps less warm about gating PRs on CI running on infra with no SLA.
<re_irc>
<@adamgreig:matrix.org> like I said, I think RTIC are using qemu quite successfully, without the sorts of issues zephyr are seeing
<re_irc>
<@adamgreig:matrix.org> so it's probably an option
<re_irc>
<@adamgreig:matrix.org> one option is to not gate them but have them be advisory only, e.g. if they run and fail then something's probably wrong, if they run and pass then great, and if they fail to run because the test rig is down then the reviewer can run the same tests manually locally
<re_irc>
<@adamgreig:matrix.org> but to be honest my suspicion is our pace of development is gentle enough to stand a few CI outages without major problem, so we could just gate on it
<re_irc>
<@adamgreig:matrix.org> I think the real advantage would just be in having a test suite at all, and being able to run it on local hardware easily (especially e.g. those nucleo boards that lots of people have or can get)
<re_irc>
<@adamgreig:matrix.org> having it then run in CI is a huge boon for contributors and makes reviewer's lives much easier too
<re_irc>
<@dirbaio:matrix.org> related to HIL testing:
<re_irc>
<@newam:matrix.org> As a related topic should we discuss moving cortex-m-rt into the cortex-m repo? That will be required regardless of testing strategy.
<re_irc>
<@adamgreig:matrix.org> dirbaio: so you'd use GHA's own CI servers to build an ELF, then have the GHA action POST it to the HIL tester?
<re_irc>
<@dirbaio:matrix.org> so you can do all the building on the github-hosted runners, no remote-code-execution runner required
<re_irc>
<@dirbaio:matrix.org> yep
<re_irc>
<@dirbaio:matrix.org> my plan is to use it for embassy, building a farm of stm32/nrf chips. I can lend access to rust-embedded's projects if needed too
<re_irc>
<@adamgreig:matrix.org> still remote code exec on the target of course but they are probably less appealing crypto miners than the CI servers :P
<re_irc>
<@adamgreig:matrix.org> don't think the stm32's hardware accelerated sha would be great
<re_irc>
<@dirbaio:matrix.org> unfortunately for HAL testing you need real hardware... I don't think the qemu stm32s are good enough
<re_irc>
<@newam:matrix.org> Yeah, too much is left unimplemented to test HALs on QEMU.
<re_irc>
<@thejpster:matrix.org> Is there a HALT_AND_CATCH_FIRE equivalent for Arm? I note the PR talks about wearing out flash deliberately.
<re_irc>
<@dirbaio:matrix.org> my plan is to only run it on `trying` and `staging` branches, so it only runs after `bors r+` or `bors try`
<re_irc>
<@dirbaio:matrix.org> so there's some review first
<re_irc>
<@adamgreig:matrix.org> given the PR would have to be deliberately malicious and it's not clear there's any material benefit for the submitter either (unlike crypto mining on CI servers), I'm sort of hopeful there won't be abuse
<re_irc>
<@dirbaio:matrix.org> there are some chips you can outright brick (nrf53's APPROTECT+ERASEPROTECT for example)
<re_irc>
<@adamgreig:matrix.org> ah, yea, that would be pretty annoying
<re_irc>
<@adamgreig:matrix.org> same deal on stm32
<re_irc>
<@thejpster:matrix.org> OK, but hopefully any malicious intent would be obvious from a code review
<re_irc>
<@thejpster:matrix.org> So yeah if the HIL run is gated on a `bors try` that seems OK
<re_irc>
<@newam:matrix.org> I run the STM32WL HIL without approval, but that's a much smaller repo in terms of contributors. I think the probability of abuse occuring is low - it is just good to keep in mind that it can occur.
<re_irc>
<@thejpster:matrix.org> And the free fast model remains an option if anyone wants to try it
<re_irc>
<@adamgreig:matrix.org> yep
<re_irc>
<@adamgreig:matrix.org> once we have a test suite it would hopefully be fairly quick to see if it runs on an arm fast model
<re_irc>
<@adamgreig:matrix.org> if someone was interested in playing with it
<re_irc>
<@adamgreig:matrix.org> first step for c-m is definitely moving c-m-rt crate into the same repo
<re_irc>
<@adamgreig:matrix.org> if there are any volunteers... 👀 otherwise I'll try and start putting it together later this week
<re_irc>
<@adamgreig:matrix.org> or put it on my list of things to do 'later this week' anyway
<re_irc>
<@newam:matrix.org> adamgreig: I will take a look at the fast model for cortex-m testing this weekend.
<re_irc>
<@adamgreig:matrix.org> cool, thanks!
<re_irc>
<@adamgreig:matrix.org> OK, I think that just about covers us for this week unless anyone has anything else to mention?
<re_irc>
<@adamgreig:matrix.org> ok, let's call it there, then, thanks everyone!
<re_irc>
<@therealprof:matrix.org> Any news about the newsletter? 😉
<re_irc>
<@adamgreig:matrix.org> the meeting's over, I don't have to answer that 😬
<re_irc>
<@adamgreig:matrix.org> hmm actually #30 has already got a fair bit of content
<re_irc>
<@adamgreig:matrix.org> much of it thanks to eldruin