global variable function wait loop PSOC4M

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
jepaz
Level 4
Level 4
25 replies posted 10 replies posted 10 questions asked

Hi Everyone,

Please I need some help in short this is the problem

I have a global variable

int ready=0;

int *ready_p=&ready;

a part of the program must read the value of this variable inside a function while the value is 0 it will stay on a loop waiting for the task to be finished

void line(float dx, float dy){

          ****CALCULATIONS NOT INVOLVING VARIABLE READY

     while(!*ready_p){

        ***UPDATE SCREEN WITH CURRENT VALUES

     }

}

My program features a UDB Counter Block when the counter compare triggers the ISR sequence this function Stop() is called.

void Stop(){   

    PWMX_Stop();    PWMY_Stop();     

    disableX()      disableY();

    *ready_p=1;  

}

I am not very clear about the pointers use.

I believe the function is not reading the global variable even if it is changed

to test the program I am working with UART at 115200

and I send the following code

G01 X# Y#

Where # is any number then the program should output a series of points on the path to the numbers that where introduced.

the problem is if the wait loop is not working the commands are not finished and a new one is sent on top

thanks for the help

I am using a PSOC4M pioneer kit

0 Likes
1 Solution
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

There are some pitfalls I can see.

A global variable that is changed within an interrupt handler must be declared as "volatile". Otherwise a test within a loop (as in your case) might get optimized out.

There is no need to access your variable "ready" using a pointer. You may of course test it directly as if(!ready) ...;

So use: volatile uint8 ready = 0;

Even better because better readable might be

typedef uint8 Bool;

#define FALSE  0

#define TRUE  !FALSE

volatile Bool ready = FALSE;

...and later...

if(!ready)...

...or...

Bool status()

{

     return ready;

}

Disabling the interrupt within its handler is bad practice and is not needed. There is an interrupt queuing mechanism within the ICU (Interrupt Controller Unit) that handles that.

Not quite sure which Cypress kit you are using: CY8CKIT-043?? The I2C pins are different from yours.

Bob

View solution in original post

4 Replies
jepaz
Level 4
Level 4
25 replies posted 10 replies posted 10 questions asked

Another thing I cant find an explanation to why would the program crash if I am running LCD commands in them In other programs in Psoc 42xx it worked great...

thanks

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

There are some pitfalls I can see.

A global variable that is changed within an interrupt handler must be declared as "volatile". Otherwise a test within a loop (as in your case) might get optimized out.

There is no need to access your variable "ready" using a pointer. You may of course test it directly as if(!ready) ...;

So use: volatile uint8 ready = 0;

Even better because better readable might be

typedef uint8 Bool;

#define FALSE  0

#define TRUE  !FALSE

volatile Bool ready = FALSE;

...and later...

if(!ready)...

...or...

Bool status()

{

     return ready;

}

Disabling the interrupt within its handler is bad practice and is not needed. There is an interrupt queuing mechanism within the ICU (Interrupt Controller Unit) that handles that.

Not quite sure which Cypress kit you are using: CY8CKIT-043?? The I2C pins are different from yours.

Bob

jepaz
Level 4
Level 4
25 replies posted 10 replies posted 10 questions asked

Thank you BOB,

I also found yesterday that I was not using

CyGlobalIntEnable;

so that was a larger issue.

thanks for the tips will keep working on this.

Any Ideas why would the program crash when calling LCD funtions inside a function (this same line function) some commands are commented inside the while loop. LCD works just fine on the main block

the kit I am working on is CYC8CKIT-044 kit

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

This behavour let me assume a stack problem.

And I found

sprintf(msg, "X:%.2f",Xcurr ); with msg holding 7 bytes. Can you be quite sure that Xcurr is always < 10??

The perfectly killing line is

sprintf(msg,"%.3f %.3f ",xlast,ylast); which will overwrite data even when xlast and ylast == 0.

Bob