ECE EmbeddedToolsSummit2018

Note: The contents of this page refer to a past CDT summit. For information on other and possible upcoming summits visit CDT/summits

Embedded Tools Summit 2018

The Embedded Tools Summit 2018 will be held during the Unconference day at EclipseCon Europe 2018.

Date: Monday, October 22, 2017 Time: 9:30 - 17:30 Room: TDB More Info: https://www.eclipsecon.org/europe2018/eclipse-community-day and https://www.eclipsecon.org/europe2018/embedded-summit Note there is a small fee for the Community day to cover expenses.

Please feel free to add to the agenda and sign up in the attendee list. This summit is for all of us.

Note that new contributors to the Eclipse wiki do have their first posts moderated to help control spam. Once approved, you'll be free to edit any time.

Aim:

To discuss development and technical issues for the CDT project.

Agenda:

Ideas for Embedded Tools Conference Agenda

1. Managed Eclipse core build

2. Rolling out language server protocol and current status

  Feature roadmap
  Indexer

3. Code mining

  Photon - What can we do in CDT?

4. Rolling out debug server protocol and current status

5. Smart Demos - accessibility to complex features

6. Dealing with current CDT backlog and triaging new bugs

  4000 current CDT issues in the backlog (Newest to oldest)
  Automated error reporting
  Errors and workarounds can be provided?

7. Close old stale issues we have no intention of fixing? Perhaps last modified date?

8. Deletion of old code (CDT old and a new CDT project? for discussion)

9. Future areas to drive CDT?

  Any new things in development that people would like to announce
  Code recommender (Cloud information to recommend what is used most often)
  A.I. 
  User assistance, better refactoring? 

10. How do we grow our community and get help on core features? What do vendors who ship CDT in their products want to happen to the CDT project? Or are they moving away from CDT? Should we grow beyond the tradition Eclipse Java platform and help other platforms like Theia, Che, VS Code?

11. Trace Compass project update

Participants:

Mark Goodchild (Renesas)

William Riley (Renesas)

Phyo Kyaw (Renesas)

Jonah Graham (Kichwa Coders)

Doug Schaefer (BlackBerry QNX)

Thomas Corbat (Institute for Software)

Mario Pierro (IAR Systems)

Joakim Lönnberg (IAR Systems)

Johan Holmberg (IAR Systems)

John Dallaway (Code Confidence)

Evgueni Driouk (ARM)

Bernd Hufmann (Ericsson)

Umair Sair (Mentor Graphics)

Van Tran (Renesas)

Minutes:

CDT meeting: https://wiki.eclipse.org/ECE_EmbeddedToolsSummit2018

Participants: Mark Goodchild (Renesas) William Riley (Renesas) Jonah Graham (Kichwa Coders) Doug Schaefer (BlackBerry QNX) Thomas Corbat (Institute for Software) Mario Pierro (IAR Systems) Joakim Lönnberg (IAR Systems) Johan Holmberg (IAR Systems) John Dallaway (Code Confidence) Evgueni Driouk (ARM) Bernd Hufmann (Ericsson) Umair Sair (Mentor Graphics)

Managed build replacement based on core build: (William Riley - Renesas)

Simplified managed build. Less complex, easier to replace parts of the system. How to store options and how to edit. Current system is inconsistent how it saves options.

Exposing build settings in the project explorer. How to handle build configurations? File based settings – how to modify the settings for individual files. Section within the file for local options.

The format is currently JSON. Needs to be diffable and inheritable from the parent folder.7 William is thinking there is one in the root folder. John hears it is a common complaint and visibility of what the user has done to the build settings.

Doug – asks the question what is a project? John – hangs off the workspace loc and delivers a mechanism independent of the file hierarchy.

Jonah – is it an Eclipse project or a UI on CMAKE. William – Sync is an issue. Jonah – we use makefiles today. Could we generate Cmake files in the directories.

William is prototyping using Ninja. But should be replaceable – e.g. could swap out Ninja and use something else.

Forcing users to launch Eclipse to launch a build does not make sense. So should be an external build tool. However an internal build should be supported. If we are clever we should be able to provide both.

Mario (IAR) have been working hard to integrate the IAR project files better into Eclipse. IAR are looking at a similar solution. IAR EW (virtual file structure) and importing to Eclipse not easy as Eclipse is file system based.

The files which are going to be indexed should be defined in some way. Not just use what is in the file system.

Mario mentions there is an option that compiler and linker options is affected. William is looking at the options being a “bag of options” so one option can effect more than one of the tools.

Renesas are committed to first prototype early next year.

Moving from describing a toolchain in XML to describing an external build system. Could be a simpler task.

Could we somehow separate this whole system to make the GUI enriched CMAKE experience independent from the IDE? Sounds a good idea, generators would not have to be Java.

John mentions toolchain migration. If we are looking at something as fundamental as this we should be able to abstract the options (at least in part) of migrating from one toolchain to another. e.g. include paths, defines are universal.

Legacy? Perhaps run a translator to move to the new system. Meaning the old MBS would go. .cproject file? Something may still exist in that file.

Action: William to state when first proof of concept will be ready in early 2019.

Monthly CDT call:

Not so much happens on the call. How do we want to communicate? Are there other conferences we should gather at. CDT summit standalone event – sounds a good idea. Face time is a good idea.

Language Server Protocol:

Keeping up with C++ is going to be a big issue. Lots of language features and relying on few people to keep track of this for CDT. Probably not sustainable. There is an Eclipse plugin for LSP being worked on.

Debug Adaptor Protocol: (Jonah)

Next generation IDE and like LSP creating a debugger adaptor protocol. Based on the earlier Chrome debug protocol. Mikael has been working on this area along with Jonah. 2 ports of GDB DAP. There is one specialising Cortex debugging in VS code, Memory view, Peripheral view (.svd viewer) and Disassembly.

Multi-process is not supported currently. Each one is a separate set of connections. Memory, Registers and disassembly are not part of the protocol today. However the protocol is extendible.

Doug would like to kill DSF. It is hard to use. Get the debugger adaptor to a level that can replace DSF? DAP is asynchronous. John has some concern if we can deliver the performance.

Jonah has recently put in some updates so that contributors can more easily understand the optimisation techniques for view updating when stepping with DSF. (Removing redundant events is the focus here)

DAP is currently using the standard platform debug – there is no involvement with CDT right now.

IAR have struggled to get their (non-GDB) based debugger working with DSF. Hard to debug when it goes wrong. Hard to know when events you are not expecting are presented. Interested in Jonah’s fixes to DSF. John says more could be done in the debug trace functions in DSF to help log what is going on. Interpreting the messages is not easy.

We should take advantage of common parts to grow the community. e.g. clang has a huge community and we can leverage this for the indexer. Likewise DAP could enable wider debugger support. Enabling LSP and DAP allows a roadmap to the future.

Trace Compass (Bernd)

Trace visualisation tool based on Eclipse. Add tracepoints and they are shown in Trace Compass. Started as Eclipse Linux tools project. They were using Lttng at first. Way to integrate more trace tools in the system. Not just for Linux - started their own Trace Compass project to promote this. Many more features and visualisations added.

Bernd steps through the Trace Compass features.

Nice install extensions feature to pull in more Trace Compass functionality. We wanted a similar function to this for Renesas plugins we don’t want to bundle with the standard tooling. Live tracing is not currently supported. Trace Compass is post mortem tracing.

Renesas are using the charting of Trace compass in our product. John asks about people using embedded RTOS type tools – is there anything to help? Many developers will have the same problems – perhaps there is assistance that could be provided? Bernd says some embedded developers are using CTF format which can then be parsed by TraceCompass. (This is what Renesas are doing FYI)

Next generation IDE (Not based on Eclipse) Trace Compass team are looking at a Trace Server (similar in concept to DAP and LSP)

Deleting code:

Lots of code exists that is not maintained. XLC parser – could be removed. Parallel tools project – had some dependencies on ?

Idea to create a CDT x deleting all old code. Some support to this idea.

What about small time application developers. E.g. those using MBS today.

What about the larger companies?

Make a proposed roadmap. Advertise our thoughts. Have a CDT workshop to then discuss the plans. Could we contact them and push them to join us? E.g. NXP, Nvidia, ST, etc. Some of the companies are 2-3 years behind.

Very few patches recently for MBS. Very hard to review this area – hard to determine if the patch breaks something.

New GIT repo? Sounds like it would be and functionality copied across.

Some confusion about the Eclipse release strategy. Platform is allowing more minor versions than before. So far CDT has done 6 month cadence. Platform is doing 3 month cadence. CDT target platform is Photon. If we need a new feature then it will switch to the latest platform. Jonah tests the latest platform and Photon.

Old bugs:

Just close bugs older than 2 years old. Then if the reporter is interested they verify it still happens and re-open it.

Meet again at a CDT conference in perhaps March. Earlier meet up on Core build when we have it scheduled.