This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

LPC2478 - lcd_putString Issue

Hello,

There's an expansion board attached to the LPC2478 which contains a motor and a lightgate which can count the revolutions of the motor, connected to a counter (timer1).

My program is written to enable the user to select various motor speeds and receive feedback as to what the actual motor speed is, which is printed on the display.

The display contains various lines of text explaining the program and various speeds the user can select.

Essentially the problem I have is that for every line of 'lcd_putString' that is used, it multiplies the reading of the motor revolutions. There's 12 lines of lcd_putString which are used in the initialisation code of the program to print this text to the display and then never called upon again. If I comment these lines of text out, so that nothing other than the motor speed reading is display, the motor speed is displayed correctly on the display (tested using an oscilloscope).

To put it simply, if there is text printed to the display using lcd_putString, the counter reading is multiplied.

A lot of hours have gone into trying to sort this issue so any help is hugely appreciated.

Parents
  • Not too easy to guess what your code might look like.

    You haven't told us hardly anything at all. We don't even know if you are talking about a DC-controlled motor, where the processor controls the voltage and a higher voltage gives more revolutions. Or a servo motor where you give some servo signal and the motor then have electronics to regulate the speed based on the servo signal. Or if maybe you have a stepper motor where the processor generates the stepper pulses. Or maybe you even have a synchronous AC motor and have the processor create an AC output of varying frequency?

    Next thing - we don't know anything about how your program initializes any frequencies or other critical parameters for producing the control signal(s) to the motor. And because we still don't know the type of motor or how you are controlling the speed, we don't know if the additional speed comes from a higher voltage or a changed pulse width or a changed frequency of pulses or something else.

    We further don't know how your LCD is connected, so we do not know if the LCD interface in some way may interfere with the control signals for the motor drive.

    And even if we knew all of the above, we would still not know exactly how the code is written so we could figure out if you have uninitialized variables getting different values depending on your printouts. Or if the code does some buffer overflow of some PWM data array you intended to control he motor with. Or if you incorrectly compute some parameter values you send to some processor registers.

    The most logical thing to do would be to identify all register values that should affect the motor speed. Print these register values when the program works ok (i.e. without the LCD output) and when it doesn't. Somewhere you should be able to find some difference to some values - then it's just a question of backtracking to figure out what is caused the difference. But "we" as other forum visitors can't do it - only you have access to all the relevant information.

    In the end, debugging is the process of breaking problems down into smaller pieces until each piece is simple enough that you can identify if it works or not. And if that doesn't work, try to figure out if the problem can be sliced in a different direction. And if that doesn't work, try to figure out if you can throw in some perturbations that will force the guilty sub-block(s) to reveal their flaws. But all these steps must be based on knowledge about the actual problem case - so knowledge of debugging is probably your most valuable skill to ace in.

Reply
  • Not too easy to guess what your code might look like.

    You haven't told us hardly anything at all. We don't even know if you are talking about a DC-controlled motor, where the processor controls the voltage and a higher voltage gives more revolutions. Or a servo motor where you give some servo signal and the motor then have electronics to regulate the speed based on the servo signal. Or if maybe you have a stepper motor where the processor generates the stepper pulses. Or maybe you even have a synchronous AC motor and have the processor create an AC output of varying frequency?

    Next thing - we don't know anything about how your program initializes any frequencies or other critical parameters for producing the control signal(s) to the motor. And because we still don't know the type of motor or how you are controlling the speed, we don't know if the additional speed comes from a higher voltage or a changed pulse width or a changed frequency of pulses or something else.

    We further don't know how your LCD is connected, so we do not know if the LCD interface in some way may interfere with the control signals for the motor drive.

    And even if we knew all of the above, we would still not know exactly how the code is written so we could figure out if you have uninitialized variables getting different values depending on your printouts. Or if the code does some buffer overflow of some PWM data array you intended to control he motor with. Or if you incorrectly compute some parameter values you send to some processor registers.

    The most logical thing to do would be to identify all register values that should affect the motor speed. Print these register values when the program works ok (i.e. without the LCD output) and when it doesn't. Somewhere you should be able to find some difference to some values - then it's just a question of backtracking to figure out what is caused the difference. But "we" as other forum visitors can't do it - only you have access to all the relevant information.

    In the end, debugging is the process of breaking problems down into smaller pieces until each piece is simple enough that you can identify if it works or not. And if that doesn't work, try to figure out if the problem can be sliced in a different direction. And if that doesn't work, try to figure out if you can throw in some perturbations that will force the guilty sub-block(s) to reveal their flaws. But all these steps must be based on knowledge about the actual problem case - so knowledge of debugging is probably your most valuable skill to ace in.

Children