Triode
Well-Known Member
I know this isn't enough to cover the entire range of things that could be going wrong, but for now I'm just trying to figure out one detail that perplexes me. Given that this receive interrupt can get messages too quickly and jam up, why won't it unjam itself when they slow down? I'm sure it's something simple I've missed.
I was using the 9th address bit but to try to solve this problem where it drops out and quits responding I decided to just use numbers 0<n<24 as addresses, since I only need a few commands. I suspected lag in LabVIEW's serial visa changing the number of bits, but that seems not to have been the case.
Oddly, it runs fine if I send messages at less than 2 per second, this is at 19200 baud, and they're coming from a labview serial VISA over RS 485. If I start sending them faster it quits responding. But the reason it jams up isn't what I'm confused about so much as WHY it won't UNJAM itself. That is, once it stops responding it does not start again even if I slow the messages way down.
To use the commands we have this in Main
I know this is a rather simplistic scheme, but I couldn't get it to stop ceasing to respond to commands, so I kept making it simpler. I have an LED for a heartbeat that confirms that the processor is still running. This is concerning because while I can have it send a confirmation and re-send a missed message, there's not much I can do if it's going to drop off and just quit listening forever.
I can add more detail as needed, I just didn't want to flood this with the entire project.
Thanks for any help!
I was using the 9th address bit but to try to solve this problem where it drops out and quits responding I decided to just use numbers 0<n<24 as addresses, since I only need a few commands. I suspected lag in LabVIEW's serial visa changing the number of bits, but that seems not to have been the case.
Code:
[CODE]//Inside interrupt routine
if(PIR1bits.RCIF == 1)
{
if(DataRdyUSART())
{
MessageChar = ReadUSART();
//designate that values under 24 are addresses, 0 is blank
if(MessageChar < 24 && MessageChar > 0) //is address
{
if(MessageChar == MyAddress)//is my address
{
Addressed = 1;
LATB4 = 0;
}
else //is not my address
{
Addressed = 0;
LATB4 = 1;
}
}
else //is data
{
if(Addressed == 1 && MessageChar >= 24)//is my data range 24 to 254
{
MessageBuffer[i] = MessageChar; //read the byte from rx register
i++;
if(i >= 200) i = 0;//make it a cyclic buffer
}
}
PIR1bits.RCIF = 0; // clear rx flag
}
}
Oddly, it runs fine if I send messages at less than 2 per second, this is at 19200 baud, and they're coming from a labview serial VISA over RS 485. If I start sending them faster it quits responding. But the reason it jams up isn't what I'm confused about so much as WHY it won't UNJAM itself. That is, once it stops responding it does not start again even if I slow the messages way down.
To use the commands we have this in Main
Code:
while(1) //infinite loop
{
for(j = 0; j < 200; j++)//scan entire buffer
{
if(MessageBuffer[j] != 0)
{
//process the commands
{...}
MessageBuffer[j] = 0;// clear the message that was just read
}
}
I know this is a rather simplistic scheme, but I couldn't get it to stop ceasing to respond to commands, so I kept making it simpler. I have an LED for a heartbeat that confirms that the processor is still running. This is concerning because while I can have it send a confirmation and re-send a missed message, there's not much I can do if it's going to drop off and just quit listening forever.
I can add more detail as needed, I just didn't want to flood this with the entire project.
Thanks for any help!