ello_ has quit [Read error: Connection reset by peer]
ello has quit [Read error: Connection reset by peer]
ello has joined #rust-embedded
ello_ has joined #rust-embedded
_whitelogger has joined #rust-embedded
okhsunrog[m] has quit [Quit: Idle timeout reached: 172800s]
pcs38 has joined #rust-embedded
kenny has quit [Ping timeout: 248 seconds]
sroemer has joined #rust-embedded
sroemer has quit [Changing host]
sroemer has joined #rust-embedded
kenny has joined #rust-embedded
<whitequark[cis]>
i do have a Discord bridge i could set up for y'all
<whitequark[cis]>
note that it can only bridge to one Discord channel per Matrix room
<thejpster[m]>
I'm not keen on using proprietary platforms for WG discussions. I'm relaxed if people here want to go and join Discord to help out over there.
<thejpster[m]>
Note: your memory.x must now provide a VECTORS section, because we found chips where the vectors needed to live somewhere different the rest of the machine code (yes, really. The TI AM2434 gives you like a 4K region to store the vectors, and the firmware must live somewhere totally different)
<thejpster[m]>
* somewhere different to the rest
<Darius>
that is.. quite common..
<Darius>
ARM has spoiled you ;)
<thejpster[m]>
Please do try out my multi-core Cortex-R52 demo, in the cortex-ar repo. I'm quite excited that we got it to work.
RobinMueller[m] has joined #rust-embedded
<RobinMueller[m]>
<thejpster[m]> "New Package Klaxon:..." <- neat, I can undraft my embassy PR which adds cortex-ar support :)
<thejpster[m]>
oooh
<thejpster[m]>
I suppose if you’re not saving register state, you’re less affected by changes in architecture. Interesting.
<thejpster[m]>
Embassy on the S32Z2 would be a very cool demo.
<jason-kairos[m]>
Does anyone here have any recommendations for doing linear regressions from a lookup table?
<jason-kairos[m]>
(eg. thermistor lookup, pretty nonlinear and converting polynomial regression to integer math seems messy)
FreeKill[m] has quit [Quit: Idle timeout reached: 172800s]
dcz[m] has quit [Quit: Idle timeout reached: 172800s]
firefrommoonligh has joined #rust-embedded
<firefrommoonligh>
<thejpster[m]> "Note: your memory.x must now..." <- Do you have an example of what a compliant memory.x looks like?
<JamesMunns[m]>
I should be back on a normal time zone next week if you want me to run the next meeting btw
<adamgreig[m]>
that would be great, thanks! I'll be on holiday with limited internet so doubt I'll be around and certainly not able to run the meeting
<adamgreig[m]>
I don't have much for the agenda this week besides that actually. the membership cleanup is coming along and I'll pr the teams repo to hibernate some people soon, just following up on the last couple. no update from me this week on the updates to the wg structure though it's in progress.
<adamgreig[m]>
we had a new release of the stm32-rs pacs, and some prs on the book and nomicon to unblock ci and get some changes in (thanks everyone for those!)
<thejpster[m]>
The project team repo has been updated after the previous changes. Don’t forget, adding yourself to what/README.md doesn’t actually grant you any permissions. The project bot in the team repo does that.
<thejpster[m]>
s/what/wg/
<thejpster[m]>
Updates to the cortex-ar crates were also published today. You now have an SMP example for the Cortex-R52 (Armv8-R Aarch32)
<adamgreig[m]>
yea, sorry, usually I make the teams PR but must have forgotten for that recent change
<adamgreig[m]>
ok, we have a couple points from triage
<jannic[m]>
Now some PRs in https://github.com/rust-embedded/book/pulls need to be rebased. How shall we handle that? Wait for the original authors, or hit the "Update with merge commit" or "Update with rebase" buttons?
<therealprof[m]>
Rebase is the right approach.
<adamgreig[m]>
yea, I think update with rebase is OK
<adamgreig[m]>
not fussed about update-with-merge either though, we haven't been strict either way
<bartmassey[m]>
It's likely moot for most, as they will be closed without merge anyhow.
<bartmassey[m]>
headed to class — next week as fates allow!
<therealprof[m]>
Merges in PRs create weird history. I absolutely hate it if I look at the history and the commits are all over the place unless "sorted" by using the right options.
dngrs[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]>
<therealprof[m]> "Merges in PRs create weird..." <- This is why I squash all my pr merges :D
pcs38 has quit [Ping timeout: 276 seconds]
pcs38 has joined #rust-embedded
<thejpster[m]>
Squash the PR or squash on merge?
<JamesMunns[m]>
I do squash-merges, so the whole PR gets squashed into a single commit
<JamesMunns[m]>
so the history is basically one commit per PR
<thejpster[m]>
I think the latter is why git keeps telling me my branches haven’t been merged
<JamesMunns[m]>
(not saying everyone should do this, but it's my preference in my projects)
<thejpster[m]>
So I’ve been preferring merge commits. I don’t really understand how it works though.
<JamesMunns[m]>
the default merge is like doing git merge branch (from main), the squash merge is basically git merge branch --squash from main
i509vcb[m] has joined #rust-embedded
<i509vcb[m]>
I tend to rebase/squash merge because I get a linear history in the unfortunate view of github because it makes a branching view more hidden to view
<i509vcb[m]>
It also means in the linear view commit 1 on 05/01/25 and commit 2 on 05/05/25 aren't potentially 20+ commits away from each other when they are part of the same change set
<KevinPFleming[m]>
thejpster: yes, that is why git (locally) claims you branch hasn't been fully merged... the commit ID of what got merged is different from what you had locally
<KevinPFleming[m]>
s/you/your/
jfsimon has quit [Quit: Leaving]
jfsimon has joined #rust-embedded
Max[m] has quit [Quit: Idle timeout reached: 172800s]
<firefrommoonligh>
I find things are easier if you don't spend any time worrying about commit history orderliness
<ian_rees[m]>
(FWIW, I'm also solidly in the "keep history tidy through rebase" camp)
pcs38 has quit [Quit: leaving]
<therealprof[m]>
Some people like to merge criss-cross, but even if the merge was "successful" the real result can only be seen in the final merged tree and one has to hope that CI catches any mismerges resulting through that. Which is bad... I always require people to have a tidy commit history (no merge commits, no fixups, no reverts or pesudo-undo commits) and if it doesn't apply cleanly they will have to rebase...