I have a strange prblem with the scc-code (2.4c by dl1bke) I get garbled
data on some of the ports. I have the following setup on two different
machines.
No1
scc0 DRSI on irq7, works OK
scc1 DRSI on irq7, does not work OK
scc2 DRSI on irq5, works OK
scc3 DRSI on irq5, does not work OK
No2
scc0 BAYCOM on irq10, not in use at the moment
scc1 same as scc0
scc2 same as scc0
scc3 same as scc0
scc4 DRSI on irq5, works OK
scc5 DRSI on irq5, does not work OK
scc6 DRSI on irq5, does not work OK
scc7 DRSI on irq5, does not work OK
By "does not work OK" I mean that garbled packages are received (by
the applications! This is not nice when forwarding, receiving strange
characters in the middle of everything...)
One can see a clear trend here. The first SCC-port, on the first SCC
using the same irq, works OK, all others malfunction.
I suspect that the problem is in the interrupt handling routines.
Especially I am concerned with the following in scc_isr() (at the end)
.....
/* This looks wierd ...
.....
*/
if (scc != NULL)
{
OutReg(scc->ctrl,R0,RES_H_IUS);
ctrl = SCC_ctrl;
} else
ctrl++;
.....
I have compared this code (scc_isr()) with the one used in NOS (sccvec.asm)
and there the IUS is only reset when using intack. I.e. the code above
would become the following if we followed the NOS code:
ctrl++;
I.e. we do not reset the IUS, and do not restart by setting ctrl to
SCC_ctrl, we just traverse the scc:s.
I will try this change and see if it solves the problem.
Anyone having any comments on this?
73 de Lars, sm6rpz
(Kernel 2.0.33, ax25-utils 2.1.42a, scc 2.4c, on an Intel 486dx2-66)
-- Lars E Pettersson | Chalmers University of Technology luvpyih.tryibyc@rt-comm.ru | Gothenburg, SWEDEN