Shop OBEX P1 Docs P2 Docs Learn Events
Smart Pin Red/Green LED Control Demo — Parallax Forums

Smart Pin Red/Green LED Control Demo

JonnyMacJonnyMac Posts: 8,924
edited 2020-03-15 19:07 in Propeller 2
I've used 2-pin red/green LEDs in several P1 projects, and to get yellow requires a cog. With the P2 we can use the smart pin PWM mode and invert one of the outpus. With the LEDs I have the yellow mix uses a very small fraction of red, so I'm not sure level control of yellow is possible -- but I'm still working on it.

Setup code:
pub start(r, g, rlvl, freq) | x

'' Start RG-2 LED driver
'' -- r and g are output pins
'' -- rlvl is the red level (1..127) in the yellow blend
'' -- freq is pwm frequency

  longmove(@rpin, @r, 2)                                        ' copy pins
  yrlevel := 1 #> rlvl <# 127                                   ' fix red ratio for yellow
  x := 255 << 16                                                ' set pwm period to 255 units
  x |= 1 #> ((clkfreq / 255) / freq) <# $FFFF                   ' set timing of 1 pwm unit
  pinstart(rpin, SP_PWM, x, 0)                                  ' red = true mode pwm, off
  pinstart(gpin, SP_PWM | OP_INV, x, 255)                       ' green = inverted pwm, off

This is alpha code -- use at your own risk. Please keep comments on RG LED control.

The 'scope image shows the outputs when the LED is set to yellow. The top trace is the red chip, the bottom is the green chip. Both are set to the same level, but the inverted state of the green pin changes the output.

Note: Some files in project require PNut v34n.

Comments

  • Some help please.
    I am attempting to try this code. I am getting an error in pub "pub fdec(value, digits)". I replaced the Jm_serial with the nov 2020 version and get the same error. What has changed?

    Thanks

  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2022-04-17 04:33

    I've used 2-pin red/green LEDs in several P1 projects, and to get yellow requires a cog.

    I took that as a challenge! :)

    You can do it in the P1 without an extra cog by using one of the counters in complementary DUTY mode. The trick is to add a speed-up cap in parallel with the current-limiting resistor. Otherwise, the high frequency of the DUTY mode output, combined with the RC filtering provided by the series resistor and the LED capacitance will dampen the forward voltages to the point that you can't get both LEDs to light up at the same time. Here's my program to produce yellow:

    CON
    
      _clkmode      = xtal1 + pll16x
      _xinfreq      = 5_000_000
    
    PUB start | i
    
      ctra := %0111 << 26 | 1
      dira[0..1]~~
      frqa := $5800_0000
      repeat
    

    I didn't have a two-pin bi-color LED, so I simulated one using discrete red and green LEDs hooked up in reverse parallel. Here's what they looked like in a dark room:

    They were hooked up to P0 and P1, using a 100R limiting resistor on P0 and 1uF ceramic cap in parallel with the resistor.

    -Phil

  • Phil
    This is P2 code. Since there has been a lack of updates like the one I found for the seven segment display in quick bytes that required a change in the fds program that jm wrote. This is why I was wondering about updates.
    Thanks and thanks for the p1 example.
    Martin

  • AribaAriba Posts: 2,682

    @pilot0315 said:
    Some help please.
    I am attempting to try this code. I am getting an error in pub "pub fdec(value, digits)". I replaced the Jm_serial with the nov 2020 version and get the same error. What has changed?

    Thanks

    The solution has already been shown to you here: https://forums.parallax.com/discussion/174478/quick-byte-max7219-demo

  • JonnyMacJonnyMac Posts: 8,924
    edited 2022-04-17 19:48

    Ugh. It's either Ground Hog Day or this user is trolling.

    The code I posted at the top of this thread was written two years and a month ago Friday -- long before Chip made changes to the P2 compiler and added function names that collide with my serial objects.

    I am attempting to try this code. I am getting an error in pub "pub fdec(value, digits)".

    Yet again, you refuse to provide useful feedback when you encounter a problem. What's the error? Oh, there it is... "Expected a unique method name." This means that the method name has been used in the file or is a compiler keyword -- which is the case here. Two years ago the FDEC feature for debugging didn't exist (in fact, built-in debugging windows didn't exist). I and others have explained multiple times that any serial f___() method should be renamed fx___() as I have in all my latest code. The demo doesn't use serial output -- commenting out references to it fixes the problem. I know that it's really hard for you to accept, but code changes frequently -- it's why I put a release date on my programs.

  • I know that code changes. "I and others have explained multiple times that any serial f___() method should be renamed fx___() as I have in all my latest code. " Well I looked into the posts and do not see this above quote."
    Well I do not remember you stating this. AND I AM NOT TROLLING. I just wanted to know if there is an UPDATE?????
    If there is, just point me to it. This is a different program from the FDS that was changed. As you see I tried to replace it with the latest. I read the release dates!!!!!!!!!!!!!!!!!! That is why I replaced it and it did not work. The extracted file had an earlier version. I replaced it with the newest version supplied int he Prop tool and ran into the same problem. BTW if the demo does not use serial output why is it there??? The question was simple. Was there a change?
    That was all. IF there was just point me in the correct direction. No need to berate me.
    Thank you.

    @Ariba
    Thank you for your patience. I am getting back at this after two years with all of the changes. Lots of digging and tearing other folks code apart to get my brain back and working at this. I may send you a message as to why. I appreciate, again, your patience.

  • Oh and by the way. I look carefully at each bit of example code. Plus if you do not use something why include it???
    I think you need to not use your templates all the time as It confuses others. Just a suggestion. Stay with the topic at hand. Again I taught complex subjects of aircraft mechanics and am a flight instructor. Meaning I teach people how to fly aircraft. One step at at time. I am adding gliders/sailplanes to my federal certificates. I am now a student for the eighth time. Very humbling.
    One must always be humble.
    Egos are not allowed. It gets you killed. NO JOKE!
    For those who have the patience thank you.

  • Software programming requires being comfortable with causing and dealing with failures until it finally works. This is because the cost of program failure is trivial during software development and bench testing.

    Crash early and crash often. When it complies without error and stops (mostly) crashing, the programming task is finally near completion.

    If there's time and energy (usually not) at the end, the redundant code can be cleaned up and correct comments can be made. 90 percent of code is never looked at again, and only snippets are pulled out here and there for anything new.

    Clear and concise example code is a rare treasure. Tweak and adjust, and just throw different things at functions until they produce the right results.

    This is the programmer's mindset and approach.

  • JonnyMacJonnyMac Posts: 8,924
    edited 2022-04-18 18:42

    Well I looked into the posts and do not see this above quote.

    In the post Andy referenced (one you created and others responded to), I spelled it out in words and with a picture:

    I replaced it with the newest version supplied in the Prop tool and ran into the same problem.

    I have explained to you before that Parallax does not have the time nor inclination to verify that every community-provided library or demo that they package with Propeller Tool is up to date -- they are very short staffed. Please delete jm_serail.spin2 from your system, and when it's called, replace it with jm_fullduplexserial.spin2 (warning: you may need to adjust a method name or two). I wrote the former before getting a handle on PASM2. It works, but it's not buffered. Once I gained some comfort with PASM2 I updated jm_serial.spin2 to jm_fullduplexserial.spin2. If you insist on using my serial driver, please use jm_fullduplexserial.spin2.

    The question was simple. Was there a change?

    As Andy pointed out, you've been shown that change and response to that specific error in great detail -- yet, you ask again. It feels like trolling.

    BTW if the demo does not use serial output why is it there???

    Because it was a demo, and someone may have wanted to modify the demo to examine values -- again, this was written before DEBUG was available on the P2. I'm sure you carry life jackets in the plane when flying over water, even if you don't think you're going to end up in the water. Many PC languages provide terminal output as a standard. I added that as a standard to my programs out of habit and convenience.

  • @whicker said:
    Software programming requires being comfortable with causing and dealing with failures until it finally works.
    Crash early and crash often.
    This is the programmer's mindset and approach.

    Stolen!

    I was looking for something wise to put on the back cover of a sourcebook for a class I’m involved with. This is it!. I hope @whicker doesnt mind the editing job. I did credit him.

  • Stolen!

    Liberated! :D

  • @JonnyMac said:

    Stolen!

    Liberated! :D

    Lol 🤣 I'm honored.

  • @whicker said:

    @JonnyMac said:

    Stolen!

    Liberated! :D

    Lol 🤣 I'm honored.

    FYI: Jon and I will be liberating the honored. Or something like that... :)

Sign In or Register to comment.