<re_irc>
<@lachlansneff:matrix.org> Just had an idea: using probe-rs on an embedded device with an embedded USB stack underneath it.
<re_irc>
<@dngrs:matrix.org> l0uisc:matrix.org: do you have the most recent r-a version? That should fix it. If not, try building one from git (it's just two commands, `cargo xtask install --server && cargo xtask install --client`)
<re_irc>
<@dngrs:matrix.org> also, if you've got the "Rust" vscode extension installed as well, bin it, and just install the "rust-analyzer" one
<re_irc>
<@dirbaio:matrix.org> latest r-a enables procAttrMacros by default
<re_irc>
<@dngrs:matrix.org> dirbaio:matrix.org: and they should work, I implemented support for RTIC's `app` module
<re_irc>
<@dngrs:matrix.org> (although it was a one line fix and I have no idea what I'm doing)
<re_irc>
<@dirbaio:matrix.org> yeah but it breaks if the macro is not "designed" to be r-a friendly
<re_irc>
<@dngrs:matrix.org> anyway, if c-m `entry` is broken I'd consider that a regression; I should have time to try and fix that on Tuesday maybe
<re_irc>
<@dirbaio:matrix.org> if the macro errors out completely when the macro input fails to parse, r-a will do the "mark everything as red and give up" thing
<re_irc>
<@dngrs:matrix.org> dirbaio:matrix.org: ok, all I can say is c-m `entry` works for me on r-a git
<re_irc>
<@dngrs:matrix.org> dirbaio:matrix.org: that's a good point, I wonder how much we can do about it. It doesn't break entirely but it seems to get confused about what's actually available
<re_irc>
<@dirbaio:matrix.org> and I really disagree with it 🍭
<re_irc>
<@dirbaio:matrix.org> dngrs:matrix.org: there's some workaround macros can do to be "r-a friendly", something like "return the whole input as-is if it failed to parse"
<re_irc>
<@dirbaio:matrix.org> can't find links now lol
<re_irc>
<@dngrs:matrix.org> no worries
<re_irc>
<@dngrs:matrix.org> I'm mostly wondering about the far future, where r-a and rustc share a lot of code, which maybe enables a more error tolerant approach
troth has quit [Ping timeout: 260 seconds]
troth has joined #rust-embedded
dreamcat4 has quit [Ping timeout: 240 seconds]
darknighte has quit [Ping timeout: 240 seconds]
dreamcat4 has joined #rust-embedded
darknighte has joined #rust-embedded
<re_irc>
<@come_744:converser.eu> jacobrosenthal:matrix.org: What about making the compiler warn when a future is not fully awaited, to force the user to write something like future.abort; to explicitly indicate the future is not forgotten? This abort suffix keword would not generate code in the executable, it would just be a way to make the compiler happy.
<re_irc>
<@come_744:converser.eu> In the article are listed usecases for async but it seems it is not including the case when there is simply no OS to manage threads…
<re_irc>
<@dirbaio:matrix.org> all that "omg you can cancel futures in rust" comes from people who expect async tasks to behave like "real" thread (or goroutines or similar)
<re_irc>
<@dirbaio:matrix.org> surprise surprise, they're not
<re_irc>
<@come_744:converser.eu> Oh i though it was more about the compiler not helping developers to manage several futures without forgetting any
<re_irc>
<@dirbaio:matrix.org> well, being able to cancel a future by dropping it is usef
<re_irc>
<@dirbaio:matrix.org> it's just "differnet" than what people are used to
<re_irc>
<@dirbaio:matrix.org> so they cancel stuff "accidentally" lol
<re_irc>
<@dirbaio:matrix.org> Go is the opposite
<re_irc>
<@dirbaio:matrix.org> canceling stuff in Go is a pain
<re_irc>
<@dirbaio:matrix.org> you have to pass `Context`s around everywhere 💩
<re_irc>
<@dirbaio:matrix.org> and you end up accidentally *not* canceling stuff you should've
troth has quit [Ping timeout: 245 seconds]
<re_irc>
<@dirbaio:matrix.org> you can't have it both ways 🤷
<re_irc>
<@come_744:converser.eu> Well I stopped considering learning go when i discovered it can return both error status and output, so that unconsistent output can be read
<re_irc>
<@dirbaio:matrix.org> hehe because no enums
<re_irc>
<@dirbaio:matrix.org> yeah that suck
<re_irc>
<@come_744:converser.eu> Plus it is developed by Google and if it is like dart (for Flutter) Google general conditions must be accepted by the devs…
<re_irc>
<@dirbaio:matrix.org> lol, that's not true
<re_irc>
<@come_744:converser.eu> Ah they put different terms for Go and Dart ?
troth has joined #rust-embedded
<re_irc>
<@come_744:converser.eu> Oh indeed
<re_irc>
<@come_744:converser.eu> My bad
<re_irc>
<@dirbaio:matrix.org> it's just plain bsd 3-clause
<re_irc>
<@come_744:converser.eu> come_744:converser.eu: And it is not for Dart, only for Flutter
<re_irc>
<@lachlansneff:matrix.org> Could be useful when there’s multiple microprocessors in a product and you want to update one from the other
<re_irc>
<@dirbaio:matrix.org> fun
<re_irc>
<@dirbaio:matrix.org> but for that you usually use an uart/whatever bootloader in the target mcu
<re_irc>
<@dirbaio:matrix.org> instead of having the main mcu drive the target mcu's swd lol
<re_irc>
<@lachlansneff:matrix.org> For sure, that’s true
<re_irc>
<@lachlansneff:matrix.org> From the probe is a good idea as well
<re_irc>
<@lachlansneff:matrix.org> It could pretend to be a usb drive or something, and you just drop the firmware onto it
starblue has quit [Ping timeout: 245 seconds]
starblue has joined #rust-embedded
creich_ has joined #rust-embedded
creich has quit [Ping timeout: 268 seconds]
rjframe has quit [Ping timeout: 245 seconds]
<re_irc>
<@jamesmunns:beeper.com> That's what the teensys do, basically. It's a separate chip driving the main chips swd lines
<re_irc>
<@jamesmunns:beeper.com> For USB mounting, I usually see that as a bootloader mode
<re_irc>
<@9names:matrix.org> I thought all the teensy's just used a bootloader?
troth has quit [Ping timeout: 240 seconds]
<re_irc>
<@jamesmunns:beeper.com> Nope! Most of them have a separate chip, usually an MKL of some type, that actually handles code loading
troth has joined #rust-embedded
PyroPeter has quit [Ping timeout: 245 seconds]
PyroPeter has joined #rust-embedded
tokomak has joined #rust-embedded
<re_irc>
<@thejpster:matrix.org> Running proprietary closed source firmware to prevent clones.
<re_irc>
<@thejpster:matrix.org> dirbaio:matrix.org: Microchip make a neat programmer. Six 'banks'. Six LEDs. Couple of buttons. A header you can attach spring pins to. Just select an image, push against the programming pads and tap 'Go'. Takes about three seconds.
<re_irc>
<@thejpster:matrix.org> We gave one to a factory rust was previously using Windows XP and an app that needed you to click about fifteen buttons per flash.
troth has quit [Ping timeout: 240 seconds]
troth has joined #rust-embedded
troth has quit [Ping timeout: 260 seconds]
troth has joined #rust-embedded
troth has quit [Ping timeout: 256 seconds]
troth has joined #rust-embedded
<re_irc>
<@tmplt:matrix.org> adamgreig: the `itm` PR is ready for review now. Is there a meeting I should attend regarding the Cortex-M team vote to answer any quetions?
<re_irc>
<@adamgreig:matrix.org> great, thanks! I'll put it on the agenda for this coming tuesday 8pm berlin time, but the actual voting etc will just happen as approvals on the pr, and any questions/discussion can happen there too
rjframe has joined #rust-embedded
tokomak has quit [Ping timeout: 245 seconds]
dcz_ has joined #rust-embedded
rjframe has quit [Ping timeout: 240 seconds]
jackneilll has joined #rust-embedded
jackneillll has quit [Remote host closed the connection]
<re_irc>
<@newam:matrix.org> For anyone else wondering why builds are failing github just reported an incident: https://www.githubstatus.com/
<re_irc>
<@newam:matrix.org> it says only pull requests & github actions, but clones are failing for me and HTTP requests are 404'ing.
<re_irc>
<@newam:matrix.org> Oh, and there is it, 1 minute later, git operations incident.
<re_irc>
<@dngrs:matrix.org> from the things that look a lot cooler live department: [distance sensor controlled brightness](https://youtu.be/h4TW6PckxMw) 🎉
<re_irc>
<@jamesmunns:beeper.com> Super slick! Tweet about it and tag rustembedded dngrs (spookyvisiongithub) !
<re_irc>
<@dngrs:matrix.org> good idea! I'll polish it some more before that :) the animation is a bit broken atm because I can't maths (converted it from an iterative form to `fn(time)` while half asleep)
<re_irc>
<@dngrs:matrix.org> also, is it to be expected that these ultrasonic sensors eat a metric ton of current?
<re_irc>
<@dngrs:matrix.org> can't power LEDs+mcu+sensor from one USB cable anymore
<re_irc>
<@jamesmunns:beeper.com> Datasheet for an HC-SR04 says 15mA
<re_irc>
<@dngrs:matrix.org> 🤔
<re_irc>
<@jamesmunns:beeper.com> the LEDs are probably more than that, each.
<re_irc>
<@jamesmunns:beeper.com> smartleds are usually like 30-60mA all-on, per pixel
<re_irc>
<@dngrs:matrix.org> it worked fine before I added the sensor... odd. Well, the protoboard is one gigantic hackjob I had to half-redo because I ripped things off while adding the sensor, maybe some wires are just a bit bork
<re_irc>
<@jamesmunns:beeper.com> Like, my 8x8 smarled pixels use a bit more than 2A if the LEDs are on.
<re_irc>
<@dngrs:matrix.org> maybe it's a voltage drop thing and the sensor errors out when its VCC goes too far below 5V
<re_irc>
<@jamesmunns:beeper.com> err, all-on, e.g. (255, 255, 255)
<re_irc>
<@dngrs:matrix.org> because it does all work as long as I don't make the LEDs too bright
<re_irc>
<@jamesmunns:beeper.com> :p
<re_irc>
<@jamesmunns:beeper.com> what USB-thing are you powering it with?
<re_irc>
<@dngrs:matrix.org> in case it wasn't clear, I'm a total EE dummy
<re_irc>
<@jamesmunns:beeper.com> Theoretically, a well-compliant USB port on a computer shouldn't give you more than 500mA
<re_irc>
<@dngrs:matrix.org> yeah
<re_irc>
<@dngrs:matrix.org> damn those safeguards
<re_irc>
<@jamesmunns:beeper.com> Often they'll give you up to 1A, but usually not much more
<re_irc>
<@dngrs:matrix.org> you reckon a power bank would give more?
<re_irc>
<@dngrs:matrix.org> *trying*
<re_irc>
<@jamesmunns:beeper.com> cheaper USB wall warts and batteries will usually give you up to 2A or so
<re_irc>
<@dngrs:matrix.org> yup, that solved it
<re_irc>
<@dngrs:matrix.org> :V
<re_irc>
<@jamesmunns:beeper.com> It *depends*, which is my favorite answer
<re_irc>
<@dngrs:matrix.org> or did it? not quite, but the sensor errors out far less than before
<re_irc>
<@jamesmunns:beeper.com> but everything is cursed, get a benchtop supply
<re_irc>
<@jamesmunns:beeper.com> Also make sure you aren't using the cheapest USB cable, the really thin/flexible ones usually use a thinner, sometimes aluminum, power cable.
<re_irc>
<@dngrs:matrix.org> yeah, never touching those ribbons again
<re_irc>
<@jamesmunns:beeper.com> Which can be enough to heat up/drop voltage due to resistance
<re_irc>
<@dngrs:matrix.org> cable should be fine, short and thick
<re_irc>
<@dngrs:matrix.org> my money's kinda on my terrible soldering
<re_irc>
<@dngrs:matrix.org> maybe, MAYBE this board (OG blue pill) doesn't even give 5V when I only power it via USB
<re_irc>
<@dngrs:matrix.org> there was something with this.
<re_irc>
<@dngrs:matrix.org> because: when I power it all through one single USB hub connection with an stlink on GND/data/3V3 and the stlink's 5V pin connected to the board's 5V pin it works
<re_irc>
<@jamesmunns:beeper.com> You uh, shouldnt connect BOTH the USB power cable AND the STLink 5v cable
<re_irc>
<@jamesmunns:beeper.com> at least not in parallel
<re_irc>
<@jamesmunns:beeper.com> like, 5v-to-5v
<re_irc>
<@jamesmunns:beeper.com> you could back-power one of the ports and damage it
<re_irc>
<@dngrs:matrix.org> theoretically yeah, but I've never had problems with any board doing that
<re_irc>
<@jamesmunns:beeper.com> yeah, I'd be more worried about the laptop, than the board.