Embitel Partnership with CMD to offer Engine Control Unit Solutions

Embitel has a partnership with CMD (COSTRUZIONI MOTORI DIESEL S.R.L.) to provide services in the area of Electronic Control of Engines. CMD’s strong system know-how, control strategy expertise and calibration expertise complements Embitel’s expertise in the area of automotive embedded systems. Together we offer customized solutions for electronic control of diesel and gasoline engines.

Statement:

Embitel - CMD is offering solutions in the area of Electronic Control Units. The ECU for Diesel Engines is already under series production, and is calibrated and used in various applications in Marine, Automotive and Avionics domains. The ECU supports Common Rail Direct Injection systems and can be calibrated for engines ranging from 1 to 6 cylinders. The gasoline ECU is being jointly developed by CMD and Embitel. The advantages we offer to our clients include lower development and customization costs, faster time to market, and higher participation and know-how sharing with customers.

About CMD:

CMD develops internal combustion engines, both diesel and gasoline, and related control systems (eg ECU). CMD Mechatronics was born from the spinoff of the group R&D of CMD Electronics SpA (www.cmdengine.com) company in the field of advanced design of internal combustion engines and hi-tech manufacturer of FNM marine engines (www.fnm-marine.com).

CMD Mechatronics design customized electronic systems for scientific and industrial fields and implement them as prototypes or for series production. Since its inception in 2000, CMD Mechatronics focused primarily on the design and development of electronics and software specifically for diesel engines.

Today CMD is available to cover every phase of the engineering design of a diesel and gasoline engine control system offering a wide range of services from PCB design services to the reengineering and migration in a complete and responding to customer specifications.

About Embitel:

Embitel (www.embitel.com) was established in 2006 and currently employs about 130 people in Embedded Systems.

Embitel is an ISO 9001:2008 certified by TUV, a young entrepreneurial company offers specialized services in embedded automotive and Industrial automation. Embitel is headquartered in Bangalore along with operations in London and Stuttgart.  

Top 10 mistakes in Eclipse Plug-in Development

Not reading the JavaDoc

This is nothing specific about Eclipse Plug-in development. Its more common among the Java programmers, or probably a common thing among all the programmers - not reading the documentation. How many of you know that there are classes that shouldn't be inherited or the interfaces that are not supposed to be implemented by you? Well API tooling will help you, but there are lot of other corner cases which you won't find unless you read the JavaDoc. I myself do this mistake all the time. Honestly for a long while I didn't know that a command's handler is supposed to return only null (which is the result of the execution)- When did you know this?
In case you didn't know, JDT provides you a JavaDoc view which shows up the Java doc with the formatting.

Forgetting to add a default constructor

You had that nice wizard class which works fine when you create it yourself and put it in a WizardDialog. But you can't make it work with the INewWizard. After a "little" debugging you realize that you didn't have a default constructor for the Wizard class! Yes, its not just the Wizard class, but most of the other classes that you specify in your plugin.xml for that "class" attribute, should have a default constructor, as it will instantiated thru reflection.

Not decomposing into different plugins

Another common thing among the newbies. They have a tendency to put everything into a single plug-in. Splitting your code base across different plug-in improves the modularity and maintainability. You should at least consider splitting the core and ui part, so that testing the core part becomes easy.

Using "internal" code

I've seen this as an unavoidable thing in many cases. You see some functionality in the internal code that you would require, so make use of those internal classes. There are thousands of internal classes, but believe me, the one that used will be refactored and changed in the next release, so you will have a hard time upgrading to a newer release. It has happened to me more than once. Why *that* class of all the classes? sigh!
If you find any internal code generic and useful, raise a bug to make it a part of API. Instead of using the internal classes, you can copy the code into your code base and make use of it.

Directly setting the classpath

 

Every plugin project is a Java Project, but that doesn't mean that you can simply update the Java classpath with the jar files that you require. Because your plug-in's classpath at runtime will be different. If you had to add a jar to the classpath, you should consider adding it thru the 'Add' button in Classpath section of the Runtime tab.

Ignoring build.properties

Most common mistake among the newbies. Add an icon/resource under a new folder; test the plug-in, which works fine; export it and deploy it elsewhere; it stops working. Reason? The build.properties didn't have an entry for the folder/file that you added, so the exported plug-in doesn't have that resource. So, remember, whenever you add a folder/individual resource, make sure you update the build.properties file as well.

Empty dispose method

Remember the the golden rule, "When you create, you dispose". SWT resources like images and fonts should be always disposed of when you are done with them. I've seen many people not doing this at all. Another important issue is when you are overriding the dispose method, you should always call the super.dispose() to ensure the resources created by the super class are properly disposed. Also, if you have attached any listeners like IPartListener or IResourceChangeListener, during the life cycle of your class, you should consider removing those listeners in the dispose method.

Not honoring monitor.isCanceled()

Your Job does a lengthy operation and the user might want to cancel it. It can be done by pressing cancel in the ProgressMonitor dialog or in the Wizard or thru the Progress View. What ever way he does, the IProgressMonitor supplied to you will have the cancel flag set to true. Its your responsibility to periodically check the isCancelled() and abort the operation. When the user presses 'Cancel' and if nothing happens, believe me, its a very bad user experience.

Blindly contributing to everywhere

People tend to add their contribution virtually everywhere thinking their plug-in is the important one to the user. But hard fact is it will be annoying for the user. So:

• Stop adding your view to every perspective that you know
• Do not extend org.eclipse.ui.startup unless its really, really, necessary
• Do not make your action set to be visible in all the perspectives
• Try not to create a modal dialog
• When you adding menu items thru objectContributions, try to add it to the specific class, rather than simply Object

Executing a long running operation in Display thread

Do I need to tell about this? Not just newbies, even experienced ones tend to do this mistake. In my present job, I have to use an internal RCP application on a regular basis, does this mistake for almost all the operations. The end result is a non-responding UI and a very frustrated user :-(  Once I pointed out a piece of code and asked a developer why he was doing such a big calculation on a Display thread, he was very surprised. He said that he is neither doing a Display.asyncExec() nor a UIJob, so the code will not run in the display thread. Here is a thumb rule. The operation that you do inside the SWT listener methods will be run in the display thread. There are more than few people who don't realize this and think that only the that gets executed in Display.asyncExec or Display.syncExec are the ones that run in the UI thread. So don't do long calculations or contact a server across the network in those listeners. If you have to run such a lengthy operation, spawn off a separate job and return quickly, so the UI remains responsive.

Source: http://blog.eclipse-tips.com/2009/01/top-10-mistakes-in-eclipse-plug-in.html

TVS and Embitel collaborate

Software testing and hardware verification provider TVS opens office in India and takes part in a UK trade mission to the country.

UK company TVS, a supplier of software testing and hardware verification solutions, has opened an office in Bangalore, India. The office, which is a joint business venture with local company Embitel, aims to bring chip verification and validation services to the Indian market, but also offers TVS’s UK and European customers a safe route to off-shore development in chip design and verification.

TVS specialises in providing software testing and hardware verification solutions to customers in the software and electronics industry either by providing highly-qualified and experienced verification engineers for an in-house project, or by organising off-shore chip verification services through a blended delivery model.

“A number of companies recognise the benefits that off-shore development brings - mainly access to large numbers of highly educated, professional engineers - but find it difficult to find the right partners and then execute on their projects,” says Mike Bartley, CEO of TVS. “Managing off-shore development can be a challenging process, but at TVS we have many years experience of handling such projects for our clients. Now with our new Indian office we are validating our long-standing relationship with the country and our confidence in the skills and expertise of its engineers. Our blended delivery model provides the local support to companies in Europe along with access to the talent pool in India.”

The company is already executing projects in Bangalore and Embitel has a good reputation in bringing embedded software development services to that market.  

“This joint venture will benefit the customers of both companies,” said Sharad Bairathi, managing partner at Embitel. “Our joint partnership provides a fuller range of expertise and gives us the ability to take on full product testing through use of hardware and software expertise as well as complete product development.”

TVS recently identified several major opportunities in the European market and is now recruiting into its Indian office to service those opportunities.

For more information, please contact:

Mike Bartley, CEO, Test and Verification Solutions (TVS)

Tel: +44 (0)7796 307958; mike@tandvsolns.co.uk

About TVS: TVS (Bristol, UK) delivers an independent testing service that not only reduces costs and time-to-market, but also improves product quality. TVS combines skills and experience in software testing, hardware verification and outsourcing to provide customers with an efficient, well-managed, quality assurance service. The company provides both consultancy and execution services using experienced engineering resources in several locations around the world. TVS customers include ARM, Panasonic, Dialog, DisplayLink, Icera, ClearSpeed, XMOS and Gnodal. Its technology partners include Cadence and Mentor Graphics.

www.tandvsolns.co.uk

About Embitel: Embitel has extensive experience in full lifecycle of embedded development and testing of real time complex solutions for global customers. Its technology partners include Texas Instruments, ARM, Samtec, CMD, Comlet, escrypt and Microchip. Embitel is also rated among TOP 21 innovators in India by NASSCOM.

www.embitel.com

Eclipse Plug-in Development Services

Embitel has extensive experience in design and development of Eclipse Plug-in’s using Eclipse framework for our global customers. Our engineers have prior experience of developing plug-in for Eclipse using JAVA programming language, being involved in all phases of the development lifecycle starting from requirements up to system testing. We leverage on this experience together with good embedded system knowledge to provide end to end product solutions to our clients.

Some of the main service offerings include design, development and testing of Eclipse plug-in’s using the following areas:

1. Launching and debugging the embedded application using Eclipse CDT (C/C++ development tools) plugin.
2. Rich Client Platform (RCP) Applications.
3. Profiling of the embedded applications, using following technologies
• Draw2D and Graphical Editor Framework (GEF) Programming for charts.
• Prespectives, Views and Editors.
• Resources.
4. Eclipse Modeling Framework (EMF)
5. Custom update manager and update site

Our team has expertise in Eclipse plug-in development on the following platform and IDE’s.   

OS & Framework	Linux, Windows, Cross-Platform Deployment, Eclipse work bench.
Integrated Development Environment	Eclipse IDE

Contact Us for a more detailed explanation and discussion on the scope of our Eclipse PlugIn Development Services for your organization.