<Ecco>
Question: what do you guys use to profile code execution? I'd like to improve the performances of my embedded Rust code
AtleoS has joined #rust-embedded
bomb has joined #rust-embedded
<sneakernet[m]>
<paulyoung[m]> "There's a video on YouTube about..." <- this is a naive understanding of cross-hardware support
<sneakernet[m]>
<Kaspar[m]> "We're trying to get there with..." <- ouch, so much specialization needed - what drives the pac's to be patched? can't the target pac be decoupled per rust-embedded architeture?
KevinLy[m] has joined #rust-embedded
<KevinLy[m]>
HI, first time posting to this channel. I have a specific question about the stm32f3 crate and getting the ADC to work. Can I ask that here or should I ask the maintainers of the crate?
<sneakernet[m]>
Kevin Ly: just ask
<sneakernet[m]>
I love Rust and want to abide by Sel4, it seems that rust-embedded is now full of hackers just trying to make Rust work for their needs.
<bomb>
sneakernet[m] what do you _love_ about RUst, if I might to ask?
<sneakernet[m]>
the design of static analysis during computation that could be proofable
<sneakernet[m]>
s/computation/compilation/
<sneakernet[m]>
* @bomb the design of static analysis during compilation that could be proofable
<sneakernet[m]>
bomb: the design of static analysis during compilation that could be proofable
<sneakernet[m]>
I created firmware for esp32 (c++) but wanted to increase ability to create nodes by leveraging Rust
<bomb>
you want to invent the Skynet!?
<sneakernet[m]>
skynet is my real job
<sneakernet[m]>
this is a better net of real people
<sneakernet[m]>
does anyone use usenet anymore... that would be my next functionality (rather than just a distributed dropbox)
<sneakernet[m]>
<bomb> "you want to invent the Skynet!?" <- you want to deploy some SneakerNet nodes? I'll send you ready to plugin nodes
<sneakernet[m]>
* plugin nodes (PM me your mailing info)
<bomb>
no
<bomb>
I'm laser focused on BombNet at the moment
<sneakernet[m]>
tell me about BombNet
<bomb>
I won't tell you, but you'll hear about it.
<bomb>
loud and clear
<sneakernet[m]>
bomb: why is this an embedded topic?
<sneakernet[m]>
sneakernet[m]: anyway, I'm happy to support others that have a game-changing idea - and I'll sign an NDA to ensure that you get all the credit/royalties
<sneakernet[m]>
I just want to make comp-sci math again
<diondokter[m]>
<sneakernet[m]> "this is a naive understanding of..." <- Are you the person that left the youtube comment? I'm curious what you think is the best way. But you're only stating it's naive without any reason or insight as to why you think that is. What's an example where using traits to abstract over your hardware doesn't work? I'm curious to see what I missed
AdamHott[m] has joined #rust-embedded
<AdamHott[m]>
Telsa's have a fully autonomous "Elon" mode that some hardware hackers discovered that I saw in the news. This got me thinking, if I wanted to create a separate mode of operation for a board that was unlocked somehow, would I put the code for that in a different section of the linker configuration and then do something with the hardware to enable it like a solder bridge?
<AdamHott[m]>
I'm curious how this would work.
ryan-summers[m] has joined #rust-embedded
<ryan-summers[m]>
Why put it in a separate section? Its as simple as having a flag in firmware that just disallows something if the flag is set
<ryan-summers[m]>
I.e. it doesn't seem any different than any other setting that you'd write for firmware
<diondokter[m]>
AdamHott[m]: Could do it with a bootloader too where it detects something and then jumps to a different application
<diondokter[m]>
Also what Ryan said
<ryan-summers[m]>
You can make it as simple or as complex as you want, just depends on requirements
<ryan-summers[m]>
And how much you're trying to hide/obfuscate the setting
<AdamHott[m]>
What would be a basic example that I could try using just software with a backdoor to enable the alternative application?
<JamesMunns[m]>
The broad term for this is "feature enablement". Sometimes it's a single GPIO that gets soldered a different way, or a value to write to flash, or an encryption key, etc.. It doesn't even need to be a separate firmware, usually just a runtime check usually, unless you're really trying to hide it like Ryan said.
<AdamHott[m]>
That's probably not basic
<ryan-summers[m]>
Store your settings using sequential-storage, then you can manipulate the setting with a debug probe
<ryan-summers[m]>
* Store your settings using sequential-storage in flash, then you can manipulate the setting with a debug probe
<JamesMunns[m]>
This is often used when you have one firmware that works with multiple boards, like having a "basic, pro, premium" hardware setting
<AdamHott[m]>
ah that's cool
<ryan-summers[m]>
Is it cool, or is it companies sucking as much profit from you as they can? ;) It depends on whether or not the hardware is actually different between the different software versions too
<ryan-summers[m]>
Sometimes more premium features actually do require upgraded hardware
<ryan-summers[m]>
But other times its just a software vendor lock (Looking at BMWs premium heated seat feature)
<JamesMunns[m]>
ryan-summers[m]: heh, this is a fair take, tho I've worked at a company where we used the same hw for three products, and if we didn't all three would have been more expensive because of volume discounts
<JamesMunns[m]>
we did sell them at three price points, the lowest end one did have slightly cheaper hardware (basically some non-pop stuff), but it really would have made them all more expensive if we needed three boards and three firmwares.
<JamesMunns[m]>
(upgrading was a one time cost, not a subscription, tho)
<dirbaio[m]>
the price of something is not what it costs to make it
<dirbaio[m]>
it's what the buyer is willing to pay
<dirbaio[m]>
is it scam/unethical to use the same PCB in two different products at two different prices? idk, if the buyers of the expensive variant do get the value out of it, maybe not?
<JamesMunns[m]>
yeah, I'm a lot more tolerant of reselling at two price points than I am at subscription rent seeking
<ryan-summers[m]>
Yeah I'm not saying it's unethical, but it is a company trying to extract maximum profit. That's not necessarily a good/bad thing because there's always the possibility for competition to come along if it gets too out of hand
<JamesMunns[m]>
I mean ALL companies are trying to extract maximum profit
<JamesMunns[m]>
not saying that's good or anything
<JamesMunns[m]>
but it's kind of what companies do
<ryan-summers[m]>
Yeah that's the point of capitalism afterall. Anyways, I've got firmware to write
<bomb>
but Micirsoft givin away Githib for freee
<AdamHott[m]>
I think it has to be justifiable by the additional R&D costs put into a set of premium features. If there's actual extra cost involved with development, then you can justify a margin?
<dirbaio[m]>
price is higher because the customer is willing to pay more
<dirbaio[m]>
not because more r&d went into making it
<AdamHott[m]>
wouldn't extra features almost always require extra engineering effort though?
<JamesMunns[m]>
totally uncorrelated
<dirbaio[m]>
yeah but that doesn't "justify" the higher price
<dirbaio[m]>
as in, companies don't need to "justify" the price
<AdamHott[m]>
market competition and perceived value will dictate that, you're saying?
<dirbaio[m]>
company sets a price, customer decides whether the price is worth it
<dirbaio[m]>
and yep companies typically set the price to maximize profit
<dirbaio[m]>
the price that they think will maximize number_of_units_sold * margin_per_unit :P
<AdamHott[m]>
thanks for the input everyone, super interesting to chat about pricing products and market dynamics!
<dirbaio[m]>
what it costs to make (cost_per_unit + NRE/units_sold_expected) is just a floor
bomb has quit [Remote host closed the connection]
bomb has joined #rust-embedded
FreeKill[m] has quit [Quit: Idle timeout reached: 172800s]
lulf[m] has quit [Quit: Idle timeout reached: 172800s]
juliand[m] has quit [Quit: Idle timeout reached: 172800s]
JamesSizeland[m] has quit [Quit: Idle timeout reached: 172800s]
danielb[m] has quit [Quit: Idle timeout reached: 172800s]
timonsku[m] has quit [Quit: Idle timeout reached: 172800s]
feerless[m] has joined #rust-embedded
<feerless[m]>
Can someone help me read a datasheet?
<feerless[m]>
Is this the correct numbering for the pins?
<JamesMunns[m]>
when you hold it like that, facing you, I'd guess pin 1 is on your left, closest to button "1", pin 8 is on your right, closest to button "A"
<feerless[m]>
JamesMunns[m]: I added numbers to the picture but maybe they are too small to see.