Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Bailey O.H.Embedded systems.Desktop integration.2005

.pdf
Скачиваний:
73
Добавлен:
23.08.2013
Размер:
9.53 Mб
Скачать

450

Chapter 11 / Cross-Platform Application Development

 

 

The User Application Layer

The user application layer can be implemented using a number of methods, languages, and tools. Now you may be asking exactly how we can write applications that execute unchanged on several different platforms. Let’s start by looking at our choices for application development.

Commercial Compilers

We have an assortment of commercial products to aid in our cross-platform efforts. For our purpose we will examine two commercial products: C++ Builder and Delphi, both from Borland International. There are actually three flavors of these two languages.

Delphi/Kylix

Delphi evolved from the old Turbo Pascal from the DOS days. Several years ago Borland introduced Kylix, which is Delphi for Linux. Both products support extended controls for their native platforms, but a cross-platform library called CLX is also included. Developing a program on one platform using the CLX controls allows the project to be ported to the other platform and compiled with little or no changes (if the proper development steps have been taken).

C++Builder

This product is the C++ equivalent of Delphi/Kylix. Unlike the Pascal products, C++Builder is named the same for both Windows and Linux. Also, like the Pascal version, native control libraries are available to take advantage of platform-specific controls, or the CLX library can be used. Again, using the CLX library provides easy cross-platform porting and compiling.

Chapter 11 / Cross-Platform Application Development

451

 

 

C++BuilderX

This product differs from C++Builder in that the IDE is functionally identical on all implemented platforms, which are Windows, Linux, and Solaris. Even the debugger functions identically across all platforms. This product supports a number of compilers including Borland, Microsoft, GNU, and Solaris. New platforms can also be added. I cross-compiled the 64-bit GNU x86 compilers and added it to the tools list. Doing this allowed me to compile for a 64-bit target on a 32-bit machine, but debugging still needs to be done on the target processor.

GNU Compilers

Someone recently told me they weren’t sure if they wanted to support the GNU compiler because they were hesitant to support new technology. The GNU compilers have been around for many years and have been the compiler of choice for UNIX for almost 20 years. If you ever used the old AT&T UNIX or DEC Ultrix and developed a C program, then chances are good you have already used the GNU compilers.

In fact, the GNU compilers are available for many embedded platforms as well. All our NetBurner code is developed in the GNU C compiler for the Motorola Coldfire processor. The GNU compilers are even used to test against ANSI compliance since they are strictly ANSI. The GNU compilers offer a wide variety of languages such as C, C++, Java, COBOL, and FORTRAN, just to name a few. In short, there isn’t another compiler on the planet that supports as many languages as the GNU series.

Application Frameworks

What is an application framework, you ask? For the purpose of this book an application framework is a tool that allows us to develop a user interface that can be compiled and used unchanged on multiple platforms. We will examine wxWidgets, which is an application framework that allows a user interface to

Chapter 11

452

Chapter 11 / Cross-Platform Application Development

 

 

be developed on one platform and then compiled on other platforms while providing the same look and feel on all of them. What’s more, some of these platforms can be integrated into cross-platform compilers, allowing development and compiling from within the same development environment on multiple platforms.

Common Application Layers

This differs from the application framework because the execution layer has been separated from the compile and link layers. In short, the same program image runs on multiple platforms without change. This is the newest of the technologies and this design is prevalent in the .NET framework. Now .NET doesn’t run on Linux but the open source equivalent Mono does. I have been able to compile a program on Mono for Windows and run the executable on the Linux Mono runtime. By the time this book hits the market there should be tools and languages that allow you to develop a program on .NET and run it on .NET or Mono on any platform. Stay tuned to www.time-lines.com for this.

The Device Interface Layer

OK, so we have several options in writing cross-platform applications: What about USB, RS-232, and Ethernet?

Well, the answer to this lies in the design and implementation of our shared libraries or DLLs. None of the host communications methods is functionally the same on Windows and UNIX/Linux. In order to accomplish a single-source solution, we will have to write a middle layer that provides a consistent functional interface between the application and device layers. In this layer we will hide the platform-dependent code and distribute the shared objects in executable form only. This will allow us

Chapter 11 / Cross-Platform Application Development

453

 

 

to take advantage of single-source application coding practices while providing a black box approach to the hardware interface layer. Best of all, once we have the middle layer coded and working, we will never again have to develop a platform-dependent user application unless we choose to do so. So where do we start? We will begin with the Ethernet wrapper, move on to USB, and finish the middle layer with the RS-232 implementation. Then we will move on to develop our application layer.

The Ethernet Software Interface

This may come as a shock but Ethernet was implemented and working on UNIX years before Windows existed. Remember, the Internet was developed on UNIX. As the software implementations of the Internet protocol was being built, it was documented and put up for public access. All documents that describe how the Ethernet transport protocols are implemented can be found in RFC documents (look for resources at www.wordware.com/files/ embsys or the www.time-lines.com web site). When Microsoft implemented Windows, they did so using the RFC documents to be compliant with the existing protocols.

Welcome to the World of Sockets

The method of implementation for Ethernet at the software level is called a socket. This term comes from the days when telephone operators inserted a plug into a socket to complete a connection. There are several ways of communicating using the Ethernet transport, but for our purposes only two will be used: TCP/IP and UDP. As I’ve mentioned earlier, TCP/IP is a dedicated connection between two systems and UDP is connectionless.

The UNIX and Linux versions of Ethernet sockets are called Berkeley Sockets. The Microsoft implementation is called

Chapter 11

454

Chapter 11 / Cross-Platform Application Development

 

 

Windows Sockets, or WinSock for short. While the resulting protocols are identical, there are some fundamental differences in how Windows implemented TCP/IP sockets. This is mostly due to differences in the Windows and UNIX architectures.

The similarities between Berkeley Sockets and WinSock make developing a middleware interface layer a fairly straightforward task. With that in mind, we have three options for how to develop our Ethernet interface layer. The first is to use #ifdef statements in a single source file that can be compiled on either platform. If we take this approach, we may find that over time as the file gets bigger, maintaining the ifdef structure may become cumbersome. Our second alternative is to build two separate source files that are native to each platform and compile each of them on their native platform. If we take this approach, our initial development efforts would be for the UNIX version, using that as a launch pad for the Windows version. Using this approach would make the Windows product a modified version of the Berkeley version (or UNIX/Linux) version. Out third option is to find an existing product or library that will work on both platforms. This would allow us to develop and concentrate on the implementation of our prototype and leave the issues that rely on platform dependency to someone else.

The Standard Function Library

The standard function library is an open source library that has been around for almost 20 years. This library is downloaded and compiled for each platform with the resulting routines linked to the user application on the native platform. It works on over 20 different platforms including Windows, Linux, and BSD versions. It will also compile with the GNU compilers. Choosing this library provides us with a single-source interface in addition to the source code. All of this will cost us only the time to add the include files and compile and link for each platform. As it turns out, the standard function library supports TCP/IP and UDP protocols. This makes our development effort much easier. The fact that this library is available on all the supported platforms we will

Chapter 11 / Cross-Platform Application Development

455

 

 

be using does not preclude the fact we must compile it for each native platform. The complete cross-platform scripts and make files are available at www.wordware.com/files/embsys and www.time-lines.com.

Alternative Cross-Platform Choices

The Delphi/Kylix platforms include several TCP/IP implementations that work on all their supported platforms. If we browse to the Internet tab in the IDE we find three components that can serve our needs. These three components, which are to the left of the XML icon, are UDPSocket, TCPServer, and TCPClient. These components are highlighted by a box in Figure 11-1.

Figure 11-1

Delphi and Kylix also contain a second set of TCP controls included with the products. These are known as the Internet Direct, or INDY, components. TCP and UDP are just a few of the supported protocols. Figure 11-2 shows the Indy Servers components tab.

Figure 11-2

Both of these offer visual solutions for the development environment, where the standard function library offers a code-only solution.

Chapter 11

456

Chapter 11 / Cross-Platform Application Development

 

 

Visual vs. Code Solutions

As we’ve just seen there are two different solutions available on the Delphi/Kylix platforms. These same solutions are also available on the C++ Builder/Kylix C++ platforms as visual controls.

But what about the standard function library being used in a cross-platform environment? Well, as it turns out the standard function library is an excellent choice for use with C++BuilderX. The following is a C++BuilderX DLL project on Windows. The standard function library only requires we use an ANSI C compiler, and all of the C++BuilderX supported compilers meet that criteria. Figure 11-3 shows the DLL project being edited on the Windows platform.

Figure 11-3

With C++BuilderX we can create a project that can be accessed on each platform. In this particular case we will create a separate project for Linux because the structure of a shared library is slightly different from a DLL on Windows.

Chapter 11 / Cross-Platform Application Development

457

 

 

Figure 11-4 shows the same project being developed on C++BuilderX running on a slackware 9.1 machine with the KDE Desktop.

Figure 11-4

In case you didn’t notice, both projects were compiled with the GNU C compiler. The GNU compiler is ANSI compliant so we now have a completely new working alternative to Delphi/Kylix that uses ANSI C and is a “code-only” solution.

If we choose C++BuilderX and develop a DLL/shared library, the level portability will be higher than when developing using GUI components. For this prototype we will build our middle layer of device interfaces using C++BuilderX. On Windows the end result will be a DLL named IPInterface.dll. The end result on Linux/FreeBSD will be IPInterface.so.

Keep in mind that using C++BuilderX allows us to generate executables and shared libraries for any platform we have a cross-compiler installed for. For example, we can build and install a GNU compiler for the AMD Athlon 64 system, then add that cross-compiler to the list of tools. We can set up C++BuilderX to allow the generation of the 64-bit target on a 32-bit machine.

Chapter 11

458Chapter 11 / Cross-Platform Application Development

Note:

For more information on cross-compiling on C++BuilderX, please visit www.time-lines.com.

Socket Implementation

The host system is the UDP client in this case. Here’s how the communications will work. The host will attempt to connect to any thermostat listing on a specific port number. It will broadcast its request to establish a connection. The thermostat will “listen” for a connection request. When the request is received, it will check to see if the sender’s IP address is in a list of accepted connections. If it is, the thermostat will accept the connection and request a password. If the proper password is sent in response, the connection will be opened. If the password is incorrect, the connection will be closed and the thermostat will go back into listen mode.

It’s a little difficult to show how the code for this works in print. The best way to explain this further is to have you download the code for Chapter 11. In the Chapter 11 folder there will be two other folders — UDPSvr and UDBCli. Within each of these folders are Windows, Linux, and Embedded folders. You can set up a working UDB client and server using Windows or Linux. The Embedded folder only contains the UDP server since it is not initiating the client side of UDP.

Chapter 11 / Cross-Platform Application Development

459

 

 

Platform-Independent USB Development

Achieving the same success with developing a middle-tier USB interface requires the same strategy used for Ethernet. To employ that strategy we will use another open source library, libusb, which is available for Windows, Linux, and UNIX from the SourceForge.net web site. This product provides a consistent developer interface to USB devices. I would strongly recommend downloading one of the snapshots as they are frequently updated and have many features the previous release didn’t have.

The libusb libraries work very similar to the standard function template by providing a consistent developer interface to the USB driver layer for Linux, UNIX, and Windows.

There are a couple of items that need to be mentioned at this time. First, the Windows version of libusb includes a device driver. This driver implements the native methods of the UNIX and Linux device drivers. In short, it makes the Windows USB driver layer look exactly like the UNIX/Linux version. Not all of the functionality is fully implemented, but enough is available to provide a consistent development interface under Windows, Linux, and UNIX to the HID drivers. Now you may be asking if the thermostat qualifies as an HID device. The answer to that is definitely a yes. Almost all of the UPS systems sold for the PC that have a USB interface are in fact seen as HID devices to Windows. Any device that interacts with a human being can be considered an HID device. Once again we will implement this middle tier in a code-only fashion and once again we will use C++BuilderX as our development IDE of choice. The function calls to the libusb library are identical across the Linux, BSD, and Windows platforms. The difference again is in the link process.

Chapter 11

Соседние файлы в предмете Электротехника