Jump to content

bugfight

Frequent Writer
  • Posts

    812
  • Joined

  • Last visited

Everything posted by bugfight

  1. needs a new status

    1. ultra

      ultra

      oh look a paradox!

  2. mmmmm sammichSALMON, tasty

  3. sometimes i wonder if flem is the only person who reads these...

  4. sometimes i just want my status to scroll off the "Recent Status Updates" list so i can make a new one to be copied...

  5. Sometimes I just want to copy someone else’s status, word for word, and see if they notice

  6. i did a pw reset and got in. it might be a good idea to send one pkg to the states and then distribute. otoh, it might cost just as much. anywayz, if we want to try that, i would be willing to do the dirty work...
  7. mmmmmm me likey. i would take several as these will be useful for many projects. can't edit wiki tho, login fails...
  8. got mine yesterday. thanks mucho, sep. can't believe you took so long, the poor pcbs had to wait to enter the endless queue... *whack*
  9. wayyyy cool, now i just have to wait for the next gen ipad and/or radical first-adopter-screwing price drop
  10. why use super-matched? this is essentially an inverter, no? check this: http://www.retrosynth.com/docs/trigger/triggermod.gif edit* oops i see you are doing expo too, thus the matched
  11. 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...
  12. wow, great demo. when do you release your major label debut?
  13. 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...
  14. no problemo, my tiny contribution i'm not drinking anything due to a bad vodka experience last week. buy tk a beer instead...
  15. 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]); } }
  16. 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...
  17. 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
  18. 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?
×
×
  • Create New...