Normally you double click any component and configure its
settings, including GPIO. Also you will see in its datasheet
(right click component) APIs to make runtime changes to
You may use functions as Pin1_Read() to read a switch and Po1_Write() to let an LED shine.
have a look into the pin's datasheet, APIs.
Thanks for the kindly supports. I made it!
The code described in the app note mentioned above does not work for me on PSoC4 pioneer board.
I tried to use it to control one of the Leds (P0_3) with the user button (P0_7).
"Use the component APIs to set the state of OutputPin based on InputPin, as shown here:
/* Set OutputPin state to the
inverse of the InputPin state */
OutputPin_Write( ~InputPin_Read() );
The result is that OutputPin is always at the opposite state as InputPin."
The ~ operator creates the complement of what was read on the
input port. But the bit position of the input pin is not same as LED
pin, so code functionaly does not work.
You have to use a mask to test input pin bit, then based on its state drive
LED to its respective on/off state. The Pioneer board turns on LEDs by
driving pin to ground, logic "0".
One other suggestion, when controling pins in a port,
generally you only modify the pin of interest. The code you
showed would keep toggling all pins.
So you use a mask on both reading the button and another mask to
write to the output pin.
In your case the basic masks look like P0_3 0b00001000 and
P0_7 0b10000000. So you would AND the mask to test the input
port pin, and either OR the output mask or AND the complement of
the output mask to set/reset the output bit.
As far as I can see the Pin_Read() function returns either 0x00 or 0x01 for a single pin component. So the Pin_Write() function should accept it without errors and work properly.
However, there might be a pitfall with interrupts, because interrupts are not disabled when calling those functions, so at least the values inside the Pin_Write() function might get corrupted when interrupts are modifying pins on the same port.
Or am I missinterpreting the Pin_Write() function?
You are quite right, Ralf. When from two different points the port data-register is accessed and one of them is within an interrupt routine the situation exists that something might go wrong. This is what the CyEnterCriticalSection() is good for, look into the System Reference Guide.
I wonder if CyEnterCriticalSection() / CyExitCriticalSection() should be called inside the pin component APIs as default. Yes, the pin component datasheet states explicitely that it's not safe to call the component API especially when ports are accessed within interrupts. And yes, it recommends that the per-pin-APIs should be used instead, which seems to be macros evaluated to atomic access instructions.
But, IMHO the question is if the software developer should always keep track which pins/ports might be affected by this. If only single pins are used, there's no difference and I agree that the per-pin-API should be preferred. However, if someone needs to output a 4-bit value for example, the per-pin-API can't be used (or it must be done bit by bit). The PSoC approach is to have independend functions, but the above seems to violate this approach.
What do you think?