8,827
edits
Howto:Port I/O from Nasal: Difference between revisions
Jump to navigation
Jump to search
Category, general cleanup
m (→Introduction) |
(Category, general cleanup) |
||
| Line 1: | Line 1: | ||
== Introduction == | |||
You can't really 'access' a device from [[Nasal]] directly. What you'll most likely want to do is define a [[generic protocol]] for the properties you're interested in sending between fgfs and your device. A generic protocol allows you to easily import external data into [[FlightGear]]'s [[property tree]] and export properties, too. | |||
= Introduction = | |||
You can't really 'access' a device from [[Nasal]] directly. What you'll most likely want to do is define a [[ | |||
You can configure FlightGear to use that protocol directly with your serial device, through network to secondary program which handles serial, etc. | 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 | Of course, in FlightGear, you can then use Nasal scripting to handle and modify the properties being sent/received by whatever logic you desire. | ||
This feature alone makes it possible to circumvent many restrictions of the | This feature alone makes it possible to circumvent many restrictions of the generic protocol, so that the protocol spec itself just boils down to transmitting and receiving a single "string" property, which in turn is entirely controlled and modified from scripting space. | ||
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. | ||
| Line 25: | Line 18: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
Obviously, you need a matching | 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. The connection details are entirely handled by FlightGear, so they need to be specified during start up time. | ||
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. | ||
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 | 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). | ||
| Line 97: | Line 90: | ||
The same concept could also be used to come up with an "input property" to process results from your device. | The same concept could also be used to come up with an "input property" to process results from your device. | ||
You could then register a listener that is automatically invoked whenever the "input property" is modified, this will automatically invoke your Nasal callback (i.e. a Nasal function) so that you can process the input. | You could then register a listener that is automatically invoked whenever the "input property" is modified, this will automatically invoke your Nasal callback (i.e. a Nasal function) so that you can process the input. | ||
<syntaxhighlight lang="php"> | <syntaxhighlight lang="php"> | ||
| Line 118: | Line 110: | ||
_setlistener("/sim/cockpit/eufd-input", processMessage); | _setlistener("/sim/cockpit/eufd-input", processMessage); | ||
</syntaxhighlight> | </syntaxhighlight> | ||
Next, you could come up with a list of supported message types: | Next, you could come up with a list of supported message types: | ||
| Line 142: | Line 133: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
See [[generic protocol]] for more info on the generic protocol and have a look in [http://gitorious.org/fg/fgdata/trees/master/Protocol $FG_ROOT/Protocol] for examples of various protocol configurations. There's also a howto tutorial available here: [[Howto: Create a generic protocol]]. | |||
See [[ | |||
We suggest you just try it, create a simple protocol with a couple properties, explore ways to send and receive those values, and so on. If your serial device is a microcontroller that your programming then you may be able to get away with sending/receiving the values directly to/from flightgear without need of any secondary 'middleware' programs at all. If not you may need a small program to handle marshalling the data between flightgear and your hardware. | We suggest you just try it, create a simple protocol with a couple properties, explore ways to send and receive those values, and so on. If your serial device is a microcontroller that your programming then you may be able to get away with sending/receiving the values directly to/from flightgear without need of any secondary 'middleware' programs at all. If not you may need a small program to handle marshalling the data between flightgear and your hardware. | ||
| Line 160: | Line 148: | ||
setprop(output_property, data); | setprop(output_property, data); | ||
</syntaxhighlight> | </syntaxhighlight> | ||
* http://plausible.org/nasal/lib.html | * http://plausible.org/nasal/lib.html | ||
* http://www.cplusplus.com/reference/clibrary/cstdio/sprintf/ | * http://www.cplusplus.com/reference/clibrary/cstdio/sprintf/ | ||
= References = | == References == | ||
* https://gitorious.org/fg/fgdata/blobs/master/Docs/README.IO | * [https://gitorious.org/fg/fgdata/blobs/master/Docs/README.IO Docs/README.IO] | ||
* https://gitorious.org/fg/fgdata/blobs/master/Docs/README.protocol | * [https://gitorious.org/fg/fgdata/blobs/master/Docs/README.protocol Docs/README.protocol] | ||
* http://flightgear.org/forums/viewtopic.php?f=30&t=15166 | * http://flightgear.org/forums/viewtopic.php?f=30&t=15166 | ||
* http://gitorious.org/fg/fgdata/trees/master/Protocol | * [http://gitorious.org/fg/fgdata/trees/master/Protocol Protocol] | ||
* http://gitorious.org/fg/fgdata/blobs/master/Nasal/bits.nas | * [http://gitorious.org/fg/fgdata/blobs/master/Nasal/bits.nas Nasal/bits.nas] | ||
[[Category:Nasal howto]] | |||
[[Category:Nasal]] | |||