LonTalk® Stack Developer's Guide 078-0483-01A
Echelon, LONWORKS, LONMARK, NodeBuilder, LonTalk, Neuron, 3120, 3150, LNS, ShortStack, and the Echelon logo are trademarks of Echelon Corporation registered in the United States and other countries. OpenLDV and LonScanner are trademarks of Echelon Corporation. Other brand and product names are trademarks or registered trademarks of their respective holders.
Table of Contents Welcome ......................................................................................................... ix Audience ........................................................................................................ ix Related Documentation ................................................................................ ix 1 Introduction to LonTalk Stack ............................................................... 1 Overview ..............................................
Serial MIP Driver Example......................................................................... 47 Serial MIP Driver API ................................................................................. 47 Structures .............................................................................................. 47 Functions................................................................................................ 48 iv 6 Creating a Model File .......................................................
Specifying Code Generator Preferences ............................................... 91 Compiling and Generating the Files .................................................... 92 Using the LonTalk Interface Developer Files ............................................ 93 Copied Files............................................................................................ 94 LonNvTypes.h and LonCpTypes.h ....................................................... 94 FtxlDev.h..................................
LtLogicalChannel ................................................................................ 134 LtIp852Router ..................................................................................... 134 10 Porting a LonTalk Stack Application .........................................137 Porting Overview ....................................................................................... 138 OSAL ....................................................................................................
LonTalk API Functions ....................................................................... 180 Commonly Used LonTalk API Functions .................................... 181 Other LonTalk API Functions...................................................... 181 Application Messaging API Functions ........................................ 182 Non-Volatile Data API Functions ................................................ 182 Extended API Functions...............................................................
Model File............................................................................................. 214 Extending the SimpleLtDevice and SimpleIp852 Examples............ 214 IP-852 Router Example Application Details ............................................ 215 Appendix H LonTalk Interface Developer Utility Error and Warning Messages.........................................................................................219 Introduction.................................................................
Welcome Echelon’s LonTalk® Stack enables you to add a high-performance ISO/IEC 14908-1 control networking interface to any product that contains a microprocessor, microcontroller, or embedded processor. The LonTalk Stack includes a simple host application programming interface (API), a complete ISO/IEC 14908-1 protocol stack implementation, a link-layer driver, a simple hardware interface, and comprehensive tool support.
• LONMARK® Application Layer Interoperability Guidelines. This manual describes design guidelines for developing applications for open interoperable LONWORKS devices, and is available from the LONMARK Web site, www.lonmark.org. • FT 3120 / FT 3150 Echelon Smart Transceiver Data Book. This manual provides detailed technical specifications on the electrical interfaces, mechanical interfaces, and operating environment characteristics for the FT 3120 and FT 3150® Echelon Smart Transceivers.
LonTalk Stack Developer’s Guide xi
1 Introduction to LonTalk Stack This chapter introduces LonTalk Stack for embedded processors. It describes the architecture of a LonTalk Stack device, including a comparison with other LONWORKS device development solutions. It also describes attributes of a LonTalk Stack device, and the requirements and restrictions of the LonTalk Stack.
Overview Automation solutions for buildings, homes, utility, transportation, and industrial applications include sensors, actuators, and control systems. A LONWORKS network is a peer-to-peer network that uses an international-standard control network protocol for monitoring sensors, controlling actuators, communicating with devices, and managing network operation. In short, a LONWORKS network provides communications and complete access to control network data from any device in the network.
600 IP-852 Routers, and the LonTalk Stack. This document refers to the ISO/IEC 14908-1 Control Network Protocol as the LonTalk protocol, although other interoperable implementations exist. A LONWORKS Device with a Single Processor Chip A basic LONWORKS device consists of four primary components: 1. An application processor that implements the application layer, or both the application and presentation layers, of the LonTalk protocol. 2.
A LONWORKS device that uses a single processor chip is called a Neuron-hosted device, which means that the Neuron-based processor (the Echelon Smart Transceiver) runs both the application and the LonTalk protocol. For a Neuron-hosted device that uses a Neuron Chip or Echelon Smart Transceiver, the physical layer (layer 1) is handled by the Neuron Chip or Echelon Smart Transceiver. The middle layers (layers 2 through 6) are handled by the Neuron firmware.
A ShortStack Micro Server is an Echelon Smart Transceiver or Neuron Chip with ShortStack firmware that implements layers 2 to 5 (and part of layer 6) of the LonTalk protocol. The host processor implements the application layer (layer 7) and part of the presentation layer (layer 6). The Echelon Smart Transceiver or Neuron Chip provides the physical interface for the LONWORKS communications channel. The ShortStack firmware allows you to use almost any host processor for your device’s application and I/O.
API, which is an ANSI C API, to manage communications with the ShortStack Micro Server and devices on the LONWORKS network. LonTalk Stack Developer’s Kit The LonTalk Stack Developer’s Kit is a set of development tools, APIs, and firmware for developing host-based LONWORKS devices that use the Echelon Smart Transceiver or Neuron Chip, a Layer 2 Microprocessor Interface Program (MIP), and the LonTalk API.
develop your application using the Echelon LonTalk API to manage communications between the LonTalk Host stack, Echelon Smart Transceiver or Neuron Chip, and other LONWORKS devices on the network. The LonTalk Stack includes an example communications interface driver for the serial link layer that manages communications between the LonTalk Host stack within the host processor and the Echelon Smart Transceiver or Neuron Chip with Layer 2 MIP.
File access methods supported FTP [4] , DMF FTP [4], DMF FTP [4], DMF [5] Link-layer type N/A 4- or 5-line SCI or 6- or 7-line SPI 2-line SCI Typical host API runtime footprint N/A 5-6 KB code with 1 KB RAM (includes serial driver, but does not include optional API or ISI API) Native LonTalk protocol stack. 850 KB Includes LonTalk API, Linux Serial MIP driver, and the SimpleDevice example application. IP-852 LonTalk protocol stack.
Notes: 1. ShortStack Micro Servers running on FT 3150 or PL 3150 Echelon Smart Transceivers support up to 254 network variables. ShortStack Micro Servers running on FT 3120 Echelon Smart Transceivers support up to 240 network variables, and ShortStack Micro Servers running on PL 3120 Echelon Smart Transceivers support up to 62 network variables. A custom Micro Server can support up to 254 network variables, depending on available resources. 2.
Development Tools for LonTalk Stack To develop an application for a device that uses the LonTalk Stack, you need a development system for the host processor.
The LonTalk Stack includes source code for the LonTalk API and the LonTalk host stack. The kit also includes source code for additional operating system and hardware APIs that you compile and link with your application. The LonTalk API defines the functions that your application calls to communicate with other devices on a LONWORKS network. The API code provides ANSI C interfaces for the host application.
Overview of the LonTalk Stack Development Process The development process for a LonTalk Stack application includes the following steps: 1. Load the Neuron firmware and the Layer 2 MIP on the Echelon Smart Transceiver or Neuron Chip. 2. Create the serial I/O hardware interface between your host processor and the Echelon Smart Transceiver or Neuron Chip. 3.
This manual describes the software development process for creating a LonTalk Stack device, which includes the general tasks listed in the following table. Task Additional Considerations Reference Install the LonTalk Developer’s Kit and become familiar with it Chapter 2, Getting Started with the LonTalk Stack Developer’s Kit Load an application image file with the Neuron firmware and Layer 2 MIP onto an Echelon Smart Transceiver or Neuron Chip.
Task Additional Considerations Develop a LonTalk Stack serial driver for your host processor that manages the handshaking and data transfers between the host processor and the Echelon Smart Transceiver or Neuron Chip. Chapter 5, Creating a LonTalk Stack Serial Driver Select a microprocessor, microcontroller, or embedded processor. The LonTalk Stack application runs on any microprocessor, microcontroller, or embedded processor.
Task Additional Considerations Reference Structure the layout and interoperable interface of your LonTalk Stack device by creating a model file You must define the interoperable interface for your device in a model file, using the Neuron C (Version 2.1) language, for every application that you implement.
Task Additional Considerations Reference Modify your application to interface with a LONWORKS network by using the LonTalk API function calls You must make these function calls for every application that you implement. These calls include, for example, calls to the LonPropagateNv() function that propagates an updated network variable value to the network. Together with the completion of the event and callback handler functions, this task forms the core of your networked device’s control algorithm.
LonTalk Stack Developer’s Guide 17
2 Getting Started with the LonTalk Stack Developer’s Kit This chapter describes the LonTalk Stack and how to install it.
LonTalk Stack Overview The LonTalk Stack Developer’s Kit contains the source code, firmware, and documentation required to add a high-performance ISO/IEC 14908-1 control networking interface to any smart device.
• Microsoft® Windows® XP, plus Service Pack 3 or later. Installing the LonTalk Stack Developer’s Kit To install the LonTalk Stack Developer’s Kit, perform the following steps: 1. Download and install the LonTalkStack200.exe file from the Echelon Web site. 2. Follow the installation dialogs to install the LonTalk Stack Developer’s Kit onto your computer.
modify and link with your application. This framework contains most of the code that is needed for initialization and other required processing. The executable for the LonTalk Interface Developer utility is named LID.exe, and is installed in the LonTalk Interface Developer directory (usually, C:\LonWorks\InterfaceDeveloper). The LonTalk Interface Developer utility also includes a command-line interface that allows make-file and script-driven use of the utility.
See Appendix G, Example LonTalk Stack Applications, for more information about these examples.
24 Getting Started with the LonTalk Stack Developer’s Kit
3 Loading the Echelon Smart Transceiver or Neuron Chip This chapter describes how to load an application image with the Neuron firmware and Layer 2 MIP onto an Echelon Smart Transceiver or Neuron Chip.
Loading Overview To create a LonTalk Stack device, you first need to load an Echelon Smart Transceiver or Neuron Chip with an application image file. The application image contains Neuron firmware that implements the data link layer of the LonTalk protocol (layer 2), and a Layer 2 MIP that enables the Echelon Smart Transceiver or Neuron Chip to transmit and receive any packet to and from the host processor.
The following table lists the Neuron processor and memory combinations, and it lists the application image files and tools that you use to program each onto an Echelon Smart Transceiver or Neuron Chip Echelon Smart Transceiver Memory Type Image File Extension Programming Tool Neuron 3120E4 Chip On-chip EEPROM APB, NDL, or NEI Network management tool NodeLoad utility NFI PROM programmer A universal programmer, such as one from BPM Microsystems or HiLo Systems APB or NDL Network management tool
Notes: • If you load an NDL file with the NodeLoad Utility, the last step of the process may generate errors when the final network management status checks are performed. • To prevent link errors, you need to copy an updated symbol file to the appropriate Neuron firmware folder on your development computer, and then specify them as custom system images in the Hardware Template Editor. This file has additional symbols for low-level serial interrupt modifications, and access to the network buffer queues.
Destination Folder on Development Computer Updated Symbol File Source/Target/Neuron/L2ML IB/ Ver14/sys3150l2mlib.sym C:/LonWorks/Images/Ver14 Source/Target/Neuron/L2ML IB/ Ver14/sys3150l2mlib.nx C:/LonWorks/Images/Ver14 Defining Incoming Layer 2 Packet Buffers You can define incoming Layer 2 packet buffers using the following syntax: [length] [miCOMM|miINCOMINGL2] [backlog/altpath] NPDU [CRC_HI] [CRC_LO] The length field includes the 2 bytes before the NPDU, the NPDU itself, and the two CRC bytes.
Function Syntax Description l2ml_freel2packet() extern system far void l2ml_freel2packet(unsigne d *mp); Frees any packet buffers returned by l2ml_getl2packet() method. This method does not check for NULL pointers. You can only free packet buffers after processing. l2ml_allocl2buffer() extern system far unsigned *l2ml_allocl2buffer(void) ; Allocates a L2 packet buffer for transmitting. This method returns NULL if there are no L2 packet buffers available.
4 Designing the Serial I/O Hardware Interface This chapter describes what you need to design the serial I/O hardware interface between your host processor and the Echelon Smart Transceiver or Neuron Chip for devices that use the Serial MIP.
Overview of the Hardware Interface This chapter describes the hardware interface, including the requirement for pull-up resistors, selecting a minimum communications interface bit rate, considerations for host latency, specifying the SCI interface, and how to perform an initial health check of the Echelon Smart Transceiver. Reliability The LonTalk Stack link layer protocol assumes a reliable serial link and does not include error detection or error recovery.
The RESET~ Pin The Echelon Smart Transceiver and Neuron Chip have no special requirements for the RESET~ (or RST~) pin. See the FT 3120 / FT 3150 Echelon Smart Transceiver Data Book, the PL 3120 / PL 3150 / PL 3170 Power Line Echelon Smart Transceiver Data Book, or the Series 5000 Chip Data Book for information about the requirements for this pin.
higher voltage drop (typically, 0.7 V), that is, the Schottky diode ensures that the voltage drop is low enough to ensure a logic-low signal. Host-driven reset of the Echelon Smart Transceiver or Neuron Chip should only be an emergency means to recover from some serious error. In addition, the host application or serial driver should always log the reason or cause for the reset, along with timestamp information.
• o sizeof(network_variable) o sizeof(message_length) BPTInterface represents data transfer overhead for the serial interface, and has one of the following values: • o 1 bit per transfer for SPI o 10 bits per transfer for SCI PPS exp is the expected packet-per-second throughput value Example: For an average network variable size of 3 bytes, no explicit messaging support, and a TP/FT-10 channel that delivers up to 180 packets per second, the minimum bit rate for an SCI interface is 19 200 bps.
Host Latency Considerations The processing time required by the host processor for an Echelon Smart Transceiver or Neuron Chip can have a significant impact on link-layer transit time for network communications and on the total duration of network transactions. This impact is the host latency for the LonTalk Stack application. To maintain consistent network throughput, a host processor must complete each transaction as quickly as possible.
• 8 data bits (least-significant bit first) • 1 stop bit The SCI link-layer interface uses two serial data lines: RXD (receive data) and TXD (transmit data). The following diagram summarizes the two serial data lines and their I/O pin assignments. The signal directions are from the point of view of the Echelon Smart Transceiver. An uplink transaction describes data exchange from the Echelon Smart Transceiver to the host processor, and uses the TXD line.
VDD 9 x 10 kΩ Echelon Smart Transceiver PL 3120 FT 5000 TXD RXD RESET~ Your hardware design should include a switch that connects the RESET~ pin to ground; you press this switch to reset the Echelon Smart Transceiver or Neuron Chip. When you press the reset switch for a LonTalk Stack device, the Neuron firmware performs reset processing, as described in the data books for the Echelon Smart Transceiver and Neuron Chips.
5 Creating a LonTalk Stack Serial MIP Driver This chapter describes the link-layer protocol (LLP) and how to develop a LonTalk Stack Serial MIP driver for your host processor. This driver manages the handshaking and data transfers between the host and the Echelon Smart Transceiver or Neuron Chip. The driver also manages the buffers in the host for communication with the Echelon Smart Transceiver or Neuron Chip.
Overview of the Link Layer Protocol The LonTalk Serial MIP driver communicates with the host processor over the built-in SCI serial interface hardware of the FT 5000 Echelon Smart Transceiver, Series 5000 chip, and the PL 3120 Echelon Smart Transceiver. The Serial MIP driver uses the Serial MIP link-layer protocol (LLP), which is a two-signal serial protocol with no extra requirements for handshake signals.
The packet sum is an 8-bit value that, when added to the first three bytes, results in an 8-bit zero result. The code packet hast the following features: • Asynchronous method of presenting itself at any time (by using an escape sequence). • Checksum verification. • Data transfer initiation. • Duplication detection using a sequence number. Duplicates may be sent when an expected response is lost or broken and does not occur within a time-out period.
Type Code Values The following table lists the values for the Type Code byte. Uplink means that data is transferred from the Echelon Smart Transceiver or Neuron Chip to the host processor. Downlink mans that data is transferred from the host processor to the Echelon Smart Transceiver or Neuron Chip. Value Type Description Uplink / Downlink 0 CpNull No data is being sent. Use this value for acknowledge-only packets, or for pinging. U/D 1 CpFail The previous transfer was broken or in error.
Value Type Description Uplink / Downlink 4 CpMsgAck The Serial MIP is entering the ready-receive state. This is the Serial MIP’s response to the CpMsgReq. U 5 CpMsgReject An attempt to transfer a message downlink is rejected because of a lack of buffer space. U This code packet will be a response to a downlink CpMsgReq code packet or a response to a CpMsg without the CpMsgReq being sent.
• All length fields do not count for escape prefixes. Instead, they reflect the length of the real data stream above the link-layer protocol. All length fields do not account for the checksum. • Broken code packets (code packets with missing or corrupt bytes) are not responded to at all, and they rely on time-out mechanisms for re-transmission. • Broken message streams are responded to as soon as the error condition is observed. The response is the CpFail code packet.
Sequence Number Cycling and Duplicate Detection The sequence number is used to reject duplicate non-LLP data. Duplicate LLP data does not effect the LLP; therefore, the sequence number is only cycled for each transfer of non-LLP data. For example, two consecutive CpMsgReq packets have no effect—the second CpMsgReq packet reinstates the ready-receive state and the CpMsgAck is re-sent. Supported MIP Command Set The following table lists the MIP commands you can use in your LonTalk Stack Serial MIP driver.
Value Name Description Uplink / Downlink 0x90 niFLUSH Sets the MIP to the “flush” state. D 0xA0 niFLUSH_IGNORE Sets the MIP to the “flush ignore comm” state. D 0xCx niIO_SET Directly controls the MIP’s four I/O pins, IO0 – IO3, for general purpose I/O control from the Neuron. The L.S. 4 bits are used to control these pins. D 0xD0 niMODE_L5 Sets the MIP to Layer 5 mode. If already in this mode the MIP will reply with this command. Otherwise the MIP will reset and resume in the new mode.
Product Query Network Management The Serial MIP supports the Product Query network management command from the host only. The code for this command is the Network Management Escape code [0x7D] followed by the sub-command and command values of [0x01], [0x01]. The response includes PRODUCT and MODEL values based on whether the MIP is currently in L2 or L5 mode. The App Version is 3.1 (31); the TXID is defined when the Serial MIP image is built, and is 4 for a TP/FT-10 channel.
Structure Description sensed. UlDiscarded. Number of tossed uplinks. Functions Function Syntax Description SciMipOpen LdvRetVal SciMipOpen( WORD iComPort, DWORD baudrate, HANDLE hNotifier); Opens the serial interface driver. iComPort. The index to the serial port. baudrate. The serial port baud rate, hNotifier. A handle to an event that will be set by the driver whenever received messages are available. The driver never closes this handle.
Function Syntax Description SciMipRead LdvRetVal SciMipRead ( LDV_Message *pMsg, int size); De-queues one uplink message or local network interface command if there is one available. size. Indicates the size of the structure of pMsg. This function returns one of the following vlaues: LDV_OK. Successful. LDV_NO_MSG_AVAIL. No messages are available. LDV_NOT_OPEN. The driver is not open LDV_INVALID_BUF_LEN The value of size is too small for the message.
Function Syntax Description SciMipStatistics LdvRetVal SciMipStatistics( LLPStats *pLlps, int size, BOOL bIfClear); Returns a structure containing device driver statistics. Set the size argument to sizeof(LLPStats). To clear the internal statistics, set bIfClear to TRUE. SciMipSetMode LdvRetVal SciMipSetMode( LLPMode mode); This Serial MIP driver supports a mode where downlink messages are transmitted without the normal CpMsgReq request. This mode works under controlled downlink traffic conditions.
6 Creating a Model File You use a model file to define your device’s interoperable interface, including its network inputs and outputs. The LonTalk Interface Developer utility converts the information in the model file into device interface data and a device interface file for your application. This chapter describes how to create a model file using the Neuron C programming language. Syntax for the Neuron C statements in the model file is described in Appendix C, Neuron C Syntax for the Model File.
Model File Overview The interoperable application interface of a LONWORKS device consists of its functional blocks, network variables, configuration properties, and their relationships. The network variables are the device’s means of sending and receiving data using interoperable data types. The configuration properties are the device’s means of providing externally exposed configuration data, again using interoperable data types.
file. NodeBuilder software is not included with the LonTalk Stack, and must be licensed separately. See the NodeBuilder FX User’s Guide for details about using the NodeBuilder Code Wizard. See Appendix C, Neuron C Syntax for the Model File, for the detailed Neuron C syntax for each type of statement that can be included in the model file. Defining the Device Interface You use a model file to define the device interface for your device.
Example: The following declaration defines an input network variable of type “SNVT_type” with the name “nviAmpere”. network input SNVT_amp nviAmpere; You define a simple output network variable using the same syntax, but with the output modifier: network output type name; Example: The following declaration defines an output network variable of type “SNVT_type” with the name “nvoAmpere”.
Using changeable-type network variables allows you to design a generic device (such as a generic proportional-integral-derivative (PID) controller) that supports a wide range of numeric network variable types for set-point, control, and process-value network variables. See Defining a Changeable-Type Network Variable or more information about implementing changeable-type network variables for LonTalk Stack applications. You can also define your own nonstandard data types.
Declaring a Functional Block A functional block declaration, by itself, does not cause the LonTalk Interface Developer utility to generate any executable code, although it does create data that implements various aspects of the functional block. Principally, the functional block creates associations among network variables and configuration properties.
You can minimize the need for type translators by using standard network variable types (SNVTs) for commonly used types, and by using changeable-type network variables, where appropriate. You can also define your own user network variable types (UNVTs). You can use the NodeBuilder Resource Editor to look through the standard network variable types, as described in Defining a Resource File, or you can browse the standard profiles online at types.lonmark.org.
other devices (or groups of devices) in the network that expect a specific network variable, and the LonTalk Stack assembles and sends the appropriate packets to these devices. Similarly, when the LonTalk Stack receives an updated value for an input network variable required by its application program, it reads the data from the network and passes the data to the application program.
1. Declare the network variable with the changeable_type keyword. You must declare an initial type for the network variable, and the size of the initial type must be equal to the largest network variable size that your application supports. The initial type must be one of the interoperable standard or user network variable types. 2.
use the NodeBuilder Resource Editor to look through the standard configuration property types, as described in Defining a Resource File, or you can browse the standard profiles online at types.lonmark.org. You can also define your own configuration property type, if needed.
property array must be shared among all network variables or functional blocks to which it applies. In this case, the device must implement the configuration properties within a configuration file. In addition, you might decide whether to implement configuration properties within a configuration file for performance reasons.
The LONWORKS file transfer protocol and the direct memory files features are mutually exclusive; your device cannot implement both.
Example: This example defines a four-channel analog-to-digital converter (ADC), with the following properties: • Four channels (implemented as an array of functional blocks) • One gain setting per channel (implemented as an array of configuration properties) • A single offset setting for the ADC (implemented as a shared configuration property) • A linearization setting for all channels (implemented as a configuration property array) #include
network variable to which the property applies. For an SFPTopenLoopSensor standard functional profile, the SCPToffset configuration property applies to the functional block, and thus implicitly applies to the profile's primary member network variable. In this example, the effective data type of this property is SNVT_volt (inherited from nvoAnalogValue). The example also includes a five-point linearization factor, implemented as a configuration property array of type SCPTsetpoint.
The global keyword causes a configuration property member to be shared among all the functional blocks or network variables whose property list contains that configuration property family name. The functional blocks or network variables in the configuration property family can have only one such global member.
fblock SFPTopenLoopSensor { nvoAmpere[0] implements nvoValue; } fbAmpereMeter[NUM_PHASES] external_name("AmpereMeter") fb_properties { cpGain, static cpUpdateRate }; Inheriting a Configuration Property Type You can define a configuration property type that does not include a complete type definition, but instead references the type definition of the network variable to which it applies. A configuration property type that references another type is called a type-inheriting configuration property.
cpDefaultOutput = 123 }; fblock SFPTopenLoopSensor { nvoAmpere implements nvoValue; } fbAmpereMeter; The initial value (123) must be provided in the instantiation of the configuration property, because the type for cpDefaultOutput is not known until it is instantiated. You can also combine type-inheriting configuration properties with network variables that are of changeable type.
msg_tag myBindableMT; msg_tag bind_info(nonbind) myNotBindableMT; Similar to network variables, you can connect bindable message tags together, thus allowing applications to communicate with each other through the message tags (rather than having to know specific device addressing details). Each bindable message tag requires one address-table space for its exclusive use. Sending application messages through bindable message tags is also known as sending application messages with implicit addressing.
2 – Device Class and Subclass Applies to all devices with the specified device class and subclass. 3 – Manufacturer Applies to all devices from the specified manufacturer. 4 – Manufacturer and Device Class Applies to all devices from the specified manufacturer with the specified device class. 5 – Manufacturer, Device Class, and Device Subclass Applies to all devices from the specified manufacturer with the specified device class and device subclass.
the highest (most specific) applicable scope level. See the NodeBuilder FX User’s Guide for information about developing a plug-in to set the scope, or see the OpenLNS Commissioning Tool User’s Guide (or online help) for information about modifying a device shape to set the scope.
predefines the _FTXL and _MODEL_FILE macros, so that you can use #ifdef or #ifndef compiler directives to control conditional compilation of source code that is used for standard Neuron C compilation and as an LonTalk Stack model file. All constructs not specifically mentioned as unacceptable or ignored are acceptable. Anonymous Top-Level Types Anonymous top-level types are not valid.
that the “open” message comes from the owner, not from someone attempting to break into the system. Authentication doubles the number of messages per transaction. An acknowledged message normally requires two messages: an update and an acknowledgment. An authenticated message requires four messages, as illustrated in the next section. These extra messages can affect system response time and capacity. A device can use authentication with acknowledged updates or network variable polls.
tool, but must specify an authentication key because the device has only a default key. How Authentication Works The following figure illustrates the authentication process: ACKD Message or Device A (Writer) 1 Request 2 Challenge 3 Reply to challenge 4 ACK or Response Device B (reader) 1. Device A uses the acknowledged service to send an update to a network variable that is configured with the authentication attribute on Device B.
messages and commands be secret, because they are sent unencrypted over the network, and anyone who is determined can read those messages. It is good practice to connect a device directly to a network management tool when initially installing its authentication key. This direct connection prevents the key from being sent over the network, where it might be detected by an intruder.
The maximum number of address table entries that a device could require is determined by the expected maximum number of different destination entries that the device requires for connections (network variables and bindable message tags). The size of the address table affects the amount of RAM and non-volatile memory required for the device.
Network Variable Configuration Table This table contains one entry for each network variable that is declared in the model file. Each element of a network variable array counts separately. The maximum size of the network variable configuration table is 4096 entries. You cannot change the size of this table, except by adding or deleting static network variables or by increasing or decreasing the number of dynamic network variables.
posted to the nvoWattage output network variable. A second nvoUsage output network variable is polled and uses non-volatile storage to count the meter's total lifetime. network network network network network input input input output output polled eeprom SNVT_amp SNVT_volt SNVT_angle SNVT_power SNVT_elapsed_tm nviAmpere; nviVolt; nviCosPhi; nvoWattage; nvoUsage; The LonTalk Interface Developer utility generates type definitions in the LonNvTypes.h file for all of the above network variables.
// Implements the meter from the previous example.
nciMaxSendTime[0] }; network output polled eeprom SNVT_elapsed_tm nvoUsage; fblock UFPTenergyMeter { nvoWattage[0] implements nvoWattage; nviAmpere[0] implements nviAmpere; nviVoltage[0] implements nviVoltage; nviCosPhi[0] implements nviCosPhi; nvoUsage[0] implements nvoUsage; } Meter external_name("Meter") fb_properties { static nciCoupling }; This example implements two arrays of configuration network variables, nciMinSendTime and nciMaxSendTime.
nvoNodeStatus implements nvoStatus; nvoFileDirectory implements nvoFileDirectory; } NodeObject external_name("NodeObject") fb_properties { cpLocation }; // Config properties for the Meter SCPTminSendTime cp_family cpMinSendTime; SCPTmaxSendTime cp_family cpMaxSendTime; UCPTcoupling cp_family cpCoupling; // Network variables for the meter network input SNVT_amp nviAmpere[3]; network input SNVT_volt nviVoltage[3]; network input SNVT_angle nviCosPhi[3]; network output SNVT_power nvoWattage[3] nv_properties { c
7 Using the LonTalk Interface Developer Utility You use the model file, described in Chapter 6, and the LonTalk Interface Developer utility to define the network inputs and outputs for your device, and to create your application’s skeleton framework source code. You use this skeleton application framework as the basis for your LonTalk Stack application development. The utility also generates device interface files that are used by a network management tool when designing a network that uses your device.
Running the LonTalk Interface Developer You use the LonTalk Interface Developer utility to create the application framework files that are required for your LonTalk Stack application. The LonTalk Interface Developer utility also generates the device interface files (*.xif and *.xfb) that can be used by network management tools to design a network that uses your device. To create the device interface data and device interface files for your device, perform the following tasks: 1.
You can include a project version number in the name of the project to facilitate version control and project management for your LonTalk Interface Developer projects. The utility creates all of its output files in the same directory as the project file. Your application’s model file does not need to be in this directory; from the utility’s Model File Selection page, you can specify the name and location of the model file.
Select a clock speed and then click Next. In the System Preferences dialog, click Next (the LonTalk Stack does not have access to the service pin; therefore, the options in this dialog do not affect your LonTalk Stack device application).
• The size of the address table (the number of addresses) • The size of the alias table (the number of aliases) • The number of receive transaction records • The number of transmit transaction records • The maximum lifetime of a transmit transaction If you do not specify an override value, the LonTalk Interface Developer utility generates appropriate values based on other preferences that you specify for the project.
• Non-priority output buffers • Priority output buffers You can select the options to automatically calculate values to have the LonTalk Interface Developer utility calculate appropriate values for the buffer configuration. Click Next.
The average amount of memory to reserve for dynamic network variable self-documentation strings is used, along with the number of dynamic network variables, to calculate the maximum amount of non-volatile data that might be required for the LonTalk Stack device. The actual size of a particular dynamic variable’s self-documentation string can exceed the specified average, as long as the actual average size is less than or equal to the specified average size.
The non-volatile data flush timeout value determines how long the LonTalk host stack waits to receive additional updates before writing them to the non-volatile data. The non-volatile root name is used to configure the non-volatile data support driver. If you use the flash file system, the non-volatile root name is used as a file system directory name in which to create non-volatile data files. If you use the direct flash model, the name represents a host processor flash device name.
allowing you to select from lists contained in a program ID definition file distributed by LONMARK International. A current version of this list is included with the LonTalk Stack. Within the device’s program ID, you must include your manufacturer ID. If your company is a member of LONMARK International, you have a permanent Manufacturer ID assigned by LONMARK International. You can find those listed within the Standard Program ID Calculator utility, or online at www.lonmark.org/mid.
The model file is a simple source file written using a subset of the Neuron C Version 2.1 programming language. The model file contains declarations of network variables, configuration properties, functional blocks, and their relationships. The LonTalk Interface Developer utility uses the information in the model file, combined with other user preferences, to generate the application framework files and the interface files. You must compile and link the application framework files with the host application.
Specifying additional directories is optional. Use separate lines to specify multiple directories. The LonTalk Interface Developer project directory is automatically included in the compiler search path, and does not need to be specified explicitly. Similarly, the Neuron C Compiler system directories (for header files specified with angled brackets, for example, #include ) are also automatically included in the compiler search path. Click Next.
Click Next. Compiling and Generating the Files From the Summary and Confirmation page of the utility, you can view all of the information that you specified for the project. When you click Next, the LonTalk Interface Developer utility compiles the model file and generates a number of C source files and header files, as described in Using the LonTalk Interface Developer Files.
The Build Progress and Summary page shows the results of compilation and generation of the LonTalk Stack project files. Any warning or error messages have the following format: Error-type: Model_file_name Line_number(Column_number): Message Example: A model file named “tester.nc” includes the following single network variable declaration: network input SNVT_volt nviVolt Note the missing semi-colon at the end of the line.
• FtxlDev.c • project.xif • project.xfb These files form the LonTalk Stack application framework, which defines the LonTalk Stack device initialization data and self-identification data for use in initialization phase, including communication parameters and everything you need to begin device development. The framework includes ANSI C type definitions for network variable and configuration property types used with the application, and implements them as global application variables.
FtxlDev.h The FtxlDev.h file is the main header file that the LonTalk Interface Developer utility produces. This file provides the definitions that are required for your application code to interface with the application framework and the LonTalk API, including C extern references to public functions, variables, and constants generated by the LonTalk Interface Developer utility. You should include this file with all source files that your application uses, but you do not normally have to edit this file.
equivalents to the built-in Neuron C types. For example, the LonPlatform.h file contains a type definition for a Neuron C signed integer equivalent type called ncsInt. This type must be the equivalent of a Neuron C signed integer, a signed 8-bit scalar. For most target platforms, the ncsInt type is defined as signed char type. A network variable declared by a Neuron C built-in type does not require a host-side type definition in the LonNvTypes.
typedef LON_STRUCT_BEGIN(SNVT_switch){ ncuInt value; ncsInt state; } LON_STRUCT_END(SNVT_switch); Type definitions for structures assume a padding of 0 (zero) bytes and a packing of 1 byte. The LON_STRUCT_BEGIN and LON_STRUCT_END macros enforce platform-specific byte packing and padding. These macros are defined in the LonPlatform.h file, which allows you to adjust them for your compiler.
Enumerations The LonTalk Interface Developer utility does not produce enumerations. The LonTalk Stack requires an enumeration to be of size byte. The ANSI C standard requires that an enumeration be an int, which is larger than one byte for many platforms. The LonTalk Stack enumeration uses the LON_ENUM_BEGIN and LON_ENUM_END macros.
• ± 1 * 10 −7 approximate relative resolution The float_type structure declaration represents a floating-point number in IEEE 754 single-precision format. This format has one sign bit, eight exponent bits, and 23 mantissa bits; the data is stored in big-endian order. The float_type type is identical to the type used to represent floating-point network variables.
Network Variable and Configuration Property Declarations The LonTalk Interface Developer utility generates network variables and configuration properties using the built-in types defined in LonPlatform.h along with the types defined in LonNvTypes.h and LonCpTypes.h. Both network variables and configuration properties are declared in the FtxlDev.
*/ volatile LonWriteableValueFile lonWriteableValueFile = { {{'\x0', '\x0', '\x0', '\x0', '\x0', '\x0', '\x0', '\x0', '\x0', '\x0', '\x0', '\x0', '\x0', '\x0', '\x0', '\x0', '\x0', '\x0', '\x0', '\x0', '\x0', '\x0', '\x0', '\x0', '\x0', '\x0', '\x0', '\x0', '\x0', '\x0', '\x0'}} }; /* * CP template file */ const char lonTemplateFile[] = \ "1.
resources. You can use any type of non-volatile memory, or any other media for persistent data storage. The template file and the read-only value file would normally be declared as const, and can be linked into a code segment, which might relate to non-modifiable memory such as PROM or EPROM (these files must not be changed at runtime). However, writable, non-volatile storage must be implemented for the writable configuration property value file.
For the network management tool, however, the read-only file remains non-writeable. If your application uses the direct memory files feature to access the files, the LonTalk Interface Developer utility generates code that declares this direct memory files window segment as non-modifiable. If your application uses LONWORKS FTP to access the files, your implementation of the LONWORKS file transfer protocol and server must prevent write operations to the read-only value file under all circumstances.
input network variables, the polled attribute changes the behavior of the network management tool’s binder, which determines how a network variable connection is managed. See Developing a LonTalk Stack Device Application for more information about propagation of network variable updates. The Message Tag Table Although the LonTalk Host stack does not use the message tag table, the LonTalk Interface Developer utility declares the message tag table in FtxlDev.
8 Developing a LonTalk Stack Device Application This chapter describes how to develop a LonTalk Stack device application. It also describes the various tasks performed by the application.
Overview of a LonTalk Stack Device Application This chapter describes how to use the LonTalk API and the application framework produced by the LonTalk Interface Developer utility to perform the following tasks: • Use the LonTalk API and LonTalk Host stack • Integrate the application with an operating system • Provide persistent storage for non-volatile data • Initialize the LonTalk Stack device • Periodically call the LonTalk Stack event pump • Send information to other devices using network vari
Host Application FtxlApi.h FtxlDev.h Application Framework LonTalk API Echelon Smart Transceiver or Neuron Processor LonTalk Protocol Stack Operating System Abstraction Layer Hardware Abstraction Layer LonWorks Channel The [LonTalkStack]\Source folder contains the LonTalk Host stack, the LonTalk API, and the serial interface driver example, which together allow your LonTalk Stack application to handle network events, propagate network variables, respond to network variable poll requests, and so on.
o Future versions or fixes to the LonTalk Stack might affect these API files Callbacks and Events The LonTalk API uses two types of notifications for occurrences within the system: callbacks and events. The LonTalk API uses a callback when the API needs a return value from the application immediately. A callback can occur in one of the LonTalk host stack contexts (tasks or threads).
a pointer to the created semaphore and returns a status variable that indicates whether the function was successful. The LonTalk Stack includes source code for OSAL files that interface with Windows and Linux. To use a different operating system or provide your own operating system services, you must modify the OSAL files to implement the API for that operating system. For more information about the OSAL functions, see The Operating System Abstraction Layer.
When data that must be stored persistently is updated in RAM, the LonTalk host stack does not immediately update the corresponding persistent memory. Instead, the LonTalk host stack defers writing the data to persistent memory so that it can continue to respond to network management commands in a timely fashion. The reasons for deferred writing of persistent memory include: • Flash sectors sizes tend to be large and can take a long time to write.
3. Calling the LonNvdRead() callback handler function to read the header of the NVD image. This function verifies the header and, if it is valid, uses the size information in the header to allocate the appropriate buffers. 4. Calling the LonNvdRead() callback handler function again (perhaps many times) to read the entire configuration and de-serialize the image. 5. Deserializing the image and updating the LonTalk host stack’s control structures. 6.
LonNvdSegNodeDefinition segments, but not for the application-defined LonNvdSegApplicationData segment. Instead, the LonTalk host stack calls the LonNvdGetApplicationSegmentSize() callback handler function in step 1 above, and the LonNvdSerializeSegment() callback handler function during step 3 above when it processes the LonNvdSegApplicationData segment. Both of these callback handler functions are generated by the LonTalk Interface Developer utility.
Initializing the LonTalk Stack Device Before your application initializes the LonTalk host stack, it must initialize the C runtime environment and the operating system. If your LonTalk Stack device uses a native LonTalk interface, your application must implement the LonGetMyNetworkInterface() function in the FtxlHandlers.c file to specify the name of the network interface to be used by the driver.
operating system event which is signaled by the LonEventReady() callback handler function. From within your application’s main thread, the application should implement an infinite loop that waits on this operating system event. Whenever the event is signaled, the application should call the LonEventPump() API function to process LonTalk Stack events. You can signal this same operating system event to schedule your main application thread to perform other functions as well.
Example: while (1) { // process application-specific data ... if (OsalWaitForEvent(readyHandle, OSAL_WAIT_FOREVER) == OSALSTS_SUCCESS) LonEventPump(); } ... void LonEventReady(void) { OsalSetEvent(readyHandle); } In the example, the readyHandle variable is the handle to an OSAL event; this handle is defined using the OsalCreateEvent() function during the application’s initialization phase, and is signaled by the LonEventReady() callback handler function whenever an event is ready to be processed.
any application-specific processing of update completion. The following figure shows the control flow for processing a network variable update.
Do not handle an update failure with a repeated propagation; the LonTalk host stack automatically retries a number of times based on the network variable’s retry count. A completion failure generally indicates a problem that should be signaled to the user interface (if any), flagged by an error or alarm output network variable (if any), or by signaled as a comm_failure error through the nvoStatus network variable of the Node Object functional block (if there is one).
To process notification of a network variable update, modify the LonNvUpdateOccurred() event handler function (in the FtxlHandlers.c file) to call the appropriate functions in your application. The API calls this function with the index of the updated network variable. The following figure shows the control flow for receiving a network variable update.
extern void myController(void); void LonNvUpdateCompleted(unsigned index, const LonBool success) { switch (index) { case LonNvIndexNviAmpere: /* fall through */ case LonNvIndexNviVolt: myController(); break; default: /* handle other NV updates (if any) */ } } In your application source file: #include "FtxlDev.
{ // nvoWatt = nviAmpere * nviVolt * nciGain.multiplier; LON_SET_UNSIGNED_WORD(nvoWatt, LON_GET_UNSIGNED_WORD(nviAmpere) * LON_GET_UNSIGNED_WORD(nviVolt) * LON_GET_UNSIGNED_WORD(nciGain.multiplier)); // nvoWatt /= nciGain.divider; LON_SET_UNSIGNED_WORD(nvoWatt, LON_GET_UNSIGNED_WORD(nvoWatt) / LON_GET_UNSIGNED_WORD(nciGain. divider)); if (LonPropagateNv(LonNvIndexNvoWatt) != LonApiNoError) { // handle propagation error here ...
Validating a Type Change The SCPTnvType configuration property is defined by the following structure: typedef LON_STRUCT_BEGIN(SCPTnvType) { ncuInt type_program_ID[8]; ncuInt type_scope; ncuLong type_index; ncsInt type_category; ncuInt type_length; ncsLong scaling_factor_a; ncsLong scaling_factor_b; ncsLong scaling_factor_c; } LON_STRUCT_END(SCPTnvType); When validating a change to a network variable, an application can check five of the fields in the SCPTnvType configuration property: • The program ID tem
This enumeration describes the type (signed short or floating-point, for example), but does not provide information about structure or union fields. To support all scalar types, test for a type_category value between NVT_CAT_SIGNED_CHAR and NVT_UNSIGNED_LONG, plus NVT_CAT_SIGNED_QUAD. The type_length field provides the size of the type in bytes. Multiple changeable-type network variables can share the SCPTnvType configuration property.
then the application must process the type changes for both the network variable and the configuration network variable. If the network variable is a member of a configuration property’s application set where the configuration property is shared among multiple network variables, the application must process the type and length changes for all network variables involved. However, if the configuration property is implemented within a configuration file, no change to the configuration file is required.
callback handler function can report the correct current size for any implemented network variable. Your myGetNvTypeCp() function could handle that mapping. For the convenience of network management tools, you can also declare a SCPTmaxNVLength configuration property to inform the tools of the maximum type length supported by the changeable-type network variable.
variable is added. On device startup, it calls this function for each dynamic network variable that had been previously defined. • LonNvTypeChanged() The LonTalk host stack calls this function when a dynamic network variable definition is changed. • LonNvDeleted() The LonTalk host stack calls this function when a dynamic network variable is deleted.
Sending an Application Message to the Network Call the LonSendMsg() function to send an application message. This function forwards the message to the LonTalk host stack, which in turn transmits the message on the network. After the message is sent, the LonTalk host stack calls the LonEventReady() callback handler function to inform the application that an event has been enqueued. When the application calls the LonEventPump() function, the LonTalk API calls your LonMsgCompleted() event handler function.
or reset, and are handled by your LonWink(), LonOffline(), LonOnline(), and LonReset() callback handler functions. Handling Local Network Management Tasks There are various network management tasks that a device can choose to initiate on its own. These are local network management tasks, which are initiated by the LonTalk Stack application and implemented by the LonTalk host stack. Local network management commands are never propagated to the network.
To return a LonTalk Stack device to the legacy mode, rather than the extended mode, perform one of the following tasks: • Re-run the LonTalk Interface Developer utility to generate a new signature for the device, and rebuild and load the application image. • Send the NM_NODE::NM_INITIALIZE extended network management command to the device. • Erase the non-volatile memory for the device. • If the device is currently commissioned in an OpenLNS database, de-commission it.
The DMF Memory Window To the network management tool, all content of the DMF memory window is presented as a continuous area of RAM memory in the virtual DMF memory space. The DMF memory space is virtual because it appears to the network management tool to be located within the Echelon Smart Transceiver or Neuron Chip’s native address space, even though it is not.
Echelon Smart Transceiver or Neuron Chip network address space (Neuron addresses in big-endian notation) Virtual address space: defined host-side, using virtual Smart Transceiver addresses in host’s byte order Physical host address space SNVT_address File directory Echelon Smart Transceiver or Neuron Chip LON_DMF_WINDOW_START Maximum range: 0x0001 – 0xFFFF Template file File directory LON_DMF_WINDOW_USAGE Registered Memory Window Template file Writable value file Read-only value file Read-only va
• Using named or unnamed files (the DMF framework uses unnamed files by default, whereas FTP uses named files) • Up to 64 KB of data for each file • For the DMF framework: Up to a total of 64 KB for all files plus the file directory itself • For FTP: unlimited size The utility initializes the file directory depending on the chosen access method. The directory can be used with an FTP server implementation or the file access host memory window implementation.
132 Developing a LonTalk Stack Device Application
9 Developing an IP-852 Router Application This chapter describes how to develop a LonTalk Stack IP-852 router application.
Developing an IP-852 Router Application You can develop an IP-852 router application using the LonTalk Stack. The IP-852 router application does not require model files, a code framework generated by the LonWorks Interface Developer, or the LonTalk API. To create an IP-852 router application you use the following two C++ classes: Class Description File LtLogicalChannel Represents the network interface used to access a native LonWorks channel. LonTalkStack\Source\ Shared\include\ LtChannel.
Function Syntax Description name persistence files. The index is arbitrary, but it may need to be between 0 and n, where n is platform dependent (depending on how unique IDs and other items are stored). LtUniqueId. The uniqueId of the native LonWorks side of the router. pLtChannel. The LtLogicalChannel representing the native LonWorks channel ipAppIndex. The application index of the IP-852 router side. ipUid. The unique ID of the IP-852 router side. ipAddress.
136 Developing an IP-852 Router Application
10 Porting a LonTalk Stack Application This chapter describes how to port a LonTalk Stack device or IP-852 router application to your platform.
Porting Overview You can port your LonTalk Stack device or IP-852 router application to your own platform. Porting your application may require one to all of the following components: 1. 2. 3. 4. 5. 6. A version of the OSAL for your operating system. A LON-link driver. Socket interfaces. The LonTalk Stack source files. Application-specific files for LonTalk Stack devices. Your own application-specific files. The following sections provide tips for creating these components.
File/Folder Description MIP. The LonLink derived class is implemented in LonLinkDcx.cpp and LonLinkDcx.h. By default, Linux will automatically use the provided Linux driver for the Serial MIP. If you are using a different operating system, you need to modify the #define LtLinkDefault statement in the Source\Shared\include\LtLinkDefault.h file to reference your LonLink derived class. Service LED To control the service LED, you need to override the virtual setServicePinState() method of the LtLink object.
Shared\LtChannel.cpp Shared\LtCUtil.c Shared\LtDomain.cpp Shared\LtFailSafeFile.cpp Shared\LtHashTable.cpp Shared\LtLinkBase.cpp Shared\LtNetwork.cpp Shared\LtNvRam.cpp Shared\LtPersistence.cpp Shared\LtPktAllocator.cpp Shared\LtPktAllocatorOne.cpp Shared\LtPktInfo.cpp Shared\LtProgramId.cpp Shared\LtTaskOwner.cpp Shared\LtUniqueId.cpp Shared\LtVector.cpp Shared\RefQues.cpp ShareIp\iLonSntp.cpp ShareIp\IpLink.cpp ShareIp\LtIpBase.cpp ShareIp\LtIpChannel.cpp ShareIp\LtIpEchPackets.cpp ShareIp\LtIpMaster.
ble.cpp Stack\LtLayer4.cpp Stack\LtLayer6.cpp Stack\LtMip.cpp Stack\LtMipApp.cpp Stack\LtMsgOverride.cpp Stack\LtNetworkImage.cpp Stack\LtNetworkManager.cpp Stack\LtNetworkManager2.cpp Stack\LtNetworkStats.cpp Stack\LtNetworkVariable.cpp Stack\LtNetworkVariableConfig uration.cpp Stack\LtNetworkVariableConfig urationTable.cpp Stack\LtOutgoingAddress.cpp Stack\LtPlatform.cpp Stack\LtProXy.cpp Stack\LtReadOnlyData.cpp Stack\LtRouteMap.cpp Stack\LtStackClient.cpp Stack\LtStatus.cpp Stack\LtTransactions.
Preprocessor Definition Description LONTALK_STACK_PLATFORM An application device using a native LonWorks network interface. LONTALK_IP852_STACK_PLATFORM An application device using an IP-852 network interface. LONTALK_ROUTER_PLATFORM An IP-852 to native LonWorks router. These preprocessor definitions control which features to be included in the LonTalk Stack by defining other preprocessor definitions that are stored in the Source\Shared\include\LtaDefine.h file.
Appendix A LonTalk Interface Developer Command Line Usage This appendix describes the command-line interface for the LonTalk Interface Developer utility. You can use this interface for script-driven or other automation uses of the LonTalk Interface Developer utility.
Overview The LonTalk Interface Developer utility consists of two main components: • The LonTalk Interface Developer graphical user interface (GUI), which collects your preferences and displays the results • The LonTalk Stack Interface Developer, which processes the data from the GUI and generates the required output files If you plan to run the LonTalk Interface Developer utility in an unattended mode, for example as part of an automated build process, you can use the command-line interface to the LonTa
• Commands of a Boolean type need not be followed by a value. In this case, the value yes is assumed. Possible values for Boolean commands are yes, on, 1, +, no, off, 0, - (a minus sign or dash). Examples: libf -–verbosecomments=yes libf --verbosecomments • Commands can be read from the command line or from a command file (script file). A command file contains empty lines, lines starting with a semicolon (comment lines), or lines containing one command switch on each line (with value as applicable).
Command Switch Long Form Short Form --buffer -B Implement specified number of buffers of the specified type --clock -c Set the Echelon Smart Transceiver or Neuron Chip clock rate (in MHz) --define -D Define a specified preprocessor symbol (without value) --defloc Description Location of an optional default command file --dmfsize -z Override size of the direct memory file memory window --dmfstart -a Override start address of the direct memory file memory window --domains -d Implement do
Command Switch Short Form Long Form --silent Description Suppress banner message display --source -n Use the specified model file --spdelay -p Set the service pin notification delay (255=default, 0=off) --txdb -t Manage specified number of transmit transaction records --txttl -T Let transmit transactions expire after specified number of microseconds --verbose -v Run with verbosity level 0 (normal), 1 (verbose), or 2 (trace) --verbosecomments -V Generate verbose comments --warning Displ
The type and number for the --buffer switch are separated by a period. You can include several buffer specifications within a single --buffer switch, separated by commas, or with multiple --buffer switches. For example: --buffer=ai.5,ao.3 --buffer=ai.5 --buffer=ao.
Buffer Type Network output priority buffers Primary Specification Alternate Specifications Valid Values nop netoutputprio 1 to 100 netoutprio Default: 3 netprio network-priority-output The application buffers (ai, ao, and aop) all have a range of 1 to 100 for the allowable number of buffers. You can set priority buffers to a count of 0 (zero), but you must specify at least one non-priority buffer in both directions (input and output).
Appendix B Model File Compiler Directives This Appendix lists the compiler directives that can be included in a model file. Model files are described in Chapter 6, Creating a Model File.
Using Model File Compiler Directives ANSI C permits compiler extensions through the #pragma directive. These directives are implementation-specific. The ANSI standard states that a compiler can define any sort of language extensions through the use of these directives. Unknown directives can be ignored or discarded. The Neuron C compiler issues warning messages for unrecognized directives.
Important: Configuration property re-ordering and merging can reduce the memory required for the template file, but can also result in slower access to the application’s configuration properties by network management tools. This can potentially cause a significant increase in the time required to commission your device, especially on low-bandwidth channel types. You should typically only use configuration property re-ordering and merging if you must conserve memory.
#pragma set_guidelines_version string The Neuron C 2.1 compiler generates LONMARK information in the device’s XIF file and in the device’s SIDATA (stored in device program memory). By default, the compiler uses “3.3” as the string to identify the LONMARK guidelines version to which the device conforms. To override this default, specify the overriding value in a string constant following the pragma name, as shown. For example, a program could specify #pragma set_guidelines_version “3.
#pragma disable_warning number #pragma enable_warning number Controls the compiler's printing of individual warning messages. Warning messages generally indicate a problem in the model file, or a place where the code could be improved. Warning messages are on by default. These pragmas can be intermixed multiple times throughout a model file to turn informational message printing on and off as needed. The number parameter refers to a specific warning number, for example #pragma disable_warning 123.
Appendix C Neuron C Syntax for the Model File This Appendix lists the Neuron C syntax for the allowable statements of a model file.
Functional Block Syntax fblock FPT-identifier { fblock-member-list } identifier [ array-bounds ] [ ext-name ] [ fb-property-list ] ; fblock-member-list : fblock-member-list ; fblock-member fblock-member fblock-member : nv-reference implements member-name nv-reference impl-specific impl-specific : implementation_specific ( const-expr ) member-name nv-reference : nv-identifier array-index nv-identifier array-index : [ const-expr ] array-bounds : [ const-expr ] ext-name : external_name ( concatena
If the fblock is implemented as an array, each network variable that is to be referenced by the fblock must be declared as an array of at least the same size. When implementing an fblock array's member with an array network variable element, the starting index of the first network variable array element in the range of array elements must be provided in the implements statement.
These extra members are declared in the member list using the implementation_specific keyword, followed by a unique index number, and a unique name. Each network variable in a functional profile assigns an index number and a member name to each abstract network variable member of the profile, and the implementation-specific member cannot use any of the index numbers or member names that the profile has already used.
Functional Block Properties Syntax fb_properties { property-reference-list } property-reference-list : property-reference-list , property-reference property-reference property-reference : property-identifier [ = initializer ] [ range-mod ] property-identifier [ range-mod ] [ = initializer ] range-mod : range_mod_string ( concatenated-string-constant ) property-identifier : [ property-modifier ] identifier [ constant-expression ] [ property-modifier ] identifier property-modifier : static | global Ke
has a range modification, then all members must have a range modification specified. In this case, each range modification pair is delimited by the ASCII vertical bar character '|'. To specify no range modification for a member of a structure (that is, revert to the default for that member), encode the field as '|'. Use the same encoding for structure members that cannot have their ranges modified due to their data type. The '|' encoding is only allowed for members of structures.
pair for each member of the nvoData network variable array), and four offset CP family members (SCPToffset), one for each member of each fblock array. It also instantiates a total of two gain control CP family members (SCPTgain), one for MyFb1, and one for MyFb2. Finally, it instantiates a single location CP family member (SCPTlocation) that is shared by MyFb1 and MyFb2.
network output SNVT_amp nvoAmpere; network output polled SNVT_time_stamp nvoInstallDate; fblock SFPTopenLoopSensor { nvoAmpere implements nvoValue; nvoInstallDate implementation_specific(128) nvoInstall; } fbAmpereMeter external_name("AmpereMeter") fb_properties { cpDefaultOutput, // optional CP cpDisplayBrightness = {50.
sync | synchronized Specifies that all values assigned to this network variable must be propagated, and in their original order. This flag is passed on to your LonTalk Stack application, and must be enforced by your application. This keyword is mutually exclusive with the polled keyword. polled For an output network variable, specifies that the value of the network variable is to be sent only in response to a poll request from a device that reads this network variable.
In an application that uses compiler-generated SD data, you can still specify additional SD data with the sd_string() modifier. The compiler appends this additional SD information to the compiler-generated SD data, but it will be separated from the compiler-generated information with a semicolon. SD data that appears after the semicolon is treated as a comment and is not included in the device’s interoperable interface.
Use a SNVT or SCPT if one is available that matches your data because SNVTs and SCPTs can provide interoperability with other devices. • A user network variable type (UNVT) or user configuration property type (UCPT) defined in a user resource file. You can use the NodeBuilder Resource Editor to create custom UNVTs and UCPTs, and to view the available UNVTs and UCPTs in your resource files. Use a UNVT or UCPT if you cannot find an appropriate SNVT or SCPT for your data.
network variables. This keyword is not required for model files. Names of array elements are automatically expanded by the LonTalk Interface Developer compiler. offline Specifies that a network management tool must take this device offline, or ensure that the device is already offline, before updating the network variable. Do not use this feature in the bind_info for a configuration network variable that is declared using the config_prop or cp keyword. Instead, use the offline option in the cp_info.
A network variable connection is authenticated only if the readers and writers have the authenticated keywords specified. However, if only the originator of a network variable update or poll uses the keyword, the connection is authenticated (although the update does take place). See Using Authentication for Network Variables for more information about authentication. The default is nonauth (config). You must the acknowledged service with authenticated updates.
The Network Variable Initializer initial-value or initializer-list Specifies an initial value (or values) for the network variable. All network variables, especially input network variables, should be initialized to a reasonable default value.
Network variable properties can be shared between two or more network variables. The use of the global keyword creates a CP family member that is shared between two or more network variables. The use of the static keyword creates a CP family member that is shared between all the members of a network variable array, but not with any other network variables outside the array.
cp_family Declares the configuration property as part of a configuration file. The cp_family declaration is repeatable. The declaration can be repeated two or more times, and, as long as the duplicated declarations match in every regard, the compiler treats these as a single declaration. The alternative to declaring a configuration property as part of a configuration file is to declare a configuration network variable, as described in Declaring a Configuration Network Variable.
of relying upon the value in the device interface file or a value stored in a network database. This specification is used for configuration properties that must be managed by the device, such as a setpoint that is updated by a local operator interface on the device. This option requires the CP family or configuration property network variable to be declared as const.
has a range modification, then all members must have a range modification specified. In this case, each range modification pair is delimited by the ASCII vertical bar character '|'. To specify no range modification for a member of a structure (that is, revert to the default for that member), encode the field as '|'. Use the same encoding for structure members that cannot have their ranges modified due to their data type. The '|' encoding is only allowed for members of structures.
5. If no initial value is available from any of the preceding rules, a value of all zeros is used. The compiler uses the first rule in this list that applies to the configuration property. These initialization rules are used to set the initial value that are loaded in the value file from the linked image, as well as the value file stored in the device interface file.
The syntax for declaring a device property list is: device_properties { property-reference-list } ; property-reference-list : property-reference-list , property-reference property-reference property-reference : property-identifier [ = initializer ] [ range-mod ] property-identifier [ range-mod ] [ = initializer ] range-mod : range_mod_string ( concatenated-string-constant ) property-identifier : identifier [ constant-expression ] identifier The device property list begins with the device_properties keyw
// empty string initializer with its own }; Message Tag Syntax msg_tag [ connection-info ] tag-identifier [, tag-identifier ...] ; Keywords The connection-info field is an optional specification for connection options, and includes the following keywords: msg_tag Declares a message tag with the specified tag-identifier.
Appendix D LonTalk API This Appendix describes the API functions, event handler functions, and callback handler functions that are included with the LonTalk API. It also describes the operating system abstraction layer (OSAL) functions.
Introduction The LonTalk API provides the functions that you call from your LonTalk Stack application to send and receive information to and from a LONWORKS network. The API also defines the event handler functions and callback handler functions that your LonTalk Stack application must provide to handle LONWORKS events from the network and LonTalk Host stack.
Commonly Used LonTalk API Functions The following table lists API functions that you will most likely use in your LonTalk Stack application. Function Description LonEventPump() Processes any messages received by the LonTalk host stack. If messages are received, it calls the appropriate event handler functions. See Periodically Calling the Event Pump for more information about this function. LonExit() Stops the LonTalk host stack for an orderly shutdown of the LonTalk Stack device.
Function Description LonGetUniqueId() Gets the unique ID (Neuron ID) value of the Echelon Smart Transceiver or Neuron Chip. LonGetVersion() Gets the version number of the LonTalk API. LonPollNv() Requests a network variable value from the network. A LonTalk Stack application can call LonPollNv() to request that another LONWORKS device (or devices) send the latest value (or values) for network variables that are bound to the specified input variable.
Function Description LonNvdAppSegmentHasBeenUpdated() Indicates that the application data segment in non-volatile data memory has been updated. LonNvdFlushData() Requests that the LonTalk host stack flush all non-volatile data to persistent memory. LonNvdGetMaxSize() Gets the number of bytes required to store persistent data. Extended API Functions The LonTalk API includes an extended API that provides additional local network management commands listed in the following table.
Function Description LonQueryTransceiverStatus() Requests the local status of the Echelon Smart Transceiver or Neuron Chip. LonSetNodeMode() Sets the operating mode for the LonTalk Stack device: • Online: An online device executes its application and responds to all network messages. • Offline: An offline device does not execute its application or respond to network messages. It will respond to network management messages. • Configured: The device is ready for network operation.
Function Description LonNvUpdateOccurred() Indicates that a network variable update request from the network has been processed by the LonTalk API. This call indicates that the network variable value has already been updated, and allows your host application to perform any additional processing, if necessary. LonOffline() A request from the network that the device go offline. Installation tools use this message to disable application processing in a device.
Function Description LonNvAdded() Indicates that a dynamic network variable has been added. LonNvDeleted() Indicates that a dynamic network variable has been deleted. LonNvTypeChanged() Indicates that one or more attributes of a dynamic network variable have changed. Application Messaging Event Handler Functions The following table lists the event handler functions that are called by the LonTalk API for application messaging transactions.
Function Description LonNvdStarvation() Indicates that a write request to non-volatile data has taken more than 60 seconds. The application should call the LonNvdFlushData() API function to ensure that non-volatile data is written. LonTalk Stack Callback Handler Functions In addition to providing event handler functions, the LonTalk API also provides callback handler functions, mainly for managing memory on the LonTalk Stack device.
Function Description LonGetMyNetworkInterface() Gets the name of the network interface used to open the native LonTalk interface. This method returns the name of the network interface, such as the serial port name. This method has the following syntax: const char *LonGetMyNetworkInterface(void); Direct Memory Files Callback Handler Functions The LonTalk API provides the callback handler functions listed in the following table to support the direct memory files (DMF) feature.
Function Description LonNvdDeserializeSegment() Indicates a request to update the LonTalk Stack device’s control structures from the serialized application’s data segment. LonNvdEnterTransaction() Indicates a request to begin a transaction for the non-volatile data segment. LonNvdExitTransaction() Indicates a request to complete a transaction for the non-volatile data segment.
The following sections provide an overview of the functions that the OSAL provides. Managing Critical Sections To manage critical sections, the OSAL provides the functions listed in the following table: Function Description OsalCreateCriticalSection() Creates a critical section. OsalDeleteCriticalSection() Deletes a critical section. OsalEnterCriticalSection() Enters a critical section. OsalLeaveCriticalSection() Leaves a critical section.
Managing System Timing To manage system timing, the OSAL provides the functions listed in the following table: Function Description OsalGetTickCount() Gets the current system tick count. OsalGetTicksPerSecond() Gets the number of ticks in a second. Managing Operating System Tasks To manage operating system tasks or threads, the OSAL provides the functions listed in the following table. Function Description OsalCreateTask() Creates a task. OsalCloseTaskHandle() Closes the handle for a task.
192 Appendix D: LonTalk API
Appendix E Determining Memory Usage for LonTalk Stack Applications This Appendix describes how much volatile and non-volatile memory a LonTalk Stack application requires, and how to determine the application’s memory requirements.
Overview The LonTalk Host stack allocates memory dynamically, so a direct measurement of the memory usage might lead to an underestimate for memory usage, especially for peak usage conditions. This appendix provides both static code analysis and runtime measurements so that you can calculate more reliable memory usage estimates. Memory Use for Code The following table lists the estimated memory required for the LonTalk Stack code.
Memory Use for Buffers The Buffer Configuration page of the LonTalk Interface Developer utility allows you to specify the number of input, output, and priority output application buffers that your LonTalk Stack application should use. The values that you specify in the utility are defined in the FtxlDev.h file that the utility generates. The LonTalk host stack uses the number of application buffers that you specify to allocate memory for both the application buffers and related internal buffers.
Resource Type Bytes Required Notes: • SD_length is the length of the self-documentation string for the network variable • NV_length is the declared size of the network variable (for changeable-type network variables, NV_length is the maximum size of the network variable) In addition to RAM, LONWORKS resources also require memory for constant data.
non-volatile data functions calculates the maximum use configuration, and reserves flash memory space so that if one segment grows, it does not interfere with other segments. This section describes the amount of non-volatile data space required for the following application elements: • Network image (LonNvdSegNetworkImage) • Node definition (LonNvdSegNodeDefinition) • Application data (LonNvdSegApplicationData) The flash memory implementation in the FtxlNvdFlashDirect.
Node Data Bytes Required Notes: • Node_SD_length is the length of the self-documentation string for the node • NV_SD_length is the length of the self-documentation string for all network variables (both static and dynamic) The following table describes the amount of non-volatile memory required for the application data.
does not siginificantly alter the amount of RAM that the application requires. The number of buffers can affect the application’s performance. You can observe that as the number of network variables for the LonTalk Stack application grows, the RAM requirement grows significantly. These memory requirements do not include the requirements for application-specific data.
Number of Aliases Number of Address Table Entries RAM Required for Data (in KB) 20 3 15 202 20 20 33 20 228 250 50 20 83 50 277 500 101 20 166 101 361 1000 203 25 333 203 528 2000 407 50 666 407 870 4000 814 100 1333 814 1552 Number of Network Variables Number of Transmit Transactions Number of Receive Transactions 10 15 100 200 Determining Memory Usage for LonTalk Stack Applications Appendix E: Appendix E
Appendix F Downloading a LonTalk Stack Application Over the Network This Appendix describes considerations for designing a LonTalk Stack application that allows application updates over the network.
Overview For a Neuron-hosted device, you can update the application image over the network using OpenLNS or another network management tool. However, you cannot use the same tools or technique to update a LonTalk Stack application image over the network. Many LonTalk Stack devices do not require application updates over the network, but for those that do, this appendix describes considerations for adding this capability to the device.
During this stage, the LonTalk Stack device should verify that the application to be downloaded can run on the device platform (using the FPGA ID or similar mechanism), and verify that the application image is from a trusted source (for example, by using an encrypted signature). 2. Download the application. A reliable and efficient data transfer mechanism should be used. The interoperable file transfer protocol (FTP) can be used, treating the entire application image as a file.
application download utility to delay additional updates until the application is ready to receive the data. After the transfer is complete and all data has been written to non-volatile memory, the application must prepare the image so that the boot loader can reboot the embedded processor from the new image. This preparation must be defined so that a device or processor reset at any point will result in a functioning LonTalk Stack device.
Appendix G Example LonTalk Stack Applications This Appendix describes the example applications that are included in the LonTalk Stack. This Appendix describes each application’s design, main() and event handler functions, and model file. It also describes how to build and load the application images and run the example applications.
Overview of the Example Applications The LonTalk Stack Developer’s Kit includes three example applications that are stored in the LonWorks\LonTalkStack\Examples directory. You can build these example applications with Microsoft Visual Studio 2008, and then run them on Windows. To run the examples, you must install OpenLDV 4.0, which you can download for free from the Echelon Web site at www.echelon.com/support/downloads.
Function Description Ip852Router A router that connects an IP-852 channel to a native LonTalk channel. For the native LonWorks channel attached to this router, this example requires OpenLDV 4.0 (or later) and a Layer 2 network interface such as the Echelon U10 USB Network Interface or PCC-10, PCLTA-20, or PCLTA-21 network interface card. This network interface cannot be shared with the OpenLNS Commissioning Tool or any other application.
To test the example application, you can use the OpenLNS Commissioning Tool or another OpenLNS installation tool to install the device or router. Running the SimpleLtDevice Example The console application takes one argument: niName (the network interface name).
The model file for this example includes a single SFPTclosedLoopActuator functional block for the two network variables. It does not include a Node Object functional block. The SimpleLtDevice project is stored in the Examples\SimpleLtDevice directory. The SimpleIp852 example is the same as the SimpleLtDevice example except that it communicates over an IP-852 channel instead of a native LONWORKS channel. The SimpleIp852 project is stored in the Examples\SimpleIp852 directory.
"\n" " is the IPv4 dotted-decimal address to use for the IP-852\n" " interface\n" " is a decimal port number to use for the IP852 interface\n" "\n"); return 1; } #else if (argc < 2) { printf("Run a simple LonTalk Device using a standard LonTalk network interface\n\n" "Syntax:\n" " SimpleLtDevice " "\n" " is the name of the native LonTalk network interface\n" "\n"); return 1; } else { SetMyNetworkInterface(argv[1]); } #endif if (OsalCreateEvent(&eventReadyHandle) == OSALST
OsalSleep(10); } OsalCloseTaskHandle(taskHandle); } OsalDeleteEvent(&eventReadyHandle); } return 0; } Application Task Function The appTask() function is contained in the main.c file, and it performs the following tasks: 1. If the device is an IP-852 device, registers the devices unique ID. The example registers a dummy unique ID. A real IP-852 device must register a valid unique ID obtained from Echelon. 2. Calls the LonInit() function to initialize the LonTalk protocol stack.
LonResgisterUniqueId(&uid); #endif sts = LonInit(); if (sts == LonApiNoError) { /* This is the main control loop, which runs forever. */ while (!shutdownApp) { /* Whenever the ready event is fired, process events by calling * LonEventPump. The ready event is fired by the myEventReady * callback.
The two network variables are defined in the model file, which is described in Model File. The myNvUpdateOccurred() function is shown below. /* * This function is called by the FTXL LonNvUpdateOccurred * event handler, indicating that a network variable input * has arrived. */ void myNvUpdateOccurred(const unsigned nvIndex, const LonReceiveAddress* const pNvInAddr) { switch (nvIndex) { case LonNvIndexNviVolt: { /* process update to nviVolt.
The myEventReady() function calls the OSAL OsalSetEvent() function to signal the application task so that it can process the network event. The myEventReady() function is shown below. /* This function is called by the FTXL LonEventReady * callback, signaling that an event is ready to be * processed. */ void myEventReady(void) { /* Signal application task so that it can process the * event.
4. Run the LonWorks Interface Developer by double-clicking the Simple Example.lidprj file. This generates an updated application framework. 5. Modify the callback handler functions in the FtxlHandlers.c and main.c files as required. 6. Rebuild the project. 7. Optionally, load the generated XIF file into the Echelon Smart Transceiver or Neuron Chip. 8. Load the new executable file into the host processor.
5. Runs a simple command console: • When the S command is pressed, sends a service pin messages from both router halves by calling the sendServicePinMsg() method of the LtIp852Router object. • When the E or Q command is pressed, breaks out of the console loop 6. On exit, does the following: • Shuts down the router by calling the Shutdown() method of the LtIp852Router object. • Closes the native LonWorks network interface by deleting the LtLogicalChannel object. The main() function is shown below.
sts = router.Start(0, ltUid, pLtChannel, 1, ipUid, ipAddress, ipPort); } if (sts == LT_NO_ERROR) { printHelp(); printf("> "); while (TRUE) { char c = toupper(getchar()); if (c == 'S') { printf("Sending service pin...\n"); router.sendServicePinMsg(); } else if (c == 'Q' || c == 'E') { printf("Exiting...\n"); break; } else if (c == 0x0a) { printf("> "); ; } else { if (c != '?') { printf("Unrecognized command\n"); } printHelp(); } } } else { printf("Initialization error %d\n", sts); } router.
Appendix H LonTalk Interface Developer Utility Error and Warning Messages This Appendix lists the LonTalk Interface Developer utility error and warning messages, and offers suggestions on how to correct the indicated problems.
Introduction All messages, errors, and warnings, come with a standard Echelon message identifier LID#zzz, where zzz is a unique decimal number. All messages shown below are not actually given with the precise language shown at runtime. Instead, a summary of the message meaning is given for each message, followed by a brief discussion of possible reasons and remedies.
LID# Description 5 An error occurred when reading a device interface file This is an internal error, probably a result of an earlier failure. A non-fatal error during the creation of the device interface file might lead to this error. Re-run the LonTalk Interface Developer utility in Trace verbosity mode and carefully examine the LonTalk Interface Developer utility Summary window to determine the root cause of the failure.
LID# Description 10 Failure to attach to LONUCL32 service DLL The LonTalk Interface Developer utility or one of its components failed to locate a file by name of “LONUCL32.DLL.” This file usually resides in the same folder that contains the LID.exe application, but can be in any folder in your current user search path. This file is typically installed into the LonWorks Bin folder.
LID# Description 23 An error occurred when reading a type info file (.NCT) This is an internal error, possibly resulting from an earlier failure. The .nct file is an intermediate file used by the ShortStack Wizard. Re-run the LonTalk Interface Developer utility in Trace verbosity mode and carefully examine the LonTalk Interface Developer utility Summary window to determine the root cause of the failure. This error is similar to LID#22, but refers to different internal software components.
LID# Description 31 A type definition cannot be generated: the type is referenced but not defined A type that you have referenced is missing from the NCT file, and intermediate file used by the LonTalk Interface Developer utility. This is an internal error. Delete all intermediate files. Re-run the LonTalk Interface Developer utility in Trace verbosity mode and carefully examine the LonTalk Interface Developer utility Summary window to determine the root cause of the failure.
LID# Description 36 The program ID found in the XIF file seems malformed and cannot be used to produce the niAppinit data Use the LonTalk Interface Developer utility and the Standard Program ID calculator to produce a good program ID record. Delete all intermediate files. Re-run the LonTalk Interface Developer utility in Trace verbosity mode and carefully examine the LonTalk Interface Developer utility Summary window to determine the root cause of the failure.
LID# Description 55 The specified framework is not yet supported This is an internal error. 57 Required source file missing 59 Too many network variables. The sum of static and dynamic variables cannot exceed 4096. 60 Insufficient number of addresses This message includes how many addresses are require for the application, and how many were specified.
LID# Description 4006 A file cannot be copied This is possibly, but not necessarily, fatal. When the LonTalk Interface Developer utility creates the host framework, it produces several files based on input provided by the user. It also copies the necessary files into the destination folder. The utility-generated files refer to these files, which are required to build the host application.
LID# Description 4017 Files cannot be made writable When the LonTalk Interface Developer utility creates the host framework, it produces several files based on input provided by the user. It copies the necessary files into the destination folder. These files are made writable after they are copied, unless this warning indicates it is not possible. See also the LID#4006 warning.
LonTalk Stack Developer’s Guide 229
Appendix I Glossary This appendix defines many of the common terms used for LonTalk Stack device development.
D downlink Link-layer data transfer from the host to the Echelon Smart Transceiver or Neuron Chip. E Echelon Smart Transceiver or Neuron Chip A chip that is used as a transceiver to attach a host processor to a LONWORKS network; the Echelon Smart Transceiver or Neuron Chip runs the Neuron Firmware and implements layers 1 and 2 of the ISO/IEC 14908-1 Control Network Protocol. execution context A general term for a thread of execution for an operating system.
H host processor A microcontroller, microprocessor, or embedded processor that is integrated with the LonTalk API and an Echelon Smart Transceiver or Neuron Chip to create a LONWORKS device. L link layer A protocol and interface definition for communication between a host processor and either an Echelon Smart Transceiver or Neuron Chip or ShortStack Micro Server. link layer protocol The protocol that is used for data exchange across the link layer.
LonTalk Stack application An application for a LONWORKS device based on the LonTalk API and Echelon Smart Transceiver or Neuron Chip. LonTalk Stack Software required todevelop high-performance LonTalk applications for a host processor with an Echelon Smart Transceiver or Neuron Chip. The LonTalk Stack includes a simple host application programming interface (API), a complete ISO/IEC 14908-1 protocol stack implementation, a link-layer driver, a simple hardware interface, and comprehensive tool support.
www.echelon.
