|
|
|
|
|
|
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
DEVELOPERS CORNER |  |
 |
 |
|
FREQUENTLY ASKED QUESTIONS - Development and Support Have a question? Send it to info@zucotto.com
1.1 Why
would someone want to use Java in an embedded system?
The two main reasons are connectivity at the application level of the target system and a better software development process. There is no better environment for service delivery than Java. First, the ability to securely download code from the Internet and run it in locally is the most compelling reason for using Java. In the age of e-commerce, services can be anywhere on the web and having the ability to provide a service for a very low cost to your customers will eventually be a must as the Internet's reach extends beyond the desktop. As a bonus, the development team benefits from a very elegant programming language for all your code, from your applications to your drivers, which includes concepts that are important to the design of embedded systems. While Java will not turn anyone into an embedded software expert, it can make both senior and junior firmware designers more productive.
Beyond the advantages mentioned above, Sun has made Java even more suitable for embedded applications by grouping its technologies into three editions: Micro (J2METM), Standard (J2SETM), and Enterprise (J2EETM). Each edition features:
J2ME specifically addresses the vast consumer space, which covers the range of devices ranging from cell phones, pagers and PDA's all the way up to the set-top box, an appliance almost as powerful as a computer. J2ME is further divided into two configurations, Connected Device Configuration (CDC) and the Connected Limited Device Configuration (CLDC) as seen in the diagram below.
J2ME Architecture Referring to the above figure, the J2ME architecture is composed of configurations and profiles. A configuration is composed of a minimal layer of core libraries designed to provide just enough functionality to safely and securely download Java classes to a device and configure the Java environment. The rest of the functionality needed to provide a complete runtime environment for a particular kind of device is provided within the context of an industry defined profile. The first configuration, the Connected Device Configuration (CDC), uses the classic Java virtual machine. This virtual machine is a full-featured virtual machine with the same functionality you would find in the virtual machine residing on your desktop system. The second configuration, the Connected Limited Device Configuration (CLDC), uses the K Virtual Machine, a small footprint virtual machine for severely memory constrained environments. The CLDC is targeted for Java environments of 128-512KB, and the CDC is targeted for Java environments of greater than 512KB. Zucotto has designed an end to end solution for wireless Internet and mobile multimedia products initially targeted at CLDC type devices and extending Java capabilities to these devices in emerging wireless technologies such as Bluetooth, 802.11 and Home RF.
1.2 Why would I want to use KJava rather than Personal Java? Sun has taken their first 5 years of experience with Java and gone back to the lab to create K Virtual Machine (KVM). It wasn't an attempt to shrink current virtual machines down into these devices, but instead it is a clean slate implementation designed specifically for embedded systems. When designing the KVM, the engineers based their design decisions first on lower memory footprints. Moreover, ramping up on the KVM is possible in a week or so for a designer
already familiar with virtual machine concepts.
1.3 Why would I want to use Personal Java rather than KJava? Preferably don't. From our experience, Personal Java is still large for embedded systems and really works only in the same context as enterprise Java, which means unlimited resources. It would be possible to build a working Personal Java embedded device, but anyone who tries to compete using a KVM solution would most likely beat you in terms of price, performance and time to market. If your product is more or less an embedded computer which is not cost-sensitive
and your project manager is known for his patience, Personal Java is worth
considering. You can freely download the Personal Java source from the
Javasoft and see for yourself if Personal Java is for
you.
1.4 How do I port KVM on my hardware platform? You have three options, in increasing order of complexity:
Being aware of the fact that exercising a same piece of software onto various hardware platforms brings more intermittent problems to light, we like the first option as it allows us to validate our integration process on one more hardware platform.
There are other options than a hardware virtual machine. Some companies are using a precompiler, which turns a set of Java classes into native code. There is merit to this approach which would provide the best of both worlds if it indeed worked. We are however highly skeptical regarding the debugging of such a system. It is already challenging to debug an embedded Java system with the many layers required by a JVM (OS, KVM, interrupt context, applications and Java applications) that running Java code through a "nativizer" which obfuscates most of the debugging information adds too much risk to an embedded project.
1.6 What is Zucotto's approach to putting a VM into hardware? First of all, we do not put the entire KVM into hardware, only components
requiring large amounts of processor time, thinSlice and the support layer
handle the rest. In our efforts in this area, we have created design tools
for ourselves that are optimized for our process and we incorporate these
in the design tools that we offer you for developing your embedded application.
We are making our embedded Java platform the path of least resistance
between your requirements and the solution.
Hardware in general, resources and drivers in particular. The Java paradigm of "write once / run anywhere" works well in the context of desktops where resources are effectively unlimited and crashes are more or less tolerated. Embedded systems have very different usage profiles. To mention only a few:
A successful (and by successful, we mean timely and quality integration)
port must be respectful of the context of embedded products, therefore
require more hardware awareness than the promised "write once / run anywhere
on the designer's part.
1.8 What are the non-technical issues to be aware of in the design
an embedded Java system? As much as possible, do not segment your development team into one Java team and one native team. In all the cases we have seen, this split resulted in a polarization of cultures and an "us versus them" mentality. Our model makes it easier to avoid this pitfall as there is no native
team.
1.9 Do you have an associated Debugger/Monitor with Whiteboard? Yes. We added some basic debugging features to Whiteboard and will
add some more as it evolves. Current features are non-intrusive, they
do not affect the system.
1.10 What is your environment? Does Zucotto provide an IDE? We don't provide one. What we do provide are simple, powerful tools that integrate into your environment, similar to Sun's approach with the JDK. We may provide an IDE in the future, but we will make sure that this does not limit you.
1.11 How will Zucotto reduce my time to market?
From the start of every embedded Java project, there is a vision. The product takes shape in the brains of a group of architects who look at all the features that can be put into a client device given a set of services somewhere across a network, public or private. The idea takes shape and when product managers are confident that the product meets customer needs, the design is launched. The traditional approach can be characterized as backwards looking. Selections are made with respect the processor, the RTOS and the wireless chipset. You then design hardware and layout, negotiate JVM licensing and have the RTOS vendor integrate the JVM onto the chosen processor. Next, the processor, JVM, RTOS, Wireless chipset and Wireless protocol stack from a variety of different vendors must all be integrated! You then face the task of debugging integrated "plug and play" units. You can only start planning for integration at the end of this process! Overall, this process results in heavy integration effort, large integration risk, large project management effort, constraining integration schedule dependencies and supplier delivery dependencies. In contrast, our approach is forwards looking. Our solution is highly integrated, you deal with one supplier, and we will work with you to fill in any gaps. Our emphasis on process means that you can proceed forward from the moment you choose Zucotto. We reduce effort, risk and schedule dependencies in the integration area plus we reduce your project management effort and dependencies on supply schedules from multiple vendors. Time to market and costs decline, plus you will sleep better at night! Overall, we put have put a strong emphasis the process of "getting there" so that you can move forward.
|
|
Home | Corporate | Products | Sales | Media | Careers | Technical | Contact | Recipes
|
 |
