High channel count Renard (chipiplexed)

[djulien]

Here is a write-up of my chipiplexed Renard experiments. Sorry about the length – there was a lot of info to cover. You may want to turn on "Allow fast web view" under the Internet options in the View Edit -> Preferences window in your Adobe reader before you open the PDF.

Let me know if you would like any further info about this, or if you do try it out and encounter problems with it, let me know and I'll see if I can help. If anyone is willing to lend a hand with creating a PCB (including the logistics of submitting it to a place to create the PCB), please let me know.

I wanted to put the files all in one place within the File Library, but they seem to apply to multiple topics, so for now they are just attached to this post. The PDF is also at:

http://downloads.eShepherdsOfLight.com/Renard-HC.pdf

don

[fathead45]

i was hoping you was going to post how you did this. i was very intrigued by this and wanted to know how you did it. thank you. time to start reading.

[Sharkey]

Wow great work ;D

That's.. a lot of text!

[cypress1138]

Any progress on the source code?

[IdunBenhad]

Hi:
As posted before under "RENARD BASICS", Don's first few pages of the PDF is an excellent explanation of how Renard works.

The whole article is well worth reading. He went to a lot of work producing this.

[cypress1138]

I have read the article and he did do an amazing job of explaining it but I would love to go through the source code as well.

[bobkeyes]

If you need the high channel count, and I do, why would you NOT use this??

[cypress1138]

I absolutely need a high channel count (4,008 to be exact... good God what am I thinking!!) 168 of these will be Ren 24LV's but the remaining 3,840 will be used to control RGB leds. Of these 3,072 channels would be used for the mega tree which would have the leds arranged into strings. To keep the wiring mess down to a minimum I want to control 16 leds with 1 board (48 channels). The leds would be split into 4 banks of 4 leds each with all of the red, green, and blue cathodes for a given bank wired in parallel and then each anode would be turned on in succession (i.e. mutliplexed) . This cuts down on the wiring spaghetti since only 28 wires are needed. The control board would be located in the middle of the 16 leds so only 14 wires would be coming out from either end. This would keep the string's wiring fairly small. The way I understand Don's design is that every led would need to be wired up individually which would require 49 wires (48 cathodes and 1 anode) which would make for a very fat bundle even with the control board in the middle of the string (25 wires top and bottom). I have been working on my own design here (http://doityourselfchristmas.com/forums/showthread.php?t=10626) but I have hit a mental block... big surprise there :wink: I think I have a handle on the hardware issues but the software side is still kicking my @$$. That is why I would love to see Don's firmware to see how he implemented his design. I am by no means a programmer (dumb wrench turner by trade) so seeing how people much smarter then myself have solved issues like this would be very helpful!

[dmoore]

Here is a write-up of my chipiplexed Renard experiments. Sorry about the length – there was a lot of info to cover. don

I'm completely impressed.... the quality of this work is amazing. I don't understand half of it but hats off to you for the amount of effort you put into it.

[djulien]

The way I understand Don's design is that every led would need to be wired up individually which would require 49 wires (48 cathodes and 1 anode) which would make for a very fat bundle even with the control board in the middle of the string (25 wires top and bottom).

If 48 (or 56) monochrome or 16 (or 18) RGB LEDs are chipiplexed, it would only take 8 wires, but it is still kinda messy wiring. I'm trying to figure out an easier way to do that, but it looks rather tedious at the moment.


If you need the high channel count, and I do, why would you NOT use this??

Well, there are trade-offs. I tried to describe those in the write-up. - mainly related to maximum number of different channel intensities at any one time (ie, the "lossy" dimming). Also, I suppose the wiring itself is more complicated (the first time).


Any progress on the source code?

Yes. I kinda got side-tracked with some distractions. During the cleanup, I made some "minor" structural changes which broke some things. :rolleyes: I think they are working again. I didn't realize anyone was waiting on this. Should I release it in a still partially messy state, or finish off the clean up? If you need it by a specific date I'll set that as my target.

Aside from the structural clean-up, I did fix a bug that was causing LED flicker. I'm in the process of building a little test rig with a string of 16 RGB LEDs to test how smoothly it can ramp and fade the LEDs from a 16F688.

I also started adapting the code to also run on a 16F689/690, which would allow driving the LEDs at a full 20 mA each, whereas they are limited to about 13 mA with the 16F688.

don

[cypress1138]

If 48 (or 56) monochrome or 16 (or 18) RGB LEDs are chipiplexed, it would only take 8 wires, but it is still kinda messy wiring. I'm trying to figure out an easier way to do that, but it looks rather tedious at the moment.
I stand corrected there would only be 8 wires from the board but the "string" itself would be... exciting... to wire up :-)


Yes. I kinda got side-tracked with some distractions. During the cleanup, I made some "minor" structural changes which broke some things. :rolleyes: I think they are working again. I didn't realize anyone was waiting on this. Should I release it in a still partially messy state, or finish off the clean up?
I would love to see it as is. What I am most interested in is how you handle the interrupts and updating the individual channels.

Thanks again for the excellent write up it has already helped me tremendously to wrap my head around all this!

[djulien]

What I am most interested in is how you handle the interrupts and updating the individual channels.

The firmware is not currently using interrupts - there was too much overhead. At first I was using interrupts, but because of the number of registers that needed to be saved and restored (W, STATUS, PCLATH, FSR) and the frequency of the interrupts (640x ZC, up to 77KHz), there weren't enough cycles left for actually turning the channels on/off and handling serial I/O with the 8 MHz internal clock.

For the channel updates, it uses an in-memory copy of the ports to turn on/off channel bits as required, then just copies those bytes out to Port A and C at the time that Timer 0 wraps (very low jitter, about 10 instructions).

I'll make one more pass thru the source code to update the comments so they match the actual code so they won't be misleading, remove some dead code sections, and (try to) refrain from any more actual code editing (for now). These will improve the readability, and then I'll post it. I will try to get that done by this weekend.

don

[cypress1138]

The firmware is not currently using interrupts

OK now I'm beyond curious!

[djulien]

OK now I'm beyond curious!

I should clarify that statement - I'm still using T0IF, TMR1IF, TXIF, and RCIF, but GIE is off, so the code just polls for the type of hardware event that it is looking for. Since the interrupts occur at different frequencies, the polling can be divided up so that everything gets processed when it needs to.

Anway, I'll try to get this comment/dead code clean-up pass completed and then post the code.

don

[cypress1138]

How goes the clean up?

[djulien]

How goes the clean up?

Okay, here's what I have so far. Sorry for the delay - work's been crazy.

The firmware is in the RenardChipiplexerFirmware subfolder. The comments actually match the code now. I hope they help to explain how the code works. There's a lot in there and too much to write lengthy documentation for, and the code is probably a little hard to follow, so please feel free to ask questions about it. Please realize that when I started this code it was my first MPASM or PIC project (not counting the little "hello world" stuff), and so it was also largely a learning experiment. As a result, the code is probably more complicated than it needs to be. A lot of that was also due to my secondary experiment of trying to turn MPASM into a "macro assembler" of sorts (since I wanted compact code but didn't want to buy a compiler). If you extract the actual opcodes from the .LST file or disassembled code, it wouldn't be so bulky.

For anyone just interested in "the magic", I suppose the SSR_ISR, Chipiplex, and FBUnpack macros are the ones that will be of the most interest, although many of the macros themselves may contain interesting little bits of code.

I did a very brief sanity check on a 16F688 but I did *not* regression test this version after the recent edits and code clean-up so there is probably something broken in there now. However, it does compile okay for the 16F688 and '689/690. In order to not delay further, I am releasing this version as-is, and then I will go back and regression test it again with some SSRs as I finish up the RGB LED handling over the next month or so. If it doesn't compile in your environment, let me know and I'll try to take a look (or if you see the problem just go ahead and fix it, but please share the changes).

EDIT: whoops, forgot the MPLAB project file - attached

don

[cypress1138]

Too Cool!!! Excellent now I have something to do on the cruise that I'm going on Monday with the wife to celebrate our 10 year anniversary... on second thought I better wait till I get back :rolleyes:
Thanks again so much for posting your source code!