QNX Neutrino & QNX4.25

Hello,
Iwas just wandering if it could be possible to compile old project with watcom 10.6 under QNX neutrino. We are planning to migrate to QNX Neutrino for the Blue Tooth support but we still have older project with QNX 4.25 that we still need to support.

Anyone know if there is any Blue tooth support for QNX 4.25?

Where can I find source code example on how to use

  • Serial Port
  • Timer
  • USB
  • Blue Tooth
  • Tcpip
  • IO
    -Makefile for GNU compiler

for QNX Neutino ?

How much space do you need on your disc to install the OS without the GUI?

Do you still have console like in QNX4.25 with ditto?

QNX Rep is coming to visit us in September and we are trying to see if a migration could be possible without too much pain.

Thanks,

Migration effort depends on your code and how much QNX4 specific stuff it uses. I go from a simple recompile to major rework.

I don’t know of any bluetooth support for QNX4.

QNX6 doesn’t have any ditto like capability ( incredible isn’t it ). There is the GNU screen application that can be ported to QNX6 but I haven’t been able to make it work as simply as ditto.

As far as disk space, it take a little more then QNX4 but not much. In fact with the right tool and some work you can get it to size similar to QNX4. My setup is 12Meg and it has photon.

As you might expect, that depends. Anything with just basic POSIX calls should compile effortlessly. Photon applications will probably port fairly nicely too, although I found some tweaking in the visuals was necessary.
If you write message passing, it will need tweaking also. Drivers/Resource Managers are a bigger project. QNX 6.3 is actually much nicer than QNX 4 for this type of stuff, but it will take a little re-educating.

I doubt it. If there is, it is probably from a 3rd party.

Serial ports, timers, Tcpip, and Makefiles haven’t changed any.
If you have a driver for Blue Tooth and USB, well you should just be writing to a standard I/O interface. open/close/read/write/etc.

If by IO you mean inp8() etc, then there’s not much new to know.
There’s a call to gain IO access, and as before you need to be root, but that’s about all.

The install CD seems to want 2Gig minimum, and it automatically installs the GUI. That’s for development. Once you have a development system, you can create target images as small as you can imagine.

You do have text consoles, but no text ditto. There is of course a ditto when both systems are using Photon.

I’ve never used QNX4’s ditto. I found telnet good enough :slight_smile:

ditto and telnet have two very distinct use.

Say customer is reporting a problem at boot time, bunch of errors on the screen (/dev/con1), how can telnet help you see these errors?

We start pretty much all our application into a console and I can’t imagine not using ditto anymore.

That should be QNX priority #1 , porting ditto to neutrino.

By the way anyone know rich moore? He is coming to see us in september with the QNX rep.

I could not imagine it either…

What I ended up doing is starting a virtual session of photon ( a photon session with no graphic driver ). Each program start in a pterm. The only way to access the pterm is via phditto or phindows. That means we need to setup tcpip, just for that purpose. That’s quite a setup to get the equivalent feature ( well not quite ) of QNX4’s ditto. Still we cannot remotely see the text on the console display at boot time…

We also stumble upon a bug were some data printed ( via printf ) would get lost, the culprid was devc-pty ;-(

See Thomas’ post on SendReceiveReply, maybe we can get the ditto_mgr stuff released at some point…

I could see this to be a major problem for us. We will see what the QNX rep has to say about it.
May be it would be easier to simply port bluetooth to QNX4. Nothing wrong with QNX4 always been reliable.

Johnny,

Don’t know what kind of sales you are looking at but if it’s big enough now is probably the only time you have some leverage to get thinks like ditto done “for free” ;-)

Johnny,

remember that QNX 4 is as old as Windows 3.11 / Windows 95. QNX Software Systems is doing a great job still supporting this OS - something that a company like Microsoft would never do, although they have the money… But you shouldn’t count on that new QNX 4 hardware drivers will be developed by QSSL forever.

something that a company like Microsoft would never do

That why we are not using Microsoft product. The day QNX start to behave like microsoft we gonna move to linux.

I’m not sure that’s entirely true. Today it takes more money to get QNX to move compare the QNX of 10 years ago. I imagine that you can get Microsoft to move but it would take an insane amount of money. In fact QNX is getting there, which is probably a sign they are getting bigger.

That sales meeting you are having will probably answer that question ;-)

Look at this study and think about Linux?
embedded.com/design/opensour … 499?pgno=2

There is several embedded manafucturer that already switched from Microsoft to Linux and the reason has nothing to do with the cost of the OS. Microsoft like changing their developement platform and stop supporting their old one to make you upgrade to the new one. Let see you develop something using Visuall C++ 4.2. 6 Months later you have 5.0 and your project doesn’t compile anymore. Library gone , etc …

Then Dot Net and Vista, a company canno’t just afford to rewrite everything each years.

So far with qnx4 we have been able to use the same stuff for that last 10 years without having to rewrite a line of code which is great. One mistake QNX made with QNX neutrino is, they stop supporting their old product and force company to spend a lot time & money to move to the new platform.

So if we have to develop something new again we will look for something that doesn’t change too often or is backward compatible.

I don’t think the Microsoft changing all the time argument stands. There is nothing that forces you to use say VC 5.0 over VC 4.2. Aside maybe the fact that you can’t buy 4.2 anymore ;-)

Of course you might have to if you want to extra features, but then don’t use these features ;-) Hence you end up with an outdated system much like QNX4.

The down side is that you are missing on all the latest features that exists out there, just like with QNX4 ;-)

Can we still use Mqueue with Neutrino?

Yes. In fact come Wednesday, Mqueue (or mq, as it is now known - SO much more efficient,
it only takes up two letters!) will be so much cooler than the QNX4 version you won’t believe it.

BTW - what are those guys at sendreceivereply.wordpress.com on about?!!

;-)

You’ll want to keep an eye on SRR, I’ve got a ditto follow-up post coming to-morrow.

Not the QNX4 ditto …
sendreceivereply.wordpress.com/2 … delivered/

talks about the Neutrino ditto replacement … and with source!