1 / 12

From the Horse’s Mouth

From the Horse’s Mouth. What Embedded Developers Like and Dislike About Eclipse-Based Development Tools. The Product. The ON Semiconductor SignaKlara Development Environment An assembly and C development environment Based on Eclipse 3.3 (and very soon Eclipse 3.4)

velasco
Télécharger la présentation

From the Horse’s Mouth

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. From the Horse’s Mouth What Embedded Developers Like and Dislike About Eclipse-Based Development Tools

  2. The Product • The ON Semiconductor SignaKlara Development Environment • An assembly and C development environment • Based on Eclipse 3.3 (and very soon Eclipse 3.4) • Fairly small user base (relatively speaking) • We make money on silicon, not software • Target devices are ultra-low-power DSPs with very little memory and no OS! • Multi-core (DSP and re-configurable co-processor)

  3. The Product (continued) • Not based on the CDT • Platform-only (plus CVS support) • Assembly-language development environment • Some C support • External toolchain called from our Eclipse-based build system via Ant • Custom debugger implemented in Java • Scriptable with Jython • Underlying C++ communications library • Primarily USB/serial connection to embedded target

  4. The Survey • Targeted sample of ~30 developers • Anonymous, administered with SurveyMonkey • Approximately 60% internal, 40% external • Surveyed developer characteristics • 71% medical devices, 25% consumer electronics industries • 58% spend most or all of their time developing embedded software • 68% have been doing embedded development >5 years • Languages used daily • Mostly assembly (87%), Python (65%), and C (49%) Consumer Electronics (25%) Other (4%) None (8%) All (13%) Some (33%)

  5. The Survey (continued) • Familiar with Visual Studio (92%), Code Composer (33%), and Code Warrior (17%) • Over 90% of respondents were Satisfied or Extremely Satisfied with our Eclipse-based product • 76% have never used any other Eclipse product, but 100% knew our product is based on Eclipse Somewhat Satisfied (9%) Extremely Satisfied (24%) Somewhat Dissatisfied (0%) Extremely Dissatisfied (0%)

  6. The Good • Most liked features • Debugging embedded applications on target devices • Building source code into executables and libraries • Source code editing and modification • Top rated items in terms of user satisfaction • Source code editing and modification • Application look and feel • Building source code into executables and libraries • Debugging embedded applications on target devices • Application usability

  7. The Bad • Biggest Eclipse-specific gripes: • Application performance (>30%) • Source code organization and project management • Lowest rated in terms of satisfaction • Application performance • Source code organization and project management https://bugs.eclipse.org/bugs/show_bug.cgi?id=35973([resources] Better project organization) • Is this really a platform issue or a build setup issue?

  8. Summary • 65% of respondents think our Eclipse-based product is somewhat better, or better by farthan other products they have used in the past. • 60% of respondents say that our Eclipse-based product is their favorite product for embedded development. • On the whole, embedded developers like Eclipse, but perhaps are not aware of other plug-ins. • Eclipse’s reputation precedes itself. No Better / No Worse (25%) Slightly Worse (10%) Far Worse (0%) Better By Far (10%)

  9. Interesting Comments • A recurring feature request was some way to graph memory. A graphical rendering for the memory view may be useful. • Suggestion of the concept of configurable levels of abstraction (Capabilities?). Perhaps this feature could be leveraged more?

  10. Questions?

More Related