Sehr schön Nils!  :topjob:
Das Auge spielt eben mit 

LG, Lukas

Moin,

ich hol' das Thema mal wieder nach oben. In ca. 2 Wochen habe ich endlich Urlaub, und in der Zeit habe ich mir vorgenommen, ein wenig an der Software des Midiboards weiter zu stricken. Ich hab das Gespann jetzt gute acht Monate im Produktiveinsatz und bin sehr zufrieden, allerdings habe ich - hauptsächlich im HMI und der Programmierung - ein paar Bugs gefunden, außerdem möchte ich mich um die Baustellen Preset-Dump und -Reload und Einrichten und Kalibrieren der Expression-Anschlüsse kümmern, und eventuell doch noch einen Mixed-Mode (vier Preset-Taster und den Rest Instant Access) implementieren.

Zu den Bugs: Hauptsächlich UI-Sachen, z.B. beim Editieren und anschließenden Speichern wird nicht per LED angezeigt, welches Preset gerade aktiv war, und nach dem Speichern kehrt der Controller immer zu Preset 1-1 zurück. Kleinigkeiten eben.

Eine Sache macht mir allerdings etwas Kopfschmerzen, die ist mir in den acht Monaten jetzt zweimal passiert: Der Controller hat anscheinend irgendwelchen Quatsch rausgesendet, und plötzlich kam nur noch Gequietsche und Gerausche ausm Amp  . Ein Tritt auf ein Preset hat's wieder erledigt, da es beide Male tierisch laut war, konnte ich nicht genau nachvollziehen, was passiert war. Ärgerlich, und schwer zu finden, weil nicht reproduzierbar - passierte beide Male im Preset Mode ohne aktives Zutun meinerseits.

Da ich das Ding jetzt wie gesagt schon acht Monate benutzt habe, hat sich schon einiges an Presets im Gerät angesammelt. Da ich die beim Basteln nicht verlieren möchte, würde ich am liebsten das externe EEPROM (das interne EEPROM des AVR nutze ich derzeit nicht) sichern oder kopieren.

Ich blicke da aber nicht durch - gibt's was an passender USB-Hardware, um ein I2C-EEPROM auszulesen? Ich will an der Baustelle eigentlich nicht selbst anfangen zu basteln und zu programmieren, sondern würde lieber auf eine fertige Lösung setzen.

Jemand eine Idee?
Gruß, Nils

Salü,

Da ich das Ding jetzt wie gesagt schon acht Monate benutzt habe, hat sich schon einiges an Presets im Gerät angesammelt. Da ich die beim Basteln nicht verlieren möchte, würde ich am liebsten das externe EEPROM (das interne EEPROM des AVR nutze ich derzeit nicht) sichern oder kopieren.

Ich blicke da aber nicht durch - gibt's was an passender USB-Hardware, um ein I2C-EEPROM auszulesen? Ich will an der Baustelle eigentlich nicht selbst anfangen zu basteln und zu programmieren, sondern würde lieber auf eine fertige Lösung setzen.

Jemand eine Idee?

Du könntest dir einen Eprom Programmer besorgen. Da gibt es auch welche die serielle EEPROMs schreiben/lesen können. Allerdings wirst du den EEPROM aus der Schaltung auslöten müssen.
Wenn du also eh löten musst, würde ich mir an deiner Stelle das Programmiergerät sparen und statt dessen eine IC-Fassung einlöten. Zum Basteln kannst du dann ganz bequem das beschriebene EEPROM heraus nehmen (und auf Antistatic-Styropor zwischenlagern) und durch einen leeren EEPROM ersetzen.
Oder du schreibst dir selbst eine Software, die nen Mikrocontroller den EEPROM auslesen lässt und über USB/UART ausgibt. Dann mit nem Terminal-Programm auslesen und auf dem PC archivieren. (Zurückspeichern sollte die Schaltung natürlich auch können ;-) )
mfg Sven

Salü,Du könntest dir einen Eprom Programmer besorgen. Da gibt es auch welche die serielle EEPROMs schreiben/lesen können. Allerdings wirst du den EEPROM aus der Schaltung auslöten müssen.
Wenn du also eh löten musst, würde ich mir an deiner Stelle das Programmiergerät sparen und statt dessen eine IC-Fassung einlöten. Zum Basteln kannst du dann ganz bequem das beschriebene EEPROM heraus nehmen (und auf Antistatic-Styropor zwischenlagern) und durch einen leeren EEPROM ersetzen.
Oder du schreibst dir selbst eine Software, die nen Mikrocontroller den EEPROM auslesen lässt und über USB/UART ausgibt. Dann mit nem Terminal-Programm auslesen und auf dem PC archivieren. (Zurückspeichern sollte die Schaltung natürlich auch können ;-) )
mfg Sven

Genau das ist das Problem: Entweder ich bin zu doof, oder.... nee ich bin zu doof. Ich finde irgendwie keine EEPROM-Programmer, die serielle EEPROMS lesen und schreiben können.

Löten muss ich nicht, da das EEPROM gesockelt ist  .

Selbst löten und programmieren wollte ich eigentlich nicht, das raubt mir unnötig Zeit. Was ich allerdings machen könnte: Ich hab das myAVR-Board MKII, da gibt's ein I²C-EEPROM-Addon für. Dann muss ich zumindest nicht löten... Eien Software für den AVR und(!) den PC brauch ich dann aber immer noch...

Salü,

Löten muss ich nicht, da das EEPROM gesockelt ist  .

Warum tauscht du es dann zum Testen nicht einfach aus?
Für Programmiergeräte schaut mal bei Batronix vorbei.
mfg Sven

Naja, ich würde halt schon ganz gerne mit dem Datensatz, der schon im EEPROM ist, arbeiten. Aber eben mit einer Kopie  .

Batronix schaue ich mir mal an.

Okay, das ist wohl keine Option - das günstigste Programmiergerät bei Batronix, das serielle EEPROMs lesen kann, geht bei 160 Euro los....

Salü,

Okay, das ist wohl keine Option - das günstigste Programmiergerät bei Batronix, das serielle EEPROMs lesen kann, geht bei 160 Euro los....

Such mal in der Bucht nach "eprom programmer", da gibt es auch das ein oder andere Low-Cost-Gerät (PCB ohne Gehäuse).
Oder schau mal hier, falls du noch nen Arduino rumliegen hast: http://www.insidegadgets.com/2010/12/22/reading-data-from-eeprom-i2c-on-a-pcb/
Mit nem Steckbrett geht es ohne Löten und die Softwareänderung, dass du damit auch wieder zurückspeichern kannst, sollte für dich auch kein Problem sein (is en Dreizeiler ).
mfg Sven

Schau ich mir mal an. Ein Arduino-Board hab ich nicht, aber wie gesagt das myAVR-Board, welches ja mit der Arduino-Umgebung läuft, und eine kleine Zusatzplatine zum Anschließen des EEPROM ist ja schnell gelötet (oder für 'n Zehner gekauft). Softwareseitig scheint das ja doch überschaubar zu sein.

Danke!

Ich hab am WE etwas an der Software gefeilt und das Problem jetzt anders "gelöst", nämlich durch nachdenken. Da ich das Konzept des Controllers noch etwas umgebogen habe, muss ich die Presets eh neu erstellen, weil ich in dem Zuge einige Tasten umbelegen werde. Ich hab deshalb den µC und das EEPROM rausgenommen und mit neuen ICs weiter gemacht. Vorher habe ich meine Presets ganz Oldschool offline in einer Papiertabelle dokumentiert  .

Für die, die's interessiert: Ich hatte ein Einsehen für die Notwendigkeit, Presetauswahl und CC-Taster zu mischen. Jetzt ist es so, dass die obere Tasterreihe (13-16,Bank up/down) dem Abrufen von Presets dient, die mittlere und untere Reihe sind fest immer IA-Taster, derer habe ich also im Preset Mode jetzt zwölf (24, wenn man die Shiftfunktion mitrechnet). Ungeachtet dessen kann ich den Controller immer noch in einen reinen Stompbox Modus umschalten, in dem dann alle 16 Taster CCs versenden.

Das neu erstellen meiner Presets ist auch gar nicht mehr so lästig, weil ich das Benutzerinterface für das Eingeben von Namen (Presets, Taster, MIDI-Geräte) dann doch eine T9-ähnliche Routine geschrieben habe - Taste 1 für ABC, 2 für DEF etc. Beschleunigt das Anlegen von Presets um den Faktor 10  , war gar nicht so schwer, wie ich befürchtet hatte, und der Code ist sogar eleganter und universeller einsetzbar geworden als die Funktionen, die ich vorher dafür zusammen gehackt hatte  :devil: .

Ab Mittwoch hab ich frei, ab dann kümmere ich mich endlich um das Thema SysEx Dump - vermutlich erst mal mit reichlich Lektüre  . Wenn ich mit diesem "Release" durch bin, löse ich mein Versprechen ein und stelle meinen Quelltext dann auch hier mal ein. Vielleicht kann ja der eine oder andere was damit anfangen.

Gruß, Nils

gelöscht (wurde auf vorherigen Seiten schon besprochen)

Eine Sache macht mir allerdings etwas Kopfschmerzen, die ist mir in den acht Monaten jetzt zweimal passiert: Der Controller hat anscheinend irgendwelchen Quatsch rausgesendet, und plötzlich kam nur noch Gequietsche und Gerausche ausm Amp  . Ein Tritt auf ein Preset hat's wieder erledigt, da es beide Male tierisch laut war, konnte ich nicht genau nachvollziehen, was passiert war. Ärgerlich, und schwer zu finden, weil nicht reproduzierbar - passierte beide Male im Preset Mode ohne aktives Zutun meinerseits.

Okay, gestern bei der Probe ist das wieder passiert. Wieder komplett ohne eigenes Zutun, ich war im Proberaum gerade am Lüften und die Anlage lief, ich hab aber nicht gespielt oder so. Da ich aber mit dem Volumenpedal in der Loop die Lautstärke runtergedreht hatte, war diesmal der Schock nicht so groß  und ich konnte mal nachverfolgen, was los war.

Scheint ein Problem mit dem Looper u sein, der hat selbsttätig ALLE Loops aktiviert und alle Schaltausgänge geschaltet - ausnahmslos ALLE, sogar die, für die im FLoorboard kein CC eingerichtet war - spricht also dagegen, dass der Controller irgendwelchen Müll sendet, den der Looper dann falsch interpretiert, zumal die anderen MIDI-Geräte unbeeindruckt bleiben.

Spricht alles dafür, dass der I²C-Bus "abgestürzt" ist und die Port Expander zurück gesetzt wurden. Dann tritt genau das Problem ein, weswegen ich eine Einschaltverzögerung der Relaisspannung eingebaut habe: Die PCF sind nach dem Einschalten alle HIGH, der ULN invertiert das, und die Relais werden aktiviert. Ich tippe auf einen Wackler in der SPannungsversorgung im Platinensteckverbinder zwischen µC- und PCF/ULN Board. Werde also in den kommenden Tagen das Teil mal ausm Rack ausbauen und überprüfen.

Hardwareseitig könnte ich natürlich die inverse Logik durch Inverter umpolen, aber das Problem bleibt: Wenn ein Bus-Reset auftritt, ist dann alles aus statt an, das ist ja auch nicht so toll - nur nicht so laut.

Bleibt also trotzdem die Frage, wie ich das ganze Softwareseitig am besten absichere. Meine Idee: Wenn der Bus n/die PCF nicht reagieren, Relaisspannung kappen, ansonsten die PCF zyklisch immer wieder statt nur einmal setzen. Gibt's noch elegantere Methoden? Jemand Vorschläge?

Gruß, Nils

Eine Sache macht mir allerdings etwas Kopfschmerzen, die ist mir in den acht Monaten jetzt zweimal passiert: Der Controller hat anscheinend irgendwelchen Quatsch rausgesendet, und plötzlich kam nur noch Gequietsche und Gerausche ausm Amp  . Ein Tritt auf ein Preset hat's wieder erledigt, da es beide Male tierisch laut war, konnte ich nicht genau nachvollziehen, was passiert war. Ärgerlich, und schwer zu finden, weil nicht reproduzierbar - passierte beide Male im Preset Mode ohne aktives Zutun meinerseits.

Ich hab ganz vergessen, das aufzulösen: Ich konnte zu Hause das Problem reproduzieren, es war eine Steckverbindung vom Controller- zum I2C-Board. Wenn ich leicht dran gewackelt habe, kam es manchmal zu einem Reset der PCF, ohne dass der Bus komplett abgestürzt ist. Ich hab die Platinenverbinder etwas nachgebogen, so dass sie jetzt saufest zupacken. Bisher ist nix weiter passiert. Hoffe, das bleibt so  . Irgendwann (TM) muss ich noch mal eine Art "Panic"-Routine einbauen.

Moin Leute,

ich brauch mal Eure Hilfe. Ich hab ein Problem, das ich nicht verstehe.

Die Anlage lief im Prinzip (bis auf das letzte Problem mit dem Wackelkontakt im I2C-Bus) seit ewig problemlos; seit ein paar Wochen habe ich aber das Problem, dass der Midi-Thru-Ausgang am Looper "abstürzt".

Das Setup ist wie folgt: Der Midicontroller hängt am Pedal-In (Midi mit Phantom) an der Frontplatte, hinten sitzt der Midi-Thru und leitet alles an ein G-Major 2 weiter.

Problem: Irgendwann (nicht reproduzierbar) kommen am GM2 keine Midisignale mehr an. Ich war mir erst wicher, es sei das GM2-das abstürzt, jetzt stellte sich mit einem Leihgerät aber raus: Is nich, mit dem Leihgerät passiert das genauso. Gestern nach einer Laufzeit von ca. 4 Stunden.

Ich doktore schon recht lange an der Analyse des Problems rum; Neustart des Midicontrollers brachte nichts, Neustart des GM2 auch nicht. Was manchmal zu helfen schien war, das Preset am GM2 manuell zu wechseln. Das scheint aber doch eher zufall zu sein, gestern brachte das nichts.

Was half: Das Rack aus- und wieder einschalten - Effektiv also, den Looper neu zu starten. Es sieht also so aus, als würde der Looper irgendwann die eingehenden Mididaten nicht mehr an den Thru weiterleiten.

Weiteres Problem: Ich verstehe nicht, was passiert. Der Midi-Thru-Port kann nicht "abstürzen", weil er nix mit Software zu tun hat... es ist ein "poor man's"-Hardware-Midi-Thru, der schlicht parallel zum Opto am RXD des AVR hängt (siehe dazu angehängter Stromlaufplan). Der Midi-Out ist nicht bestückt.

Es ist definitiv nicht der Midicontroller, der sich aufhängt, da der Looper immer noch weiter auf Befehle korrekt reagiert. Der Controller sendet also definitiv Mididaten raus.

Jetzt kann's natürlich sein, dass ein Bug in der Software dafür sorgt, dass nur noch auf Midikanal 1 Daten raus gehen. Ich weiß nicht genau, wie ich das analysieren kann. Ich kann leider die Midikanäle von Looper und GM2 nicht tauschen, weil der Midikanal im Looper hardcoded ist... (jaja, ich weiß. Faulheit rächt sich immer irgendwann). Ich könnte, wenn der Fehler das nächste mal auftritt, das GM2 auf Omni stellen und schauen, ob was ankommt.

Mehr Ideen habe ich nicht. Wie gesagt, mit der Loopersoftware KANN das nichts zu tun haben, weil der Thru Hardware ist. Am Opto kann's auch nicht liegen, denn der AVR im Looper bekommt immer noch seine Befehle.

WTF? Ich bin ratlos...
Nils

Hi Nils,
wenn ich das richtig sehe, dann sind die Eingänge am Looper nicht galvanisch getrennt oder?
Gruss
Jürgen

Tante Edit: Blödsinn geschrieben, der 6N139 macht´s...