-
Posts
812 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Posts posted by bugfight
-
-
wow, great demo.
when do you release your major label debut?
-
i've been using m-audio uno for midiboxing for a few years (under winxp).
the only issue i've had is it doesn't support multiple clients at once.
i have not built the midibox64 though.
hope that helps...
-
...
bugfight - thanks so much mate - I owe you a beer - what do you drink?
...
no problemo, my tiny contribution
i'm not drinking anything due to a bad vodka experience last week.
buy tk a beer instead...
-
ok, first i think there was good reason to keep the same color leds anodes on a single sr...
as a result you are wasting a lot of bits in your color arrays, and cycles setting pins instead of
whole registers as a byte at once.
but aside from that, anywhere i see the same code (or similar code) repeated i look for a better way.
there are rare cases where you need to trade code efficiency for execution efficiency, but i don't think
these cases fall under that umbrella.
note that i haven't compiled these so it's likely there are some typos...
where you have:
matrix_2[_MATRIX_SONG_COLUMN][0] = 0x30; matrix_2[_MATRIX_SONG_COLUMN][1] = 0x30; matrix_2[_MATRIX_SONG_COLUMN][2] = 0x30; matrix_2[_MATRIX_SONG_COLUMN][3] = 0x30; matrix_2[_MATRIX_SONG_COLUMN][4] = 0x30; matrix_2[_MATRIX_SONG_COLUMN][5] = 0x30; matrix_2[_MATRIX_SONG_COLUMN][6] = 0x30; matrix_2[_MATRIX_SONG_COLUMN][7] = 0x30; switch(evnt1-0x10) { case 0: // SONG 1 matrix_2[_MATRIX_SONG_COLUMN][evnt1-0x10] = evnt2; break; case 1: // SONG 2 matrix_2[_MATRIX_SONG_COLUMN][evnt1-0x10] = evnt2; break; case 2: // SONG 3 matrix_2[_MATRIX_SONG_COLUMN][evnt1-0x10] = evnt2; break; case 3: // SONG 4 matrix_2[_MATRIX_SONG_COLUMN][evnt1-0x10] = evnt2; break; case 4: // SONG 5 matrix_2[_MATRIX_SONG_COLUMN][evnt1-0x10] = evnt2; break; case 5: // SONG 6 matrix_2[_MATRIX_SONG_COLUMN][evnt1-0x10] = evnt2; break; case 6: // SONG 7 matrix_2[_MATRIX_SONG_COLUMN][evnt1-0x10] = evnt2; break; case 7: // SONG 8 matrix_2[_MATRIX_SONG_COLUMN][evnt1-0x10] = evnt2; break; default: //matrix_2[evnt1-0x10][evnt0-0x90] = evnt2; break; }
i would have:int i; unsigned char songIdx = evnt1-0x10; for(i=0; i<8; i++) { if(i == songIdx) matrix_2[_MATRIX_SONG_COLUMN][i] = evnt2 else matrix_2[_MATRIX_SONG_COLUMN][i] = 0x30; }
where you have:void DisplayLED(unsigned char column, unsigned char color) __wparam { switch(color) { case 0x00: //OFF MIOS_DOUT_PinSet(column+8, 0); MIOS_DOUT_PinSet(column+8+8, 0); MIOS_DOUT_PinSet(column+8+16, 0); break; case 0x10: // RED MIOS_DOUT_PinSet(column+8, 1); MIOS_DOUT_PinSet(column+8+8, 0); MIOS_DOUT_PinSet(column+8+16, 0); break; case 0x20: // GREEN MIOS_DOUT_PinSet(column+8, 0); MIOS_DOUT_PinSet(column+8+8, 1); MIOS_DOUT_PinSet(column+8+16, 0); break; case 0x30: // BLUE MIOS_DOUT_PinSet(column+8, 0); MIOS_DOUT_PinSet(column+8+8, 0); MIOS_DOUT_PinSet(column+8+16, 1); break; case 0x40: // CYAN MIOS_DOUT_PinSet(column+8, 0); MIOS_DOUT_PinSet(column+8+8, 1); MIOS_DOUT_PinSet(column+8+16, 1); break; case 0x50: // MAGENTA MIOS_DOUT_PinSet(column+8, 1); MIOS_DOUT_PinSet(column+8+8, 0); MIOS_DOUT_PinSet(column+8+16, 1); break; case 0x60: // YELLOW MIOS_DOUT_PinSet(column+8, 1); MIOS_DOUT_PinSet(column+8+8, 1); MIOS_DOUT_PinSet(column+8+16, 0); break; case 0x70: // WHITE MIOS_DOUT_PinSet(column+8, 1); MIOS_DOUT_PinSet(column+8+8, 1); MIOS_DOUT_PinSet(column+8+16, 1); break; default: break; } }
i would have:void DisplayLED(unsigned char column, unsigned char color) __wparam { color >>= 4; MIOS_DOUT_PinSet(column+8, (color & 0x01)); color >>= 1; MIOS_DOUT_PinSet(column+8+8, (color & 0x01)); color >>= 1; MIOS_DOUT_PinSet(column+8+16, (color & 0x01)); }
where you have:void SR_Service_Prepare(void) __wparam { static unsigned char row; static unsigned int x; row = ++row & 0x0F; MIOS_DOUT_SRSet(0, 0); MIOS_DOUT_SRSet(4, 0); switch(row) { case 0 : { MIOS_DOUT_PinSet1(row); MIOS_DOUT_PinSet1(row+32); for (x = 0; x < 8; x++) { DisplayLED(x, matrix_1[row][x]); DisplayLED(x+32, matrix_2[row][x]); } break; } case 1 : { MIOS_DOUT_PinSet1(row); MIOS_DOUT_PinSet1(row+32); for (x = 0; x < 8; x++) { DisplayLED(x, matrix_1[row][x]); DisplayLED(x+32, matrix_2[row][x]); } break; } case 2 : { MIOS_DOUT_PinSet1(row); MIOS_DOUT_PinSet1(row+32); for (x = 0; x < 8; x++) { DisplayLED(x, matrix_1[row][x]); DisplayLED(x+32, matrix_2[row][x]); } break; } case 3 : { MIOS_DOUT_PinSet1(row); MIOS_DOUT_PinSet1(row+32); for (x = 0; x < 8; x++) { DisplayLED(x, matrix_1[row][x]); DisplayLED(x+32, matrix_2[row][x]); } break; } case 4 : { MIOS_DOUT_PinSet1(row); MIOS_DOUT_PinSet1(row+32); for (x = 0; x < 8; x++) { DisplayLED(x, matrix_1[row][x]); DisplayLED(x+32, matrix_2[row][x]); } break; } case 5 : { MIOS_DOUT_PinSet1(row); MIOS_DOUT_PinSet1(row+32); for (x = 0; x < 8; x++) { DisplayLED(x, matrix_1[row][x]); DisplayLED(x+32, matrix_2[row][x]); } break; } case 6 : { MIOS_DOUT_PinSet1(row); MIOS_DOUT_PinSet1(row+32); for (x = 0; x < 8; x++) { DisplayLED(x, matrix_1[row][x]); DisplayLED(x+32, matrix_2[row][x]); } break; } case 7 : { MIOS_DOUT_PinSet1(row); MIOS_DOUT_PinSet1(row+32); for (x = 0; x < 8; x++) { DisplayLED(x, matrix_1[row][x]); DisplayLED(x+32, matrix_2[row][x]); } break; } default : { break; } } }
i would have:void SR_Service_Prepare(void) __wparam { static unsigned char row; unsigned int x; //edit* just noticed, no reason for this to be static row = ++row & 0x07; //<-- here you were cycling 16 rows i think you meant 8, no? //this would have resulted in a 6.25% duty cycle (vs 12.5%). //note that the duomatrix uses a 25% duty cycle MIOS_DOUT_SRSet(MATRIX1_DOUT_START, 0);//<-- hardwire bad, napster good. define constants MIOS_DOUT_SRSet(MATRIX2_DOUT_START, 0);// so you can move your matrix in the chain MIOS_DOUT_PinSet1(row + (MATRIX1_DOUT_START * 8)); MIOS_DOUT_PinSet1(row + (MATRIX2_DOUT_START * 8)); for (x = 0; x < 8; x++) { DisplayLED(x + (MATRIX1_DOUT_START * 8), matrix_1[row][x]); DisplayLED(x + (MATRIX2_DOUT_START * 8), matrix_2[row][x]); } }
-
the real good times
-
i took a quick look at the code, and there is much room for improvement. first i would suggest to use Tick() or Timer() to handle your testing instead of inlining it in Init() and using MIOS_Delay(). there should be examples on uCApps.
i don't know why this would cause a problem with one array and not the other, though, that does suggest a hardware problem. try all the permutations (swapping cables, arrays and doutx4) and see if it behaves the same. you might also try connecting the doutx4 for both arrays, but not the first array itself.
if you want some suggestions on code efficiency, i can give some, but that is another story...
-
looks nicey in green
-
that may explain it, though you may be overloading the red ones.
i don't think you need common connected, its for reactive loads....
the fact that it's a switcher may be why current noise causes reboots though.
try a fat cap and a small cap on each array for psu decoupling
-
-
that is interesting, if you're 595s aren't overheating on one board with all lit, you must be ok.
maybe those leds like a +3v supply? hm maybe i'll try mine with no res...
so in that case it must be a power supply problem or code.
is this a switching supply?
edit* i'm assuming you tried both singly. how are you connecting the pair?
-
yes you need the resisters but they do need to be lower in value because the darlington has a fairly high voltage drop, so you only have somewhere near ~3.5 V instead of 5v (iirc).
it may well be that if your leds are not efficient enough you will need better leds or source supplies for each source pin as well (udnxxxx whatever it was).
each pin of the 595 can easily supply 25mA or so for a high power led, but the total power with all 8 on at once is too high for the power rating of the 595. i planned on ~12mA max per pin. if you have the datasheet for your leds, you can calc r as:
R = (5 - Vuln - Vled) / Iled
where:
Iled is target current in Ampere
Vled is the voltage drop of the led at Iled
Vuln is the voltage drop of the ulnxxxx
(this needs to be adjusted a bit if the timing characteristics of the leds cause them to dim when pulsed)
i made some guestimates to arrive at 150r (since i got my leds surplus), which does seem a bit dim thru the sparkfun buttons.
-
where are your current limiting resistors?
-
woohoo!
now i can lay down the dope moves, and build my campsite cred.
-
ahhh that's more like it.
now: bigger carbon footprint, orgo or ftumch?
-
why not?
hehe "break down"
was more hoping for debate on the young ones, or anarchy, or cliff richard...
-
lol,
watch out or rick will hold his breath...
-
or we can ban all cars in case there's a cliff
-
mmmmm dj hero for xbox360...
-
OK keep living in denial if you like... or educate yourself.
...
lol: new "scientist"
is "new science" like "new economy"?
both built on consensus...
-
i'm still afraid of global cooling since the 70s, so i'm leaving all my appliances on all the time!
-
...It could also be realized with the new MBHP_CORE_STM32 module...
hehe, you should call it "marvin"
then you can say "hey, marvin, since you have a brain the size of a planet, could you just send this pot position over there? thanks"
-
sorry, just catching up...
i think a more likely (or just another) reason you need lower R is that the darlingtons have a fairly large voltage drop...
-
mmmm led pr0n
mmmm flax oil...
-
wilba is using the button and duo led matrix:
...
nope
E-70 Electone Midification
in MIDIfication
Posted
ouch, i'm going to assume the gutting comment was a joke.
the e-70 is quite a find, i had to look for several months to get mine.
inside are some of the same analog circuits as the famous yamaha cs series.
i haven't done any mods yet, though, can't seem to find a service manual.
and mighty Queue is so fat...
btw, the d85 is almost the same guts. there are some nice threads on electro-music and organforum...