Dimming while receiving serial

[Adam]

I commented out the hserin line, and put some code in its place to flash a led when a serial interrupt occurs (I fiqured I better get interrupts to work before I try and read the serial buffer)

 

[Nigel Goodwin]

I commented out the hserin line, and put some code in its place to flash a led when a serial interrupt occurs (I fiqured I better get interrupts to work before I try and read the serial buffer)

Please post the code you added!.

 

[Adam]

@ device INTRC_OSC_NOCLKOUT
cmcon = 7


DEFINE HSER_RCSTA 90h
DEFINE HSER_TXSTA 20h
DEFINE HSER_BAUD 2400

Include "modedefs.bas"
TRISB = %01000000
RCSTA=%10010000 
PIR1=%00000000 
PIE1=%00100000 
INTCON = %11000000

On interrupt goto lemon


i var byte
aval var byte
bval var byte
cval var byte
dval var byte
eval var byte
fval var byte
gval var byte
hval var byte

aval = 1
loop:
if aval > 0 then
  high portb.2
endif
for i = 1 to 255
pauseus 50
if i = aval then
   low portb.2
endif
next i

goto loop

lemon:
disable
high portb.2
pause 500
low portb.2
PIR1=%00000000 
'HSERIN [aval, bval, cval, dval, eval, fval, gval, hval]
enable
resume

END

 

[Nigel Goodwin]

You've got a 'pause 500' in the interrupt routine - while the interrupt routine is sat waiting for half a second your LED's will be ON or OFF (depending on their state when the interrupt was called) - having the LED ON for half a second is going to make your PWM look like permanently ON.

Your interrupt routine needs to be as short as possible, it certainly shouldn't have any delays in it.

 

[Adam]

I know that, the point of that is as a test to see if the interrupt works, I know full well that when it does that it will make a mess of the dimming, but the problem is that the dimming is a mess before there is any reason for an interrupt to occur, so why is the interrupt occuring when nothing has been sent?

 

[Exo]

Do some tests to examine the interrupt behaviour.

Try to find out what interrupt triggers the interrupt routine by testing the flags. normally, this could only be the usart interrupt, because you masked out the others, but there's no way to be sure with this basic compiler adding it's own filth to the code...

Then, if it is the usart interrupt, find out how it gets triggerd and how many times. There could be just 1 spontanious interrupt triggered by the usart beeing configured - if this is the case, a well written interrupt/packet reception routine will automatically ignore the byte.

One thing to try is setting up the usart by yourself by writing the required values to the registers directly and not using predefined basic routines to do so (like DEFINE HSER_BAUD 2400).