I’m using Momentics 6.2.1B on a x86 PC with a 8 port serial card.
I’m using devc-ser8250 and everything works OK most of the time.
But sometimes transmission is frozen for about 12 seconds on one of the
ports, just the transmission, the reception keep going with no problem.
No characters get lost when the transmission is frozen, they get transmitted
after the 12 second period elapses.
It happens on all of the ports at random, but I didn’t see it happen on two
ports at the same time.
I’m almost sure than the problem is not in my program, nor in the card.
Any suggestions?
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>
I’m using Momentics 6.2.1B on a x86 PC with a 8 port serial card.
I’m using devc-ser8250 and everything works OK most of the time.
But sometimes transmission is frozen for about 12 seconds on one of the
ports, just the transmission, the reception keep going with no problem.
No characters get lost when the transmission is frozen, they get
transmitted
after the 12 second period elapses.
It happens on all of the ports at random, but I didn’t see it happen on
two
ports at the same time.
I’m almost sure than the problem is not in my program, nor in the card.
Any suggestions?
Is there information available about the scope of the problem? (QNX
versions, environmental/configuration issues that trigger it, etc.)
I’d kind of like to know whether my products have a time bomb that I haven’t
yet uncovered.
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net
“Jeff Howles” <> mario_carminatti@hotmail.com> > wrote in message
news:c0edpk$g49$> 1@inn.qnx.com> …
I’m using Momentics 6.2.1B on a x86 PC with a 8 port serial card.
I’m using devc-ser8250 and everything works OK most of the time.
But sometimes transmission is frozen for about 12 seconds on one of the
ports, just the transmission, the reception keep going with no problem.
No characters get lost when the transmission is frozen, they get
transmitted
after the 12 second period elapses.
It happens on all of the ports at random, but I didn’t see it happen on
two
ports at the same time.
I’m almost sure than the problem is not in my program, nor in the card.
Any suggestions?
From my understanding there are some UARTS which have bugs in them, and
require some workarounds. I don’t have the details as it’s outside of my
pervue - but I’ll speak to some people and see if we can get it posted to
developers corner for others to try out.
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>
Is there information available about the scope of the problem? (QNX
versions, environmental/configuration issues that trigger it, etc.)
I’d kind of like to know whether my products have a time bomb that I
haven’t
yet uncovered.
Thanks,
Marty Doane
Siemens Dematic
“Adam Mallory” <> amallory@qnx.com> > wrote in message
news:c0fvqj$q74$> 1@inn.qnx.com> …
AFAIK this is already a known issue and has been addressed. Contact
your
support with your support plan# or your sales rep in order to get a fix.
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net
“Jeff Howles” <> mario_carminatti@hotmail.com> > wrote in message
news:c0edpk$g49$> 1@inn.qnx.com> …
I’m using Momentics 6.2.1B on a x86 PC with a 8 port serial card.
I’m using devc-ser8250 and everything works OK most of the time.
But sometimes transmission is frozen for about 12 seconds on one of
the
ports, just the transmission, the reception keep going with no
problem.
No characters get lost when the transmission is frozen, they get
transmitted
after the 12 second period elapses.
It happens on all of the ports at random, but I didn’t see it happen
on
two
ports at the same time.
I’m almost sure than the problem is not in my program, nor in the
card.
Any suggestions?
In QNX4 Dev.ser sources there is a function (test_tx) which gets called on
every rx or line status change interrupt and test if a tx interrupt was
lost, just look at the comments in async.c.
In QNX6 this test is missng. I’ve added this on devc-ser8250 and the problem
seems to have dissapeared.
Is there information available about the scope of the problem? (QNX
versions, environmental/configuration issues that trigger it, etc.)
I’d kind of like to know whether my products have a time bomb that I
haven’t
yet uncovered.
Thanks,
Marty Doane
Siemens Dematic
“Adam Mallory” <> amallory@qnx.com> > wrote in message
news:c0fvqj$q74$> 1@inn.qnx.com> …
AFAIK this is already a known issue and has been addressed. Contact
your
support with your support plan# or your sales rep in order to get a fix.
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net
“Jeff Howles” <> mario_carminatti@hotmail.com> > wrote in message
news:c0edpk$g49$> 1@inn.qnx.com> …
I’m using Momentics 6.2.1B on a x86 PC with a 8 port serial card.
I’m using devc-ser8250 and everything works OK most of the time.
But sometimes transmission is frozen for about 12 seconds on one of
the
ports, just the transmission, the reception keep going with no
problem.
No characters get lost when the transmission is frozen, they get
transmitted
after the 12 second period elapses.
It happens on all of the ports at random, but I didn’t see it happen
on
two
ports at the same time.
I’m almost sure than the problem is not in my program, nor in the
card.
Any suggestions?
In QNX4 Dev.ser sources there is a function (test_tx) which gets called on
every rx or line status change interrupt and test if a tx interrupt was
lost, just look at the comments in async.c.
In QNX6 this test is missng. I’ve added this on devc-ser8250 and the problem
seems to have dissapeared.
Interesting. In QNX6 there is a timer for this purpose.
Eduard.
P.S. I’d appreciate very much if QSSL find it possible to share details
on this UART’s bug and public fix somewhere. I am not surprised, it seems
modern chips have no silicon inside, but insects
You’re right, there is a timer.
It’s a byte counter with a 50ms decrement period, about 12 seconds for a
full cycle, which is the time that transmission gets frozen.
The timer is also present in QNX4, besides the tx interrupt test.
In QNX4 Dev.ser sources there is a function (test_tx) which gets called
on
every rx or line status change interrupt and test if a tx interrupt was
lost, just look at the comments in async.c.
In QNX6 this test is missng. I’ve added this on devc-ser8250 and the
problem
seems to have dissapeared.
Interesting. In QNX6 there is a timer for this purpose.
Eduard.
P.S. I’d appreciate very much if QSSL find it possible to share details
on this UART’s bug and public fix somewhere. I am not surprised, it seems
modern chips have no silicon inside, but insects >
You’re right, there is a timer.
It’s a byte counter with a 50ms decrement period, about 12 seconds for a
full cycle, which is the time that transmission gets frozen.
The timer is also present in QNX4, besides the tx interrupt test.
I can’t really comment on the fix since I didn’t do it - but AFAIK, the work
around was present, but wasn’t triggered due to some logic issues in io-char
lib.
If an official fix is required, you need to go through the your sales rep or
with support (and a support plan). If an experimental build is fine, I’ll
see what I can do about getting something posted to developers corner.
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>
Adam, thank you for your response.
I’m contacting our sales representative in order to see if she could get us
the official fix We dont have any support plan.
In the meantime it would be great if you post the experimental build
somewhere.
Thanks again,
Gonzalo.
“Gonzalo Casas” <> nadie@ningunlado.com> > wrote in message
news:c0hhks$6kj$> 1@inn.qnx.com> …
You’re right, there is a timer.
It’s a byte counter with a 50ms decrement period, about 12 seconds for a
full cycle, which is the time that transmission gets frozen.
The timer is also present in QNX4, besides the tx interrupt test.
I can’t really comment on the fix since I didn’t do it - but AFAIK, the
work
around was present, but wasn’t triggered due to some logic issues in
io-char
lib.
If an official fix is required, you need to go through the your sales rep
or
with support (and a support plan). If an experimental build is fine, I’ll
see what I can do about getting something posted to developers corner.
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net
Adam, thank you for your response.
I’m contacting our sales representative in order to see if she could get
us
the official fix We dont have any support plan.
In the meantime it would be great if you post the experimental build
somewhere.
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>
“Gonzalo Casas” <> nadie@ningunlado.com> > wrote in message
news:c0is3v$bk7$> 1@inn.qnx.com> …
Adam, thank you for your response.
I’m contacting our sales representative in order to see if she could get
us
the official fix We dont have any support plan.
In the meantime it would be great if you post the experimental build
somewhere.
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net
You’re right, there is a timer.
It’s a byte counter with a 50ms decrement period,
You’re right, accordingly to timer.c from io-char library it has 50ms
interval. Accordingly to io-char.h (struct ttydev_entry) this is a ‘char’
type. And finally, accordingly to tto.c from devc-ser8250 driver source,
every time when driver sends byte to THR it sets up tx_tmr to 3. So, time
out should be 150 ms.
about 12 seconds for a
full cycle, which is the time that transmission gets frozen.
However, it looks like might be some interference or bug. Personally, I
don’t like that timer counters compared against 0 in timer_tick()
function (io-char library). I usualy use
if(tmr_cnt<0)
{
//timer expired, do something about it
}
The timer is also present in QNX4, besides the tx interrupt test.
You’re right again. And timer initialization when sending byte is inside
of the brackets _disable() … _enable()
Does this problem exist on SMP systems or on single CPU also?
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>
“Gonzalo Casas” <> nadie@ningunlado.com> > wrote in message
news:c0is3v$bk7$> 1@inn.qnx.com> …
Adam, thank you for your response.
I’m contacting our sales representative in order to see if she could get
us
the official fix We dont have any support plan.
In the meantime it would be great if you post the experimental build
somewhere.
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net
