In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Sparks-R-Fun wrote: datacps, You want to accomplish a lot! As far as I can tell everything you want to accomplish with the SX should be within its capabilities. I do not recall if you are using an SX48. If not, you might want to consider using one since it has two independently running hardware timers as well as twice the internal memory and more I/O pins than the SX28. However, I will assume for now that you are using an SX28 and will not discuss the use of the SX48 hardware timers. First, as I noted in my opening comment, you are trying to accomplish a lot! It seems that you have already made a good deal of progress. However, since your delays are not working properly you will need to reduce your program down to its fundamental parts. I suggest that you begin verifying the operation of subsections whose functionality may be in question. For example, do you know for certain that you can change the value of a variable simply by rotating your encoder? If not, you might have a problem with your encoder logic. If you can verify that the encoder is altering the value of a variable in the desired way, then look elsewhere for a problem. Can you alter the pulse delays programmatically with hard-coded statements or a FOR.NEXT loop? If not, there may be a problem with how you are trying to process the delays. However, if you can change the delay programmatically and your encoder subroutine is actually changing the variable correctly you may need to look for other statements or subroutines that might alter or reset your delay value. [RED][B] I think it will serve you well to separate each individual part of the program and verify its operation.[/B][/RED] Sometimes each part works separately but the system fails to function as a whole. When that happens you know you need to look at the interactions between various parts but at least you know that each part works. [QUOTE="datacps"] Can I change the ISR rate with an encoder to control my pulse out speed?????? [/QUOTE] The direct answer to that question is NO. I am not aware of any way to change the interrupt rate aside from reprogramming the device. However, you can check a counter during each interrupt. If it is not time to do anything, simply update the counter and return. So you can achieve a very similar effect. With all that you are trying to do, I am going to recommend that you consider a slightly different approach and do almost all of your signal processing inside the interrupt. but not yet. First verify that the separate parts of your program are operating properly. When you are ready to restructure your program give careful consideration to how quickly you need your fastest signal response to be. That value or something a little faster will be the basis for your interrupt rate. In your case, 800Hz might be the fastest you will need to process signals to support a 400Hz motor especially since a hand-turned encoder probably will not alter its state very quickly. If you need a greater interrupt rate for PWM then use it as your base rate. The key is to handle your fastest signal changes and then relate all other time-based signal processing tasks to that fast rate. [GREEN][B] Inside the ISR...[/B][/GREEN] I think you will eventually want to handle three things within your interrupt service routine. You will want to check for a change in your encoder position and alter a variable accordingly. You will want to alter any output signals if it is time to do so. You will also want to keep track of how many interrupt time intervals have occurred. A typical way to do this is by adjusting one or more counter variables. I suggest that you leave the main code to operate the LCD and perform other non-time-critical tasks such as reading from or writing to an EEPROM, etc. The PAUSE command is useful but because of the number of things you are trying to have happen nearly simultaneously I think you need to abandon it and handle all of your signal timing directly in an ISR. Use interrupt-based counters and leave the PAUSE statements for things like the LCD that can run in the main program loop. Obviously I did not solve your problem. You will need to narrow down your trouble location a little more or possibly repost your code. I recommend that you focus on getting the various parts working separately and then concentrate on combining everything together once the various subsections are known to work. If I have not been very clear or you need more information, just let me know. - Sparks ---------- End of Message ---------- You can view the post on-line at: http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=226156#m228499 Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2007 (http://www.dotNetBB.com)