Not a workaround, but working
#define On 1
#define Off 0
LED_Switch() already takes into account the defined active-low or high connection of the LED and will always turn it on when used with an argument != 0.
Happy New Year to everybody!
Looking for a callable API under program control. Again trying to get
Designer staff to implement inb a release.
"LED_Switch() already takes into account the defined active-low or high connection"
I may not have described this adequately. I want under SW control an API that allows
LED_Switch() or LED_On()..... to be sensitive to a variable, under SW control, defining
what the active state is.
This is a trivial problem to code, just was a suggestion for a API release.
Oh, Dana, now I see what you are thinking of.
Since LED connection as active-high or low is a hardware design fact I think that Cypress's philosophy was to have code generated for the two possibilities at compile-time instead of checking at runtime what the case might be. The former could probably use less RAM and less flash than checking.
May I ask what the configuration is you need the API for?
Bob, just user choice. I already have done the workaround, just posted
as a suggestion for the tools guys for a future release.
That's good a idea but as bob pointed out it would need more (not much though) RAM//ROM. And more over in typical and most applications - user knows whether his LED is active high or active low. Even if he changes the design at a later stage, it is not going to be like dynamic change in runtime, where you need to control the active state from SW.
But yeah I already have implemented something which will detect LED's active state at startup (can also be modified to do periodic check) and then decide the logic accordingly. Example 1 of the Application Note - AN2094 discusses this. But I intended that example to demonstrate PSOC's capability to change Drive Modes dynamically.
Thanks for the replies.
Regarding point about taking more RAM/ROM, if user does not
use an API to implement this, would not compiler optimize it
out ? Hence no additional ROM/RAM if un-used ?
An example of an application is a PID controller, like Temp, where
one user to another their logic is inverted. So you are selling into an
end market where both user requirements need to be met.
As you point out easily handled in reg writes and code, but thought is
just an easy upgrade to designer that yields more flexibility for the
module. In fact another useful capability is ability to handle paralleling
of pins to increase drive capability, with additional api's to manage.
Just a thought. Making GPIO more useful and easy to use......
One last thought MSUR, this module was incorrectly named, eg LED module,
should have been GPIO module. It has the decided advantage of ease of
use, no shadow register setup by user (already done by module APIs).
Makes one wonder how many Calls Cypress has had over the years on
general GPIO register writes because user had not stumbled onto shadow
Consider a release be done of Designer with a GPIO module that in background
calls on LED module APIs, no need to re-invent the wheel.
THAT, Dana is a very good suggestion that i will support! I do not know how often I suggested PSoC1 users who have got stuck when trying to access a port pin to use the LED-usermodule. When I could convince them they were satisfied. Having a bit more support for port pins as in Creator would overcome for the PSoC starters one of the initial difficulties.