Instant Interrupts and HSERIN

[Rob]

Hi,

I've been struggling with this for around a week so I thought I'd check here to see if anyone's got any pointers.

I am collecting some data sent once per minute serially at 9600 baud. A startbyte is sent as $FD followed by 6 bytes representing SS:MM:HH DD:MM:YY

The following code works right at the start of my program

hserin [wait ($FD), str databyte\6]

but implementing Darrel's Instant Interrupts and the RX_INT I only seem to capture 2 of the bytes of data being the MM and HH so if write:

@   INT_DISABLE  RX_INT                                ; Disable RX Interrupt 
hserin 100,timeout [databyte(1), databyte(2)]
@   INT_ENABLE  RX_INT                                 ; Enable RX Interrupt
@   INT_RETURN

where timeout just re-enables the RX_INT and then returns. I would have expected the above snippet to save the $FD and then the SS data packet so I'm not sure why it skips these two and saves the MM and HH data bytes


If I try to capture more than two bytes:

hserin 100,timeout, [databyte(1), databyte(2), databyte(3)]

the hserin just jumps to timeout every time. I am ONLY enabling RX_INT at the moment so that I could eliminate interference by any other Interrupt but this has made no difference.

Any help would be greatly appreciated

Thanks in advance

Rob

[skimask]

@   INT_DISABLE  RX_INT                                ; Disable RX Interrupt 
hserin 100,timeout [databyte[1], databyte[2]]
@   INT_ENABLE  RX_INT                                 ; Enable RX Interrupt
@   INT_RETURN

Take a quick look around the 1 and 2

[Rob]

@   INT_DISABLE  RX_INT                                ; Disable RX Interrupt 
hserin 100,timeout [databyte[1], databyte[2]]
@   INT_ENABLE  RX_INT                                 ; Enable RX Interrupt
@   INT_RETURN

Take a quick look around the 1 and 2

Hi Skimask,

thanks for the reply. I will try with square brackets tomorrow. I started using round brackets for array addressing when inside a square bracket statement, like HSERIN, a short while ago after reading a post by Darrel. I will try the square brackets tomorrow and let you know if it makes any difference

Cheers

Rob

[skimask]

Hi Skimask,
thanks for the reply. I will try with square brackets tomorrow. I started using round brackets for array addressing when inside a square bracket statement, like HSERIN, a short while ago after reading a post by Darrel. I will try the square brackets tomorrow and let you know if it makes any difference
Cheers
Rob

I just found that post myself. Weird...
The ONLY time I use round brackets is when define precedence.

[Rob]

I just found that post myself. Weird...
The ONLY time I use round brackets is when define precedence.

Yeah, I thought it was weird myself! I hope it is as simple as this but Darrel's not normally wrong.

I will update this thread tomorrow - I have to say it's frustrated me more than a rubik's cube!

Rob

[Rob]

Oops - my post just crossed with Darrel's - thanks for the replies - I will try your example tomorrow Darrel and see what's occurring (hopefully!)

Cheers

Rob

[Darrel Taylor]

Yup, Square brackets will cause an error when they are inside other square brackets.

There's no need to DISABLE/ENABLE inside the handler. An interrupt source can't interrupt itself like it would in ON INTERRUPT.

But I think what's happening is that the handler is being called multiple times before the rest of the program see's the data.

As a test, try something like this ...

hserin 100,timeout [databyte(1), databyte(2)]
@   INT_DISABLE  RX_INT                                ; Disable RX Interrupt 
@   INT_RETURN

This should return the first 2 bytes then disable the RX_INT.
The USART will overflow and stop working after that unless it is re-enabled quickly.

I'm not saying this is the way to properly receive data in an interrupt.
It's just a test to help understand what's going wrong.
<br>

[skimask]

Yup, Square brackets will cause an error when they are inside other square brackets.

Obviously, haven't checked all cases, but I've got this line with square-in-square and works ok:

lcdchardata[ lcdcharloop + 1 ] = font [ ( lcdchardata[0] * 5 ) + lcdcharloop ]

But it's also got a variable inside parenthesis...maybe that's the kicker...

[Darrel Taylor]

Following up on the Square brackets vs Round brackets ...

I honestly thought it was a PBP problem.
But with further investigation, I've found it to be a MicroCode Studio problem that only happens during an ICD compile.

Possibly first discovered by Bruce.
http://www.picbasic.co.uk/forum/showthread.php?p=23772

Which means that it only comes into play with HSEROUT/IN statements.

So I guess it's still a good idea to use Round brackets inside Square brackets, in case you ever plan on using the ICD.
But it also looks better for the programs that won't.

HTH,

EDIT: Good timing ski.

[Rob]

Hi Darrel,

thanks for your help on this one - it really had me stumped!

There's no need to DISABLE/ENABLE inside the handler. An interrupt source can't interrupt itself like it would in ON INTERRUPT.

Cool - I didn't realise that!

But I think what's happening is that the handler is being called multiple times before the rest of the program see's the data.

As a test, try something like this ...

hserin 100,timeout [databyte(1), databyte(2)]
@   INT_DISABLE  RX_INT                                ; Disable RX Interrupt 
@   INT_RETURN

This should return the first 2 bytes then disable the RX_INT.
The USART will overflow and stop working after that unless it is re-enabled quickly.

I have tried what you asked me to above and it works every time! I've got it capturing all the bytes now by:

hserin 100,timeout, [databyte(0), databyte(0), databyte(1), databyte(2), databyte(3), databyte(4), databyte(5)]
@   INT_DISABLE  RX_INT

(the duplicate; databyte(0), databyte(0), just removes the $FD as I don't need it)

I'm not saying this is the way to properly receive data in an interrupt.
It's just a test to help understand what's going wrong.
<br>

I'm now trying to re-enable the interrupt at some point after the data has been read by the rest of the program but it's not working at the moment. I will keep trying and update this thread later.

Cheers to all

Rob

[Rob]

Right, I was definitely being stupid!

There were actually 8 bytes of data being sent (the colons aren't sent nor are the spaces or slashes);

$FD SS:MM:HH DD/MM/YYYY

This meant that RCIF was being set again by the extra YY before I was doing anything with the data in my program. Thanks very much Darrel, I wouldn't have found this if you hadn't pointed me in the right direction.


Darrel, this is for a small project for my work and I was wondering if you would allow me to include your code in the finished item please? I know you've said to people in the past that they could but I thought I had better ask out of courtesy. I know you say keep the internet free, but obviously hosting your webpage costs YOU money so I wondered if you had anywhere to donate to help with these costs? I can't find anywhere on your webpage.

Cheers

Rob