OpenArbor RoadMap

From DDCIDeos
Jump to navigationJump to search

This page documents the OpenArbor team's plans for current and future releases.

Current Stable Release

OpenArbor_12.0.0

Open PCRs by Category

OpenArbor PCRs by Category

Integration Tool UI

DDCI_PCR:2967: Provide a GUI for the integration tool. A good first step is to provide some read-only views for the output of the integration tool.

Continuous Integration Testing

DDCI_PCR:2752: Have the OA test system detect when a new DDS is available for testing, run the OA automated test suite automatically.

Develop BSPs with OpenArbor

  • DDCI_PCR:2601
  • We need a BSP devkit that does not depend on our internal maintainer-tools cygwin suite. MH and BC will give us the greenlight on the following steps once this has been done (sometime in 2014?).
  • OpenArbor Makefile and maybe Target Manager integration for building BSPs.
  • Debug BSPs using OpenArbor and JTAG.

Implement a JTAG Interface for Target Management

Investigate tool control framework (Trace32) as a replacement for JTAG.

A company-wide goal is to provide a way to develop small footprint applications using Deos. By using JTAG instead of TCP/IP, we could reduce the memory footprint on the target by using JTAG to fill the same roles as our standard app's ftp, status monitor, network, etc.

To accomplish this, would require coordination between the OpenArbor, Deos and TRAC product teams.

Build System

Improvements to the build system on our wishlist:

  • DDCI_PCR:2096: Better support for building from the command line.
  • Continue the "478" roadmap:
  • Allow users to make their own "desk tree" content (also helps DDC-I developers make the "real" desk tree content):
  • "dogfood": Allow and encourage DDC-I developers to use OpenArbor for Deos development:

Automated Testing

DDCI_PCR:2697: Consider ways to help users accomplish automated/batch test runs for their applications within OpenArbor.

Linux Host

Requested by marketing (and several customers).

Memory Map Report

Aaron Ideas/Thoughts

In the target manager, the status monitor context menu:

  1. uses an icon for "enable" that looks more like a "refresh" icon. I suggest a "check mark" when it is enabled, and a blank otherwise. Like the "Build automatically" button in the "Project Properties".
    Actually all the tree views have the same issue.
    1. A, slighly, more radical suggestion is to remove the enable button entirely. If every tree view had an associated window, then closing the window disables it. I realize that ping is different, but I have a solution for that if you are interested.
  2. The "Auto Update" should also be an "enable/checkmark" option rather than an icon.
  3. The default auto refresh rate of 300ms seems an order of magnitude too fast, i.e., it should be at least 3 seconds, or probably better yet 5 seconds. I'm not sure what the use case is for auto refresh. I wouldn't expect it would be commonly used.
  4. The "Manual Update" item seems like it would more appropriately be called "Refresh", or "Reload". Its action is tied to F5. If you google for "F5 key" "refresh" and "reload" are the terms most frequently used to describe it. If you do make this change, the automatic verbiage should be consistently updated.
  5. DDCI_PCR:2372: The F5 refresh capability is only enabled when the status monitor tree view has focus. When one of the processes in the tree view is selected, or the status monitor window has focus, F5 doesn't work. It should.
  6. The F5 key should be noted as a keyboard accelerator in the context menu.
  7. The icon for "Manual Update" should be more like something you get when you google "refresh icon".
  8. In the tree views I've used, when something in the tree view is selected, the associated "right hand window" is usually made visible. For OA, when the status monitor tree view is clicked, the window showing status monitor should be displayed. I'm not sure if a single click should do it or if a double click should be necessary. In the project views it currently requires a double click. The video stream already behaves in my desired manner.

Target manager

  1. In the "new remote target" dialog, when t10xx (proably all non-qemu targets), or "no load list support" is selected the text box for the hostname is very small.
  2. When no "load list support" is selected and a timemap is gathered:
    1. when a save of the timemap is attempted, the default save location defaults to something rather strange, definitely not within the workspace
    2. When the timemap is saved, the timemap window still shows the need to save (there is still an asterisk next to the "TimeMap".

Event logs:

  • Something seems odd about this:
    • The events logged by logSystemEvent() show up in the scheduling log.
  • After a logSystemEvent() in the timemap, there is a similarly timestamped event for "executing on fixed budget". This also appears to happen after exception events, e.g., TBE, which is even more confusing.

In the status monitor "Process" tab:

  1. it would be nice to have three independently selectable options for "Select Quotas": initial, remaining, used. Hopefully we'll eventually have "low water mark" to also report. At least for now the values should be selected with checkboxes rather than a radio button, with a title of "Displayed Quotas". It would be nice if the checkboxes and the title were on the same line to conserve vertical space.
  2. The quotas display takes a substantial amount of horizontal space, it would be better if the columns were slightly smaller, and the titles provide a tooltip containing the full column title. The "Threads" tab has a similar issue.
  3. It would be nice if the columns provided sorting.

In the status monitor "Threads" tab:

  1. The "Thread Name" and "Thread Template" values should be left justified. In general text strings should be left justified, numbers right justified.

When a project is deleted, if that project is in use by some other project, it would be nice if the dependency was noted and resolved, e.g., the user offered an option of removing the dependency.

  • When a dependency is selected in Deos Component / Dependencies, the "delete" key should work.

In the target manager, the title for one of the text boxes is "hostname", it should be "target name or IP". At least "host" should be "target".

In the target manager there are three user interface idioms that deal with managing the state differences between the user's desire (as expressed by the load list and selected platform registry), and the current target state:

  1. Button: Edit Attributes
  2. Button: Update Target Load
  3. Tree view: load list manager

The two buttons are very similar in functionality.

The load list manager doesn't have an associated "window" (I'm not sure what the proper term in Eclipse is), like the status monitor and video stream tree views do. I don't know why I would activate the load list manager, or for that matter do anything with it.

I propose that we eliminate the two buttons and create a window associated with the load list tree view. The window would show, conceptually, the current desired state, and the current target state and provide a way for the user to reconcile them. E.g., an "Apply" button. The window contents could be, effectively, the same as the dialog for the "Update Target Load" button.

This would de-clutter the button list and provide some useful feedback that the load list was active and a more uniform way to deactivate it.

It would also eliminate some modal dialogs (always a good thing), and provide a place to specify other more persistent behaviors, e.g., a "Reconcile differences automatically" setting for the load list to permit OA to update the target load automatically when an executable was rebuilt, or when the target was rebooted.

Regarding Timemap: DDCI_PCRs:3133,3165,3187,3189,3190

  1. Currently the "time map details" window shows a "Duration" field that is the delta time between events in the original event sequence. When a thread, or "System Events" is selected, the details window only shows the relevant events for the selection, and that is a GOOD thing. However, I believe the duration in the details window should be adjusted to show the duration between events being displayed, not the duration in the original event flow.
  2. It would be very handy to be able to further filter, by type, the events in the details window, and perhaps the graph window. For example, being able to indicate that certain event types (e.g., system tick, or "executing on fixed budget", be suppressed. A context menu would be fine UI, or a tabular display of the events with a multi-select. A particular use case is that I wish to verify the periodicity of an event, say system tick. If I could indicate that only system tick be displayed, then the duration should be the same from event to event.
  3. I'm less sure of the value of this, but I'm often concerned about variation from periodicity, i.e., the difference between the duration of adjacent events. My suggestion is to display the variation in another column, either between adjacent events, or between adjacent events of the same type. That would be a very quick way to show how periodic an event sequence is.
  4. It would be nice to be able to sort and/or filter, the detail window by "Core", the secondary sort key would be timestamp.
  5. If item 2 above is resolved via a context menu, then I suggest adding "show event in graph" as well. The use of "double click" on an event in the details window is not obvious, and having another means to make the capability apparent would be a good thing. Another possibility is another "box" like the "colors", and "multi-select" boxes below and to the right of the graph window, that toggles between "Single click on events in details window to select event in graph window" and "Double Click on events...". Having the graph window follow the selection in the detail window would permit keyboard navigation of the graph using the arrow keys, in the detail window.
  6. If item 2 above is hard, and item 4 is easy, then an alternate for item 2 would be to permit sorting on Event Type and perhaps Thread Handle. That way I could see all the System Tick, or Window Start events together and then the duration, and deviation, data would also be apparent. I believe three sort keys would be sufficient, e.g., core, then event type, then time, or just have an option to group by core.
  7. I thought we had a way to have the graph window group events by core, but I could not find that capability.
  8. The width and height of the scroll bar buttons do not scale to indicate the percentage of the graph window displayed.

Results from "first user experience" using OA to run an example:

The "help contents" doesn't appear for me unless I first request a help search.

DDCI_PCRs:2952,3149: After creating a platform project, the "new remote target:" button presents several detailed configuration items that should be hidden behind an "expert" or "more" sort of interface so that the first time user is not presented with so many things they wouldn't know what to do with. Alternatively, "new platform project" could create the target with the default settings and leave it to the user to use the "edit remote target" dialog if changes are needed. If you want to get fancy, the new target dialog could only be shown if there was missing data, like the IP address.

The "Import Deos Examples" dialog should default to the architecture of the currently selected platform project.

The basecon.hyp is renamed to bootimage.hyp in OA. I don't have a problem with the new name, but if we're going to rename, should we change the name in the BSP?

When OA exits, any OA started QEMU virtual machine processes should be killed.

DDCI_PCR:3150: The 653 tabs should not appear unless the target has 653 enabled.

Completed Roadmap Items

2017

DDCI_PCR:3127 Time Map sorting/filtering enhancements

DDCI_PCR:3148: When OA starts in an empty workspace, the first screen should contain a link to some sort of an overview/ introduction/ thanks for trying OA. At least something that points them at what to do first. I suggest the "Introduction" section of the OA User Guide. If that is chosen, a few more sentences there would be helpful to get more context, e.g., OA is IDE for developing, debugging, testing applications using Deos, HeartOS, .... Then a suggestion to go to the quick start guide to run an example, and a link to support@ddci.com.


Event logs:

  • AL: Something seems odd about this:
    • The events logged by logProcessEvent() show up in the "System Events" log.

DDCI_PCR:2555 Status Monitor tab names are misleading

2016

Build System

  • DDCI_PCR:2400: Parallelize project builds for better performance on multicore workstations.

Eclipse 4

Evaluate Eclipse 4 and consider upgrading OpenArbor to use it.

BPH's notes: Just for giggles, I fired up OpenArbor self-hosted in Eclipse 4.3, and everything mostly worked. Partly as a result of Eclipse 4.3 and partly due to getting the latest versions of some components, a few things were missing.

  1. The Matchers class from SWTBot is gone or moved or merged or something.
  2. The org.eclipse.update.core plugin, from which we were using SiteManager.handleNewChanges, is no more.
  3. The common IDE plugin had a dependency org.eclipse.ui.presentations.r21, which wasn't used anywhere.
Retrieved from "https://ddci.zapto.org/ddciWiki/index.php?title=OpenArbor_RoadMap&oldid=57616"