Board index FlightGear Development New features

New subsystem blocking or non blocking

Discussion and requests for new features. Please note that FlightGear developers are volunteers and may or may not be able to consider these requests.

New subsystem blocking or non blocking

Postby jcuk » Tue Jul 31, 2012 10:33 am

Hello

I'm currently planning on developing drivers for Saitek switch panels for FG. I've got a proof of concept application working at the moment, where I have a small C program that talks to the panel and decodes the commands, and I now want to move forward and integrate this into the main code. If I understand correctly I'll need to create a new subsystem to do this, but my code currently blocks until there is a change in state of one of the switch panels and I'm not sure if the subsystems are suitable for use with blocking code. I think that all subsystems are executed synchronously in order, so blocking on one would cause the entire simulator to halt. Is this correct?

If this is correct, I'm guessing that I need to spawn a background thread to handle the blocking code, but I don't think C++ supports native multi threading. Does FG use thread library, if so which one? As a bit of background, I come from a Java background, so I'm comfortable with multi threading concepts and I've done some Objective-C but I haven't touched C++ for 20 odd years so I more than a little rusty.
FGMap for iOS Available now for iPhone and iPad
jcuk
 
Posts: 22
Joined: Sat Jun 02, 2012 9:35 pm
Location: Herts, UK
OS: OSX / Linux

Re: New subsystem blocking or non blocking

Postby Hooray » Tue Jul 31, 2012 10:13 pm

We have multi-platform threading wrappers in SimGear and OSG.
That said, it isn't clear if you really need to use threads here, you could just as well use non-blocking I/O via select, which would not require a worker thread, but is well supported by FG.

Almost certainly, you don't want to create a subsystem from scratch, but rather a new I/O protocol.
See the wiki for details
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: New subsystem blocking or non blocking

Postby jcuk » Fri Aug 10, 2012 10:15 am

Thanks for the info. It turns out that it was the usb-hidraw setup that meant the calls were blocking when I ask for the status of the switches on the panel. I had another look at it last night and it turned out to be a trivial to put the hidraw into non-blocking mode so I can now save all the bother of worker threads and simplify things somewhat.

I've use the IO protocol stuff before to stream data over UDP for an iOS version of Atlas, but unless I'm missing something I don't think this supports USB and also there is a certain amount of processing of the messages needed. When I said I was creating a new subsystem I was planning to do something similar to FGJoystickInput.cxx, and add it to input.cxx. Hopefully this is appropriate.
FGMap for iOS Available now for iPhone and iPad
jcuk
 
Posts: 22
Joined: Sat Jun 02, 2012 9:35 pm
Location: Herts, UK
OS: OSX / Linux

Re: New subsystem blocking or non blocking

Postby Hooray » Fri Aug 10, 2012 10:35 am

Here's some background information:

viewtopic.php?f=30&t=15166&hilit=usb+hid
viewtopic.php?f=24&t=14535&hilit=usb+hid#p144050
viewtopic.php?f=30&t=15101&hilit=usb+hid
http://code.google.com/p/flightgear-bug ... ail?id=619

In other words, we have a pending feature request to implement USB/HID support using a cross-platform library so that the whole thing gets mapped into the FlightGear property tree. This should make your project much simpler, shouldn't it?

If you are interested in working on this, let us know so that we can provide further pointers.

When I said I was creating a new subsystem I was planning to do something similar to FGJoystickInput.cxx, and add it to input.cxx. Hopefully this is appropriate.

Yes, it is absolutely appropriate, but obviously we have a certain "design" in mind, so that others can reuse your work and use it for related things.
As can be seen in the feature request discussion, core developers already talked about how to implement USB/HID support and how to map it into the property tree.

That would in fact involve a modification of the I/O (protocol) system, or another SGSubsystem (like you mentioned originally). Then, the subsystem would use "listeners" (familiar concept from Java, right?) to invoke callbacks in order to instantiate, initialize and set up USB/HID devices.

Please see the feature request for details.
Obviously, you would need to be able to build FG from source - but we have plenty of docs to get you started (see the wiki).
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: New subsystem blocking or non blocking

Postby jcuk » Fri Aug 10, 2012 2:38 pm

Great, this is fantastic. I wasn't thinking in terms of a generic HID-USB functionality, but this does make more sense to make any solution generic. I'm at work now but will have a more detailed look thorough the links when I get home and see if I can contribute something.
I'm more than happy to get stuck in with coding, and I'm not particularly looking for a simple solution where someone else does the hard work and I just write the config file. I mean, where's the fun in that? :wink: I've been a bit crippled over the last couple of months by very intermittent internet access at home, but I've got some time off in the next two weeks, so wanted to try and get stuck in then.

Yep, callbacks are a familiar concept and I've managed to get the USB stuff working cross platform with library whos name escapes me at the moment (well, Linux and OSX. It says it works with windows, but I've no windows machine to test). I've used the property tree before and I can follow how the Generic protocol uses the config files to map input and output to the tree. I need to get a bit of a better understanding in my mind of what is generic in USB comms and what is specific to the device that I've got and then I think that's all the major pieces covered, and it all sounds doable.

I've managed to get FG built and running from source under linux, not yet under osx and I haven't got a windows machine, so barring me sorting out my mac build I'll be working on my old Linux machine.

Thanks for all the pointers

Jason
FGMap for iOS Available now for iPhone and iPad
jcuk
 
Posts: 22
Joined: Sat Jun 02, 2012 9:35 pm
Location: Herts, UK
OS: OSX / Linux

Re: New subsystem blocking or non blocking

Postby Hooray » Fri Aug 10, 2012 3:06 pm

Great, this is fantastic. I wasn't thinking in terms of a generic HID-USB functionality, but this does make more sense to make any solution generic. I'm at work now but will have a more detailed look thorough the links when I get home and see if I can contribute something.
I'm more than happy to get stuck in with coding, and I'm not particularly looking for a simple solution where someone else does the hard work and I just write the config file. I mean, where's the fun in that?


It's not that this is particularly complex or tedious to do, we can provide all the pointers and help that you need. With your background in Java programming, the C++ code and the concept of "listeners" and callbacks should seem fairly natural actually - so you probably won't need too long to add a new "dummy" subsystem to get started quickly.

Obviously, you could still focus on what's important for your own project now, and let others complete it later on.

I've been a bit crippled over the last couple of months by very intermittent internet access at home, but I've got some time off in the next two weeks, so wanted to try and get stuck in then.

Being able to use gitorious to clone the repositories there, would definitely be good - the simgear/flightgear repositories are straightforward to clone, even on mobile broadband.

However, fgdata may be a bit troublesome, but you could just as well use the fgdata from the latest release, modify the "version" file in $FG_ROOT and then use your own compiled binaries. Because most of your work will happen in C++ space anyway.

I need to get a bit of a better understanding in my mind of what is generic in USB comms and what is specific to the device that I've got and then I think that's all the major pieces covered, and it all sounds doable.

Yes, that's probably going to be most time-consuming, the C++ stuff is straightforward actually - and looking at the links below, it shouldn't take you much more than 30+ minutes to get a dummy prototype up and running. Obviously mapping an API to the property tree using listeners would be a little more complex though. For starters, you could directly map library-functions to property-tree callbacks.

I've managed to get FG built and running from source under linux, not yet under osx and I haven't got a windows machine, so barring me sorting out my mac build I'll be working on my old Linux machine.

that sounds fine, and should be no problem: most developers are using some variant of *nix, and frankly it's much easier to build FG on *nix platforms, too ;-)


The wiki has a separate portal, dedicated to contributors who want to get involved in core development: http://wiki.flightgear.org/Portal:Developer

To get started, you'll probably want to take a look at: http://wiki.flightgear.org/Howto:Start_core_development

The specifics of adding a new subsystem to FlightGear are covered here: http://wiki.flightgear.org/Howto:Create_new_subsystems
This article also provides an introduction to using the SGPropertyChangeListener class, so that your subsystem may subscribe to property tree events in order to "fire" its own callbacks (i.e. subsystem methods like "valueChanged").

Basically this works such that you could add a subscription for some arbitrary path, such as "/usb-hid" - now, whenever somethhing writes to "/usb-hid", your class will be automatically invoked using a listener, i.e. one of the class methods ("valueChanged") will be "fired", so that you can process these events - i.e. in order to see if the events are valid and match what you are expecting.

This technique is fairly common in FlightGear, it is also used to instantiate new AI traffic, but also the new Canvas system uses this method: All IPC is handled through the property tree and a separate C++ subsystem which registers listeners to "parse" and "process" and writes to a certain branch, such as /ai/ or /canvas or anything else.

In turn, this enables you to map an existing API or cross-platform USB/HID library into property tree space by coming up with typical operations, like "open, send, receive, validate, close" etc.
Ultimately, any other FlightGear system would be able to your new USB/HID layer by using the property tree. Which means that arbitrarily complex USB/HID protocols could be implemented in scripting space using Nasal scripting, which would merely invoke the C++ "glue" code.

Some of the details on adding new files to the existing cmake build environment are discussed here: http://wiki.flightgear.org/Howto:Create ... instrument

A short introduction to the C++ API of the SGPropertyTree Node class is provided here: http://wiki.flightgear.org/Howto:Work_w ... y_Tree_API

Please note that so called "tied properties" shouldn't be used, but "PropertyObjects" should be favored whenever possible: http://wiki.flightgear.org/Howto:Use_Pr ... ee_Objects
Lots of non-FG specific programming resources and pointers are available here: http://wiki.flightgear.org/Programming_resources
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: New subsystem blocking or non blocking

Postby Hooray » Sun Aug 12, 2012 6:41 pm

Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: New subsystem blocking or non blocking

Postby jcuk » Wed Feb 13, 2013 12:14 pm

Hi Hooray

A (very) belated thanks for all the help. After trashing my dev system, I took a break, but I'm starting again now. I noticed that a generic usb-hid discussion has started up on a new thread, so I've move over to that one.

viewtopic.php?f=30&t=15101&p=177111#p148500

ta

jcuk
FGMap for iOS Available now for iPhone and iPad
jcuk
 
Posts: 22
Joined: Sat Jun 02, 2012 9:35 pm
Location: Herts, UK
OS: OSX / Linux


Return to New features

Who is online

Users browsing this forum: No registered users and 5 guests