Specific Pic Programming

A

Amigorick

New member
I am curious about some specific programming for the pic 688 used in the Renard based Controllers.
My neighbor has two 8 foot diameter "wheels" in his yard. He has white lights around the circumference
of the wheel. There are 8 "Spokes" (from the center), created by four square tubes evenly spaced across the diameter of the ring.
He has green and blue leds alternately installed on the spokes but each color is run across the diameter of the wheel.
So basically he has 4 strands of leds on the wheel. he wants them to "chase" so that it appears the wheel is turning.
I have the Diagnostic pic that tests all the channels in sequence. Could a code be developed using the Diagnostics
program, that would have channels 1-4 turning on in order with about a second in between, and channels 5-8 doing the same?
I could use an 8 channel controller to make both wheels appear to rotate. He doesn't want them sequenced to
the music, just to turn. So the controller with the Pic, programmed in this fashion, could literally be just plugged in
and it would start the channel sequencing and would run all night until powered down.
Next question. Can anyone create a code I can write to the pic, that would do this? I know ZERO about creating
code for the pics. I have looked at .asm files but not sure how to even read them correctly much less edit them.
I hope someone might have time to see if this can be done. I would be willing to pay for your time.
Thanks in advance for any suggestions or assistance!! See attached Pic.Color Wheel Diagram.jpg
 
At one time I uploaded PIC firmware code to the DIYC file library that would (essentially) do this, and I think that Dirk copied it the the Green-site file library. Unfortunately neither of these file libraries seem to be accessible right now.
 
That is my luck. :( If you do find anything about it please let me know. Thanks!!
P. Short said:
At one time I uploaded PIC firmware code to the DIYC file library that would (essentially) do this, and I think that Dirk copied it the the Green-site file library. Unfortunately neither of these file libraries seem to be accessible right now.
Click to expand...
 
I did something similar (but with candles) using the RenTester firmware. You would need to modify the data table for the information that gets sent out and plug the Data Out of the Renard into the Data In for it work, but it should work perfectly.
 
Is the RenTester firmware the same as the diagnostic firmware? Unfortunately, I know nothing about writing or even
editing the code for the firmware. Looking through it in Notepad, many parts of it are familiar and I understand what
they are, but have no idea about the majority of it.

ctmal said:
I did something similar (but with candles) using the RenTester firmware. You would need to modify the data table for the information that gets sent out and plug the Data Out of the Renard into the Data In for it work, but it should work perfectly.
Click to expand...
 
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.
 
I found some old code that might be helpful...
 

Attachments

  • simple_flasher-20111020_1348156791.asm
    9.6 KB · Views: 2
  • AC_4ch_dimmer_20140210_1392058609.asm
    16.7 KB · Views: 2
  • cylon-20090830_1331046479.asm
    8 KB · Views: 1
Last edited:
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!!

P. Short said:
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.
Click to expand...
 
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:
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?
 
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:
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.
 
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.
 
The author of RenServo is ctmal, but unfortunately it appears that the links to his RenServo firmware are no longer usable.
 
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?


P. Short said:
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.
Click to expand...
 
P. Short said:
The author of RenServo is ctmal, but unfortunately it appears that the links to his RenServo firmware are no longer usable.
Click to expand...
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.
 
You must log in or register to reply here.
Back
Top