protofuse

the compilation of this code gives me warning 94: comparison is always true due to limited range of data type for the second if() statement. void MPROC_NotifyReceivedEvnt(unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam { if( (evnt0 & 0xf0) == 0x90) // being sure that this is a note message { unsigned char channelIndex = evnt0-0x90; unsigned char noteIndex = evnt1; unsigned char value = evnt2; unsigned char matrixIndex = noteIndex - 1 - _NOTE_MATRIX_OFFSET + channelIndex; if (matrixIndex >= 0 && matrixIndex < 32) // being sure that we'll write inside bounds { matrix[matrixIndex] = value; } } } same warning if I cast like that : void MPROC_NotifyReceivedEvnt(unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam { if( (evnt0 & 0xf0) == 0x90) // being sure that this is a note message { unsigned char channelIndex = evnt0-0x90; unsigned char noteIndex = evnt1; unsigned char value = evnt2; unsigned int matrixIndex = (int) ( noteIndex - 1 - _NOTE_MATRIX_OFFSET + channelIndex ); if (matrixIndex >= 0 && matrixIndex < 32)// being sure that we'll write inside bounds { matrix[matrixIndex] = value; } } } any suggestions?

yes, I corrected that... for the midi note / led mapping, I had to redo little things. the second test about the matrixIndex gives me a warning: warning 94: comparison is always true due to limited range of data type grrr. explicit cast is required?

you're right ... 64 is for the other matrix!

indeed, ok! void MPROC_NotifyReceivedEvnt(unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam { if( (evnt0 & 0xf0) == 0x90) // being sure that this is a note message { unsigned char channelIndex = evnt0-0x90; unsigned char noteIndex = evnt1; unsigned char value = evnt2; unsigned char matrixIndex = noteIndex - 1 - _NOTE_MATRIX_OFFSET + channelIndex; if (matrixIndex >= 0 & matrixIndex <= 64)// being sure that we'll write inside bounds { matrix[matrixIndex] = value; } } } I'll fire it in the gear!

void MPROC_NotifyReceivedEvnt(unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam { if( (evnt0 & 0xf0) == 0x90) { unsigned char channelIndex = evnt0-0x90; unsigned char noteIndex = evnt1; unsigned char value = evnt2; if( (noteIndex - 1 - _NOTE_MATRIX_OFFSET)+channelIndex <= 64) { matrix[8*(noteIndex - 1 - _NOTE_MATRIX_OFFSET)+channelIndex] = value; } } } the first if is ok, the second one could be improved I guess (bitwise operator ?!)

Thorsten, I'll correct it right now and test it ... just "after right now" it is strange that only 1 pot does that... thanks a lot ! I keep you informed !!

hello lylehaze, thanks for your answer. considering the pots event map of the core1: {0xbA, 0x01}, {0xbA, 0x02}, {0xbB, 0x01}, {0xbB, 0x02}, {0xbA, 0x03}, {0xbA, 0x04}, {0xbB, 0x03}, {0xbB, 0x04} why it doesn't for 0xbB, 0x02 ? oh, wait.. I may not explain enough my stuff... parts of code involved are: const unsigned char pot_event_map[32][2] = { //-------- AIN 11 // SR1 = instrument control 1 for channels 1-8 {0xb0, 0x03}, {0xb1, 0x03}, {0xb2, 0x03}, {0xb3, 0x03}, {0xb4, 0x03}, {0xb5, 0x03}, {0xb6, 0x03}, {0xb7, 0x03}, // SR2 = send B rate for channels 1-8 {0xb0, 0x02}, {0xb1, 0x02}, {0xb2, 0x02}, {0xb3, 0x02}, {0xb4, 0x02}, {0xb5, 0x02}, {0xb6, 0x02}, {0xb7, 0x02}, // SR3 = send A rate for channels 1-8 {0xb0, 0x01}, {0xb1, 0x01}, {0xb2, 0x01}, {0xb3, 0x01}, {0xb4, 0x01}, {0xb5, 0x01}, {0xb6, 0x01}, {0xb7, 0x01}, // SR4 = send A controls + send B controls {0xbA, 0x01}, {0xbA, 0x02}, {0xbB, 0x01}, {0xbB, 0x02}, {0xbA, 0x03}, {0xbA, 0x04}, {0xbB, 0x03}, {0xbB, 0x04} }; ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS when a pot has been moved ///////////////////////////////////////////////////////////////////////////// void AIN_NotifyChange(unsigned char pin, unsigned int pin_value) __wparam { // send mapped CC value MIOS_MIDI_BeginStream(); // midilink encapsulation header MIOS_MIDI_TxBufferPut((unsigned char)pot_event_map[pin][0]); // first value from table MIOS_MIDI_TxBufferPut((unsigned char)pot_event_map[pin][1]); // second value from table MIOS_MIDI_TxBufferPut(MIOS_AIN_Pin7bitGet(pin)); // 7bit pot value MIOS_MIDI_EndStream(); // midilink encapsulation tail } so the 3rd value is always sent... I GUESS! could it be an overcurrent issue ? I write again a very strange thing: it happens when I turn a bit the pot. not when the value is high at the beginning: - I start the midibox with this pot at 0. it boots correctly, everything works fine. I turn a bit ...issue! - I start the midibox with this pot at N>0. it boots correctly, everything works fine. I turn a bit ...issue!

issue 2) fixed! it reminds me that: post on the protodeck's blog about connector I checked 999times, not 1000 ! bad boy I am! pots/AIN connector problem! issue 1) still in tracking!

ok Thorsten. I ommited to write something. this didn't happen before... (before what..?!) I'm quiet sure my code is safe. but "being sure" isn't the way to follow when you track a bug !! the code(s) are here: http://code.assembla.com/protodeck/subversion/nodes/protodeck/protodeck_CORE_1/main.c http://code.assembla.com/protodeck/subversion/nodes/protodeck/protodeck_CORE_1/main.h http://code.assembla.com/protodeck/subversion/nodes/protodeck/protodeck_CORE_2/main.c http://code.assembla.com/protodeck/subversion/nodes/protodeck/protodeck_CORE_2/main.h there is only one pot that gives me that, the one sending {0xbA, 0x02} from core1. this is the core that freezes when data flows from core1 from this freaky pot.

Thorsten, considering your clearly explained test/advices, I guess it is for the bug 2) Do you have an idea about the bug 1) ?? it is very strange.

Ok I'll do it firstly...this afternoon. ok I'll check it in the second time. but I really think about murdered* pots :-( thanks a lot Thorsten I'll keep this post updated

one big clue about 1) if I disconnect the midilink between core1 and core2, if I turn this weird* pot, no problem. so my hypothesis: it is a midi issue between the 2 core ... no? for the 2) I'm still stuck, and VERY stuck :-(

hello experts, I'm tracking my 2 last protodeck hardware bugs and I'd need some help. 1) one pot give me a headache everything works fine (2cores + 2 dout + 3 ain + 3 din) I'm turning one pot (THE damned pot) and the other core freezes (some leds switch off, buttons and pots attached to the core frozen don't respond etc) this is the ONLY pot that gives me that. I tested to boot the gear with this pot a little bit open, it boots right ; I turn a bit ... wow! 2nd core freezes! so I guess it isn't an overcurrent, but a "signal" problem.. any ideas? 2) the problem of testing pots independently of the previous described problem (I'm quiet sure about that), 8 pots attached to one SR give me headache too. one works, the other not etc etc. I switched ribbon cable from one SR to other, the previous unworking pots works and vice versa. so, I bet on the SR. I changed it... all the same. and I had the genius idea to test the pots... but, how could I test the pots? I wanted to test continuity between SR and pots but I found a strange thing: my continuity tester beeeeeps* when I test the continuity between all the middle pins on my pots... (those more far don't give that) how could I test that? all ideas would be appreciated :)

sorry I didn't view your answer it wasn't that. still tracking this last hardware bug on the protodeck :-(

hello, only several hard bugs on the protodeck... grrr. bug tracking, at this point, is very annoying but has to be done! I think I killed a 74HC4051 (analog mux/demux)... My question isn't "how to test it?" indeed, replace and try is the right way for that. the symptom was: freaking flow (not like a jitter, a real random flow, continuous when one pot on the mux/demux was opened etc) The question is: what could be frequent causes to kill this kind of component in midibox world ?? It would prevent me some headache tracking things that doesn't matter ;) I guess short circuit or smtg like that ... but is there a frequent cause to that? all hypothesis about that could be fine...

thanks a lot for your precise explanation!! it illustrates clearly the race condition concept I thought I understood... "hello" was for debug purpose indeed... but it wasn't a good method ; proof: both 2 cores are ok, but only one "hello" :) so, I can write the protodeck is all ok! excepted for ltc module that doesn't work as I would like...I posted in another thread, I'll repost inside it soon... thanks again Thorsten, & all messages received here :-)

hi folks, several midilink issues, I guess. 2 cores 4 midi port (in out for each core) the 1st core with optocoupler, the 2nd without optocoupler midi out from J11 of 1st Core to midi in J11 of 2nd Core 1st core midi merger forward point 2nd core midi merger endpoint no core ID issues. correct ID (thanks to smashTV/tim), correct upload process. in init, I put these message in order to be sure all core run: // note on hello from core1 MIOS_MIDI_BeginStream(); MIOS_MIDI_TxBufferPut(0x90); MIOS_MIDI_TxBufferPut(0); MIOS_MIDI_TxBufferPut(0x7f); MIOS_MIDI_EndStream(); // note on hello from core2 MIOS_MIDI_BeginStream(); MIOS_MIDI_TxBufferPut(0x90); MIOS_MIDI_TxBufferPut(1); MIOS_MIDI_TxBufferPut(0x7f); MIOS_MIDI_EndStream(); midiOx with midiin cable in midi in of 1st core, midiout cable with midi out from 2nd core no prob with MIOS_MIDI_BeginStream(); and MIOS_MIDI_EndStream(); indeed, din handled by 1st core works correctly (I have message from them through the 2nd core) BUT - I only received a hello message from the 2nd when I switch on the whole beast (if I put a midi cable at the midi out of the 1st one, I have its hello message) - when I upload with mios studio, it works. BUT in smart mode, the 1st core doesn't upload correctly with the cable as described before. if I move the midi in (PC) from midi out 2nd core to midi out 1st core, I can upload in smart mode the 1st core. - if I upload in manual mode the 1st core with cable like describe before (at the beginning), it works, and when the first core reboots, it fires the little hello midi note...... my conclusion: "some" messages don't go from the 1st core to the 2nd, sometimes... why? How could I unstick me? I could be happy, din, ain from the 1st core fire good messages to the 2nd... so I have the whole thing almost ok. but I'm afraid this behaviour drives me to unstability or smthg like that. all ideas, advices would be appreciated.

you can check how I did to illustrate the thing: http://www.julienbayle.net/diy/protodeck/#pots

I posted a lot of information about the protodeck : http://www.julienbayle.net/diy/protodeck/ I didn't finish it yet... even if it already works very fine, I have to clean up things inside its guts like messy cable path, replacement of several connector by soldering (for power supplying, for example) etc etc. I have to make the whole thing more reliable (at least in my head :o ) Now, a big work to do: the interface between the protodeck and Ableton Live. As I'm a max for live beta tester, I can begin to work on it ... right now :P

ok TK. I think I have the right code (I'm doing a pause at work, so I cannot test right now) I define these before Init() unsigned char matrixBlinkingState[64] ; unsigned char flash_ctr; I fill these matrixBlinkingState with 0x00 in Init() cause nothing blinks at the beginning unsigned int index; for (index = 0; index < 8; index++) { matrixBlinkingState[index] = 0x00 ; } DisplayLED hasn't been changed. ///////////////////////////////////////////////////////////////////////////// // This function is called by SR_Service_Prepare, decompose color component and UP the right rgb pins ///////////////////////////////////////////////////////////////////////////// void DisplayLED(unsigned int column, unsigned char color) __wparam { color >>= 4; MIOS_DOUT_PinSet(column+8, (unsigned char)(color & 0x01)); // RED color >>= 1; MIOS_DOUT_PinSet(column+8+8, (unsigned char)(color & 0x01)); // BLUE color >>= 1; MIOS_DOUT_PinSet(column+8+8+8, (unsigned char)(color & 0x01)); // GREEN } I put the counter incrementation outside of the for loop in order to keep it consistent... the if/test can really be improved I'll do it asap with bitmask etc as you did.. but I have to figure out how I can do that in my case. void SR_Service_Prepare(void) __wparam { static unsigned int row; static unsigned int lastrow; unsigned int x; row = ++row & 0x07; // row cycling MIOS_DOUT_PinSet0(lastrow); // lastrow OFF MIOS_DOUT_PinSet1(row); // current row ON for (x = 0; x < 8; x++) { if( flash_ctr >= 200 ) { flash_ctr = 0; if (matrixBlinkingState[x+row*8] == 0x00) DisplayLED(x , matrix[x+row*8]); // displaying the led (x,row) else DisplayLED(x , 0x00); // OFF this led cause it blinks } } lastrow = row; flash_ctr++; } I control blinking state with velocity: 0x7E means solid state, 0x7F means blink state. void MPROC_NotifyReceivedEvnt(unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam { int channelIndex = evnt0-0x90; int noteIndex = evnt1; unsigned char value = evnt2; if (value != 0x7E || value != 0x7F) matrix[8*(noteIndex - 1 - _NOTE_MATRIX_OFFSET)+channelIndex] = value; //-1 cause note begin at 1 and row at 0 else if (value == 0x7F) // value = 0x7F means blinking state ON matrixBlinkingState[8*(noteIndex - 1 - _NOTE_MATRIX_OFFSET)+channelIndex] = 0x01; else (value == 0x7E) // value = 0x7E means blinking state OFF matrixBlinkingState[8*(noteIndex - 1 - _NOTE_MATRIX_OFFSET)+channelIndex] = 0x00; }

Thorsten, I'm including this code before making my 1st test. Indeed, I'd like to control it with another midi device. I'm a little bit stuck cause I'm using RGB led. Could you help me? I'm using a lookup table: static unsigned char matrix[64] ; I feed it with MPROC_NotifyReceivedEvnt() function: void MPROC_NotifyReceivedEvnt(unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam { int channelIndex = evnt0-0x90; int noteIndex = evnt1; unsigned char value = evnt2; matrix[8*(noteIndex - 1 - _NOTE_MATRIX_OFFSET)+channelIndex] = value; //-1 cause note begin at 1 and row at 0 } I read it with SR_Service_Prepare() void SR_Service_Prepare(void) __wparam { static unsigned int row; static unsigned int lastrow; unsigned int x; row = ++row & 0x07; // row cycling MIOS_DOUT_PinSet0(lastrow); // lastrow OFF MIOS_DOUT_PinSet1(row); // current row ON for (x = 0; x < 8; x++) { DisplayLED(x , matrix[x+row*8]); // displaying the led (x,row) } lastrow = row; } and the parsing function is DisplayLED: void DisplayLED(unsigned int column, unsigned char color) __wparam { color >>= 4; MIOS_DOUT_PinSet(column+8, color & 0x01); // RED color >>= 1; MIOS_DOUT_PinSet(column+8+8, color & 0x01); // GREEN color >>= 1; MIOS_DOUT_PinSet(column+8+8+8, color & 0x01); // BLUE } could you help me?

hello worker8 solide? je sais pas. en tout cas, ça a commencé en mars par les idées et le design global, et qques mois après, finalement, ça marche bien :) en tout cas, ça marche comme je voulais! pour info, ça me servira à contrôler Ableton Live. Pour ça, j'avais bosser sur une API de connexion à Live en Python... fun mais chiant! Je beta teste actuellement Max For Live qui permettra de faire pareil de manière officielle et avec un langage de plus haut niveau. yeah! pas encore bcp de photos et videos. mais dès que j'ai fait les finitions de mon boîtier, je vais tout publier et documenter et photographier et videoer!

okay :) for me, it was the same concept (for me = for me, the cute noobie) :P the conclusion of all my tests around that is: when a flat ribbon cable unshielded (with pots on one side & AIN on the other side) is putted VERY near from a part (transfo) of the PSU... false detection flows suddenly. if I keep cable as far enough of this part of the psu, NO problem. I guess improvements could be done, but now, with the box closed, no problem with that.

wire-bound?