crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
PyroPeter has quit [Ping timeout: 265 seconds]
PyroPeter has joined #rust-embedded
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 245 seconds]
dreamcat4 has quit [Ping timeout: 245 seconds]
nohit has quit [Read error: Connection reset by peer]
nohit has joined #rust-embedded
dreamcat4 has joined #rust-embedded
fabic has joined #rust-embedded
dreamcat4 has quit [Ping timeout: 252 seconds]
nohit has quit [Ping timeout: 252 seconds]
nohit has joined #rust-embedded
dreamcat4 has joined #rust-embedded
fabic has quit [Ping timeout: 268 seconds]
fabic has joined #rust-embedded
Shell is now known as Shellhound
fabic has quit [Ping timeout: 252 seconds]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 260 seconds]
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
jackneill has joined #rust-embedded
unmanbearpig has quit [Ping timeout: 265 seconds]
unmanbearpig has joined #rust-embedded
nohit has quit [Ping timeout: 252 seconds]
nohit has joined #rust-embedded
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 268 seconds]
<re_irc> <> newam: Re: security risks for public self-hosted runners - you can host the runner in a separate, private repo, and then forward CI results from that repo into the public one. Then, all CI runs have to be requested via an admin (e.g. approved to run) or automated via bors
<re_irc> <> We do this for nightly CI of an stm32h7 application as well as hardware-in-the-loop CI for new PRs
<re_irc> <> Can check out for an example
<re_irc> <> It does slow things down when it isn't automatic though
<re_irc> <> Not that much - there's not a ton of PRs, and you just have to have a `bors try` to get CI to run
<re_irc> <> Or have it trigger nightly
<re_irc> <> cortex-m _has_ had people hijack the CI process to mine bitcoin in the past, so just keep that in mind from a security perspective
<re_irc> <> as an alternative
<re_irc> <> github actions can give signed openid-connect tokens (JWTs) to jobs
<re_irc> <> from the JWT you can get the repo and branch
<re_irc> <> and I think the PR creator too (?)
<re_irc> <> and they can be trusted because they're signed
<re_irc> <> I was thinking of writing some server where you post an ELF and the JWT, and it runs it for you
<re_irc> <> so you can selfhost just that, and hit it from the GHA-hosted runners
<re_irc> <> since it can see the branch name, it can only allow runs from staging/trying branches, so it can be gated by a `bors try` or `bors r+`
<re_irc> <> or maybe if it can see the author username the server could have a list of trusted users
<re_irc> <> How would that approach program the binary and then e.g. run support python scripting?
<re_irc> <> E.g. to verify that the device is pingable, or can respond to network requests
<re_irc> <> it'd be some rust using some http server lib and probe-rs
<re_irc> <> but yeah you can't script stuff
<re_irc> <> it's the test firmware itself who would have to exit with pass/fail
<re_irc> <> So more geared towards on-target unit tests etc. ,which def have value though
<re_irc> <> yeah...
<re_irc> <> Granted, hard to do integration testing on a remote CI server unless you set up said server with your hardware
<re_irc> <> I'm concating tail -f /dev/ttyUSB0 | defmt-print.. but it sometimes fails on startup and im not sure if it has any buffering. is there some obvious other way? i don't have a debugger
<re_irc> <> missing timestamps etc in defmt-print, i guess probe-run has more features
<re_irc> <> defmt requires every single byte to go through uncorrupted
<re_irc> <> if you're losing or corrupting bytes it'll fail and never recover
<re_irc> <> like
<re_irc> <> it works decently over uart, I probably commited some crimes
<re_irc> <> the very first byte the target sends has to be the very first byte that defmt-print receives
<re_irc> <> if you restart the target without restating defmt-print, it may get stuck on a "half written" defmt frame
<re_irc> <> or maybe it's uart flow control issues
<re_irc> <> hard to know
<re_irc> <> defmt 0.3 adds COBS framing, so it'll be able to recover from corruption
<re_irc> <> ok
<re_irc> <> seems to help that my target always gets reset when i read from serial
<re_irc> <> so that's a feature
<re_irc> <> I'd recommend using defmt-rtt if you can, using hardware uarts is going to be a bit painful
<re_irc> <> ok
<re_irc> <> maybe you can add your own framing to avoid corruption, but it's probably not worth the work
<re_irc> <> don't know anything about RTT, do I need a debugger for that? or is something I am likely to be able to hook up to without any extra HW
<re_irc> <> yeah you need a debug probe
<re_irc> <> well worth getting one, you can use it to flash, view logs, debug, single-step, view crash stacktraces with various tools
<re_irc> <> you can get them quite cheap, stlink V2 clones are quite cheap and work OK, or you can get the hs-probe for a bit more money
<re_irc> <> Ok. thanks. I see lots of chips have j-tag pin holes, but no socket. do i usually need to solder on a socket or is it sufficent to just stuff it in?
<re_irc> <> hm, most boards (especially if they're dev boards) have the socket
<re_irc> <> which chip/board are you using?
<re_irc> <>
<re_irc> <> ambiq Apollo3 Blue MCU? huh
<re_irc> <> yes, cortex-m based,
<re_irc> <> i'm fast-forwarding a rust hal by cherry-picking from their C hal
<re_irc> <> (then I can swap it out with native rust later)
<re_irc> <> yeah seems it doesn't have a swd socket
<re_irc> <> thanks sparkfun
<re_irc> <> :(
<re_irc> <> it's probably the 2x5 footprint next to the module
<re_irc> <> yeah, that's what I thought. so need to solder, not the end of the world, but..
<re_irc> <> anyway, thanks for you help, got to run
<re_irc> <> and it's not in probe-rs either, not sure how hard it'd be to get it to work
<re_irc> <> yeah.. insisting on writing the firmware in rust, re-implementing a hal, + adding support to probe-rs.. i'm never going to get to the actual code
<re_irc> <> jwho needs an SWD socket. debugging is for noobs
<re_irc> <> yeah just run your program blind
<re_irc> <> stick it in there, pray it works :D
<re_irc> <> Next level: only one try. If it doesn't work, delete source code and start from scratch.
<re_irc> <> put a panic handler that bricks your chip. Had a panic? buy another devboard
<re_irc> <> why run. send to the factory and ship, np
<re_irc> <> in a mask ROM in an ASIC 👌
<re_irc> <> XD hey, a guy at ABB in the production told me he buys a new phone after a year when it's clogged with viruses/random apps ... he was like "wtf you can do that" when I told him he can just reinstall the OS etc lol
<re_irc> <> I recently wrote a python script to hand-code a binary because we're debugging an issue where the startup voltage causes the CPU to periodically skip some instructions
<re_irc> <> Would not recommend
<re_irc> <> xd
<re_irc> <> wowwwwww that must've sucked
<re_irc> <> *is currently still sucking
<re_irc> <> oh no :O
starblue has joined #rust-embedded
emerent_ has joined #rust-embedded
emerent is now known as Guest6958
emerent_ is now known as emerent
Guest6958 has quit [Ping timeout: 260 seconds]