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?
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 overrun
MAINLOOP_UART
btfss RCSTA, OERR
rgoto MAINLOOP_UART_NoOERR
MAINLOOP_UART_OERR
bcf RCSTA, CREN ; re-enable receiver
movf RCREG, W
bsf RCSTA, CREN
MAINLOOP_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.html](http://www.ucapps.de/howto_tools_mpasm.html)
If 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 uS
Best Regards, Thorsten.
I 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…)
Since 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.
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.
