haesslich

Hi everybody. How fast can I load 2 douts (8x74hc595) seriell connected?? - means just 3 wires connected to the microcontroller. mfg brain

Hello! OK i checked the sc signal. While the transient process the sc signal goes shortly down to -2,5V!!! (1µs/div) So I disconnected the sc wire of the DIN and DOUT and changed the measuring point to the pic - but still the same. The ribbon cables I changed some days ago. There was another strange thing: as I told, if I disconnect the last DIN everything works fine on the user side, but nothing changes on the bus!? I found out that I only have to disconnect the SC-wire from the third DIN and everything works (on the user side - nothing changes aon the bus) So I think we set some limits to the problem but for me this seems to be mystery ;D by the way: we use HC ICs mysterious Daniel

Hi Thorsten. I checked the edges some days ago. They dont look like digital - they have a enormous transient process, about 2V and they need some time to come to level. I do not think that the dout has any problems, because as i sad, they act like they should. If there were some leds flashing (which should not flash) i could see flashing bits on the oscilloscop. so the pic sent these messages! So one point is clear the transient process is not correct - but how to handle this problem?? Daniel

Hi tk thanks for these informations. we will test it on the next debugging session. I did the whole sunday tests on the seq. So i'll write down my results - perhaps somebody can find out a pattern. Now i'm more sure than before that the mistake is on the DIN modules: If i disconnect the third Din module, everything (the leds) works fine. Don't say therefore the mistake must be on the third DIN module. I checked it with three! different din modules, even if there is no 74HC165 in the socket, the leds go mad. There were no changes on the measurements on the bussystem if i connect or disconnect the the DIN#3, the bus signals seem wrong to me everytime. only changes in the behaviour of the LEDs, when i connect or disconnect din#3. Then i thought the mistake must be in the second modul - but i didnt find anythig. So i did a grand measuring: I checked every in and out of the bus at the ics (Pin9, Pin10) I found two different oscilloscop pictures. The first which i will call "OK" in the following looks like this: ____ ______________ ______________ __________ |_| |_| |_| the second one witch i will call "wrong" in the following looks like this: __ __ __ ____| |_____________| |_____________| |_________ DIN#1: IC_1 Pin_9 OK Pin_10 OK IC_2 Pin_9 OK Pin_10 OK IC_3 Pin_9 OK Pin_10 OK IC_4 Pin_9 OK Pin_10 wrong DIN#2 IC_1 Pin_9 wrong Pin_10 wrong IC_2 Pin_9 wrong Pin_10 OK IC_3 Pin_9 OK Pin_10 OK IC_4 Pin_9 OK Pin_10 NO SIGNAL! In some case IC4 of DIN#1 inverts the bus to wrong and IC2 of DIN#2 inverts the bus to OK back DIN#3 -> not connected LEDs are ok, even the bus looks strange for me DIN#3 connected -> LEDs go mad ANYBODY an idea?? i'll check with the mios debug interface next time, when i have energy and motivation for a debug session and will post the results here afterwards ;) Greets brain

hi doc! i don't think that the voltage is the problem in our case, because the voltage regulator does not even get significant hot. (without any heatsink). for testing the seq. i lately used a small lab-voltage supply. i don't believe that this is too small. (should be at least 1A, i can check on that). but i did not check the current after the regulator...

edit: english version: i'll explain from the beginning, i hope to reduce confusing ;) we (haesslich&braintu) built the seq. v2.4 because we only had one of the "old" pics. some leds startet blinking wildly when certain combinations of buttons were activated. example: after starting the seq. the steps 1, 5, 9, 13 were lit up (just like they have to be) but LED 8 was blinking wildly. after pressing another button ~ 4-6 other LEDs started blinking wildly. when playing, the "cursor" did not invert these LEDs but just lighted them constantly up. (the steps thet were set regularly were inverted when the "cursor" went through the pattern - just like they should be.). today we used the oscilloscope to measure the bus. at first everything seemed to be okay (bus signal = low as long as no step set; bits set the bus signal high), but then we found out that step-button 9 kind of inverted the bus signal. in this case the bus was constantly high and by setting any step, the corresponding bits pull the bus signal to low. and exactly then our special friends among the leds started going wild ;-) next i started measuring the bus signal on all ics. at the pin where one ic gives the bus signal to the next one in a row. i found out, that some chips hat the right signal levels (bus = low, bits = high), and some had wrong levels (bus = high, bits = low). but: interesting that the wrong signal levels were changed to right signal levels on some chips. [this is the point where i got confused ;-) ] for example i measured this: ic_1 -> right levels ic_2 -> right levels ic_3 -> wrong levels ic_4 -> right levels then i looked again on the bus at the dout module (on the oscilloscope screen). and i recognized: indeed here i could see a wildly blinking bit synchronized to a wildly blinking led. therefore i think that the main module sends out these commands, right? but now i don't have any idea what to do next. i guess that some connections (maybe at the buttons?) have switched ground and signal. but on the other hand: i connected the ground in star-shape. (i did not use the ground on the din and dout for the buttons and leds but connected all led and button grounds to one line which i connected directly to the ground of the voltage regulator on the core module). if buttons in this case would have switched connections, the ground would be pulled to 5V. both of us checked the dout and din modules for shorts, optical and with multimeter. my last idea is to desolder all connections and solder again with heat shrink tube. before i do this i just wanted to check here again. sorry for the confusion; i think we discovered a real problem in our seq. (this time not interpreting some menu-feature as a bug or hunting ghosts or anything; i wish i could make a short video of the blinking leds. it's lighting up very short and not really bright, but very fast and quite randomly.) i hope i could explain more clearly now, have a nice weekend! brain and in german: Hi thorsten ich schreibe mal in deutsch - hoffe das ist ok - kann ja nachher die ergebnisse nochmal auf englisch posten. Ich fange nochmal ganz von vorne an. Wir (häßlich und braintu) haben den seq aufgebaut. da wir noch den "alten" pic haben ists nur möglich die version 2.4 aufzuspielen. die leds haben bei bestimmten tasten angefangen zu blinken. wenn der seq gestartet hat leuchten step 1,5,9,13 - wie es sein soll. zb led 8 flackert aber. hat man jetzt noch eine weitere taste gedrückt - haben noch ca 4-6 weitere leds geblinkt bzw leuchteten einfach auf. wenn der step an den stellen war, wo fälschlicherweise leds leuchten wurden diese aber nicht invertiert! heute haben wir dann das oszilloskop an den bus gehalten. zuerst schien alles ok (die busleitung war low und bits wurden als high gesendet), aber dann ist uns aufgefallen, dass beim drücken von steptaste 9 sich die pegel gedreht haben. der bus war jetzt auf high und die bits wurden als low gesendet - jetzt begannen auch die leds (verstänlicherweise) auszuflippen. dann habe ich den bus an allen ics gemessen. also immer dort wo der eine ic die daten an den nächsten weiter gibt. hier ist aufgefallen, dass manche ics den richigen pegel hatten (low = bus, high = bit wird gesendet) und andere den falschen pegel hatten (bus = high, daten senden = low). es war aber so dass nicht, sobald ein ic den pegel gedreht (also "falscher pegel") hat der nächste zwangsweise diesen übernommen hat, sonder es kam auch vor dass ein ic diesen wieder richtig gedreht hat. so sah zb eine messung so aus: IC_1 -> richtiger pegel IC_2 -> richtiger pegel IC_3 -> falscher pegel IC_3 -> richtiger pegel dann habe ich mir ein bit einer flackernden led am bus (auf dem oszilloskopbild) rausgesucht. und hier wurden tatsächlich die befehle vom pic aus an das dout modul gesendet. dh man sah synchron zur led auf dem oszilloskop ein bit "blinken". also schließe ich daraus, dass der fehler an den eingängen liegt da der pic ja tatsächlich aus irgendeinem grund meint er müsste etwas an die douts senden. Ich habe aber keine ahnung wie ich weiter vorgehn soll. meine vermutung ist, dass manche taster enen schluß gegen plus anstatt gegen masse legen. dies kann aber eigenlich nicht sein, da ich die masse als sternmasse verkabel habe, soll heißen ich habe nicht die massen an den douts und dins benutzt sondern alle massen der taster und leds in reihe verbunden und diese auf die masse des 5-Volt outs auf dem core modul gelegt. würden taster einen schluß gegen plus bilden so müsste nicht mehr gehen, da die masse dann auf 5V läge. Ich habe echt keine Idee was ich noch machen kann. Die dout und din Module habe ich mehrfach auf kurzschlüsse optisch und auch mit dem multimeter getestet. meine letzte idee ist jetzt noch alle taster abzulöten und neu zu verkabeln. bevor ich diesen aufwand jedoch betreibe wollte ich nochmal hören, ob du eine idee hast was ich noch tun könnte um diesen fehler zu lokalisieren. Ich hoffe ich habe mich verständlich ausgedrückt. schönes wochenende noch brain

Hi. I ve done a lot of measureings. Now Im very shure that the problem is somewhere in the bus system. I checked the bus at every buspin from the ics and found out something strange. on some pins its a low level. bits are sent with a high level. on other pins this turns around. teh bus state is high and bits are sent with a zero. so tk or someone els whats the normal state? and if i push button like step9, pla or braek the state on the ics switch. anybody an idea??? please help!!

okay i checked with the srio interconnection test, everything seems to be okay. next i had a look for shorts on the dout module, found some, soldered properly (this time without short circuits ;) ) again but this did not solve every problem. here is one fantastic example of the chaos :) i set to 48 bpm so that i can see more clearly what's appening. i set no step, and no led lights up. well as long as i don't change into the menu: in the bpm menu LED 4 blinks. back in the main page it stops blinking. i really do not have any idea what this is supposed to be :) is there a possibilitiy, that the short circuits destroyed the shift registers?

so i checked every important connection, and changed the ics on the dout. the only thing that changed is the, lets say error-behavior. the led behavior is realy to complex to discribe it, just an example: after swiching on the seq stepLEDs 1,5,9,13 are high, 12 and 16 jitter. same with the previous ics: 1,4,8,16 are on, if you hit a step button the LED from the step befor goes high, just the led! - in the lcd everything is correct. I hope somebody understands what i mean. i have no idea what could be wrong

Hi. no everything else is allright. If I push for example Step 1, I can see the "C-3" goes on in the LCD. The steps are even given out correctly to MIDI, as I said, tested it with Laptop and Reason. OK - I try to make some usefull tests to describe the LED behaviour. Then i will leave a massage in about 2h. thx

Hi everybody. Finished yesterday our Seq-Prototyp. Works realy gread and it makes realy fun! ;D There is still one mistake left. The 16 step LEDs seems to be "mad". They do not flash as they should. When I build the CLock-Box some time ago, there was a kind of the same mistake. But I can't remember what was the solution. May there be something wrong with the DOUT, cause I tested the Seq sequencing Reason and everything works great. Maybe there is a kind of data-transmission problem. Maybe wireing mistake? If anybody got an idea, please tell me Thanks braintu

hallo! habs hinbekommen. offenbar musste ich die flags wirklich setzen - nachdem ich die mit dem main.asm abgeglichen hatte, und neu programmiert, tat es jedenfalls. und danke für das angebot, Ijmarkus! so eine hilfsbereitschaft ist ja auch nicht selbstverständlich. also warten braintu und ich mit clockbox UND midibox seq. auf :)

while i am playing around with the code i'd like to show some pics of the hardware prototype: the fader is planned to work as a pitchbender and is fitted to center position via springs. this is however not implemented in the firmware yet ;) in the next step i will configure the computer-keys to work as combined start-stop keys. i plan to set up an array which contains the actual state of the channel and with every hit to a key i invert the corresponding state. but i guess i won't even need to programm that array, i might have seen an array with exactly the same function on friday when i had a first look to the sourcecode...

hallo! beim mios aufspielen ist mir ein fehler unterlaufen, danach war der pic18f452 nicht mehr zu reanimieren :-/ ich habe dann versucht mit meinem brenner (elektor e-blocks) den chip zu löschen und den bootloader neu drauf zu programmieren, aber auch danach kamen keine statusmeldungen vom chip im miosstudio an -> keine reaktion beim aufspielen vom mios :-( kann ich den chip getrost vergessen oder gibts noch eine möglichkeit den zu retten? grüße!

though having not tested the defective module any further (this will be done as soon as i begin putting together the modules for the midibox seqv3, i'll need the module there) i have a question: i'd like to set the start- and stoppoints for the multi midi outputs to the next measure instead of the next quarter. i guess i have found it - in the MCLOCK_TICK() i moved a #if multiclock part from the if( ++mclock_ctr_24 == 24 ) { loop to the if( ++mclock_ctr_beats == 4 ) { loop regards, florian

okay here are my test-results: one button on the second shift register triggered all 128 midi notes in the midio128 application. okay next i started measurements with the srio_interconnection_test. i measured the SC and RC levels directly at the 74HC165 pins. as far as i could see, they seemed to be all right. so nothing good here. after all that mess i tried another DIN module and now - well: the midibox works (midi out ports and corresponding LEDs are messed up in order, but in general the box works). so: the error is within the DIN module. but i did not manage to locate it with the srio_interconnection_test - do you have any further recommondations?

i recently finished the clockbox incl. the hardware for the multi out option. i recompiled the application with the multi out flag, programmed the pic but the multi outs seem not working properly. the leds are lighting up fine, midi clock comes out of the 8 additional midi outs, but the play and stop buttons do not work. the play buttons just do nothing, the stop buttons stop some random outs (incl. turning off some leds which do not correspond to the stopped midi outs). i checked the connections to the core module and tested the pushbuttons seperately. seems right. does anyone have a clue, where to look for the bug? i don't know where to look elsewhere in the hardware for the bug. have i missed something in the applications code? thanks