06:26 <onkoe[m]> <jannic[m]> "Here is some explanation: https:..." <- thanks for the links! I’ve read through the issues but can’t seem to find a ‘replacement’ for my new library.

06:26 <onkoe[m]> would it suffice to just take a pin from the caller and hope they’re not wrong? does a DigitalPin work for this?

06:27 <onkoe[m]> s/a/an/, s/DigitalPin/OutputPin/

07:10 <korken89[m]> <sourcebox[m]> "korken89: After having a..." <- Ah that's a bit harder, but having a f32 only nice with that sounds fine as well :)

12:08 <jannic[m]> <onkoe[m]> "thanks for the links! I’ve..." <- > <@onkoe:matrix.org> thanks for the links! I’ve read through the issues but can’t seem to find a ‘replacement’ for my new library.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/MMmujtYFKUIOcypuzMyYBuPO>)

12:12 <jannic[m]> If you are writing a library that should be usable on different MCUs, you can define some ADC trait yourself, like the one suggested in the ticket:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/xYWZTqDSXkxecZjfgkkDjBpo>)

12:26 <Lumpio-> idk having that in e-h wouldn't hurt IMO

12:26 <Lumpio-> I know in a lot of cases it might not be enough just by itself

12:27 <Lumpio-> But would it hurt to have it

13:29 <JamesMunns[m]> I don't think the decision was "e-hal shouldn't have one", it was "nobody could agree what would cover all/most bases in a portable way"

13:29 <JamesMunns[m]> I'm sure that discussion will start again after 1.0 ships :D

13:30 <jannic[m]> It wouldn't add much, either. The old API was removed because it wasn't working well, and the ticket for adding a new one is still open because nobody considered it important enough to work on it pre-1.0.

13:30 <jannic[m]> And there are a lot of details to be defined: What does the result mean? Should the ADC value be scaled so that `0..u32::MAX` is the full range of possible values? What `Error` values can be returned? etc.

13:50 <Lumpio-> I think the error question should be solved exactly the same way as the other traits

13:52 <Lumpio-> If Arduino manages to have an analogRead having an equivalent wouldn't hurt even if it's not perfect!

14:20 <Lumpio-> Although, hm

14:21 <Lumpio-> What kind of abstract drivers would one build with an adc hmm

15:03 <firefrommoonligh> onkoe: What is your specific use case/project req?

16:12 <U007D[m]> Does anyone know if it's possible to specify the build target via cargo features?... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/VKANLqqkKaNjaQtnHCpyGieV>)

16:19 <firefrommoonligh> (My thought is this is a good question and I am curious what/if the answer is)

16:26 <dirbaio[m]> No, it's not possible. 

16:28 <U007D[m]> Aw, that’s too bad. But thank you—good to know.

16:29 <JamesMunns[m]> My suggestions here would be:

16:29 <JamesMunns[m]> * Use a tool like just or xtask to handle the details like this

16:29 <JamesMunns[m]> * Have separate, thin bin crates for each target, with the bulk of details in a shared lib

16:30 <U007D[m]> Thanks, @jamesmunns:beeper.com, good suggestions

16:43 <ChristianHeussy[> U007D: Here's an example that switches out logic based on target. Not sure if it's helpful but I found it interesting the first time I looked it over: https://github.com/Infineon/gpio-access-t2g-bodyentry-starterkit/tree/main/src

17:25 <U007D[m]> <ChristianHeussy[> "U007D: Here's an example that..." <- Yes, this is similar to what I am doing. The desire to set the target by specifying the target is improving developer ergonomics—no need to specify (and possibly mess up) redundant pieces of information. Not possible, sadly, so I’ll take James’ suggestion and codify the combinations of required features. ty!

18:02 <onkoe[m]> <firefrommoonligh> "onkoe: What is your specific use..." <- My apologies - I should have led with that! I’m developing a library for the LPPS-22 analog linear potentiometer. However, I’m not sure how to take its inputs without using a 0.3 channel.

18:03 <onkoe[m]> Since embedded-hal 1.0 doesn’t have the `adc` module, I don’t know if any crate retains this ADC functionality 😅

18:33 <firefrommoonligh> I looked it up. I would use a function that is a linear map between excitation voltage and motion range. Likely a one-liner fn body

18:37 <firefrommoonligh> For something that small, I would not use a lib, but your lib.rs would likely look like that

18:37 <firefrommoonligh> maybe with hard-set range_out values

18:37 <firefrommoonligh> * ```rust... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/VDcZTOunziUwAZKrfXYsbOnl>)

18:38 <firefrommoonligh> * For something that small, I would not use a lib, but if you go that route, your lib.rs would likely look like that.

18:38 <firefrommoonligh> * maybe with configurablerange_out and excitation_voltage values, vice fn params.

18:43 <firefrommoonligh> Obtaining voltage_read will be specific to the ADC used. Ie if it's one onboard MCU A, MCU B, an I2C one etc etc; not the role of the LPPS-22 lib. There is an interface here: the voltage reading, between ADC, and LPPS-22. LPPS-22 is only relevant to things downstream of this interface.

18:45 <firefrommoonligh> * Obtaining

18:45 <firefrommoonligh> voltage_read will be specific to the ADC used. Ie if it's one onboard MCU A, MCU B, an I2C one etc etc; not the role of the LPPS-22 lib. There is an interface here: the voltage reading, between ADC, and LPPS-22.

18:46 <firefrommoonligh> * /// Map output voltage of the LPPS-22 to output distance, in mm.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/VJMpslkqhBvRQgiaMIjdVGxm>)

18:46 <firefrommoonligh> * /// Map output voltage of the LPPS-22 to measured distance, in mm.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/GEYGxpKGfEDQPFLTxGiUDmQV>)

18:47 <firefrommoonligh> I would probably also include some sort of calibration

19:02 <firefrommoonligh> For your cal, you could adjust the input and output ranges, or if you want to get fancy, model as a polynomial to eliminate the slight non-linearity

20:49 <StephenD[m]> I asked about this a while ago but then my power went out and I got busy, so sorry for reviving this. But does anyone know anything about using dfu on linux with the zadig libusb driver? It just gives me permission issues

20:50 <StephenD[m]> I also tried dfu-buddy but it's saying it can't find the memory region. I am wondering if this is just the permissions issue bubbling up as something else though

20:53 <StephenD[m]> I'm open to changing to a different driver, just having trouble sourcing one

21:03 <jamwaffles[m]> Is there a way to see what the actual size of the image written to an MCU flash is? I can see the output of `cargo size -q --release -- -A` is e.g.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/KduSxgXxWsYZiMJihesARWNO>)

21:03 <jamwaffles[m]> s///, s/out/into flash/

21:12 <JamesMunns[m]> generally, it's:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/KvWfpDYGktAiXCWtlmBEbzvd>)

21:15 <JamesMunns[m]> s///, s/bin/binary/

21:17 <jamwaffles[m]> Hacky way is good way! I just want to see if some refactors are bloating the final image so I'm not looking for too much detail/accuracy. Thanks!

21:27 <adamgreig[m]> Or use -B instead of -A and then "dec" is everything written to flash iirc

21:27 <adamgreig[m]> (-B is also the default)

21:29 <JamesMunns[m]> I think dec includes ram

21:30 <JamesMunns[m]> I do think that by default `.text` includes "everything in flash"

21:30 <JamesMunns[m]> (e.g. .rodata and .vector_table get smooshed into that column)

21:41 <onkoe[m]> <firefrommoonligh> "For your cal, you could adjust..." <- Woah, thank you so much for the detail and assistance! 🥹

23:03 <StephenD[m]> <sourcebox[m]> "What are you trying to do? I'..." <- Where do you get the windows drivers for this?