Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 30

Thread: Specific Pic Programming

  1. #11
    Join Date
    May 2007
    Posts
    5,745
    Post Thanks / Like

    Default Re: Specific Pic Programming

    Quote Originally Posted by dirknerkle View Post
    I found some old code that might be helpful...
    I'm pretty sure that none of those are it.
    Phil

  2. #12
    Join Date
    Nov 2010
    Location
    Dothan, Alabama
    Posts
    423
    Post Thanks / Like

    Default Re: Specific Pic Programming

    we only plan on using one Renard SS8 to run the wheels. I could even
    use only four channels and just plug both wheels into the same plugs as
    the other wheel. So at the most, one pic would be enough.
    maybe that makes it a little easier! Thanks!!

    Quote Originally Posted by P. Short View Post
    But I'm playing around with creating (or recreating) an AC chase controller for up to 2-8 channels on one PIC. Trying to span more than one PIC is more than what I have the time or inclination to create. Maybe in a day or so.

  3. #13
    Join Date
    May 2007
    Posts
    5,745
    Post Thanks / Like

    Default Re: Specific Pic Programming

    I haven't forgotten this thread.

    I've just created a PIC16F688 program (renard-chase) based on bits and pieces of code from here and there, and am about to do some testing of it.

    Perhaps I got a bit carried away, especially since it would likely be a one or two line change to the diagnostic PIC that does a lamp test (if I had the source, which I don't) to do what was requested. The program that I'm working on has a few extra bells and whistles:

    1) It has a user knob that controls the rate of the chase.
    2) It has a user knob that controls which outputs are the first and last in the chase (allowing up to eight lights in the chase)
    3) It has a user knob that controls the direction of the chase
    4) It has a user knob that determines if the chase always continues in one direction, or changes direction when it hits a 'limit'
    5) It has a user knob that controls the attack rate (i.e. does a light come on full-brightness when it first turns on, or does it's brightness ramp up)
    6) It has a user knob that controls the decay rate
    7) It has a user knob that determines how many outputs are on at once.

    By 'user knob' I mean a #define statement near the beginning of the assembly file that the user can change.
    Last edited by P. Short; 12-08-2021 at 12:21 PM.
    Phil

  4. #14
    Join Date
    Feb 2009
    Location
    Plymouth, MN
    Posts
    9,437
    Post Thanks / Like

    Default Re: Specific Pic Programming

    This brings up a curiosity I've always had...

    How much "slush" time is there in the ISR part of the Renard code for inserting additional code? Or is there any time for checking the status of a value or two?

    http://digwdf.org/store/
    Even though the DIGWDF Store has been closed for almost three years, it's still awesome!
    User guides, documentation and other files are still free and available for downloading.

  5. #15
    Join Date
    May 2007
    Posts
    5,745
    Post Thanks / Like

    Default Re: Specific Pic Programming

    Depends.

    When using either a PIC16F1825 or an external 18.432 MHz oscillator with a PIC16F688 there is a bit of room for 'slush'. With the PIC16F688 using it's internal oscillator there isn't much, if any, extra room.

    The limiting factor is whether or not the ISR uses up so much of the CPU bandwidth that the foreground Renard protocol processing code can't keep up with the result that the UART under-runs, losing data. It's been a long time since I've counted instructions in both the ISR and foreground code to know what the maximum baud rate is that would work with '688 using it's internal oscillator, nor exactly how much slush there is in the other configurations.

    Edit: What do you have in mind?
    Last edited by P. Short; 12-08-2021 at 03:52 PM.
    Phil

  6. #16
    Join Date
    Feb 2009
    Location
    Plymouth, MN
    Posts
    9,437
    Post Thanks / Like

    Default Re: Specific Pic Programming

    A few years ago I played with the 688 code a bit in trying to insert a "minimum" and "maximum" for the RenServo firmware so that the value would never be greater than a value that would peg the servo to either extreme, which can physically damage the servo. Typically, dedicated servo controllers include settings (usually potentiometers) to tweak the range of a servo's motion between a desired range which is never at either of the servo's extremes. Vixen's range is, of course, 0-255 in a cell value and the RenServo firmware translates these values into an appropriate pulse, using 127 as the "center" of the servo's motion. However, between sequences, Vixen isn't sending anything, which the RenServo firmware sees as zero and the servo gets jammed at its minimum.

    Since servos have a center point and when initially powered up, they generally "find" their center. But different servos have different ranges of motion -- some are 90 degrees, some are 120, some are 180, 225, and some are continuous rotation. Therefore, it's important to be able to change the min/max setting to prevent servo damage. Since the 688 can effectively control up to 8 servos, I was trying to create a minimum and maximum for each of the eight channels so that if the value for a servo was lower than its minimum, the minvalue would be substituted and if the value was greater than the maximum, the maxvalue would override it.

    I vaguely recall that I had inserted quite a few lines of code to do the proper comparisons for each of 8 outputs and the result was that nothing worked after that.

    I played with it for a couple days, wasn't successful at all and I eventually gave up on the project.

    http://digwdf.org/store/
    Even though the DIGWDF Store has been closed for almost three years, it's still awesome!
    User guides, documentation and other files are still free and available for downloading.

  7. #17
    Join Date
    May 2007
    Posts
    5,745
    Post Thanks / Like

    Default Re: Specific Pic Programming

    RenServo is a totally different beast, I'm not sure who wrote that (ctmal, perhaps)? In all of my Renard code the ISR is used for driving the SSR's, and the foreground is used for serial communications (receiving and forwarding data, and placing locally-destined data in an array for use by the ISR). I've never looked at the RenServo source to see how things are handled there.
    Phil

  8. #18
    Join Date
    May 2007
    Posts
    5,745
    Post Thanks / Like

    Default Re: Specific Pic Programming

    The author of RenServo is ctmal, but unfortunately it appears that the links to his RenServo firmware are no longer usable.
    Phil

  9. #19
    Join Date
    Nov 2010
    Location
    Dothan, Alabama
    Posts
    423
    Post Thanks / Like

    Default Re: Specific Pic Programming

    Wow !!!! Talk about above and beyond!!! I wish I knew the coding like you and some of the others.
    Sure I can look at it and "understand" what it might be doing, but not enough to make it do it.
    Is there any study material (for Dummies) out there that us wannabee's could look into to try and learn how to do it?


    Quote Originally Posted by P. Short View Post
    I haven't forgotten this thread.

    I've just created a PIC16F688 program (renard-chase) based on bits and pieces of code from here and there, and am about to do some testing of it.

    Perhaps I got a bit carried away, especially since it would likely be a one or two line change to the diagnostic PIC that does a lamp test (if I had the source, which I don't) to do what was requested. The program that I'm working on has a few extra bells and whistles:

    1) It has a user knob that controls the rate of the chase.
    2) It has a user knob that controls which outputs are the first and last in the chase (allowing up to eight lights in the chase)
    3) It has a user knob that controls the direction of the chase
    4) It has a user knob that determines if the chase always continues in one direction, or changes direction when it hits a 'limit'
    5) It has a user knob that controls the attack rate (i.e. does a light come on full-brightness when it first turns on, or does it's brightness ramp up)
    6) It has a user knob that controls the decay rate
    7) It has a user knob that determines how many outputs are on at once.

    By 'user knob' I mean a #define statement near the beginning of the assembly file that the user can change.

  10. #20
    Join Date
    Feb 2008
    Location
    Warminster, PA
    Posts
    1,803
    Post Thanks / Like

    Default Re: Specific Pic Programming

    Quote Originally Posted by P. Short View Post
    The author of RenServo is ctmal, but unfortunately it appears that the links to his RenServo firmware are no longer usable.
    Yeah, I just noticed the other day that my site is down. I hope to fix it this weekend. In the meantime, I'm sure I have it somewhere if you want it.
    Chris
    [URL="http://www.maloneylights.com"]http://www.maloneylights.com[/URL]
    [URL="http://halloween.maloneylights.com"]http://halloween.maloneylights.com[/URL]
    [URL="http://ctm.maloneylights.com"]http://ctm.maloneylights.com[/URL]

Page 2 of 3 FirstFirst 123 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •