dubstructor

OK enough of fresh air, back to the wicked foggy atmosphere of my room. Now guess what ? I've uploaded my first app !!!!! Should be bouncing everywhere ..... but ..... nothing more happens. The upload seems to work well, I've verified the ID numbers, I have the checksums, no problem (yeepee ! After all that's what I've been sweating for) . I uploaded a simple test application, supposed to send a CC 1 on channel 1 with the last pot value on any pot tweaking (using 8 unmuxed pots) : main.c #include "main.h" #ifndef _DEBUG_C #include "cmios.h" #include "pic18f452.h" #endif void Init(void) __wparam { MIOS_SRIO_UpdateFrqSet(1); // ms MIOS_SRIO_NumberSet(NUMBER_OF_SRIO); MIOS_SRIO_DebounceSet(DIN_DEBOUNCE_VALUE); // gestion de l'anti-rebonds pour les DIN MIOS_SRIO_TS_SensitivitySet(DIN_TS_SENSITIVITY); MIOS_AIN_NumberSet(AIN_NUMBER_INPUTS); MIOS_AIN_UnMuxed(); MIOS_AIN_DeadbandSet(AIN_DEADBAND); // définit la variation minimale à laquelle soient sensibles les AIN. } void Tick(void) __wparam {} void Timer(void) __wparam {} void DISPLAY_Init(void) __wparam { MIOS_LCD_Clear(); // print static messages MIOS_LCD_CursorSet(0x00); // first line MIOS_LCD_PrintCString("HELLO"); MIOS_LCD_CursorSet(0x40); // second line MIOS_LCD_PrintCString("WORLD !!"); } void DISPLAY_Tick(void) __wparam {} void DIN_NotifyToggle(unsigned char pin, unsigned char pin_value) __wparam { } void AIN_NotifyChange(unsigned char pin, unsigned int pin_value) __wparam { MIOS_MIDI_BeginStream(); MIOS_MIDI_TxBufferPut(0xb0); MIOS_MIDI_TxBufferPut(1); MIOS_MIDI_TxBufferPut(pin_value); MIOS_MIDI_EndStream(); } #ifdef _DEBUG_C extern void DISPLAY_Init(void); #endif main.h : // $Id: main.h 234 2008-03-28 23:10:41Z tk $ #ifndef _MAIN_H #define _MAIN_H ///////////////////////////////////////////////////////////////////////////// // Global definitions ///////////////////////////////////////////////////////////////////////////// #define AIN_NUMBER_INPUTS 8 // number of used analog inputs (0..64) #define AIN_MUXED_MODE 0 // set this to 1 if AIN modules are used #define AIN_DEADBAND 7 // plus petite variation de valeur à laquelle les AIN soient sensibles. // Les grandes valeurs réduisent la résolution, mais aussi l'hypersensibilité aux petits mouvements. // 7 is ideal for value range 0..127 (CC events) #define NUMBER_OF_SRIO 2 // max(nombre de 74hc595, 74hc165) #define DIN_DEBOUNCE_VALUE 10 // anti-rebond #define DIN_TS_SENSITIVITY 0 // sensibilité du touch-sensor (j14; pin 27=RD4 du PIC). 0 si inutilisé. ///////////////////////////////////////////////////////////////////////////// // Global Types ///////////////////////////////////////////////////////////////////////////// typedef union { struct { unsigned ALL:8; //vecteur de flags sur un octet }; struct { unsigned DISPLAY_UPDATE_REQ:1; //réaffichage de page }; } app_flags_t; //prototypes MIOS void MPROC_NotifyReceivedEvnt(unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam {} void MPROC_NotifyFoundEvent(unsigned entry, unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam {} void MPROC_NotifyTimeout(void) __wparam {} void MPROC_NotifyReceivedByte(unsigned char byte) __wparam {} void SR_Service_Prepare(void) __wparam {} void SR_Service_Finish(void) __wparam {} void ENC_NotifyChange(unsigned char encoder, char incrementer) __wparam {} #endif /*_MAIN_H*/ I attach the hex I obtain, but I don't think this is the problem - anyways it's the same with other sample apps. I've re-plugged my LCD in order to see if I could write to it with miosstudio and .... I always got my row full of unexpressive blocks. Its datasheet mentions an initialization sequence, but I guess this is done by the PIC on startup ? Anyways, I ain't got no input MIDI messages on pot turning. I assume that since I receive checksums while uploading, and anyways using feedback from core, the datas I send actually reach Rx. Just to be sure, I led-tested it like in troubleshooting test in 3, and sent a sysex with midiox : tadaaaaaa ! it flickers ! (great progress again, because up to now it did hopelessly not). So, the upload seems to be successful, but the PIC then doesn't behave like it should. Weird. Does the sysex on startup always prove for sure that the PIC is OK ? (Now that I solved my upload problem maybe I should move or rename this topic ?? Besides, [glow=red,2,300]NOTE TO THE READER : THE MAIN LESSON HERE IS ALWAYS USE MIDI CABLES.[/glow] Maybe not the only thing I had to fix, but the greatest help I think .) project.hex project.hex

YAAAAAAY GREAAAAAAAAAAAAT !!!!! I finally managed to have a correct loopback in miosstudio !!!!!!!!!! But curiously not in midiox, even with the "attach input to output" unticked, and devices closed then re-opened, I still have this infinite loopback. Anyways I just made a great step forth !!!!! Thanks fellows ;) Et vive mios studio !!!! Now I'm getting out for a little while, I need fresh air. I will go on in my midistuff debugging later and give you the freshest news. I feel this is all close ..... Already get my champagne ready .....

OK forget my last post, just crossed posts ^^ Errrrr .... no I'm not using those on parallel, anyways on my PC midiox won't open ports that miosstudio uses ....

In MIDIox I have done nothing more than selecting my device - the one I named "noah's ting" - on both midi input and output, and in MIOSstudio I've never changed anything in the internal routing, excepted linking my device in left panel to MIOS studio in port and MIOS studio out port in left panel to my device. I join the screenshots. EDIT : ok lylehaze I'm trying it, but this was the first thing I did and I did have this infinite loop, so I thought I misunderstood and that's why thereafter I cabled the whole loop including core's opto. By "removing the link", I assume you mean unticking the lil' box at the bottom of the routing window ? Thanks again for your help. mios routing.JPG midiox routing.JPG mios routing.JPG midiox routing.JPG

OK now I use MIDI cables and I finally have a loopback. Here's the configuration : MIDIox -> GM5 OUT <----------> CORE IN -> OPTO (pic not stuffed) -> CORE OUT <----------> GM5 IN -> MIDIox. But ..... it loops back so well that I fall in an infinite loop everytime I send something, until I unplug any midi pin ! The good thing is that I have exactly the same messages on both input and output, and at the same times. One more bothering thing is that when I unplug a midi pin to break the loop while sending sysex, or when I exit midiox ...... My PC reboots. So ..... driver issue ? I firstly thought the issue was due to that core and gm5 are commonly grounded, so I removed the ground pin of my core midi out, but it didn't fix the problem. One troubling fact I have to point out is that on pic's startup, as I already said, I receive the sysex on BOTH INPUT AND OUTPUT, that I don't take for normal. Lylehaze, I'll do the tests you recommand as soon as I have a correct loopback, because if I understand well, they're aimed at seeing if every part at the pic side of opto is in place and/or works well . Unfortunately I actually have no scope, used that at school but can't anymore now that I'm in holiday ! but I guess if I send either a continuous FFFFF.... (high midi state) or 00000.... (low midi state) sysex, I will be able to use a multimeter instead and see if the voltages across the midi path are those you nicely computed for me, right ? So please don't remove your post !! OK fellows, now I try on either another PC or with another driver, though I'm afraid if ploytec's doesn't work, none of them can something for me ... EDIT : when I unplug the ground on core out, I receive, on key hitting, a 256 bytes random sysex that also appears in output monitor, and this time without infinite loopback. Just to be sure : I haven't cut opened any jumpers on gm5, so the five ports appear in my devices list. Am I right to chose the first for both input and output ? Anyways, if I check the schematics (again), it's the only one I'm actually using. And, obviously, if I chose for example the second port for input, I have no loopback. So ..... should I cut the jumpers ? EDIT 2 : no, forget that ground stuff, it's all random. I just re-made it and had exactly the same infinite loopback than described.

Right back .... OK I went buying my midi sockets, soldered them on gm5, plugged one cable between them and .... Still nothing. I can't f***ing get my output messages to the input. I had a polarized 1uF cap on C3 that I thought it could be the issue. I replaced it with a non-polarized, it didn't change anything. I still see my gm5 led flicker when hitting a key or releasing it but nothing in the input. So... gm5 issue ? Driver issue ? Cable issue (I tested both of them) ? PC issue ? On the other hand, I still have no current variation on the pic side of core opto, though everything is well stuffed after one more drastic check. Unfortunately they didn't have any 6n138 so I'll have to reorder some from the internet. One more 'strange' thing : on startup I receive the sysex on both input and output monitors, is it normal ? Heeeeeeeeeeeeeeeeeeeeeeeeeeeelp !!!!! EDIT : I don't exactly know how it happened, but hot-unplugging my gm5 and somehow randomly handling it, I finally had alot of midi events on both input and output of midiox !!!! Grande première !!!! But .... it leads to midiox crashdown.

Gosh I made a silly answer ... Ok forget what I wrote .... I just ensured that all my pull-up/down resistors are stuffed, and that the opto is fed (like I did already many times), everything is OK. So why don't I have any current signal at Rx ?

Hi lylehaze Hey.... After having read from you on PSUs I'm not sure I will discard your advices so fast ... Anyways I bet they would say A, too. Zeno's paradox..... ;d Seems like I'll never reach my goal because I always got a half of the remaining way to run.... But you're right every half forth is good to take. Outch my forehead.... Careful, if I slap it too hard my poor head will burst. But, yeah, didn't realize that current stuff at all. A led plugged in series with a resistor between the outings of my pseudo-midi connections flickers on keyboard hitting though ... But, in this case, maybe it is the resistor that creates the current ? So, maybe the issue finally comes from the opto ? Although it passed the standalone tests OK, I point out the fact that the test in 3 : Rx pin - led|>|- 220 - gnd leads to the led lighting but not flickering on receiving events. So, what ? Can I directly go buy another 6n138 or can my gm5 in some manner produce a voltage but zero current signal, or (put whatever you want in here) ? If so, is there a workaround on the gm5 itself ? (hope not on the chip because I will absolutely not be able to modify it and I think it really has been made with all material you can ever dream about to solder SMD, and moreover not by me but by an old electronics guru I can trust as well as smashTV). And... what do you mean "the "other side" of the circuit" ? Because the PIC seems OK and my board as well ... For your suggestion on MIDI cables, OK, it's worth trying but I'll have to purchase two extra MIDI sockets (I have only two and two cables that I'm not using now). Do you think it still could be the "guilty part" even if : - I do receive my sysex at startup (core midi out - gm5 midi in OK (?) ) - I do see the led flicker when shortening core midi in +/- (gm5 midi out - core midi in OK (?) ) Do you guys all think I should remove the gm5 opto from its socket to test it, too ? (I'm always very reluctant on doing that because always fear damaging with my big fingers) And, finally, the reason why I woke up this night : I'm too dumb. Another forehead slap. Actually, when I did those tests on GM5, I don't know why, but I think I didn't try the loopback configuration, because it was satisfying enough to see both incoming and transmitted signals. But I just thought - and got out of bed - those two things don't mean that either GM5 or computer can handle both directions AT THE SAME TIME. Or maybe I'm saying nonsense, maybe MIDI is made of such a way that messages going in opposite directions are never sent at the same time .... or USB .... dunno, just trying to understand. So .... up to now I thought there were no problem from this side, but now I'm not so sure of it. Maybe the driver (though, I'm using ploytec's, how can this be possible ?) Or my hardware USB config ? Is there a workaround, a mysterious option in my motherboard's BIOS I should switch ON/OFF like I already had to a thousand times ? I'm using a 4-ports USB cards plugged on PCI #3 slot, which has always been working fine with my other USB devices until now, my motherboard is an ASUS P4P800-X stuffed with a Celeron 2.60GHz (X86 type, family 15 model 2, brown eyes, curly-haired) . What makes me think of it, is that, since I began this adventure, I never succeeded in communicating with my computer without any problems. Firstly, I connected my core to gameport (which was actually recognized as a MIDI device), and .... same problem. Secondly, thinking I had my first PIC scr***d up and waiting for smash's, I tried to build a parallelport programmer, without any success (P18 started up, but never recognized my programmer, though I could switch LEDs ON/OFF with the Vdd/Vss... ON/OFF buttons, but with DATA IN never reacting, always stuck to 1). I tried every configuration for the parallelport from the BIOS (adress, (bi)directionnal ...), tried to (de)activate the interrupt requests and so on .... never worked. Thirdly, this. Nevertheless all my periphs work fine, I guess that if my motherboard was responsible for all that mess, I would already have encountered issues with them. So, let's sum it up : - could it be the core opto even if it passed the standalone test ? - should I check the gm5 opto, or could I have made any mistake on my gm5 pcb leading to voltage but zero current ? - (anyway I will try it but) could it really come from that I'm not using true MIDI cables ? - is it possible that my computer is the worst crap ever and definitely prevents me from having midi fun although I use enhanced drivers ? - one more thing I forgot : since it seems that I can both send and receive datas, but not the two at the same time, what will happen if I "don't use feedback from core" ?? After all, my MIDIbox will only be aimed at sending datas. But this time I won't try things I don't understand. Thanks a lot for all your suggestions ! Tomorrow I'll go trying it on friends' computers, before maybe shopping two MIDI sockets and a dozen optos. And try to make it shorter next time (hope your eyes don't cry too much when reading me). Good night guys.

Hy smash, hi TK, hi janis, good to feel your support ... Of course I trust ya ;) Your PIC undoubtedly works. BTW I've not thanked you. So thanks ! Love the stickers )) Anyways I made the tests prog1 to out2 just to follow the procedure, but since I receive the sysex string I don't think it was necessary.... It gives me to think (maybe wrongly ?) that the board is fine (at least the PSU and the circuitry that leads Tx signal to MIDI OUT), and the GM5 : MIDI IN to USB OUT too. And BTW my former one was not so dead after all :( But let's forget that Well, I have no grief against that, but ... OK, I already tried that : I have the MIDI NOTE ON and NOTE OFF messages in the output monitor on key hitting, but nothing in the input monitor ! It's even the first thing I did, before trying sysexes ... And yet ... With the oscillo, I saw a few bits incoming for both note on and note off events (unfortunately I lost the paper where I wrote down the datas I received, and have no further access to this material-but I remember it seemed totally OK). With the wave generator, I sent to gm5 a square wave oscillating between 0 and 5V, making its frequency vary, so that I generated alea pseudo MIDI codes, and I actually saw a lot of random events in midiox input monitor, varying accordingly with my frequency variations. So I can't understand WHY the loopback test fails (and I already tried every possible combination of polarity, though I brought very particular care when plugging it for the first time, re-checking the gm5 PCB in accordance with my core). I must precise, I demanded for help soldering the gm5 smd chip to a technician from my school, who did it with monsters I can never afford, like a huge soldering oven and a binocular.... He even checked it after with very accurate testers and everything was fine. Soldering the other parts of the gm5 was mine, but I also checked it OK... One of the life's great mysteries I guess. My bad .... I didn't notice the difference so I made a copy-paste of the message I had when trying to upload the app of troubleshooting : TEST SW 1 (though, it's not a MIOS-level hex, so ..... it should start at 0x3000 ?) Actually, when trying to upload the hex I joined, the message was : The reboot request will lead to an error acknowledge, please ignore! Waiting for upload request... Received Upload Request Sending block #1 00003000-000030FF And then nothing.... /*So I guess my toolchain is OK ? (BTW I'm also stucked from the software side because I spent two weeks writing my own custom app which finally worked on ACsim, but I can't compile it under the release target, seemingly due to some pointer's issue ... But that's another problem I'll post in the appropriate section when my MIDI stuff agrees to work).-*/ AAAAAAARGH !!!!! Wouldn't it have been wrong, it would maybe have been the key ... I've never been so disappointed by things working well ..... I'm deeply sorry for the mistake .... But thank you for learning me one more thing (these days I learn a bunch everyday, my head will soon be in a memory overflow). Funny you write me "before you're assuming that the PIC has to be reprogrammed", because before receiving smash's PIC, and after my "PIC burner friend" went away, I built a PIC burner working with P18 which, because of my computer's lousy ports, didn't even pass the compatibility test (neither did none of my roommates' computers. No laptop though.) Oh, makes me think ... You should maybe advise readers to make P18 compatibility tests, for example the very desperate one with the 100 ohm resistor between those two pins of the parallelport - with of course special care not to swap pins . (why not translate them ? I can make it if you want, hoping my understanding of german is still correct enough - and my english is not too bad ...). But anyway it was fun, and now I owe two 74HC14 I can build analogue sound circuits with... (like a theremin - to be followed ....) As I said, there's only two twisted-pair wires between core and gm5, which are both no more than 20cm long, so I didn't shield them with ground. The rest is the USB cable's business.... which knows it has to do his job well, or else it knows what will happen >) . And yes, I just checked it one million-and-second time, it's all OK. But thanks So what I think to do know, is to try with another 6n138, though it passed the standalone tests OK - or maybe to test the one on the GM5 ? but I would emphasize the fact that I take for sure it works in both directions, only not in loopback configuration - . Or, firstly, to do one thing I know I should have done, re-plugging my LCD .... What I'd surely have done if not so buzzy . But, I'm not sure at all that the LCD works, because with my former PIC, I managed to have my second line full of blocks, but never "Ready" or "Hello" or whatever I tried to make it say with MIOSstudio, and curiously the backlight had worked for a few hours before slowly fading to dark and desperatly staying that way - with the blocks always here, though (checked the BC338 OK). Writing all that I'm thinking to something : could it be my computer's responsibility again ? I mean, I was not at home when trying all those tests with oscillo and so on.... So, not using my computer... But right now I'm on mine and using ploytec's driver, and anyway I DO RECEIVE THE CORRECT SYSEX ON STARTUP. And the gm5 obviously receive - and transmits - MIDI data since its proper led flickers on keyboard events and so does the one I put on gm5 MIDI OUT . So I assume that making the same tests at home it would lead to the same results.

Hello everybody !! Let's get direct : I'm planning on burn it all and go buy a real, good-working MIDI controller. No, just kidding, love DIY too to give up that silly way... But I knew I had to be stuck one day, this day has come. Already tried many times to search for someone having my problem ..... Please don't hesitate to indicate me any post I could possibly have missed .... Here's the plot : my first attempt was a total failure. I purchased a virgin 18f452, then asked a friend of mine possessing a PIC burner to burn the bootloader on it. Back home, I happily saw the sysex messages every two seconds, then tried to upload MIOS, then .... things began to get messy. First, it failed, so, passing out all the good advices TK and others patiently gave to noobs like me, I tried whatsoever, like unticking or ticking every options that could possibly be, I didn't know at all what I was doing but did it anyway, until that - I don't really know how - MIOS seemingly came on the PIC, since from that moment, I only had the (good) sysex string on startup. I must mention, it was absolutely not obvious that I had to care on my PIC id number, which was curiously 70 and not the 00 expected (already saw it in a post, and confirm it should be put in FAQ - anyways it solved this guy's problem, not mine :( ) . Well, after that, totally unable to upload any hex file. I first thought I had my PIC f**** up because of my newbie's eagerness, plus, I found bizarre that its ID was 70. And I made many random manips, such as wildly (and dumbly) unplugging the pic, and so on in that kind of ABSOLUTELY MUSTN'T-DO stuffs.... Thought I really killed him. I so decided to calm down and patiently wait for another pic from smash TV, with already bootloader and mios on it, in order not to have to burn it by myself and just to be sure that things had this time been well done. Now, I received this piece of wonder, then re-checked for the millionth time my core breadboard (which had been meanwhile covered by dust), basic hardware tests passed OK again, brand new pic stuffed in and .... I receive the correct sysex string in both midiox and miosstudio (with this time ID 00). And I actually have the same problem than before : trying to upload a basic test application (compiled with sdcc under code::blocks - a simple code that is supposed to send midi cc#1 at channel one only when I turn the pot on PIN1), the upload request is received as expected, but then miosstudio tries to upload the first block and ... nothing more happens till I stop the process (yet I gave him a chance, waiting for an afternoon or so ^^). Looks like that : The reboot request will lead to an error acknowledge, please ignore! Waiting for upload request... Received Upload Request Sending block #1 00000000-000000FF I don't think it's useful, but I join both my codefiles and hex (made for a pic18f452 - character lcd displaytech 162c, 16x2 - no AIN module, pots directly connected on analogue input pins of the pic - DOUT and DIN both with 3 SR, but left apart for the test app). Anyways, it doesn't work with any other hex file. As I mentioned, I received the sysex string : F0 00 00 7E 40 00 01 F7 on startup. Though, The loopback test of gm5 doesn't work (although I checked with an oscillo at school : data are transmitted from the pc, as a led placed between gm5:out pins indicates, and when I applied a square wave on GM5:in, I received a lot of midi events, which seems to prove that my g35 is actually working - so why the loopback test doesn't work ?) - I tried "lowering the Low Level Output Buffer size (normaly set to 2048) and increasing the output delay" in midiox. Successless. Datas are actually transmitted by the pic, as the test out1 and the gm5 led both indicate, and moreover I do receive the correct sysex string at startup. Just to be sure, before test PC1 I just selected for both send and receive, the gm5 midi port 1 ; after, I selected all the five ports, it didn't work anyway. So, let's go again for all that troubleshooting stuff .... Test prog 1 : errrr ... I hope I can trust smashTV ? Test core 1 : quartz 10.000 AEC08H, rechecked the datasheet, actually a parallel cut. Test core 2 : not for me (I'm using V3). Test core 3 : working on a breadboard, with all connections checked by multimeters. Test core 4 and 5 : everything OK, ca. 0V on ground and 5.11V on Vdd. Test core 6 and 7 : polarities already checked a million time. Test core 9 : .... Test core 10 and core 11 : anyways I receive the good sysex string !!!!!! Test out 1 : led flickers, so does gm5 led on startup. Test out 2 : my midi out grounds are not connected (only a shielding if I well understood ?) Test PC 1 : first chose "MIDI USB port 1" on both input and output. Then tried with the five at the same time. Am I wrong here ? Test PC 2 : receive nothing (but as I mentioned, my GM5 seemingly works in both directions). Test in 1 : 220 ohms, red-red-brown, even checked with multimeter. Test in 2 : checked for the million-and-first time. Test in 3 : the led is lit but doesn't flicker while sending sysex (although the gm5 led does). This tends to confirm the idea I had that my core's opto doesn't work. Well, let's go forth .... Test in 4 : the led is still lit when connected at either pin 6 or 8 from the opto... Test in 5 : Ok, led flickers. Test in 6 (opto's standalone) : aaaaaaaaand ..... uuuuuh ? it WORKS ? led is on when j13:m- is free, off when grounded .... grrrr ..... so if the opto is fine, why does my led not flicker when connected on Rx and sending sysex????? Test in 7 : all my hopes rely on it. I beg you please, please don't work .... Blaaaah seems to work, I have 5.11 V (the normal voltage output of my 7805 circuitry) when switch cable open, and ca. 45 mV when closed. Test inout : gm5 led flickers, but nothing received. Tried all the possible configurations of the polarity, doesn't work as well. Test SW1 : unable to upload hex code again ... Test SW2 : this one I didn't burn by myself. Again, I blindly rely on smashTV bootloader's burning abilities. Summing it up : there's two main issues - I don't seem to have any MIDI signal relayed by my core's opto, and yet it seems OK (anyways I'll buy a new one and see) - I've seen from my eyes (greatly helped by an oscillo and a wave generator) that my gm5 works in both directions, though I don't receive anything when I loop it back and send him a sysex dump (and yet, its led flickers). Besides, I do receive a sysex on startup, so I don't understand why the loopback tests don't work. I use simple wires (about 20 cm long, pair-twisted) to connect to GM5, and have the MIDI out grounds from both core and gm5 opened. Could the issue come from it ? Oh, and something I forgot : I made my first attempts with the gameport, since I have no MIDI plugs on my computer. I thought the upload problem could also come from here, that's why I got on building a GM5. You know the following. Thank you for having read this hard piece of bla bla. minimal.zip minimal.zip

:D hé hé nan j'ai rien contre l'allemand (ni les Allemands d'ailleurs :P), c'est juste que j'ai eu beaucoup de mal à déchiffrer le thread, mais je pense y être arrivé ..... Non non, j'apprécie l'effort ;) Bon donc effectivement il semblerait que ça soit la raison de la présence de cette masse, l'anti-parasitage. Donc inutile dans ce cadre. Bin parce qu'en fait c'était la question ^^ Oui je sais j'ai l'air de poser des questions con comme ça mais avant qu'on me jette la pierre je tiens à préciser que faute de moyens, je dois attendre la mois prochain pour commander quelques pièces manquantes, et que donc en attendant bin .... je suis au point mort ..... alors je lis, lis, lis et relis, me documente, me pose une tonne de questions (que je ne me poserais certainement pas avec le matos sous la main puisqu'il suffirait de cinq minutes d'expréimentation pour voir si ça marche) ..... et RAAAAAAH ! j'enrage ;) J'ai envie de passer à l'action nom de d'là , je bous ! M'enfin merci pour toutes vos réponses maintenant je sais au moins que je peux enlever 4 embases MIDI et une paire de câble de ma liste de commande. Bien à vous

OK exactly what I was thinking (for the cable ground). Damn parasits ^^ But anyway it's clear (I think it's clear) that for this use it shouldn't mess around .... And for the same reason, as lucem explained it so well, that parasits such as "USB ground loop" are significant only in audio applications, not in digital ones - unless the fluctuations don't overcome the TTL level, I guess ... For the GM5 : no I just stuffed one optocoupler ...... Because for the moment I just need one IO..... I just was wondering this because for now I can't achieve my first testings, waiting the next month for my missing parts, so I'm still in my info-gathering phase. And think it would be dumb to erase those jumper tracks if later (who knows) I need it. But anyways, this is just a matter of days for me to try it out and finally know...... So don't get too bothered about it ........ Good night everybody EDIT : ah ah yeah maybe this should be sent to english section ..... But how the hell will I find it back without this "Fehlerteufelchen" i like so damn much ^^ ...... he he german is such a beautiful language. Know, two days ago I met two german people hitch-hiking and couch-surfing. What a pleasure for me to speak again in german, so many years after .....

Lut tout le monde, bon alors il semblerait que je sois le seul franchouillard à me poser la question, j'ai déjà eu quelques réponses sur les forums anglais et (outch) allemand - enfin il me semble avoir compris ce qu'ils disaient ^^ Bon m'enfin voilà : supposons que j'ai un core PIC avec les ports MIDI et l'optocoupleur montés, et idem pour le GM5 . (parce que pour d'obscures raisons d'alimentation on ne peut pas se passer d'optocoupleur pour la liaison core-gm5 ; la première solution à laquelle j'avais pensé était relier le J11 du core directement aux ports midi IO du gm5 mais apparemment faut oublier.). Donc la question est : à quoi sert la masse sur les MIDI outs, vu que de l'autre côté, le pin central n'est relié à rien ? En d'autres termes, puis-je me passer de 2 paires d'embases MIDI et d'une paire de câbles et juste relier les ports MIDI avec des bêtes fils, et si oui, qu'est-ce que je fais de cette foutue masse "en l'air" sur les MIDI outs ? Bon plus simplement, si quelqu'un d'autre que moi utilise un core PIC et un GM5 (sans beaucoup de périphériques gourmands en courant, perso y'aura 8 potards, un DIN avec 3 SR, un DOUT avec 4 SR, et un LCD 2*16 sans rétroéclairage), je serais intéressé, si ça fonctionne et que c'est autre chose que embases MIDI - câble - embases MIDI, pour savoir comment il a fait la liaison. Dernière chose, toujours sur le GM5 : est-ce qu'en mode 5 IO (les trois jumpers fermés) on peut n'utiliser qu'une IO ? Ou faut-il absolument se placer dans la bonne config jumper ? Voilà , merci de vos réponses, sur ce je me remets à ce foutu soudage de SMD avec fer à 2 balles. Mais j'y crois, j'y crois.

Got it ^^ Thx for the explanations. Just another lil question about the linking between the CORE and the GM5 : ok I stuff the optocopleurs circuitry. But can I just use simples wires instead of MIDI cables and sockets (two per MIDI cable, on DIN:pin 2 and pin 4) ? I guess yes, but I don't quite understand the role of the ground pin on MIDI outs, since the facing pin of MIDI ins is not connected to anything ? And a last question that has nothing to see with it, but can I use only one IO in 5 IO mode on the gm5 ? Else I'll have to cut some jumpers. I mean, "who can the more can the less", but electronics is such a strange world ....

Yeepee !! Got mine yesterday 8) What a cool birthday gift for me ^^ Thanks a bunch man.

Yeah the adventure is going on !!!!!!!!

OK abcmann, that all makes sense now ;) Aaaaah and I just understood that this "ground loop" when you power from USB is bothering only for audio applications ..... still don't see why it doesn't bother us for MIDI messages but ok. Not sure that USB powering will be enough since I'll have an LCD (w/o backlight though) - and I actually bought and (proudly :D )mounted the PSU with capacitors and 7805 (my first circuitry ever he he) so I would be soooooo pleased to use it somewhere in my midithing - but anyways you're right, I've been so used to buy on the internet that I just forgot "physical" stores round my place. So an extra optocoppler will probably not be the worst difficulty on my midi-quest )) .... lucem : Ich bin versichert. Es ist genau was ich glaubte ^^. OK y'all, thanks a lot, now I can get back to my today's resistor sorting activities. Tschüss !

Hi guys, tried the best I could to understand your subject but replying in german is beyond my abilities, I fear ..... (english asks me already such an effort ^^) So, still in the informations-gathering phase, I found this subject while wondering myself exactly the same question than amiga-falcon - just because my first order ever (he he) is already running and I don't wanna have to pay the ship fee just for one more small 6N138 :) Actually I just ordered one because I thought that one day I'll maybe have to use real MIDI ports, but I will begin only with USB, so my plan was to let the optocoppler, the DIN jacks and so on .... unstuffed and, as amiga-falcon did it, just wire between core:j11 and gm5:j6. Why did I poor lil noob think it should work ? Just because of that, found in the GM5 page : "GM5:J6 : Digital MIDI IO pins. Can be used for direct digital connections to J11 (MIDI Link port) of the MBHP_CORE module. Connect a J6:Ox pin to J11:MI, and J6.Ix to J11:MO. Up to 5 cores can be bidirectionally linked this way. Ground (J11:Vs, don't forget it!) is available at J7. For audio applications like MIDIbox SID, MIDIbox FM or MIDIbox CV it is recommented to use an optocoupler at MIDI In to avoid a ground loop between USB and audio (-> 50 Hz hum!) For a full featured 2x5 MIDI Interface, line I2-I5 and O2-O5 can be connected to a breakout board with 4 additional opto isolated MIDI INs and 4 additional MIDI Out Jacks." (And I precise, I'm just trying to build a very basic midibox w/o any of the features listed beyond). Yet, I understood all what you guys said (I think ? Mein deutsch müsste sich verbessern, aber ich habe noch Errinerungen von meinen alten Schulja(ä?)hren). So ...... Can't help being confused ...... ???? (my only idea about it is that it's valuable only when the GM5 is the main PSU ..... right ? And in this cas, assuming that I only use LEDS, pots and buttons, is this worth providing power for the core through USB ? This famous "ground loop" couldn't scramble my MIDI messages ?) Sorry for suddenly lowering the level in this topic . Tschüss ^^ EDIT : of course you can answer in german ^^ won't hurt

TK > Great ^^ !!

Have I got a chance to be in ? Pretty please ^^ I'm sure there's one or two chips you guys don't know what to do with ^^ (besides when I signed in the ordering amount was about 248 ...... but I know life is sometimes cruel ;p )