LED Module

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

cross mob
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

Handy for general purpose logic controlled output, it would be nice

   

if there was one additional API call associated with module, to be

   

able to switch the active state under SW control. so LED_On(), pin

   

is high, active, if the API to set the state was to set active state to a

   

high. And vice versa LED_On(), pin is low, active, if the API to set the

   

state was to set active state to a low.

   

 

   

Just a suggestion, not looking for a workaround.

   

 

   

Regards, Dana.

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

Not a workaround, but working

   

#define On 1

   

#define Off 0

   

 

   

LED_Switch(On);

   

LED_Switch(Off);

   

 

   

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!

   

Bob

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

Looking for a callable API under program control. Again trying to get

   

Designer staff to implement inb a release.

   

 

   

Regards, Dana.

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

"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.

   

 

   

Regards, Dana.

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

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

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

Bob, just user choice. I already have done the workaround, just posted

   

as a suggestion for the tools guys for a future release.

   

 

   

Regards, Dana.

0 Likes
MeenakshiR_71
Employee
Employee
100 likes received 50 likes received 25 likes received

Hello Dana,

   

 

   

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.

   

 

   

Regards,

   

MSUR

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

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 ?

   

 

   

Regards, Dana.

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

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......

   

 

   

Regards, Dana.

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

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

   

register requirements.

   

 

   

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.

   

 

   

Regards, Dana.

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

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.

   

 

   

Bob

0 Likes