Skip to content

Commit

Permalink
Notes from Core working group call: May 10, 2024
Browse files Browse the repository at this point in the history
  • Loading branch information
brghena committed May 10, 2024
1 parent dbd491e commit a26e0f4
Showing 1 changed file with 67 additions and 0 deletions.
67 changes: 67 additions & 0 deletions doc/wg/core/notes/core-notes-2024-05-10.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,67 @@
# Tock Meeting Notes 2024-05-10

## Attendees
- Branden Ghena
- Brad Campbell
- Leon Schuermann
- Amit Levy
- Andrew Imwalle
- Hudson Ayers
- Viswajith
- Johnathan Van Why
- Alyssa Haroldsen


## Tutorial Updates
* Leon: We're doing a final run-through of the tutorial. All the code's in place, although there's still a PR or two that won't be controversial. We're still breaking down the code into milestones and making sure things are consistent with the libtock-sync API.
* Leon: We're also doing a cleanup of the writing and publishing a new VM image.
* Leon: There will be one more semi-large libtock-c PR, which only adds the tutorial folder with a bunch of apps. So that shouldn't be too hard to merge
* Brad: Are there other things in the branch that need to be merged upstream, other than what's in the PRs right now?
* Leon: There's an open PR for the entire branch, I think. We're pushing directly to the branch and everything goes there, so the PR should reflect the changes. That's a libtock-c PR
* Leon: The changes on the PR, as far as I see, migrate openthread to libtock-c-sync, and add a bunch of applications in the examples / tutorials folder
* Kernel PR - https://github.com/tock/tock/pull/3979
* (There is no PR in libtock-c at this time, it'll be here soon)
* Leon: For the next few days, anything non-controversial but time-sensitive we'll send out a notice in the tutorial slack channel.
* Brad: That sounds good
* Leon: We think everything should be in by tomorrow
* Brad: The getting started guide is also in progress: https://github.com/tock/book/pull/38
* Branden: Can you explain this?
* Brad: Backstory from Pat was that they did a tutorial runthrough at UCSD, and the getting started guide was a bit much. I agree that it's got a TON of information, and it's not always obvious which parts are important. So the thought was that breaking it down into parts could help guide you to what's most important.
* Brad: So I did a first pass in this PR. The goal was for Pat or Tyler to review and make additional updates for problems they saw from the runthrough
* Brad: As far as the tutorial text goes, is there anything you need there?
* Leon: We have a draft but we're going through it right now. Tyler is still producing text for the openthread parts. That won't be as bad as it sounds though, as people will only be doing small additions to the openthread starter code.
* Leon: I'll keep people in the loop as the text changes and when we want reviews
* Leon: For the entire tutorial we have roughly 3-4 hours, counting some setup. So we are tuning down the tutorial a little to make it fit in time. We have roughly 10 people signed up now. So it's possible that people will finish early, and for those we intend to do ad-hoc walkthroughs of app signing and things like that.
* Brad: I think you don't have to worry about adding more stuff. People will either just want to stop when finished, or will want to dive deeper and will be able to be guided to documentation
* Branden: Hands-on stuff like this always takes longer than you expect too. So I wouldn't worry about getting done too early
* Leon: We do have a getting-started guide, but people aren't necessarily going to go through it in advance, even if we tell them to. So that will take some time too
* Brad: I do wonder whether you could get people to compilation _while_ you're doing the introduction stuff. Particularly first-round compilation on some of the libraries
* Leon: I have the VM on some flash drives that I can just do first-round compilation on for them before handing out.
* Leon: We also have a tock-assets website that uses a CDN, so it should work better than you might expect, even in Hong Kong


## Rust-NL
* https://2024.rustnl.org/
* Leon: We met with a bunch of people from the Rust Embedded working group, that work on the HAL crates and things like that
* Leon: They run into many of the exact same issues we do. Static muts, and hardware CI, and stuff. Really nice to have conversations with them.
* Amit: Even if sharing code isn't going to happen at a large scale, I think there are many overlaps in challenges and sharing of solutions.
* Leon: We'll present a more organized version on a subsequent call
* Brad: It would be pretty cool if we could share testing hardware, for overlapping boards
* Hudson: Was there any mention of the recent libtock-rs PR to using some of their stuff?
* Leon: I mentioned it and they approved of it. They thought that this is what their interfaces are for and that it makes sense.


## Libtock-C
* Brad: Libtock-c rewrite is in, with new interfaces and a new style guide. It's hopefully MUCH more consistent for all drivers. So there's some consistency and most drivers work the same
* Brad: Other benefits are the split between libtock and libtock-sync. Libtock does asynchronous code only. There are no uses of yield and you'll only get an asynchronous API. There's almost no internal state too, so almost everything is exposed back to you. The services folder is the exception to the state thing.
* Brad: If you want a synchronous version, which needs some small internal state, that's the libtock-sync code. So hopefully this makes it clearer what to use depending on your desires
* Hudson: I think it's an enormous improvement
* Brad: I will add, that from porting some of the examples that if you're using the sync API it's mostly the same as before with some renaming. The asynchronous versions, which have callbacks customized for the use case, take a little learning but even with that for the majority porting should be straightforward. Not a lot of gotchas.
* Hudson: I noticed in the now-merged PR had a description that some BLE, IPC, and I2C stuff isn't ported over yet. Is that still true and is it tracked in an issue somewhere?
* Brad: That's correct. We do need a tracking issue for that
* Hudson: We also move some stuff to a folder outside of CI. Should we include that in the issue too?
* Brad: Some of those, but not all. Old courses don't really matter. But some of it is SPI stuff that needs to be updated
* Brad: Amit is putting work into IPC and maybe has something that's close anyways
* Hudson: Okay, I'll make a tracking issue for this


0 comments on commit a26e0f4

Please sign in to comment.