ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
<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
<KevinLy[m]> I'm just trying to read analog data (from potentiometer) through the ADC of an STM32F303 (on the discovery board).... (full message at <>)
<KevinLy[m]> * I'm just trying to read analog data (from potentiometer) through the ADC of an STM32F303 (on the discovery board).... (full message at <>)
<KevinLy[m]> * (Sorry, I don't know how to format this message with line breaks)... (full message at <>)
<bomb> sneakernet[m] good answer :)
<sneakernet[m]> KevinLy[m]: > <> (Sorry, I don't know how to format this message with line breaks)... (full message at <>)
<sneakernet[m]> bomb: is Rust going to get there, or will the current insanity require a fork?
<bomb> no idea, I'm very new to Rust
<sneakernet[m]> I'm always looking to prove my math via Sel4 standards to create yet another toolchain
<sneakernet[m]> @bomb wanna make one of these
<sneakernet[m]> * another toolchain /s
<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
<bomb> sneakernet[m] this is why
<sneakernet[m]> <bomb> "sneakernet this is why https://..." <- are you designing a np-hard trigger?
<Kaspar[m]> <sneakernet[m]> "ouch, so much specialization..." <- Actually the pacs don't need patching anymore - I'll PR dropping those lines now.
TimSmall[m] has joined #rust-embedded
<TimSmall[m]> <KevinLy[m]> "I'm just trying to read analog..." <- > <> (Sorry, I don't know how to format this message with line breaks)... (full message at <>)
<JamesMunns[m]> TimSmall[m]: > <> Kevin Ly: You can use markdown syntax to format code blocks in Matrix chat messages.... (full message at <>)
mali[m] has joined #rust-embedded
<mali[m]> Is it still a go-to crate for bitfields, or is there a better alternative in recent years?
<mali[m]> Hi, I had used modular-bitfield crate for a device driver.
<mali[m]> It seems a bit dated, but maybe cause it just works.
<JomerDev[m]> I played with recently but that is more for bitfields in registers
GregBodnar[m] has quit [Quit: Idle timeout reached: 172800s]
M9names[m] has quit [Quit: Idle timeout reached: 172800s]
crabbedhaloablut has quit []
crabbedhaloablut has joined #rust-embedded
ChristianHeussy[ has joined #rust-embedded
<ChristianHeussy[> <JomerDev[m]> "I played with"; <- Take a look at deku:
<ChristianHeussy[> <mali[m]> "Hi, I had used modular-bitfield..." <- > <> Hi, I had used modular-bitfield crate for a device driver.
<ChristianHeussy[> Take a look at deku:
<ChristianHeussy[> > Is it still a go-to crate for bitfields, or is there a better alternative in recent years?
RobertJrdens[m] has joined #rust-embedded
<RobertJrdens[m]> I found bitbybit the nicest when I compared a couple of crates. See e.g.
<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]> I don't understand which pin is which number
GrantM11235[m] has quit [Quit: Idle timeout reached: 172800s]
<feerless[m]> which of these is it?
<dirbaio[m]> it's a typical keyboard matrix
<dirbaio[m]> you have to "scan" it to read it
<feerless[m]> so if bits 1 and 5 are set then I know button 1 was pressed? and so on?
<feerless[m]> Also that still doesn't answer the original question
bomb has quit [Quit: 💣]
<dirbaio[m]> no
<dirbaio[m]> you have to actively scan it. for example something like... (full message at <>)
<feerless[m]> what is opendrain output? Is that a strong 0?
<JamesMunns[m]> open drain means:
<JamesMunns[m]> "high" voltage is open circuit
<JamesMunns[m]> "low" voltage is connected to ground
<JamesMunns[m]> its something most (but not all) chips support
<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.
jannic[m] has joined #rust-embedded
<jannic[m]> Or use which seems to solve exactly this problem.
<JamesMunns[m]> ah, yes, I think your tiny numbers match what I would guess, but I don't know for sure.
<JamesMunns[m]> Do you have a multimeter? you could check it very quickly if you have that.
<feerless[m]> I do have a multimeter
<JamesMunns[m]> Does it have continuity/"beep" mode?
<JamesMunns[m]> If yes: put it in that mode, then put your probes on pin 1 + 8, the far outside pins. press button "4", and tell me if it beeps
<JamesMunns[m]> If not, keep pressing buttons until one of them makes it beep, and tell me which one.
<JamesMunns[m]> (one button at a time)
<feerless[m]> okay, give me a sec
<JamesMunns[m]> (I think either "4" or "A" will make it beep, not sure how they count though)
<feerless[m]> with the probes on the outermost pins (1 & 8) and pressing button 4 ("A") the loop is closed
<JamesMunns[m]> Nice!
<JamesMunns[m]> Okay, now put the probes on the two leftmost pins you labeled 1 and 2
<JamesMunns[m]> then see which button closes the lopp
<JamesMunns[m]> s/lopp/loop/
<JamesMunns[m]> ah no sorry hold on
<JamesMunns[m]> do the one you think is 1 and 7
<JamesMunns[m]> so come in on the right side one, but not on the left side
<JamesMunns[m]> does pressing button "3" close the loop?
<JamesMunns[m]> or does button "B" close the loop?
<feerless[m]> loop is open
<feerless[m]> for all button on pin 1 & 2
<feerless[m]> which makes sense
<JamesMunns[m]> yeah sorry, try 1 and 7
<JamesMunns[m]> I read the page wrong to start, yeah
<feerless[m]> no button corresponds to 1 & 2
<feerless[m]> button 3 closes the loop for pins 1 & 7
<JamesMunns[m]> cool! so your labels were right!
<feerless[m]> So I guess the layout is 1 to 8 from left to right when viewed from the top down.
<feerless[m]> thank you James Munns
<feerless[m]> that is a neat way to determine the pin numbering
<JamesMunns[m]> yep! Notice in the other diagram where it looks backwards, they are looking at the back of the board
<feerless[m]> Still wish the datasheet were a bit better
<JamesMunns[m]> so it makes sense when you flip it and look at the front of the board, the numbers are "backwards"
<JamesMunns[m]> feerless[m]: unfortunately we all do very often.
<JamesMunns[m]> that's why it's good to learn how to verify manually whenever you can!
AtleoS has quit [Ping timeout: 268 seconds]
AtleoS has joined #rust-embedded
crabbedhaloablut has quit []
crabbedhaloablut has joined #rust-embedded
sourcebox[m] has quit [Quit: Idle timeout reached: 172800s]
dygear[m] has joined #rust-embedded
<dygear[m]> jamesmunns Seems like there is a lot of that goin' around.
<dirbaio[m]> that's a quite gratuitous ping
<dygear[m]> We were talking in another server about pins not being numbered correctly.
<whitequark[cis]> the best labels in the datasheets i've seen for chips are "dead bug view" and "live bug view"
<whitequark[cis]> completely unambiguous, if a little morbid
<barnabyw[m]> “dorsal” and “ventral” are would work too
<barnabyw[m]> s/are//
<barnabyw[m]> e.g. that one amplifier chip has a dorsal bolt