10 Replies Latest reply on Jan 3, 2013 1:09 PM by JoMe_264151

    LED Module


      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.

        • 1. Re: LED Module

          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!



          • 2. Re: LED Module

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


            Designer staff to implement inb a release.




            Regards, Dana.

            • 3. Re: LED Module

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

              • 4. Re: LED Module

                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?





                • 5. Re: LED Module

                  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.

                  • 6. Re: LED Module

                    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.







                    • 7. Re: LED Module

                      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.

                      • 8. Re: LED Module

                        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.

                        • 9. Re: LED Module

                          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.

                          • 10. Re: LED Module

                            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.