ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
<re_irc> <James Munns> My $0.02, you might still want RTIC for the hard realtime control loop, but everything else is going to be much better with async
<re_irc> <James Munns> mostly because most control algorithms work better with fixed control/data polling latencies
<re_irc> <dirbaio> "include!("rants/you_can_do_realtime_with_async_too.txt");"
<re_irc> <dirbaio> 🙈
<re_irc> <James Munns> realtime is a squishy goal anyway
<re_irc> <dirbaio> "realtime" as in "predictable latency"
<re_irc> <James Munns> ehhhh
<re_irc> <James Munns> control theory goes a bit further
<re_irc> <James Munns> in that you often want to have a REALLY DETERMINISTIC spacing between "read sensors like current measurement, accs, gyros", "do calculations", and "apply changed control parameters"
<re_irc> <James Munns> like, can you make a quadrotor work with just async? yes!
<re_irc> <James Munns> probably really really well!
<re_irc> <James Munns> I have worked with robotics customers that REALLY cared about ~uS jitter between those three events tho
<re_irc> <James Munns> but like
<re_irc> <James Munns> yeah, it's probably overkill
<re_irc> <dirbaio> if you write your async code properly you can get equally REALLY DETERMINISTIC timings as if you write it with RTIC
<re_irc> <James Munns> with multiple executor priorities?
<re_irc> <dirbaio> yup
<re_irc> <James Munns> yeah! Then that approach would be totally fine
<re_irc> <James Munns> not sure if you'll gain much vs "three timer tasks and an async idle", but you can solve that problem however you want!
<re_irc> <James Munns> like, I'm not bagging on embassy, I know you know how to do it :D
<re_irc> <dirbaio> you can read your sensors with DMA, so you can read them all at the same time
<re_irc> <dirbaio> +async i2c/spi
<re_irc> <dirbaio> without async, you'd have to either use blocking i2c/spi (so you waste CPU in high prio)
<re_irc> <dirbaio> * prio, blocking low prio tasks more than needed)
<re_irc> <dirbaio> or you write delicious state machine spaghetti to use DMA, with either unsafe or unergonomic "&'static mut"
<re_irc> <dirbaio> +coordinating timer, i2c/spi, and dma irqs,
<re_irc> <dirbaio> so it's no longer "three timer tasks" :P
<re_irc> <James Munns> should have kept my mouth shut :p
<re_irc> <dirbaio> 😈
<re_irc> <James Munns> I guess I'll hedge my bets by saying "don't do your control loop in the same executor as everything else in the system" :D
<re_irc> <James Munns> now if you'll excuse me, I need to go finish making my OS entirely async lol
<re_irc> <James Munns> Finally made it so I can make static, intrusive, mpmc, linked list channels
<re_irc> <James Munns> so now I can use those to drive all my run queues and io providers
<re_irc> <James Munns> also I learned that "std" uses the exact same algo for "std::sync::mpsc"
<re_irc> <firefrommoonlight> James Munns: Currently, how I'm handling polling latencies:
<re_irc> - The IMU supposedly has "guaranteed" reporting intervals, so I'm trusting that the GPIO interrupt on its ready pin is consistent; that interrupt triggers a DMA xfer. (Mistake?) So far, so good though.
<re_irc> - Trusting the Rx receiver to also send data at a consistent rate. (Uart line-idle interrupt) (With a "lost-link" timeout, at which point pre-defined behavior happens
<re_irc> - Mid PID is run off a hardware timer. Outer loop is run off a "%" counter on the mid loop's ISR. (Eg divides in with a ratio)
<re_irc> <firefrommoonlight> Not sure if that's the best way, but is my current process
<re_irc> <firefrommoonlight> Motor control is handled in the IMU data TC ISR, wherein I pass a new motor signal each IMU update
<re_irc> <James Munns> (trust but verify is a good approach here - keep your own timer, have asserts if you fall above/below expected windows w/ a certain tolerance)
<re_irc> <James Munns> (don't necessarily panic, so maybe not an assert-assert, but give yourself a log or a warning or something)
<re_irc> <firefrommoonlight> Stuff like current measurement with ADCs is less critical latency/timing wise, as long as it doesn't interfere with the more fundamental processes
<re_irc> <firefrommoonlight> That might be a good call. Maybe a timer as a sanity-check for the IMU? Losing the IMU, btw, is disasterous; will always result in a crash
<re_irc> <firefrommoonlight> I agree trusting external devices to report at a consistent rate is a trap, and that them appearing to work now doesn't mean it always will
<re_irc> <firefrommoonlight> Intent was to make sure we process IMU data as soon as it's ready
<re_irc> <firefrommoonlight> Which is why the main "rate" control loop is in its TC ISR
<re_irc> <firefrommoonlight> (Again, this is just how I currently have it; loads of room for improvement...)
<re_irc> <James Munns> ehhhhh
<re_irc> <James Munns> I mean
<re_irc> <James Munns> there are things I would tell/recommend you if it was safety critical
<re_irc> <James Munns> and there are things I would tell you if it's a hobby, and the "cost of failure" is relatively low
<re_irc> <James Munns> (especially compared to your time)
<re_irc> <James Munns> like, will you spend 8x as long to avoid crashing one unit? If that's 8 weeks vs 1 week of work, and the hardware costs $100, probably a bad tradeoff
<re_irc> <James Munns> but like, KNOWING when things go wrong (like a latching fault/warning bit that turns on a red light until reset, but doesn't do anything else), or having logs (like in a ring buffer, which you can download if your red light goes off during a flight) are good investments
<re_irc> <James Munns> because they will save you more time debugging, with very little outlay
<re_irc> <James Munns> (again, this is all different if you are making a retail product or especially if safety critical, but don't design for an arena you're not in)
<re_irc> <James Munns> tie a string to it so it doesn't fly away uncontrolled, or buy some extra propellers so you can replace them when they shatter after it hits the ground a couple times lol
<re_irc> <James Munns> this is like "will it scale" for webdev, but for embedded folks
<re_irc> <James Munns> don't build a multi-region serverless redundant whatever whatever if a single binary and sqlite will do the job for the next year lol
<re_irc> <James Munns> (I mean, unless you want to, then go for it! it's a hobby project, I'm not your boss)
<re_irc> <dirbaio> but but but IT hAs tO bE WeBScALe
<re_irc> <James Munns> eh, everyone goes through that
<re_irc> <James Munns> you see your first horrors on the job, and pick up the horror mitigation strategies as gospel, without realizing when the horrors are actually something to avoid or ignore
<re_irc> <James Munns> I had that problem BAD coming out of safety critical into a more rapid-prototyping/startup'y kind of field
<re_irc> <James Munns> WHAT DO YOU MEAN YOU DON'T HAVE TRACEABILITY?!?! OR UNIT TESTS?!?!
<re_irc> <James Munns> (spoiler: that was not the biggest fire at the time)
<re_irc> <James Munns> anyway, thanks for listening to my soapbox of the night
<re_irc> <James Munns> I hope the quadrotor is going fun :D
<re_irc> <firefrommoonlight> James Munns: Those are great calls! First target market is hobbyists, but... we're still talking a 10:1 thrust ratio, spinning blades, an a 6S LiPO
<re_irc> <firefrommoonlight> So, semi-safety-critical? Not in the traditional sense, but have to be careful!
<re_irc> <firefrommoonlight> and speeds over 100mph
<re_irc> <firefrommoonlight> (The one I'm testing on now is a small one with ducted props and is more like 2:1, but the intent is to work on larger ones too)
<re_irc> <firefrommoonlight> Have the props handy, although the ducts are a real lifesaver there!
<re_irc> <firefrommoonlight> James Munns: You mean speed bumps?!
<re_irc> <firefrommoonlight> James Munns: I appreciate it! Good stuff
<re_irc> <firefrommoonlight> Right now, the quadrotor will not maintain a stable hover, probably due to PID tuning or logic errors
<re_irc> <James Munns> There's a skill to building something in the SHAPE of what it needs to be, later in it's life, when it needs to be more reliable
<re_irc> <James Munns> without overbuilding everything before you've worked out all the what and how of what it does
<re_irc> <firefrommoonlight> So, I have it in the back of my mind that I'd like to use the code base and knowledge for more ambitious projects... we are on the same page there
<re_irc> <firefrommoonlight> Step one is sell FC boards that work with Betaflight (popular OSS firmware). Should be GTG there, but the current MCUs I can get aren't compatible
<re_irc> <firefrommoonlight> Step 2 is getting it to work with my custom firmware, which is months+ away
<re_irc> <firefrommoonlight> Step 3 is branching out of the hobby market, probably never, maybe years away
<re_irc> <James Munns> wrote up a bunch of my design process here, though that's typically a bit after you know more about requirements and such: https://twitter.com/bitshiftmask/status/1521526185179627520
<re_irc> <firefrommoonlight> Thanks! Diving in
<re_irc> <James Munns> but like, good rule of thumb is:
<re_irc> - First, make sure you actually know what you want it to do
<re_irc> - Second, figure out vaguely how you are going to achieve that
<re_irc> - Third, figure out how to tell if it's not doing what you want it to do, and how to make your life as easy as possible to figure out why (and how to fix it)
<re_irc> <James Munns> (this is all too vague to probably actually be useful, but like, step one vaguely maps to "requirements", which you should write down and track, even if only loosely, the second maps to "a plan", which again, you should have and keep updated, even if only loosely and it changes over time, and part three vaguely maps to "verification" (if done proactively), or more likely "diagnostics and retrospective analysis" (if...
<re_irc> ... done reactively)
<re_irc> <James Munns> "requirements" and "a plan" can just be in a markdown document in the git repo, btw.
<re_irc> <James Munns> but you'd be blown away by how a dozen or two bullet points can make the success/failure difference for projects, especially if you have multiple people involved.
<re_irc> <firefrommoonlight> I think here the process can go with gradual feature additions. Ie, can build it up in steps, and like evolution, leaving a valid program at every step (one that flies)
<re_irc> <James Munns> if you can't tell, I'm much more of a "process" person than any specific kind of "plan" person
<re_irc> <James Munns> :)
<re_irc> <firefrommoonlight> For example, while staying with the hobby target, start with basic "Rate" controls, with offboard radio processor, and nothing fancy. Add "attitude" controls. Add onboard radio processing. Add TOF sensor in one place. Add second TOF sensor. Add GPS. Use these for loitering, obstacle clearance etc. Add advanced autopilot modes. Add auto-PID tuning/calibration etc etc etc
<re_irc> <firefrommoonlight> Process is so important
<re_irc> <James Munns> Sure! Just write it down, and update it before you take the next step
<re_irc> <firefrommoonlight> I don't actually have a requirements list for this... I have a mental map, but should really write it down, as you say
<re_irc> <James Munns> so you have a chance at seeing where it's going to go wrong before it does :)
<re_irc> <firefrommoonlight> I could get a real firm one set up, although it would be tiered
<re_irc> <James Munns> write what you know, write what you don't
<re_irc> <James Munns> plans don't have to be perfect, especially early
<re_irc> <James Munns> and if something is big and spooky, figure out how to break it down, or how far you need to get before you can sort out what kind of spooky it is.
<re_irc> <dirbaio> that sounds super cool, I want one 👀
<re_irc> <firefrommoonlight> Me too!
<re_irc> <James Munns> firefrommoonlight: I know that feeling :D
<re_irc> <kevlan> James Munns: I had to deal with this issue a few years ago. We thought bringing in a contractor with lots of experience in high reliability systems would help us out when we were just trying to get the product to work. There was lots of head butting over things like analyzing all error paths when we were just trying to get a demo of the product working.
emerent has quit [Ping timeout: 244 seconds]
emerent has joined #rust-embedded
<re_irc> <ryan-summers> It's definitely hard - for high reliability systems, something like more than 50-75% of your time is testing, analyzing, tracing, verifying, design, etc. and the actual development is a relatively small period. Rapid prototyping phases are _very_ different from final product phase. The issue is that a lot of companies will want to turn the initial prototype into a final product, but from a safety-critical design...
<re_irc> ... process flow, that's not possible
<re_irc> <ryan-summers> Because for e.g. medical devices, the whole concept of functional safety arises from the _process_ you follow to develop the product, which requires associated risk analysis and failure mode and effects analysis. If you use any development before that conceptual work is done, you fundamentally have not followed a "safe" process and won't conform with development standards
<re_irc> <ryan-summers> Conceptually, it's like putting bandaids on all the holes you find in the boat instead of trying to design the boat to be void of holes
crabbedhaloablut has joined #rust-embedded
loki_val has quit [Remote host closed the connection]
<re_irc> <eldruin> PSA: embedded-hal-async 0.1.0-alpha.1 release is now out! https://github.com/rust-embedded/embedded-hal/releases/tag/embedded-hal-async-v0.1.0-alpha.1
dc740 has joined #rust-embedded
<re_irc> <henrik_alser> eldruin: Awesome!!
causal has quit [Quit: WeeChat 3.5]
dc740 has quit [Remote host closed the connection]
Amadiro has joined #rust-embedded
Amadiro__ has quit [Ping timeout: 276 seconds]
aspe has joined #rust-embedded
badboy has quit [Ping timeout: 256 seconds]
<re_irc> <Lachlan> I'm hitting this super odd failure case (I feel like I hit those constantly) where flash writes are visible in the memory mapped flash region on one board, but not visible on a different board. As far as I can tell, they're exactly the same model and revision (STM32H743IIT6). I'm cleaning/invaliding the caches, so I'm pretty sure it's not a caching issue. Anyone run into something like this before?
<re_irc> <TimSmall> Are you running the exact same binary on both? If-not, could it be some sort of alignment problem (just a guess)?
causal has joined #rust-embedded
<re_irc> <Lachlan> Almost exactly the same, but the addresses of everything are the same
<re_irc> <Lachlan> The boards are slightly different
<re_irc> <Lachlan> Main difference is that the ethernet pins are different
<re_irc> <dirbaio> different clocks, or power supply issues?
<re_irc> <dirbaio> * HSE oscillator,
<re_irc> <dirbaio> like, maybe it's not meeting the clock/power requirements for flash so
<re_irc> <dirbaio> -so
<re_irc> <Lachlan> I can look into that, but there's another interesting bit of data
<re_irc> <Lachlan> I write to flash in bank 2, and then read from that area and write that to a location in bank 1.
<re_irc> <Lachlan> The writes to bank 2 succeed.
<re_irc> <Lachlan> And are visible in the memory map
<re_irc> <dirbaio> the docs homepage of "embedded-hal" mentions some "nb::await!" and "nb::try_nb!" macros
<re_irc> <dirbaio> that I can't find anywhere?
<re_irc> <dirbaio> also the futures example uses "futures 0.1" which is _ancient_
<Shell> anything which uses futures 0.1 is probably pre-async-standardisation
<re_irc> <mabez> dirbaio: I think it's because docs.rs defaults to the latest non alpha version, so 0.2.7. I think that text comes from here: https://github.com/rust-embedded/embedded-hal/blob/2e91b430c5f3c2e06cb3f12a7812e17cafd2d3bc/src/lib.rs#L189
<re_irc> <dirbaio> ah they're feature-gated, that's why it doesn't show up in nb's docs https://github.com/rust-embedded/nb/blob/v0.1.x/src/lib.rs#L382-L401
<re_irc> <dirbaio> and removed in "nb 1.0".. which EH is not using yet lol
<re_irc> <dirbaio> * 1.0", used in EH1.0
<re_irc> <dirbaio> we should probably remove all that from EH0.2 docs, it's confusing people trying to use the "real" async
<re_irc> <dirbaio> i'm not even sure it works in today's rust lol
<re_irc> <James Munns> Hey luojia65, have you used any of the Allwinner RISC-V targets? Specifically the D1/D1s?
<re_irc> <James Munns> I saw you were involved in some of the RustSBI stuff which mentions that, but I'm not super familiar with SBI. I'd be interested in writing some bare-metal code for the D1/D1s though :D
<re_irc> <James Munns> (I think that's specifically the "Nezha" core)