after resolving the first problem with my encoders connected via DIN board, I seem to be running into the second one. Here’s the story:
I connected 4 encoders to the first shift register - everything was working fine. What a surprise ;)
Then I decided I wanted to have a fifth encoder which I connected to pin 0 of the second shift register. Now if I turn the encoder, “enc_example_3_v1_3” sometimes gives me feedback, sometimes the app just hangs. Then I have to reboot the PIC by switching off/on. Interestingly, the app only starts to hang if I turn this encoder…
I did connect ground to the corresponding pin on the first shift register only, on the encoder board all grounds are connected together. I think that there is a ground connection on the DIN board already, so that the second shift register is grounded and should work - though I am not sure about this. Anybody who is better in interpreting the schematic of the DIN board??
I would just run a multimeter to the pins and see if it grounds out
It does, so there’s no problem with ground.
As for the encoder problem have you tried switching the encoder out to see if it is bad?
The problem now does not only happen with the last encoder. More testing showed that it might happen on any encoder.
Interestingly, when I first switched on the core today, I was not able to reproduce the error. Only after uploading an application the error ocurred again. (I was switching between enc_test 2 and enc_test 3).
I still get a “Reboot MIOS” message only sporadically, say like in 5-10% of the uploads. In the last few hours I had no such message at all. I suspect that this might be one of the points to dig deeper…
All the bridges are there (though I only count 14 on Thorsten’s board), all the resistors are there.
The power supply is stable, and the 7805 doesn’t get hot at all.
Did some more testing. Problem seems to have something to do with MIDI In :o
As long as no MIDI-Ox is connected, everything runs smooth. When the PC running MIDI-Ox is running (so I can upload different apps), then the strange behaviour described above starts to show…
I wonder if this has something to do with the LCD resistor that Sephult describes?? What exactly did you do there?
Also are you getting the appropriate checksums for the applications? (you can find out what checksums each program has by converting the main.hex to main.syx, using the convert program*)
Are you able to get a stable checksum every time, especially using the 2048*4 @ 700 F7 Delay?
-Sephult
*You need to have active perl to do this, read .asm for more info.
It apparently is a MIDI feedback problem. I’m kind of astonished, as I would think that the PIC should be able to handle incoming MIDI data, even if it’s the same as the one it sends itself.
Is this due to the fact that there is only limited functionality in the test applications (enc_example…)? I should think so.
..so, this means that you found the reason for your problems?
No, MIOS doesn’t provide a feedback detection. It’s only a minor feature which allocates some RAM and causes more problems when it solves (especially in combination with a MIDIbox Link to another core module).
I have a stable “ENC_example_x” application as long as MIDI data received from the PIC isn’t sent back to it. Apparently, the fact that the core does not reboot itself after receiving a new app via sysex does not have to do anything with the problems I had! Still I’m a bit worried, since most people seem to get this message…
I see why there is no feedback detection. As I will be using the MIDI link feature in the future, I should have thought about that :-/
Well, nobody’s perfect :P
Thanks guys, I guess this topic can be closed now :)
MIOS doesn’t reboot so long as MIDI events are received - every time a MIDI device sends some notes/controllers/sysex strings to the core, the handler will wait at least 2-3 seconds before rebooting. Only realtime events (like MIDI clock or Active Sense) will be ignored.
