<re_irc>
<@dirbaio:matrix.org> yeah I ended up in that doc article
<re_irc>
<@dirbaio:matrix.org> but didn't understand it either
<re_irc>
<@dirbaio:matrix.org> 😂
<re_irc>
<@adamgreig:matrix.org> the first include:target:tv6 adds a tv6 target to all three versions
<re_irc>
<@adamgreig:matrix.org> the second include:target:tv7 then overwrites it
<re_irc>
<@dirbaio:matrix.org> why
<re_irc>
<@dirbaio:matrix.org> what's the point lol
<re_irc>
<@dirbaio:matrix.org> why'd you ever want that
<re_irc>
<@adamgreig:matrix.org> because that's how the include things work, it's for overwriting/adding more detail/etc to existing matrix combination jobs, or adding single extra jobs
<re_irc>
<@adamgreig:matrix.org> if you want cross product of versions and targets, you're meant to do what you ended up with
<re_irc>
<@adamgreig:matrix.org> and if you then just want to change features for one of them, that's what include is for, it overwrites the one(s) that match and adds the extra keys
<re_irc>
<@dirbaio:matrix.org> so odd
<re_irc>
<@adamgreig:matrix.org> yea
<re_irc>
<@adamgreig:matrix.org> real "what can we squeeze into yaml" shit
<re_irc>
<@dirbaio:matrix.org> I always thought it was "do the cross product of all others, and then include these extra ones"
<re_irc>
<@adamgreig:matrix.org> in that case you'd just get six right? the three versions, plus three more manual includes
<re_irc>
<@adamgreig:matrix.org> be glad they didn't use the secret yaml lore instead and make you write it out with anchors and aliases and overrides and such lol
<re_irc>
<@dirbaio:matrix.org> yeah.....
<re_irc>
<@dirbaio:matrix.org> yikes
<re_irc>
<@adamgreig:matrix.org> so you'd expect to get six, but actually it's dumber/weirder, if you had "include: [ { features: bla } ]" you'd get three, all with features bla, if you had "include: [ { features: bla }, { features: foo } ]" you'd still get three, all with features foo... idk
<re_irc>
<@adamgreig:matrix.org> anyway best not think about it too much i guess
<re_irc>
<@dirbaio:matrix.org>
<re_irc>
<@adamgreig:matrix.org> : i wouldn't think so right? you can just do some more transactions...
IlPalazzo-ojiisa has quit [Remote host closed the connection]
cr1901 has quit [Read error: Connection reset by peer]
starblue has quit [Ping timeout: 276 seconds]
starblue has joined #rust-embedded
cr1901 has joined #rust-embedded
rardiol has joined #rust-embedded
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
<re_irc>
<@romancardenas:matrix.org> Has anyone implemented an interface to deal with RISC-V's CLIC peripheral? I plan to add generic implementations of standard peripherals on the "riscv" crate and pointers to already tested implementations would help me 😃
jr-oss has joined #rust-embedded
<re_irc>
<@dkhayes117:matrix.org> romancardenas: I had been making plans to do the same when I had time. First step would be adding the extra registers that CLIC defines, which also would be feature gated. It has new memory-mapped registers "CLICINTIP[0], CLICINTIE[0], CLICINATTR[0], CLICINCTL[0]" up to 4095, and 3 new CSRs: "xNXTI, xINTSTATUS, xINTHRESH" I haven't looked any deeper into the standard yet.
<re_irc>
<@romancardenas:matrix.org> I'll do some research. AFAIK the standard is still ongoing
Dr_Who has quit [Read error: Connection reset by peer]
starblue has quit [Ping timeout: 268 seconds]
WSalmon has quit [Ping timeout: 248 seconds]
WSalmon_ has joined #rust-embedded
emerent has quit [Ping timeout: 252 seconds]
emerent has joined #rust-embedded
starblue has joined #rust-embedded
<re_irc>
<@boiethios:matrix.org> Hello, I need some advice helping me to find an architecture to manage time in an agnostic manner. I'm writing a library for keyboard firmwares: the concept is that the user feeds a new state each tick (it's an array of bools telling if the key is pressed or not) and the function spew HID reports out that are to be feed to the host.
<re_irc>
This seems easy, but there is a catch: there is a need to manage time because some stuff can timeout. For example, a key output something else if it's been pressed for X milliseconds.
<re_irc>
Before extracting that code, I used to have a channel mechanism with RTIC: I have pressed/released events, that I spawn directly, and a timeout event that I spawn in the future: "spawn_after(/*etc*/)"
<re_irc>
<@boiethios:matrix.org> I feel like I cannot reproduce this architecture in an agnostic manner. What would you do in my place?
<re_irc>
<@boiethios:matrix.org> +Note that I can have at most one “timeout” active at a time.
<re_irc>
<@k900:0upti.me> You probably just have to take some object that you can ask about a current time
<re_irc>
<@k900:0upti.me> Or a function
<re_irc>
<@k900:0upti.me> Cause there's no platform agnostic way to have that
<re_irc>
<@k900:0upti.me> And on most platforms there's no single correct way to have that either
<re_irc>
<@boiethios:matrix.org> : That makes sense, but do you think I can use such an API with my previous mechanism (spawning an event in the future)? Channel communication is idiomatic in Rust, and it's so easy to write/use from a user POV.
<re_irc>
<@k900:0upti.me> Actually I think there's a bigger problem there
<re_irc>
<@k900:0upti.me> If you make it so your logic is fully driven externally, you can't produce events on a timer
<re_irc>
<@k900:0upti.me> Because they will not be consumed until the next time you're polled
<re_irc>
<@boiethios:matrix.org> Yes, that's the user's job to call the function every 1ms or so. No issue with that.
<re_irc>
<@k900:0upti.me> Then you should probably just have the user provide the current time when they poll you
<re_irc>
<@k900:0upti.me> And handle timeouts based on that
IlPalazzo-ojiisa has quit [Remote host closed the connection]
<re_irc>
<@boiethios:matrix.org> : Thanks. Sometimes, the most simple and obvious is not so obvious when one has only thought in some direction.
<re_irc>
<@boiethios:matrix.org> : Do the controllers HAL usually provide such a function?
<re_irc>
<@k900:0upti.me> No
<re_irc>
<@k900:0upti.me> Most SoCs don't even have a "clock"
<re_irc>
<@k900:0upti.me> But they'll have timers
<re_irc>
<@k900:0upti.me> And you can generally get those timers to produce some sort of counter that's not tied to a specific instant in time
<re_irc>
<@k900:0upti.me> But can give you meaningful durations
<re_irc>
<@boiethios:matrix.org> Oh, I see, thanks. I'll have to find an API that works with that, then.
starblue has quit [Ping timeout: 246 seconds]
<re_irc>
<@boiethios:matrix.org> : There is a small issue, though. After the timer elapsed, a hardware interrupt is called which sends to a specific function, so reading the “elapsed” function is done from another context than writing to it (which makes mandatory to have some synchronization). I could prevent that with the spawning mechanism previously.
<re_irc>
<@k900:0upti.me> You don't ever use the hardware timers in your code
<re_irc>
<@k900:0upti.me> You just store the last "time" value
<re_irc>
<@k900:0upti.me> And do timeouts based on that