ilmenator

You could choose the 512, which also works. Or you go for the SMD version of the 256, which is a bit tricky to solder but fits nicely for an external bankstick. Take 3 of everything. You can easily fry one of the PICs, then it's good to have a spare part... or you might want more of these MIOS applications ;D ilmenator

Okay, though I find it not very bright to answer my own posting, here goes: The PIC was dead as can be. Luckily I have a spare one (thanks go to Microchip ;) ). I have no idea what it was that I did wrong, but apparently this was the reason behind all my problems. The new PIC is working okay. Regarding the button problem I mentioned earlier: it's not a problem with the button but with the LEDs on DOUT. The problem I was having is that in CS_MENU_DOUT_TABLE in the cs_menu_io_tables file the pins are counted from left to right; the pdf counts from right to left by naming the pins D0...D7. I got confused over that. So if anybody wants to know: Pin# 0 = D7 Pin# 1 = D6 ... Pin# 7 = D0 Thanks again, ilmenator

It looks like I fried the PIC or something :( In fact, I reburned the bootstrap loader but the symptoms are just the same. Now I think it's time to get out the multimeter again... Best regards, ilmenator

Thanks Thorsten! Actually, the only modifications I did to the application was that I changed the DIN ports for some of the buttons in cs_menu_io_tables. There still seems to be some problem with one of the buttons, but this is something I will have to dig a bit deeper tonight. Then I commented out all of the encoder definitions in mios_tables, as I have only one encoder connected. For that one I changed the encoder mode to MIOS_ENC_MODE_DETENTED, because ...DETENTED2 did not work properly with my encoder. That's about it... I guess that CS_ENABLED 1 in main.asm is correct as long as there is some buttons and encoders connected to the PIC, right? This thread is probably more and more likely to be moving into the MIOS Programming area :) Best regards, ilmenator

Hi all, yesterday night I finally got my MBSID working. After tweaking around a bit with the menus and on-board control (I have a 2x40 LCD, 10 buttons beneath and one encoder apart from Menu, Edit, CC and Link buttons) I tried JSynth. After sending some sysex message to the PIC it suddenly kind of died. When I switch it on, I just see the upper row of the LCD completely black, the lower row not displaying anything. I cannot upload any app via sysex anymore, I just get the regular (each sec or so) sysex string from the PIC. Nothing else. Tonight I will try to reburn the bootstrap loader into the PIC, I hope that the PIC itself hasn't died. But I'm curious: is it possible at all that I destroyed the part of memory where the bootstrap loader is located by sending weird sysex messages via MIDI ??? Best regards, ilmenator

Thorsten, I think that this was the reason, I have been uploading a number of applications, and I have always gotten a "Rebooting MIOS" message now. I am a bit relieved that there is nothing wrong with my hardware :) Regards, ilmenator

Fantastic! I hope there is still some space left on the PIC for that portion of code!! ;) Best, ilmenator

Hey Thorsten, I didn't mean to ask for you to implement this ;) - I just thought that there might be an easy way to achieve this, but apparently there is none. I will look into the code and then decide whether it's possible for me or not. Anyway, I did not think of memory limitations, so this might be a serious "contra" for me as well. Thanks, ilmenator

Boy, what a professionally looking case! :o Congratulations!!! ilmenator

Great! Though this surely would not be limited to J5, any DOUT should do, right (regarding the necessary routines)?? Best, ilmenator

Hi all, I am building an MBSID with the basic control surface, but I have a 2x40 character display connected to the first core. I know that I can display more menu entries at once (10 instead of 5), but I would like to exchange that feature for longer strings (like "play" instead of "ply", "jump" instead of "jmp", "legato" instead of "leg" - you get the picture). So basically I would stick to the 5 buttons under the display, but have longer strings displayed. I guess that I would have to change the cs_menu_print.inc file for the strings that are displayed, but is there any easy way to tell MIOS that menu entries in general should have a length of 8 instead of 4 characters? Something like an "offset" value to tell MIOS where to place the next string? I hope I made myself clear. Thanks for any ideas, ilmenator

Hi all, here http://www.ucapps.de/midibox_sid_cs/2x20_enc_multi_w_j5.pdf a spare LED connection on J5 of the core module for the MBSID "basic setup" is mentioned. Would it be possible to use it as a MIDI in indicator? What would have to be done software-wise to allow this? Thanks, ilmenator

I will do so as soon as possible - will probably take until tomorrow night, though. Thanks, ilmenator

I see. So kind of the opposite problem to mine - the system does not reboot after receiving a new app via sysex. Well, it's not so bad because the basic functionality is there - it's just that I have to switch off and on again to have the new app up and running. Still, I guess it's a minor problem :) Regards, ilmenator

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

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

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

Hi all, It does, so there's no problem with ground. 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

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

Thorsten, you are my HERO! Your analysis was so right - pin 22 of the PIC wasn't connected to SC on J4 but to SD. Therefore I did not have any SC signal on J9 either. Excellent! ;D I feel a bit like a goof, though; actually all of my core boards did have that mistake, because the first boards were built for the MIDI filter project without any DIN or DOUT, and the error slipped through unnoticed. The other boards were just "copied" from those first. Thanks again to Thorsten and Sephult - long live the spirit of this forum ;D ;D ;D ilmenator

Bei Reichelt z.B. ist die Mehrwertsteuer auch schon drin. Da liegt der PIC irgendwo bei 12 Euro, wenn ich mich recht erinnere... ilmenator

Thanks Thorsten, I will check this tonight when I get home! Looking forward to a working system :) ilmenator

Okay, I kicked out the AIN part. Now if I temporarily shortcut pin D7 with Vs on J3 of the DIN board, I get a huge number of MIDI messages in MIDI-Ox, which do not seem right to me... it's like: TIMESTAMP PORT STATUS DATA1 DATA2 CHAN NOTE EVENT 000CC0BF 9 B0 60 7F 1 -- CC: Data Increment 000CC0C2 9 B0 61 7F 1 -- CC: Data Decrement 000CC0C5 9 B0 62 7F 1 -- CC: NRPN LSB 000CC0C7 9 B0 63 7F 1 -- CC: NRPN MSB 000CC0CA 9 B0 64 7F 1 -- CC: RPN LSB 000CC0CD 9 B0 65 7F 1 -- CC: RPN MSB 000CC0CF 9 B0 66 7F 1 -- Control Change 000CC0D2 9 B0 67 7F 1 -- Control Change 000CC0D5 9 B0 68 7F 1 -- Control Change 000CC0D8 9 B0 69 7F 1 -- Control Change 000CC0DA 9 B0 6A 7F 1 -- Control Change 000CC0DD 9 B0 6B 7F 1 -- Control Change 000CC0E0 9 B0 6C 7F 1 -- Control Change 000CC0E3 9 B0 6D 7F 1 -- Control Change 000CC0E5 9 B0 6E 7F 1 -- Control Change 000CC0E8 9 B0 6F 7F 1 -- Control Change 000CC0EB 9 B0 70 7F 1 -- Control Change 000CC0EE 9 B0 71 7F 1 -- Control Change 000CC0F0 9 B0 72 7F 1 -- Control Change 000CC0F3 9 B0 73 7F 1 -- Control Change 000CC0F6 9 B0 74 7F 1 -- Control Change 000CC0F8 9 B0 75 7F 1 -- Control Change 000CC0FB 9 B0 76 7F 1 -- Control Change 000CC0FE 9 B0 77 7F 1 -- Control Change 000CC101 9 B0 78 7F 1 -- CC: All Sound Off 000CC103 9 B0 79 7F 1 -- CC: Reset Cntrl 000CC106 9 B0 7A 7F 1 -- CC: Local Cntrl 000CC109 9 B0 7B 7F 1 -- CC: All Notes Off ... In fact, there's many more lines like this. I would expect one controller to change, not the controller numbers themselves... Quite frustrated, ilmenator

Hi Thorsten, I get some F0 00 00 7E 40 00 0F 61 F7 (about 17 times) and then after the second block of sysex data it's like 16 times F0 00 00 7E 40 00 0F 2D F7 for the AIN_DIN_DOUT application when MIDI buffer size is set to 256 bytes (I also tried any other sizes from this to 2048 ). I used various MIDI interfaces, this time upload is done via a MIDISPORT 4x4. My Yamaha USB interface does not work :-( I will try to change the code for the AIN_DIN_DOUT application as you suggestetd. Thanks a lot, ilmenator

Hi Sephult, thanks for your comments! AIN_DIN_DOUT gives me a lot of AIN messages, I think because the analogue inputs are not grounded. Do I need to change the code to change that or can I just ground some pins on the PIC board (I do not have a AIN board)? I did see the "READY." message after uploading MIOS. But when I upload an application there is no Rebooting MIOS message, I have to restart the PIC by powering off and on again. Then there is the application's welcome message as you would expect after the MIOS message. By the way, CRC application gives me a value of FD45. Does that provide any information? So in other words I'm still stuck :-[ Thanks a lot, ilmenator