Tools Team: Decide on 2019 objectives

[adamgreig]

As part of our 2019 planning, we want to figure out what each team wants to work on this year, including new ideas, items from the 2019 wishlist (#256), and any leftover items from this year.

Let's use this issue to come up with a list of possible items and then prioritise them.

[japaric]

cc @rust-embedded/tools

I think we should focus primarily on improving svd2rust. Error messages need to be improved (the groundwork already landed in the svd parser). We should detect and reject files that don't adhere to the SVD spec early on rather than producing crates that don't compile. We could look into ways to produce less code to improve compile time of PAC. A good chunk of the ecosystem relies on svd2rust so we should make it as good as possible.

I would also like to see itm / itmdump gain more features like demuxing of ITM channels and support for parsing perf / event metrics (e.g. interrupt entry / exit).

[thejpster]

@dtwood was looking at implementing code for an Ethernet PHY and had the idea for an svd2rust style interface generator, but for things that weren't microcontrollers (either where we write an SVD file, or have some other tool with similar output but a different DSL).

[dtwood]

@thejpster, for an example of what I've been hoping to generate, see https://github.com/dtwood/tm4c-hal/blob/282ea0cb180aa8dfb93391c8e86dd25826ae7a7a/tm4c129x-hal/src/ethernet.rs#L368 - the PHY had 16 16-bit registers accessible through the MAC, so this provides an interface that takes a reference to the MAC when calling read/write/modify.

I've also done https://github.com/dtwood/tm4c-hal/blob/282ea0cb180aa8dfb93391c8e86dd25826ae7a7a/tm4c129x-hal/src/ethernet.rs#L405, - the rx descriptor belongs to a buffer of descriptors allocated by the program, therefore unlike with memory-mapped peripheral registers, it needs some sort of new function.

Currently both of these have been done with hand-written (and only with the fields that I currently need) SVD files and a local modified version of svd2rust. I'd be happy to do some work to make it all a lot nicer, but it probably needs some thought on how this actually wants to work first, whether that's integrated into svd2rust or at a standalone tool.

[Disasm]

@dtwood was looking at implementing code for an Ethernet PHY and had the idea for an svd2rust style interface generator, but for things that weren't microcontrollers (either where we write an SVD file, or have some other tool with similar output but a different DSL).

Something similar will be helpful for FPGA-based targets with different peripherals unrelated to the CPU: MAC IP, external PHYs, other IP cores with lots of registers.

[japaric]

We discussed in yesterday's meeting (#290) that teams should start deciding on
how to prioritize their work items for this year. We'll let each team decide how
to do the item prioritization but we recommend having a real-time / synchronous
meeting (IRC or video meeting) to discuss all the potential goals.

If appropriate, you can reserve a time slot during the weekly meetings to have
this synchronous discussion. Just let us know in advance in one of the meeting
issues (e.g. #291).

Finally, if any of your goals for this year requires changes in any of the
rust-lang/* repositories and you haven't mentioned them in #256 or #269 then
please report them in #269 ASAP. We'll discuss prioritization of rust-lang
request during the next meeting (2019-01-15).

cc @rust-embedded/tools

[adamgreig]

Points from the WG meeting at Oxidize:

• Investigate SVD format alternatives or other formats
• Investigate alternatives to svd2rust code generation / API
• Is the svd2rust write function appropriate? Should we have write-from-0 vs write-from-reset or rename or remove write or..?
• Work on cross

[eldruin]

2019 finished. Maybe we can create a follow up issue for 2020. Nominating for next week's meeting.

[adamgreig]

Closing as we're now well into 2020; if anything outstanding from this list is still relevant please add it to the not-yet-awesome embedded rust list, or create a new issue to track it.