20,741
edits
Howto:Port I/O from Nasal: Difference between revisions
Jump to navigation
Jump to search
m
→Introduction
m (→Introduction) |
m (→Introduction) |
||
| Line 9: | Line 9: | ||
So just because there's no low level "function" available to do something from Nasal, that doesn't necessarily mean it cannot be done. This doesn't just apply to networking I/O or serial port access: There's also no dedicated Nasal command to play sounds, control AI traffic, place clouds etc - yet, we can do all of these things, by leveraging dedicated subsystems which are invoked/interfaced to via the property tree. | So just because there's no low level "function" available to do something from Nasal, that doesn't necessarily mean it cannot be done. This doesn't just apply to networking I/O or serial port access: There's also no dedicated Nasal command to play sounds, control AI traffic, place clouds etc - yet, we can do all of these things, by leveraging dedicated subsystems which are invoked/interfaced to via the property tree. | ||
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, without you having to handle the details from scripting space. | ||
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). | 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). | ||
| Line 19: | Line 19: | ||
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. | 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. | 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. | ||
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. | 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 | All of these things are internally handled by the [[Generic Protocol]] system and 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). | 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). | ||