hi!

how do i toggle a software controlled digital outpin using setpin and clearpin APIs'?

kindly see the project attached below

 Hi Neha,

You can toggle using CyPins_SetPin(CYREG_PRTx_PCy) and CyPins_ClearPin(CYREG_PRTx_PCy) where x and y are port and pin configs which in the attached project is PRT1_PC7. (x=1,y=7)

thnx srim, thnx dana..it worked!!!

cheers :)

neha i'll suggest u

dont depend on API use basic software coding constructs

like

use delays   P[1]=0 and then gave delay again put these statements in loop to get toggling digital led or output

I am sorry, but I have to contradict your last post.

Not using APIs is a technique that will lead into a one-way-road dead-end-street.

The world is changing and so are PSoCs (there is some rumor about a PSoC4 coming). One thing that can be kept unchanged is the API for an underlying technical (hardware) function. So using APIs will prevent you from having to change your program when the outer world suddenly looks different. That might be a simple thing like a pin swapped by accident on your PCB. Everything went well on the Kit, now on frabicated pcb it won't. So change the pin. In creator when you did a good work it is only in the pins-window assigning a new value (or two if it was a swap). No API? Going trugh the program and looking up all occurences of this port- and pin-accesses and do not forget a single one. Now can you imagine what amount of program-changes you might have, when you switch from a PSoC3 to a PSoC5 when you hand-coded everything and didn't use APIs? I even find it easier to use an API for an LED-component than to use some construct to change a port pin without influencing the other pins on the same port.

You will sleep better when using APIs.

Bob

I can only second Bob with regards to the API. Use them, they make your life easier. You don't need to read so much documentation, and they avoid many pitfalls and traps for you.

However, there are two exception: if you need to access features which aren't exposed via the APIs, or if you really really need to care about performance, and the APIs provide too much overhead (which is rarely the case with PSoC, since the generated code is already streamlined for your configuration). And for the latter one, look up the two rules of Donald Knuth about performance optimizations, before you do any :)

I will contradict the API rule as follows -

1) The reason we love PSOC is its register based architecture. Finally analog meets digital

meets FPGA flexibility.

2) Coders writing APIs do not have your specific project in mind and its performance needs.

3) We love PSOC because there are APIs for the basics (contradicting my own points).

4) All of us are getting pushed competitively, exploiting HW and SW is how that gets done.

5) There are dangers in register manipulation, same is true trying to get an ice cream cone

at MacDonalds. :)

6) PSOC has a component authoring tool for the purpose of creating off the wall components.

7) PSOC has Verilog to get down to the sub register level, gates. Hoorah.

So lets walk that tightrope and memorialize the ones that fall, and laud the ones that make it :)

Regards, Dana.

Thnx sachin, Bob, hli  and danaa.

In PSoC 1 I created a h file for all the I/O ports. This let me toggle all pins. EX: P1[1] . Turm on port 1 bit 1. Can I use this type of code for the PSoC 3?

For every pin of a PSoC3 / 5 there is a #define to access it with the help of 3 macros to read, set or reset any pin (except on port 15 some pins). Have a look into the System Reference Guide (Help -> Documentation -> System Reference)

Bob 

Thank you very much for responding so quickly. I will do my homework so I can toggle the pins.

Thank You,

Philip

 Refer to the attached project for toggling the GPIO using SFRs.

Where is the attached project?

Under help, the reference guide was excelent.

Thank You,

Philip 

You are always welcome!

Bob

Attaching the project here...

Digital Pins can be toggled by using the software constructs or PWM API