WO2012044262A1

WO2012044262A1 - Embedded system design, programming, and simulation architecture

Info

Publication number: WO2012044262A1
Application number: PCT/TH2010/000037
Authority: WO
Inventors: Krisada Sangpetchsong; Udomsak Boonprasert
Original assignee: The Thailand Research Fund; Royal Thai Naval Academy
Priority date: 2010-09-30
Filing date: 2010-09-30
Publication date: 2012-04-05

Abstract

In an embodiment an architecture includes a target system and host system respectively configured to provide a recurrent target-side communication loop and a recurrent host-side communication loop. The target communication loop provides timing control for synchronizing host-side embedded simulation operations with target-side embedded system simulation operations. The host system also includes a graphical programming environment that provides graphical blocks, including a set of graphical blocks corresponding to target system add-on devices. During simulation operations, target - host communication, including communication corresponding to signals associated with target system add-on devices, occurs by way of sequenced execution of the recurrent target-side communication loop and the recurrent host-side communication loop. The target system also includes a bootloader configured to selectively initiate the execution of a particular modular program selected from a plurality of modular programs in response to user input received by way of a selection module. Each modular program corresponds to an independently executable embedded application. The bootloader can map a selection signal value to a starting address of a particular modular program by way of a configuration table, and transfer target system execution control to the particular modular program during target system bootload operations.

Description

EMBEDDED SYSTEM DESIGN, PROGRAMMING,

AND SIMULATION ARCHITECTURE

Cross Reference to Related Applications

This application relates to and incorporates by reference a) PCT Patent Application No. PCT/TH2010/000010, entitled "Communication and Process Sequencing Architecture, System, and Method for Hardware-in-the-Loop Simulation," filed on 17 March 2010; and b) PCT Patent Application No. PCT/TH2010/000020, entitled "Embedded System Providing Bootloader Selected Execution of Multiple Independent Modular Programs," filed on 15 June 2010.

Technical Field

Aspects of the present disclosure relate to an architecture for embedded system design, programming, and or simulation, which includes a host system that provides a graphical programming environment for developing, modeling, and simulating embedded application code executable by a target system. The architecture can flexibly and efficiently support any type of hardware-in-the-loop, processor-in-the-loop, or software-in-the-loop configuration by controlling or sequencing simulation operations based upon target - host data packet transfer. The target system can store multiple independently executable modular programs, which can be selectively executed in response to user input. The architecture can additionally support a suite of add-on target devices, the modeling and simulation of such add-on devices, and the generation of embedded application code corresponding to such add-on devices.

Background

Embedded systems can be defined as special purpose systems or devices that are used in a wide variety of instrumentation and automation applications, such as temperature measurement or control, antilock braking, robotic motion control, missile guidance, and many other applications. In general, for performance optimization and cost reduction purposes, a given embedded system is directed to a specific type of embedded application, and is programmed to perform specific or dedicated types of embedded application tasks.

The main component of an embedded system is typically a microcontroller or digital signal processor, which controls the instrumentation or automation application to which the embedded system is directed. Microcontrollers have to be programmed before they are implemented in an embedded application and increasingly, graphical programming environments such as National Instruments Labview (National Instruments Corporation, Austin TX, USA) or MatLAB / Simulink (The MathWorks, Inc., Natick MA, USA) are used to facilitate such programming as such environments substantially increase programming flexibility and simplicity. Programming the microcontrollers is done via a host or test platform or system such as a Personal Computer (PC). A microcontroller control program under development or testing is often referred to as a simulation model. The microcontroller itself and the associated resources that are required to implement an embedded application corresponding to the microcontroller control program are typically referred to as a target system.

Unfortunately, existing embedded system design and simulation systems, tools, and techniques rely upon needlessly complex or cumbersome data exchange protocols, target- dependent codes, and/or substantial overhead with respect to target - host communication control and timing synchronization. Additionally, existing embedded system design and simulation systems, tools, and techniques may not be able to flexibly or efficiently implement different types of simulation or test configurations in the absence of complex data exchange protocols and overhead. Moreover, existing embedded system design and simulation systems, tools, and techniques fail to provide a simple, efficient, low overhead, target independent manner of accommodating various types of target-side devices that may be used to implement an embedded application under consideration.

Any unnecessary target - host communication and/or control complexity that an embedded system developer is required to manage can be a burden that reduces the amount of time the developer can spend actually developing, modeling, and/or testing an embedded application algorithm itself. With respect to a target system, microcontroller based embedded systems typically have limited memory resources (e.g., ROM and RAM) and as such, it is inefficient to impose unnecessary overhead on program code directed to these systems.

Most embedded systems store a single embedded program directed to implementing a specific set of embedded system functions, where the single embedded program is typically stored in flash memory. Any change to program functionality requires reprogramming the flash memory, which can occur via in-application programming (IAP) operations. Certain embedded systems provide for the storage of multiple embedded programs in flash memory, and the selective execution of a given embedded program from among the multiple stored embedded programs. However, such systems are implemented in a manner that is inflexible with respect to overall embedded system design, or impose a significant overhead burden upon the embedded system with respect to managing and selectively executing the multiple stored programs.

A need exists for an embedded system design, programming, and simulation architecture that addresses one or more of the foregoing drawbacks.

Summary

In accordance with an aspect of the disclosure, an embedded system development and simulation process can be implemented by way of a host system that includes an embedded system development environment configured for embedded system simulation operations involving a target system, where the process includes providing a recurrent target - host communication loop by which communication corresponding to information transfer between the target system and the host system occurs during embedded system simulation operations; providing a simulation model corresponding to the embedded system, the simulation model comprising a set of graphical blocks that includes at least one block corresponding to a target system add-on device configured for at least one of user input operations, visual interface output operations, sensing operations, and actuation operations; and performing embedded system simulation operations corresponding to the simulation model, the embedded system simulation operations comprising the execution of a target simulation process and the execution of a host simulation process, the target simulation process and the host simulation process configured to communicate by way of the recurrent target - host communication cycle.

The aforementioned recurrent target - host communication loop can include a target communication loop corresponding to the target system, the target communication loop including a target transmitter process, wherein the target communication loop recurrently operates; and a host communication loop corresponding to the host system, the host communication loop including a host receiver process, wherein the host communication loop recurrently operates, wherein the target communication loop provides timing control for synchronizing the host communication loop with the target communication loop during embedded system simulation operations.

The aforementioned embedded system simulation operations can include initiating execution of the target communication loop; initiating execution of the host communication loop in response to execution of the target communication loop; generating signals corresponding to the target system add-on device; and transferring data corresponding to the generated signals between the target simulation process and the host simulation process by way of the recurrent target - host communication loop.

The target transmitter process can provide timing control for synchronizing the host communication loop with the target communication loop by successively outputting packets at predetermined time intervals, and/or avoiding outputting packets at times other than predetermined time intervals.

The target communication loop can include a target-side wait state in which the target communication loop is maintained until a next predetermined time interval is reached. Similarly, the host communication loop can include a host-side wait state, in which the host communication loop is maintained until the host receiver process receives a packet output by the target transmitter process.

In some aspects of the present disclosure, the target communication loop further includes a target receiver process and the host communication loop further includes a host transmitter process. An embedded system development and simulation process can further include executing the target communication loop and the host communication loop in a sequenced manner by way of executing the target communication loop in response to one from the group of execution of the host communication loop and receipt of a dummy packet generated in response to user input; and executing the host communication loop in response to execution of the target communication loop.

The target simulation process and the host simulation process can be configured in accordance with an open loop configuration, and communication between the target simulation process and the host simulation process can occur by way of data packet transfer from the host transmitter process to the target receiver process and dummy packet transfer from the target transmitter process to the host receiver process. Synchronization between the target communication loop and the host communication loop can thus occur by way of dummy packet reception by the host receiver process.

Additionally or alternatively, target simulation process and the host simulation process can be configured in accordance with a closed loop configuration, and communication between the target simulation process and the host simulation process can occur by way of data packet transfer from the target transmitter process to the host receiver process and data packet transfer from the host transmitter process to the target receiver process. Synchronization of the host communication loop with the target communication loop can thus occur by way of data packet reception by the host receiver process and synchronization of the target communication loop with the host communication loop occurs by way of data packet reception by the target receiver process. Execution of the target communication loop or transition out of the target-side wait state can occur in response to the target reception process receiving a dummy packet generated in response to user input.

A process in accordance with an aspect of the disclosure can further include providing a graphical configuration interface corresponding to the target system add-on device, the graphical configuration interface responsive to user input for establishing operating parameters corresponding to the target system add-on device. The process can also include providing a graphical simulation interface corresponding to the target system add-on device, the graphical simulation interface configured to provide a visual simulation of target system add-on device operation during embedded system simulation operations.

According to an aspect of the disclosure, an embedded system development and/or simulation architecture can include a target system having a target side processing unit and a set of target-side communication modules including a target transmission module configured to operate in accordance with a recurrent target-side communication loop; and

a host system having a host-side processing unit; a graphical embedded system development and simulation environment providing a set of graphical blocks, at least one graphical block corresponding to a target system add-on device configured for at least one of user input operations, visual interface output operations, sensing operations, and actuation operations; and a set of host-side communication modules including a host reception module configured to operate in accordance with a recurrent host-side communication loop that is initiated in response to target system execution of the target-side communication loop, wherein data transfer between the target system and the host system corresponding to the target system add-on device occurs by way of at least one of the recurrent target-side communication loop and the recurrent host-side communication loop.

The target-side communication loop and the host-side communication loop are configured for synchronous operation based upon packet transfer between the target system and the host system. The set of target-side communication modules can include a target reception module configured to operate with the target transmission module in accordance with the target-side communication loop, and the set of host-side communication modules can include a host transmission module configured to operate with the host reception module in accordance with the host-side communication loop. The target system and the host system can exist in an open loop configuration or closed loop configuration, configured to operate in a manner analogous or identical to that described above.

According to an aspect of the disclosure, the host system's embedded system development and simulation environment can provide a graphical configuration interface corresponding to the target system add-on device, the graphical configuration interface responsive to user input for establishing operating parameters corresponding to the target system add-on device. The graphical embedded system development and simulation environment can additionally or alternatively a graphical simulation interface corresponding to the target system add-on device, the graphical simulation interface configured to provide a visual simulation of target system add-on device operation on the host system during embedded system simulation operations.

In accordance with an aspect of the disclosure, an embedded system development and simulation process can be implemented by way of a host system coupled to a target system, where the host system provides a graphical embedded system development and simulation environment, and the target system includes an embedded processing unit, a selection interface coupled to the embedded processing unit and configured to receive user input, and a target system memory coupled to the embedded processing unit. The target system memory includes a modular program memory configured to store a plurality of modular programs, each modular program comprising program instructions corresponding to an embedded application. The target system memory further includes a bootloader configured to selectively initiate the execution of a modular program stored within the modular program memory in response to user input provided to the selection interface. The embedded system development and simulation process can include performing a target system bootload process that identifies in response to user input provided to the selection interface a particular modular program within a plurality of modular programs stored in the modular program memory; initiating execution of the particular modular program; establishing a recurrent a recurrent target - host communication loop by which communication between the target system and the host system occurs during embedded system simulation operations; executing the target communication loop; executing the host communication loop in response to execution of the target communication loop; and transferring data corresponding to embedded system simulation operations between the target system and the host system by way of the recurrent target - host communication loop.

The recurrent target - host communication loop can include a target communication loop corresponding to the target system, the target communication loop including a target transmitter process, wherein the target communication loop recurrently operates; and a host communication loop corresponding to the host system, the host communication loop including a host receiver process, wherein the host communication loop recurrently operates, wherein the target communication loop provides timing control for synchronizing the host communication loop with the target communication loop during embedded system simulation operations;

A target system bootload process can include determining a selection signal value corresponding to user input provided to the selection interface; mapping the selection signal value to a unique starting address of a modular program stored within the modular program memory to thereby identify the particular modular program; and transferring target system execution control to a program instruction corresponding to the starting address of the particular modular program. Modular programs can be stored in the modular program memory at uniformly separated starting addresses, or at least some modular programs can be stored in the modular program memory non-uniformly separated starting addresses, for instance, starting addresses that vary in accordance with a set of user defined modular program sizes. The modular program memory can include a factory program memory and a user program memory, the factory program memory storing at least one predetermined modular program and the user program memory storing at least one user program, each user program comprising one of a user defined modular program and a user customized modular program. According to an aspect of the disclosure, mapping a selection signal value to a unique starting address of a modular program can include accessing a configuration table that defines an association between a plurality of unique selection signal values corresponding to user input providable to the selection interface and a plurality of unique program instruction addresses to which target system execution is transferable in response to user input provided to the selection interface. In certain aspects of the disclosure, mapping the selection signal value to a unique starting address of a modular program comprises selectively determining one of a starting address of a factory program and a starting address of a user program based upon user input provided to the selection interface. Selectively determining a starting address of a factory program or a starting address of a user program can include accessing a configuration table that defines a plurality of address associations that includes a first set of associations between a first set of unique selection signal values corresponding to user input providable to the selection interface and a set of unique program instruction addresses corresponding to factory programs; and a second set of associations between a second set of unique selection signal values corresponding to user input providable to the selection interface and a set of unique program instruction addresses corresponding to user programs.

The target communication loop can further include a target receiver process and the host communication loop can further include a host transmitter process. The target communication loop and the host communication loop can be configured to synchronously execute in relation to each other based upon packet transfer in one or more manners described herein to support open loop or closed loop simulation operations. In accordance with an aspect of the disclosure, an embedded system development and simulation architecture can include a target system having a target-side processing unit; a selection interface coupled to the target-side processing unit and configured to receive user input; and a target system memory. The selection interface can include at least one of a set of jumpers, a set of switches, a set of touch sensitive elements, and a set of visual feedback elements. The target-side processing unit, the selection interface, and at least a portion of the target system memory can be carried by a common support structure.

The target system memory can store a plurality of modular programs, each modular program comprising program instructions executable by the processing unit to implement an embedded application; a bootloader configured to selectively initiate the execution of a particular modular program stored within the memory in response to user input provided to the selection interface; and a set of target-side communication modules including a target transmission module configured to operate in accordance with a recurrent target-side communication loop. The modular program memory can include a factory program memory that stores at least one predetermined modular program and a user program memory that stores at least one of a user defined modular program and a user customized modular program. Depending upon embodiment details, factory programs can be stored in the factory program memory at uniformly separated starting addresses, and user programs can be stored in the user program memory at uniformly separated or non-uniformly separated starting addresses.

The bootloader can be configured to determine as part of a target system bootload process a selected execution address in response to a signal output by the selection interface, the selected execution address corresponding to a starting address of a particular modular program stored within the modular program memory. The bootloader is further configured to transfer target system execution control to a program instruction stored at the starting address of the particular modular program.

The target system memory can include a configuration table that defines an association between a plurality of unique selection signal values corresponding to user input receivable by way of the selection interface and a plurality of unique program instruction addresses to which the bootloader can transfer target system execution. The configuration can define one or more address associations corresponding to factory programs and one or more address associations corresponding to user programs.

Such an architecture can further include a host system having a host-side processing unit; and a set of host-side communication modules including a host reception module configured to operate in accordance with a recurrent host-side communication loop that is initiated in response to target system execution of the target-side communication loop. The target transmission module provides timing control for synchronizing the host communication loop with the target communication loop by successively outputting packets at predetermined time intervals.

The set of target-side communication modules can further includes a target reception module and the set of host-side communication modules can further includes a host transmission module. The target-side communication modules and host-side communication modules can be selectively configured in accordance with an open loop or closed loop configuration. Synchronized communication between the target system and the host system can occur by way of packet transfer in one or more manners described herein. Additionally, initial operation of the target-side communication loop can be triggered by target-side reception of a dummy packet, which can be generated in response to host-side user input (e.g., by way of user interaction with a trigger module).

Brief Description of the Drawings

FIG. 1A is a block diagram showing aspects of an architecture for embedded system design, programming, and/or simulation according to an embodiment of the disclosure.

FIG. 1 B is a block diagram showing further aspects of an architecture for embedded system design, programming, and/or simulation according to an embodiment of the disclosure.

FIG. 1C is a block diagram showing representative elements within a set of embedded system development resources according to an embodiment of the disclosure.

FIG. ID is a block diagram showing representative elements within an add-on device blockset according to an embodiment of the disclosure. FIG. IE is a block diagram of a representative graphical simulation model having graphical blocks organized within a simulation environment window generated by way of the graphical embedded system development environment in accordance with an embodiment of the disclosure.

FIG. 2A is a block diagram illustrating portions of a representative target programming GUI according to an embodiment of the disclosure.

FIG. 2B is a block diagram of a representative a representative adjunct, associate, or corollary programming device according to an embodiment of the disclosure.

FIG. 3 is a block diagram of a representative adjunct, advanced, associate, or corollary user selection device according to an embodiment of the disclosure. FIG. 4A is a block diagram of a selective execution fixed memory map according to a representative embodiment of the disclosure.

FIG. 4B is a representative embodiment of a static configuration table according to an embodiment of the disclosure.

FIG. 5A is a block diagram of a selective execution flexible memory map according to a representative embodiment of the disclosure.

FIG. 5B is a block diagram of a representative dynamic configuration table according to an embodiment of the disclosure.

FIG. 5C is a block diagram of a representative dynamic configuration table according to another embodiment of the disclosure. FIG. 6 is a representative target mode selection list or table that can be provided to and/or displayed by a visual feedback element or display device in accordance with an embodiment of the disclosure. FIG. 7 is a flow diagram of a process for bootloader-based selective target system operation according to an embodiment of the disclosure.

FIGs. 8A and 8B are block diagrams respectively showing a representative data packet structure and a representative dummy packet structure according to an embodiment of the disclosure.

FIG. 9A is a block diagram of a dummy packet initiable simulation configuration according to an embodiment of the disclosure.

FIG. 9B is a schematic illustration of a closed loop target - host communication process according to an embodiment of the disclosure.

FIG. 9C is a flow diagram corresponding to the closed loop target - host communication process of FIG. 9B.

FIG. 9D is a flow diagram of a dummy packet based simulation initiation process according to an embodiment of the disclosure. FIG. 10 is a block diagram of a host-to-target open loop simulation configuration according to an embodiment of the disclosure.

FIG. 11 A is a block diagram of a target-to-host open loop simulation configuration according to an embodiment of the disclosure.

FIG. 1 IB is a schematic illustration of a target-to-host open loop simulation process according to an embodiment of the disclosure.

FIG. l lC is a flow diagram corresponding to the target-to-host open loop communication process of FIG. 11B.

FIG. 12 is a block diagram of a representative target - host configuration according to another embodiment of the disclosure. FIG. 13A is a flow diagram of a high level packet reception and synchronization process according to an embodiment of the disclosure.

FIG. 13B is a flow diagram of a low level packet reception and synchronization process according to an embodiment of the disclosure.

FIG. 14 is an illustration of a representative communication module graphical user interface (GUI) according to an embodiment of the disclosure. FIG. 15 A is an illustration of a representative LED appearance configuration GUI according to an embodiment of the disclosure.

FIG. 15B is an illustration of a representative LED array simulation interface according to an embodiment of the disclosure.

FIG. 16A is an illustration of a representative LCD appearance configuration GUI according to an embodiment of the disclosure.

FIG. 16B is an illustration of a representative LCD parameter definition GUI according to an embodiment of the disclosure.

FIG. 16C is an illustration of a representative LCD output format GUI according to an embodiment of the disclosure. FIG. 16D is an illustration of a representative LCD module simulation defined within a simulation environment window according to an embodiment of the disclosure.

Detailed Description

Aspects of the present disclosure relate to an architecture for embedded system design, programming, and/or simulation, which includes a host system that provides a graphical programming environment for the development, modeling, simulation, testing, verification, and/or execution of modular programs corresponding to embedded applications that are executable by a target system. Any given modular program includes program code directed to performing embedded system operations in association with a particular embedded application.

In general, the term embedded application can be defined as a) a particular manner in which the target system is put to use; b) a collection of target system functions or operations that categorize or define a given embedded system's capabilities; and/or c) program instructions resident on the target system that serve as application program software that manages, controls, or implements such target system use or embedded system capabilities. Thus, a modular program can be defined as application program code that, when executed by the target system, manages controls, or implements a particular embedded application.

The host system's graphical programming environment facilitates the modeling and simulation of embedded system devices, elements, or resources; and the generation of embedded application program code, which can include modular programs as further described below. The host system's graphical programming environment also facilitates the transfer or download of embedded application program code to the target system, and the simulation of embedded application code either on the host system itself and/or in association with application program code execution on the target system. In several embodiments, an architecture in accordance with the present disclosure can support or include a suite of add-on devices, elements, or resources that can be coupled to the target system to support or implement a particular type of embedded system functionality. A suite of add-on devices can include add-on input devices (e.g., one or more types of push buttons or toggle buttons, a keypad, or other input device); add-on output devices (e.g., one or more types of LED or LCD displays, a speaker, or other output device); add-on sensing devices (e.g., a temperature sensor or an optical sensor); and/or add-on actuating devices (e.g., a servo device and associated driver units). The graphical programming environment can provide for the modeling and simulation of such add-on devices, as well as the generation of embedded application code corresponding thereto.

Various embodiments of the present disclosure can flexibly support or implement any type of open loop or closed loop hardware-in-the-loop (HIL), processor-in-the-loop (PIL), and/or software-in-the loop (SIL) test configuration in a simple, efficient, minimal overhead or essentially overhead free manner by way of controlling, sequencing, or synchronizing target- side operations and host-side operations based upon target - host data packet transfer. For instance, in several embodiments (e.g., corresponding to a closed loop target - host configuration), a target system can remain in a wait state until receipt of a data packet from the host system, after which the target system can perform target-side operations associated with a current simulation or execution time interval or increment. Following completion of such target-side operations, the target system can output a data packet directed to the host system, and return to the target-side wait state. The host system can remain in a host-side wait state until receipt of a data packet from the target system, after which the host system can perform host-side operations associated with the current simulation or execution time interval or increment. Upon completion of such host-side operations, the host system can output a data packet directed to the target system, and return to the host-side wait state. Thus, target- side operations and host-side operations can be performed in a separated, alternating, or sequenced manner, where target-side operations and host-side operations can be triggered by or synchronized to data packet receipt from the host system and the target system, respectively.

In view of the foregoing, target-side operations can occur in accordance with a recurrent target-side communication loop, and host-side operations can occur in accordance with a recurrent host-side communication loop. In multiple embodiments, the initiation of a given iteration of the recurrent target-side communication loop can be controlled, regulated, or gated by the combination of a) an increment in a target-side sample or simulation time interval, which can correspond to a real time operation or process; and b) packet receipt from the host system. The initiation of a given iteration of the recurrent host-side communication loop can be controlled, regulated, or gated by packet receipt from the target system. The recurrent target-side communication loop's synchronization to a target-side sample or simulation time increment in combination with the alternating execution of target-side communication loop iterations and host-side communication loop iterations results in the mutual synchronization of target-side operations and host-side operations in a straightforward, reliable, temporally predictable, and essentially overhead free manner. Taken together, a single iteration of a target-side communication loop in association with a single iteration of a host-side communication loop can be defined as a target - host communication cycle. In various embodiments, the target system can store multiple independently executable modular programs, where any given modular program corresponds to a distinct or independent embedded application. Modular programs can include one or more preconfigured, predefined, or factory provided modular programs (hereafter "factory programs") and/or one or more user customized or user defined modular programs (hereafter "user programs"). The target system can include a selection interface that is responsive to user input, and which provides a set of selection signals or selection signal correlates to a bootloader configured to selectively initiate the execution of a particular program instruction set or modular program in response to such user input. In general, selection signal correlates can be signals that the target system's bootloader can interpret or decode in order to identify or determine selection signal values.

Factory programs can provide a target system with default or factory-provided functionality corresponding to one or more types of embedded applications. For instance, a set of factory programs can be directed to enabling a target system to implement one or more of a mass storage device (e.g., a thumb drive or USB data storage device), a data acquisition device, a signal generation device, a data logging device, signal or databus analysis device, specific LAB functional-test unit, or another type of device. User programs can be directed to providing the target system with user customized, user defined, or user specific functionality. A given user program can be based upon program code originally generated (e.g., from scratch) by the user, and/or program code within another user program or factory program.

Architectural Overview

FIGs. 1A and IB are block diagrams showing aspects of an architecture 10 for embedded system design, development, programming, and/or simulation according to an embodiment of the disclosure. The following description references FIGs. 1A and IB simultaneously. In an embodiment, the architecture 10 includes at least one bootload-selective multi-configuration target system, apparatus, or device 100 (hereafter "target system") that can be configured for communication with a test or host platform or system 400.

Aspects of Representative Host System Embodiments

The host system 400 can be a computing platform, computer system, or computing device that includes a processing unit, a memory, a set of user or developer input / output (I/O) interface devices (e.g., a mouse, a keyboard, and a display device), a data storage device (e.g., a hard disk drive), and a set of host communication resources 498 that facilitate or enable communication with external systems or devices, such as the target system 100. The host system's communication resources 498 can include hardware, firmware, and/or software configured to implement one or more types of signal or data exchange interfaces, for instance, a set of data transfer interfaces that can correspond to one or more of an RS-232 interface, a Universal Synchronous/Asynchronous Receiver/Transmitter (USART), a Universal Serial Bus (USB) interface, an Ethernet interface, one or more types of wireless signal transfer interfaces, and/or another type of interface.

The host system 400 provides a graphical embedded system development environment 410 for developing, modeling, simulating, testing, and/or executing modular programs 140 that are intended for transfer or download to and execution by the target system 100. In various embodiments, the embedded system development environment 410 includes a graphical programming framework that facilitates or enables graphical or visual programming operations through which aspects of target system operation can be designed, simulated, tested, and implemented.

The host system 400 includes a set of embedded system development resources 500, which can include a set of databases, libraries, modules, components, and/or tools that operate in association with the graphical programming framework, and which facilitate modular program development, download, testing, simulation, and/or execution. As further detailed below, the set of embedded system development resources 500 can include a set of programmable graphical objects or blocks that can be configured to model and/or implement particular aspects of target system operation.

In general, the graphical programming framework enables target system modeling and simulation by way of user selective configuration of graphical blocks, such that one or more portions of a target system can be represented by a set of block diagrams. A given block can correspond to or represent an embedded system process, for instance, corresponding to or implementing an algorithm (e.g., associated with a particular modular program 140) or a device driver. A block can have a graphical user interface (GUI) associated therewith, which facilitates the definition or assignment of default parameter values or data values corresponding thereto.

The graphical programming framework can further provide or be associated with an automatic code generator 420, which can generate embedded application program code or program instructions that can implement one or more embedded algorithms and/or device drivers. Such algorithms or device drivers can be graphically represented by blocks. Generated code can include, for instance, program instructions corresponding to an embedded application algorithm, program instructions for controlling or communicating with I/O, sensing, or actuating devices, or firmware associated with a target communication resource. Generated code can be compiled and/or downloaded to the target system 100 as portions of one or more modular programs 140 that implement a particular type of target-side functionality. Additionally, generated code can remain on the host system 400 as portions of one or more host-side modular programs 140 that facilitate the design, development, simulation, testing, and/or implementation of particular target-side functionality. In a representative embodiment, the embedded system development environment 410 is a Matlab / Simulink environment (The Math Works, Inc., Natick MA, USA) that includes Real Time Workshop (RTW) and Real Time Workshop Embedded Coder (RTWEC), which can automatically generate code for modeling and/or implementing portions of the target system 100. Other embodiments of the present disclosure can be based upon other embedded system design environments, for instance, the LabVIEW graphical programming environment (National Instruments Corporation, Austin TX, USA), or the Scicos Block Diagram Modeler/Simulator (www-rocq.inria.fr/scicos, developed at INRIA, the French National Institute for Research in Computer Science and Control, Rocquencourt, FR (www.inria.fr)) .

The host system 400 can include a number of hardware, firmware, and/or software elements directed to performing particular processes or operations corresponding to an embedded system test, simulation, or execution configuration under consideration. Such elements can include a set of host-side communication modules 470 that manage recurrent host-side communication loop operations, and at least one host processing module 474 currently under consideration. The host processing module 474 can correspond to, operate in accordance with, or define portions of a simulation process that occurs on the host system 400 (e.g., a host simulation process or host-side simulation process). The host-side communication modules 470 can include a host reception module 472, a host transmission module 476, and a trigger module 478, as further described in detail below. The host reception module 472 can correspond to, operate in accordance with, or define portions of a host receiver process or host reception process. Similarly, the host transmission module 474 can correspond to, operate in accordance with, or define portions of a host transmitter process or host transmission process. In some embodiments, the host-side communication modules 470 can include a host processing module 474 currently under consideration.

A host communication unit 490 can include hardware, firmware, and/or software that facilitates or enables packet receipt from and/or packet transfer to the target system 100. In an embodiment, the host communication unit 490 can serve as a packet transfer interface for one or more of the host reception module 472, the host transmission module 476, and the trigger module 478. The host communication unit 490 can include one or more elements within the set of host communication resources 498, in a manner that depends upon a host system and/or a target system configuration under consideration. Aspects of Representative Target System Embodiments

The target system 100 can include hardware and/or software elements configured to selectively execute modular programs 140 in response to user input directed to a selection interface 200 or an advanced user selection device 300. The target system 100 can store multiple modular programs 140 in one or more memories 120, 210, where such modular programs 140 can be factory programs 142 and/or user programs 144. In general, separate modular programs 140 can correspond to separately or independently executable embedded applications (e.g., a particular modular program 140 can comprise an embedded application that can be executed independent of another modular program 140). A given modular program 140 can correspond to a process that when executed can implement a categorically distinct, related, or identical type of embedded application or embedded system with respect to the execution of another modular program 140 that resides on the target system 100. A single target system or device 100 in accordance with the present disclosure can facilitate the selective simulation, emulation, and/or implementation of multiple embedded applications or embedded systems by way of the selective execution of target resident modular programs 140.

In various embodiments, the target system 100 includes a bootloader 130 that includes or is associated with a program selection module 132. The bootloader 130 can determine a particular set of program instructions to which target system execution is to be transferred in response to user interaction with the selection interface 200 and/or an advanced user selection device 300. For instance, depending upon a set of selection signals generated as a result of user interaction with the selection interface 200, the bootloader 130 can determine a selected execution address, and initiate target system program instruction execution beginning at the selected execution address. A selected execution address or a program instruction to which the bootloader 130 transfers target system execution can correspond to a particular a) factory program 142; b) user program 144; or c) set of program instructions corresponding to a target system support routine (e.g., a driver), such as a set of program instructions corresponding to in-application programming (IAP) operations, which can form a portion of an IAP module 134. Depending upon embodiment details, an IAP module 134 can be a portion of or distinct from the bootloader 130.

As indicated above, the target system 100 can include a set of add-on devices, elements, or resources 101 configured to support embedded operations performed by one or more modular programs 140. The set of add-on devices 101 can include, for instance, a set of add-on user interface devices 102, a set of add-on sensing devices 106, and a set of add-on actuating devices 108. The set of add-on user interface devices 102 can include one or more input devices 104 (e.g., a keypad, a button, or a touch screen) and/or output devices 105 (e.g., a display device such as an LCD, a set of LEDs, or a multi-segment display). The set of add-on sensing devices 106 can include sensing elements such as a thermocouple or temperature encoder, and the set of add-on actuating devices 108 can include elements such as a stepper motor, a servomotor, or other electromechanical actuator. As further detailed below, the target system 100 additionally includes a set of target communication resources 198 that facilitate or enable communication with external systems or devices, such as the host system 400. Such communication resources 198 can include hardware, firmware, and/or software configured to implement one or more types of signal or data exchange interfaces, such as an RS-232 interface, a US ART interface, a USB interface, an Ethernet interface, one or more types of wireless signal transfer interfaces, and/or another type interface.

The target system 100 further includes a set of target-side communication modules 170 that manage recurrent target-side communication loop operations. The target-side communication modules 170 can include a target reception module 172, a target transmission module 176, and a timing manager 178. The target-side communication modules 170 can cooperatively operate in association with the execution of at least one target processing module 174 under consideration. The target processing module 174 can correspond to, operate in accordance with, or define portions of a simulation process that occurs on the target system 100 (e.g., a target simulation process or target-side simulation process). The target reception module 172 can correspond to, operate in accordance with, or define portions of a target receiver process or target reception process. Similarly, the target transmission module 176 can correspond to, operate in accordance with, or define portions of a target transmitter process or target transmission process. In some embodiments, the target-side communication modules 170 can include a target processing module 174 currently under consideration.

A target communication unit 190 can include hardware, firmware, and/or software that facilitates or enables packet receipt from and/or packet transfer to the host system 400. In an embodiment, the target communication unit 190 can serve as a packet transfer interface for one or both of the target reception module 172 and the target transmission module 176. The target communication unit 190 can include one or more elements within the set of target communication resources 198, in a manner that depends upon a target system and/or a host system configuration under consideration.

As shown in FIG. IB, in various embodiments the target system 100 includes a processing unit or microcontroller unit (MCU) 110, a selection interface 200, and possibly an off-chip memory 210. The processing unit 110 and at least a portion of the selection interface 200 can be carried by a common support structure 290, such as a circuit board, set of circuit boards, or housing. Off-chip memory 210 and/or other elements (e.g., one or more add-on devices 101) can be similarly carried by the common support structure 290.

The processing unit 110 can include a microprocessor core or instruction processor 112; a timing unit 114; and an on-chip memory 120. The processing unit 110 can further include particular communication and/or embedded application support resources, for instance, which can form one or more portions of the target system's set of communication resources 198. For instance, the processing unit 110 can include a set of input peripherals 192; a set of output peripherals 194; a set of data communication and General Purpose Input / Output (GPIO) peripherals 196; and/or other resources or elements corresponding to one or more types of embedded applications that the target system 100 is configured to support. Particular communication and embedded application support resources can include, for instance, an Analog to Digital Converter (ADC), a Digital to Analog Converter (DAC), pulse width modulation (PWM) circuitry, a Universal Synchronous / Asynchronous Receiver / Transmitter (USART), an RS-232 interface, an IEEE-485 interface, an Ethernet interface, an Inter-Integrated Circuit (I2C) interface, a Controller Area Network (CAN) interface, and/or other types of elements.

The on-chip memory 120 can include at least one register set 122; a run-time or execution memory 124; a bootloader 130 that can include a program selector or program selection module 132 and an In Application Programming (IAP) module 134; a set of modular programs 140, which can include one or more factory programs 142 and/or one or more user programs 144; a set of target-side communication modules 170; and possibly one or more configuration tables 180, 182. A configuration table 180, 182 can reference or include a set of modular program starting addresses.

While the embodiment of FIG. IB illustrates modular programs 140 residing within the on- chip memory 120, in some embodiments one or more modular programs 140 (e.g., user programs 144) can reside in the off-chip memory 210. Representative manners in which modular programs 140 can be organized within or mapped to particular portions of the target system's memory 120, 210 are described in detail below with reference to FIGs. 4A - 5C.

In certain embodiments, the memory 120 can include an operating system that serves as an interface between an executing modular program 140 and target hardware. In such embodiments, the modular program 140 can rely upon the operating system to manage or coordinate target processes, target task prioritization and scheduling, and target hardware allocation. However, in multiple embodiments, the target system 100 need not include an operating system. In such embodiments, an executing program module 140 is itself directly responsible for managing or coordinating essentially all primary aspects of target system operation. Target system embodiments that omit or exclude an operating system can provide one or more of reduced cost, reduced overhead, enhanced simplicity, better task timing control, and increased or maximal availability of target system resources for an embedded application under consideration. The memory 120 can include one or more of a cache memory, volatile and/or nonvolatile Random Access Memory (RAM), and Read Only Memory (ROM). The RAM can include, for instance, one or more types of Static RAM (SRAM), dynamic RAM (DRAM), and/or magnetoresistive RAM (MRAM). The ROM can include one or more types of programmable ROM (PROM), such as flash memory or electrically erasable PROM (EEPROM).

Each element of the processing unit 110 can be coupled by a set of buses 118. The instruction processor 112 can retrieve and execute stored program instructions, in a manner understood by one of ordinary skill in the art. Such stored program instructions can facilitate or effectuate the simulation or implementation of a type of embedded system functionality under consideration.

The processing unit 110 can exhibit a Von Neumann, Harvard, Modified Harvard, reconfigurable, or other type of architecture, in a manner understood by one of ordinary skill in the art. The processing unit 110 can include or be, for instance, a microcontroller, a digital signal processor (DSP), a microprocessor, a System on a Chip (SoC), or a configurable / programmable logic device such as a Field Programmable Gate Array (FPGA). In a representative implementation, the processing unit 110 can be an STM8 or STM32 family microcontroller (STMicroelectronics, Geneva, Switzerland). In another representative implementation, the processing unit 110 can be a commercially available processor, microcontroller, or configurable / programmable logic device, such as produced by Atmel Corporation (San Jose, CA), Intel Corporation (Santa Clara, CA), Maxim Integrated Products (Sunnvale, CA), Microchip Technology Incorporated (Chandler, AZ), NXP Semiconductors Group (Eindhoven, the Netherlands), Nuvoton Technology Corp. (Hsinchu Science Park, Taiwan), Renesas Electronics Corporation (Kawasaki, Kanagawa Japan), Texas Instruments Incorporated (Dallas, TX), Xilinx, Inc. (San Jose, CA), or another company.

Depending upon embodiment details, the target system 100 can include additional and/or other elements, for instance, particular types of digital signal, analog signal, mixed-signal, radio frequency (RF), or mathematical processing (e.g., encryption / decryption) elements or resources. Such additional or other elements can be internal or external to the processing unit 110. Aspects of Representative Host-Side Embedded System Development Resources As indicated above, the host system 400 includes a set of embedded system development resources 500, which includes elements, resources, or modules that form portions of or operate in association with the graphical embedded system development environment 410 to facilitate embedded system development, modeling, simulation, testing, and/or verification operations, which can include one or more host processes corresponding to host-side hardware and/or software, and one or more target processes corresponding to target-side hardware and/or software. The embedded system development resources 500 facilitate particular aspects of modular program development, modeling, simulation, download, testing, and/or execution.

FIG. 1C is a block diagram showing representative elements within a set of embedded system development resources 500 according to an embodiment of the disclosure. In an embodiment, the set of embedded system development resources 500 includes a blockset library 510; a modular program library 540; a set of built-in and/or third-party functions, resources, or tools 550; a set of compiling and linking tools 560; and an adjunct software component library 580.

The blockset library 510 can include multiple sets of graphical blocks. Any given block set can include a number of blocks that are categorically related with respect to modeling and simulating the operation or functionality of a type of target system or host system device, element, structure, or resource. In an embodiment, the blockset library 510 includes a host communication blockset 510, a target communication blockset 514, a target peripheral driver blockset 520, one or more built-in or third party blocksets 522, and one or more add-on device blocksets 530.

The host communication blockset 512 and the target communication blockset 514 can include blocks that are respectively directed to modeling and simulating packet-based communication between the host system 400 and the target system 100, including communication controlled by way of recurrent communication loops and corresponding communication cycles in accordance with particular embodiments of the present disclosure. The target peripheral driver blockset 520 can include blocks that are directed to modeling and simulating the operation of target system peripherals. A built-in or third party blockset 522 can include blocks that are directed to modeling and simulating the operation of predetermined or commonly encountered types of embedded system elements or resources, such as digital signal processing, radio frequency (RF), signal acquisition, signal generation, GPS system, input / output (e.g., push / toggle buttons, character/graphical display and interface units, Light Emitting Diodes (LED), or gauges / instrumentation) and/or other elements. The built- in or third party blockset 522 can also include blocks corresponding to target system drivers, signal processing algorithms, control system algorithms, and/or other algorithms.

FIG. ID is a block diagram showing representative elements within an add-on device blockset 530 according to an embodiment of the disclosure. In general, an add-on device blockset 530 can include blocks directed to modeling and simulating the operation of particular types of target-side devices, elements, or resources that the target system can utilize in order to implement an embedded application under consideration. Thus, an add-on device blockset 530 includes blocks corresponding to the target system's set of add-on devices 101, in order to facilitate modeling or simulation of the target system's add-on devices 101.

In an embodiment, the add-on device blockset 530 includes an add-on I/O blockset 532, an add-on sensing device blockset 536, and an add-on actuating device blockset 538. The addon I/O blockset 532 can include an add-on input device blockset 534 (e.g, directed to user input operations) and an add-on output device blockset 535 (e.g., directed to the provision of visual output to a user). The add-on input device blockset 534 includes blocks directed to modeling and simulating the operation of one or more types of target system input devices such as a keypad, a button (e.g., a push button or a toggle button), a joystick, or a touch pad, panel, or screen. Similarly, the add-on output device blockset 535 includes blocks directed to modeling and simulating the operation of particular types of target system output devices such as one or more types of LCD displays, one or more types of LED displays (e.g., a multi- segment display), a speaker, or another type of output device. The add-on sensing device blockset 536 can include blocks directed to modeling and simulating essentially any type of sensing element, such as a thermocouple; a temperature encoder; a pressure sensor; a GPS module; an accelerometer, a gyroscope, or one or more portions of an inertial measurement unit (IMU); a magnetic compass; a gravity sensor; or a photodetector. The add-on actuating device blockset 538 can include blocks directed to modeling and simulating essentially any type of actuating element, such as a stepper or servo motor. As further described below with reference to FIGs. 15A - 16D, a set of add-on block GUIs can be associated with particular blocks within the add-on device blockset 530. The set of add-on block GUIs can facilitate user configuration or customization of add-on block functionality in accordance with a specific configuration of target-side devices, elements, or resources associated with an embedded application under consideration.

Referring again to FIG. 1C, the modular program library 540 can include a set of factory programs 142 and/or user programs 144, as well as specific factory provided embedded application algorithms 542 and/or user provided embedded application algorithms 544 that can respectively correspond to factory programs 142 and user programs 144. A given factory provided and/or user provided embedded application algorithm 542, 544 may provide a base level of functionality corresponding to a type of embedded application under consideration, and may be extensible or customizable to facilitate the development and simulation of a modular program suited to particular embedded application requirements.

The set of built-in or third-party tools 550 can include one or more standard tools for embedded application modeling and simulation, such as Signal Processing Blockset, Simulink Fixed Point, or Stateflow (which are Mathworks, Inc. add-on blocksets) . The set of compiling and linking tools 560 can include tools directed to creating executable embedded application program code, such as a Keil compiler (Keil - an ARM Company, Piano, TX USA, www.keil.com) and/or one or more portions of the GNU compiler collection (GCC, gcc.gnu.org, Free Software Foundation, www.fsf.org). Finally, the adjunct software component library 580 can include a set of add-on, adjunct, or associate software components, such as an IAP component or module 582 and possibly a custom controls library such as an Object Linking and Embedding Control extension (OCX) library or Dynamic Link Library (DLL).

FIG. IE is a block diagram of a representative graphical simulation model 550 having graphical blocks organized within a simulation environment window 412 generated by way of the graphical embedded system development environment 410 in accordance with an embodiment of the disclosure. In an embodiment, the representative graphical simulation model 550 includes a user interface model 552, a sensing model 554, an algorithm model 556, and a deployment or utilization environment model 558. Additonally or alternatively, a simulation model can include an actuation model (not shown), in a manner understood by one of ordinary skill in the art.

The user interface model 552 includes a number of graphical blocks corresponding to target- side I/O elements, and the sensing model 554 includes a number of graphical blocks corresponding to target-side hardware elements such as particular add-on sensing elements, devices, or modules. The algorithm model 556 includes one or more graphical blocks corresponding to a set of target-side algorithms under development, testing, or simulation. Once simulated, tested, and verified, such algorithms can be programmed into the target system 100. The utilization environment model 558 includes a number of graphical blocks that correspond to a physical system or environment in which the target 100 is to be deployed or utilized. The utilization environment model 558 can also be referred to as a plant model, in a manner understood by one of ordinary skill in the art. The graphical blocks of each of the user interface model 552, the sensing model 554, and the algorithm model 556 are defined, selected, organized, and configured to support the development, testing, simulation, and/or verification of particular types of target system functionality in order to facilitate the implementation of an embedded application in a utilization environment under consideration.

The representative simulation model 550 shown in FIG. IE corresponds to an aircraft control system. In such a simulation model 550, the user interface model 552 can include a joystick block, a keypad block, and a graphical LCD block. The sensing model 554 can include an IMU block, a GPS block, a pressure sensor block (e.g., corresponding to a barometric pressure sensor), and a magnetic compass block. The algorithm model 556 can include a signal processing algorithm having program instructions directed to processing signals received from the sensing model 554; and a control algorithm having program instructions configured to receive such processed signals and generate aircraft control signals in response thereto. The utilization environment model 558 can include an aircraft simulation model configured to receive aircraft control signals and perform particular operations (e.g., simulated flight control operations) in response to the aircraft control signals, and further configured to provide feedback to the control algorithm. The utilization environment model 558 can additionally include a parameter display model configured to present or display aircraft status or state information by way of graphical representations of aircraft gauges or instruments. The representative simulation model 550 can simulate aircraft control operations in accordance with an HIL, PIL, and/or SIL simulation configuration. Depending upon configuration details, signals corresponding to target-side blocks can be generated by actual target-side hardware elements, devices, or modules, or generated (i.e., software simulated) by host-side program instructions corresponding to such blocks. During simulation operations, signal or data transfer between target-side blocks and host-side blocks occurs by way of a number of target - host communication cycles that involve a recurrent target-side communication loop and a recurrent host-side communication loop and corresponding data packet transfer in accordance with embodiments of the present disclosure.

Aspects of Representative Target System Programming Interfaces

In various embodiments, the target system 100 can be programmed by way of a host-side target programming interface 600. In some embodiments, the target system 100 can additionally or alternatively be programmed by way of an adjunct programming device 700 that can be configured to communicate with each of the target system 100 and the host system 400 at particular times.

In general, target system programming operations involve the transfer or download of factory programs 142 and/or user programs 144 from a modular program library 540 (e.g., which resides on the host system 400 or an adjunct programming device 700) to the target system's on-chip memory 120 and/or off-chip memory 210. Such programming operations can occur by way of IAP operations, which can be initiated in response to user input received by way of the selection module 200, as further described below. In several embodiments, the target programming interface 600 or an adjunct programming device 700 facilitates or enables user identification, selection, modification, and/or confirmation of a set of modular programs 140 to be transferred from a modular program library 540 to the target system 100. In some embodiments, the target programming interface 600 or adjunct programming device 700 can further facilitate or enable user identification or selection of target system memory addresses at which modular programs 140 are to be stored. The set of modular programs 140 to be downloaded to the target system, and possibly one or more target system memory addresses corresponding thereto, can be specified by a modular program download list or data structure. In a number of embodiments, the target programming interface 600 or an adjunct programming device 700 can include elements configured to provide or support the generation of and user interaction with a graphical user interface (GUI) that enables user identification and arrangement of modular programs 140 to be downloaded to the target system's memory 120, 210. A representative GUI provided by the target programming interface 600 is detailed hereafter. For purpose of simplicity and to aid understanding, in the description that follows the target programming interface 600 and a modular program download list are directed to storing user programs 144 in the target system's memory 120 based upon user input, where the user input can specify at least one target system memory address at which a user program 144 is intended to reside.

FIG. 2A is a block diagram illustrating portions of a representative target programming GUI 610 provided by a target programming interface 600 according to an embodiment of the disclosure. In an embodiment, the target programming GUI 610 includes a number of graphical control elements and graphical input elements, such as one or more graphical buttons, text boxes, list boxes, and the like. The target programming GUI 610 can include, for instance, a target status button 612; an add user program button 614; a remove user program button 616; a program target button 618; and a finish or exit button 620.

In response to user selection of the target status button 612, the target programming GUI 610 can communicate with the target system 100, retrieve current target system status information, and provide or display such status information, for instance, indicating whether the target system 100 is ready for programming. In response to user selection of the add user program button 614, the target programming GUI 610 can create or add an entry to a user program download list, and enable the user to identify a first or next user program 144 for inclusion in the user program download list as further described below. In response to user selection of a remove user program button 616, the target programming GUI 610 can remove a user program 144 from the user program download list. In response to user selection of the program target button 618, the target programming GUI 610 transfers control to the target programming interface 600, which communicates with the target system 100 by way of IAP operations to download and store user programs 144 specified in the user program download list to the target system's memory 120. Following user selection of the add user program button 614, user selection of a browse button 624 facilitates user identification or selection of a particular user program 144 for inclusion in the user program download list. In various embodiments, user programs 144 added to the user program download list can be executable binary files (e.g., .bin and/or .hex files). The target programming GUI 610 can include a set of text boxes 626a-d configured to display user program information in response to user identification or selection of a particular user program 144 for inclusion in the user program download list. Such user program information can include a user program filename (e.g., the name of an executable file stored on the host system 400, an adjunct programming device 700, or another device, system, or network); a user-assigned descriptor or identifier (ID) associated with the user program 144; a user program size; and possibly a storage or starting address at which the user program 144 is to reside within the target system's memory 120 (hereafter "target system address"). In several embodiments, the target system address of a first user program 144 within the user program download list can be predetermined, fixed, or assigned a default value. For instance, the target system address of a first user program 144 can automatically be assigned a default value based upon a lowest address at which user programs 144 are defined to reside within the target system's memory 120. In certain embodiments, the target system address of a user program 144 added to the user program download list corresponds to a fixed or predetermined address offset relative to a first or last user program 144 that is already referenced within the user program download list. In other embodiments, the target system address of a user program 144 added to the user program download list depends upon the sizes of other user programs 144 already present within the user program download list, and/or user input overriding automatically calculated user program storage addresses. Some embodiments can receive user input overriding a default value for the target system address corresponding to a first user program 144 and/or other user programs 144 within the user program download list.

In response to user selection of the program target button 618, the target programming interface 600 can transfer a) a sequence of user programs 144 specified by the user program download list; and possibly b) a table associating user programs 144 with their target starting addresses to the target system 100. Such transfer can occur by way of IAP operations, in accordance with a particular IAP mode selected on the target system 100 by way of user input directed to the selection interface 200.

In multiple embodiments, the target programming interface 600 and any corresponding GUI provided thereby can include program instructions configured to execute on one or more types of computer systems or computing devices. The target programming interface can further be configured to communicate with a target system 100 and transfer multiple modular programs 140 thereto in a manner that is independent of any specific type of modular program development tool, toolkit, or toolchain. As a result, an architecture 10 provided by embodiments the present disclosure can be independent of any given manufacturer's modular program development tool, toolkit or toolchain. Additionally, an architecture 10 in accordance with embodiments of the present disclosure can enable one or more factory program developers and one or more user program developers to respectively generate factory programs 142 and user programs 144 in a manner that is not limited to a particular modular program development tool, toolkit, or toolchain. That is, one or multiple factory program developers and one or multiple user program developers can respectively develop factory programs and user programs by way of identical, similar, or dissimilar tools, toolkits, or toolchains. Aspects of Representative Adjunct Programming Devices

FIG. 2B is a block diagram of a representative adjunct, associate, or corollary programming device 700 according to an embodiment of the disclosure. In an embodiment, an adjunct programming device 700 can include a processing unit 710 that is coupled to each of a memory 720, a communication unit 730, a target programming interface 750, and a power source 790 (e.g., a battery and/or a line power coupling). The processing unit 710 can be, for instance, an MCU or other type of device that can be configured to execute program instructions stored in the memory 720.

In various embodiments, the memory 720 includes an adjunct programming manager 725. The adjunct programming manager 725 can include program instructions directed to communicating with a computer system (e.g., the host system 400) or other programming device 700, downloading or retrieving modular programs 140 therefrom, and storing such modular programs 140 in the adjunct programming device's memory 720. In some embodiments, the adjunct programming manager 725 can include, for instance, one or more program instruction sets that facilitate or enable program module retrieval or download by way of IAP operations (e.g., involving USB, USART, or another type of communication interface) supported by the adjunct programming device's processing unit 710 and communication unit 730.

The adjunct programming manager 725 can further include program instructions directed to performing particular target system communication and/or programming operations, for instance, a) acquiring target system status or configuration information; and b) uploading modular programs 140 to a target system 100. In some embodiments, such target system communication and/or programming operations can occur by way of IAP operations supported by the adjunct programming device's processing unit 710 and communication unit 730. The adjunct programming manager 725 can additionally include program instructions directed to managing a programming user interface 740. In several embodiments, the programming user interface 740 includes hardware and/or software (e.g., firmware) configured to provide a visual user interface. The programming user interface 740 can include, for instance, one or more visual display elements such as a flat panel display device. In some embodiments, the programming user interface 740 includes a set of touch sensitive portions, regions, devices, or elements, which can correspond to or include one or more of a display element, a button, a keypad, a touchpad, a slider, a rotator, or other touch responsive user interface element. Such touch sensitive elements can be implemented by way of a touch screen, or a printed circuit board (PCB) that carries touch sensitive hardware, for instance, a PCB that includes S- Touch™ printed circuit board technology.

In a representative embodiment, the programming user interface 740 includes a one or more of a display window 780, a set of push buttons 782, a ratiometric rotator wheel 784, and possibly a ratiometric slider 786, one or more of which can be implemented using touch sensitive elements. The adjunct programming manager 725 can generate a GUI within the display window 780, which can include portions of a target programming GUI 610 such as that described above. A GUI generated by the adjunct programming manager 725 can facilitate user management of modular program download operations, as well as the aforementioned target system communication and/or programming operations.

In some embodiments, an adjunct programming device 700 can selectively serve as a programming device configured to perform target system programming operations, and an advanced user selection device 300 configured to generate selection signals or selection signal correlates in response to user input. Following receipt of such user input, a combined adjunct programming device / advanced user selection device can transfer selection signals or selection signal correlates to the target system 100 such that the target system's bootloader 130 can transfer execution control to an appropriate user selected program instruction set or modular program 140.

Aspects of Representative Selection Interface Embodiments

Depending upon embodiment details, a user interface that facilitates or enables user selection of a program instruction set or a modular program 140 for execution can be an integral part of a target system 100, or a portion of a device that is separate or distinct from the target system 100, which can be coupled to the target system 100. A user interface that is carried by or which forms an integral part of a target system 100 can be defined as a primary or basic interface, and user interface that is separate from or selectively couplable to the target system 100 can be defined as a secondary or advanced interface.

Aspects of Representative Primary or Basic Selection Interfaces

In various embodiments, a primary or basic selection interface 200 can include one or more user selectable, user manipulable, or user positionable elements or devices configured to receive user input. In multiple embodiments, the selection interface 200 can include one or more electromechanical interfaces or devices, such as a set of switches (e.g., a set of DIP switches or a rotary switch), a set of jumpers, a potentiometer, a knob, or a slider, which can be configured to provide, output, or route selection signals corresponding to one or more selection interface settings established by way of user input. In some embodiments, the selection interface 200 can include a visual or graphical display device, such as a liquid crystal display (LCD). Additionally or alternatively, the selection interface can include a touch sensitive device, screen, pad, panel, or interface (e.g., which can be distinct from or an integral portion of a visual display device). As further detailed below, a touch sensitive selection interface 200 can include one or more touch sensitive user selection elements such as a touch sensitive switch, button, knob, slider, or other element. In some embodiments, such touch sensitive selection elements can be visual or graphical elements. The selection interface 200 can include a set of outputs coupled to a set of processing unit input pins (e.g., a set of boot pins or configuration pins), which can provide or carry the selection signals in a manner that enables the bootloader 130 to determine and/or transfer processing unit execution to a selected execution address based upon one or more selection signal values. For instance, in several embodiments, as part of a target system reset or booting process, the bootloader 130 can retrieve, receive, or read the values of selection signals carried by the relevant processing unit input pins; determine a selected execution address based upon such selection signal values; and jump to the selected execution address.

Aspects of Representative Advanced Selection Interfaces

FIG. 3 is a block diagram of a representative advanced, adjunct, auxiliary, or corollary user selection device 300 according to an embodiment of the disclosure. In an embodiment, an advanced user selection device 300 can include a processing unit 310 that is coupled to each of a memory 320, a communication unit 330, an advanced selection interface 340, and a power source 390 (e.g., a battery and/or a line power coupling). The processing unit 310 can be, for instance, an MCU or other type of device that can be configured to execute program instructions stored in the advanced user selection device's memory 320.

In various embodiments, the memory 320 includes an advanced interface manager 325. The advanced interface manager 325 can include program instructions directed to supporting or performing target system communication and user selection operations, for instance, a) acquiring or retrieving target system status or configuration information; b) managing operations performed by the advanced selection interface 340, such as displaying target system status or configuration information and receiving user input corresponding to selection signals or selection signal correlates; and c) transferring selection signals or selection signal correlates to the target system 100. The target system's bootloader 130 can execute an appropriate program instruction set or modular program 140 based upon the selection signals or selection signal correlates received from the advanced user selection device 300. In some embodiments, particular target system communication operations can occur by way of IAP operations supported by the advanced user selection device's processing unit 310 and communication unit 330.

In several embodiments, the advanced selection interface 340 includes hardware and/or software (e.g., firmware) configured to provide a visual user interface. The advanced selection interface 340 can include, for instance, one or more visual display elements such as a flat panel display device. In some embodiments, the advanced selection interface 340 includes a set of touch sensitive portions, regions, devices, or elements, which can correspond to or include one or more of a display element, a button, a keypad, a touchpad, a slider, a rotator, or other touch responsive user interface element or device. Such touch sensitive elements can be implemented by way of a touch screen, or a printed circuit board (PCB) that carries touch sensitive hardware, for instance, a PCB that includes S-Touch™ printed circuit board technology (STMicroelectronics, Geneva, Switzerland). In a representative embodiment, an advanced selection interface 340 includes a display window 380, a set of push buttons 382, a ratiometric rotator wheel 384, and possibly a ratiometric slider 386, one or more of which can be implemented by way of touch sensitive elements. The advanced interface manager 325 can display target configuration information in the display window 380, and detect user input, for instance, input received by way of touch sensitive elements, to facilitate the aforementioned target system communication and/or user selection operations.

Aspects of Representative Bootloader Embodiments

In general, the bootloader 130 includes one or more program instruction sets to which target system execution control is immediately or directly transferred in response to a target system reset. Thus, the first program instructions that are executed after a target system reset are bootloader instructions. A target system reset can occur in response to an initial power-up condition, or in response to user input corresponding to a reset command (e.g., received by way of user interaction with a reset button carried by the target system 100).

A first portion of the bootloader's execution can involve the initialization of particular target resources, and possibly the performance of target self-test operations. Following the first portion of the bootloader's execution, a second portion of the bootloader's execution can involve determining a selected execution address based upon a set of selection signal values, followed by transferring execution to a program instruction stored at the selected execution address, as further detailed hereafter. As indicated in FIGs. 1A and IB, the bootloader 130 can include a program selection module 132 and an IAP module 134. In several embodiments, the program selection module 132 includes program instructions directed to converting or mapping selection signals corresponding to user input received by way of the selection interface to a selected execution address that identifies the beginning of a) an embedded application support routine, such as a portion of the IAP module 134 (e.g., an IAP program instruction set); or b) a modular program 140. The program selection module 132 can further include a set of program instructions (e.g., one or more jump instructions) that transfers target system execution to a program instruction stored at the selected execution address. Thus, based upon a set of selection signal values, in various embodiments the program selection module 132 can transfer target system execution to a) program code within or associated with the bootloader 130, such as a program instruction sequence forming a portion of the IAP module 134; or b) a modular program 140.

The IAP module 134 includes program instructions directed to performing one or more types of IAP operations, which can involve the transfer or download of program code (e.g., modular programs 140) from a source system or device such as the host system 400 or an adjunct programming device 700 to the target system's on-chip and/or off-chip memories 120, 210 by way of a communication or data transfer interface that is supported by each of the target system 100 and the source device. In various embodiments, the target system 100 and the source device(s) can support multiple types of data transfer interfaces, such as two or more of a USART interface, a USB interface, an I2C interface, a CAN interface, an Ethernet interface, a particular wireless signal transfer interface, or another interface. In several embodiments, the program selection module 132 can map particular selection signal values corresponding to or indicating an IAP request to distinct one or more functional portions or subroutines of the IAP module 134. Distinct functional portion of the IAP module 134 can facilitate or enable data communication by way of a distinct type of data transfer interface. In various embodiments, the bootloader 130 can include a primary, default, or factory provided bootloader that when executed initializes particular target system resources, and which possibly performs a set of target system self test operations. In such embodiments, the primary bootloader can include the IAP module 134. The program selection module 132 can be implemented as a secondary bootloader to which the primary bootloader transfers execution control. In some embodiments, the primary bootloader can transfer control to the secondary bootloader in response to determining that a set of selection signal values does not correspond to an IAP request, that is, the set of selection signal values corresponds to a modular program execution request. In other embodiments, the primary bootloader can transfer control to the secondary bootloader once target system initialization and/or self-test operations are complete, such that the secondary bootloader can determine whether the set of selection signal values corresponds to an IAP request or a modular program execution request. In certain embodiments, program code corresponding to a primary bootloader and a secondary bootloader can exist as a unified or single set of program instructions, which can be factory provided or user defined.

Aspects of Representative Modular Program Memory Maps

Depending upon embodiment details, modular programs 140 can be organized within the memory 120 in multiple manners. For instance, the organization of modular programs 140 within the memory 120 can depend upon whether some or all target resident modular programs 140 are sequentially stored at addresses based upon actual modular program sizes, or at predetermined address increments corresponding to a predetermined maximum modular program size. A manner in which modular programs 140 are organized within the memory 120 can define particular aspects of a memory map, as further described in detail hereafter.

Aspects of Representative Fixed Memory Map Embodiments

In general, a memory map can be defined based upon a manner in which the bootloader 130, selectively executable modular programs 140, program instruction sets corresponding to one or more selectively executable embedded application support routines (e.g., the IAP module 134), and possibly one or more configuration tables 180, 182 are organized within the memory 120. FIG. 4A is a block diagram of a selective execution fixed memory map (hereafter fixed memory map) 150 according to a representative embodiment of the disclosure. In an embodiment, the bootloader 130, which includes the program selection module 132 and the IAP module 134, is defined to reside within a first or bootloader region or portion 152 of the memory 120, spanning a bootloader address range. Hence, the bootloader' s starting and ending addresses are predetermined or known. Factory programs 142 are defined to reside within a second or factory program portion 154 of the memory 120, spanning a factory program address range; and user programs 144 are defined to reside in a third or user program portion 156 of the memory 120, spanning a user program address range.

In such an embodiment, factory programs 142 can be defined to have a maximum factory program size, and user programs 144 can be defined to have a maximum user program size. Separate factory programs 142 are sequentially stored at starting addresses that correspond to the maximum factory program size, whether any such factory program 142 actually occupies the maximum factory program size. Thus, separate factory programs 142 reside at uniformly spaced starting addresses within the memory's factory program portion 154. The starting address of any given factory program 142 is therefore fixed or predetermined, and can be defined by the starting address of a first factory program 142 (or the starting address of the factory program portion 154) plus an integral multiple (e.g., 0, 1, 2,...) of the maximum factory program size. In the fixed memory map 150, the maximum factory program size can therefore be defined as a fixed factory program starting address increment.

Similarly, separate user programs 144 are sequentially stored at starting addresses that correspond to the maximum user program size. Separate user programs 144 reside at uniformly spaced starting addresses within the program memory's user program portion 144, whether any such user program 144 actually occupies the maximum user program size. The starting address of any given user program 144 is therefore fixed, and can be defined by the starting address of a first user program 144 (or the starting address of the user program portion 156) plus an integral multiple (0, 1, 2...) of the maximum user program size. In the fixed memory map 150, the maximum user program size can therefore be defined as a fixed user program starting address increment. For purpose of illustration, in the representative embodiment of FIG. 4 A the bootloader's size is defined as 40K Bytes, the maximum factory program size is defined as 15K Bytes, and the maximum user program size is defined as 80K Bytes. Factory program starting addresses are separated from each other by a fixed increment of 15K Bytes, and user program starting addresses are separated from each other by a fixed increment of 80K Bytes. Additionally, the factory program portion 154 of the representative fixed memory map 150 can accommodate up to two factory programs 142a-b (e.g., the target system 100 can be pre-programmed with two factory programs), and the user program portion 156 can accommodate up to four user programs 144a-d. Representative hexadecimal starting addresses for the bootloader 130, a first and a second factory program 142a-b, and a first through a fourth user programs 144a-d are also illustrated in FIG. 4A. Other embodiments can provide for a different maximum factory program size, a different number of factory programs 142, a different maximum user program size, and/or a different number of user programs 144. FIG. 4 A additionally shows a representative embodiment of the selection interface 200 that includes three selection elements (e.g., switches or jumpers) 202a-c, each of which can be user configured to indicate a selection signal value of 0 or 1. Other embodiments can include other numbers and/or alternate types of selection elements. In FIG. 4A, three selection signal values corresponding to the three selection elements 202a-c are provided to three input pins Al - A3 of the processing unit 110. Thus, the three input pins Al - A3 can be defined to carry a triplet of selection signal values (hereafter referred to as a selection signal triplet). The program selection module 132 can receive, read, or determine the selection signal values specified by a selection signal triplet; map such values to a selected execution address in accordance with the fixed memory map 150; and initiate the execution of program code corresponding to the selected execution address.

In various embodiments, mapping operations performed by the program selection module 132 in accordance with the fixed memory map 150 can involve a table or data structure that associates distinct selection signal triplets with distinct selected execution addresses. A selected execution address can correspond to the starting address of a) an intra-bootloader or bootloader-based program instruction set (e.g., associated with the IAP module 134); b) a factory program 142; or c) a user program 144. FIG. 4B is a representative embodiment of a static configuration table 180 that provides an illustrative mapping of selection signal values to selected execution addresses according to an embodiment of the disclosure. In an embodiment, in response to the detection of a selection signal triplet equal to (0, 0, 0), the program selection module 132 maps this selection signal triplet to a first starting execution address, which corresponds to a bootloader-based program instruction set that performs IAP operations by way of a USB port (hereafter referred to as IAP - USB). The program selection module 132 accordingly transfers processing unit execution control to the IAP - USB program instruction set that begins at the first starting execution address.

Similarly, in response to the detection of a selection signal triplet equal to (0, 0, 1), the program selection module 132 maps this selection signal triplet to a second starting execution address, which corresponds to a bootloader-based program instruction set that performs IAP operations by way of a USART port (hereafter referred to as IAP - USART). The program selection module 132 accordingly transfers execution control to the IAP - USART program instruction set that begins at the second starting execution address.

In response to the detection of a selection signal triplet equal to (0, 1, 0), the program selection module 132 maps this selection signal triplet to a third starting execution address, which corresponds to an address at which a first factory program 142a begins. The program selection module 132 accordingly transfers processing unit execution control to the first factory program 142a. Similarly, in response to the detection of a selection signal triplet equal to (0, 1, 1), the program selection module 132 maps this selection signal triplet to a fourth starting execution address that corresponds to an address at which a second factory program 142b begins. The program selection module 132 additionally transfers processing unit execution control to the second factory program 142b.

In response to the detection of a selection signal triplet equal to (1, 0, 0), the program selection module 132 maps this selection signal triplet to a fifth starting execution address that corresponds to an address at which a first user program 144a begins. The program selection module 132 then transfers processing execution control to the first user program 144a. Similarly, in response to the detection of a selection signal triplet equal to (1, 0, 1), the program selection module 132 maps this selection signal triplet to a sixth starting execution address that indicates an address at which a second user program 144b begins. The program selection module 132 accordingly transfers processing unit execution control to the second user program 144b. In response to the detection of a selection signal triplet equal to (1, 1, 0), the program selection module 132 maps (1, 1, 0) to a seventh starting execution address that indicates the beginning of a third user program 144c, and transfers processing unit execution control to the third user program 144c. Finally, in response to a selection signal triplet equal to (1, 1, 1), the program selection module 132 maps (1, 1, 1) to an eighth starting execution address that indicates the beginning of a fourth user program 144d, and transfers processing unit execution control to the fourth user program 144d.

In addition or as an alternative to the above, in some embodiments any given address determination or mapping by the program selection module 132 in accordance with the fixed memory map 150 can correspond to a predetermined reference or base address, such as the starting address of the bootloader 130 or the starting address of a first factory program 142a, to which an appropriate address offset can be added to yield an appropriate selected execution address. Thus, an alternate static configuration table 180 can map selection signal triplets to address offsets, which the program selection module 132 can add to a reference address to generate starting execution addresses. In such embodiments, the reference or base address can also reside in the static configuration table 180.

In embodiments that involve a fixed memory map 150, the set of starting execution addresses is fixed or predetermined. Thus, in several embodiments, a static configuration table 180 can be stored as an array of constants within the bootloader' s source code. In a representative implementation, the program selection module 132 includes program code corresponding to a set of switch-case or multiway branch statements, where branching or processing unit execution is selectively controlled in accordance with selection signal values that can be mapped, converted, or transformed into selected execution addresses (e.g., in accordance with the static configuration table 180). Aspects of Representative Flexible Memory Map Embodiments

In various embodiments, a total number of factory programs 142 and/or user programs 144 stored in the target system's memory 120, 210 can be flexibly defined, configured, expanded, or adjusted. Additionally, factory programs 142 and/or user programs 144 can be sequentially stored in the memory 120 such that the starting address of any given factory program 142 and/or user program 144 is respectively based upon the actual amount of memory occupied by other factory programs 142 and/or user programs 144 within the memory 120. In some embodiments, one or more default factory programs 142 can be provided or made available (e.g., on a computer readable medium) to a user, and particular individual factory programs 142 can be selectively transferred from a source device (e.g., the host system 400 or an adjunct programming device 700) to the target system 100 in response to user input. In a number of embodiments, a number of factory programs 142 and their organization within the memory 120 can be fixed, while a number and/or organization of user programs 144 can be flexible, configurable, or expandable. In certain embodiments, particular factory programs 142 can be pre-loaded in the target system 100, and their starting addresses can remain fixed thereafter. For ease of understanding, the following description considers a set of pre-loaded factory programs 142 having fixed, predetermined, or static starting addresses within the memory 120, and flexibly configurable user programs 144 having starting memory addresses that depend upon actual user program size(s). User programs 144 can be flexibly mapped, allocated, tracked, referenced, or accessed within the on-chip memory 120, and in some embodiments also the off-chip memory 210, by way of a modifiable configuration data structure. In the description that follows, a reference to the on-chip memory 120 can therefore include or encompass portions of the off-chip memory 210.

FIG. 5A is a block diagram of a selective execution flexible memory map (hereafter flexible memory map) 160 according to a representative embodiment of the disclosure. In an embodiment, a dynamic configuration table 182 is defined to reside within a first portion or region 162 of the memory 120, within a configuration table address range. The bootloader 130 is defined to reside within a second or bootloader portion 164 of the memory 120, spanning a bootloader address range; factory programs 142 are defined to reside within a third or factory program portion 166 of the memory, spanning a factory program address range; and user programs 144 are defined to reside within a fourth or user program portion 168 of the memory 120, spanning a flexible or configurable user program address range. The representative flexible memory map 160 of FIG. 5 A illustrates two factory programs 142a-b and two user programs 144a-b residing within the memory 120. FIG. 5 A illustrates representative starting addresses corresponding to the dynamic configuration table 182, the bootloader 130, the first and second factory programs 142a-b, and the first and second user programs 144a-b. The memory 120 includes a fifth, spare, or available portion or region 169, to which user programs can be flexibly allocated (e.g., by way of IAP operations). In some embodiments, the fifth or spare memory portion 169 can include addresses that map to the off-chip memory 210.

FIG. 5B is a block diagram of a representative dynamic configuration table 182a according to an embodiment of the disclosure. In an embodiment, the dynamic configuration table 182a includes a data field that stores a user program count identifying a total number of user programs 144 currently stored in the memory 120; and a set of data fields storing or referencing the starting address of each user program 144 within the memory 120. The location of the starting address of each user program 144 can be defined as an offset from the starting address of the dynamic configuration table 182a itself. For instance, the starting address of a given user program 144 can be defined at the memory address at which the dynamic configuration table 182a begins, plus a multiple of a predetermined offset from the dynamic configuration table's starting address. The predetermine offset can be, for instance, a multiple of a number of bytes or a number of words, depending upon the architecture of the processing unit 110 being used. For instance, a first user program 144a can begin at a one word offset from the dynamic configuration table's starting address, a second user program 144b can begin at a two word (i.e., 2 x 1 word) offset from the dynamic configuration table's starting address, and so on. For the flexible memory map 160 of FIG. 5 A, the user program count equals 2, and thus the dynamic configuration table 182a includes a starting address of the first user program 144a and a starting address of the second user program 144b. In a number of embodiments, a dynamic configuration table 182 can include additional or other information or data than described above in relation to FIG. 5B. FIG. 5C is a block diagram of a representative dynamic configuration table 182b according to another embodiment of the disclosure. In an embodiment, the dynamic configuration table 182b includes a data field that stores the current user program count; and, for each user program 144 stored in the memory 120, the dynamic configuration table 182b includes a data field storing or referencing a user program starting address, a data field storing a user program size, and an array of data fields storing a user program identifier or name. The dynamic configuration table 182b in FIG. 5C assumes an array of User Program Name/Descriptor of size 10 words. In some embodiments, a user program identifier or name can be user specified by way of a programming user interface 740, as further detailed below.

Depending upon embodiment details, a dynamic configuration table 182 can be defined to have a predetermined maximum size (e.g., 2K Bytes), or the dynamic configuration table 182 can be a dynamically allocated array that the bootloader 130 loads or generates based upon a number of user programs and user program sizes transferred to the target system 100 during IAP operations. In some embodiments, the dynamic configuration table 182b can be populated or updated by program instructions associated with or corresponding to a portion of the bootloader 130 during or following IAP operations.

In a manner analogous to that described above with reference to FIGs. 4A and 4B, some embodiments that include a dynamic configuration table 182 can also include a static configuration table 180 that references or stores static or fixed starting addresses, such as a set of starting addresses corresponding to bootloader-based program code (e.g., one or more portions of the IAP module 134) and starting addresses corresponding to one or more factory programs 142a-b. Thus, the program selection module 132 can access a static configuration table 180 or a dynamic configuration table 182 based upon the value of a selection signal to determine an appropriate selected execution address. Other embodiments can include a single or unified configuration table having static as well as dynamic portions, which the program selection module 132 can accordingly access based upon the selection signal value.

In embodiments in which the number and/or organization of factory programs 142 can be user configured within the memory 120 in addition to the number and organization of user programs 144, a dynamic configuration table 182 can include a set of data fields storing the starting address of each factory program 142 resident on the target system 100, and possibly a data field storing a current count of such factory programs 142 and/or a set of data fields storing an identifier or descriptor corresponding to each factory program 142. In accordance with various embodiments described herein, the program selection module 132 can utilize multiway branch statements and/or one or more portions of a data structure such as a static configuration table 180, a dynamic configuration table 182, or a unified configuration table to map selection signal values generated or received by way of user interaction with the selection interface 200 to a selected execution address that corresponds to a program instruction that initiates a) a given type of IAP operation (e.g., IAP-USP or IAP-USART); b) the execution of a particular factory program 142a-b; or c) the execution of a particular user program 144a-b. For instance, in a representative implementation, the program selection module 132 can map a selection signal value corresponding to 0 or 1 to an address at which a program instruction that initiates IAP - USB operations resides, or an address at which a program instruction that initiates IAP - USART operations resides, respectively. The program selection module 132 can respectively map a selection signal value corresponding to 2 or 3 to an address at which a first factory program 142a begins or an address at which a second factory program 142b begins. Analogously, the program selection module 132 can map a selection signal value of 4, 5, or higher to an address at which a first user program begins 144a, an address at which a second user program begins 144b, or an address at which another user program begins, respectively. Thus, for a plurality of unique selection signal value sets (e.g., 000, 001, 010, 011, 100, 101, etc., where each triplet of binary values represents a distinct selection signal value set) that can be received or generated based upon user interaction with the selection interface 200, the program selection module 132 can associate each unique selection signal value set with a starting address of a unique program instruction set. Each unique program instruction set can correspond to a particular type of IAP operation, a distinct factory program 142, or a distinct user program 144.

FIG. 5A additionally shows a representative embodiment of the selection interface 200 that includes a configurable selection element 204. In some embodiments, the configurable selection element 204 can provide an analog or digital selection signal or selection signal correlate that can exhibit a variable, flexible, or graduated range of values, in a manner that corresponds to the number of modular programs 140 currently stored in the memory 120.

As previously indicated, a selection interface 200 can include a set of visual feedback elements such as a flat panel display element (e.g., an LCD display device) and/or a set of LEDs, which can be coupled to a set of processing unit pins (e.g., input and/or output pins). The program selection module 132 and/or other portions of the bootloader 130 can provide or transfer information or data such as the digital selection signal, a user program count, and possibly other information to the visual feedback element(s). For instance, the program selection module 132 can provide or transmit the user program count and/or other information to the set of visual feedback elements prior to or in association with providing a digital selection signal value to the visual feedback element(s). The visual feedback element(s) can indicate or display the user program count to a target system user to facilitate the receipt of an appropriate or intended selection signal value and the corresponding execution of an intended program instruction set or modular program 140. Following the determination or generation of the digital selection signal, the program selection module 132 can provide, issue, transmit, or transfer the digital selection signal to a set of processing unit output pins, such that the visual feedback element(s) can indicate or display the digital selection signal value to a user. After a target system reset occurs and initialization operations are complete, the program selection module 132 can determine whether a current or most recently generated digital selection signal value remains constant or unchanged during a predetermined time interval (e.g., approximately 5, 10, 15, or 30 seconds), thereby indicating correct user input, prior to mapping the digital selection signal value to a selected execution address.

In some embodiments, the selection interface 200 can include one or more touch sensitive elements, portions, or regions (e.g., which can be distinct from or integral with the set of visual feedback elements) that can implement a set of configurable selection elements 204 such as a button, a keypad, a touchpad, a selection knob or wheel, a slider bar, or another type of user interface element. The touch sensitive element(s) can generate or output digital values rather than analog values, such that the program selection module 132 can directly perform a touch sensitive element digital output to digital selection signal value mapping, thereby eliminating an analog to digital conversion such as that described above. Such touch sensitive element digital output to digital selection signal mapping can occur in a manner that corresponds to a number of modular programs 140, such as a number of user programs 144, currently stored in the memory 120.

In addition or as an alternative to the foregoing, in certain embodiments, the program selection module 132 can provide or transmit to a set of visual feedback elements (e.g., associated with the selection interface 200) information or data corresponding to a list or table that identifies selectively executable program instruction sets, factory programs 142, and/or user programs 144 and selectable digital values associated therewith to the visual feedback element(s). Particular information or data within such a list or table can be based upon or retrieved from one or more configuration tables 180, 182.

FIG. 6 is an embodiment of a representative target mode selection list or table 188 that can be provided to and/or displayed by a visual feedback element (e.g., a flat panel display device such as an LCD) in accordance with an embodiment of the disclosure. As indicated in FIG. 6, a target mode selection list 188 can include or specify for each distinct execution address available for user selection a) a digital value; and b) a corresponding descriptor or identifier that identifies or categorizes a program instruction set or modular program 140. Thus, for each distinct starting address of a user selectable program instruction set or modular program 140 within the on-chip memory 120 and possibly the off-chip memory 210, the target mode selection list 188 can include a selectable digital value and an identifier.

Depending upon embodiment details, one or more identifiers within the selection list 188 can correspond to a target system execution mode; and/or one or more identifiers can correspond to a modular program filename or descriptive name, such as a descriptive factory program name or a descriptive user program name. A target system execution mode identifier can provide, for instance, a categorical indication of a manner in which the target system 100 can be configured to operate in response to user input. In a representative embodiment, execution mode identifiers can include "IAP - USB," "IAP - USART," "Factory Program 1," "Factory Program 2," "User Program 1," "User Program 2," and so on. Representative descriptive factory program names can include, for instance, "Thumb Drive" or "Flash Drive" (e.g., corresponding to a mass storage device such as a USB flash drive), or "Function Generator" (e.g corresponding to a function generator or arbitrary function generator device), "Data Logger" (e.g. corresponding to a data logging device with predetermined input types and a configurable sampling rate), and/or "Signal Probe" (e.g. corresponding to an oscilloscope or a signal monitoring and interpreting device) or another name that conveys a type of functionality associated with a given factory program 142. Representative descriptive user program names can include, for instance, "Data Logger 1," "Signal Generator," "Temperature Controller," or another name that conveys a type of functionality associated with a given user program 144. Aspects of Representative Bootloader-Based Selective Execution Processes

FIG. 7 is a flow diagram of a process 800 for bootloader-based selective target system execution according to an embodiment of the disclosure. In an embodiment, the process 800 is initiated in response to a target system reset. The process 800 can include a first process portion 802 that involves performing a set of target initialization and possibly target self-test operations, followed by a second process portion 804 that involves determining a set of selection signal values in response to user input received by way of the selection interface 200 or an advanced user selection device 300. A third process portion 806 can involve determining whether the set of selection signal values corresponds to an IAP request. If so, a fourth process portion 808 can involve determining whether the IAP request corresponds to an IAP - USB request. If so, a fifth process portion 810 can involve transferring execution control to a set of program instructions (e.g., a portion of the IAP module 134) directed to performing target programming operations by way of USB-based IAP operations. Otherwise, a sixth process portion 812 can involve transferring execution control to a set of program instructions (e.g., a portion of the IAP module 134) directed to performing target programming operations by way of USART-based IAP operations. Following either of the fifth or sixth process portions 810, 812, the process 800 can include a seventh process portion 814 that involves waiting for a target system reset.

If in association with the third process portion 806 it is determined that the set of selection signal values does not correspond to an IAP request, an eighth process portion 816 can involve loading one or more configuration tables 180, 182 (e.g., a static configuration table 180 and/or a dynamic configuration table 182), and a ninth process portion 818 can involve accessing configuration table content (e.g., by mapping the set of selection signal values to a selected location or offset within a configuration table 180, 182) to determine a starting execution address. A tenth process portion 820 can involve jumping to a starting execution address specified by the selected offset within the configuration table 180, 182. Such a starting execution address corresponds to a modular program 140 (e.g., a factory program 142 or a user program 144) that is associated with the set of selection signal values. Aspects of Minimal Overhead Target - Host Communication

As indicated above, various embodiments of the present disclosure can flexibly support or implement any type of open loop or closed loop target - host test configuration in a simple, efficient, minimal overhead manner by way of controlling, sequencing, or synchronizing target-side operations and host-side operations based upon target - host data packet transfer.

FIGs. 8A and 8B are block diagrams respectively showing a representative data packet 900 and a representative dummy packet 950 according to an embodiment of the disclosure. In an embodiment, the data packet 900 includes a data structure having a number of portions or fields, including a header portion or header 902, a data portion 904, and an optional terminal portion or terminator 906. In various embodiments, a data packet 900 can be defined and/or configured in response to user input by way of a GUI.

The header 902 can store a set of bits, bytes, or words that indicate the start or a beginning segment or section of the data packet 900; and the terminator 906 can store a set of bits, bytes, or words that indicate the end or final segment or section of the data packet 900. The data portion 904 can store a sequence of bits, bytes, or words corresponding to or representing data, which can be interpreted, analyzed, processed, or operated upon in accordance with an embedded application under consideration. In various embodiments, the size, span, or data carrying capacity of the data portion 904, as well as one or more data types corresponding to data carried by the data portion 904, can be configured or programmably defined in response to user input. Thus, depending upon embodiment details, the data portion 904 can carry one type of data, or multiple distinct types of data, that is, data formatted in accordance with different data formats. In the embodiment shown, the data portion 904 is configured to carry an unsigned 8-bit integer value, a double precision floating point value, and an unsigned 16- bit integer value. The data portion 904 can be configured to carry additional data types, in a programmably defined sequence, as indicated in FIG. 8A.

As further detailed below, aspects of embedded system simulation, testing, or execution operations in accordance with particular embodiments of the disclosure can involve the transfer of a packet for simulation control and/or initiation purposes, where one or more data values carried by such a packet may not be relevant to simulation control itself. FIG. 8B is a block diagram of a representative dummy, ghost, initiation, or control packet 950 according to an embodiment of the disclosure. The dummy packet 950 can have a structure that is identical, essentially identical, similar, or analogous to that of the data packet 900 described above. In general, the dummy packet 950 and the data packet 900 share matching headers 902, and matching terminators 906 in the event that the data packet 900 includes a terminator 906. Thus, a dummy packet 950 in accordance with an embodiment of the disclosure includes at least a header 902. In several embodiments, at least a portion of the digital values within the dummy packet's data portion 904 can be arbitrary or undefined.

Aspects of Representative Target - Host Test Configurations

FIG. 9 A is a block diagram of a dummy packet initiable simulation configuration 10a according to an embodiment of the disclosure, in which a set of target-resident communication modules includes at least one of a target receiver or reception module 172 and a target transmitter or transmission module 176, and a set of host-resident communication modules includes at least one of a host receiver or reception module 472 and a host transmitter or transmission module 476. The set of host-resident communication modules can additionally include a trigger generator or trigger module 478, which can initiate communication directed to the target system 100 in response to user input as further detailed below. Communication from the target system 100 to the host system 400 occurs by way of the target transmission module 176 and the host reception module 472; and communication from the host system 400 to the target system 100 occurs by way of the host transmission module 476 and the target reception module 172. In various embodiments, the inclusion or utilization of a single communication module or multiple communication modules within the set of target- side communication modules 170 and/or the set of host-side communication modules 470 can depend upon a simulation, text, or execution configuration under consideration, as further described below.

The target reception module 172 manages the target system's reception and verification of packets output by the host system 400. The target reception module 172 additionally controls the transition of target system operations from a target-side wait state to a target-side task execution state, such that the target system 100 remains in the target-side wait state until a complete or correct data packet 900 or dummy packet 950 has been received from the host system 400. When in a target-side task execution state, the target system 100 can a) execute program instructions corresponding to a target processing module 174 (e.g., program instruction directed to an embedded application algorithm, and/or device driver operation); and/or b) transmit packets to the host system 400 by way of the target transmission module 176. Upon exit from a target-side task execution state, control of target-side operations returns to the target reception module 172, thereby establishing a recurrent target-side communication loop.

In a manner analogous or similar to that described above, the host reception module 472 manages the host system's reception and verification of packets output by the target system 100. The host reception module 472 additionally controls the transition of host system operations from a host-side wait state to a host-side task execution state, such that the host system 400 remains in the host-side wait state until a complete, valid, or correct packet has been received from the target system 100. When in a host-side task execution state, the host system 100 can execute program instructions corresponding to a host-side processing module 474, and/or transmit packets to the target system 100 by way of the host transmission module 476. Upon exit from a host-side task execution state, control of host-side operations returns to the host reception module 472, thereby establishing a recurrent host-side communication loop. In general, embedded system modeling, simulation, or testing involves the performance of a set of target-side and/or host-side operations, processes, or functions that correspond to a predetermined time interval such as a particular simulation or sampling time increment; followed by the performance of a set of target-side and/or host-side operations, processes, or functions that correspond to a next sequential simulation or sampling time increment; and so on in a repeated manner until modeling, simulation, or testing terminates. Thus, simulation involves the execution of a set of target-side and/or host-side program instructions that correspond to a particular simulation or sampling time t_k, followed by the execution of a set of target-side and/or host-side program instructions that correspond to a next simulation or sampling time t_k+i- Various embodiments of the disclosure operate in accordance with a target - host communication process through which target-side and host-side operations are temporally defined with respect to a simulation time increment or interval, and sequenced with respect to each other as described in detail hereafter. Aspects of a Representative Target - Host Communication Process

FIG. 9B is a schematic illustration of a target - host communication process 1000 according to an embodiment of the disclosure. In general, simulation in accordance with a target - host communication process 1000 provided by the present disclosure involves a set of recurrent communication loops. More particularly, in various embodiments, simulation in accordance with a target - host communication process 1000 corresponding to FIG. 9B involves a recurrent target-side communication loop and a recurrent host-side communication loop that respectively include or encompass a number of target-side communication cycles and host- side communication cycles. A given target-side communication cycle and a counterpart host- side communication cycle can be defined as a target - host communication cycle. In an embodiment, a single or complete target - host communication cycle corresponds to a single target-side communication cycle (or a single pass or iteration through the recurrent target-side communication loop) and a single host-side communication cycle (or a single pass or iteration through the recurrent host-side communication loop). In various embodiments, a complete target - host communication cycle is temporally bounded by the span of a single simulation time increment or interval.

Within a particular target - host communication cycle, target-side operations and host-side operations occur sequentially in a segregated, separated, or alternating manner with respect to each other, such that the target system 100 remains in a target-side wait state while the host system 400 performs simulation operations corresponding to a current simulation time interval, and the host system 400 remains in a host-side wait state while the target system 100 performs simulation operations corresponding to the current simulation time interval. Based upon data packet reception, a recurrent target-side communication loop and/or a recurrent host-side communication loop can coordinate or synchronize the segregated or alternating operation of the target system 100 and the host system 400 within a current target - host communication cycle, and from one target - host communication cycle to a next target - host communication cycle. An embodiment of the present disclosure can exhibit deterministic timing behavior with respect to the duration of a single or multiple target - host communication cycles (e.g., where a given target - host communication cycle can temporally span a single sampling interval, or correspond to a predetermined number of sampling intervals), where such deterministic timing behavior is based upon specifying that target - host data packet transfer(s) initiated during a particular target - host communication cycle be completed within that same target - host communication cycle. The transition from one target

- host communication cycle to the next can correspond to or be defined with respect to the transition from one simulation or sampling time interval to a next simulation or sampling time interval.

In addition to the foregoing, a target - host communication process 1000 according to an embodiment of the present disclosure specifies that target - host data transfer initiated during a target - host communication cycle under consideration is completed during this same target

- host communication cycle. Therefore, a data packet 900 output by the target system 100 or the host system 400 during a given target - host communication cycle is intended to be received by the host system 400 or the target system 100, respectively, prior to the termination of this target - host communication cycle. In other words, packet transmission and packet reception are temporally bound to the target - host communication cycle in which such data packet transmission and data packet reception began. Thus, target - host communication initiated during a particular simulation time interval is completed during this simulation time interval, thereby avoiding target - host data communication overlap between one simulation time interval and another.

In various embodiments, the nature of a simulation, test, or execution configuration under consideration can determine particular aspects of packet transfer between the target system 100 and the host system 400. For instance, in an open loop target-side data acquisition configuration, the target system 100 acquires and transfers data packets 900 corresponding to sampled signals or data to the host system 400. Following receipt of one or more data packets 900, the host system 400 can analyze, process, and/or store data carried by such data packets 900. Thus, data transfer in an open-loop target-side data acquisition configuration is from the target system 100 to the host system 400. In an open loop host-side signal generation configuration, the host system 400 generates signals or data (e.g., in response to or based upon user input), and transfers data packets 900 corresponding to the generated signals to the target system 100. Following receipt of one or more data packets 900 that carry the generated data, the target system 100 can process or operate upon such data. Thus, data transfer in an open loop host-side signal generation configuration is from the host system 400 to the target system 100. In a closed loop configuration, the target system 100 transfers data packets 900 to the host system 400, and the host system transfers data packets 900 to the target system. A closed loop configuration can therefore be characterized by mutual data packet transfer between the target system 100 and the host system 400.

Depending upon hardware and/or software capabilities, a discrepancy can exist with respect to the best attainable accuracy of event, task, or communication timing between a target system 100 and a host system 400. In various situations, the temporal resolution of event or task timing (e.g., associated with data sampling) on the target system 100 can be better or more accurate than event or task timing on the host system 400. That is, the target system's timing mechanism can be more accurate than or have a finer temporal resolution than the host system's timing mechanism. For instance, a PC-based host system 400 that executes using a Microsoft Windows operating system, without using additional kernel resources, may not be able to guarantee timing resolution better than 1 msec with respect to responding to external events such as data sampling. Such a limitation in timing accuracy can be particularly problematic when dealing with real time simulation operations.

In particular embodiments of the disclosure (e.g., a configuration 10a such as that shown in FIG. 9 A), a target - host communication process 1000 can define the target system 100 as a master timing regulator for simulation events or tasks. As further detailed below, such embodiments can rely upon the target system's timing manager 178 to supervise or regulate the overall progress of simulation operations, such that target-side packet verification, packet processing, and packet transmission operations sequentially occur based upon the timing manager's generation or supervision of a target-side communication cycle advance signal. During a time interval corresponding to a given target-side communication cycle advance signal, the target system 100 can receive a packet 900, 950; perform one or more target-side processing operations; and/or transmit a packet 900, after which the target system 100 transitions to a target-side wait state. The target system 100 can exit or transition out of the target-side wait state in response to a next target-side communication advance signal (e.g., an increment in the target-side communication advance signal), in response to which the target system 100 can determine whether a packet 900 has been received from the host system 400. In several embodiments, a next target-side communication advance signal can be or correspond to a next (e.g., successive) increment in a simulation or sampling time interval. Thus, successive target-side communication cycles can be regulated based upon simulation or sampling time interval advancement, under the direction of the timing manager 178. In such embodiments, the host system 400 can effectively be synchronized to the target system 100 based upon reception of data packets 900 output by the target system 100. More particularly, the host system 400 can exit or transition out of a host-side wait state in response to receipt of a packet 900 from the target system 100. Upon exiting the host-side wait state, the host system 400 can perform one or more host-side processing operations and/or transmit a packet 900 to the target system 100, after which the host system 400 transitions to another host-side wait state during which the host system 400 waits for a next packet 900 from the target system 100. In terms of regulating the overall timing of simulation events or tasks, the host system 400 can thus be subservient or a slave to the target system 100. In an alternate embodiment, the host system 400 can serve as a master timing regulator for simulation events or tasks; or, one of the target system 100 and the host system 400 can be selectively or programmably configured (e.g., in response to user input) as a master timing regulator for simulation.

FIG. 9C is a flow diagram corresponding to the target - host communication process 1000 of FIG. 9B. With reference to each of FIG. 9B and 9C, a target - host communication process 1000 according to an embodiment of the disclosure includes a first target-side process portion 1002 in which the target system's timing manager 178 maintains target-side operations in a target-side wait state pending a simulation time increment. While in the wait state, the target system 100 can receive one or more portions of a packet 900, 950 transmitted by the host system 400 (e.g., an incoming data packet 900 can be stored in a buffer as it is received).

In response to a simulation or sample time increment, timing manager 178 transfers execution control to the target reception module 172. In a second target-side process portion 1004 the reception module 172 determines whether a complete, valid, and/or correct format packet 900, 950 has been received. In various embodiments, a complete, valid or correct data packet 900 includes an appropriate header 902, an appropriately sized data portion 904, and an appropriate terminator 906. A complete, valid, or correct dummy packet 950 includes at least an appropriate header 902. In the event that a complete, valid, or correct packet 900, 950 has not been received, the process 1000 remains at the first process portion 1002. Upon confirmation of complete, valid, or correct packet receipt, in a third target-side process portion 1006 the target reception module 172 can transfer execution control to the target processing module 174. In association with the third target-side process portion 1006, the target processing module 174 processes or operates upon data corresponding to or included within the received data packet 900, in a manner that corresponds to an embedded system application and/or corresponding simulation configuration under consideration.

In a fourth target-side process portion 1008, the target transmission module 176 transmits a data packet 900 to the host system 400. The fourth target-side process portion 1008 can be initiated upon transfer of execution control from the target processing module 174 to the target transmission module 176. Transmission of a data packet 900 to the host system 400 serves as an indication or signal to the host system that target-side simulation operations (e.g., target-side processing of the most-recently received data packet 900) corresponding to the current simulation time interval are complete, and host-side simulation operations corresponding to the current simulation time interval can proceed. Following the fourth target-side process portion 1008, the target-host communication process 1000 can return to the first target-side process portion 1002.

In a representative embodiment, the second through fourth target-side process portions 1004 - 1008 of FIG. 9C can be implemented by way of an interrupt service routine, which can be initiated or entered in response to a next simulation time increment in a manner understood by one of ordinary skill in the art.

In a first host-side process portion 1022, the host reception module 472 remains in a wait state pending receipt of a data packet 900. In a second host-side process portion 1024, the host reception module 472 determines whether a complete and/or correct data packet 900 has been received. In the absence of a complete and/or correct data packet 900, the host reception module 472 returns to or remains in the host-side wait state. Upon verification of complete and/or correct data packet reception, the host reception module 472 transfers execution control to the host processing module 474, which can perform processing operations associated with the received data packet 900 in a manner that corresponds to an embedded system application and corresponding simulation configuration under consideration.

Following the third host-side process portion 1026, the host processing module 474 can transfer execution control to the host transmission module 476 or return control to the host reception module 472 depending upon an embedded application and/or a simulation configuration under consideration. In the event that data packet transfer from the host system 400 to the target system 100 is desired or required, the host-side transmission module 476 can transmit a data packet 900 in a fourth host-side process portion 1028. Following the fourth host-side process portion 1028, or if data packet transfer from the host system 400 to the target system 100 upon completion of the third host-side process portion 1026 is unnecessary, execution control returns to the host reception module 472, which waits for the arrival of another data packet 900.

Aspects of Dummy Packet Simulation Initiation

As indicated by FIGs. 9B - 9C, in an embodiment of a target - host communication process 1000, the target system 100 can begin simulation operations in a target-side wait state, waiting to receive a data packet 900 from the host system; and the host system 400 can begin simulation operations in a host-side wait state, waiting to receive a data packet 900 from the target system 100. Thus, each of the target system 100 and the host system 400 can be in a mutual wait state with respect to each other. Such a situation can occur in the simulation of a closed loop configuration.

In certain situations, such as when packet communication occurs by way of an enumerated port (e.g., a USB virtual COM port or USB HID port), the target system 100 needs to be up and running through an initialization phase in order for the host system 400 to detect the presence of the target system 100. Similarly, the host system 400 needs to be up and running through at least an initial pass of the recurrent host-side communication loop that results in the host system's transmission of a data packet 900 in order for the target system 100 to detect the presence of the host system 400.

More particularly, target-side program instructions must be executing and ready to transmit a data packet 900 to the host system 400 in order for the host system 400 to detect the presence of the target system 100. However, the target system 100 begins operation in the target-side wait state, rather than a packet processing or packet transmission state. Moreover, the target system 100 remains in the target-side wait state until receiving a data packet 900 from the host system 400, but the host system 400 begins operation in the host-side wait state rather than a packet processing or packet transmission state. Thus, in such situations, at the outset of closed loop simulation operations, the host system 400 would fail to detect the target system 100 in the absence of an appropriate closed loop simulation initiation mechanism.

Analogously, host-side program instructions must be executing and ready to transmit a data packet 900 to the target system 100 in order for the target system 100 to detect the presence of the host system 400. However, the host system 400 begins operation in the host-side wait state, rather than a packet processing or packet transmission state. The host system 400 remains in the host-side wait state until receiving a data packet 900 from the target system 100, but the target system 100 itself begins operation and remains in the target-side wait state rather than a packet processing or packet transmission state. Hence, in such situations, at the outset of closed loop simulation operations, the target system 100 would fail to detect the presence of the host system 400 in the absence of an appropriate closed loop simulation initiation mechanism. An appropriate closed loop simulation initiation mechanism should be conceptually simple, resource efficient, and involve minimal or essentially zero overhead. Additionally, an appropriate closed loop simulation initiation mechanism should remain unchanged or essentially unchanged with respect to any variant of closed loop simulation under consideration (e.g., any type of HIL, PIL, and/or SIL simulation). Furthermore, an appropriate closed loop simulation initiation mechanism should naturally integrate into a target - host communication process 1000 such as that described above. Various embodiments in accordance with the present disclosure provide an appropriate simulation initiation mechanism by way of a host-side trigger module 478. In an embodiment, the host system 400 can include a trigger module 478 that can send a dummy, trigger, initiation, or ghost packet 950 to the target system 100 in response to host- side user input that initiates simulation operations (e.g., successive target-side and host-side operations in accordance with a target-host communication process 1000). Such host-side user input can be specified or selected by way of user selection of a GUI control (e.g., a graphical button) or menu item.

After the reception of a dummy packet 950, the target system 100 can transition out of a target-side wait state to a packet verification state, followed by a target-side processing state. After target-side processing operations are complete, the target system 100 can a) transmit a data packet 900 to the host system 400, thereby transitioning the host system 400 out of its host-side wait state; and b) return to the target-side wait state, thereby establishing the recurrent target-side communication loop. Following the receipt and verification of the data packet 900 output by the target system 100, the host system 400 can transition to a host-side processing state. After host-side processing operations are complete, the host system 400 can a) transmit a data packet 900 to the target system 100; and b) return to the host-side wait state, thereby establishing the recurrent host-side communication loop. FIG. 9D is a flow diagram of a dummy packet based simulation initiation process 1100 according to an embodiment of the disclosure. In an embodiment, the process 1100 includes a first process portion 1102 in which the target system 100 is initially operating in a target-side wait state, and a second process portion 1104 in which the host system 400 is initially operating in a host-side wait state. A third process portion 1106 can involve recurrently determining whether the trigger module 478 has been activated, for instance, in response to user input. If so, in a fourth process portion 1108 the host transmission module 474 or the host communication unit 490 can transmit a dummy packet 950 to the target system 100. In a fifth process portion 1110, the target system 100 can receive the dummy packet 900 and transition out of the target-side wait state. Receipt of the dummy packet 950 can cause the target system 100 to progress through the recurrent target-side communication loop. Thus, following the fifth process portion 1110, the target processing module 174 can acquire signals or data, the target transmission module 176 can transmit a corresponding data packet 900 to the host system 400, and the target system 100 can then return to a wait state pending receipt of a data packet 900 from the host system 400.

The inclusion of a trigger module 478 configured to initiate simulation operations by way of host-side transmission of a dummy packet 950 to the target system 100 facilitates or enables the use of an enumerated port (such as a USB virtual COM port or USB HID port) for communication between the target system 100 and the host system 400. Additionally, initiating simulation operations by way of host-side transmission of a dummy packet 950 to the target system 100 eliminates unnecessary communication protocol, handshaking, and/or packet definition requirements. Host-Transmission to Target-Reception Open Loop Configuration

In certain situations, the target system 100 can transmit dummy packets to the host system 400, for instance, in an open loop configuration in which the host system 400 transmits data packets to the target system 100, but the target system 100 is intended to retain overall timing control over each individual communication cycle that includes a recurrent host-side communication loop and a recurrent target-side communication loop.

FIG. 10 is a block diagram representing an open loop configuration 10b in accordance with the present disclosure, in which the host system 400 generates signals or data intended for target system reception and processing. In such a configuration 10b, data packet transfer is directed from the host system 400 to the target system 100. Following a simulation time increment and the target system's reception of a data packet 900 transmitted by the host system 400 and any target-side processing thereof, the target system 100 can transmit a dummy packet 950 to the host system 400 in order to synchronize the host system's data packet transmission operations with target system operation, such that overall simulation timing control is regulated by the target system 100.

Thus, for the simulation of a host-transmission to target-reception open loop configuration 10b, a target system 100 acting as a master simulation timing regulator can send a dummy packet 950 to the host system 400 to regulate, control, or synchronize the timing of the host system's data packet transmission to the target system 100 with respect to the target system's control of successive simulation or sample time increments. In view of the foregoing and as indicated by FIG. 9C, during simulation operations directed to a host-transmission to target- reception open loop configuration 10b, after processing data received from the host system 400, the third target-side process portion 1006 transfers target-side execution control to the target transmission module 176, which in association with the fourth target-side process portion 1008 transmits a dummy packet 950 to the host system 200. Upon completion of the fourth target-side process portion 1008, target-side execution control returns to the first target- side process portion 1002.

In response to receipt of the dummy packet 950, the host-side reception module 472 transfers execution control to the host-side processing module 474, which can generate a next set of signals or data that the host transmission module 476 can include in a data packet 900 that is transmitted to the target system 100.

Target-Transmission to Host-Reception Open Loop Configuration

FIG. 11 A is a block diagram representing an open loop configuration 10c in accordance with an embodiment of disclosure, in which the target system 100 sends data packets 900 (e.g., which include sampled data values) to the host system 400 in association with successive simulation time increments. In such a configuration, the host system 400 can remain synchronized to the target system 100 as a result of data packet reception itself. As a result, packet transfer from the host system 400 to the target system 100 in such a configuration is not necessary. Thus, for the simulation of a target-transmission to host-reception open loop configuration 10c, target - host synchronization based upon the target system 100 as a master simulation timing regulator does not require packet transmission from the host system 400 to the target system 100. Therefore, during simulation operations directed to a target- transmission to host-reception open loop configuration 10c, following receipt of a data packet 900 by the host-side reception module 472, the host-side processing module 474 can transfer or return host-side execution control to the host-side reception module 472, in association with which the host-side reception module 472 waits for another data packet 900. Correspondingly, for a target-transmission to host-reception open loop configuration 10c according to an embodiment of the disclosure, the target system 100 need not wait to receive packets 900, 950 from the host system 400, and verify whether packets 900, 950 are complete and/or correct. Rather, the target system 100 can remain in a target-side wait state until a next simulation time increment occurs, after which the target system 100 can perform data acquisition or sampling operations and then transfer a next data packet 900 to the host system 400. Target - host communication in such an open loop configuration 10c can be adapted accordingly, as described in detail hereafter.

FIG. 11B is a schematic illustration of a target - host communication process 1200 corresponding to a target-transmission to host-reception open loop configuration 10c according to an embodiment of the disclosure. FIG. 11C is a flow diagram corresponding to the target - host communication process 1200 of FIG. 11B. As indicated in FIGs. 1 IB and 11C, a first target-side process portion 1202 involves recurrently waiting for a next simulation time increment. In response to a simulation time increment, the timing manager 178 can transfer execution control to a target processing module 174, which can initiate or direct a second target-side process portion 1204 that involves sampling or acquiring data values. Next, in a third target-side process portion 1206 a target transmission module 176 can transmit a corresponding data packet 900 to the host system 400. Assembly of sampled data values into the data packet 900 can occur in association with one or both of the second and third target-side process portions 1204, 1206 depending upon embodiment details.

In a first host-side process portion 1222, a host reception module 472 remains in a wait state pending data packet receipt. In a second host-side process portion 1224, the host reception module 472 determines whether a complete and/or correct data packet 900 has been received. If not, the reception module 472 remains in the host-side wait state. Otherwise, the host reception module 472 transfers execution control to a host processing module 474, which processes the data corresponding to the received data packet 900 in a third host-side process portion 1226. Following the third host-side process portion 1226, control is transferred to the first host-side process portion 1222.

Aspects of Target - Host Test Configuration Variations

Depending upon embodiment details or a simulation configuration under consideration, one or both of the target system 100 and the host system 400 can include additional and/or other program instruction modules directed to processing data.

FIG. 12 is a block diagram of a representative target - host configuration lOd according to another embodiment of the disclosure, which includes a first and a second target processing module 174a, 174b as well as a first and a second host processing module 474a, 474b. In various embodiments, the definition and/or control sequence ordering of particular processing modules 174a-b, 474a-b can be user selected or programmably specified, for instance, by way of a GUI, in a manner understood by one of ordinary skill in the art. Target - host communication can occur in accordance with a process that is identical, essentially identical, analogous, or substantially similar to that described above, involving a recurrent target-side communication loop and a recurrent host-side communication loop that sequentially handle target-side and host-side simulation operations, respectively. Aspects of Packet Reception and Synchronization

In various embodiments, a determination of whether a complete, correct, or valid packet 900, 950 has been received can involve a packet synchronization process. Depending upon embodiment details or target and/or host system capabilities, a packet reception and synchronization process can be a high-level or a low-level process.

FIG. 13 A is a flow diagram of a high level packet reception and synchronization process 1300 according to an embodiment of the disclosure. Such a high level packet reception and synchronization process 1300 can be applicable in simulation situations involving communication by way of multiple types of communication channels, such as a Human Interface Device (HID) USB device class communication protocol where data packet transmission and reception is naturally processed by packet). In an embodiment, the process 1300 includes a first process portion 1302 that involves the host system's reception module 472 determining whether a packet 900, 950 has been received. In general, determination of whether a packet 900, 950 has been received can involve checking the value of a flag. Depending upon embodiment details and/or a type of communication port under consideration, determination of packet reception by the host system 400 can be handled at a high level by an operating system function call (e.g., when communication occurs by way of an HID port for the host system 400), or a library of function calls by the target system 100. While the description that follows indicates particular communication modules 170 corresponding to the target system 100, analogous types of operations can be performed by counterpart host system communication modules 470.

In the event that a packet 900, 950 has not been received, the process 1300 remains at the first process portion 1302. Upon confirmation of packet receipt, in a second process portion 1304 the target reception module 172 can retrieve the packet's contents (e.g., from a buffer), where the packet's contents can include one or more of a header 902, a data portion 904, and a terminator 906. In a third process portion 1306, the target reception module 172 determines whether the received packet 900, 950 is complete or correct. The third process portion 1306 can involve an examination of values within the packet's header 902 and possibly the packet's terminator 906, and can further involve determining whether the length of the packet's data portion 904 is appropriate. If the received packet 900, 950 is not complete or correct, the process returns to the first process portion 1302. Following the verification of a complete or correct data packet 900, the target reception module 172 can arrange or organize data therein in a fourth process portion 1308, and output the organized data (e.g., to a set of memory locations or addresses accessible to the target processing module 174) in a fifth process portion 1310. After the fifth process portion 1310, control returns to the first process portion 1302.

FIG. 13B is a flow diagram of a low level packet reception and synchronization process 1350 according to an embodiment of the disclosure. Such a low level packet reception and synchronization process 1350 can be applicable in simulation situations in which an operating system provides limited or no high level packet detection capabilities, for instance, in situations involving communication by way of a virtual COM port or a serial (RS232/COM) port where data is presented to the reception module 172 character by character. In an embodiment, the process 1350 includes a first process portion 1352 that involves the target reception module 172 determining whether a target - host synchronization condition exists. Such a synchronization condition can be indicated, for instance, by the value of a flag. In various embodiments, a target - host synchronization condition can be defined or determined based upon successful data packet reception. At the initiation of simulation operations, the target system 100 and the host system 400 are unsynchronized with respect to each other because neither the target system 100 nor the host system 400 has received a complete or correct data packet 900 or dummy packet 950.

In the event that the target reception module 172 determines that a synchronization condition exists (i.e., an in-synchronization condition exists), the reception module 172 can read an entire packet 900, 950 in a second process portion 1354, and determine whether the packet 900, 950 is complete or correct in a third process portion 1356. If the packet 900, 950 is incomplete or has an incorrect format, the reception module 172 sets or maintains the value of an out-of-synchronization indicator (e.g., by appropriately setting or maintaining the value of a synchronization flag) in a fourth process portion 1358, after which control returns to the first process portion 1352.

In the event that the target reception module 172 determines in the third process portion 1356 that a received packet 900, 950 is complete or correct, the reception module 172 can arrange or organize data within a data packet 900 in a fifth process portion 1360, and output the organized data (e.g., to a set of memory locations or addresses accessible to the target processing module 174) in a sixth process portion 1362. Following the sixth process portion 1362, the reception module 172 can set an in-synchronization indicator (e.g., by appropriately setting the value of a synchronization flag) in a seventh process portion 1364, after which control returns to the first process portion 1352.

If in association with the first process portion 1352 the target reception module 172 determines that a target - host synchronization condition does not exist (i.e., an out-of- synchronization condition exists), the reception module 172 can continually or repeatedly look for the arrival of a packet header 902 in an eighth process portion 1370, and determine in a ninth process portion 1372 whether a packet header 902 has arrived. If not, control can return to the eighth process portion 1370.

Once a data packet header 902 has arrived, the target reception module 172 can read or retrieve the remainder of the packet 900, 950 in a tenth process portion 1374, and determine in an eleventh process portion 1376 whether the received packet 900, 950 is complete or correct. If not, the target reception module 172 can signal an out-of-synchronization condition (e.g., by appropriately setting the value of a synchronization flag) in a twelfth process portion 1378, after which control can return to the first process portion 1352 such that the reception module 172 waits for the arrival of another packet 900, 950.

If the reception module 172 determines that a received packet 900, 950 is complete or correct, control can be transferred to the fifth through seventh process portions 1360-1364, in which the reception module 172 organizes data within a data packet 900, outputs the data, and establishes an in-synchronization condition (e.g., by appropriately setting the value of a synchronization flag). Following the seventh process portion 1364, the process 1350 can return to the first process portion 1352.

Aspects of Representative Communication Module GUIs

FIG. 14 is an illustration of a representative communication module graphical user interface (GUI) 1400 according to an embodiment of the disclosure, which can be directed to the configuration of a target reception module 172. Such a GUI 1400 can include a set of GUI elements such as a drop down menu, text boxes, a check box, and/or other GUI controls. For instance, the GUI 1400 of FIG. 14 includes a number of text boxes for receiving user input directed to defining the format of a data packet header 902, the data format(s) of a data packet's data portion 904, a data packet terminator 906, and a simulation time increment value. This GUI 1400 further includes a check box for enabling the target reception module's wait state (e.g., by selection of a "blocking" mode). One of ordinary skill in the art will understand that the present disclosure can provide corresponding, analogous, or similar types of GUIs directed to the configuration of one or more simulation parameters and/or particular program instruction modules.

Aspects of Representative Add-On Block GUIs

A block within the add-on device blockset 530 can include or be associated with program instructions configured to generate one or more user interfaces corresponding to the block to facilitate or enable simulation operations involving the block's corresponding add-on device. More particularly, a block within the add-on device blockset 530 can include program instructions that generate or manage a user interface configured to receive user input that defines or specifies a manner in which signals or data associated with the add-on device can be output in accordance with a visual format or appearance corresponding to or representative of the add-on device. Additionally or alternatively, a block within the add-on device blockset 530 can include program instructions that generate or manage a user interface by which addon device parameters, signals, or signal formats can be selected or specified.

FIG. 15A is an illustration of a representative LED appearance configuration GUI 1500 according to an embodiment of the disclosure. In an embodiment, the LED appearance configuration GUI 1500 includes a set of graphical controls 1502 that enables user selection of a pixel off color (e.g., black) and a pixel on color (e.g., red) for the segments of a multi- segment LED The LED appearance configuration GUI 1500 additionally includes a graphical mapping 1504 that visually specifies an association between individual LED segments and an LED input signal format.

FIG. 15B is an illustration of a representative LED array simulation interface 1520 according to an embodiment of the disclosure. In an embodiment, the LED array simulation interface 1520 includes a first multi-segment LED 1522 and a second multi-segment LED 1524, each of which can be configured to activate or illuminate particular LED segments in accordance with an LED input signal format, and a pixel off color and a pixel on color specified by way of an LED appearance configuration GUI 1500. FIG. 16A is an illustration of a representative LCD appearance configuration GUI 1600 according to an embodiment of the disclosure. The LCD appearance configuration GUI 1600 includes one or more sets of graphical controls 1602, 1604 responsive to user input for configuring an LCD module's simulated visual appearance. In an embodiment, a first set of graphical controls 1602 can include list boxes, drop down menus, or other controls (e.g., radio buttons) configured to select an LCD background color, a pixel on color, and a pixel off color in response to user input. A second set of graphical controls 1604 can include graphical controls configured to select a character pixel size, a character border size, an inter-pixel spacing, a horizontal character spacing, and a vertical character spacing in response to user input.

FIG. 16B is an illustration of a representative LCD parameter definition GUI 1620 according to an embodiment of the disclosure. In an embodiment, the LCD parameter definition GUI 1620 includes a parameter selection interface 1622 having number of graphical controls (e.g., list boxes or drop down menus) responsive to user input for selection of an LCD module type, an LCD supply voltage level, an LCD interface type (e.g., 4 bits), a number of output lines or rows (e.g., 1 - 3), a number of characters per output line, a control pin port, a control pin sequence definition, and a data pin port, a data pin sequence definition. The LCD parameter definition GUI 1620 further includes a module summary box 1624 that identifies a selected type of LCD module and a corresponding set of commands to which the selected LCD module is responsive.

FIG. 16C is an illustration of a representative LCD output format GUI 1630 according to an embodiment of the disclosure. In an embodiment, the LCD output format GUI 1630 includes a first text box 1632 responsive to user input for defining a displayed data format, and a second text box 1634 responsive to user input for defining a buffer size.

FIG. 16D is an illustration of a representative LCD module simulation 1650 defined within a simulation environment window 412 according to an embodiment of the disclosure. The LCD module simulation 1650 includes a graphical LCD block 1660 and a simulated LCD display window 1662 corresponding to a target-side LCD add-on device or module for which a simulated visual appearance, an LCD module type and corresponding control parameters, and a data display format have been configured in accordance with the representative user interfaces of FIGs. 16A - 16C. During simulation operations, data input to the LCD block 1660 by way of a buffer block 1664 is presented by the simulated LCD display window 1662 in accordance with an output format established by way of the LCD output format GUI 1630 of FIG. 16C. While features, aspects, and/or advantages associated with certain embodiments have been described in the disclosure, other embodiments may also exhibit such features, aspects, and/or advantages, and not all embodiments need necessarily exhibit such features, aspects, and/or advantages to fall within the scope of the disclosure. It will be appreciated by a person of ordinary skill in the art that several of the above-disclosed systems, components, processes, or alternatives thereof, may be desirably combined into other different systems, components, processes, and/or applications. In addition, various modifications, alterations, and/or improvements may be made to various embodiments that are disclosed by a person of ordinary skill in the art within the scope and spirit of the present disclosure.

Claims

1. An embedded system development and simulation method implemented by way of a host system that includes an embedded system development environment configured for embedded system simulation operations involving a target system, the method comprising: providing a recurrent target - host communication loop by which communication corresponding to information transfer between the target system and the host system occurs during embedded system simulation operations, the recurrent target - host communication loop comprising:

a target communication loop corresponding to the target system, the target communication loop including a target transmitter process, wherein the target communication loop recurrently operates; and

a host communication loop corresponding to the host system, the host communication loop including a host receiver process, wherein the host communication loop recurrently operates,

wherein the target communication loop provides timing control for synchronizing the host communication loop with the target communication loop during embedded system simulation operations;

providing a simulation model corresponding to the embedded system, the simulation model comprising a set of graphical blocks that includes at least one block corresponding to a target system add-on device configured for at least one of user input operations, visual interface output operations, sensing operations, and actuation operations;

performing embedded system simulation operations corresponding to the simulation model, the embedded system simulation operations comprising the execution of a target simulation process and the execution of a host simulation process, the target simulation process and the host simulation process configured to communicate by way of the recurrent target - host communication cycle, the embedded system simulation operations comprising:

initiating execution of the target communication loop;

initiating execution of the host communication loop in response to execution of the target communication loop;

generating signals corresponding to the target system add-on device; and transferring data corresponding to the generated signals between the target simulation process and the host simulation process by way of the recurrent target - host communication loop.

2. The method of claim 1, wherein the target transmitter process provides timing control for synchronizing the host communication loop with the target communication loop by successively outputting packets at predetermined time intervals.

3. The method of claim 2, wherein the target transmitter process avoids outputting packets at times other than the predetermined time intervals.

4. The method of claim 2, wherein the target communication loop comprises a target-side wait state, the method further comprising maintaining the target communication loop in the target-side wait state until a next predetermined time interval is reached.

5. The method of claim 2, wherein the host communication loop comprises a host-side wait state, the method further comprising maintaining the host communication loop in the host-side wait state until the host receiver process receives a packet output by the target transmitter process.

6. The method of claim 1, wherein the target communication loop further includes a target receiver process and the host communication loop further includes a host transmitter process, the method further comprising executing the target communication loop and the host communication loop in a sequenced manner comprising:

executing the target communication loop in response to one from the group of execution of the host communication loop and receipt of a dummy packet generated in response to user input; and

executing the host communication loop in response to execution of the target communication loop.

7. The method of claim 6, wherein the target simulation process and the host simulation process are configured in accordance with an open loop configuration and communication between the target simulation process and the host simulation process occurs by way of data packet transfer from the host transmitter process to the target receiver process and dummy packet transfer from the target transmitter process to the host receiver process.

8. The method of claim 7, wherein synchronization between the target communication loop and the host communication loop occurs by way of dummy packet reception by the host receiver process.

9. The method of claim 6, wherein the target simulation process and the host simulation process are configured in accordance with a closed loop configuration and communication between the target simulation process and the host simulation process occurs by way of data packet transfer from the target transmitter process to the host receiver process and data packet transfer from the host transmitter process to the target receiver process.

10. The method of claim 9, wherein synchronization of the host communication loop with the target communication loop occurs by way of data packet reception by the host receiver process and synchronization of the target communication loop with the host communication loop occurs by way of data packet reception by the target receiver process.

11. The method of claim 9, wherein initiating execution of the target communication loop occurs in response to the target reception process receiving a dummy packet generated in response to user input.

12. The method of claim 1, further comprising providing a graphical configuration interface corresponding to the target system add-on device, the graphical configuration interface responsive to user input for establishing operating parameters corresponding to the target system add-on device.

13. The method of claim 12, wherein the graphical configuration interface comprises selectively executable program instructions associated with the graphical block corresponding to the target system add-on device.

14. The method of claim 1, further comprising providing a graphical simulation interface corresponding to the target system add-on device, the graphical simulation interface configured to provide a visual simulation of target system add-on device operation during embedded system simulation operations.

15. The method of claim 14, wherein the graphical simulation interface comprises program instructions associated with the graphical block corresponding to the target system add-on device.

16. An embedded system development and simulation architecture comprising:

a target system comprising:

a target-side processing unit; and

a set of target-side communication modules including a target transmission module configured to operate in accordance with a recurrent target-side communication loop; and

a host system comprising:

a host-side processing unit;

a graphical embedded system development and simulation environment providing a set of graphical blocks, at least one graphical block corresponding to a target system add-on device configured for at least one of user input operations, visual interface output operations, sensing operations, and actuation operations; and

a set of host-side communication modules including a host reception module configured to operate in accordance with a recurrent host-side communication loop that is initiated in response to target system execution of the target-side communication loop,

wherein data transfer between the target system and the host system corresponding to the target system add-on device occurs by way of at least one of the recurrent target-side communication loop and the recurrent host-side communication loop.

17. The system of claim 16, wherein the target-side communication loop and the host-side communication loop are configured for synchronous operation based upon packet transfer between the target system and the host system.

18. The system of claim 16, wherein the set of target-side communication modules includes a target reception module configured to operate with the target transmission module in accordance with the target-side communication loop, and the set of host-side communication modules includes a host transmission module configured to operate with the host reception module in accordance with the host-side communication loop.

19. The system of claim 18, wherein the target system and the host system exist in an open loop configuration that provides data packet transfer from the host system to the target system and dummy packet transfer from the target system to the host system.

20. The system of claim 19, wherein data packet reception by the target system controls a cyclical operation of the recurrent target-side communication loop and dummy packet reception by the host system controls a cyclical operation of the recurrent host-side communication loop.

21. The system of claim 20, wherein the target system and the host system exist in a closed loop configuration that provides data packet transfer from the target system to the host system and data packet transfer from the host system to the target system.

22. The system of claim 21, wherein data packet reception by the host system controls a cyclical operation of the recurrent host-side communication loop and data packet reception by the target system controls a cyclical operation of the recurrent target-side communication loop.

23. The system of claim 22, wherein the set of host-side communication modules further comprises a trigger module configured to transmit a dummy packet to the target system in response to user input.

24. The system of claim 16, wherein the graphical embedded system development and simulation environment provides a graphical block corresponding to the trigger module.

25. The system of claim 16, wherein the graphical embedded system development and simulation environment provides a graphical configuration interface corresponding to the target system add-on device, the graphical configuration interface responsive to user input for establishing operating parameters corresponding to the target system add-on device.

26. The system of claim 16, wherein the graphical embedded system development and simulation environment provides a graphical simulation interface corresponding to the target system add-on device, the graphical simulation interface configured to provide a visual simulation of target system add-on device operation on the host system during embedded system simulation operations.

27. An embedded system development and simulation method implemented by way of a host system coupled to a target system, the host system providing a graphical embedded system development and simulation environment, the target system comprising an embedded processing unit, a selection interface coupled to the embedded processing unit and configured to receive user input, and a target system memory coupled to the embedded processing unit, the target system memory comprising a modular program memory configured to store a plurality of modular programs, each modular program comprising program instructions corresponding to an embedded application, the target system memory further comprising a bootloader configured to selectively initiate the execution of a modular program stored within the modular program memory in response to user input provided to the selection interface, the embedded system development and simulation method comprising:

performing a target system bootload process that identifies in response to user input provided to the selection interface a particular modular program within a plurality of modular programs stored in the modular program memory;

initiating execution of the particular modular program;

establishing a recurrent a recurrent target - host commumcation loop by which communication between the target system and the host system occurs during embedded system simulation operations, the recurrent target - host communication loop comprising: a target communication loop corresponding to the target system, the target communication loop including a target transmitter process, wherein the target communication loop recurrently operates; and

wherein the target communication loop provides timing control for synchronizing the host communication loop with the target communication loop during embedded system simulation operations; executing the target communication loop;

executing the host communication loop in response to execution of the target communication loop; and

transferring data corresponding to embedded system simulation operations between the target system and the host system by way of the recurrent target - host communication loop.

28. The method of claim 27, wherein performing the target system bootload process comprises:

determining a selection signal value corresponding to user input provided to the selection interface;

mapping the selection signal value to a unique starting address of a modular program stored within the modular program memory to thereby identify the particular modular program; and

transferring target system execution control to a program instruction corresponding to the starting address of the particular modular program.

29. The method of claim 27, wherein modular programs are stored in the modular program memory at uniformly separated starting addresses.

30. The method of claim 27, wherein at least some modular programs are stored in the modular program memory non-uniformly separated starting addresses.

31. The method of claim 27, further comprising storing a plurality of modular programs in the modular program addresses in accordance with a plurality of user defined modular program memory addresses.

32. The method of claim 27, wherein mapping the selection signal value to a unique starting address of a modular program comprises accessing a configuration table that defines an association between a plurality of unique selection signal values corresponding to user input providable to the selection interface and a plurality of unique program instruction addresses to which target system execution is transferable in response to user input provided to the selection interface.

33. The method of claim 27, wherein the modular program memory comprises a factory program memory and a user program memory, the factory program memory storing at least one predetermined modular program and the user program memory storing at least one user program, each user program comprising one of a user defined modular program and a user customized modular program, and wherein mapping the selection signal value to a unique starting address of a modular program comprises selectively determining one of a starting address of a factory program and a starting address of a user program based upon user input provided to the selection interface.

34. The method of claim 33, wherein selectively determining a starting address of a factory program or a starting address of a user program comprises:

accessing a configuration table that defines a plurality of address associations comprising: a first set of associations between a first set of unique selection signal values corresponding to user input providable to the selection interface and a set of unique program instruction addresses corresponding to factory programs; and a second set of associations between a second set of unique selection signal values corresponding to user input providable to the selection interface and a set of unique program instruction addresses corresponding to user programs.

35. The method of claim 27, wherein the target transmitter process provides timing control for synchronizing the host communication loop with the target communication loop by successively outputting packets at predetermined time intervals.

36. The method of claim 35, wherein the target transmitter process avoids outputting packets at times other than the predetermined time intervals.

37. The method of claim 35, wherein the target communication loop comprises a target- side wait state, the method further comprising maintaining the target communication loop in the target-side wait state until a next predetermined time interval is reached.

38. The method of claim 35, wherein the host communication loop comprises a host-side wait state, the method further comprising maintaining the host communication loop in the host-side wait state until the host receiver process receives a packet output by the target transmitter process.

39. The method of claim 27, wherein the target communication loop further includes a target receiver process and the host communication loop further includes a host transmitter process, the method further comprising executing the target communication loop and the host communication loop in a sequenced manner comprising:

40. The method of claim 39, wherein the target system and the host system are configured in accordance with an open loop configuration and communication between the target system and the host system occurs by way of data packet transfer from the host transmitter process to the target receiver process and dummy packet transfer from the target transmitter process to the host receiver process.

41. The method of claim 39, wherein synchronization between the target communication loop and the host communication loop occurs by way of dummy packet reception by the host receiver process.

42. The method of claim 39, wherein the target system and the host system are configured in accordance with a closed loop configuration and communication between the target system and the host system occurs by way of data packet transfer from the target transmitter process to the host receiver process and data packet transfer from the host transmitter process to the target receiver process.

43. The method of claim 42, wherein synchronization of the host communication loop with the target communication loop occurs by way of data packet reception by the host receiver process and synchronization of the target communication loop with the host communication loop occurs by way of data packet reception by the target receiver process.

44. The method of claim 42, wherein initiating execution of the target communication loop occurs in response to the target receiver process receiving a dummy packet generated in response to user input.

45. An embedded system development and simulation architecture comprising:

a target system comprising:

a target-side processing unit;

a selection interface coupled to the target-side processing unit and configured to receive user input; and

a target system memory comprising:

a modular program memory storing a plurality of modular programs, each modular program comprising program instructions executable by the processing unit to implement an embedded application;

a bootloader configured to selectively initiate the execution of a particular modular program stored within the memory in response to user input provided to the selection interface; and

a host system comprising:

a host-side processing unit; and

a set of host-side communication modules including a host reception module configured to operate in accordance with a recurrent host-side communication loop that is initiated in response to target system execution of the target-side communication loop.

46. The system of claim 45, wherein the bootloader is configured to determine as part of a target system bootload process a selected execution address in response to a signal output by the selection interface, the selected execution address corresponding to a starting address of a particular modular program stored within the modular program memory.

47. The system of claim 46, wherein the bootloader is further configured to transfer target system execution control to a program instruction stored at the starting address of the particular modular program.

48. The system of claim 45, wherein the modular program memory comprises a factory program memory that stores at least one predetermined modular program and a user program memory that stores at least one of a user defined modular program and a user customized modular program.

49. The system of claim 48, wherein factory programs are stored in the factory program memory at uniformly separated starting addresses.

50. The system of claim 49, wherein at least some user programs are stored in the user program memory at non-uniformly separated starting addresses.

51. The system of claim 45, wherein the target system memory further comprises a configuration table that defines an association between a plurality of unique selection signal values corresponding to user input receivable by way of the selection interface and a plurality of unique program instruction addresses to which the bootloader can transfer target system execution.

52. The system of claim 51, wherein the configuration table defines a plurality of address associations comprising:

a first set of associations between a first set of unique selection signal values corresponding to user input providable to the selection interface and a set of unique program instruction addresses corresponding to factory programs; and

a second set of associations between a second set of unique selection signal values corresponding to user input providable to the selection interface and a set of unique program instruction addresses corresponding to user programs.

53. The system of claim 45, wherein the selection interface comprises at least one of a set of jumpers, a set of switches, a set of touch sensitive elements, and a set of visual feedback elements.

54. The system of claim 45, wherein the target-side processing unit, the selection interface, and at least a portion of the target system memory are carried by a common support structure.

55. The system of claim 45, wherein the target transmission module provides timing control for synchronizing the host communication loop with the target communication loop by successively outputting packets at predetermined time intervals.

56. The system of claim 45, wherein synchronization between the target communication loop and the host communication loop occurs by way of dummy packet reception by the host reception module.

57. The system of claim 45, wherein the set of target-side communication modules further includes a target reception module and the set of host-side communication modules further includes a host transmission module, and wherein the target system and the host system are configured in accordance with an open loop configuration and communication between the target system and the host system occurs by way of data packet transfer from the host transmission module to the target reception module and dummy packet transfer from the target transmission module to the host reception module.

58. The system of claim 45, wherein the set of target-side communication modules further includes a target reception module and the set of host-side communication modules further includes a host transmission module, and wherein the target system and the host system are configured in accordance with a closed loop configuration and communication between the target system and the host system occurs by way of data packet transfer from the target transmission module to the host reception module and data packet transfer from the host transmission module to the target reception module.

59. The system of claim 58, wherein synchronization of the host communication loop with the target communication loop occurs by way of data packet reception by the host reception module and synchronization of the target communication loop with the host communication loop occurs by way of data packet reception by the target reception module.

60. The system of claim 59, wherein the set of host-side communication modules includes a trigger module configured to transmit a dummy packet to the target reception in response to user input.