ThomasT

Thanks. Good to know. I'll try that.

What do you mean with "fix"? Do you have an idea what a PSU for 22A looks like? Its not worth the efford, in normal operating it needs 2A or so. How should this be? No I havent.

Puh...I don't remember the number. But they are on Thorsten's list. I have already built...I just wnat to do some improvement because I had some other things to fix, so I wanted to update the software as well. Just as an importent tipp: never combine midiboxes as I did. Chain them as single *independent* devices. -> debug horror. http://www.krachwerk.de/projekte.html http://www.krachwerk.de/midibox/midibox.html

Hi, I'm just debugging an update of my software. I wanted to delay the fader movement so I tried to move them (after timing mechanism) in main::tick() or main::timer(). But this do not work correctly. Before I do further debugging I just want to asks if this can causes problems. Sometimes the fader moves, sometimes they don't. And there seems to be no rule. So I suspect a problem with interupt handling or something like this. Normal direct fader movment works perfectly. What's this for you my asks... I have 4 midiboxes with 8 faders each. Don't know why, but my ALPS faders take more current that Thorsten descriped. I think up to 700mA accourding datasheet. The problem is that my power supply offers only 5A on 12V. So I have only 150mA per faders. Thats not enough so movement of all faders together will not work properly. My idea was to delay the movement depending on the midibox id. midibox 4 moves directly, the next 8 faders of midibox 3 1s later, midibox 2 2s later midibox 1 3s later. Maybe the times need improvment. Why, midibox 1 as last and midibox 4 as first? The faders of midibox 4 moves faster. The ones of midibox 1 slowest. Don't know why. My be an problem of usage. (lower channels vs. higher channels) Only on events that causes movements of all faders. These are, reset (per menu or startup) and snap shot recall. In all other cases the faders move directly of cause. Thanks for any ideas. Thomas If this will work I will publish my whole code. But not before.

Hallo! Ich habe hier noch zwei alte Platinen mit 16F877 Microcontrollern. Midibox64 PCB nach dem Layout von Greg. Soviel ich weiss ist die Platine im wesentlichen kompatibel zu den neuen PICs und MIOS Applications. Die Motorfader-Boards zum Ansteuern von 16motorfadern müssen leicht überarbeitetet werden, da die neue MF Application ein zusätzlichens Shiftregister braucht. Aber die Teile funktionieren (Baujahr 2001) und haben bis vor einem halben Jahr noch im Studio zu verlässig gewerkelt. Wenn jemand Interresse hat, bitte melden. Für Porto und einen kleinen Ausgleich für den 16F877 PIC würde ich die Teile verschicken, bei mir sammeln sie nur Staub. Ach, ja. Wer es nur zum Ausschlachten will: alle ICs ausser der PIC sind direkt gelötet und nicht gesockelt... Gruß Thomas

Hi, I redesigned my electronics, so I have the two Midibox64 Module including Motorfader boards left. If someone is interested I would send them for very little money. Faeatures: PIC 16F877 PCB design by Greg with no modifications. Motorfader-Board design by myself. (see: http://krachwerk.de/projekte.html and http://krachwerk.de/midibox/midibox.html) You can use those boards with little modifications with MIOS. As far as I remember the the main board can be used without any modifications but the motorfaderbaord need an additional shiftregister. Maybe it's useful for someone. Thomas

Übrigens, bin ich auch dabei eine Art Gruppenkonzept zu realisieren. Na ja dabei ist gut...Zeitmangel... Aber Konzept steht bereits. Wenn du mir die Arbeit abnehmen möchtest, Thorsten... ;) Und zwar plane ich mehrere Midiboxen in Kette zu verbinden. Die erste MIDI-Box hat die Steuerbuttons, die letzte die Displays. Ansonsten halt alles ganz trivial MIOS like mit einem Unterschied dass ich die MIDI-Befehle direkt in hex codieren will (so wie beim Peavey 1600). Die leaning Funktion hat sich nicht wirklich bewährt. Zu den Gruppen: Die Elemente (Buttons, Fader, Poties) sind in 3 Bänken aufgeteilt. D.h. sie existieren virtuell dreimal. (mehr geht nicht ohne die MIOS Funktionen per Hand zu umschiffen, MIOS Table etc.) Diese drei Bänke (Bankstick brauch und will ich nicht...) werden umgeschaltet. Für alle MIDIboxen in der Kette. Nun möchte ich aber nicht alle umschalten, sondern nur bestimmte Elemente, z.B. die letzten 8 Fader nebst den dazugehörigen Buttons und Poties. Also eine Befehl "schalte alles was zu den letzten 8 Fadern gehört auf Bank 2 um". Und alle was dazu gehört - die Poties und Buttons und die Fader selbst - werden dazu als Gruppe zusammengefasst. Auch wenn sie physikalisch auf verschiedenen cores liegen. Natürlich inklusive den Editierfunktionen Gruppe anlegen/umbennen, Bank Name editieren. Gruppe und Bank umschalten. (wobei Bankumschaltung nur auf Gruppe wirkt, Gruppe 0 == alle Gruppen). Jeder Fader etc. hat also nicht nur die üblichen Parameter, sondern zusätzlich noch eine Gruppenzugehörigkeit.

>TEXT_GROUP/TEXT_BANK/TEXT_FADER/TEXT_BUTTON bereits die Cursor Position, evtl. hast Du vergessen, diese anzupassen. Das könnte es gewesen sein.

>ist wirklich sehr vorteilhaft, per midi...sonst musst du immer den pic aus dem sockel nehmen, in den JDM rein und wieder zurück..... Falsch. Der lässt sich doch inline programmieren. Thorsten hat doch auch in seinen Layouts ein entsprechende Buchsenleiste vorgesehen. Meine sind sogar aufgelötet (SMD).

>mich würde mal interessieren, ob es möglich ist ein komplettes, lauffähiges MIOS (für MIDIBox 64 mit 64 pots/faders und 64 buttons) mit dem JDM zu brennen, da ich probleme mit dem "upload-via-midi" habe. ich habe schon mehrfach ein MIOS v1.6 (direkt) draufgebrannt. Das ist natürlich möglich. Allerdings musst du da entweder den AssemblerCode oder Hex Code umarbeiten, da im MIOS der Bootloader nicht mit drin ist. Ist aber nicht allzuschwer, allerdings weitaus schwerer als das MIOS per MIDI zu laden. >wenn ich den PIC (18F452) dann in das core-modul schnall, ein lcd anschließe (sonst nichts!) und strom drauf gebe, dann meldet sich das lcd ganz verheissungsvoll mit dem "startbildschirm" und wechselt anschließend zur anzeige "ready". Also geht es doch! Mehr macht das MIOS nicht! Du hast keine Applikation geladen. Erst damit wird die MIDI-Box zum Leben erweckt. Die Funktionen die ein Buttondrücke im MIOS auslösen laufen so ins Leere. Nichtmal ein nop wird gemacht... >aber danach passiert leider nix mehr!!! auch die buttons für die menü-steuerung (die ich schon versuchsweise angeschlossen hatte) helfen nicht weiter. Lade mal eine Applikation drauf die ungefähr das macht was du erwartest. Also z.B. Buttons bedient.

Hallo! Ich sehen kein Problem ein AT-Netzteil zu benutzen. Klar ist es oversized aber möglich. Du kannst direkt die 12V (mit Regler auf 8V runtergesetzt für Motorfader) und 5V benutzen. Ohne Spannungsregler. Mache ich grad auch hier. Allerdings nur zum Testen. Ich wollte das 100W NT eigl. in die Midibox einbauen. Ging aber vom Platz her nicht. Du verbrätst auch keine 197W! Sondern im wesentlichen natürlich nur das was du abnimmst. Also eben auch nur ein paar Watt. Deswegen kann der Lüfter eigl. auch abgeklemmt werden. Viele NT brauchen keine Mindestbelastung. Manche schon. NImm halt eine Glühlampe... Netzteil startet man indem "PS-ON" (meinst ein grünes oder braunes Kabel) auf Masse geklemmt wird.

Hi Thorsten und alle anderen! Mühsam ernährt sich das Eichhörnchen... Stand: Endlich Maincore mit zwei PICs fertig. D.h. erstmal der letzte PIC in der Kette montiert. An ihm hängen u.U. die zwei Displays. Hat sich einfach als günstig erwiesen. Ohne Display zu debuggen ist horror... Gestern tadellos hochgefahren bis zum "READY". :) Natürlich wieder von Freundin eingeweiht da temporär auf Fussboden abgelegt...diesmal musste aber nur der Versorgungsstecker dran glauben, letztens wars ein 25Euro Motorfader. :( Allerdings gibts ein klitzekleines Problem mit der Anzeige Software. Ich denke es ist nichts kritisches, aber ich frage halt mal parallel. Codeschnipsel: TMB_UI_DISPLAY ;clear screen call MIOS_LCD_Clear ;group in first line TABLE_ADDR TEXT_GROUP call MIOS_LCD_PrintString movf TMB_CURRENT_GROUP, W, BANKED call MIOS_LCD_PrintBCD1 ;@todo: group name ;bank in second line movlw 0x40 call MIOS_LCD_CursorSet TABLE_ADDR TEXT_BANK call MIOS_LCD_PrintString movf TMB_CURRENT_BANK, W, BANKED call MIOS_LCD_PrintBCD1 ;@todo: bank name ;last moved fader/poti/button ;a fader is a motorized poti... movlw 0x80 call MIOS_LCD_CursorSet TABLE_ADDR TEXT_FADER call MIOS_LCD_PrintString movf TMB_CURRENT_BANK, W, BANKED call MIOS_LCD_PrintBCD1 ;@todo: switch between faders/poti/button ; getting their names or printing its number ;last sent or recieved midi-event movlw 0xC0 call MIOS_LCD_CursorSet TABLE_ADDR TEXT_BUTTON call MIOS_LCD_PrintString movf TMB_CURRENT_BANK, W, BANKED call MIOS_LCD_PrintBCD1 ;@todo: use the last midi event ; not this dummy here return Aufgerufen wird die Funktion in main.asm in den User_Display Funktionen: ;; -------------------------------------------------------------------------- ;; This function is called by MIOS when the display content should be ;; initialized. Thats the case during startup and after a temporary message ;; has been printed on the screen ;; -------------------------------------------------------------------------- USER_DISPLAY_Init goto TMB_UI_DISPLAY ;; -------------------------------------------------------------------------- ;; This function is called in the mainloop when no temporary message is shown ;; on screen. Print the realtime messages here ;; -------------------------------------------------------------------------- USER_DISPLAY_Tick goto TMB_UI_DISPLAY Also eigl. simpel. Nur der Effekt ist nicht, dass alle vier Displayzeilen belegt werden, sondern immer nur in der ersten geschrieben wird. Es blinkt halt fröhlich wenn "BANK", "GROUP", "FADER" etc. nacheinander in der ersten Zeile des ersten Displays erscheinen. Nach der Doku und den Beispielanwendungen und den MIOS Sourcen sollte es doch so funktionieren. Wo habe ich was übersehen?

Hi Thorsten! I know the documentation. But I wanted to know if not only USER_MPROC_NotifyFoundEvent is called, but also USER_MPROC_NotifyReceivedEvent and three times USER_MPROC_NotifyReceivedByte during a midi-event. But I saw you uploaded the source code of MIOS. This will answer such questions. Thomas.

Hi Thorsten! After getting the first board running, I developed the main core board first. It's a horror for debugging without any dispplay or even a single LED. This board is ready (it may be still have some errors...) but not soldered. I have to check out what I need and then contact farnell and reichelt. And even then I will solder only the displays and the PIC. (some Rs, Cs and Ts too) It contains on one 200x150 board two core modules with 80 poties, 80 buttons, 80 leds and two displays connects to the second PIC which will be the last in the chain. It took a week to layout it. For some reasons I will not publish it... In this time I want to start to develope the software. And I have some questions and lack of knowlegdes... 1. How can the Inter-MB communication realized by MIOS? On your MB-Link page there are no hints how to handle such "masked" events in the software. Communication is neccessary for display (only the last PIC has a display) and for bank changes etc. pp. The first MB (this one you debugged...) must send a "all MBs please change the bank to 2" to all MBs in the chain. Or "only special faders change your bank". etc. 2. When exactly will this functions be called USER_MPROC_NotifyFoundEvent USER_MPROC_NotifyReceivedByte USER_MPROC_NotifyReceivedEvent What happens if two events come directy after each other? What happes if there are to many events to store? Does the last one win or will it be lost? What happens after MIDI-Timeout?

Post ist unterwegs. Weitere Infos im Beipackzettel.

Hi! I just had a little time to work on the midibox. As you may remember a got some bit errors while flashing the MIOS via MIDI-In. I burned the MIOS.hex directly into the PIC. The I try to upload a checkerboard-pattern from 0x4000. Again I got the right checksum, but some bit errors. It seems that bits are only lost, never doubled. Pattern like 01010101 mutate to 0110101... If I understand the UART/MIDI interface correctly the signal has no build in takt like SPDIF. So the incoming signal is sampled in shorter intervalls. I really don't understand why i'm getting this f****** bit errors. MIDI-ping works. Different speeds while sending the MIDI-syx did not help. Greeting Thomas

>Just to make sure, it's wired straight through I don't know. In principle yes. But it can make a difference if you using a female connector on the JDM PCB and a male plug or vice versa. I don't know how to explain. It's like looking from the frontside or backside. I don't remember what is right. I only remember that I interchanged the sides. (mirrored)

That would be true if nothing will ne loaded. But the bootloader sends correct acknowledge-messages with the rigth check sum. And if I read the PIC out than there was something loaded into the flash. I only have to check if this procedure works 100% correctly. Not today, perhaps this evening.

I still got the decribed behaviour. - I used external power (18V) for JDM. Ok, programming seems to work without problems. Even progrmming a 00-Buffer works now. - I sacrificed the first PIC and soldered another one to explude that this PIC was really detroyed. (BTW: I noticed that this new PIC could not be programmed without external power for the JDM, the older one could, but with errors, and reading problems - never the same reading result) - I burned the bootloader (ok) - I uploaded MIOS via sysex (ok, no error string) But MIOS will not run correctly. I get the request from the prim bootloader again and again. After each 2s. So I can imagine that there are only some possibilities: 1.) MIOS is not uploaded correctly (not very likely) 2.) MIOS crashes (my guess) 3.) MIOS has a bug (not very likely) Any Ideas?

Are you sure your com-cable is correct? I had similar problems until I realized that I interchanged the plugs. I used female where I should use mal or so. I maybe a crosscable should work. But I got voltages in the expected range, I did not realize it immediately. But clock and data was interchanged and the voltage were a little bit too low, AFAIR.

Mangels FTP Zugang hier, per email.

Es gibt aber noch ein paar Ungereimtheiten. Z.B. mag das Brennen mit dem JDM zwar Probleme machen. Ok. Aber auch das Auslesen und Schreiben über Sysex und Bootloader klappt ja nicht ordentlich. Und da ist JDM nicht mehr beteiligt. Ok, setzt voraus, dass der Bootloader ordentlich gebrannt wurde. Aber laut Prüfung ist er das. Es gibt natürlich auch noch andere Möglichkeiten. Hochfrequentere (== nicht mit Multimeter zu messende) schwingende Versorgundspannungen beim Sysexen. Allerdings gibt es eine auffällige Korrelation des Datenmülls in bestimmten Speicherbereichen. Besonders gut dort zu erkennen wo eine gleichmässig gefüllte LUT oder ähnliches liegt. Thomas, genervt weitersuchend und genau ahnend dass es irgendwas triviales ist...

Hier auch nochmal. Habs grad auch in de.sci.electronics gepostet. Habe mein Problem soweit eingrenzen können. ---------------------------------------------------------------------- Hallo, ich habe ein Problem einen PIC 18F452 zu brennen. Brennsoftware ist IC-Prog 1.05C und ein selbstgebastelter JDM Programmer der bislang gute Dienste bei 16F877 geleistet hat. Tests der Spannungen, alle ok. Von diesem JDM Programmer zog ich fünf Strippen zu den zu brennenden PIC. Dieser ist eingelötet auf der Platine (PLCC Gehäuse) diese Kabel werden mit Stecker verbunden wo normalerweise ds Jumper drauf sind. Das einzige was ich nicht gemacht habe ist den pull-down R an Pin RB5 zu verbinden. Laut datenblatt wird der nur gebrauch um den low voltage Programmmodues zu aktiven. Brauche ich aber nicht. (muss noch prüfen ob es das ist) Brennen klappt teilweise aber nur kleinere Programme. Ab einem bestimmten Speicherbereich z.B. so ca. 00A0 - 00F0 gibt es Bereiche in denen immer was anderes eingebrannt wird. Nicht die Bits die ich will... Bzw. ausgelesen wird. Bei Auslesen kommt es auch dazu, dass immer was anderes augelesen wird. Programmieren mit nur 0x00 nach vorherigem Löschen auf 0xFF (durch Einlesetest bestätig) ergab das auch in der Drehe um 00A0 nicht 00 gebrannt wurde sondern irgendwelcher Müll FFFF oder EFFF FEEE steht. (Auslesen mit IC-Prog und JDM) Ist der PIC defekt? Falls ja, könnte ich das selber gewesen sein? Gibt es andere Möglichkeiten, die diesen Effekt verursachen könnten? (bevor ich jetzt auslöte und ihn damit zerstöre) Danke und Gruss Thomas Thiele ---------------------------------------------------------------------- Ergänzungen für Midibox - Bauer: der primäre Bootloader funktioniert und brennt auch irgendwas in den PIC ein wenn ich versuche MIOS zu laden. Allerdings startet MIOS nicht. Es reagiert auch nicht auf ping. Der prim. Bootloader läuft weiterhin. Wenn ich MIOS direkt brenne, dann läuft es zwar. D.h. ping funktioniert. Aber ich kann keine Applikation laden. Also Beispiel habe ich das 8fach Motorfader-Beispiel genommen. Korrekte Acknowlege-String mit sinnvoller Checksumme werden geliefert aber nix passiert weiter. Ich erwarete ein Flut von Controller-Messages da die Potieingänge alle noch offen sind und daher zufälligen Pegel haben.

I wrote you an email on tk@midibox.org. Something I forgot tomentioned. I did not apply the pull down resistor on pin RB5 during programming. Its on the JDM bord but the PIC is directly soldered like in the core schematic. I just soldered 5 wires from the JDM board to a plug. And this I plug directly into JP3 while programming. The datasheet says it's only important during low voltage programming. I do not need the lvp bit. Right?

...I like talking to myself... But from the datasheet PORT B: "the weak pull-up is automatically turned off when the port is configured as output. The pull-ups are disabled on a Power-on Reset."