Lesss Posted January 15, 2008 Report Share Posted January 15, 2008 Hi, I have a problem!I have made midimerger (http://www.ucapps.de/midimerger.html) by myself but it blokade after a few minutes of simultaneusly playing at both of inputs. During this playing at the first input is possible and fine but the second one doesn’t work. It can be unlock only by return switching (power on/off) on merger. Playing separate at individual inputs and playing at a small number of sounds (till two) doesn’t make any problem. But when I’m trying to play at least three sounds (rather intensively) on both keyboards it attains to block the merger and after a while only the input 1 unblocks. It happens independently of using different processor (PIC16F.. i PIC18F). Is there anyone who did try this ... and had the same problem?(Sorry for my english)Best regards(Polish version -) Witam,Zrobi?em midimerger (http://www.ucapps.de/midimerger.html) ale "zawieszasi?" po paru chwilach podczas jednoczesnej gry na obu wej?ciach w takisposób, ?e granie na wej?ciu pierwszym "dzia?a" a na wej?ciu drugim nie.Odblokowa? to mozna dopiero po ponownym w??czeniu zasilania mergera. Gra"osobna" na poszczególnych wej?ciach nie nastr?cza problemów oraz gra ma??ilosci? (do dwóch) d?wi?ków (klawiszy) na obu wej?ciach. Ale przyjednoczesnej grze co najmniej trzema d?wi?kami (do?? intensywnie) na obuklawiaturach dochodzi do blokady dzia?ania mergera a po chwili odblokowujesi? tylko "wej?cie 1". Efekt ten zachodzi bez wzgl?du na wykorzystanieprocesora (PIC16F.. i PIC18F). Czy mo?e kto? próbowa? ten uk?ad i mia?podobne efekty? Quote Link to comment Share on other sites More sharing options...
TK. Posted January 16, 2008 Report Share Posted January 16, 2008 Hi Lesss,I'm still thinking about a possible reason, but still haven't got any idea, what could cause such a hangup. Only, but unlikely reason could be, that one of your synths starts a SysEx stream with F0, which never stops (no F7 and no other Status Byte)Does it also happen, when the cables at the two MIDI inputs are swapped?Best Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
Lesss Posted January 17, 2008 Author Report Share Posted January 17, 2008 Hi Thorsten,I've checked it with 6 synths. It didn't helpped swapping the cables. It is always the input 2 (pin 26 Pic- procesors) that blokes.Best regardsSee screens, (MIDI OX)screen1 - moment that it blocksscreen2 - after it is blockedINPUT 1 - Channel 4INPUT 2 - Channel 1screen1.JPGscreen2.JPG Quote Link to comment Share on other sites More sharing options...
TK. Posted January 18, 2008 Report Share Posted January 18, 2008 Hi Lesss,ok, only notes are sent. Meanwhile I looked through the code and noticed, that I added a timeout mechanism which prevents, that even uncomplete SysEx streams could lock up the MIDI forwarding.But I also noticed, that a check for the OERR (Rx buffer overrun flag) of the internal UART is missing. So far I remember, the receiver won't generate a new interrupt anymore on incoming MIDI data so long this flag stays set.Could you please add following code: ;; check for MIDI receive buffer overrunMAINLOOP_UART btfss RCSTA, OERR rgoto MAINLOOP_UART_NoOERRMAINLOOP_UART_OERR bcf RCSTA, CREN ; re-enable receiver movf RCREG, W bsf RCSTA, CRENMAINLOOP_UART_NoOERR[/code]below the MainLoop label in mainloop.inc, and rebuild a new .hex file as described here: http://www.ucapps.de/howto_tools_mpasm.htmlIf this unlocks the receiver, we know that this is the reason. It gives me the required input for planning additional measures - because it must have a reason, why the UART buffer register is not read by the CPU within ca. 640 uSBest Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
Lesss Posted January 19, 2008 Author Report Share Posted January 19, 2008 Hi Thorsten,Is it irrelevant in witch part I would put it or is there any specific place?How it to do?Best regards Quote Link to comment Share on other sites More sharing options...
TK. Posted January 19, 2008 Report Share Posted January 19, 2008 It's as simple as I wrote:below the MainLoop label in mainloop.inc, and rebuild a new .hex file as described here: http://www.ucapps.de/howto_tools_mpasm.htmlI did the modification for you, but please note that this always takes about 10..15 minutes for me, since MPASM doesn't run on my notebook (so, I need to boot the PC, re-assemble, transfer to notebook, transfer to ucapps server, etc...)-> http://www.ucapps.de/tmp/merger_v1_4a_18f_mod1.zipSince more changes are to be expected for finding out the root cause, it would be very helpful if you could try to rebuild the application. Otherwise it will take much longer for both of us to solve this issue.Best Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
TK. Posted January 20, 2008 Report Share Posted January 20, 2008 Hi Lesss,things are changing fast today ;)I've re-released the merger source code, so that it can be compiled with GPASM instead of MPLABNew release package: -> http://www.ucapps.de/midimerger/merger_v1_4b_18f.zipThe modification for the buffer overrun check is already part of this package.But please note, that I assume that more changes are required.For the case that you need to rebuild a new .hex, don't use MPASM anymore, but GPASM instead as described here:http://www.ucapps.de/howto_tools_gpasm.htmlBest Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
Lesss Posted January 21, 2008 Author Report Share Posted January 21, 2008 Hi Thorsten,I’ve found a solution for my problem!Your corrections provide to unblock the system and thanks to that it will be improved. The problem was with correct impulse form from both IC 6N138 (see screen). Therefore the design and the merger source code are correct.Thorsten, thank You for Your help and time that You spent on it.Best Regards(screen - Two Capacitors "C")Sorry for my english Quote Link to comment Share on other sites More sharing options...
TK. Posted January 21, 2008 Report Share Posted January 21, 2008 Fine that you solved this! :)Could it be, that he supply voltage of the PIC is not clean enough? (is there a big el-cap between 5V and ground?)Because a cap between +5V and Rx input normaly "worsens" the signalBest Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
Lesss Posted January 22, 2008 Author Report Share Posted January 22, 2008 Hi Thorsten,Everything is O.K. Supply voltage is clear. El-cap..is ok (47/100mikroF). A cap beetween +5V and Rx doesn’t worsen the signal. Condenser is too small for that. It only soothes too rapid signal, which can bring forth hazard. Condenser is experimentally selected.Best Regards 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.