Start Address Programming

[rangebob]

I've watched the videos on how to do the programming and thought it was going OK. I downloaded the Renard-20090915.asm file and went into notepad and setup all of my start addresses and saved them as .asm files in a text folder. I then went into the MPLab and setup the project and built all which created the hex file. I did that for each of the controllers that I needed to create for my start addresses. I finally went into PikKit 2 to flash the Pic and imported the file and flashed it and verified it, success, imported the next file and so on all with successes. As I was importing the files the hex code didn't look like anything was changing. Today I printed out 2 of the hex code files using notepad and I compaired the lines. They are all identical. Where in the HEX file is there supposed to be a difference so controller 0 grabs that stuff and then controller 2 grabs theirs.

Thanks
Bob

[g2ktcf]

What are you trying to do? The normal Renard FW does not need start addresses.....so I am confused.

[LabRat]

the "Renard" protocol is such that it will always grab the first "N-channel" from the stream. It strips this data from the stream and passes the remaining dimming value onto the next controller. Hence there is no such "start address" when it comes to the REN. *if* you were using the DMX code (which can also run in the renards), then the data is passed along UNMODIFIED, hence the need to program start addresses into each controller.

Does this help?

[dirknerkle]

The steps to creating multiple HEX files with different start addresses are as follows:

1. Open the ASM file with an editor such as Notepad.
2. Change the start address.
3. Save the file, then close the editor.
4. Compile the file into HEX.
5. Rename the hex file so that the filename has the start address in it.

Repeat steps 1-5. My guess is that you're changing the start address and recompiling but you're not changing the resultant HEX file name -- you're just overwriting it every time.

When done, you should have multiple files that have similar yet different file names; the difference being the start address in the file name.

When you flash the chips, load the appropriate HEX file first, then flash the chip.

Start address firmware isn't probably something you want to use if you're hard-wiring your controllers or if you're daisy-chaining them from one to another. In such scenarios, leave the start address zero.

[rangebob]

I don't want to have the controllers in order when I patch them with the 45 cables... so that is why I want to use a start address on the controllers. I don't intend to have the controllers wired in order so can I skip the start address even if the order of the controllers are 1, 4, 2, 3, 7, 9, etc...

dirknerkle I did those steps in the order that you stated, I did create the 13 different asm files and then used MPLab to compile them into HEX files. When I look in my HEX folder I have 13 different HEX files in that folder just like in the text folders. Each time before I compiled it I followed all of the steps to make the program think that I was starting a new file.

To compile the steps I took each time:
Select Device ensured 16F688 was selected and then OK
Project: Project Wizard ensured same chip was selected 16F688
Selected Assembler
Browsed and found the name of the first asm file and moved it to the right.
Build All...
After it built I stopped since I was going to use the PikKit 2 to program the chips.

[budude]

I don't want to have the controllers in order when I patch them with the 45 cables... so that is why I want to use a start address on the controllers. I don't intend to have the controllers wired in order so can I skip the start address even if the order of the controllers are 1, 4, 2, 3, 7, 9, etc...

dirknerkle I did those steps in the order that you stated, I did create the 13 different asm files and then used MPLab to compile them into HEX files. When I look in my HEX folder I have 13 different HEX files in that folder just like in the text folders. Each time before I compiled it I followed all of the steps to make the program think that I was starting a new file.

To compile the steps I took each time:
Select Device ensured 16F688 was selected and then OK
Project: Project Wizard ensured same chip was selected 16F688
Selected Assembler
Browsed and found the name of the first asm file and moved it to the right.
Build All...
After it built I stopped since I was going to use the PikKit 2 to program the chips.

You cannot have lower address Renards after a higher address one unfortunately. The Renards will read in and discard all incoming data until it gets to the data for the controller address it has. It then uses the 8 bytes it needs and sends out the rest. So for example - if you had all Ren16's and the first was set for address 33 and the next physical was 1, it would read in the data left off from the first - in this case 49-last address and would assume the data for 49 is it's own. in other words, the first 16 byes read by the first controller were really intended for the controller addressed as '1' but it all got discarded. A far worse case is if you had the highest Ren first - you would end up with no data at all for subsequent.

Note that for wireless - things are done differently. You could also modify the boards to bridge IN to OUT but the boards as-is act as above.

[rangebob]

Well bummer... I guess I saw a problem with the different HEX files was a good thing then. I thought it would be similar to LOR equipment to were the wiring didn't matter. I guess I need to get some longer Cat 5 cables to wire these things up.

[rangebob]

Thinking about it more: What good is the start address then? I thought the purpose was so the controllers didn't have to be in order and it would count the X spots and use those channels and then the next would do the same thing.

[budude]

Well bummer... I guess I saw a problem with the different HEX files was a good thing then. I thought it would be similar to LOR equipment to were the wiring didn't matter. I guess I need to get some longer Cat 5 cables to wire these things up.

Why do you need the boards addressed in a specific manner - this should not be a requirement? Within Vixen (and probably LSP) you can re-order the channels in a profile any way you wish so that the logical layout/order in Vixen does NOT have to match what is done physically. I do this a ton - for my LED strips, I put them in color order which meant putting the channels in 1,5,9, etc order. Vixen doesn't care about controller addressing - a group of Renard controllers looks like one giant controller to it.

[budude]

Thinking about it more: What good is the start address then? I thought the purpose was so the controllers didn't have to be in order and it would count the X spots and use those channels and then the next would do the same thing.

For Renard/Serial - really the only reason I could think of is with wireless using Dirk's Ren-W stuff - but that is a different .asm file. In that case, the data is broadcast to all controllers in parallel so it has to know exactly which one it is. For Renard/DMX, it can come into play if you mix-n-match "normal" DMX devices with Renard/DMX. I use this when mixing LOR and Renard/DMX - I start the Renard/DMX at address '33' past my two LOR boxes (1-16,17-32) as the LORs pass on the entire data stream unlike Renards.

[rangebob]

I'm using vixen for my sequencing. I have several layouts for different parts of my display, the mega tree colors in one location, all roof together, all tree together, etc... When a sequence is played does it use the Natural order for distributing the data to the boards? In the natural order my first 3 SS16 boards are for the mega tree but the very last board #13 is also for the mega, I would love to be able to have a cat5 come from the computer to board 1, 2, 3, 13 and then out to the next series of stuff in the yard.

I'm new to Vixen. For the past 4 years I've used LOR equipment so this is all new to me.

[macebobo]

...Today I printed out 2 of the hex code files using notepad and I compaired the lines. They are all identical....

Bob,

You can use a program installed on every windows system called file compare to do this for you. <enter> means press enter)

1) Open a command window (Click Start, then click run, type cmd<enter>)
2) change to the directory that has your firmware/hex files (type cd\firmware<enter>) if you followed the tutorials, otherwise replace firmware with the folder name you created.
3) Type FC filename.hex filename.hex (replacing filename.hex with the names of the files you want to compare) and press <enter>

FC saves time and paper and my old eyes see far too many 1's and 0's during the day that they all get mixed up, so I use this tool nearly daily. :D

-- John

[gdyrdave]

I just got my ren8x8xb assembled and works great. Now when I reprogramed the pic with a start address...nada. Trying to use 3 or 4 or something other than 0 . When I program the start address back to 0 it works. I have 1 ren-w rev 6 as the transmitter. I have a ren24ss with the snap on . And 1 8x8xb. I am using MPLAB IDE and just changing the line #define START_ADDR 0. Compiles fine with the execption of the 3 warnings as PS pointed out in his comments. Can you help me out Dirk. You did last time. BTW Dirk, you got any more 8x8's boards left? Thanks guys and gals. This site is a Godsend!!!
Dave

[Materdaddy]

What channel are you using in vixen after programming the start address? The start address number is in multiples of 8, so start address of 3 will actually be channel 25.

I'm just making sure you're not thinking start address 3 will make the first channel of that controller channel 3 from vixen.

If you haven't already, this is a good read from the wiki: http://www.doityourselfchristmas.com/wiki/index.php?title=Renard_Start_Address_Configuration _Guide

[gdyrdave]

Yes I am aware of the starting address. 0 is 1-8, 1 is 9 16..etc. the program compiles but dont work unless I set the starting address to 0. I am using Dirks 8x8xb's and want to program start addresses in the 8 channel sections. I have a 24ss for 1 thru 24. have another to program 25 to 48, and 4 more 8x8xb for the consecutive numbers after that. If I put 3 as the starting address it should be 25-32. Not happening. Program the chip back to 0, works great for 1-8. I can post what I am using. Got it off of the Wiki site.

[Mactayl]

One question, are your trying the start address with just that one board or do you have that connected up after all the other boards because if you are connecting that one up after the the other boards it's start address will count 24 channels after the last controllers channel in the daisy chain then it will start turning channels on.

[dirknerkle]

I just got my ren8x8xb assembled and works great. Now when I reprogramed the pic with a start address...nada. Trying to use 3 or 4 or something other than 0 . When I program the start address back to 0 it works. I have 1 ren-w rev 6 as the transmitter. I have a ren24ss with the snap on . And 1 8x8xb. I am using MPLAB IDE and just changing the line #define START_ADDR 0. Compiles fine with the execption of the 3 warnings as PS pointed out in his comments. Can you help me out Dirk. You did last time. BTW Dirk, you got any more 8x8's boards left? Thanks guys and gals. This site is a Godsend!!!
Dave

Relax. You'll be okay. You should expect to get 3 warning errors -- not terminal errors. And yes, I have a few of the 8/8XB boards left...


Yes I am aware of the starting address. 0 is 1-8, 1 is 9 16..etc. the program compiles but dont work unless I set the starting address to 0. I am using Dirks 8x8xb's and want to program start addresses in the 8 channel sections. I have a 24ss for 1 thru 24. have another to program 25 to 48, and 4 more 8x8xb for the consecutive numbers after that. If I put 3 as the starting address it should be 25-32. Not happening. Program the chip back to 0, works great for 1-8. I can post what I am using. Got it off of the Wiki site.

I've attached a zip copy of compiled start_addr firmware from address 0 through 34. These all work fine. It sounds like you're having a problem with compiling it. This will be faster than trying to figure out what the problem is with MPLAB... These are all set at 57600 baud and use PWM, so they're good for incans and LEDs.

[gdyrdave]

Dirk
Thanks Dave. Thought you would come through. Need to find out why it wont compile though. Will try these tonight. I will let you know. I would 4 to 6 more boards if ya got em.

Dave

[dirknerkle]

Dirk
Thanks Dave. Thought you would come through. Need to find out why it wont compile though. Will try these tonight. I will let you know. I would 4 to 6 more boards if ya got em.

Dave

Glad to help, my friend! I've got about a dozen of the MiniRen8/8XB boards left...

[gdyrdave]

I will take 6. Will paypal you tomorrow. I tried one of your hex files and did not work.. Dissapointing cause I want to break up the display by 8's after the others. I love this wireless thing. I looked at the hex file and the eeprom showed 3 in the second address. That is the only difference I see in all the files.... AAAggghhhh!!!!!!!

[dirknerkle]

I will take 6. Will paypal you tomorrow. I tried one of your hex files and did not work.. Dissapointing cause I want to break up the display by 8's after the others. I love this wireless thing. I looked at the hex file and the eeprom showed 3 in the second address. That is the only difference I see in all the files.... AAAggghhhh!!!!!!!

Shazzzzbattt!!! If it didn't work, I would say something is wrong with the method, settings or programmer you're using to flash the PIC, or your XBees are communicating. And you're right about the only difference being the byte for the hex address -- that's the only difference between all those HEX files.

BTW, when you say it didn't work, have you tried the pic in a different controller (as the first pic of a controller)? If it worked in a different controller, then you know your programmer is okay and you're flashing the pics properly. That would likely mean that the XBee radios aren't set up properly.

If the pic did NOT work in a different controller, then your method/programmer is faulty.

Sometimes by swapping pieces around here and there you can determine where the problem lies by the process of deduction.

[gdyrdave]

Boy I have egg on my face!!!. I did more check (BTW.. you can change the address by editing the 1st eeprom address) Well anyway I got into checking the profile in Vixen. yeah i have 56 channels set up but dumb me forgot to check the renard output plug setup...YUP! only had 24 channels set in that dude. changed it to 56 and voila! Sometimes it is the simpler things that get ya... Any way thanks all for your support and I hope this helps someone else in the future. Dirk, I'll get with ya later today about the boards... Thanks

Dave

[Livermore-Dad]

Boy I have egg on my face!!!. I did more check (BTW.. you can change the address by editing the 1st eeprom address) Well anyway I got into checking the profile in Vixen. yeah i have 56 channels set up but dumb me forgot to check the renard output plug setup...YUP! only had 24 channels set in that dude. changed it to 56 and voila! Sometimes it is the simpler things that get ya... Any way thanks all for your support and I hope this helps someone else in the future. Dirk, I'll get with ya later today about the boards... Thanks

Dave

Think most people have done that one, I surely did last year!!

Tory