Jump to content

2nd shift register on DIN board problem


ilmenator
 Share

Recommended Posts

Hi all,

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??

Thanks, ilmenator

Link to comment
Share on other sites

Hi ilmenator!!!

I would just run a multimeter to the pins and see if it grounds out :)

As for the encoder problem have you tried switching the encoder out to see if it is bad?

Did you solder the 15 bridges like Thorsten has on the DIN page at the bottom? (14 bridges on Smash's boards)

How about the 10k -> 5v pull up coming off of the serial pin of the second shift register?

Also does the pin have the appropriate 10k to 5v pull up for the encoder?

Well let me know if you find any thing out!!!

-Sephult

Link to comment
Share on other sites

Hi all,

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.

Thanks, ilmenator

Link to comment
Share on other sites

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?

Best, ilmenator

Link to comment
Share on other sites

OK!

Go under devices in MIDI-OX

uncheck attach midi input to midi output

go to the top right cell with outputs listed

drop down tree and remove the midi input from the tree

Try this first and see what happens.

-Sounds like a feedback problem, try that and let me know.

-I'll keep checking up on the forum

-Sephult

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Thanks again, ilmenator

Link to comment
Share on other sites

Hi Ilmenator,

..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).

Best Regards, thorsten.

Link to comment
Share on other sites

Hi Thorsten,

I think that the problem is solved  :D

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  :)

Regards, ilmenator

Link to comment
Share on other sites

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.

Could you please check if this was the reason?

Best Regards, Thorsten.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...