<re_irc>
<alvela> : Would be worth reposting in the probe-rs matrix: https://matrix.to/#/#probe-rs:matrix.org
<re_irc>
< (@ubik:matrix.org)> alvela: Great, thanks, had no idea there was a room for it 🙂
<re_irc>
<thejpster> With I2C, the clue is in the name. It’s the Inter-IC bus, for connecting two or more ICs, which implies they are on the same PCB. We have other protocols for running over long noisy cables, like RS-422 and CANbus. They usually have differential outputs, or at least a big voltage swing.
<re_irc>
<EJVeraT> Hi guys, hope you're great, I have a question, what hardware / board, you recommend me to start in embedded rust?
<re_irc>
< (@k900:0upti.me)> And it's just an overall good board
<re_irc>
< (@k900:0upti.me)> But pretty expensive
<re_irc>
< (@k900:0upti.me)> micro:bit or Pi Pico are probably your best options if you want cheaper
<re_irc>
< (@k900:0upti.me)> ESP32 stuff also works and is very cheap but the initial setup will be slightly jankier
<re_irc>
< (@ubik:matrix.org)> I can vouch for the Pi Pico. It's cheap, easy to program and small enough that you can even use it in a production project.
<re_irc>
< (@ubik:matrix.org)> Plus there's both a super-complete HAL and Embassy support.
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
id_tam has quit [Ping timeout: 252 seconds]
bjc has joined #rust-embedded
lehmrob has joined #rust-embedded
lehmrob has quit [Ping timeout: 252 seconds]
<re_irc>
< (@datdenkikniet:matrix.org)> RE this: as a neat example, I'm working on a Definitely Not PTP Over Ethernet Network Sync™️ over on this branch (https://github.com/datdenkikniet/stm32-eth/tree/ptp-testing/examples), see " client.rs" and "server.rs". With HSE oscillators and a simple P-controller (math courtesy of , I and/or D controller parts pending for even more precision!) we can sync two units to within ~800 nanoseconds...
<re_irc>
... when they're connected to the same switch.
<re_irc>
< (@datdenkikniet:matrix.org)> RE this: as a neat example, I'm working on a Definitely Not PTP Over Ethernet Network But Kind Of™️ on this branch (https://github.com/datdenkikniet/stm32-eth/tree/ptp-testing/examples), see " client.rs" and "server.rs". With HSE oscillators and a simple P-controller (math courtesy of , I and/or D controller parts pending for even more precision!) we can sync two units to within ~800...
<re_irc>
... nanoseconds when they're connected to the same switch.
<re_irc>
< (@datdenkikniet:matrix.org)> RE this: as a neat example, I'm working on a Definitely Not PTP Over Ethernet But Kind Of™️ on this branch (https://github.com/datdenkikniet/stm32-eth/tree/ptp-testing/examples), see " client.rs" and "server.rs". With HSE oscillators and a simple P-controller (math courtesy of , I and/or D controller parts pending for even more precision!) we can sync two units to within ~800 nanoseconds when...
<re_irc>
... they're connected to the same switch.
<re_irc>
< (@datdenkikniet:matrix.org)> RE this: as a neat example, I'm working on a Definitely Not PTP Over Ethernet But Kind Of™️ on this branch (https://github.com/datdenkikniet/stm32-eth/tree/ptp-testing/examples), see " client.rs" and "server.rs". With HSE oscillators and a simple P-controller (math courtesy of , I and/or D controller parts pending for even more precision when time is available!) we can sync two units to within...
<re_irc>
... ~800 nanoseconds when they're connected to the same switch.
<re_irc>
< (@korken89:matrix.org)> P controller and last 10 min of work day 😅
<re_irc>
< (@korken89:matrix.org)> Also no estimator, so it's quite outlier sensitive :)
<re_irc>
< (@datdenkikniet:matrix.org)> RE this: as a neat example, I'm working on a Definitely Not PTP Over Ethernet But Kind Of™️ on this branch (https://github.com/datdenkikniet/stm32-eth/tree/ptp-testing/examples), see " client.rs" and "server.rs". With HSE oscillators and a simple P-controller (math courtesy of , I and/or D controller parts pending for even more precision and actual outlier resilience when time is available!)...
<re_irc>
... we can sync two units to within ~800 nanoseconds when they're connected to the same switch.
<re_irc>
< (@adamgreig:matrix.org)> I found a simple filter tightened it up to around 100ns, same standard non-ptp switch and reasonable hses
<re_irc>
< (@korken89:matrix.org)> Yeah should be no problem
<re_irc>
< (@korken89:matrix.org)> The jitter was around 20-40ns
<re_irc>
< (@korken89:matrix.org)> Adding an integration term will push the bias close to zero
<re_irc>
< (@korken89:matrix.org)> I think we'll share the results :)
<re_irc>
<EJVeraT> Thanks guys about the recommendations of the initial board to learn embedded rust. I'll order some Pi pico's boards
Foxyloxy___ has joined #rust-embedded
Foxyloxy_ has quit [Ping timeout: 252 seconds]
<re_irc>
<dngrs (spookyvision@{github,cohost})> You will need a probe though if you want to do any kind of debugging/logging (you can use another pi board for that); personally I'd probably recommend espc3 over pico because a) integrated "probe" b) 1st party wifi (some pi boards have wifi but it's another vendor's chip).
<re_irc>
If going pi make sure the SWD pins are exposed, so you can actually use a probe. Some on AliExpress don't have that
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<Félix the Newbie> I don't need a debug device, with 3 leds I can display numbers up to 8! This is such a luxury. I could find the address of my I2C slave with a couple of loops:
<re_irc>
<dngrs (spookyvision@{github,cohost})> you can even display an arbitrary amount of numbers using only one LED, just requires a bit of working memory bookkeeping 😬
<re_irc>
<Félix the Newbie> dngrs (spookyvision@{github,cohost}): And a sense of rhythm.
<re_irc>
<Félix the Newbie> : I could turn the leds on in the slave part 🎉 It was mainly thanks to your explanations, thanks a lot. The protocol is kinda weird, but it's easy to understand.
<re_irc>
<thejpster> Does anyone here know anything about QNX, specifically the 2D graphics API?
<re_irc>
< (@jamesmunns:beeper.com)> Félix the Newbie: A bit of help for anyone missing rhythm: https://docs.rs/blinq
<re_irc>
<Félix the Newbie> Nice, I only need to learn morse now.
GenTooMan has quit [Read error: Connection reset by peer]
GenTooMan has joined #rust-embedded
<re_irc>
<Peter Hansen> : Cool. FYI, at first glance, the docs don't make it obvious to me whether the pattern is read MSB to LSB, or LSB to MSB. E.g. is 0b1000 on then 3xoff, or 3xoff then on?
<re_irc>
< (@jamesmunns:beeper.com)> Had to go look at the code, it's msb to lsb, so 1000 is one on three offs
<re_irc>
<Peter Hansen> That was my assumption. Just wanted to note that unless I simply overlooked it, the docs don't seem to mention it.
<re_irc>
< (@jamesmunns:beeper.com)> Yeah, I should add that, I haven't touched that in a year or two 😅
<cr1901>
jamesmunns: I'm trying to add "magic header deser" to postcard-infomem. Is there a moral equivalent of "I don't have data yet to give you" for postcard::result?
<re_irc>
< (@jamesmunns:beeper.com)> I don't think so? There's an "unexpected end of buffer" error you hit when deser expects more buffer
<cr1901>
i.e. pop() returns only one u8, but if I'm parsing a magic constant, I don't want to return that
<cr1901>
but it's not actually an error
<re_irc>
< (@jamesmunns:beeper.com)> I don't know if I understand what you want
<re_irc>
< (@jamesmunns:beeper.com)> There are the "take_n" helpers
<cr1901>
actually wait, disregard
m5zs7k has quit [Remote host closed the connection]
<re_irc>
< (@jamesmunns:beeper.com)> You could just pop the first four bytes in the constructor of the deser flavor and bail if the contents is missing/wrong
<re_irc>
< (@jamesmunns:beeper.com)> Also I think there's a try_extend default trait methods you could use in the ser flavor
<cr1901>
I want support for the header being not the first 4 bytes in the constructor (i.e. grepping for a magic constant and then decoding)
<cr1901>
err I said that wrong
<re_irc>
< (@jamesmunns:beeper.com)> That way you don't need to call parse_magic on every byte you pop
<cr1901>
oh, yea that'll work
<cr1901>
I'm operating _nowhere_ near optimally today
<re_irc>
< (@jamesmunns:beeper.com)> You could advance and do the linear search in the constructor too, I suppose
<re_irc>
< (@jamesmunns:beeper.com)> No worries, just calling it like I see it :)
<re_irc>
<Slushee> I've been making this for fun and I've gotten stuck
<re_irc>
<Slushee> +on like 296
<re_irc>
<Slushee> I made this method "pub fn custom" which sets the state of some "OutputPin"s
<re_irc>
<Slushee> the issue is that on the 7 segment display I get 'Ghost numbers', there are numbers being displayed on the wrong digits because the LEDs or the pins or something don't turn fast enough
<re_irc>
<Slushee> I fixed this on the rpi pico by just using a countdown timer, but I'm not sure how to do that with the generic "embedded_hal"
<re_irc>
<Slushee> I've seen that on "the embedded_hal" docs, but I don't know how I would go on and do that, I don't know what trait to specify on the display struct: