I have tried using Counter, Timer and PWM components of PSoC3 in my development project. I find there is a same problem:
Only a lower byte of the uint16 period works properly when I use XXX_WritePeriod(uint16 Period) for Counter, Timer or PWM. If the uint16 period's value is larger than 0xFF, the higher byte of uint16 period 'value is going to overflow to the lower byte( for example, XXX_WritePeriod(0x0100) is to work as exactly same as XXX_WritePeriod(0x01) ). However, the configuration values of the Period in these components without using XXX_WritePeriod(uint16 period) to change the period value, they work properly.
Is it possible that the components of Counter, Timer and PWM have some bugs in PSoC Creator 2.0?
Could you please advise me how to sort out this problem?
Solved! Go to Solution.
I can not open your example code. The error message is
prj.M0051: Unable to open the workspace "C:\Documents and Settings\qingshan\My Documents\PSoC Creator\WritePeriod\WritePeriod\WritePeriod.cywrk": (Unexpected xml node type encountered: workspa, expected: CyGuid_). Address the error and try again.
Could you please advise me how to sort the problem above?
I just downloaded my project from the link above and successfully opened it in PSoC Creator 2.0 on a different machine from which it was created by me. I do not have the lightest clue, what the cause for your errormessage might be. I would try to download once more and try to save it aside from any personal folder, for instance in a self-created folder C:\Cpypress PSoC\Psoc3.
Together with your original description of errorneous behaveour of Designer 2.0 I would try a complete de-installation, download of the latest version and re-installation (though that will take some time...).
Sorry not beeing able to help you better
PS: Anyone else here having problems to open the project with Designer 2.0? Please have a try!
No problem for open your example project now after reinstalled PSoC Creator 2.0. Many thanks.
However, how can I know that the timer works properly from your example project? Your design & code in your project did not implement an real application.
void Get_Parameters(uint8 buf)
//Obtain the pameters from USB Endpoint for
//setting pump drive and LED on duration.
// buf -- data buffer for holding parameters
// length -- total number bytes of parameter data
uint8 cmdID = buf;
if(cmdID == COMMAND_SET_PARAMETER )
PUMP_ON_DUTY = (buf << 😎 + buf;
PUMP_PERIOD_TIME = (buf << 😎 + buf;
//Set pump PWM Pulse On/Off duty time (in ms)
PUMP_ON_OFF_CYCLES = (buf << 😎 + buf;
LED_ON_MS = (buf << 😎 + buf;
//Set LED counter time (in ms)
extern uint16 LED_ON_MS;//in ms
//Initilise multiplexer to an NC (without LED connection).
//set mutilplexer connect to NC(without LED connected)
// start clock & counter
void Set_LED(uint8 LEDno)
//Set LED on.
// LEDno -- which LED
//Set LED DeMux control register
//Set LED control register "high"
/* Place your Interrupt code here. */
/* `#START isrLED_Interrupt` */
/* `#END` */
/* PSoC3 ES1, ES2 RTC ISR PATCH */
#if(CYDEV_CHIP_FAMILY_USED == CYDEV_CHIP_FAMILY_PSOC3)
#if((CYDEV_CHIP_REVISION_USED <= CYDEV_CHIP_REVISION_3A_ES2) && (isrLED__ES2_PATCH ))
I used the debugger to check the values (written to and read from) andeverything works as expected.
PS:Are your Timers 16 bit wide?
Oh, I see:
I presume that buf is an array uf unsigned char and your result is an unsigned int16 (uint16)
then the term (buf << 😎 is an unsigned char as well and the upper bits will be dropped (shifted out). At last it will be expanded to a 16 bits result, but the bits are already lost.
(((uint16)buff) << 😎 | (uint16) buff
or even write a macro for that
Yes, that's the issue. Another option is to make buf[ ] array and every other variable unsigned 16 bits.
Standard C requires all intermediate calculations to be done using the width of an int. For the 8051 this can be very ineffecient since all the math would be done in 16-bit format. To make for practical performance and code size the computations by default are done using the size of the values in the expression. The type casting that was suggested is the right way to handle this. It is possible to tell the Keil compiler to use the standard C rules: Build Settings->Compiler->General->Integer Promotion set to True. I don't recommend this approach, but this should make it clear that the compiler is specifically disabling the ANSI integer promotion rules.
Hi guys, many thanks for your help me sorting the problem out. Particularly thanks to Bob for his pointing out the exact bugs in my codes.