Win32 programming example: Introduction to embedded software development programs (Articles completely copied from the Internet)

Microsoft Windows CE is a compact, efficient, and scalable operating system. It is widely used in a variety of embedded products, from handheld computers to specialized industrial controllers and consumer electronics. Windows CE has passed its own capabilities to prove that it can meet the needs of 32-bit embedded program development. Equally important: Windows CE enables embedded system designers to take full advantage of Microsoft's 32-bit Windows-based development tools.

One of the primary reasons for choosing Windows CE for embedded application software is the wide application of Microsoft Win32 application programming interface (API. From high-end servers running in Microsoft WindowsNT operating system to the smallest desktop and embedded applications, Win32 API is almost all the kernels for developing 32-bit application software for Windows.

This article aims to introduce Win32 event-driven programming to developers who develop new embedded systems based on Windows CE. This article will:

This section describes the 32-bit Windows operating system and Win32 programming model.
Describes how threads, events, and messages are operated.
This section describes how Win32 manages Windows CE memory.
Explain the concept of Win32 accidental operations.
You can compare the interfaces of devices to be synchronized.
To summarize the advantages of the clearly defined API.
This article does not mean to be a completely Win32 programming guide, but rather introduces Win32 as a development tool for embedded applications.

Introduction

For thousands of program developers around the world, the Win32 program mode is very common. Win32 is a powerful target for a wide range of desktop or enterprise applications. With the emergence of Windows CE, it has become an ideal program interface form for embedded systems. Win32 provides consistent, well-documented and powerful functional program interfaces for Windows CE operating systems.

Programs developed on the Windows CE platform using Win32 are similar to those of other Win32 programs. This means that when program developers develop new applications for the Windows CE operating system, it can use these large numbers of Win32 program resources, third-generation tools, and external specialized technologies. Programmers with Win32 programming experience will find that creating (maintaining existing) Windows CE devices (such as handheld computers) the application is far simpler than the application that creates a similar embedded operating system for a special platform or other applications.

Embedded system designers quickly realized the power of Windows CE and quickly integrated the operating system with their new products. However, many embedded software developers are not familiar with the general technology of Windows event drivers. For these software developers, it is good to know some basic Win32 knowledge before they start their first Windows CE-based project.

What is Win32?

"Win32" indicates a common application programming interface (API) for all Microsoft 32-bit platforms ). These platforms generally refer:

Windows 95, Windows 98
Windows NT
Windows CE
This article focuses on the Windows CE operating system, but it is worth noting that most Win32 application programming interfaces are applicable to all three of the above platforms. There are many advantages of this same Application Programming Interface: it is easy to log on to the application, there is a lot of existing program knowledge, examples and third-generation software resources.

Platform differences

The Win32 application programming interface defines a Windows platform that you can use as a programmer. The purpose of the Win32 Application Programming Interface is to provide a common interface setting. However, the application programming interfaces of different platforms vary depending on different features and hardware constraints. Some members of the Win32 platform family support all Win32 application programming interfaces (hereinafter referred to as APIS), while others only support some APIs. Windows CE is designed for compact, embedded applications and small devices. Win32 APIs are the most restrictive. However, Windows CE APIs are well-developed to handle a large number of advanced embedded applications.

Win32 and Microsoft basic class library (MFC)

Using the Win32 interface is not the only way to create a 32-bit Windows-based application. Another important approach is the Microsoft basic class library (MFC) that can be used in Win32 and Microsoft Visual C ++ development environments ). MFC is highly encapsulated for many (not all) Win32 APIs (figure 1 ). Generally, MFC provides classes that represent important Windows user interface objects, such as Windows, dialog boxes, paint brushes, brushes, and fonts. MFC also provides corresponding classes for embedded application software without any user interface requirements. The member functions of the MFC class call the WIN32API function, which can simplify the design of complex applications cleverly.

As a Win32 programmer, You can freely choose to use C, C ++, and Win32 APIs, or use C ++ and MFC. Visual c ++ supports the above two development systems for all Windows CE Win32 target operating systems.

This document describes Win32 APIs. For more information about the application of MFC under Windows CE, see the Windows ce sdk documentation.

Win32 Program Model

Win32 is a common and consistent (though not all) API that surpasses all 32-bit Windows platforms. In order to have a thorough understanding of Win32 API, so as to use its functions efficiently, it is very important to understand the basis of some underlying operating systems. This section summarizes the most important concepts of the 32-bit operating system and Win32 API, providing the foundation for you to learn more deeply. For more details about the 32-bit windows architecture, Win32 API, and other programming themes, read a book on that topic. Microsoft press can provide such books. At the end of this article, some of these books are listed.

Windows CE kernel and Win32 API

Those who think of Windows CE may have the illusion that it is only a downgrade of the existing operating system (such as Windows 95. But in fact, Windows CE is developed based on a small, highly user-oriented embedded application operating system. In addition to excluding (or replacing) operating system features not required by Windows CE-based applications, its kernel also has a large number of other Microsoft 32-bit operating systems. For example, in Windows NT, all applications running on Windows CE run in a Priority multi-task processing environment in fully protected memory space. In addition, like Windows NT, Windows CE supports local unified character encoding standard character string, making it more suitable for international promotion. However, unlike other 32-bit Windows platforms, Windows CE is very compact and user-oriented and only occupies less than KB of memory.

Windows CE Win32 APIs are smaller than other 32-bit windows Windows Win32 APIs. Windows CE only includes half of Windows NT APIs. However, Windows CE's Win32 API also has features not available in other systems. For example, the notification API can process notification events (such as clocks) at the operating system level rather than at the running application level ). Touch-screen APIs and built-in support for Windows CE databases are not available in other operating systems. The Touch Screen API is easy to implement for screen correction and user interaction management of tactile sensitive monitors, while the database API provides quick and simple tools for accessing compact and general-purpose databases. Another little-known aspect about Windows CE is its high degree of modularization; embedded system developers (using Visual C ++ software packages included in Microsoft Windows CE) you can create a customized version of Windows CE for their unique hardware platform and application software.

The Windows CE operating system provides a completely new design environment. Windows CE developers almost do not need to support the original applications or devices. Therefore, the operating system can consider some of the latest ideas and applications, the most advanced embedded 32-bit microprocessor is used as its hardware target platform.

What does this mean for a Windows CE platform Win32 API user? This means that for a modern 32-bit embedded system, it is a simpler API and a more optimized target operating system. Next, we will study some important Win32 APIs and the internal content of the Windows CE operating system.

Programs and clues

The first step to understand the underlying content of Win32 APIs and Windows CE is to understand how multi-task and multi-line cable applications are organized. In Win32 terminology, a program is defined as a running program instance. Like other 32-bit Windows platforms, Windows CE is a multitasking operating system. In a running program, it supports executing multiple clues.

For embedded applications, Windows CE's multi-line cable execution capability is an important embodiment of its functions. In this way, Win32 embedded program developers will give priority to the creation and synchronization of Win32 cable.

The processing of Win32 cable is different from other commonly used embedded operating systems. Unlike Unix or its derived systems, the 32-bit Windows platform has been designed to support multiline cable applications from the very beginning. Wire Cable management (timing arrangement, synchronization, and resource management) is completed by the kernel. program developers use functions to load the kernel (accessed through Win32 APIs) to establish and manage Wire Cable management in their applications.

For example, if an embedded application must monitor multiple input devices and properly reflect events that are not synchronized to one or more devices. Furthermore, if such a program also needs to update some shared resources (such as the global data structure, files on the disk, or other devices) as a reflection of related device events. A program like this requires a reliable cable management system. This is exactly the function that Win32 APIs can provide: Multiple cable stores can be quickly and easily created on the Win32 API cable creation interface; synchronous cable stores (multiple cable stores simultaneously access one data) you can do this in different ways, including key segments, nameless and nameless events, and mutually exclusive targets.

Windows CE is designed to occupy the minimum program resources when performing these synchronization tasks. This is very important for developers who do not have powerful functions. Because the kernel is responsible for the management of cable, it does not need to use another processor to perform loop detection programs or cable operations, and other useless Application Layer Cable management. The kernel has built a program that manages several cable entries and enables the program to perform it efficiently.

For applications that contain several programs, Win32 provides a complete set of processing methods for cable, program management, and synchronization. These cable management features are very suitable for embedded application software and are easy for Windows CE developers.

Message

Programs running on 32-bit Windows platforms are more specialized. Program clues depend on messages to initialize programs, control system resources, and communicate with operating systems and users. Windows messages come from various sources, including operating systems, user activities, such as keyboard input, mouse, touch screen, and other running programs or clues.

When a message is sent to a clue, the message is placed in the message queue for final processing (Figure 3 ). Each clue has a message queue that is completely independent from other clues. Clues generally have a continuously running message loop to restore and process messages. When there is no message in the queue and the clue is not engaged in any other activity, the system suspends the clue to save resources of the central controller.

Messages can also be used for control purposes to initialize various types of programs in your application, and they can use message parameters to transmit data. For example, a clue may receive a message that is activated on the touch screen. The message parameters can indicate that X and Y are the coordinates of user actions. In another type of message, a parameter can include a pointer or a handle pointing to a data structure, window, or other object.

Interrupt handling

As an embedded software developer, you may be most concerned about how the processing rules of Windows CE messages affect the timing of your external system interfaces. By careful design and accurate measurement, Windows CE ensures that the disconnection sequence and other related features and embedded system design are applicable.

Embedded applications often have time-critical device interfaces and need to discover and respond to device and system events within a minimum defined time. To support such applications, Windows CE includes highly optimized interrupt transfer, priority, and service systems.

In the Windows CE kernel, interrupt processing is divided into two obvious parts: the interrupt service program (ISR) and the interrupt service clue (IST ). The purpose of this system is to make ISR as small and fast as possible. At the hardware level, each one of the disconnects request (IRQ) leads to a specific software ISR. When triggered, the given ISR not only notifies the kernel ist location, but also does a small amount of work. Once the IST is initialized (though not necessary), the system is ready to accept the next one and process the next one.

Each interrupt has a priority associated with them. Windows CE uses the priority-based time segment algorithm to determine the time sequence of clues. The ist associated with each ISR is a normal clue. Therefore, it is the responsibility of the application software developer to set priority for the IST to meet the application's timing requirements.

The final result of separating ISR and ist in the interrupt program is that the typical interrupt wait time is greatly reduced, and the possibility of an unacceptable delay in the interrupt program is also greatly reduced. In addition, embedded software packages and features of the Windows CE kernel make it possible to customize the interrupt sequence and priority to meet the needs of specific applications. Windows CE and its time-critical and real-time applications include more detailed content than this article, titled real-time systems with Microsoft Windows CE.

Memory Management

Win32 API provides developers with a set of complete and consistent interfaces. When developing a vast majority of applications, software developers do not need to consider the specific memory structure. However, for many embedded applications, especially those with strict memory resource constraints or critical timing requirements, it is important to have a good understanding of memory management methods.

The general structure of Windows Memory is different for different 32-bit Windows platforms, and the special detailed structure varies with different processors in the same 32-bit Windows operating system. (For example, the memory structure of Windows NT is quite different on the X86 platform and on the DEC Alpha platform .) For this discussion, we will focus on the Windows CE operating system section.

Storage Structure of Windows CE

Like other 32-bit Windows platforms, the Windows CE operating system also has the virtual memory feature. The memory is always allocated to an application page at a specific time. The page size is determined by the system designer (and specified when the operating system is created for the target hardware platform ). For example, in a handheld computer, the memory page size is typically 1 kb or 4 kb.

During initialization (import), Windows CE creates an independent 4 GB virtual address space shared by all programs. When a program references a virtual address, it is recorded by the kernel on the physical memory. This makes it unnecessary for application software developers to consider the physical layout of the target system memory. Although all programs share a single address space, applications can avoid misuse of each other. Windows CE protects program memory by changing the protection of each page, instead of allocating it to different address spaces of each program. As an application developer, you may not care too much about the physical structure of the memory of the target system. The memory can be all random access to the memory, or it may include a flash card or hard drive. Windows CE allows you to manage memory resources, while Win32 APIs provide you with the necessary interfaces for allocating, using, and releasing memory.

However, as an embedded system designer, you will need to carefully consider the memory needs of applications that will be executed on your new hardware platform, and fully consider the costs, speed, and reliability, balance conflicts between various goals. If you develop a new hardware platform for Windows CE, Windows CE's embedded software packages for Visual C ++ can help you make these decisions and form an operating system.

Regardless of your system memory configuration, Rom (read-only memory) will occupy a very important position. Unlike other 32-bit Windows operating systems, the code of the Windows CE operating system is in the read-only memory and executed in that read-only memory. Depending on your product needs, you can also choose to place application code in read-only memory. For example, pocket word, pocket Excel, and other applications, including those provided in handheld computer read-only memory.

Program groups stored in the Rom are executed locally in Windows CE. Therefore, embedded system designers can use only a small amount of RAM for Stack storage. Correspondingly, your embedded applications can use RAM as both the program memory and temporary storage space.

To further improve the performance of the application software, Windows CE uses the memory to be split as needed. The operating system only needs to extract and load a small part of the ram-based program for execution. The flexibility and speed of ROM and ram-based programs means that Windows CE-based devices can be constructed into various memory structures.

Memory Structure of handheld computers

The memory structure of a typical Windows CE hardware platform is very different from that of a Windows-based desktop computer. To understand how memory is usually processed in Windows, it is useful to examine the most common representative Windows CE-based device-handheld computer.

In a handheld computer, Ram is divided into two main parts: storage memory and program memory. The amount of Ram allocated to the two parts can be modified by the user of the handheld computer (within the limit ). Figure 4 shows the ram division.

The storage memory in a handheld computer is similar to the hard disk ram of a desktop computer. It is used to store data and non-system applications. Each segment in the third segment is accessed by a different set of Win32 APIs:

Windows CE system registers are similar to Windows NT and Windows 95 operating system registers. You can use the Win32 register function to manipulate the register key and value.
Applications and data installed by users are stored in common file storage segments. Windows CE file system API is a subset function of the standard Win32 file system.
For database applications, Windows CE database APIs are used to store managed and stored applications. This API is unique to Windows CE and does not exist on other Win32 platforms.
Program memory is used for Stack storage of systems and non-system programs. Non-system applications are acquired from the storage memory (or maybe the PC Card), non-compressed and loaded into the memory of the program to be executed.

Handling exceptions

Handling of unexpected situations is a powerful programming technology. The corresponding Win32 API function can easily detect unexpected errors and restore them. Structured troubleshooting of unexpected situations allows the code of dangerous segments to fail due to hardware resource problems, device conflicts, and minor encoding errors, to separate these programs from other applications. This protects applications from premature termination or sensitive system problems.

Structured unexpected situation handling includes defining a series of declarations as protection, and defining another set of statements for the first set of statements as the handle to unexpected situations. An unexpected handle defines one or more declarations to ensure system operation, regardless of the existing state of the claim.

On most 32-bit Windows platforms, programmers who use Win32 APIs usually have two options when handling unexpected situations. They use C or C ++ to write applications, in addition, use the macros provided by Win32 to handle unexpected situations, or use C ++ to write applications, and use the unexpected situation processing functions defined by C ++.

For the compilation of such programs, Windows CE developers cannot access C ++ (Windows CE-Oriented Visual C ++ currently does not support handling unexpected situations, therefore, you must use the Win32 API to handle Macros in unexpected situations.

To handle Win32 exceptions, you will use a set of macros defined in the Win32 API. The following code shows the basic concepts:

_ Try {

// The statements in here have a possibility of failure

// And so are guarded.

}

_ Finally {

// This is the exception handler. This code will execute

// After the guarded statements, no matter what happened

// In the guarded block of code above.

}

// This code will execute normally if the program flow allows

// It (no Goto, exit, etc .)

The _ Try and _ finally macros generate the necessary underlying code for handling exceptions.

Unexpected processing is useful for general multi-threaded orders such as those in embedded applications. Processing macros for Win32 structured unexpected situations is an easy and powerful way to protect applications from unexpected failures.

Device Processing

There are countless hardware devices (peripheral devices) that are compatible with Windows platform (Windows NT and Windows 95) desktops, and more things emerge on the market every year. Windows CE platforms generally do not support many peripheral hardware types of devices supported by desktop computers. However, creating reliable device interfaces for Embedded Systems is a challenging part in embedded programming. This is because the timing of typical embedded system interfaces and other operational needs are far more difficult than desktop computer computing systems and applications.

Fortunately, Win32 API provides a rich set of device interface methods, making it easier to write device interface programs and suitable for specific embedded systems.

How can Win32 APIs help Win32 APIs provide you with a set of consistent stream-based interfaces on your hardware platform. To use a device, you must first use a function suitable for the device type to open it. For most devices, you use the createfile function in the following example:

Handle hport = createfile ("COM1"); // open the serial port

The createfile function opens a specified device (serial port) and returns a handle for subsequent operations (such as reading and writing) on this device. Various functions (including readfile, writefile, lockfile, and others) accept this handle as a parameter, and allow you (for example) to read and write data and check the device status, and include the devices or files that are locked from access to other programs in the list. File input and output operations are processed into functions that use the same API as other device types and include random access functions in the file. The lockfile function can be used to lock devices and files simultaneously accessed by several programs or clues.

After your application has completed the device or file, it will call the closefile function to close the device and clear the device as necessary.

Synchronous and asynchronous device processing

Embedded systems often have time series requirements for key devices. For this reason, the software interface to the underlying operating system must be able to manage events of different types of devices at the software level at the same time (or almost simultaneously. Win32 API supports synchronous and asynchronous access to devices and is designed with complex device interfaces.

Synchronous interfaces are those that require the software to get action from the device and then wait for the result. In synchronous device interfaces, the readfile and writefile functions mentioned above are the most common ones. When used in synchronous I/O, whether you are using files, parallel ports, serial ports, a channel, or other device interfaces on the disk, all are public and compatible.

Asynchronous interfaces are interfaces that require applications to serve. A good example of an asynchronous device is the keyboard. Appropriate and timely processing of asynchronous events is critical to many embedded applications. Fortunately, device drivers written for Windows CE support simultaneous multi-clue access to the drive. This greatly simplifies the processing of asynchronous input devices.

The method of the specified device you access depends on the characteristics of the device and the requirements of the specific application you develop. If you create a brand new device (and Device Drivers) on your Windows CE-based hardware platform, you can both go from the level of your hardware device and drive, there are also many options at the application level.

Custom devices and Win32

Although the embedded system can support a small number of devices, the embedded system can form unique and complex device interface problems. When you develop a new hardware platform that supports input and output devices, you will have to make decisions and trade-offs at different layers of your design. For example, unless you only use the usual off-the-shelf hardware, you must write your device driver to support your new peripheral devices. You also need to configure your Windows CE to include some necessary components for device processing. At the same time, you need to write interface code to meet the needs of new devices at the application level. With so many variables, how do you maintain a certain degree of consistency between your devices? The answer is in Win32 API. In the Win32 API environment, write your target driver. You have reason to confidently think that application developers with interfaces for new devices can create trusted applications, verifiable and maintainable basic code. The Windows CE device driver development kit, or DDK for short, provides information and examples on how to create Win32 powerful device drivers.

Device Type

Windows CE supports two basic types of device drivers, built-in curing drivers and installable drivers. As the name implies, a built-in solid driver is a device specified for a given Windows CE hardware platform. The embedded system designer of Windows CE is responsible for providing a built-in and fixed driver to drive the devices included in the system. For example, many Windows CE platforms have an LCD touch screen. Manufacturers of these platforms provide device drivers for their devices so that the hardware can be used in Windows CE operating systems. In a complete system, these built-in solidified drivers are located around the kernel in the Windows CE read-only memory.

The installable device driver is set to any peripheral device that is temporarily connected to the Windows CE hardware platform. Devices of this type include modem, printer, digital camera, PC Card, and any number of other external devices. The installable device driver may be in read-only memory, but is typically loaded with the application software of the temporary device interface.

Summary

This article has briefly introduced Windows CE-oriented Win32 API, which aims to highlight the general characteristics and advantages of this widely used and important API. There are many other details you need to learn before using Windows CE embedded products for the first time; fortunately, there are a lot of resources for Win32 API information.
These resources include Microsoft Development Network (msdn), articles (such as this article), newspapers, and a large number of published books.