Howto:Port I/O from Nasal: Difference between revisions

Jump to navigation Jump to search

Howto:Port I/O from Nasal (view source)

Revision as of 11:26, 2 February 2012

617 bytes added ,  2 February 2012
m
→‎Introduction
mNo edit summary
Line 10: Line 10:


You would just be delegating the I/O job to a dedicated sub system and merely use the property tree system to set and get the data to be processed. So, Nasal wouldn't even (need to) know that it is processing data that's coming from an external source. Thus, Nasal doesn't even need low level port access. All these low level details are handled by a separate subsystem.
You would just be delegating the I/O job to a dedicated sub system and merely use the property tree system to set and get the data to be processed. So, Nasal wouldn't even (need to) know that it is processing data that's coming from an external source. Thus, Nasal doesn't even need low level port access. All these low level details are handled by a separate subsystem.
In Nasal, you could use a conventional setprop() call to set a property, which is then picked up by the I/O subsystem and sent to its destination (e.g. serial port/network).
<syntaxhighlight lang="php">
setprop("/myoutput-property/data", "my data");
</syntaxhighlight>
Obviously, you need a matching [[Generic protocol]] that picks up the corresponding properties, marshals them into the required format and sends them to their destination.


Setting up and using a [[Generic Protocol]] is very easy, just a simple XML file defining the property values you want to send and/or receive...with optional formatting. Flightgear can then use this protocol with various end points from simple logging to file, across the network, directly to/from a serial device, etc...via a simple command line option.
Setting up and using a [[Generic Protocol]] is very easy, just a simple XML file defining the property values you want to send and/or receive...with optional formatting. Flightgear can then use this protocol with various end points from simple logging to file, across the network, directly to/from a serial device, etc...via a simple command line option.


We have numerous people here who manage to create I/O protocols and who manage to interface to FG using network sockets, without even knowing what sockets really are, how they internally work, let alone how to cater for the differences across the plethora of platforms supported by FlightGear. All of these things are internally handled by the [[Generic Protocol]] system.
There are many FlightGear users who manage to create I/O protocols and who manage to interface to FG using network sockets or serial port I/O, without even knowing what sockets or UARTs really are, how they internally work, let alone how to cater for the differences across the plethora of platforms supported by FlightGear.  
 
All of these things are internally handled by the [[Generic Protocol]] system, abstracted away by the FlightGear property tree, where hardware I/O is just a matter of dealing with the FlightGear [[property tree]].
 
This is due to the power of the subsystems that are largely configurable, usable and accessible using XML and the property tree - there's is often no need for any low level "hard coding" (i.e. in C or C++ space).
 
Basically, FlightGear allows you to make use of features that would take even an experienced C++ developers hours or even weeks to recreate in C++ space, and this is without even touching the core C++ source code.


This is due to the power of the subsystems that are largely configurable, usable and accessible using XML and the property tree - there's is often no need for any low level "hard coding" (i.e. in C or C++ space). Basically, FlightGear allows you to make use of features that would take even an experienced C++ developers hours or even weeks to recreate in C++ space, and this is without even touching the core C++ source code.
Accessing a serial port by coming up with a generic protocol is simple and well-documented.  


Accessing a serial port by coming up with a generic protocol is simple and well-documented. We have a plethora of examples, too - if you'd like to copy/paste stuff from different places. Then, all you need to do is to come up with input and output properties for transmitting your data. Once this is working, you can look into coming up with a piece of Nasal to further process the properties as required.
We have a plethora of examples, too - if you'd like to copy/paste stuff from different places. Then, all you need to do is to come up with input and output properties for transmitting your data. Once this is working, you can look into coming up with a piece of Nasal to further process the properties as required.


A generic protocol is really nothing more than a list of properties to send and/or receive. Nothing complex to develop and think about, just what properties are of importance to you. Also don't worry about Nasal at this point, it is not necessary for sending/receiving from generic protocol which just reads/writes from the property tree. Thinking about Nasal at this point is just muddying the water...forget about it until you actually need it.
A generic protocol is really nothing more than a list of properties to send and/or receive. Nothing complex to develop and think about, just what properties are of importance to you. Also don't worry about Nasal at this point, it is not necessary for sending/receiving from generic protocol which just reads/writes from the property tree. Thinking about Nasal at this point is just muddying the water...forget about it until you actually need it.
Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/39973"

Navigation menu