20,741
edits
Howto:Port I/O from Nasal: Difference between revisions
Jump to navigation
Jump to search
m
→Introduction
m (turn forum thread into a wiki howto: http://flightgear.org/forums/viewtopic.php?f=30&t=15166) |
m (→Introduction) |
||
| Line 3: | Line 3: | ||
= Introduction = | = Introduction = | ||
You can't really directly 'access' a device from nasal. What you'll most likely want to do is define a | You can't really directly 'access' a device from nasal. What you'll most likely want to do is define a [[Generic Protocol]] for the properties your interested in sending between fgfs and your device. You can configure FlightGear to use that protocol directly with your serial device, through network to secondary program which handles serial, etc. | ||
Of course, in flightgear, you can then use nasal to handle and modify the properties being sent/received by whatever logic you desire. | |||
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. | 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. | ||
Setting up and using a | 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 are, how they internally work, let alone how to cater for the differences across the plethora of platforms supported by FlightGear. | 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. | ||
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. | ||