haesslich Posted June 3, 2007 Report Share Posted June 3, 2007 Hi everybody.How fast can I load 2 douts (8x74hc595) seriell connected??- means just 3 wires connected to the microcontroller.mfg brain Quote Link to comment Share on other sites More sharing options...
TK. Posted June 3, 2007 Report Share Posted June 3, 2007 Faster than the PIC can be clocked - the transfer speed is no issue hereWhat are you planning to do exactly?Best Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
Braintu Posted June 11, 2007 Report Share Posted June 11, 2007 Now I am logged in wth my account. ;DI am working on a project were i want to controll 512 LEDs. I want to controll allways 64 LEDs by 2 DOUTs (seriell) and load them parallel. (2DOUTs X 8) So I was thinking what the max speep will be to laod them.Daniel Quote Link to comment Share on other sites More sharing options...
TK. Posted June 11, 2007 Report Share Posted June 11, 2007 Hi Daniel,I have to ask for some more details to get a clear picture. Are you planning to use MIOS routines to preload the DOUTs this way, or should be it an own (assembly based) routine?In both cases I think that this is the wrong way. The best way to control 512 LEDs is time multiplexing.So far I remember, I've a C based test routine for my 64 Duo-Colour-LED/button matrix somewhere on my harddisk, which can be easily extented for much more than 128 LED output functions. So, if this would help, I can publish it as a programming example.Best Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
Braintu Posted June 11, 2007 Report Share Posted June 11, 2007 No - i'll write a new prog. Maybe cc5x for pic or gcc if i use an atmega. I just want to calculate how fast i can reload the leds. 512 leds should be reload able in a very short time and very often. But what do you mean by time multiplexing.daniel Quote Link to comment Share on other sites More sharing options...
TK. Posted June 11, 2007 Report Share Posted June 11, 2007 If short execution time does matter (I think you mean: saving CPU performance for other tasks), time multiplexing is the way to go. "Very often": here it really depends which timing requirements you mean with "often" --- one microsecond, one millisecond, 10 milliseconds?The idea is: you won't notice a big difference when the LEDs are updated within 1 microsecond or 10 milliseconds, because they cannot switch so fast. So, why not using the same output pins for driving mutliple rows of LEDs - one row after another - so fast that your eyes won't regognize the difference.Here a link which gives a nice explanation: http://www.fpga4fun.com/Opto4.html, but I'm sure that there are also other ones, especially with AVR programming examples.For 512 LEDs you would use a 8x64 pin matrix (8 common lines it makes sense to add a big driver transistor here, as each common line has to sink the current of 64 LEDs at once!)Such a matrix would require 9 * 74HC595 - and this number of registers can be updated very fast. With the PIC propably within ca. 100 uS. You could update the LED rows from a timer interrupt which is called each millisecond. On each invokation of you time you would have set a new pattern for 64 LEDs, and select a new common line. With the effect, that all 512 LEDs are updated within 8 mS, but the CPU is only loaded by 10%.This is the way, how most of the LED multiplexing routines of MIDIboxes are working (e.g. MB64E, which can control up to 1024 LEDs this way)Best Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
Braintu Posted June 12, 2007 Report Share Posted June 12, 2007 Thank you for this idea. It sounds realy inteligent but i have to think about it, because most of the stuff is planned already. So thank you Quote Link to comment Share on other sites More sharing options...
TK. Posted June 12, 2007 Report Share Posted June 12, 2007 I can only strongly suggest to spend some more effort into the planning phase, and especially to do some programming evaluations before building up the complete LED matrix in order to find out the best performance solution which meets your requirements (which are still a little bit unclear to me... however :))Just for the records - this is how a 8x64 = 512 LED matrix could be controlled from the MIOS SDCC wrapper:// LED pattern array - prepared for 512 LEDs (=64 bytes)unsigned char led_patterns[64];/////////////////////////////////////////////////////////////////////////////// This function is called by MIOS before the shift register are loaded/////////////////////////////////////////////////////////////////////////////void SR_Service_Prepare(void) __wparam{ static unsigned char row_ctr; unsigned char i; // increment counter on each cycle, wrap at 8 row_ctr = (row_ctr + 1) & 0x07; // select LED row, the appr. DOUT is the 9th shift register in the chain MIOS_DOUT_SRSet(8, 1 << row_ctr); // init pattern of DOUT 1..8 (= 64 outputs) // offset depends on row_ctr for(i=0; i<8; ++i) MIOS_DOUT_SRSet(i, led_patterns[row_ctr * 8 + i]);}[/code]So, there is no need for a special timer, as the update cycle of the SR upload is already interrupt driven by a timer resource.Just to highlight it again (for the case that you change your decition): such a LED matrix, where one shift register controls the common line of so many LEDs (64 per row) definitely requires a transistor on the 9th DOUT (where the common lines are connected)Best Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
stryd_one Posted June 13, 2007 Report Share Posted June 13, 2007 Thus endeth the class. (Elegant coding 101) ;DEdit: Seriously though, am I the only one that has tried this and is now highly embarassed to show their own ugly code? I think I'm gonna just delete mine now hehe Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.