Trying to fix that last bug in my SX/B prorgam and need another set of eyes. (
RobotWorkshop
Posts: 2,307
Hello,
I am stuck at the moment and could really use some help from the rest of you on the forum. At the moment there is one elusive bug in my program that has been driving me crazy trying to find. Another set of eyes could really help. Either I am overlooking the same problem over and over, missed something special in the SX datasheets and documentation, or have just run into some unexplained quirk using SX/B on the SX48. Whatever it is I would like to get this figured out so I can get onto some of the other aspects of my project.
I've attached the program so that anyone with an SX48 could try it or you can at least look over the code for any glaring oversights.
The program is relatively simple. It uses JonnyMac's ISR based serial routines to receive serial characters (On RA.2) and buffers them in the background. The ISR also checks an encoder connected to port B (pins 0 and 1) and an opto on pin 2 for the center position. If there is any change of the encoder it will update encValue accordingly. If it sees the "Center" it will reset encValue to 0. 0 is the center and is what I was basing the movements from.
There is a motor connected to RB.6 for the Speed (driven by the TIMER1 PWM) and direction set by RB.5 These two pins just go to an L298 H-Bridge. Other than that some LEDs are wired up which have been useful for diagnostics.
The Main program loop should check to see if any commands come in and address them as they show up. Once that is done (or if none come in) it should go on to control the motor. If there is an active movement going on it will see if it is done and end it is so. If not it will adjust the PWM and keep it going.
The program starts up fine but I get one unexpected problem that is throwing off the whole thing. I found this by turning on an LED upon entering RX_BYTE and turning it off as it leaves that function. Upon normal operation I should barely see that LED flicker and only when I am actively sending data to the SX48 via the serial line. The LED is off when it powers up but if I turn the head (which makes the encoder change) for some reason it gets to RX_BYTE and just hangs there. This is a huge problem since while it's there waiting for a character it is NOT updating the PWM for the motor. Since I check rxBufCnt to see if there is anything there before calling RX_BYTE I can't figure out how it is getting there.
So, either I have a mistake that I keep overlooking or something deeper is going on. For a moment I thought that perhaps since the encoder is on port B that it might be generating extra Interrupts. Even if that was the case I would have expected that it would just receive a garbled character (as was happening early on with the TIMER1 TIMER before disabling those Interrupts). Getting a garbled character isn't a problem since it would just return from RX_BYTE and it would be thrown away. The problem is how/why is it getting to RX_BYTE when there isn't a character in there to read?? Jon, if you happen to read this have you ever run into a problem like this and could this be another reason why you added an rxReady to the latest version of your code?
Another troubleshooting test was to uncomment the two lines after MAIN to just display what was received and display then jump back to MAIN. As far as I can tell it always receives the codes correctly from the host.
Any ideas? Pointers? Suggestions?
I had thought about possibly moving some of the code for the motor PWM to the ISR and would have to make sure it all gets done well before the next ISR cycle comes through. That may be an option but it still doesn't explain why the program ever gets to RX_BYTE and waits when it shouldn't have ever gotten there unless a character was waiting.
Best Regards,
Robert
Post Edited (RobotWorkshop) : 3/1/2008 8:33:21 PM GMT
I am stuck at the moment and could really use some help from the rest of you on the forum. At the moment there is one elusive bug in my program that has been driving me crazy trying to find. Another set of eyes could really help. Either I am overlooking the same problem over and over, missed something special in the SX datasheets and documentation, or have just run into some unexplained quirk using SX/B on the SX48. Whatever it is I would like to get this figured out so I can get onto some of the other aspects of my project.
I've attached the program so that anyone with an SX48 could try it or you can at least look over the code for any glaring oversights.
The program is relatively simple. It uses JonnyMac's ISR based serial routines to receive serial characters (On RA.2) and buffers them in the background. The ISR also checks an encoder connected to port B (pins 0 and 1) and an opto on pin 2 for the center position. If there is any change of the encoder it will update encValue accordingly. If it sees the "Center" it will reset encValue to 0. 0 is the center and is what I was basing the movements from.
There is a motor connected to RB.6 for the Speed (driven by the TIMER1 PWM) and direction set by RB.5 These two pins just go to an L298 H-Bridge. Other than that some LEDs are wired up which have been useful for diagnostics.
The Main program loop should check to see if any commands come in and address them as they show up. Once that is done (or if none come in) it should go on to control the motor. If there is an active movement going on it will see if it is done and end it is so. If not it will adjust the PWM and keep it going.
The program starts up fine but I get one unexpected problem that is throwing off the whole thing. I found this by turning on an LED upon entering RX_BYTE and turning it off as it leaves that function. Upon normal operation I should barely see that LED flicker and only when I am actively sending data to the SX48 via the serial line. The LED is off when it powers up but if I turn the head (which makes the encoder change) for some reason it gets to RX_BYTE and just hangs there. This is a huge problem since while it's there waiting for a character it is NOT updating the PWM for the motor. Since I check rxBufCnt to see if there is anything there before calling RX_BYTE I can't figure out how it is getting there.
So, either I have a mistake that I keep overlooking or something deeper is going on. For a moment I thought that perhaps since the encoder is on port B that it might be generating extra Interrupts. Even if that was the case I would have expected that it would just receive a garbled character (as was happening early on with the TIMER1 TIMER before disabling those Interrupts). Getting a garbled character isn't a problem since it would just return from RX_BYTE and it would be thrown away. The problem is how/why is it getting to RX_BYTE when there isn't a character in there to read?? Jon, if you happen to read this have you ever run into a problem like this and could this be another reason why you added an rxReady to the latest version of your code?
Another troubleshooting test was to uncomment the two lines after MAIN to just display what was received and display then jump back to MAIN. As far as I can tell it always receives the codes correctly from the host.
Any ideas? Pointers? Suggestions?
I had thought about possibly moving some of the code for the motor PWM to the ISR and would have to make sure it all gets done well before the next ISR cycle comes through. That may be an option but it still doesn't explain why the program ever gets to RX_BYTE and waits when it shouldn't have ever gotten there unless a character was waiting.
Best Regards,
Robert
Post Edited (RobotWorkshop) : 3/1/2008 8:33:21 PM GMT
Comments
I'm still not quite sure how the program above is ending up in RX_BYTE since it shouldn't be called unless there is something already in the buffer. With something in the buffer it should not wait at RX_BYTE.
Any ideas?
The SX/B code in the interrupt is using __PARAM1 & __PARAM2. With the NOCODE (or the NOPRESERVE) option these are not saved & restored like they need to be.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
www.iElectronicDesigns.com
·
That was it! Thank You!!! Thank You!!! That cleared up all the odd behavior and as far as I can tell everything is working just as it should. Such a simple thing cleared up everything. I have been using the LED's connected to the board to show the status of the flags and it all appears correct.
Now that the code is working it brought up one issue that I completely missed and didn't show itself until the main program started cycling through as it should. It seems to go through the loop so fast that i'm updating the TIMER value way too often. In fact, I think i'm updating so quickly that just resets both timer registers before it gets a chance to count up high enough to get to the HIGH portion of the timers cycle. I'm going to add a slight delay after I update the timer which should confirm and fix the problem.
If that does it then it should be noted in the documentation warning about a potential issue if you update the timers too often.
Best Regards,
Robert
Thanks for the help.
Robert