Echelon FTXL User Manual
Page 94
82
Developing an FTXL Application
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 FTXL events.
You can signal this same operating system event to schedule your main
application thread to perform other functions as well. For example, you could
signal the operating system event from within an interrupt handler to signal the
main application task to process application I/O. Calling the LonEventPump()
function when there are no FTXL events is acceptable.
The host application should be prepared to process the maximum rate of
L
ON
W
ORKS
traffic delivered to the device. Although events are enqueued within
the FTXL LonTalk protocol stack, your application should call the
LonEventPump() function frequently to process events. Use the following
formula to determine the minimum call rate for the LonEventPump() function:
1
−
=
rCount
InputBuffe
ate
MaxPacketR
rate
where
MaxPacketRate
is the maximum number of packets per second arriving
for this device, and
InputBufferCount
is the number of input buffers defined for
your application (that is, buffers that hold incoming data until your application is
ready to process it). The formula subtracts one from the number of available
buffers to allow new data to arrive while other data is being processed.
However, the formula also assumes that your application has more than one
input buffer; having only one input buffer is generally not recommended.
If the application expects periods of inactivity, it can simply wait for the FTXL
LonTalk protocol stack to post an event. If the application expects periods where
it is busy for several milliseconds at a time, it should call the LonEventPump()
function during the busy time to ensure that events are processed. Use the
formula above to determine a baseline for how often to call the LonEventPump()
function.
Recommendation: In the absence of measured data for the network, assume 90
packets per second arriving for the device. This packet rate meets the TP/FT-10
channel’s throughput figures, assuming that most traffic uses acknowledged or
request/response service. Use of other service types will increase the required
packet rate, but not every packet on the network is necessarily addressed to this
device.
Using the formula, devices that implement two input buffers and are attached to
a TP/FT-10 network that expect high throughput should call the
LonEventPump() function approximately once every 10 ms.
When an event occurs, the LonEventPump() function calls the appropriate event
function for your host application to handle the event. Your event handler
functions must be designed for this minimum call rate, and should defer time-
consuming operations (such as lengthy flash writes) whenever possible, or
manage them in separate contexts (tasks or threads).
See Appendix D,
, on page 147, for a list of the available event
handler and callback handler functions.