ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
<re_irc> <kelleyk> Rahix: Any chance that you're around? I wrote a simple MCP20137 driver for your "port-expander" crate earlier today.
<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. ;)
<re_irc> <kelleyk> * to
<re_irc> <kelleyk> James Munns: Be careful, that's what they want you to think:
<re_irc> <kelleyk> (Jokes aside, "For all helmets, we noticed a 30 db amplification at 2.6 Ghz...")
<re_irc> <James Munns> I mean, the "connect it to ground" is a pretty important part :p
<re_irc> <James Munns> if you skip that step, a dome is pretty much a parabolic antenna :p
<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)
<re_irc> <James Munns> * (your
emerent has quit [Ping timeout: 240 seconds]
emerent has joined #rust-embedded
explore has joined #rust-embedded
starblue has quit [Ping timeout: 248 seconds]
starblue has joined #rust-embedded
fabic_ has joined #rust-embedded
<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.
<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)
_whitelogger has joined #rust-embedded
<re_irc> <9names (> Are you sure? For a spec that is transport layer agnostic, it seems to talk a lot about the physical layer:
<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]."
<re_irc> Earlier in the spec they talk about earlier standards, specifically:
<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."
<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?
<re_irc> <9names (> 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"
<re_irc> <9names (> * internet search
<re_irc> <9names (> example with some useful info about data formats for Type C:
explore has quit [Quit: Connection closed for inactivity]
fabic_ has quit [Ping timeout: 240 seconds]
fabic_ has joined #rust-embedded
<re_irc> <firefrommoonlight> What's y'alls go-to for arccos, arctan etc on no-std?
<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
<re_irc> <James Munns> Does libm or micromath have those maybe?
<re_irc> <James Munns> Looks like it:
<re_irc> <firefrommoonlight> Looks to be the case -
<re_irc> <firefrommoonlight> Which of the 2 do you recommend?
<re_irc> <James Munns> I think libm is strictly more accurate, but often larger/slower
<re_irc> <James Munns> Micromath is a reasonable approximation, which is probably fine if you're not doing orbital mechanics or something
<re_irc> <firefrommoonlight> Thanks!
<re_irc> <James Munns> I think it discusses it's worst case error in the docs somewhere
<re_irc> <firefrommoonlight> Haha oh boy
<re_irc> <firefrommoonlight> Now micromath and num_traits are fighting :(
<re_irc> <firefrommoonlight> over who owns abs, powi etc
<re_irc> <James Munns> <f32 as micromath::F32Ext>::abs(x)
<re_irc> <James Munns> Or something like that
<re_irc> <firefrommoonlight> Good call!
<re_irc> <firefrommoonlight> Perf - thank you!
fabic_ has quit [Ping timeout: 272 seconds]
<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)?
<re_irc> <kelleyk> I was playing with micromath and realized that a 512-element lookup table would do the job just as well.
<re_irc> <kelleyk> (Precompute the expensive math once instead of dealing with on-device approximations, basically.)
fabic_ has joined #rust-embedded
<re_irc> <kelleyk> This seems like a reasonable example:
<re_irc> <thejpster> Does anyone have an Elkhart Lake? Intel released the source for the Programmable Services Engine, which is a Cortex-M7.
<re_irc> <thejpster>
<re_irc> <thejpster> Would be fun to see it Rewritten In Rust.
<re_irc> <James Munns> kelleyk: You could calculate with a, and just create a file
<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
<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.
<re_irc> <kelleyk> And thanks for the suggestion with!
<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.
fabic_ has quit [Ping timeout: 240 seconds]
starblue has quit [Ping timeout: 246 seconds]
starblue has joined #rust-embedded
fabic_ has joined #rust-embedded
<re_irc> <newam> Wow "cargo-fuzz" is fast.
<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.
<re_irc> <newam> +it
fabic_ has quit [Ping timeout: 246 seconds]
bpye has quit [Ping timeout: 246 seconds]
bpye has joined #rust-embedded
bpye2 has joined #rust-embedded
bpye has quit [Ping timeout: 276 seconds]
bpye2 is now known as bpye
vancz has quit []
vancz has joined #rust-embedded
bpye has quit [Ping timeout: 276 seconds]
bpye has joined #rust-embedded
bpye4 has joined #rust-embedded
bpye has quit [Ping timeout: 256 seconds]
bpye4 is now known as bpye
<re_irc> <riskable> Yay! I got my "Config.toml"-to-const code working with strings! Haha that was _really friggin hard_!
<re_irc> <riskable> My "add_const_gen!" macro will take a struct like:
<re_irc> #[derive(Debug, Serialize, Deserialize)]
<re_irc> add_const_gen! {
<re_irc> pub struct HardwareConfig {
<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 "" that is nothing more than this:
<re_irc> include!(concat!(env!("OUT_DIR"), "/"));
<re_irc> use core::include;
<re_irc> <riskable> In my "" I have:
<re_irc> let out_dir = env::var_os("OUT_DIR").unwrap();
<re_irc> let mut out = String::new();
<re_irc> let dest_path = Path::new(&out_dir).join("");
<re_irc> <riskable> And for everyone's reference, here's the files that make this process happen in all their glory:
<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 "" 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...
<re_irc> ... a huge pain in the ass to write into a "correct" Rust-specific type 👍
<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
<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?
<re_irc> <adamgreig> (like, SPI/I2C for comms, but GPIO to control a couple extra pins, reset/mode sort of thing)
<re_irc> <GrantM11235> "ExclusiveDevice" takes a generic spi bus and a generic OutputPin chipselect