sauce has quit [Remote host closed the connection]
sauce has joined #rust-embedded
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #rust-embedded
m5zs7k has quit [Ping timeout: 268 seconds]
m5zs7k has joined #rust-embedded
cr1901 has quit [Read error: Connection reset by peer]
m5zs7k has quit [Ping timeout: 252 seconds]
cr1901 has joined #rust-embedded
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
m5zs7k has joined #rust-embedded
cr1901 has joined #rust-embedded
<re_irc>
< (@firefrommoonlight:matrix.org)> : Thank you for all your hard work on this project. It has helped me immensely
<re_irc>
<Félix the Newbie> I have a split keyboard with a stm32 in the master part, and the slave (right) part is connected through a jack (TRRS). How can I matrix scan the right part? IIUC, I must open an USART connection, something like "let serial = serial::Serial::usart1(c.device.USART1, pins, CLOCK.bps(), &mut rcc);" but then I'm not sure how to access the pins on the right part?
<re_irc>
< (@k900:0upti.me)> You don't do that directly
<re_irc>
< (@k900:0upti.me)> There's probably some piece of hardware on the other side that you need to talk to
<re_irc>
< (@k900:0upti.me)> How exactly will depend on what hardware it is
<re_irc>
<Félix the Newbie> Hm, let me have a look at the spec
<re_irc>
<FredrikLL> I thought it was usually through I2C
<re_irc>
< (@k900:0upti.me)> It's probably some sort of I/O expander thingy
<re_irc>
<Félix the Newbie> FredrikLL: It's a guess, I'm not sure either
<re_irc>
< (@k900:0upti.me)> Could be serial, could be I2C or SPI
<re_irc>
< (@k900:0upti.me)> Could be something fancy like 1wire but unlikely
<re_irc>
<FredrikLL> I’m not sure either, just have a vague memory of it
<re_irc>
<Félix the Newbie> Oh, indeed, I think it's a i2c port extender. So IIUC, I have nothing special to do: once it's set up, I can use new pins like they're normal ones?
<re_irc>
< (@k900:0upti.me)> No]
<re_irc>
< (@k900:0upti.me)> * No\
<re_irc>
< (@k900:0upti.me)> * No
<re_irc>
< (@k900:0upti.me)> Not at all
<re_irc>
< (@k900:0upti.me)> You need to talk to it over its own protocol
<re_irc>
< (@k900:0upti.me)> Maybe look for a crate for it
<re_irc>
<Félix the Newbie> And through this protocol, I can say: “set this pin to this state” etc. ok, I got it. I'll use a battery-included crate for that.
<re_irc>
< (@k900:0upti.me)> Assuming there is one
jcroisant has quit [Quit: Connection closed for inactivity]
IlPalazzo-ojiisa has joined #rust-embedded
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #rust-embedded
<re_irc>
<paologentili> Hi, I'm working on my first embedded project in Rust and I'd like to separate the hardware code from the logic code. I've created a hw module with a Hardware public struct with all the peripherals, gpio, etc that I actually need to use. This struct implements a _new_ pub function which gets called in main.rs. How can I enforce this function to actually work only the first time? It sounds like this...
<re_irc>
< (@ryan-summers:matrix.org)> Generally, you can enforce single instantiation like that through simple ownership, and don't need to explicitly declare it as a singleton
<re_irc>
< (@ryan-summers:matrix.org)> Single the peripherals are already a singleton, once you move out of that into your struct, it's no longer possible to make a second
<re_irc>
< (@ryan-summers:matrix.org)> * Since
<re_irc>
< (@ryan-summers:matrix.org)> Also w.r.t the static Mut, check out frameworks like embassy and RTIC that handle the resource mutexing and management. It's almost always very unsafe code that is easy to get wrong
<re_irc>
<pgentili> : Oh, very good point.
<re_irc>
<pgentili> : I'll check out those frameworks for sure but for now I'd like to try and learn without them. Thanks!
<re_irc>
< (@ryan-summers:matrix.org)> Just beware about concurrent access from multiple priority levels. If you have that, your resources must have mutexes
<re_irc>
<olsen__> Hi folks, is there any support for an arm cortex-r52 on its way?
<re_irc>
< (@k900:0upti.me)> R52 is just a core
<re_irc>
< (@k900:0upti.me)> HAL support needs to be done for a specific SoC
<re_irc>
< (@k900:0upti.me)> The core itself is just aarch32 which is already supported
<re_irc>
< (@adamgreig:matrix.org)> more practically, there's very little support or (public) use of cortex-r, so you'd have to do a lot yourself, there is https://github.com/rust-embedded/cortex-r and I thought I'd seen another project but can't find it now...
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded
dc740 has joined #rust-embedded
madb has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
dc740 has joined #rust-embedded
<re_irc>
<fasterthanlime> 👋 hello hello
<re_irc>
<fasterthanlime> playing around with the rust-embedded discovery book for microbit - I like GDB's TUI as much as the next person, but what is everyone using in terms of VSCode debug integration? I was going to go Native Debug + GDB MI, but I've fallen down this rabbit hole: https://probe.rs/docs/tools/vscode/#installation (currently building the vscode extension from source since.. there's no Releases afaict?)
<re_irc>
<Félix the Newbie> No debug, Rust is so powerful there is no crash.
<re_irc>
<dngrs (spookyvision@{github,cohost})> Last time I used a debugger for embedded I was happy with CodeLLDB, but logging is often more useful because you don't want to/can't "stop" embedded code (your motor would stop turning, etc)
<re_irc>
< (@adamgreig:matrix.org)> I think the probe-rs vscode integration is the way to go, it gets a lot of work and love
<re_irc>
<fasterthanlime> : huh, I clearly need more coffee
<re_irc>
< (@k900:0upti.me)> Big same tbh
<re_irc>
< (@adamgreig:matrix.org)> (that said, probe-rs also supports "RTT" which is basically printf style debugging using the debug probe, which doesn't need to stop execution of the firmware and is generally pretty low impact, especially combined with "defmt" which does the actual string formatting on the host and just sends the raw values over the wire)
<re_irc>
< (@adamgreig:matrix.org)> (but, I think the vscode integration lets you view those outputs in vscode anyway? so it's probably still the way to go...)
<re_irc>
<fasterthanlime> seems to work okay! it lets me step through code / set breakpoints visually, which is nice
<re_irc>
<fasterthanlime> it says something about "RUST_LOG", not sure _where_ that would be set in the embedded world, but I guess I can find out later. I've heard good things about defmt!
<re_irc>
< (@k900:0upti.me)> That's for the runner itself
<re_irc>
< (@k900:0upti.me)> (the RUST_LOG bit that is)
<re_irc>
<dngrs (spookyvision@{github,cohost})> : Important point there too, lots of example code uses logging over semihosting instead and that is _very_ slow (which will in turn mess up hardware timings). I think It's mainly used because less intrusive to set up compared to RTT/defmt
<re_irc>
< (@adamgreig:matrix.org)> I think in part just because logging over semihosting existed first, and rtt/defmt came somewhat later, and people coming from C are maybe more familiar with semihosting because rtt was mostly a proprietary extension there? for rust stuff there's only specialist uses for semihosting really, mostly in emulation
<re_irc>
< (@adamgreig:matrix.org)> emulation, and having your embedded firmware read and write files on the host disk 😬
<re_irc>
< (@yatekii:matrix.org)> OMG the famous fasterthanlime is using probe-rs :D
<re_irc>
<dngrs (spookyvision@{github,cohost})> Mhm I keep seeing it in hal examples
<re_irc>
<fasterthanlime> so RTT is real-time terminal / real-time transfer, right? I think I understand the "your program has whole ownership of the core, there's zero safety net, you can't have libstd, good luck" part, but I don't understand the "you have micro-usb and can flash with a standard protocol and get a nice terminal" bit
<re_irc>
<fasterthanlime> I guess that's what the smaller chip on the micro:bit bbc v1 is about
<re_irc>
< (@k900:0upti.me)> Most dev boards have two chips, one that runs your actual code and one that provides some sort of debugging interface
<re_irc>
< (@k900:0upti.me)> Sometimes they're the same chip
<re_irc>
< (@yatekii:matrix.org)> fasterthanlime: yes, correct :) You need a debug probe that kind of is a protocol translator between microchip and PC. That's where probe-rs and co come in :)
<re_irc>
< (@k900:0upti.me)> In production you might not have a debug cihp
<re_irc>
< (@k900:0upti.me)> * chip
<re_irc>
<fasterthanlime> "cargo embed" says something about a GDB stub, it's.. a program running on my computer that speaks GDB MI and translates that to.. USB stuff? The Cortex-Debug vscode extension had a _lot_ of specifics about "which OCD (on-chip debugger) to use", the discovery book goes through none of that, so I'm assuming probe-rs is its own thing
<re_irc>
< (@k900:0upti.me)> The debug chip protocol is usually something custom
<re_irc>
< (@k900:0upti.me)> probe-rs speaks a bunch of them
<re_irc>
<fasterthanlime> so the "probe-rs" project is 10% "cargo-embed" (which is "invoke cargo build the right way + flashing") and 90% "probe-rs" which is abstracting over.. different debug cores?
<re_irc>
< (@k900:0upti.me)> And can generally figure out which one to use automatically
emerent has quit [Ping timeout: 252 seconds]
<re_irc>
< (@k900:0upti.me)> Flashing is also probe-rs mostly
<re_irc>
< (@yatekii:matrix.org)> fasterthanlime: yes :) there is other tools than cargo-embed, but yes :)
<re_irc>
< (@adamgreig:matrix.org)> probe-rs handles talking to the debug probe, understanding the architecture of the cpu you're debugging, and knowing how to write the flash memory on your particular chip, among a few other things
<re_irc>
< (@k900:0upti.me)> cargo-embed is basically "call cargo with the right flags then shove the result into probe-rs and pray"
emerent has joined #rust-embedded
<re_irc>
<fasterthanlime> does it also take care of linker scripts?
<re_irc>
<fasterthanlime> like, the ELF file needs to have the right things in the right place and stuff?
<re_irc>
< (@adamgreig:matrix.org)> nope, that's done by the cortex-m-rt crate for cortex-m microcontrollers like on the microbit
<re_irc>
< (@yatekii:matrix.org)> fasterthanlime: nope, that's still standard rust procedure :)
<re_irc>
< (@adamgreig:matrix.org)> which the microbit crate depends on for you
<re_irc>
<fasterthanlime> mhhh so I've looked at what "cortex-m-rt"'s "entry" proc macro does and it seems to mostly make an "extern "C"" function whose export name is "main"
<re_irc>
<fasterthanlime> I'm suspicious of crate dependencies being able to set a linker script for the final executable but I also know nothing yet, so
<re_irc>
< (@k900:0upti.me)> fasterthanlime: Build scripts are fun
<re_irc>
< (@adamgreig:matrix.org)> which is what finally calls your extern C main
<re_irc>
< (@adamgreig:matrix.org)> so the cortex-m-rt crate has a link script, but it doesn't setit for your final executable - that's done by your project having a ".cargo/config.toml" that sets a "-Tlink.x" flag
<re_irc>
<fasterthanlime> : ahhh that's what I was about. is "link.x" generated by cortex-m-rt's build script?
<re_irc>
< (@adamgreig:matrix.org)> in principle you could put any linker script you want there, including a custom one of your own, cortex-m-rt is just providing one that works for most use cases and you can easily use with the flag
<re_irc>
<fasterthanlime> from "link.x.in" ?
<re_irc>
< (@adamgreig:matrix.org)> yes, exactly
<re_irc>
<fasterthanlime> ok cool, things make sense. thanks everyone
<re_irc>
<fasterthanlime> > // _IMPORTANT_: The weak aliases (i.e. "PROVIDED") must come _after_ "EXTERN(__INTERRUPTS)".
<re_irc>
> // Otherwise the linker will ignore user defined interrupts and always populate the table
<re_irc>
sobbing at linkers right now
<re_irc>
> // with the weak aliases.
<re_irc>
< (@adamgreig:matrix.org)> wait til you get to the bottom 😄 "/* Do not exceed this mark in the error messages below | */"
<re_irc>
<dngrs (spookyvision@{github,cohost})> fasterthanlime: That sobbing will never stop ✨
<re_irc>
<fasterthanlime> ok I'm going through Noah's video - so probe-rs has a protocol that isn't GDB-related at all? (and then the GDB stub does the translation?) and presumably the vscode extension doesn't have anything GDB-related
<re_irc>
<fasterthanlime> as opposed to most OCDs which are GDB-based?
<re_irc>
< (@yatekii:matrix.org)> I already see a blogpost on how on fire embedded is :D :D :D
<re_irc>
< (@adamgreig:matrix.org)> "OCD" is a sort of overloaded/non-standard term here
<re_irc>
< (@adamgreig:matrix.org)> but no, most debug probes don't speak gdb at all, pretty much the only one that does is the black magic probe
<re_irc>
<fasterthanlime> : haha I'm very burned out at the moment and hating anything I write so this is me trying something different (also I've had the micro:bit forever, needed to take it out at some point)
<re_irc>
< (@k900:0upti.me)> probe-rs can speak GDB but it can also speak the VSCode debugger protocol directly
<re_irc>
< (@k900:0upti.me)> Very few things actually speak GDB in hardware
<re_irc>
< (@adamgreig:matrix.org)> the popular ones are cmsis-dap (an ARM standard), stlink (an ST proprietary standard), jlink (another standard by j-link who make fancy debug probes), some others
<re_irc>
< (@adamgreig:matrix.org)> generally those USB protocols all wrap "send these SWD commands to the target", where SWD is a two-wire protocol that goes between the probe and the target
<re_irc>
< (@adamgreig:matrix.org)> in probe-rs, gdb is at the top layer as a way for gdb to tell probe-rs "please insert a breakpoint here" or "please read this memory address"
<re_irc>
<fasterthanlime> ok so the micro:bit board comes with a debug probe directly but if I was messing with a chip directly I'd need to have the right debug probe for it, the video has a photo of what I imagine is a fancy j-link probe?
<re_irc>
< (@yatekii:matrix.org)> fasterthanlime: phew :P I hope you get better :) Embedded is a bit daunting at first :D
<re_irc>
< (@k900:0upti.me)> fasterthanlime: Pretty much most debug probes actually speak SWD
<re_irc>
< (@adamgreig:matrix.org)> in openocd, which is commonly used instead of probe-rs outside of rust dev, the situation is basically the same - openocd knows how to talk stlink, cmsis-dap, jlink, etc, and it knows how to flash targets and read their memory, and it exposes gdb at the top
<re_irc>
< (@k900:0upti.me)> To the chip that is
<re_irc>
< (@adamgreig:matrix.org)> yea, the microbit has two CPUs on it, one of them is running debug probe firmware and is connected to the one that runs your code
<re_irc>
< (@adamgreig:matrix.org)> generally most debug probes are compatible with most MCUs that talk the same protocol (like SWD or JTAG)
<re_irc>
< (@adamgreig:matrix.org)> with some exceptions, like stlinkv3 is vendor locked to only work on stm32 microcontrollers
<re_irc>
<fasterthanlime> : that also means it should be relatively hard to brick? like even if the code I flash to the nrf51 actually tries to return from main or whatever, I can always flash something else with the other chip?
<re_irc>
< (@k900:0upti.me)> So you have [chip with your code] <--SWD--> [debug probe] <--vendor protocol over USB--> [debug server on your machine] <--GDB/DAP--> [your IDE]
<re_irc>
< (@adamgreig:matrix.org)> yea, it's essentially impossible to brick when you have a debug probe attached
<re_irc>
< (@k900:0upti.me)> fasterthanlime: Yes
<re_irc>
<fasterthanlime> ok that's cool
<re_irc>
< (@adamgreig:matrix.org)> often the chip has some magic registers that let you lock it out from further debug access, to protect your software before sending it to users, and that's the main danger
<re_irc>
< (@adamgreig:matrix.org)> but those are very hard to activate by mistake
<re_irc>
< (@adamgreig:matrix.org)> (and in some cases, they can be overridden at the cost of wiping the flash memory)
<re_irc>
<fasterthanlime> completely unrelated, the micro:bit safety manual says only use alkaline batteries, don't use li-ion/ni-mh unless you've made _really sure_ they don't go over 1.5v, is that a little paranoid or is there a real risk of ruining the board with some rechargeable batteries having a little overzealous voltage?
<re_irc>
<fasterthanlime> +or zinc-carbon
<re_irc>
<fasterthanlime> : > GDB/MI is a line based machine oriented text interface to GDB
<re_irc>
> that sounds awful, of course the industry standardized around that lol
<re_irc>
< (@k900:0upti.me)> fasterthanlime: Realistically very unlikely you'll kill it unless something is VERY wrong with the board design, but you'll have to really check the schematics to know
<re_irc>
< (@k900:0upti.me)> fasterthanlime: I don't think the client/server protocol is GDB/MI
<re_irc>
< (@adamgreig:matrix.org)> so it _looks like_ in theory you could have up to 5.5V at the battery terminal without incident, but you'd want to study it a bit further to be really sure...
<re_irc>
< (@k900:0upti.me)> (it's also terrible but hey)
<re_irc>
< (@adamgreig:matrix.org)> putting two lipos in the 2xaa battery holder it comes with would likely damage it, but connecting a single lipo to the connector on the board seems fine
<re_irc>
<fasterthanlime> : oh yeah that's what gdb uses to talk to probe-rs's gdb stub? gdb-mi is what vscode extensions use to talk to gdb (afaict)
<re_irc>
< (@k900:0upti.me)> Yes
<re_irc>
< (@adamgreig:matrix.org)> oh, I see, on the older v1 microbit the battery connection goes directly to the debug probe chip, so a fully charged lipo would immediately damage it
<re_irc>
< (@adamgreig:matrix.org)> so it depnds which version you have!
<re_irc>
< (@k900:0upti.me)> It does WHAT
<re_irc>
< (@k900:0upti.me)> Excuse me
<re_irc>
< (@adamgreig:matrix.org)> it looks like yours is the v1, so you can't exceed about 3.3v on the battery connector
<re_irc>
< (@adamgreig:matrix.org)> (so no lipos)
<re_irc>
< (@k900:0upti.me)> Oh yeah, just to prepare you: "it does WHAT" is definitely a phrase you'll hear a lot when dealing with hardware
<re_irc>
<fasterthanlime> mhh rust-analyzer is unhappy about _one_ of the crates lol
<re_irc>
<fasterthanlime> does r-a generally play nicely with embedded? it's been okay so far but I'm only a couple ohurs in
<re_irc>
<dngrs (spookyvision@{github,cohost})> It does play nice in most cases
<re_irc>
<dngrs (spookyvision@{github,cohost})> I've had more problems in VSCode than in Lapce, interestingly
<re_irc>
<fasterthanlime> dngrs (spookyvision@{github,cohost}): you're using lapce as a daily driver? to do embedded rust? truly living on the edge
<re_irc>
<dngrs (spookyvision@{github,cohost})> fasterthanlime: VSCode mainly, but I gave Lapce a try specifically because RA-VSCode was giving me completion/import issues - I think it's timeouts on the VSCode plugin side related to long build.rs cycles or max symbols or something? Also hitting that with web-sys
<re_irc>
< (@adamgreig:matrix.org)> : so on the v1, the probe chip is a mkl26z128 that has a built-in 5v-to-3v3 LDO designed for running off USB, and the USB vbus goes to that chip, and its 3v3 output is connected to the battery connector too and all the 3v3 devices run off that net (with a diode to stop it back-feeding batteries), so they saved having a separate ldo, but it means the battery connection will directly feed all the 3v3...
<re_irc>
... devices so can't exceed 3.6v or so
<re_irc>
< (@adamgreig:matrix.org)> sweet bom optimisation. guess they didn't like it because it's a separate ldo on v2 and the battery input goes through it
<re_irc>
<Félix the Newbie> I'm trying to read the I2C code from QMK to translate it in Rust, it's like an awful symbol soup 😰
<re_irc>
< (@k900:0upti.me)> Looks like some fancy bit packing
<re_irc>
<Félix the Newbie> They could have used a function or something, right? It's super hard to follow the general logic.
<re_irc>
<Félix the Newbie> I feel like it'll be easier to look at a random I2C + stm32 full example, I'll learn more. Does someone have something like that please?
<re_irc>
< (@jamesmunns:beeper.com)> I think we found a crate for this, at some point in the history?
<re_irc>
<Félix the Newbie> * example in Rust,
<re_irc>
< (@k900:0upti.me)> This isn't generic i2c
<re_irc>
< (@k900:0upti.me)> This is the specific protocol that specific chip speaks
<re_irc>
< (@jamesmunns:beeper.com)> protip: in embedded you always end up needing to refer to a ton of external docs, and referencing chat logs or issues where you ask questions (and get answers!) will save you a bunch of time. I highly recommend keeping a "NOTES.md" in any hardware project repo
<re_irc>
- How to send and receive N bytes over I2C
<re_irc>
< (@jamesmunns:beeper.com)> : So, K900 is right, there's two things:
<re_irc>
- what those N bytes mean
<re_irc>
< (@k900:0upti.me)> There's a crate for the MCP23017, but I can't find one for the 23018
<re_irc>
< (@k900:0upti.me)> Not sure how different the interfaces are
<re_irc>
< (@k900:0upti.me)> If at all
<re_irc>
< (@k900:0upti.me)> You'll want to look up the datasheets for that
<re_irc>
<Félix the Newbie> : I did that quite recently, so I haven't copy/pasted everything relevant which has been said here
<re_irc>
< (@jamesmunns:beeper.com)> in a sense, this is "standard I2C" you will be speaking - you can find examples for "general I2C" in the stm32f3xx-hal repo.
<re_irc>
For the "what the bytes mean", yeah, finding a similar crate (like the mcp23017), and finding the datasheets will explain the byte-protocol
<re_irc>
<Félix the Newbie> : In QMK, it's referred as MCP23, so I guess it's the same thing
<re_irc>
< (@k900:0upti.me)> Definitely would not rely on naming here
<re_irc>
<Félix the Newbie> Ok, I need to move, I'll have a better look at it this evening, now that I understand better what I'm looking for, thanks!
<re_irc>
< (@jamesmunns:beeper.com)> Yeah, that shows you how to do the basic "protocol setup". Sorta like sending and receiving UDP frames, if that makes sense
<re_irc>
< (@jamesmunns:beeper.com)> the second part is "what do you put in the UDP frames (or I2C payloads) to make the device do what you want"
<re_irc>
< (@jamesmunns:beeper.com)> I2C has three main "primitives": "read", which sends nothing* and gets back N bytes; "write", which only* sends N bytes, and "write_then_read", which sends N bytes, and gets back M bytes.
<re_irc>
< (@jamesmunns:beeper.com)> There are asterixes, because the main device always sends an address byte, and the peripheral device (should) always ACK every byte, so it's always a little bidirectional, even when you are just "read"ing or "write"ing.
<re_irc>
< (@jamesmunns:beeper.com)> https://en.wikipedia.org/wiki/I%C2%B2C is a decent overview, I think adafruit has a good simple explainer as well. You won't need to know most details, other than (in most cases) "everything has a 7-bit address, and you either read, write, or read_then_write to every device to interact with it".
<re_irc>
< (@yatekii:matrix.org)> fasterthanlime: I had the same issue, which is weird, because this should not be an issue. r-a has been acting up the entire week tho
<re_irc>
<Félix the Newbie> : As usual (IMHO), the Wikipedia article is garbage, but the adafruit one is really good 👍️
<re_irc>
<Félix the Newbie> If I2C is so simple as being used with 2 wires, the signal can be transferred through a lot of cables, right? Like RJ network cables or others
<re_irc>
< (@k900:0upti.me)> It's not really about the number of wires, it's about the encoding
<re_irc>
<Félix the Newbie> That would be funny to have split keyboards using exotic cables to connect the 2 halves.
<re_irc>
< (@k900:0upti.me)> But generally you can run it a couple meters with no issues
<re_irc>
< (@jamesmunns:beeper.com)> You can, but i2c doesn't work very well over long distances, or with interference
<re_irc>
< (@k900:0upti.me)> Though maybe not if you use unshielded cables
<re_irc>
< (@jamesmunns:beeper.com)> more than a meter or two would be challenging, IMO, maybe a bit more at lower (100kHz or lower) speeds.
<re_irc>
< (@k900:0upti.me)> I think the spec says 1 meter max
<re_irc>
<Félix the Newbie> : I'm not talking about huge cables, the length of my current cable is like half a meter
<re_irc>
< (@k900:0upti.me)> But it's not like people care what the I2C spec says
<re_irc>
< (@k900:0upti.me)> But if your goal is to just use a funny looking cable over a short distance, it should be fine, yeah
<re_irc>
< (@k900:0upti.me)> Though shielded is obviously preferred still
<re_irc>
<Félix the Newbie> : I keep that in a corner of my mind, but I'm very very far from creating my own device.
<re_irc>
<Félix the Newbie> I feel dizzy each time I look at a PCB, but I suppose that to experienced people, it's just like looking at lines of code.
jcroisant has joined #rust-embedded
<re_irc>
< (@therealprof:matrix.org)> Félix the Newbie: That might work, depending on a ton of factors. To ensure signal integrity the pull-ups need to be chosen appropriate which they're not if your using some random dev board, those are optimised for higher speeds/lower power consumption with short lines.
<re_irc>
< (@therealprof:matrix.org)> You can always try, but I'd recommend going for the lowest possible speed rather then default of setting the speed selection to 11.