Instant Interrupts and HSERIN

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

Code:

---

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:

Code:

---

@  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:

Code:

---

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

Code:

---

@  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 :)

Quote:

---

Originally Posted by skimask

Code:

---

@  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

Quote:

---

Originally Posted by Rob

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.

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 ...

Code:

---

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>

Quote:

---

Originally Posted by skimask

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

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

Rob,

Have you tried the str with hserin? Hserin[str time\7] will (should,) grab seven bytes, I've used this with Darrel's Instant Interrupts to capture over forty bytes without problem.

Jerry.

Quote:

---

Originally Posted by Darrel Taylor

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:

Code:

---

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

---

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

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.

Quote:

---

Originally Posted by 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.

---

Aha! Good call! Which is one of the possibilities I haven't explored....I don't use an ICD...well, I do, but it's basically ON DEBUG with a serial LCD backpack...Invaluable...everybody should have one....maybe two...

Hi Darrel,

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

Quote:

---

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!

Quote:

---

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 ...

Code:

---

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:

Code:

---

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)

Quote:

---

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

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

Of course, you can use it to your hearts content.

The only thing I ask of anyone is....
"Don't remove my name and act like you wrote it."

Not saying you would, that's just my only rule.<hr>
Thank you for the offer of donation.

I really don't need the money, but if you wanted to make me feel like my program was worth it ...
Find you're local school for blind children. Every city has at least one.
Toss them a few bucks. Doesn't have to be alot.

Show me the receipt, and I'll rewrite your program for you, because it's still got some problems to be worked out in that RX handler. :)
<br>

Quote:

---

Originally Posted by Darrel Taylor

Of course, you can use it to your hearts content.

The only thing I ask of anyone is....
"Don't remove my name and act like you wrote it."

---

Thanks very much! Rest assured - I won't remove your name from it - you deserve massive credit for the hard work you've put into it!

Quote:

---

I really don't need the money, but if you wanted to make me feel like my program was worth it ...
Find you're local school for blind children. Every city has at least one.
Toss them a few bucks. Doesn't have to be alot.

Show me the receipt, and I'll rewrite your program for you, because it's still got some problems to be worked out in that RX handler. :)
<br>

---

I REALLY WILL have a look for our local school for blind children (not because I want you to re-write my program though!).

Thanks again

Rob

That has to be one of the most kind hearted things I've heard in a long time. Just confirms what I've always thought you were like Darrel..;o}

I will make an offer here too since kids are my favorite people. Fax or email me a copy of this, along with proof-of-purchase for PBP (gotta do the distributor thing you know), and I'll make sure you receive the next 2 new releases of PBP on CD free of charge.

Just let me know which new version you want, and it's on the way..;o}

P.S. Darrel will also get 2 new releases.

Hmmm, the Taylor Reynolds 3rd party charity foundation.

Kind of a ring to it. :)

If only it would work.
<br>

Quote:

---

Originally Posted by Bruce

That has to be one of the most kind hearted things I've heard in a long time. Just confirms what I've always thought you were like Darrel..;o}

I will make an offer here too since kids are my favorite people. Fax or email me a copy of this, along with proof-of-purchase for PBP (gotta do the distributor thing you know), and I'll make sure you receive the next 2 new releases of PBP on CD free of charge.

Just let me know which new version you want, and it's on the way..;o}

P.S. Darrel will also get 2 new releases.

---

Hi Bruce,

That's an extremely generous offer from you. I have donated to the Royal London Society for the Blind (RLSB).

I only donated £20.00 but if this is enough for you to do a single release of PBP upgrade then I'd like you to give it to Darrel please - I will send you the email receipt for this to the email on your signature.

You've also earned Mecanique some money today as I thought while I've got my wallet out it's about time that I bought a copy of PBP for myself - now I can use it at home as well as at work! (I don't think my wife will like you for that though!) I can't wait to do all the little projects that I've been promising myself that I will do at home!

Rob

That's hilarious.

Might have worked better if you bought PBP from Bruce, instead of Mecanique. :)
But, that wasn't the point of the exercise.

And, the main point was executed (minus receipt) so you qualify for a rewrite from me, or simply more help if you prefer.

Thanks for the donation!

Best regards,
Darrel

Quote:

---

That's an extremely generous offer from you.

---

I think generosity is all over the place in this thread, and for sure not just from me.

What goes around, comes around. If you can help someone, just do it. It all comes right
back to you at some point.

I still think Darrel has the hard part, (since now he's writing code for you that's guaranteed
to work) but he's got the next 2 PBP upgrades coming gratis for the effort. Thanks to you.

If it helped make a sale for Dave at Mecanique, I couldn't be happier. Dave has done a
lot over the years for PBP users with MCS and MCS+, and he well deserves it. And
you probably saved a £ or 2 on shipping charges..;o}

Quote:

---

I only donated £20.00

---

It's not the amount that matters. It's the fact that you did it willingly, and cared enough to
do it.

In my book, this worked out to be a win-win situation for everyone invloved, and was well
worth the minimal effort.

And now we have yet another registered PBP user (insert Darrels' WOOHOO graphic
here)..;o}

Hi Darrel,

I thought you were joking with your offer to re-write my code. I do like to have a stab at things myself but I would very much appreciate a hand with the RX handler if you don't mind taking a quick look please?

I've got it very simple at the moment but I realise that this code only works correctly if I know exactly how many databytes I am going to receive:

<font color="#000080"><i>'****************************** *************************************************
'RX Interrupt Handler: Get Time
'************************************************* ******************************

</i></font>GetTime:

' Databyte START 0 1 2 3 4 5 6
' $FD SS MM HH DD MM YY YY

</i></font><b>HSERIN </b>100,Timeout, [DataByte(0), <b>STR </b>DataByte\7]

</i></font>DataReceived = Yes

<font color="#008000">@ INT_RETURN


</font>Timeout:

DataReceived = No

<font color="#008000">@ INT_RETURN</font>


If you need the whole code I can do so by attachment - although I'm afraid everyone would laugh at me ;-)

Thanks very much

Rob

I can't seem to receive 8 bytes. I've looked at this post, but still can't solve the problem. The LED is not toggling. If I set to 5 bytes, no problem.
I've enable rx int in the main loop after I have process the data.

Code:

---

DEFINE OSC 20
datain var byte[8]
DEFINE HSER_BAUD 9600 ' Select the baud rate
DEFINE HSER_RCSTA 90h ' Enable serial port & continuous receive
DEFINE HSER_TXSTA 24h ' Enable transmit, BRGH = 1
DEFINE HSER_SPBRG 129 ' 9600 Baud @ 20MHz, 0.16%
DEFINE HSER_CLROERR 1 ' Clear overflow automatically 


Int_RX:

 HSERIN 100, Timeout, [ STR datain\8]

@    INT_DISABLE  RX_INT
toggle LED

@ INT_RETURN   

Timeout:          'serial timeout

@ INT_RETURN

---

The way the above is written, bypass most/all DT's INT call convention.

Could you post your Whole code, PIC model and Configuration fuses?

A small description of what you want to do would also be great.

I think the main loop is taking too long, hence the serial interrupt can't receive all 8 bytes properly. Still trying to reduce the serial processing time in main loop.

Quote:

---

Originally Posted by Pic2008

I think the main loop is taking too long,...

---

Could be, but it won't affect Instant Interrupts. It doesn't pay any attention to what the main loop is doing. Unlike ON INTERRUPT.

But if there was something in the main loop.
Like Steve may have hinted ...

Can't say without more information/code.

Gimmee gimmmee ....
<br>

Note that in the Int_RX ISR, the INT is disabled.
In the main loop, I will check the serial data whether the serial data match a predefined format before it is enabled again in main loop. I didn't use any pause for this serial data checking, I want it to check all 8 bytes before determining which command to execute. I use RB INT, but this INT is not trigger during serial comm. I also use ADC in main loop with PAUSE.

One thing I'm not really sure is how does "HSERIN 100, Timeout, [ STR datain\8]" really work in ISR? From this thread, it said it receive 2 bytes, this means ISR need to execute another 3 times to receive 8 bytes completely?
If the packet size is always 8 bytes, declaring datain as 8 bytes is sufficient right?

I remembered if PC send 8 bytes to PIC, the LED is not toggle, meaning this Int_RX ISR is not trigger at all.

Should I use "@ INT_DISABLE RX_INT" in ISR or main loop? When is the proper time to enable RX_INT again?

After going through the code over and over again, I still can't find the problem until my colleague check her application code which sends the 8 bytes. There is a bug from her application.

Now, the problem is solved, PIC confirmed can receive 8 bytes using DT interrupt.

Thanks for all the guidance.