00:15 <re_irc> <kelleyk> Rahix: Any chance that you're around? I wrote a simple MCP20137 driver for your "port-expander" crate earlier today.

00:16 <re_irc> <kelleyk> I need to expose the ability to enable the MCP20137's internal pull-ups, though, and I don't see any examples of that for the other chips that "port-expander" supports. Would love any thoughts you have on how to expose that so maximize the chances that you'll like the resulting PR. ;)

00:16 <re_irc> <kelleyk> * to

00:22 <re_irc> <kelleyk> James Munns: Be careful, that's what they want you to think: http://web.archive.org/web/20100708230258/http://people.csail.mit.edu/rahimi/helmet/

00:23 <re_irc> <kelleyk> (Jokes aside, "For all helmets, we noticed a 30 db amplification at 2.6 Ghz...")

00:23 <re_irc> <James Munns> I mean, the "connect it to ground" is a pretty important part :p

00:24 <re_irc> <James Munns> if you skip that step, a dome is pretty much a parabolic antenna :p

00:24 <re_irc> <James Munns> (you body is a high resistance path to ground, especially if you are going head to foot the long way :p)

00:25 <re_irc> <James Munns> * (your

05:05 <re_irc> <almindor> yatekii: No, I think the transport layer is agnostic in the spec. It's just that right now the crate works using "display-interface" and so far only SPI displays were tested.

05:08 <re_irc> <almindor> display-interface currently supports SPI and I2C but I don't have any I2C displays to test with (currently actualy no MCU either but that's besides the point :D)

06:12 <re_irc> <9names (@9names:matrix.org)> Are you sure? For a spec that is transport layer agnostic, it seems to talk a lot about the physical layer:

06:12 <re_irc> "Note that the electrical basis for DSI (SLVS) has two distinct modes of operation, each with its own set of electrical parameters.The PHY layer is described in MIPI Alliance Specification for D-PHY[4]."

06:12 <re_irc> Earlier in the spec they talk about earlier standards, specifically:

06:12 <re_irc> "DBI-2 specifies a parallel interface where data can be sent to the peripheral over an 8-, 9- or 16-bit-wide data bus, with additional control signals. DBI-2 supports a 1-bit data bus interface mode as well."

06:12 <re_irc> So maybe you're actually supporting MIPI DBI/DBI-2 controllers? Or screens that support the MIPI DCS but roll their own data transport formats?

06:19 <re_irc> <9names (@9names:matrix.org)> I haven't been able to find a copy of the DBI spec, but a quick good seems to imply that the standard SPI interface is "MIPI DBI Type C"

06:20 <re_irc> <9names (@9names:matrix.org)> * internet search

06:21 <re_irc> <9names (@9names:matrix.org)> example with some useful info about data formats for Type C:

06:21 <re_irc> https://github.com/notro/utinydrm/blob/91c20a522bc5d82abc62e7faec5aba22b438dbde/mipi-dbi.c#L70

14:43 <re_irc> <firefrommoonlight> What's y'alls go-to for arccos, arctan etc on no-std?

14:43 <re_irc> <firefrommoonlight> CMSIS-DSP, wrapped, can do sin and cos (and therefore tan, and their recips), but not sure how to handle the arc fns

14:48 <re_irc> <James Munns> Does libm or micromath have those maybe?

14:48 <re_irc> <James Munns> Looks like it: https://docs.rs/libm/0.2.1/libm/

14:49 <re_irc> <firefrommoonlight> Looks to be the case - https://docs.rs/micromath/latest/micromath/trait.F32Ext.html#tymethod.acos

14:49 <re_irc> <firefrommoonlight> Which of the 2 do you recommend?

14:50 <re_irc> <James Munns> https://docs.rs/micromath/latest/micromath/trait.F32Ext.html

14:50 <re_irc> <James Munns> I think libm is strictly more accurate, but often larger/slower

14:50 <re_irc> <James Munns> Micromath is a reasonable approximation, which is probably fine if you're not doing orbital mechanics or something

14:50 <re_irc> <firefrommoonlight> Thanks!

14:51 <re_irc> <James Munns> I think it discusses it's worst case error in the docs somewhere

14:51 <re_irc> <firefrommoonlight> Haha oh boy

14:51 <re_irc> <firefrommoonlight> Now micromath and num_traits are fighting :(

14:51 <re_irc> <firefrommoonlight> over who owns abs, powi etc

14:52 <re_irc> <James Munns> <f32 as micromath::F32Ext>::abs(x)

14:52 <re_irc> <James Munns> Or something like that

14:53 <re_irc> <firefrommoonlight> Good call!

14:54 <re_irc> <James Munns> https://doc.rust-lang.org/book/ch19-03-advanced-traits.html#fully-qualified-syntax-for-disambiguation-calling-methods-with-the-same-name

14:56 <re_irc> <firefrommoonlight> Perf - thank you!

15:24 <re_irc> <kelleyk> I had a related question the other evening--is there a good pattern for precomputing lookup tables (via codegen/embedding, at compile time through Rust magic, whatever)?

15:24 <re_irc> <kelleyk> I was playing with micromath and realized that a 512-element lookup table would do the job just as well.

15:25 <re_irc> <kelleyk> (Precompute the expensive math once instead of dealing with on-device approximations, basically.)

15:29 <re_irc> <kelleyk> This seems like a reasonable example: https://github.com/eldruin/embedded-crc-macros-rs/blob/master/src/lib.rs

15:31 <re_irc> <thejpster> Does anyone have an Elkhart Lake? Intel released the source for the Programmable Services Engine, which is a Cortex-M7.

15:31 <re_irc> <thejpster> https://github.com/intel/pse-fw

15:31 <re_irc> <thejpster> Would be fun to see it Rewritten In Rust.

15:41 <re_irc> <James Munns> kelleyk: You could calculate with a build.rs, and just create a consts.rs file

15:42 <re_irc> <James Munns> Depending on what you need to calc, you might be able to use a const function, which would be even better

15:49 <re_irc> <kelleyk> In that particular situation, it was converting an ADC measurement to a reading for a thermocouple, so just a few log/exp/multiply type operations; but since the input range is so limited, I thought of the lookup table option.

15:49 <re_irc> <kelleyk> And thanks for the suggestion with build.rs!

16:08 <re_irc> <thejpster> Monotron used a 64 KiB lookup table (32 bit x 8 x 3 x 3). Flash is cheap and maths is expensive.

16:08 <re_irc> <thejpster> Elkhart Lake board: https://www.ibase.com.tw/en/product/category/Embedded_Computing/Single_Board_Computer/3_5_Single_Board_Computer/IB836

17:37 <re_irc> <newam> Wow "cargo-fuzz" is fast.

17:37 <re_irc> I hooked it up to a "read" SPI trait for an Ethernet chip and managed to navigate the entire DHCP state machine in seconds.

17:37 <re_irc> <newam> +it

21:43 <re_irc> <riskable> Yay! I got my "Config.toml"-to-const code working with strings! Haha that was _really friggin hard_!

21:46 <re_irc> <riskable> My "add_const_gen!" macro will take a struct like:

21:46 <re_irc> #[derive(Debug, Serialize, Deserialize)]

21:46 <re_irc> add_const_gen! {

21:46 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/106fc5f3647ae6b59e3175aca93d6c47343147a10fe132006900fecda2ce236d (29 lines)

21:46 <re_irc> pub struct HardwareConfig {

21:48 <re_irc> <riskable> This allows one to figure out the type of each field when you read in something like a "Config.toml" to generate the correct "const <whatever>" values in something like a "config.rs" that is nothing more than this:

21:48 <re_irc> include!(concat!(env!("OUT_DIR"), "/userconfig.rs"));

21:48 <re_irc> use core::include;

21:50 <re_irc> <riskable> In my "build.rs" I have:

21:50 <re_irc> let out_dir = env::var_os("OUT_DIR").unwrap();

21:50 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/990db7f3b9bc25ae2ba3d7294e9eea653731bf1f5967e114e9807404b0201224 (9 lines)

21:50 <re_irc> let mut out = String::new();

21:50 <re_irc> let dest_path = Path::new(&out_dir).join("userconfig.rs");

22:00 <re_irc> <riskable> And for everyone's reference, here's the files that make this process happen in all their glory:

22:00 <re_irc> - "build.rs": https://gist.github.com/riskable/829f3f544a827a56da64957f52d46c1f

22:00 <re_irc> - "config_struct.rs": https://gist.github.com/riskable/2621da7110e30f407437030c00f7857c

22:00 <re_irc> - "config.rs": https://gist.github.com/riskable/3c2493723e60c5deebe32f15edfea35d

22:06 <re_irc> <riskable> What's the benefit of doing it this way instead of just telling the end user to edit a bunch of "const" lines in a "config.rs" file? It lets the end user add and edit numeric fields like a "u16" without having to know that it needs to be a "u16" (LOL). It also gives you the flexibility to perform a "translate" step where the end user can use things like advanced syntax (e.g. wildcards/repeat expressions) that would be...

22:06 <re_irc> ... a huge pain in the ass to write into a "correct" Rust-specific type 👍

22:09 <re_irc> <riskable> Of course, it also makes it easier to convert things that are of indeterminate length (e.g. keyboard macros) into "const" things so you don't need an allocator

23:41 <re_irc> <adamgreig> does anyone have an example of a driver that uses embedded hal SPI/I2C and GPIO, and so can return an error that's generic over the HAL SPI/I2C and GPIO errors?

23:41 <re_irc> <adamgreig> (like, SPI/I2C for comms, but GPIO to control a couple extra pins, reset/mode sort of thing)

23:56 <re_irc> <GrantM11235> "ExclusiveDevice" takes a generic spi bus and a generic OutputPin chipselect https://github.com/rust-embedded/embedded-hal/blob/dd7bd7f3fb727de9bb3fe4e6b081213d65549ef5/src/spi/blocking.rs#L351-L422