Author
Topic: Porting to QNX / photon (Read 15325 times)

I currently use the now discontinued Audrey from 3Com as a touch screen interface for my home automation. These are a very popular device amongst the hobbiest home automation crowd. What would be involved in porting the orbiter software to QNX so that it could run on the audrey? I have done a little development for QNX/photon and it seems to be relatively straight forward to port applications from linux to QNX. Getting the interface to work in photon is another matter.

Hmm.. I asked around and none of us know anything about QNX/photon. However, we definately want to help the community get going with Pluto.

Our Orbiter was written entirely in ANSI C++, and we use the same code for both Windows and Linux. In order to make the UI optimized and easy to port to other platforms, the Orbiter Gen actually does all the complicated 'pre-rendering', and basically just outputs static bitmap files that the Orbiter needs to display. That's how we were able to make the same Orbiter run on low-power devices like mobile phones. So, it should be very easy to make it run on any other type of device. Orbiter.cpp just has a handful of virtual functions that need to be implemented: Draw text, Draw a graphic, Draw a rectangle, etc. A few primitives. We use the SDL library to do this since that works on both Windows and Linux.

How do you compile for QNX/photon? Is it a Windows-based compiler? Is it ansi c++? Do you know if our code will compile on it? The easiest way to find out is just to check out the code and try to do a build. We provide both gcc makefiles, and vs.net project files. We can also provide some programming assistance on our end, although we don't have an Audrey.

I currently use the now discontinued Audrey from 3Com as a touch screen interface for my home automation. These are a very popular device amongst the hobbiest home automation crowd. What would be involved in porting the orbiter software to QNX so that it could run on the audrey? I have done a little development for QNX/photon and it seems to be relatively straight forward to port applications from linux to QNX. Getting the interface to work in photon is another matter.

Hi,

hooh, that would be great. I have 3 Audreys at home, but I'm only using them through web interface on Misterhouse. That would be cool to run Orbiter GUI on Audreys.

Aaron, you say that you prepare all pictures for GUI and then show them - wouldn't then be easier to try with web interface ? - in this case almost any device could work for Orbiter (at least GUI - touchscreen for command/control)...

If this would work, then any device with web browser will work as touchscreen gui ?

One of the big reasons we don't is for performance. It's important that the tablets run with instant screen changes in order to make it really responsive for the user. If you want to control your TV, we found that even 300ms was considered "slow". But WiFi, by it's nature, often has a latency close to that long anyway. So this way we can preload into a cache the most commonly used screens, and they can be pre-converted into a format more compatible with the display hardware for quick bliting, and then as you use the tablet, it just blits images rapidly onto the screen. The sending of the messages over wi-fi is handled in a separate thread so they happen concurrently. There are a lot of other things that would be difficult to do with a web interface. For example our orbiter includes a PHillips Pronto emulator for embedded ccf files, which would require an active-x control in a web page, and then you've lost the cross-platform advantage of html.

We've thought about a new orbiter that's based on flash, though, and we have a guy whose playing around with it to see how well it works. That could be embedded in web pages easy enough.

Speed of the interface is very important to me. It is why I had gotten frustrated with the misterhouse interface. To me web pages just don't feel like an actual remote. I have been working on designing my own interface which actually runs on the audrey. I had also looked at using flash but I wasn't sure quickly it would run on the slow processor and more importantly I know C++ and I'm clueless about flash. I am currently using XAP to communicate with misterhouse. So far the interface is just a few buttons which can control lights and such but at least it is fast and smooth. Seeing how nice the orbiter interface looks I can't help but want to get it to work.

To answer your questions:How do you compile for QNX/photon?QCC is the compiler

Is it a Windows-based compiler? Is it ansi c++? I develop for QNX by installing the free distribution that they provide within microsoft virtual machine. There is a reasonably good IDE and compiler included. You don't need an audrey to develop code. The QNX install on any X86 system will do.

Do you know if our code will compile on it?Not yet... but I'll certainly try to find out.

Speed of the interface is very important to me. It is why I had gotten frustrated with the misterhouse interface. To me web pages just don't feel like an actual remote. I have been working on designing my own interface which actually runs on the audrey. I had also looked at using flash but I wasn't sure quickly it would run on the slow processor and more importantly I know C++ and I'm clueless about flash. I am currently using XAP to communicate with misterhouse. So far the interface is just a few buttons which can control lights and such but at least it is fast and smooth. Seeing how nice the orbiter interface looks I can't help but want to get it to work.

...

Hi,

I see. Do you have any more info on your project? I certainly would also like to have faster interface than web pages. And so will probably some other Misterhouse&Audrey users... Have you announce it on MH mailing list ?

is the entry for Orbiter, and under it are the user's manal and programmer's guide (docs 27 and 28). A new User's manual is going to be included in tomorrow's build.

There is also a document for building from source code and getting the source from svn (doc id=101). You can also download the source directly by clicking the download link. Note that when you scroll down in the download section to 'Orbiter', you will see a link for the source code (SPSC), and a list of all the dependencies the module has. The source code may have additional dependencies (like .lib's needed to build).

If you use the Kick-start cd, you can just check 'get source code' in the installation wizard and it will get everything, including the source, automatically. However, wait until the 2.0.0.5 build because there's a problem with the current 2.0.0.4. It will be up tomorrow.

I see. Do you have any more info on your project? I certainly would also like to have faster interface than web pages. And so will probably some other Misterhouse&Audrey users... Have you announce it on MH mailing list ?

My project is just in the proof of concept stage at this point. When I have time to flesh it out a bit more I will post where I am at to the MH mailing list. Although if I can get an orbiter working on the audrey I may not feel the need for the other project.

I still think that I'd like to find some nice way of keeping MH around because it is so flexible while using pluto for interfaces, media, and phone.

Mr. House has a lot of very loyal users. We put 1 programmer on the task of finding a way to make Pluto work with Mr. House. But he said it's not so easy since both programs do the same things and mirror a lot of stuff, but in different ways. Both have a list of devices, for example, yet each needs different data and stores the device info differently. So they can't really share device data. But if both programs have their own separate list of devices, they're not really "working together" and it doesn't help the user too much. We will look into this more in the future, but at the moment it was decided that since we still have so much to finish on Pluto we had to focus our energies here and will revisit Mr. House at a later time.

Mr. House has a lot of very loyal users. We put 1 programmer on the task of finding a way to make Pluto work with Mr. House. But he said it's not so easy since both programs do the same things and mirror a lot of stuff, but in different ways. Both have a list of devices, for example, yet each needs different data and stores the device info differently. So they can't really share device data. But if both programs have their own separate list of devices, they're not really "working together" and it doesn't help the user too much. We will look into this more in the future, but at the moment it was decided that since we still have so much to finish on Pluto we had to focus our energies here and will revisit Mr. House at a later time.

I understand your point of view on "working together". I really don't think that it makes sense to try and share device data in that sense. All I would be looking for is the ability to continue to use misterhouse to read data from certain hardware and fire certain events. I think that the simplest approach for me (not sure this will help everyone else) is to have pluto send and recieve some XAP events. MH can already handle XAP and so can a number of other devices. The interface that I have been working on is not MH specific. It just sends and recieves XAP so it works equally well with MH and with other XAP aware software.

In any event if this is something important to the hobbiest community I think it is fair that someone who wants this functionality should work on it. I'm sure you folks are already busy enough with all the hard work you've been doing on pluto.

Mr. House has a lot of very loyal users. We put 1 programmer on the task of finding a way to make Pluto work with Mr. House. But he said it's not so easy since both programs do the same things and mirror a lot of stuff, but in different ways. Both have a list of devices, for example, yet each needs different data and stores the device info differently. So they can't really share device data. But if both programs have their own separate list of devices, they're not really "working together" and it doesn't help the user too much. We will look into this more in the future, but at the moment it was decided that since we still have so much to finish on Pluto we had to focus our energies here and will revisit Mr. House at a later time.

I understand your point of view on "working together". I really don't think that it makes sense to try and share device data in that sense. All I would be looking for is the ability to continue to use misterhouse to read data from certain hardware and fire certain events. I think that the simplest approach for me (not sure this will help everyone else) is to have pluto send and recieve some XAP events. MH can already handle XAP and so can a number of other devices. The interface that I have been working on is not MH specific. It just sends and recieves XAP so it works equally well with MH and with other XAP aware software.

In any event if this is something important to the hobbiest community I think it is fair that someone who wants this functionality should work on it. I'm sure you folks are already busy enough with all the hard work you've been doing on pluto.

Glenn

Hi,

I agree with both. I don't think of MH as being another Pluto. If pluto handles all devices and gives proper GUI to handle actions, devices etc.. then it doesn't make sense to do the same on MH. But MH is very strong on each field, that is for now probably missing in Pluto. For instance I have whole house audio on MH, also all kinds of Internet retrieiving infos, media libraries, special audio learn while sleep feature etc...etc...

So what I would really like for Pluto to have is general interface where all events/infos/lists of devices could be retrieved and actions can be triggerred. And that is more than enough. I'll then just transform MH into several pluto devices that provide whole house audio, or get weather situation and tells me jokes few times a day....

I'm not real programmer, but can write dirty Perl scripts - and that is strong feature of Perl, particularly for proof of concept projects. So some things could be easily tried on MH and then if they are good maybe transferred to Pluto...

So I suggest just some kind of general interface and leave the rest to the comunnitiy. I'm sure if Pluto will operate OK, many MH users (and other also) will take it as GUI frontend and leave features to MH that are not available in Pluto....

I looked over the schedule. The programmer who worked on the Mr. House part is Dan H, and can be reached at dan.h at plutohome com. It looks like he is presently working on the DHCP plug-and-play module and will be tied up the rest of the week. However, he might be able to squeeze in a couple days next week before taking on his next assignment. If anyone interested in this Mr. House integration wants to send Dan an email, then Dan can send you back a message and perhaps arrange a time when you guys can chat by IM, phone, or just exchange emails, so that he can do a Pluto - Mr. House integration that will prove useful to the real-world Mr. House users.