I guess the problem is that none of us realtime programmers really read
POSIX standards. If we did, we’d know that POSIX does not require you to
have a paged VM model. And in case you do have it, it defines mechanism to
control VM behavior. One can lock any particular page or all pages of a
process so they never will be paged out. In QNX6 they are in fact all locked
by default and for a process to be subject for paging it has to explicitly
unlock them using munlockall() call, defined by POSIX.
I guess the problem here is that none of us realtime programmers went to
the
POSIX standards meetings to say that standards should not be written in a
way which implies the existance of a particular memory model,
architecture,
etc… If the standard implies adherence to a shared VM model, then it is
a
bad standard. Hard realtime code can’t be written in the presence of such
a
model, because VM throws fine grained execution determination right out
the
window. If you need a millionth of a second response time, and the system
decides right then to do a page out, your application is non-functional.
QNX shouldn’t be required to fake a shared VM model to satisfy POSIX.
They
should go back to the standards committee, and suggest that the
requirement
is poorly formed. (If it is, in fact, an actual requirement.)
The fact that there are some realtime operating systems which have a
shared
VM model shouldn’t require QNX to implement same. In those OSes, there
are
usually explicit programmer notes on the avoidance of paging for
close-tolerance realtime operations.
Personally, I don’t mind using a realtime OS with paging if paging can be
circumvented. However, I don’t think all realtime OSes should be required
to implement such a model.
Previously, Todd Hitt wrote in comp.os.qnx, qdn.public.qnxrtp.devtools, qdn.public.qnxrtp.os, qdn.public.qnxrtp.newuser:
I think I miscommunicated.
I’m using the read command to read the incoming message, not bits from the
8250’s register. I’m using devctl to do that.
It’s looking like I’m going to have to write my own “driver” and control the
8250 completely. On further investigation, playing with the 8250 register’s
causes the 8250 driver (or somebody) to become rather unhappy. My
application won’t read (it never returns) nor do a tcdrain (also never
returns) once I mess with things. It does do a write though!
One would think that with all the RS-485 communication stuff used in QNX’s targeted applications, that there would be a good 485 driver one of these years.
On the other-hand, there are problems with many UART chips as far as handling the 485 turn-around goes. The big one is that the transmitt buffer empty interrupt happens when the buffer is ready to handle another character - but before the bits of the last transmitted character are shifted out. This is a problem for the driver writer. One can set up a timer to wake you up a bit later (this may be the problem you are seeing), or send an extra final character which will possibly be trashed when you turn the transmitter off. Another solution is to moniter transmitted data via the receiver and turn off the transmitter when the message has been locally received. A side beni is that you have some indication that no other traffic interferred with your message.
Some of the newer UARTS can be programmed to handle turn-around after the last transmit bit is sent making life much easier - these are the deep fifo parts 165[67]0? or something like that.
Michael J. Ferrador <> n2kra@orn.com> > wrote in message
news:90qgc4$6vm$> 1@inn.qnx.com> …
I don’t know if I was supposed to get the graphics-ddk
BUT the svga driver built, but did not display under bench
I was going to try to i586 optimizations to start
I got 3 versions of benchI[345], but no major speed diff,
not that I expected any - It’s video (io? mem?) bound.
It’s probably bus or memory bound.
The video RAM in your frame buffer usually needs to be accessed
as non-cacheable, which means no matter how fast your CPU, it’s
all of a sudden the same clock speed as your bus.
On top of that, the video cards CRTC section (the circuits that
constantly paint your monitor with an image of what’s in the
frame buffer) has priority over the CPU when they need to access
the RAM, so the higher your resolution, color depth and refresh
rate, the less bandwidth is available to write into frame buffer
RAM.
This overlaying of mountpoints is a very handy feature for things like
Or implementing Plan 9 http://plan9.bell-labs.com/plan9dist/
speaking of which, can you support multi-API’s aka
Personalities (Mach), Subsystems (NT)
field updates and servicing. It also makes for a more unified system,
where
pathnames result in connections to servers regardless of what services
they’re providing, giving us a more unified API.
Future articles related to this topic will examine how the package
filesystem takes advantage of this pathname unioning, how the package
manager works, and how to write your own packages to use with the package
installer and the package filesystem.
I was wondering how you did that, what looked like
links /x86/lib/dll & /lib/dll with out a link count
When I first tried this, to save devg-svga.so (In case I built a better
one), I tried linking it to devg-svga.orig.so and got a not supported.
Is that the expected behavior from pkg-fs, or a bug?
Long story made short … links don’t work well on files with the
package filesystem. The behaviour is better in the next version which
should percolate out with the next patch.
That is partially correct. The package filesystem lets the
request “fall through” to the underlying filesystem which
will allow the link to be created. At the same time it marks
the file as being spilled so that it is no longer resolved by
the package filesystem.
Or implementing Plan 9 > > > http://plan9.bell-labs.com/plan9dist/
speaking of which, can you support multi-API’s aka
Personalities (Mach), Subsystems (NT)
It is entirely possible that you would be able to provide
a “per-user” customizable filesystem space on the same
machine. It isn’t at all as straighforward as it would
be compared to Plan9 who actually implemented seperate
namespaces right from the start for users. I think of
it more as the ability to filter what the users sees
from the filesytem.
I was wondering how you did that, what looked like
links /x86/lib/dll & /lib/dll with out a link count
This layer rides above the actual device based filesystem.
That is to say that you can use the package filesystem with
files living on any other filesystem (dos,cd,qnx4,ext2 etc)
living on any medium (devb,flash,nfs etc). That is why
in the /bin directory you see that there are files there
which actually originate “elsewhere” where “elsewhere” is
more than one place.
I am just going through newsgroup postings and the QNX site trying to find information about how to enable a 485 port and am only finding comments
such as these. I expected to find another driver or an option to Dev.ser that allows for 485 operation. It is very hard to believe, and annoying, that
this capability isn’t already available. Oh well.
Is the source to Dev.ser available? It would be a small matter to modify an existing working driver to include RS485 than to have to start from
scratch. Otherwise I guess we will have to do what many of you out there have already done, and write our own driver. I’d like to avoid it since we
really don’t have the time. We assumed this capability was going to be in the QNX driver.
As far as turn around time, many UARTs do let you know when the last character clears the transmit buffer. I’ve seen hat on the older Zilog UARTs from
the 80’s. I don’t know enough about the 82C50 or 16C550 parts, but I suspect they also allow for that.
Any suggestions?
-Paul N. Leonard
David Hawley wrote:
One would think that with all the RS-485 communication stuff used in QNX’s targeted applications, that there would be a good 485 driver one of these years.
On the other-hand, there are problems with many UART chips as far as handling the 485 turn-around goes. The big one is that the transmitt buffer empty interrupt happens when the buffer is ready to handle another character - but before the bits of the last transmitted character are shifted out. This is a problem for the driver writer. One can set up a timer to wake you up a bit later (this may be the problem you are seeing), or send an extra final character which will possibly be trashed when you turn the transmitter off. Another solution is to moniter transmitted data via the receiver and turn off the transmitter when the message has been locally received. A side beni is that you have some indication that no other traffic interferred with your message.
Some of the newer UARTS can be programmed to handle turn-around after the last transmit bit is sent making life much easier - these are the deep fifo parts 165[67]0? or something like that.
I use Connect Tech Inc. adapters to handle my 485 interface. The cards work fine and the have QNX and Neutrino (QRTP) drivers that work well. Once I set the adapter up I forgot it was there…
I don’t work for them either - I just like their products.
I am just going through newsgroup postings and the QNX site trying to find information about how to enable a 485 port and am only finding comments
such as these. I expected to find another driver or an option to Dev.ser that allows for 485 operation. It is very hard to believe, and annoying, that
this capability isn’t already available. Oh well.
Is the source to Dev.ser available? It would be a small matter to modify an existing working driver to include RS485 than to have to start from
scratch. Otherwise I guess we will have to do what many of you out there have already done, and write our own driver. I’d like to avoid it since we
really don’t have the time. We assumed this capability was going to be in the QNX driver.
As far as turn around time, many UARTs do let you know when the last character clears the transmit buffer. I’ve seen hat on the older Zilog UARTs from
the 80’s. I don’t know enough about the 82C50 or 16C550 parts, but I suspect they also allow for that.
Any suggestions?
-Paul N. Leonard
David Hawley wrote:
One would think that with all the RS-485 communication stuff used in QNX’s targeted applications, that there would be a good 485 driver one of these years.
On the other-hand, there are problems with many UART chips as far as handling the 485 turn-around goes. The big one is that the transmitt buffer empty interrupt happens when the buffer is ready to handle another character - but before the bits of the last transmitted character are shifted out. This is a problem for the driver writer. One can set up a timer to wake you up a bit later (this may be the problem you are seeing), or send an extra final character which will possibly be trashed when you turn the transmitter off. Another solution is to moniter transmitted data via the receiver and turn off the transmitter when the message has been locally received. A side beni is that you have some indication that no other traffic interferred with your message.
Some of the newer UARTS can be programmed to handle turn-around after the last transmit bit is sent making life much easier - these are the deep fifo parts 165[67]0? or something like that.
Do some searching of deja and the knowledge base. This has been discussed before and I think code was posted.
“Paul N. Leonard” wrote:
All our serial ports reside on the CPU board. Of the four ports, one can be used as RS485
with RTS controlling the Tx/Rx direction. I think I may have found the drivers on the QNX
web site, but I’m not sure they are the current ones. I’ll probably modify them to include
an RS485 option. <sigh
Thanks for the input.
rectech wrote:
I use Connect Tech Inc. adapters to handle my 485 interface. The cards work fine and the have QNX and Neutrino (QRTP) drivers that work well. Once I set the adapter up I forgot it was there…
I don’t work for them either - I just like their products.
All our serial ports reside on the CPU board. Of the four ports, one can be used as RS485
with RTS controlling the Tx/Rx direction. I think I may have found the drivers on the QNX
web site, but I’m not sure they are the current ones. I’ll probably modify them to include
an RS485 option.
Thanks for the input.
rectech wrote:
I use Connect Tech Inc. adapters to handle my 485 interface. The cards work fine and the have QNX and Neutrino (QRTP) drivers that work well. Once I set the adapter up I forgot it was there…
I don’t work for them either - I just like their products.
----- Original Message -----
From: <keith@qnx.com> in message news:94pk8n$6k7$1@nntp.qnx.com…
Newsgroups: qdn.public.qnxrtp.os
Subject: Re: Patch Improves, BUT… mostly net
Just for reference…
We don’t actually recommend editing the system initialization files
directly. When you do an update they won’t be updated since they’re
spilled.
OK, I Cut and Pasted the all the commented stuff
from /etc/rc.d/rc.sysinit
to /etc/rc.d/rc.local
…example…
BTW, we didn’t start inetd automatically since it tends to be a security
hole. That code in the /etc/rc.d/rc.sysinit was never actually meant to
and uncommented the stuff I wanted, even if it was not meant to be used
in /etc/rc.d/rc.sysint, if you copy / run it elsewhere, it would be nice to
have correct code that is capable of running. Not everyone who needs it,
is going to know enough shell to find the error.
be used . . .
Michael J. Ferrador <> n2kra@orn.com> > wrote:
uhhh… DUH!
We’re in the design stages for some custom image processing boards and our
hardware guys asked me what was the maximum amount of memory-mapped I/O
that
they can configure the boards with and still be usable with Neutrino/RTP.
I
didn’t know and didn’t see anything in the docs or knowledge base on this.
For our system, we expect to have 4 to 8 similar PCI devices per single
board computer (PowerPC based). Each device has some large memories on
board
for which it would be convenient if it could be mapped directly into a
process’s address space.
What is the maximum amount of memory-mapped I/O that Neutrino can handle?
Can we use a gigabyte or more, several hundred megabytes, or what? Any
limits on a per-device basis?
Thanks for any info or pointers to docs on this that you can provide.
Wayne Fisher
Team Leader/Architect - Core Software
Focus Automation Systems Inc.
I would think that a 1GB per card would be OK in theory, I might get
concerned around 2GB (don’t know why exactly . Remember that each
process get’s it’s own 4GB address space currently (at least on x86) so
the total memory mapped by your processes (including stack, heap, shared
memory, and the memory mapped board) definately can not exceed 4GB.
This is an interesting question, I hope someone from QSSL answers in a
more authoritative fashion. In theory you should be able to map (4GB -
memory used by process) but there may be some implementation
thingamajigs that prevent this.
-----Original Message-----
From: Wayne Fisher [mailto:wayne.fisher@focusautomation.com]
Posted At: Monday, April 16, 2001 8:21 AM
Posted To: os
Conversation: Maximum addressing range: PCI
Subject: Re: Maximum addressing range: PCI
It doesn’t look like this made it out last time… Here it is again.
We’re in the design stages for some custom image processing boards and
our
hardware guys asked me what was the maximum amount of memory-mapped
I/O
that
they can configure the boards with and still be usable with
Neutrino/RTP.
I
didn’t know and didn’t see anything in the docs or knowledge base on
this.
For our system, we expect to have 4 to 8 similar PCI devices per
single
board computer (PowerPC based). Each device has some large memories on
board
for which it would be convenient if it could be mapped directly into a
process’s address space.
What is the maximum amount of memory-mapped I/O that Neutrino can
handle?
Can we use a gigabyte or more, several hundred megabytes, or what? Any
limits on a per-device basis?
Thanks for any info or pointers to docs on this that you can provide.
Wayne Fisher
Team Leader/Architect - Core Software
Focus Automation Systems Inc.
I would think that a 1GB per card would be OK in theory, I might get
concerned around 2GB (don’t know why exactly > > . Remember that each
process get’s it’s own 4GB address space currently (at least on x86) so
the total memory mapped by your processes (including stack, heap, shared
memory, and the memory mapped board) definately can not exceed 4GB.
This is an interesting question, I hope someone from QSSL answers in a
more authoritative fashion. In theory you should be able to map (4GB -
memory used by process) but there may be some implementation
thingamajigs that prevent this.
I think NTO is limited to 4GB of virtual memory.
-----Original Message-----
From: Wayne Fisher [mailto:> wayne.fisher@focusautomation.com> ]
Posted At: Monday, April 16, 2001 8:21 AM
Posted To: os
Conversation: Maximum addressing range: PCI
Subject: Re: Maximum addressing range: PCI
It doesn’t look like this made it out last time… Here it is again.
We’re in the design stages for some custom image processing boards and
our
hardware guys asked me what was the maximum amount of memory-mapped
I/O
that
they can configure the boards with and still be usable with
Neutrino/RTP.
I
didn’t know and didn’t see anything in the docs or knowledge base on
this.
For our system, we expect to have 4 to 8 similar PCI devices per
single
board computer (PowerPC based). Each device has some large memories on
board
for which it would be convenient if it could be mapped directly into a
process’s address space.
What is the maximum amount of memory-mapped I/O that Neutrino can
handle?
Can we use a gigabyte or more, several hundred megabytes, or what? Any
limits on a per-device basis?
Thanks for any info or pointers to docs on this that you can provide.
Wayne Fisher
Team Leader/Architect - Core Software
Focus Automation Systems Inc.
\
I would think that a 1GB per card would be OK in theory, I might get
concerned around 2GB (don’t know why exactly > > . Remember that each
process get’s it’s own 4GB address space currently (at least on x86) so
the total memory mapped by your processes (including stack, heap, shared
memory, and the memory mapped board) definately can not exceed 4GB.
This is an interesting question, I hope someone from QSSL answers in a
more authoritative fashion. In theory you should be able to map (4GB -
memory used by process) but there may be some implementation
thingamajigs that prevent this.
I think NTO is limited to 4GB of virtual memory.
I suspect that mapping more than 3.5Gb might be problematic due to
‘thingamajigs’.
There might be architecture-specific pacularities as well.
Since PCI cards are mapped into REAL memory before being re-mapped into
virtual memory, and the address bus is 32 bits wide…
I think that all of the limitations under QNX6 are hardware limitations.
i.e. If running on an x86 machine with 32-bit PCI (as far as I know, the
only type supported by QNX6 at the moment)
Max of 4gb of REAL address space
With all PCI cards installed, they must allow for all other real memory
ranges required by other memory/peripherals
Other than that, the only limits should be the ones imposed by physical
restraints and the PCI standards
I too, am waiting for the official QSSL response, however!
We’re in the design stages for some custom image processing boards and
our
hardware guys asked me what was the maximum amount of memory-mapped I/O
that
they can configure the boards with and still be usable with
Neutrino/RTP.
I
didn’t know and didn’t see anything in the docs or knowledge base on
this.
For our system, we expect to have 4 to 8 similar PCI devices per single
board computer (PowerPC based). Each device has some large memories on
board
for which it would be convenient if it could be mapped directly into a
process’s address space.
What is the maximum amount of memory-mapped I/O that Neutrino can
handle?
Can we use a gigabyte or more, several hundred megabytes, or what? Any
limits on a per-device basis?
Thanks for any info or pointers to docs on this that you can provide.
Wayne Fisher
Team Leader/Architect - Core Software
Focus Automation Systems Inc.
\
If we assume that QNX6 uses 32bits for all of its addressing then the PCI
addressing range will be limited to something smaller than the max. of 4GB.
Gotta leave room for main memory, etc.
But, if QNX6 uses 64bits behind the MMU than it’s theoretically possible
that a full 32 bits of addressing could be allocated to PCI devices
(assuming, of course, that the CPU itself can address more than 4GB).
However, with processes limitted to 4GB of address, no one process could
address all 32bits worth of the PCI bus.
I expect that the answer may also be different depending on the CPU
selected. I’m interested in the x86 and PowerPC architectures.
Since PCI cards are mapped into REAL memory before being re-mapped into
virtual memory, and the address bus is 32 bits wide…
I think that all of the limitations under QNX6 are hardware limitations.
i.e. If running on an x86 machine with 32-bit PCI (as far as I know, the
only type supported by QNX6 at the moment)
Max of 4gb of REAL address space
With all PCI cards installed, they must allow for all other real memory
ranges required by other memory/peripherals
Other than that, the only limits should be the ones imposed by physical
restraints and the PCI standards
I too, am waiting for the official QSSL response, however!
–
Wayne Fisher
Team Leader/Architect - Core Software
Focus Automation Systems Inc.
