Tube-Town Forum
Technik => Tech-Talk Design & Konzepte => Thema gestartet von: Nils H. am 26.08.2011 23:13
-
Moin,
melde mich, nachdem ich 'ne Woche krank im Bett gelegen habe, mit der Vorstellung meines neuen Projekts zurück aus der Versenkung.
Ich hab ja in diesem Thread (http://www.tube-town.de/ttforum/index.php/topic,14107.0.html) schon ein wenig rumgejammert, dass ich mit dem Management meiner Effektbataillon unzufrieden bin. Naja, nicht direkt unzufrieden, denn das System funktioniert eigentlich gut, aber es gibt doch Verbesserungsmöglichkeiten. Und da ich immer schon mal was mit µCs machen wollte, habe ich beschlossen, die nächste Generation meines FX-Looper/Switcher-Systems zu entwickeln und zu bauen - diesmal mit µC und MIDI. Das Projekt ist - für meinen Kenntnisstand - sehr ambitioniert, und ich muss speziell an der Programmierfront einiges an Vorarbeit leisten, bevor was produktives dabei herauskommen wird, weswegen ich mir keinen Zeitrahmen setzen will - es ist fertig, wenn's fertig ist.
Als erstes möchte ich mich mit dem Konzept des ganzen befassen, und das sollte gut durchdacht und stimmig sein, bevor überhaupt irgendwas praktisch in Angriff genommen wird. Was auf jeden Fall schon fest steht ist die Nutzung eines fertigen Arduino-Boards, da ich mit der Platinenentwicklung und -fertigung so wenig wie möglich zu tun haben will; außerdem gibt's die leistungsfähigeren µCs nur als SMD, und das verträgt sich gar nicht mit Tremor und Kurzsichtigkeit ;D .
Jedenfalls, ich fange mal an damit, meine Vorstellung darzulegen und so. Ich schreibe den Mist hier parallel auch an einer Art "Konzeptpapier", dass mir als Leitfaden und Dokumentation dienen soll. Später irgendwann, wenn das soweit ist, dass es sich lohnt, werde ich das auch hier veröffentlichen.
Los geht's mit der
Grundidee
Das alte System
Das hier entwickelte System soll langfristig das bestehende Looper-/Switcher-Racksystem ersetzen. Dieses besteht aus einer Rackeinheit mit 12 Audio-Loops, von denen jeweils vier intern in Serie geschaltet sind, sowie 6 potentialfreien Schaltausgängen. Bedient wird die Rackeinheit über einen Bodencontroller mit insgesamt 20 zweipoligen Fußschaltern, über die zum einen die Spulenspannung der Relais geschaltet wird; mit dem anderen Schalterpol wird die zugehörige LED am Controller geschaltet. Der Controller wird über ein voll belegtes 25-poliges D-SUB-Kabel mit der Rackeinheit verbunden.
Dieses System verlagert die Komponenten eines komplexen Pedalboards in ein 19“-Rack. Die Effektgeräte stehen im Rack auf ausziehbaren Bodenwannen und sind so geschützter als auf einem Pedalboard, z.B. gegen versehentliches Verstellen. Vor den Füßen auf der Bühne liegt nur noch ein Controller, der deutlich kompakter ist als ein entsprechendes Pedalboard. Eine Programmierbarkeit bietet das System nicht, wurde von mir aber auch nicht benötigt, da ich kein „Preset-Spieler“ bin – ich schalte meine Effekte einfach nach Lust und Laune ein oder aus.
Der Wunsch nach einer Midifizierung des Systems entstand mit dem Bedürfnis, das im Setup vorhandene 19“-Effektgerät G-Sharp von TC Electronic effizienter zu nutzen. Bisher nutze ich dieses rein im „Manual“-Modus mit fest eingestelltem Delay und Hall, bei dem das Effektgerät an den Reglern auf der Frontplatte eingestellt wird. Über die auf der Rückseite vorhandene Remotebuchse können die Funktionen Delay an/aus, Hall an/aus und Tap Tempo fernbedient werden.
Schöner wäre es, auch die Presets des Gerätes nutzen zu können und so z.B. unterschiedliche Delayeinstellungen und –typen sowie, alternativ zum Delay, auch die Modulationseffekte des G-Sharp nutzen zu können. Dafür ist aber eine Ansteuerung per MIDI unerlässlich. Die einfache Lösung wäre, zusätzlich zum Controller des Loopers ein MIDI-Pedal zu benutzen, und das ist in der Tat die Lösung, die ich im Moment nutze. Der Nachteil ist, dass wieder mehr Platz vor den Füßen benötigt wird, und auch von der Bedienung her ist es suboptimal.
Das neue System
Das neue System soll wie handelsübliche kommerziell erhältliche Switchingsysteme arbeiten und aus zwei Komponenten bestehen. Die alte Rackeinheit wird durch einen per MIDI steuerbaren Looper/ Switcher nach dem Vorbild von Geräten wie dem GCX Audio Switcher von Voodoo Lab oder dem RG-16 bzw. Rack Gizmo von RJM ersetzt. Bei diesen Geräten können die Loops und – im Falle des Rack Gizmo – die Schaltausgänge per MIDI über Continuous-Controller-Befehle ein- und ausgeschaltet werden, das Rack Gizmo ist darüber hinaus auch noch in der Lage, Presets abzuspeichern. Beide Geräte erlauben allerdings nur die Verwendung von bis zu acht Loops. Das GCX bietet keine seperaten Schaltausgänge, das Rack Rack Gizmo hingegen acht. Acht Loops reichen für mein derzeitiges Setup aber nicht aus, so dass die neue Rackeinheit mit der gleichen Anzahl Loops ausgestattet werden soll, wie die alte Rackeinheit.
Gesteuert werden soll die Rackeinheit per MIDI Foot Controller. Hier könnte vermutlich jeder programmierbare MIDI Foot Controller zum Einsatz kommen, der das Senden von CC-Befehlen beherrscht, wie z.B. das Ground Control Pro, ebenfalls von Voodoo Lab oder die Controller von CAE. Alle „bezahlbaren“ Controller haben aber den Nachteil, dass sie nicht genügend Fußtaster für die Steuerung von bis zu 12 Loops sowie mehreren Schaltausgängen haben. Andere Lösungen wie z.B. CAE werden dann sehr schnell sehr teuer. Da ich mich für dieses Projekt sowieso intensiv mit den Themenbereichen MIDI-Protokoll, Microcontroller und Programmierung auseinandersetzen muss, soll im zweiten Schritt auch der passende MIDI Foot Controller entworfen und gebaut werden.
Anforderungen
Looper / Switcher
Features:
- 12 True-Bypass-Audio-Loops mit mit diskretem Input, Insert, Output
- Alle Loops auch als Schaltausgänge nutzbar (Insertbuchse, Tip = NC, Ring = NO)
- 8 potentialfreie Schaltausgänge (Tip auf Masse, NO)
- Steuerung per MIDI
- Ein- und Ausschalten der Loops per CC-Befehl
- Möglichkeit der Speicherung von Presets
- Einschleifbarer Buffer (OP/JFET)
- Individuelles Schalten der Loops per CC#80-91
- Individuelles Schalten der Schaltausgänge per CC#104-111
- Speichern von Presets
- MIDI-Kanal 1-16 frei einstellbar, Omni-Mod
Hardware:
- Arduino-Basis
- 19“-Rackunit, 2HE
- 7-Segment-Anzeige mit serieller Ansteuerung zur Anzeige der Presetnummer
- Versorgung per 9V AC/DC-Adapter
- USB-Anschluss für FW-Update
- MIDI-/Pedal-In an der Frontplatte
- 9V Phantom-Power für Controller, ggf. schaltbar
- Aufbau der Treiberschaltungen, Relais und Buchsen auf Eyeletboard oder Loch-/Streifenraster
Weiter geht's dann später mit den möglichen geeigneten Arduino-Varianten für die Rackeinheit sowie den Anforderungen an den Floorcontroller. Input, Vorschläge und Meinungen sind natürlich erwünscht!
Gruß, Nils
-
wow. Viel Glück, Nils.
-
wow. Viel Glück, Nils.
Das klingt ja sehr skeptisch ;) . Ich weiß, das klingt sehr ambitioniert, und es wird ein langer Weg sein, bis die Kiste fertig ist. Im Wesentlichen ist es ein Programmierprojekt, denn die Hardwareseite ist ja sehr überschaubar. Wenn man an die Software einigermaßen strukturiert rangeht und das von Anfang an modular aufbaut, kann man ja Feature um Feature einbauen. Und wichtig ist halt ein stimmiges Grundkonzept.
Gruß, Nils
-
Moin,
weiter gehts:
Microcontroller (Rackeinheit):
Gerade hier würde ich mich über Input freuen, da ich kaum Erfahrungen mit Microcontrollern habe; vielleicht habe ich bei meiner Recherche ja Lösungswege übersehen, die andere Alternativen erlauben.
Anforderungen:
Der Microcontroller für den Switcher benötigt in der angepeilten Ausbaustufe (12 Loops und 8 Schaltausgänge) 20 freie digitale I/O-Pins, konfiguriert als Ausgang. Hinzu kommt noch die gleiche Anzahl digitaler Inputs für die Bedienung durch Taster auf der Frontplatte sowie zwei Pins für Midi I/O und ein Pin für die Ansteuerung der seriellen 7-Segment-Anzeige. Insgesamt werden also 44 I/O-Pins benötigt (20 Outputs und 24 Inputs).
Der ATmega168 und ATmega328 haben nur 14 digitale I/O, von denen zwei für MIDI In/Out abgezogen werden müssen. Allein durch die Anzahl an benötigten Outputs ergeben sich zwei Möglichkeiten:
- Einsatz eines Boards mit ATmega1280 oder ATmega2560
- Einsatz zweier / mehrerer Boards mit ATmega168 oder ATmega328
Letzteres ist im Hinblick auf den Beschaffungspreis eigentlich nur sinnvoll bei Einsatz eines Arduino Pro oder Pro-Mini. Ein weiterer Nachteil des ATmega168 wäre das mit 512 Byte sehr knapp bemessene EEPROM.
Mögliche Controller und Boards:
ATmega1280
- 54 digitale I/O
- 16 analoge Inputs
- 128 kB Flash / 8 kB SRAM / 4 kB EEPROM
- Kein aktuelles Design
Mögliche Boards:
Original Arduino MEGA
- schwierig zu bekommen, weil veraltet
- Preis ca. €24,-
- Benötigt MIDI-I/O-Shield ("Shield" heißen bei Arduino die Aufsteck-Tochterboards), kostet €15,-
- Maße ca. 102 mm x 54 mm
Miduino Keyboard/Piano Foot Pedals MIDI/USB
- Arduino MEGA-Board
- Preis: €65,-
- Inkl. MIDI I/O-Shield
- Beinhaltet nicht benötigtes Programm, für das wohl mit bezahlt wird
ATmega2560
- 54 digitale I/O
- 16 analoge Inputs
- 256 kB Flash / 8 kB SRAM / 4 kB EEPROM
Mögliche Boards:
Original Arduino MEGA 2560
- Preis: um €50,-
- Benötigt zusätzlich MIDI-I/O-Shield, kostet ca. €15,-
- Maße ca. 102 mm x 54 mm
ATmega328
- 14 digitale I/O
- 8 analoge Inputs
- 32 kB Flash / 2 kB SRAM / 1 kB EEPROM
Mögliche Boards:
Original Arduino Uno
- Preis: ca €25,-
- Benötigt MIDI-I/O-Shield, kostet €15,-
- Maße ca. 69 mm x 54 mm
Original Arduino Duemilanove
- Preis: ca. €25,-
- Benötigt MIDI-I/O-Shield, kostet €15,-
- Maße ca. 69 mm x 54 mm
Original Arduino Pro
- Preis: ca €17,-
- Benötigt MIDI-I/O-Shield, kostet €15,-
- Kein USB-Anschluss, Kabel oder Konverter benötigt
- Sehr kompaktes Board
Die einzige sinnvolle Variante ist nach meiner Einschätzung der Einsatz des MEGA- oder MEGA 2650-Designs. Das Optimum würde wohl ein Board mit ATmega2560 darstellen, inkl. MIDI-I/O liegt der Preis bei ca. 65 Euro.
Mit etwas Glück ist ein MEGA-Board für ca. 25 Euro zu bekommen, ergänzt um ein MID-I/O-Shield z.B. von Miduino liegt der Anschaffungspreis bei ca. 40 Euro. Der geringeren Flashspeicher von 128 kB (256 kB beim 2560) sollte bei dieser Anwendung keinen Nachteil darstellen.
Die Beschaffung eines MEGA-basierten Miduino-Designs scheint nur dann sinnvoll, wenn kein originales MEGA-Board zu einem günstigen Preis beschafft werden kann. In diesem Fall scheint z.B. das Projekt „Keyboard/Piano Foot Pedals MIDI/USB“ für 65 Euro das richtige und günstigste Miduino-Projekt zu sein, zu diesem Preis könnte man dann aber auch gleich zur erstgenannten Lösung greifen.
-
Zum Schluss für heute meine Idee vom
Midi Foot Controller
Die folgenden Listen stellen einen möglichen Funktionsumfang dar. Die Programmieraufgabe wird beim Controller deutlich größer sein als beim Looper/Switcher, so dass die Software mit der Zeit wachsen wird. Es muss noch festgelegt werden, welche Features für einen Grundbetrieb benötigt und was die Mindestanforderungen an die Software sein werden.
Features:
- Senden von PC-Befehlen
- Senden von CC- oder PC-Befehlen per Direktanwahl-Taster
- Speichern von 100 Presets
- Steuerung von bis zu 8 Geräten auf unterschiedlichen MIDI-Kanälen
- Anschlussmöglichkeit von 2 Expression-Pedalen
- Range-Einschränkung der Expressionpedale möglich
- Fußtaster konfigurierbar als Schalter (latching) oder Taster (momentary)
- Fußtaster können bis zu 4 andere Taster zurücksetzen
Hardware:
- Metallgehäuse
- Metall-Fußtaster
- Low Current-LED
- Beleuchtetes LCD 16x2
- Mindestens vier Taster plus Bank up/down zur Presetwahl
- 20 Taster zum Schalten aller Loops und Schaltausgänge der Rackeinheit
- Phantomgespeisung oder Versorgung per Steckernetzteil
- 9V DC-Output zur Versorgung von Effektgeräten
- USB-Anschluss für FW-Update
Microcontroller:
Der Microcontroller für den MIDI Foot Controller benötigt für die Direktanwahl von 12 Loops und 8 Schaltausgängen sowie das Schalten von 4 oder 5 Presets / Bank 26 bzw. 27 digitale Inputs sowie ebenso viele digitale Outputs für die zugehörigen LED. Dazu kommt noch je ein Pin für MIDI-Out und die Kommunikation mit dem LC-Display mit serieller Ansteuerung. Damit benötigt der Controller mehr als die 54 digitalen I/O-Pins, die der ATmega1280 oder ATmega2560 zur Verfügung stellen. Das Problem kann auf mehrere Arten umgangen werden, z.B.:
- Verschaltung der Fußtaster als Matrix, Auswertung über die Arduino Keypad-Library. Für die Auswertung der Taster werden dann statt 27 Eingängen nur noch 11 benötigt.
- Auswertung mehrerer Taster über analoge Eingänge. Die Taster werden hier mit unterschiedlichen Widerständen verschaltet und bilden mit den Pull-Up-Widerständen unterschiedliche Spannungsteiler. 4-5 Taster pro Eingang sollten problemlos möglich sein, es würden dann 6 oder 7 analoge Eingänge benötigt. Im Arduino Playground steht hierfür die „AnalogButtons“-Library zur Verfügung.
Für den Controller wird aber auf alle Fälle ein Controller mit reichlich I/O-Ports benötigt, auch reichen die 512 Byte bzw. 1 kByte der kleineren Atmels nicht aus. Sinnvoll ist hier nur der Einsatz eines ATmega1280 oder 2560, für die Varianten und die Verfügbarkeit gilt das für die Rackeinheit bereits gesagte. Da nur ein Midi-Out vorgesehen werden muss, kann die Midi-Beschaltung aber deutlich einfacher ausfallen, so dass kein separates MIDI-Shield benötigt wird.
Soweit erstmal von mir für heute,
Gruß, Nils
-
Hallo Nils,
genau auf Arduino Basis hab ich eine light Variante in meinen Attenuator verbaut. Light, denn er kann nur senden und hat nur ein Led zur Statusanzeige.
Arduino NG rev. C mit 6 analogen Inputs und 14 digitalen Pins (IO)
digital IO:
7 x ON-OFF-ON Taster + 1 x ON-OFF-ON Taster/Schalter Kombi = 15 Taster und 1 Schalter, benötigen 8 digitale Pins (mit je 10k gegen GND verbunden) als Input und 2 als Output (Stromversorgung abwechselnd für obere und untere Taster/Schalterstellung)
1 x digitaler Pin für LED
1 x digitaler Pin für Send (TX) (5V -> 220k -> Din-Buchse (pin 2 glaub ich) , GND -> Din-Buchse (pin 3) , TX -> Din-Buchse (pin 4 glaub ich)
analog IO:
5 Potis (1M B) den Schleifer an analogen Pins (Stromversorgung über 5V Arduinoboardnetz)
Dazu noch ein, leider bei mir fast unterdimensioniertes, Netzteilmodul vom C, ein Resettaster nach außen geführt (NO, ATmega Pin 1 -> GND soweit ich mich erinnere), ein USB Kabel und einen Umschalter zwischen USB PS bzw externem PS.
Zur Funktion:
Er dient mir zur Steuerung eines G-Major 2 (nur begrenzt MIDI steuerbar) und hat 3 Modi:
Modus 1: Normalbetrieb beim Einschalten.
14 CC Nachrichten (0 oder 127 im Wechsel) auf 14 Tastern und 5 CC Nachrichten (0-127) auf Tastern bei einer Änderung >5. Led leuchtet alle ~5 Sekunden kurz auf.
Modus 2: Feinbetrieb.
wird durch betätigen des 15. Tasters aktiviert und erneutes Betätigen aktiviert, gleich wie Normalbetrieb nur werden Änderungen der Potistellung sofort weitergegeben und das LED leuchtet genau invers zu Modus 1.
Modus 3: Programmwechselbetrieb.
PC Nachrichten und CC für Bankwechsel.
10 Taster dienen als Eingabefeld für die Zahlen 0-9 (newPatchNumber=(newPatchNumber*10+inputNumber)%1000 bzw bei >128 %100). 2 Wechseln User und Factorybank, 2 dienen dem Wechsel zum nächsten oder vorherigen Patch. Aktiviert wird der Modus durch betätigen des Schalters 16, gesendet wird die PC Nachricht entweder bei Bankwechsel oder Release des Schalters 16.
Soweit funktioniert eigentlich alles, aber ein paar Mankos hat mein Controller. Keine einheitlichen Taster, somit aufwenigerer Code (Reaktion nicht nur auf Press sondern auch unter Umständen auf Release (PC)), bei Wechsel eines Patches kennt er nicht die Konfiguration der Schalter im G Major2 somit wird möglicherweise die gewünschte Aktion erst beim 2. Versuch aktiv. Beim Einschalten, oder direkter Interaktion am G Major2, kennt er noch nicht den aktuell aktiven Patch und wechselt so bei +1 /-1 nicht zum erwarteten Patch bzw funktionert ein Taster wieder erst beim 2. Mal wie erwartet. Weiters können sich Potis gegenseitig beeinflussen, vielleicht sollte ich sie noch mit Dioden isolieren.
Ebenso können unerwartete Komplikationen auftreten, zB steuert ein Poti bei mir die Input Lautstärke, ist diese beim Ausschalten auf 0 gedreht und verwendet den G Major2 das nächste Mal ohne Midicontroller sucht man das erste Mal ziemlich lange verzweifelt, bis man den Fehler findet warum kein Ton mehr aus dem Verstärker kommt ;)
Auf der Softwareseite habe ich die Arduino IDE und die Arduino MIDI Lib von sourceforge (so weit ich mich erinnere) verwendet. Funktioniert auch problemlos auf allen gängigen Betriebssystemen. Sollte ich ihn noch einmal neu bauen würde ich auch jedenfall keine gemischten Taster und Schalter verwenden und alle Funktion auch von einfacher Programmierbarkeit abhängig machen.
HTH als Anregung bzw hilft Dir meine Fehler zu vermeiden. BTW es ist zumindest für mich angenehm wenigstens die 4 Modifikatoren zB Reverbmix im G-Maj2 per echten Potis zu steuern, bzw eine Taptempofunktion zu haben oder das Gate direkt zu schalten ohne sich durch das Menü zu kämpfen. Die Plastikknöpfe des G-Maj2 werden ebenso geschont. Jetzt fehlt es nur noch einen Foot Controller parallel zu den vorhandenen Tastern zu verbauen, leider fehlt mir aber die Zeit.
Gruß,
Sepp
-
Insgesamt werden also 44 I/O-Pins benötigt (20 Outputs und 24 Inputs).
Der ATmega168 und ATmega328 haben nur 14 digitale I/O, von denen zwei für MIDI In/Out abgezogen werden müssen. Allein durch die Anzahl an benötigten Outputs ergeben sich zwei Möglichkeiten:
- Einsatz eines Boards mit ATmega1280 oder ATmega2560
- Einsatz zweier / mehrerer Boards mit ATmega168 oder ATmega328
Die 20 Taster könntest du als 5x4-Matrix schalten. Anstatt 20Pins würden diese dann nur noch 9 Pins benötigen. Die Ausgänge für Loops und Schaltaufgaben (beides wahrscheinlich mit Relais) könntest du über I2C-Portexpander machen. Damit würdest du am µC nur noch die Pins für den I2C-Bus benötigen (also 2Pins).
Das wären dann also 11Pins +2Pins Midi-I/O = 13Pins.
mfg sven
Edit: Seh grad: Für den Footcontroler hast du die Taster als Matrix vorgesehen, warum nicht bei der Rackeinheit?
-
Salü,
Der Microcontroller für den MIDI Foot Controller benötigt für die Direktanwahl von 12 Loops und 8 Schaltausgängen sowie das Schalten von 4 oder 5 Presets / Bank 26 bzw. 27 digitale Inputs sowie ebenso viele digitale Outputs für die zugehörigen LED. Dazu kommt noch je ein Pin für MIDI-Out und die Kommunikation mit dem LC-Display mit serieller Ansteuerung. Damit benötigt der Controller mehr als die 54 digitalen I/O-Pins, die der ATmega1280 oder ATmega2560 zur Verfügung stellen. Das Problem kann auf mehrere Arten umgangen werden, z.B.:
Die LEDs könntest du über Schiebregister und die serielle Schnittstelle des µCs ansteuern (oder wieder Portexpander+I2C). Das LC-Display lässt sich auch im 4Bit-Modus betreiben, um Pins zu sparen.
mfg sven
Edit: Warum sollen es eigentlich fertige Arduino-Boards sein? Wenn ich die Preise so les, hast du bei zwei Boards locker den Preis für ein USB-Programmiergerät+µC+Quarz+Hühnerfutter+Lochrasterplatine erreicht. Das Programmiergerät lässt sich dann später weiter verwenden, sodass für deinen nächstes µC-Projekt nur noch µC+Quarz+Hühnerfutter fällig wird.
-
Moin Sven,
danke für die Hinweise!
Edit: Seh grad: Für den Footcontroler hast du die Taster als Matrix vorgesehen, warum nicht bei der Rackeinheit?
Beim Controller kommt man an der Matrix-Lösung nicht vorbei, weil er so viele I/Os benötigt. Bei der Rackeinheit ist das nicht so zwingend nötig, jedenfalls wenn ich zum "großen" ATmega greife. Das ist der einzige Grund, warum ich das bei der Rackeinheit nicht hingeschrieben habe. Ich hab aber auch noch gar keine Ahnung, welche Variante den größeren Programmieraufwand hat - u.U. ist das mit der Matrix-Bibliothek eh einfacher.
Salü,Die LEDs könntest du über Schiebregister und die serielle Schnittstelle des µCs ansteuern (oder wieder Portexpander+I2C). Das LC-Display lässt sich auch im 4Bit-Modus betreiben, um Pins zu sparen.
Als LCD hab ich eines mit serieller Ansteuerung (die gibt's fertig) vorgesehen, dann braucht's sogar nur einen Pin. Andererseits wird natürlich ein nacktes LCD deutlich billiger. Mal sehen, ob am Ende die vier Pins für die Ansteuerung über bleiben.
Edit: Warum sollen es eigentlich fertige Arduino-Boards sein? Wenn ich die Preise so les, hast du bei zwei Boards locker den Preis für ein USB-Programmiergerät+µC+Quarz+Hühnerfutter+Lochrasterplatine erreicht. Das Programmiergerät lässt sich dann später weiter verwenden, sodass für deinen nächstes µC-Projekt nur noch µC+Quarz+Hühnerfutter fällig wird.
Das Hauptproblem sehe ich dabei im Format des µC: So wie ich das sehe, werde ich einen ATmega1280 oder 2560 brauchen, und den gibt's nur als SMD oder BGA. Insofern ist ein Aufbau auf Lochraster o.ä. schon mal raus, und auf SMD-Löten hab ich auch keinen Bock, das überlasse ich gerne anderen ;) . Als Grund sehe ich da weniger den Bedarf an I/O-Ports, das ließe sich ja anderweitig lösen, sondern vor allem den Speicherbedarf, vor allem beim EEPROM. Für den Controller hab ich das schon mal überschlagen, da fallen pro Preset ca. 25 Byte an. Damit sind die kleineren µC mit 512B oder 1kB raus - meiner - zugegeben, bisher oberflächlichen - Recherche zufolge ist es nicht so einfach möglich, das EEPROM zu erweitern. Bei der Rackeinheit hab ich das noch nicht überschlagen, da wäre es vermutlich noch nicht ganz so kritisch.
Dann soll der µC ja im Gerät programmierbar sein, es ist doch unpraktisch, für ein FW-Update jedes mal das Ding aufzuschrauben und den µC rauszunehmen, um ihn im Programmiergerät neu zu programmieren.
Oder siehst Du / sieht jemand da andere Lösungsansätze?
Gruß, Nils
-
Salü,
Die meisten Programmiergeräte unterstützen auch das Programmieren in der Schaltung.
Wie zum Beispiel diese Gerät auf dem Foto für PICs von Microchip.
(http://www.home.hs-karlsruhe.de/~risv1011/Dateien/uC-Funktionsgenerator/programmieren.JPG)
Ähnliche Geräte gibt es bestimmt auch für Atmel-µC. Wenn du die Steckerleiste auf der Platine unterbringst muss du das Gerät natürlich aufschrauben, aber ich persönlich finde das nicht so schlimm. Wenn die Schaltung erstmal entgültig läuft, wird man nicht mehr ständig neue Software aufspielen und in der Testphase hat man die Platine/die Schaltung eh offen aufem Tisch liegen.
Zur Erweiterung des EEPROMs gibt es auch externe EEPROM-IC (via I2C oder SPI). Wenn du aber eh einen entsprechend großen µC wegen der IO-Pins vorsiehst, kannst du dir das ja sparen.
Als LCD hab ich eines mit serieller Ansteuerung (die gibt's fertig) vorgesehen, dann braucht's sogar nur einen Pin. Andererseits wird natürlich ein nacktes LCD deutlich billiger. Mal sehen, ob am Ende die vier Pins für die Ansteuerung über bleiben.
Der 4Bit-Modus bezieht sich nur auf die Datenleitung. Zusammen mit den Steuerleitungen werden dann 7Pins benötigt.
Die Taster würde ich generell als Matrix schalten, vielleicht freust du dich irgendwann noch über die freien Pins wenn dir noch irgend ne tolle Erweiterung einfällt. ;)
mfg sven
Edit.: Das Argument SMD kann ich nachvollziehen. Gottseidank gibt es die meisten PICs auch als THT-Bauteile. Sogar in der dsPIC-Reihe werden einige im DIL-Gehäuse angeboten
-
Salü,
Für die Rackeinheit benötigst du doch eigentlich überhaupt kein EEPROM oder?
Presets speicherst du ja nur im Footcontroller. Und alles was nicht nur Laufzeit geändert und dauerhaft gespeichert werden soll kann in den Programmflash.
mfg sven
-
Salü,
Für die Rackeinheit benötigst du doch eigentlich überhaupt kein EEPROM oder?
Presets speicherst du ja nur im Footcontroller. Und alles was nicht nur Laufzeit geändert und dauerhaft gespeichert werden soll kann in den Programmflash.
mfg sven
Doch. Die Rackeinheit soll auch programmierbar sein. Da ist es aber weniger kritisch, da sollte man mit 3 Byte pro Preset auskommen, da ist auch bei 512 Byte noch genug Platz für Konfigurationsdaten. Insofern muss ich das noch mal absondieren, ob ich das mit einem kleineren mC hinbekomme. Bei der Arduino-Umgebung will ich aber auf jeden Fall bleiben, die erscheint mir sehr komfortabel, und es gibt viele gute Erweiterungen.
Gruss, Nils
-
Moin Sven,
Wenn du die Steckerleiste auf der Platine unterbringst muss du das Gerät natürlich aufschrauben, aber ich persönlich finde das nicht so schlimm. Wenn die Schaltung erstmal entgültig läuft, wird man nicht mehr ständig neue Software aufspielen und in der Testphase hat man die Platine/die Schaltung eh offen aufem Tisch liegen.
da bin ich mir nicht so sicher. Die Rackeinheit ist softwareseitig sicher deutlich simpler gestrickt und wenn's läuft, läuft's. Beim Floorboard will ich mir, glaube ich, den Luxus gönnen und im Zweifelsfalle einfach mit USB-Kabel und Laptop ohne Schrauberei im Proberaum eine neue Software einspielen können. Wir alle kennen das doch, dass wir von einem Gerät, egal wie ausgereift, immer gerade was anderes wollen als das, was es kann ;D .
Zur Erweiterung des EEPROMs gibt es auch externe EEPROM-IC (via I2C oder SPI). Wenn du aber eh einen entsprechend großen µC wegen der IO-Pins vorsiehst, kannst du dir das ja sparen.
Ich denke, fürs Floorboard wird's darauf hinaus laufen. Ist doch wie beim Amps bauen - man denkt, der Klöterkram und das Hühnerfutter schluckt nicht viel, aber - überspitzt dargestellt - bei allen Verrenkungen, Erweiterungen, Expandern und so hat man vermutlich auch schnell das Preisniveau eines fertigen Boards erreicht.
Der 4Bit-Modus bezieht sich nur auf die Datenleitung. Zusammen mit den Steuerleitungen werden dann 7Pins benötigt.
Stimmt. Mein Fehler :) . Der Gedanke, das seriell über einen einzelnen Pin abfrühstücken zu können, erscheint mir aber deutlich reizvoller, zumal ein entsprechendes LCD nur einige wenige Euros mehr kosten würde als das nackte LCD-Modul.
Die Taster würde ich generell als Matrix schalten, vielleicht freust du dich irgendwann noch über die freien Pins wenn dir noch irgend ne tolle Erweiterung einfällt. ;)
D'akkordeon ;D .
Gruß, Nils
Edit: P.S. die Lösung mit einem Schieberegister für die Outputs ist natürlich trotzdem sexy, denn das sind ja Pfennigartikel, und im DIL16-Gehäuse lässt sich das prima lokal dort unterbringen, wo's benötigt wird, was den Verdrahtungsaufwand überschaubar hält. Statt 20 Datenleitungen zu ziehen einfach ein paar 74HC595 verteilen....
-
I2C I/O - Expander : PCF8574
Schonmal an z8encore gedacht ?
In-Cicuit-Programmierung, On-Chip-Debugger, priorisierbare Interrupts,
Flashen über serielle Schnittstelle und vor allem kein Fuse-Bit-Gequarke.
Kost´ 6-7 Eu bei R&S.
Braucht an Peripherie nen Quarz, paar Cs und Rs und nen MAX3232 zum Flashen und Debuggen - Fertig.
Schaltpläne kannste von mir haben.
Gruß
Bernhard
-
Moin Nils,
ich habe hier
http://www.tube-town.de/ttforum/index.php/topic,14548.0.html (http://www.tube-town.de/ttforum/index.php/topic,14548.0.html)
vor einer Weile schon mal ein Switching System für einen Amp eingestellt, daß auf dem Arduino Pro Mini basiert. Die Ausgangspins habe ich dort auch mit dem 74HC595 vervielfältigt, dabei mußt du aber darauf achten, daß der nur 35mA treiben kann, was für Relais nicht reicht. Abhilfe schafft ein nachgeschalteter ULN2803, da bist du mit 500mA pro Pin auf der sicheren Seite.
Um eingangsseitig Pins am Arduino zu sparen habe ich 74HC147 verwendet, mit dem Ding kann man neun Eingänge auf vier Bit codieren.
-
Moin,
I2C I/O - Expander : PCF8574
guter Hinweis. Gibt's bei ---- für kleines Geld.
Schonmal an z8encore gedacht ?
In-Cicuit-Programmierung, On-Chip-Debugger, priorisierbare Interrupts,
Flashen über serielle Schnittstelle und vor allem kein Fuse-Bit-Gequarke.
Kost´ 6-7 Eu bei R&S.
mhhhh.... werde ich gerade nicht so richtig warm mit. Schnelles googlen brachte mir gerade wenig Erkenntnis über den Einstieg in die Programmierung. Das ist der Punkt, der mir bisher ganz gut an Arduino gefällt, dass es durch die gute Dokumentation und hohe Verbreitung einsteigerfreundlich ist und die Programmierung auf einer einigermaßen abstrakten Ebene stattfindet.
ich habe hier
http://www.tube-town.de/ttforum/index.php/topic,14548.0.html (http://www.tube-town.de/ttforum/index.php/topic,14548.0.html)
vor einer Weile schon mal ein Switching System für einen Amp eingestellt, daß auf dem Arduino Pro Mini basiert. Die Ausgangspins habe ich dort auch mit dem 74HC595 vervielfältigt, dabei mußt du aber darauf achten, daß der nur 35mA treiben kann, was für Relais nicht reicht. Abhilfe schafft ein nachgeschalteter ULN2803, da bist du mit 500mA pro Pin auf der sicheren Seite.
Ja, habe ich damals gesehen. In dem Thread ist ja auch anderweitig ein paar Mal die Empfehlung Arduino gefallen. Dass irgend eine Treiberschaltung benötigt wird, egal ob ULN2803 oder per diskreten Transistoren, ist mir klar.
Um eingangsseitig Pins am Arduino zu sparen habe ich 74HC147 verwendet, mit dem Ding kann man neun Eingänge auf vier Bit codieren.
An der Stelle wäre es vielleicht mal ganz sinnvoll zusammen zu tragen, welche Art der Ein- und Ausgangsvervielfältigung besser oder schlechter ist. Oder ist es am Ende bei so einer Anwendung egal?
Für die Erweiterungen von Eingängen gäbe es ja die Möglichkeiten
- Taster als Matrix verschalten
- Taster über unterschiedliche Spannungsteiler über analoge Eingänge auswerten
- i²C Port Expander (PCF8574)
- Priority Encoder (74HC147)
Bei den Ausgängen wären das
- Schieberegister
- ebenfalls I²C Port Expander
Hab ich was vergessen?
Gefühlsmäßig am nächsten steht mir im Moment, für den Floorcontroller einen großen µC zu nehmen, der bringt fast alles mit, was ich brauche, und ich muss nur die Taster als Matrix verschalten. In der Rackeinheit dann einen "kleinen" ATmega, Outputs per Shift Register (3 Pins), 21 Inputs ebenfalls als Matrix (10 Pins), 2 Pins Midi I/O. Ich hab da jetzt keine richtigen Argumente für, aber der flüchtige Blick über die Dokumentation brachte bei mir bei Schieberegistern und Matrixschaltung den sympatischsten Eindruck.
Der Vorteil, alles / vieles per I²C-Port-Expander zu machen, wäre vermutlich eine vereinheitlichte Programmierung über alle I/Os.
Gruß, Nils
-
Salü,
Port-Expander hat halt den Vorteil, dass man sie als Ausgang und Eingang verwenden kann (auch gemischt, also einen Teil des Ports als Ein- und den anderen als Ausgang). Außerdem können sie einen Pegelwechsel per Interrupt an den µC weiterreichen (wenn dieser noch Pins für externe Interrupts frei hat), sodass man nicht pollen muss, wenn man auf Daten wartet. Praktisch ist auch, dass man einzelne Schaltungsmodule mit ner 4-Drahtleitung verbinden kann, anstatt einer 8-Poligen Flachbandleitung (z.B. kann man dann die LEDs und dem LCD an der Frontplatte ne eigene Platine spendieren und alles per I2C mit der Hauptplatine verbinden). Außerdem wird beim Port-Expander das Byte "in einem Zug" auf die Ausgänge gelegt. Beim Schieberegister wird es "durch geschoben". Bei LEDs stört das nicht, bloss bei Relais bin ich mir nicht sicher ob das Störungen geben könnte oder ob die träge genug sind.
Bissel Lesestoff: http://www.mikrocontroller.net/articles/Port-Expander_PCF8574
mfg sven
-
Moin Sven,
danke für den Link.
Wenn ich das richtig verstanden habe, stellt sich das von Dir geschilderte Problem nicht, wenn man ein "latching" Register benutzt. Da werden die Ausgänge erst gesetzt, wenn man das Byte komplett in den IC geschoben und freigegeben hat.
Gruß, Nils
-
Hallo,
zu den Vorteilen der Port-Expander hat SvR ja schon geschrieben.
Ich bin kein Freund davon, Taster als Matrix zu verschalten, weil es einfach vom Aufbau her oft umständlich ist. Deswegen habe ich den 74HC147 verwendet. Das ist zusagen die Variante, wenn man a) kein Matrix zurechtfummeln und b) kein Bussystem wie I2C einsetzen will.
@SvR: Beim 74HC595 Schieberegister werden die Ausgänge auch "in einem Zug" geschaltet. Deswegen braucht das Ding auch drei Steuer-Leitungen: An einer liegt das zu übernehmende Bit an, mit einem Impuls an der Zweiten wird das Bit übernommen und ein internes Register weiter-geshiftet (das kann man dann beliebig oft wiederholen). Erst mit einem Impuls an der dritten Leitung wird der aktuelle Zustand des internen Registers auf die Ausgänge geschaltet. Durch dieses Verfahren kann man die Bausteine auch schön kaskadieren, damit bekommt mit drei Pins am µC beliebig viele Ausgänge hin.
Eine Sache noch zu den Interrupts, normalerweise hast du recht, man sollte stupides Pollen vermeiden, aber in dieser konkreten Anwendung ist das wurscht, der Prozessor hat ja sonst nichts zu tun, außer auf Eingabe zu warten, d.h. für die Hardwareauswahl braucht man das hier nicht zu beachten.
Edit: Nils war schneller mit dem Schieberegister...
-
Salü,
Ich würde der Einfachheit halber nur ein System einsetzen. Port-Expander haben halt den Vorteil, dass sie über einen Bus angesteuert werden. Mit bis zu 8 Bausteinen an einem Bus bist du auch später noch flexibel, wenn du noch en paar Looper/Schaltausgänge willst oder doch noch ein EEPROM brauchst.
Taster zu ner Matrix löten is ja jetzt kein Hexenwerk. Da würde ich nicht extra ein IC für her nehmen. Einfach in Zeilen und Spalten aufteilen. Das ist doch nix im Vergleich zu nem Röhrenradio in ptp ;) :devil:
(http://www.home.hs-karlsruhe.de/~risv1011/Dateien/Lorenz_Radio/unten5.JPG)
mfg sven
-
Sag mal ist das eigentlich was persönliches, daß du ständig versuchst, meine Antworten zu widerlegen und alle von der grenzenlosen Überlegenheit des I2C-Busses zu überzeugen? Das war schon in dem anderen Thread so (universeller Fußschalter), wußte gar nicht, daß wir Streit haben ???. Der Vergleich zum ptp-Röhrenradio ist doch albern...
-
Salü,
Ich hab sicher nichts gegen dich persönlich ???
Nils hat nach Vor- und Nachteilen zum Thema Schieberegister und I2C-Portexpander gesucht und ich hab einige Argumente geliefert um ihm bei der Meinungsbildung zu helfen.
Klar ist der Vergleich zum ptp-Röhrenradio albern, deshalb war auch ein zwinkerndes Smily dahinter.
mfg sven
-
Kinder! Nicht streiten, sonst kommt Ihr auf die stille Treppe! :devil: . Ist doch normal... ich bin von meinen vertrauten und bewährten Lösungen auch immer überzeugter als von anderen ;) .
Ehrlich gesagt finde ich an der Matrix-verschaltung auch nix übles... außer vielleicht, dass es schwierig ist, mal eben mehr Taster hinzuzufügen, sofern die Matrix voll belegt ist. Ich hätte an der Rackeinheit 21 Taster (12 Loops, 8 Schaltausgänge, einen "Store" zum speichern von Presets), da ist aber in einer 6x4- oder 5x5-Matrix noch Raum für weitere Taster.
Letzlich muss ich wahrscheinlich mal die verschiedenen Varianten aufmalen und schauen, was übersichtlicher zu verdrahten ist. Gerade im Floorboard ist ja alles räumlich großzügig verteilt.
Unterm Strich bleibt, dass es genug Varianten gibt, um Ein- und Ausgänge zu erweitern. Die I²C-Variante hätte den unschlagbaren Vorteil, dass auch das Erweitern des EEPROM kein Problem wäre - im Moment, neben dem Komfort der großzügigen I/O-Ausstattung, das Killerargument für ein großes Board für den Floorcontroller.
Naja. Ich denke, ich werde wie gesagt alle Szenarios mal grob durchspielen.
Gruß, Nils
-
Salü,
Ich hab sicher nichts gegen dich persönlich ???
Nils hat nach Vor- und Nachteilen zum Thema Schieberegister und I2C-Portexpander gesucht und ich hab einige Argumente geliefert um ihm bei der Meinungsbildung zu helfen.
Klar ist der Vergleich zum ptp-Röhrenradio albern, deshalb war auch ein zwinkerndes Smily dahinter.
mfg sven
Na dann ist es ja gut :bier:
Hatte nur irgendwie das Gefühl, daß jedesmal wenn ich etwas poste sofort eine Gegenrede kam...
-
Moin,
ich will auch mal ein paar Worte zur Hardware verlieren, auch wenn das eher unspektakulär und fast selbstverständlich ist.
Gehäuse für den Looper / Switcher
Der Looper Switcher wird in einem 19“-Gehäuse mit 1-2HE aufgebaut. Eine Ventilierung dürfte nicht nötig sein, kostet aber keinen oder kaum Aufpreis. Gute Gehäuse von Adam Hall sind bei TT für etwa €50,- erhältlich, günstigere Gehäuse liegen bei etwa €40,- (Musikding) bis €32,- (Pollin). Inwieweit da relevante Qualitiätsunterschiede bestehen, kann ich nicht sagen. Für die Urversion hatte ich damals *irgendwo* im Internet ein 2HE-Gehäuse gekauft, das war unproblematisch. Schließlich soll hier ja auch keine 10kg-Endstufe verbaut werden.
Wenn, wie oben geschrieben, alle 12 Loops diskret ausgeführt werden sollen, geht das nur auf 2HE. Will man mit 1HE auskommen, muss man ein paar Kompromisse eingehen.
Zunächst mal gilt es zu entscheiden, welche Buchsen benutzt werden sollen. Ich würde da ganz gerne die Neutrik Amp-Style Buchsen nehmen. Leider benötigen die etwas Platz, horizontal 20 mm, vertikal wegen der nach unten heraus stehenden Lötösen 22 mm, und dann muss man sehr genau aufpassen, dass kein Lot unten heraussteht und irgendwo kurzschließend anliegt. Beim Musikding gibt's noch diese geschlossenen Buchsen, die die Lötfahnen nach hinten raus haben, aber ich hab keine von denen zu Hause, und ein Datenblatt / Zeichnung gibt's auch nicht.
In einem 1HE-Gehäuse müssen die Neutrik-Buchsen einmal um 90° gedreht werden, so dass die Lötösen zur Seite stehen. Auf diese Weise lassen sich neben den Midi-Buchsen und dem Netzteilanschluss maximal 34 Buchsen unterbringen, weswegen dann auf die komplette Trennung aller Loops verzichtet werden muss. Die Loops 1-4 und 5-8 würden dann (wie beim alten System) fest in Reihe verschaltet und mit einem Input und Output versehen. Für so eine "Chain" braucht man dann 6 Buchsen. Die Loops 9-12 können dann diskret mit 3 Buchsen für Input, Insert und Output ausgeführt werden. Das sind zusammen dann 24 Buchsen, bleiben noch genau 8 Buchsen für die Schaltausgänge und 2 Buchsen für den einschleifbaren Buffer.
Auf 2HE wäre natürlich alles einfacher unter zu bringen, man hätte dann maximale Flexibilität zum Preis einer weiteren HE (und viel umbauter Luft), und die Verdrahtung der Buchsen wäre deutlich weniger Fummelei. Ich neige aber im Moment eher zur 1HE-Variante.
Beim alten System hatte ich die Buchsen in Print-Ausführung gewählt und die Lochrasterplatten über die Buchsen montiert. Ich denke aber, hier möchte ich Buchsen und Platinen trennen und die Buchsen frei verdrahten - anders ginge es auf 1HE eh nicht.
Auf der Frontseite sollen, wie bereits erwähnt, für jede Loop und jeden Schaltausgang ein Taster und eine LED untergebracht werden, dazu ein Taster für "Store", sowie eine 7-Segment-Anzeige für die Anzeige des Presets. Schön wären Taster mit integrierter LED, aber nach dem was ich bisher gefunden habe ist das preislich indiskutabel.
Ich hab die 1HE-Variante mal skizziert und angehängt. Ich hab jetzt mal mit 440mm Gehäusebreite gerechnet.
Gruß, Nils
-
Hallo Nils,
um das unterbringen der Buchsen zu erleichtern, wäre vielleicht eine Breakoutbox zur rückseitigen Montage im Rack eine Alternative. Alle Buchsen kommen in die Breakoutbox und werden dort auf eine platzsparendere Buchsenart übersetzen, den Controller, das Interface und die Anzeige kann man dann in einem kurzem 1HE Gehäuse unterbringen und zB per Multicore verbinden.
Bin gespannt auf das Ergebnis,
Gruß,
Sepp
-
Salü,
Port-Expander hat halt den Vorteil, dass man sie als Ausgang und Eingang verwenden kann (auch gemischt, also einen Teil des Ports als Ein- und den anderen als Ausgang). Außerdem können sie einen Pegelwechsel per Interrupt an den µC weiterreichen (wenn dieser noch Pins für externe Interrupts frei hat), sodass man nicht pollen muss, wenn man auf Daten wartet. Praktisch ist auch, dass man einzelne Schaltungsmodule mit ner 4-Drahtleitung verbinden kann, anstatt einer 8-Poligen Flachbandleitung (z.B. kann man dann die LEDs und dem LCD an der Frontplatte ne eigene Platine spendieren und alles per I2C mit der Hauptplatine verbinden). Außerdem wird beim Port-Expander das Byte "in einem Zug" auf die Ausgänge gelegt. Beim Schieberegister wird es "durch geschoben". Bei LEDs stört das nicht, bloss bei Relais bin ich mir nicht sicher ob das Störungen geben könnte oder ob die träge genug sind.
Bissel Lesestoff: http://www.mikrocontroller.net/articles/Port-Expander_PCF8574 (http://www.mikrocontroller.net/articles/Port-Expander_PCF8574)
mfg sven
Moin,
ich hab mich ein wenig mit der Port Expander Lösung beschäftigt, und ich sehe zwei Probleme.
Erstens: Treiben der Relays. Das ist ein grundsätzliches Problem und hat nix mit dem PCF8574 zu tun; wenn ich die Relais über Transistoren oder einen Darlington-Array treibe, reicht bei 9V Versorgung die Spannung nicht mehr aus, um die Relais zu schalten. Ich verwende ganz gerne die blauen Takamisawa-12V-Relais, weil die erstens bei 9V sehr zuverlässig arbeiten und zweitens einen Spulenwiderstand von 960 Ohm haben, so dass sie bei 9V nur knapp 10mA verbraten.
Über einen Transistor oder Treiber-IC bleiben mir aber nur 8,2V bis 8,3V, und da flattern die Relais. Jetzt habe ich das Datenblatt studiert, und dort steht, dass jeder der Ports des PCF8674 max. 25mA aufnehmen kann, im verlinkten Artikel steht, dass man in Summe 200mA nicht überschreiten sollte. Strommäßig sollte ich mit dem 8574 also locker 8 Relais mit zugehöriger LED (~2mA) ansteuern können - kann man das bringen, die Relais direkt zu treiben, oder sind da Probleme vorprogrammiert?
Die Alternative wäre, dass ich doch mit 12V DC in das Gerät reingehen muss, dort die Relaisversorgung abzweige und dann noch mal einen Regler nachschalten muss, der die Spannung auf 9V runterholt, damit ich über den DC out die Pedale versorgen kann - das geht zwar, ist aber irgendwie auch doof.
Zweitens: Laut Datenblatt sind die Ports des 8574 nach dem Einschalten erstmal auf HIGH, bis der IC einen anderen Zustandsbefehl bekommt. Werden die Relais über einen 2804 getrieben, heisst dass, sie sind alle erstmal durchgeschaltet, bis das Programm im µC sie auf LOW setzt. Eigentlich hab ich keine Lust, da noch einen Inverter zwischen zu basteln; jemand Ideen für eine andere Lösung?
Gruß, Nils
-
Salü,
Erstens: Treiben der Relays. Das ist ein grundsätzliches Problem und hat nix mit dem PCF8574 zu tun; wenn ich die Relais über Transistoren oder einen Darlington-Array treibe, reicht bei 9V Versorgung die Spannung nicht mehr aus, um die Relais zu schalten. Ich verwende ganz gerne die blauen Takamisawa-12V-Relais, weil die erstens bei 9V sehr zuverlässig arbeiten und zweitens einen Spulenwiderstand von 960 Ohm haben, so dass sie bei 9V nur knapp 10mA verbraten.
Über einen Transistor oder Treiber-IC bleiben mir aber nur 8,2V bis 8,3V, und da flattern die Relais. Jetzt habe ich das Datenblatt studiert, und dort steht, dass jeder der Ports des PCF8674 max. 25mA aufnehmen kann, im verlinkten Artikel steht, dass man in Summe 200mA nicht überschreiten sollte. Strommäßig sollte ich mit dem 8574 also locker 8 Relais mit zugehöriger LED (~2mA) ansteuern können - kann man das bringen, die Relais direkt zu treiben, oder sind da Probleme vorprogrammiert?
Der PCF8574 könnte das zwar strommässig mit machen, allerdings kann er nur mit maximal +7V versorgt werden. Also wird sein High-Pegel deutlich unter den 8,2V liegen -> also flattert es auch.
Oder hab ich dich falsch verstanden?
Wenn du nicht zusätzlich eine 12V-Versorgung einbauen willst, warum nimmst du dann keine 9V-Relais. Oder hast du die Relais schon gekauft?
mfg sven
-
Salü,Der PCF8574 könnte das zwar strommässig mit machen, allerdings kann er nur mit maximal +7V versorgt werden. Also wird sein High-Pegel deutlich unter den 8,2V liegen -> also flattert es auch.
Oder hab ich dich falsch verstanden?
Wenn du nicht zusätzlich eine 12V-Versorgung einbauen willst, warum nimmst du dann keine 9V-Relais. Oder hast du die Relais schon gekauft?
mfg sven
Arrrgh Denkfehler. Der High-Pegel ist zwar hoch genug, um die Relais abzuschalten (Masseschaltung an den Relais - über den Relais lägen dann nur noch 4V, wenn der 8574 vom Arduino mit 5V versorgt wird), aber der Strom ist dann trotzdem zu hoch. Mist.
Edit: oder hab ich das falsch verstanden, kann der 8574 bei HIGH zwar nur 100µA sourcen, aber mehr sinken? /Edit
9V-Relais sind aber immer selten, und wenn dann teuer; und die meisten Relais ziehen auch zu viel Strom. Die 12V-Takas sind mit 12,5mA bei 12V halt echt der Knaller, finde ich. Mir wird wohl nix anderes bleiben, als 12V und 9V in der Kiste bereit zu stellen.
Haste 'ne Meinung zu der Einschalt-Geschichte?
Gruß, Nils
-
Salü,
Haste 'ne Meinung zu der Einschalt-Geschichte?
Wie sieht den die Verschaltung rund um die Schaltkontakte der Relais aus? Wenn die Relais Umschalter sind, könnte man sie ja einfach passend verkabeln oder?
Kenn mich mit Loopern und dem Kram allerdings nicht so aus (mir reicht en Wah und en 2-Kanal-Amp ;) ). Weiß deshalb nicht warum es stört, wenn die Ausgänge High sind. Evtl. könnte man auch die Betriebsspannung der Relais schaltbar machen, sodass man erst den Portexpander initialisiert und dann vom µC die Betriebsspannung für die Relais frei gibt.
mfg sven
-
Salü,Wie sieht den die Verschaltung rund um die Schaltkontakte der Relais aus? Wenn die Relais Umschalter sind, könnte man sie ja einfach passend verkabeln oder?
Kenn mich mit Loopern und dem Kram allerdings nicht so aus (mir reicht en Wah und en 2-Kanal-Amp ;) ). Weiß deshalb nicht warum es stört, wenn die Ausgänge High sind. Evtl. könnte man auch die Betriebsspannung der Relais schaltbar machen, sodass man erst den Portexpander initialisiert und dann vom µC die Betriebsspannung für die Relais frei gibt.
mfg sven
Naja wenn die Ausgänge High sind, schaltet der Transistor oder 2804 durch, die Relais werden geschaltet und die Loops wären alle aktiv. Verdrahte ich die Relais so, dass sie bei einem High des 8574 aus sind, sind sie alle durchgeschaltet, wenn keine Spannung da ist - das ist auch doof, stell' Dir vor, aus irgendeinem Grund fällt die Spannungsversorgung am Rackgerät aus, und plötzlich sind ALLE Effekte an ;D .
Gruß, Nils
-
Salü,
Okay, jetzt versteh ich das Problem.
Mal zwei Lösungsideen, die mir auf die Schnelle einfallen würden:
1. wie beschrieben die Relaisspannung erstfreigeben, wenn der Expander initialisiert wurde
2. einfach mal ausprobieren, wie lang der High-Zustand dauern würde, wenn der µC gleich als erstes den Expander initialsieren würde und dessen Ausgang auf Null setzten. Vielleicht störts gar nicht.
Wo findet man die Info über den Startzustand im Datenblatt? Habs grad nur schnell überflogen und nix gefunden.
mfg sven
PS: anderster rum verkabelni ist ja dann eigentlich keine so schlechte Lösung (wenn dir/uns sonst nichts besseres einfällt), da sie nur im Fehlerfall ein Problem wäre. Und alle Effekte an, ist dann vielleicht auch ein nettes Ablenkungsmanöver. ;) Und wenn du die Effekte aus der selben Quelle mit speisen willst, haben die ja dann auch keinen Saft mehr
-
Moin,
ich denke, ich bau 'ne Einschaltverzögerung über ein Relais ein. Wenn ein freier Pin am µC über bleibt, kann ich's sogar vom µC aus schalten, wenn nicht, dann halt einen npn per RC-Glied durchsteuern.
Gruß, Nils
-
Moin,
ich hab in der letzten Woche mal Stück für Stück weiter gemacht. Für die Rackunit hab ich ein paar Entscheidungen getroffen:
1. I/O-Erweiterung durch den Einsatz von I²C-Portexpandern, in diesem Fall 8x PCF8574. Gerade für das Ansteuern der LED und Abfragen der Taster ist das Killerargument, dass die Module gemischt als I/O konfiguriert werden können.
2. In Sachen µC steht für mich der Zukauf eines Boards fest, und auch schon, welches. Ich habe mich für das Freeduino USB Kit entschieden. Das ist ein Arduino Diecimila-kompatibles Board mit einem 328P, welches weitestgehend auf SMD verzichtet und als Through-Hole-Bausatz für rund 20 Euro zu haben ist. Da hab ich auch kein schlechtes Gewissen, das eingebaut zu belassen. Im Übrigen ist ein MEGA-Board für den Floorcontroller auch raus aus der Nummer, weil ich doch möglichst auf SMD verzichten will. Man stelle sich vor, ich schrotte aus versehen den µC, dann kann ich das ganze Board wegschmeißen - bei obigem Board wird halt einfach ein neuer in die Fassung gesteckt.
3. Ich habe die Möglichkeit sondiert, für die Rackeinheit doch PCBs zu erstellen, weil die Schaltung doch schon relativ komplex ist. Ich habe mich aber dagegen entschieden, gerade für einen Prototypen ist mir der Preis vernünftiger Boards zu hoch. Außerdem hab ich keine Ahnung vom PCB-Layout, und in der freien Version von Eagle ist man ja auch auf 100x80 beschränkt, was bei weitem nicht ausreicht. Deshalb werde ich die Schaltung auf Lochraster aufbauen und die Leiterbahnen halt von Hand mit Silberdraht verlegen ;D .
Ich hab auch schon eine fast komplette Stückliste gemacht, demnach komme ich auf Materialkosten von ca. 200 Euro.
Anbei mal der Stromlaufplan, am Layout arbeite ich noch.
Gruß, Nils
-
Salü,
Zwei Dinge die mir jetzt beim drüber gucken aufgefallen sind:
1. ext. Interrupt:
Ich würde den nur bei den Expandern anschließen, die auch (teilweise) als Eingänge verwendet werden.
Macht den Aufbau evtl. ein bissel übersichtlicher, wenn ein paar Verbindungen wegfallen.
2. Pull-up-Rs:
Ich hab keine Pull-up-Widerstände für den I2C-Bus gefunden.
http://www.sprut.de/electronic/pic/grund/i2c.htm#kabel
mfg sven
-
Moin,
danke für's drüberschauen.
Salü,
Zwei Dinge die mir jetzt beim drüber gucken aufgefallen sind:
1. ext. Interrupt:
Ich würde den nur bei den Expandern anschließen, die auch (teilweise) als Eingänge verwendet werden.
Macht den Aufbau evtl. ein bissel übersichtlicher, wenn ein paar Verbindungen wegfallen.
das macht den Kohl, glaube ich, nicht fett. Das beträfe ja eh nur die drei, die die Relais ansteuern, und da ist es - nach meiner bisherigen Layoutskizze - egal, ob ich eine dritte Leitung parallel ziehe. Macht aber natürlich beim Aufbau weniger Arbeit. Mal sehen ;) .
2. Pull-up-Rs:
Ich hab keine Pull-up-Widerstände für den I2C-Bus gefunden.
http://www.sprut.de/electronic/pic/grund/i2c.htm#kabel (http://www.sprut.de/electronic/pic/grund/i2c.htm#kabel)
mfg sven
äh, ja. Vergessen :bier: .
Gruß, Nils
-
Salü,
Ich seh grad das du bei den LEDs und Tastern immer gemischt hast. Mach doch zwei Expander rein mit LEDs und zwei rein mit Tastern und nur einen gemischt. Wenn jetzt ein ext. Interrupt kommt, musst du 5 Portexpander abfragen, bei wem die Taste gedrückt wurde. Machst du nur einen gemischt, sind es nur noch drei mögliche Quellen für einen externen Interrupt, die abgefragt werden müssen.
mfg sven
-
Salü,
Ich seh grad das du bei den LEDs und Tastern immer gemischt hast. Mach doch zwei Expander rein mit LEDs und zwei rein mit Tastern und nur einen gemischt. Wenn jetzt ein ext. Interrupt kommt, musst du 5 Portexpander abfragen, bei wem die Taste gedrückt wurde. Machst du nur einen gemischt, sind es nur noch drei mögliche Quellen für einen externen Interrupt, die abgefragt werden müssen.
mfg sven
So hatte ich es erst; ich hab mich dann beim Layouten für die Mischvariante entschieden, weil es die Verdrahtung der LEDs und Taster in Gruppen zu je vier an einem 8574 erlaubt und die Verdrahtung damit einfacher und übersichtlicher wird. Je ein 8674 lässt sich dann örtllich nahe an der LED-/Tastergruppe plazieren, und ich muss keine Leitungen hin- und herziehen, sondern nur die Busleitung/V+/GND von Expander zu Expander. Die zusätzlichen Abfragen sollten da softwareseitig aber kein Problem sein, ist ja nicht so, als wäre die Anwendung ultra-timingkritisch.
Gruß, Nils
-
Salü,
Ok hast recht, macht Sinn das ganze so zu Gruppen zusammen fassen.
mfg sven
-
Naja wenn die Ausgänge High sind, schaltet der Transistor oder 2804 durch, die Relais werden geschaltet und die Loops wären alle aktiv. Verdrahte ich die Relais so, dass sie bei einem High des 8574 aus sind, sind sie alle durchgeschaltet, wenn keine Spannung da ist - das ist auch doof, stell' Dir vor, aus irgendeinem Grund fällt die Spannungsversorgung am Rackgerät aus, und plötzlich sind ALLE Effekte an ;D .
Gruß, Nils
Sorry für die späte Antwort.
ULN2803 ist ein open-collektor-Treiber, invertiert und löst Dein Problem.
Dann sind im Einschaltzustand alle aus.
Und wenn das Ding keinen Saft hat, sowieso. ;D
-
Und noch 2 Sächele, Du hast Glück, daß ich grade beruflich mit den Dingern rummache :
- Die gemeinsame Interruptleitung der 8574 sollte nen Pullup haben, 10k sind angemessen.
- Die Schalteingänge der 8574 müssen auch Pullups haben, ich nehme da Wiederstandsleitern mit 1k.
- Die fehlenden Pullups an den beiden I2C-Leitungen hat der Kollege ja schon angemahnt.
Weitermachen !
:guitar:
-
Moin,
Open Collector-Ausgänge haben die ULN280X doch alle. Genau das invertierende Verhalten ist doch das Problem: Die Ausgänge des 8574 sind nach dem Einschalten HIGH, wodurch der Ausgang des 280X auf LOW gezogen wird und die Relais schalten. Erst wenn der µC die Ausgänge der 8574 auf LOW setzt, werden die Relais abgeschaltet.
Das hat den Vorteil, dass man nicht mit invertierter Logik programmieren muss - HIGH = an, aber beim Einschalten ist das halt doof. Ich hab mich jetzt für eine fixe Einschaltverzögerung für den Spannungszweig der Relais entschieden.
Zu den Pullup-Widerständen: Die Busleitungen und die Interruptleitungen hatte ich schon nach Svens Einwurf mit Pullups ausgerüstet. Bei den 8574 hab ich mich jetzt an die gängigen Beispiele im Netz gehalten, dort wird immer gesagt, dass die internen Pullups für Tastereingänge ausreichend sind.
Anbei mal der aktualisierte Planentwurf, außerdem mal mein Layoutentwurf. (Edit: Layouts noch mal ausgetauscht /Edit)
Gruß, Nils
-
Salü,
Was mir grad noch aufgefallen ist. Du hast bei den Relais überall die üblichen Schutzdioden eingebaut.
Hat der ULN2804 die nicht schon intern oder deute ich da das Datenblatt falsch? http://www.utc-ic.com/spec/ULN2804.pdf
Dann hast du für die Pullups 680ohm vorgesehen. Ist zwar nur ne Kleinigkeit, aber du könntest da eigentlich genauso gut 1k nehmen. Dann hast du überall ein 1k verbaut und kannst evtl durch Staffelpreise bei der größeren Bestellmenge Geld sparen. ;)
mfg sven
-
Hallo,
zurück aus meinem Urlaub sehe ich hier erfreulich viel Fortschritt.
Respekt !!!
-
Moin,
richtig, die ULN280X haben integrierte Schutzdioden, eigentlich bräuchte ich den COM nur mit +12V zu verbinden; meine bisherige Erfahrung ist aber, dass die Dioden am besten funktionieren, wenn sie so dicht wie möglich am Relais sind. Mal sehen, die 1N4148 hab ich eh zu Hauf rumfliegen.
Mit den 680R hast Du recht, 1k dürchte auch noch genug Strom liefern, um den 2804 durchzuschalten.
Gruß, Nils
-
Hallo,
zurück aus meinem Urlaub sehe ich hier erfreulich viel Fortschritt.
Respekt !!!
Merci ;D . Hoffe, der Urlaub war gut :bier: .
Für mich ist das Projekt eine sehr große Herausforderung, weil ich a) noch nie was mit µC gemacht habe und b) meine Programmierkenntnisse sehr rudimentär und eingerostet sind. Mal sehen, ob's was wird. Die finanzielle Ersparnis gegenüber kommerziellen Produkten ist ja bei der Reackeinheit schon enorm (im Moment rund 400 Euronen zum günstigsten Produkt), zumindest wenn man nur die Materialkosten betrachtet; die eigene Zeit darf man ja eh nicht in Betracht ziehen, sonst kann man's auch gleich lassen.
Ich vermute dass der Controller bei ähnlichen Materialkosten liegen wird, dafür wird die Software um einiges aufwändiger; aber hier gibt es vermutlich ein gigantisches Sparpotential. Und da sagen immer alle, selber machen is' nich' billiger :devil: :devil: :devil: .
Gruß, Nils
-
Hallo,
ja der Urlaub war gut (Argentinien und Chile).
Wichtigste Erkenntnis ist: Der Winter in Chile ist vergleichbar mit dem Hochsommer in Deutschland: 14 Grad und Regen.......
-
Ich nehm lieber 1N4007 als Schutzdioden, die halten VIEL mehr aus als die 1N4148
und kosten auch fast nix.
Warum nimmst Du als Pullups einzelne R´s ? Da gibbes doch so schöne Netzwerke.
Spart Platz.
Wenn Dich die Logik am ULN280x stört, spendier doch nen billichen Inverter davor (74HCT540 oder 541,
weiss ich grad auswenig nicht, welcher treibt und welcher invertiert)
-
Moin,
Ich nehm lieber 1N4007 als Schutzdioden, die halten VIEL mehr aus als die 1N4148
und kosten auch fast nix.
Naja ich finde, die sind aber auch overkill und nehmen deutlich mehr Platz weg.
Warum nimmst Du als Pullups einzelne R´s ? Da gibbes doch so schöne Netzwerke.
Weil ich gar nicht auf die Idee gekommen bin. Guter Tip, hatte ich nicht auf'm Schirm.
Wenn Dich die Logik am ULN280x stört, spendier doch nen billichen Inverter davor (74HCT540 oder 541,
weiss ich grad auswenig nicht, welcher treibt und welcher invertiert)
Mich stört nicht die Logik des ULN280X, im Gegenteil, die Logik ist ja genau richtig. Das einzige "Problem" ist der Einschaltzustand der 8574 - und das Problem ist, zumindest theoretisch, für mich befriedigend gelöst.
Gruß, Nils
-
Moin,
ich möchte mal ein paar weitere Worte in Sachen Hardware verlieren, nämlich zu
Gehäuse und Ausstattung für den Floor Controller
Das Chassis könnte ein kleineres Problem werden, abhängig davon, wie kompromissbereit ich hier bin. Das Gehäuse soll 26-27 Taster mit LED, den µC und ein 2x16-Zeichen-LCD beherbergen; evtl. auch noch, genauso wie die Rackeinheit, eine vierstellige 7-Segment-Anzeige zur Anzeige der Patchnummer, denn das LCD verkommt im Bühnenalltag zum Ablesen mit Sicherheit zur kleinen Funzel. Für mehr als die Patchnummer taugt die 7-Segment-Anzeige aber nicht, weil man nicht alle Buchstaben damit darstellen kann, und deswegen taugt sie auch nicht als einzige Anzeige. Hier hab ich noch keine vernünftige und gleichzeitig bezahlbare Alternative gefunden.
Jedenfalls, das Gehäuse muss entsprechend groß sein. Mein aktueller Controller ist 400x300 und hat vier Reihen mit je fünf Fußschaltern. Der horizontale Abstand der Schalter beträgt 75 mm, der vertikale - glaube ich - 70 mm. Bei diesen Abständen sind die Schalter gut bedienbar, allerdings braucht es dafür passendes Schuhwerk - schwere Lederstiefel oder Trekking Boots sind hier aus dem Rennen - zumindest ich bekomme es mit meinen allwettertauglichen Lederschuhen manchmal nicht hin, nur einen Schalter zu treffen.
Ich habe im Moment drei Alternativen ins Auge gefasst:
Hammond 1456WL1BKBU
- Grundfläche ca. 510 mm x 287 mm
- Oberseite 10° geneigt
- Höhe vorne 40 mm, hinten 90 mm
- 2 mm Aluminium
- Oberteil schwarz, Unterteil blau - yuck.
Eigentlich das optimale Gehäuse, ich habe nichts anderes / besseres gefunden, um fast 40 Fußtaster komfortabel unter zu bringen, und die gewinkelte Oberseite ist natürlich auch toll. 2 mm Alu sollte trittfest genug sein, läßt sich aber trotzdem noch gut bearbeiten. Allerdings ist es mit etwa 65 Euro auch relativ teuer. Weiterer Nachteil: In mein Pedalboard-Flightcase passt es nur mit Ach und Krach, und dann passt auch nix anderes mehr ;D .
Eine günstigere Alternative sind die Chassis der 1441er Serie von Hammond, hier gibt's zwei brauchbare Kanditaten:
Hammond 1441-34 bzw. 36
- 432 mm x 305 mm
- Höhe 51 mm (-34) bzw. 76 mm (-36)
- 1,2 mm Stahl
- schwarz pulverbeschichtet
Hammond 1441-38
- 432 mm x 356 mm x 76 mm
- ebenfalls 1,2 mm Stahl
Ganz großer Nachteil der 1441er Chassis ist, dass sie flach sind. Mein aktueller Controller hat auch keine geneigte Oberfläche, und beim Zugriff (Zutritt ;D ) auf die oberste Reihe ist das schon nervig. Dafür sind sie relativ günstig.
Wenn ich nicht aufs Geld schauen muss, würde ich wohl zum 1456 greifen. Hier lassen sich die Taster in einem 7x4-Raster mit bequemen 75 mm Abstand in beiden Richtungen unterbringen, und speziell im Bereich der Rückwand ist reichlich Platz, um Kram zu montieren.
Das 1441-34 und -36 sind eigentlich zu klein. Bei einem 6x5-Raster haben die Taster horizontal knapp 75 mm Abstand, vertikal reicht's nur für 60 mm - wahrscheinlich viel zu wenig. Einziger Vorteil wäre, dass das Chassis in der -34er-Ausführung nur 51 mm hoch ist, 76 mm (-36) ohne Slope scheint mir relativ viel.
Im 1441-38 würden die Taster ebenfalls in 5 Reihen mit 6 Tastern angeordnet, bei gleichem horizontalem Abstand reicht es vertikal für 70 mm, das geht noch ganz gut (mit den oben geschilderten Winterstiefeleinschränkungen). Das Chassis ist aber halt 76 mm hoch, ich weiß nicht, wie blöd das wirklich ist.
Irgendwie müsste man die 1441er Chassis eigentlich kippen, vielleicht mit unterschiedlich hohen Füßen vorne und hinten (oder hinten Füße und vorne keine - der Controller soll am Ende eh ins mit Schaumstoff ausgekleidete Flightcase), dann wären vermutlich die 76 mm Höhe auch nicht so dramatisch.
Den besten Kompromiss zwischen Platz und Preis bietet für mich im Moment das 1441-38, das ist also derzeit mein Favorit. Vom großen 1456 muss ich mir vielleicht mal einen Papp-Dummy bauen, um einen Eindruck von der Größe zu bekommen; und es kostet halt rund das doppelte.
Jemand andere Alternativen oder Vorschläge?
Gruß, Nils
-
Salü,
Jemand andere Alternativen oder Vorschläge?
Dir ein Gehäuse genau nach deinen Vorstellungen auf Maß kanten lassen?
Ich hab mit dem Shop gute Erfahrungen gemacht (ich erwähn ihn deshalb immer wieder gerne hier ;) ):
http://www.mein-stahlzuschnitt.de/
Einfach ein U-Profil (auf Anfrage sind auch andere Winkel als 90° möglich*) kanten lassen. Seitenteile dann aus Multiplex, Pressspann was auch immer und noch en einfaches Blech für den Boden mitbestellen. Manchmal isses allerdings en bissel schwierig über den Mindestbestellwert (20€) zu kommen und Pulverbeschichtung usw. ist halt nicht möglich.
mfg sven
*http://www.tube-town.de/ttforum/index.php/topic,14874.msg146235.html#msg146235
-
Salü,Dir ein Gehäuse genau nach deinen Vorstellungen auf Maß kanten lassen?
Ich hab mit dem Shop gute Erfahrungen gemacht (ich erwähn ihn deshalb immer wieder gerne hier ;) ):
http://www.mein-stahlzuschnitt.de/ (http://www.mein-stahlzuschnitt.de/)
Einfach ein U-Profil (auf Anfrage sind auch andere Winkel als 90° möglich*) kanten lassen. Seitenteile dann aus Multiplex, Pressspann was auch immer und noch en einfaches Blech für den Boden mitbestellen. Manchmal isses allerdings en bissel schwierig über den Mindestbestellwert (20€) zu kommen und Pulverbeschichtung usw. ist halt nicht möglich.
mfg sven
*http://www.tube-town.de/ttforum/index.php/topic,14874.msg146235.html#msg146235
Keine schlechte Idee - die Bleche für ein Gehäuse mit 450x355 mit 10° Neigung kämen je nach Material auf 23 Euro (Stahl 1mm) / 26 Euro (Stahl 1,5mm) oder 45 (!) Euro (Alu 2mm), plus halt die Holzwangen. Also den Mindestbestellwert schaffe ich ;D .
-
Salü,
Wenn du es bearbeiten kannst, würde ich für die Anwendung Stahlblech klar bevorzugen. Alu ist einfach so lapprig, grad bei der relativ großen Fläche und den Fusstastern.
mfg sven
-
Ich nehm lieber 1N4007 als Schutzdioden, die halten VIEL mehr aus als die 1N4148
und kosten auch fast nix.
Hallo,
1N4148 sind hier schon die richtige Wahl, denn 1N400X sind eigentlich lahme Krücken. Da macht die kleine, flinke 1N4148 ein deutlich besseres Bild. Der Peakstrom ist auch mehr als ausreichend, und mehr braucht es ja auch nicht.
Gruß, Volker
-
... b) meine Programmierkenntnisse sehr rudimentär und eingerostet sind.
Wenn du dabei auf Probleme stößt kann ich dir gerne helfen.
-
Salü,
Wenn du es bearbeiten kannst, würde ich für die Anwendung Stahlblech klar bevorzugen. Alu ist einfach so lapprig, grad bei der relativ großen Fläche und den Fusstastern.
mfg sven
Moin,
2mm Alu sollte eigentlich genauso stabil sein. Der aktuelle Controller ist eine Holzkiste mit einem 1,5mm Alu-Deckel oben drauf, der ist bei 400x300 ausreichend stabil. Was mich aber stört ist der hohe Preis.
Die Bearbeitung von Stahl sollte gehen, wobei das auch eine Frage der Materialstärke ist. Aus dem Bauch heraus würde ich dazu neigen, zu 1mm zu greifen und notfalls in der Mitte eine Stützwange ins Chassis einzubauen. Ich habe ein - zugegeben, viel kleineres - 1441er Gehäuse für meinen Ampswitcher benutzt, das fühlt sich mit 1,2mm Materialstärke an wie ein Panzer. 1,5mm sollte aber auf jeden Fall reichen, worst case ist, dass ich mir meine Stufenbohrer ruiniere, was aber auch kein Drama ist, weil's ein 10 Euro Satz aus der bucht ist (jaja... wer billig kauft, kauft zweimal... schon klar). Problematischer wird da der rechteckige Ausschnitt für das / die Displays. Sollte mit ein paar guten neuen Blättern für die Stichsäge auber auch gehen.
Wenn du dabei auf Probleme stößt kann ich dir gerne helfen.
Danke fürs Angebot. Wenn ich in Probleme laufe, sage ich Bescheid :bier: . Das ist ein paar Jahre her, dass ich in C/C++ programmiert habe, und halt auch nix großes. Ich sehe solche Projekte ja auch immer als Chance, was dazu zu lernen oder vergessenes wieder aufzufrischen. Mal schauen, wie' läuft :) .
Gruß, Nils
-
Moin,
ich hol' das hier mal aus der Versenkung, damit von dem Thema nicht nur Geschwätz überbleibt ;D . Nachdem ich das Projekt vor gut eineinhalb Jahren wegen Verdachts auf umfassende Ahnungslosigkeit und der Gefahr mich zu übernehmen erst mal eingestampft hatte, habe ich diese Baustelle Ende letzten Jahres wieder aufgenommen. Die Grundidee ist dieselbe geblieben, mit ein paar Änderungen im Detail.
Ich habe viel gelesen und rumrecherchiert und mich letztlich gegen die Arduino-Lösung entschieden. Stattdessen habe ich die µC-Schaltung selbst aufgebaut (in der Tat nur Hühnerfutter, wie Sven immer sagt) und mich auch gegen die Arduino-Softwareumgebung entschieden. Ich programmiere den/die µC jetzt also in Standard-avr-C mithilfe der avr-gcc-Toolchain und Eclipse mit AVR-Plugin unter Linux. Bisher läuft's ganz gut, und vorletzte Woche habe ich einen kleinen Meilenstein erreicht, auf den ich auch ein klein wenig stolz bin, weil ich im Herbst letzten Jahres von dem ganzen Kram noch überhaupt keine Ahnung von dem Kram hatte und bisher alles ganz gut funktioniert.
Ich habe mich dazu entschieden, als erstes die (aus meiner Sicht) anspruchsvollere Baustelle in Angriff zu nehmen, nämlich die des passenden Midi-Fußschalters. In meinem Pflichtenheft für die Anlage sehe ich wesentlich mehr Verantwortlichkeit beim Controller als beim Looper/Switcher selbst und daher ein weit größeres Lernpotential. Die Hard- und Software für den Looper/Switcher sollte, wenn der Controller fertig ist, quasi als "Nebenprodukt" mit abfallen.
Der Controller ist jetzt fertig, zumindest was die Hardware und die Schnittstellen zwischen Hard- und Software angeht. Der Controller ist in einem Hammond 1441-32 Stahlblechgehäuse untergebracht. Das Gehäuse ist 432 mm breit, 305 mm tief und 51 mm hoch und beherbergt 20 Taster mit LED sowie ein großes 2x16 Zeichen LC-Display.
Der Microcontroller ist ein ATMEGA 328P und kann in der Schaltung per USB programmiert werden, Das Display, die Taster und die LEDs werden über insgesamt sechs I²C-Portexpander angesteuert. Weil es sich ja um eine Art Prototypen handelt, habe ich, wo es geht, auf feste Verbindungen verzichtet und alle Peripherie steck- oder schraubbar gemacht.
Die obere Platine beherbergt die Schaltung zur Ansteuerung des LCDs. Auf der mittleren Platine ist das 5V-Netzteil, der µC, das externe EEPROM und die USB- und MIDI-Schnittstellen (wobei ich bisher nur MIDI-Out aus dem Gehäuse führe, USB und MIDI-In nicht). Die untere Platine ist die I/O-Platine mit fünf Portexpandern und insgesamt 40 I/Os. Das geht auf PCB sicher alles platzsparender, andererseits ist hier ja Platz genug. Die Platinen sind Streifenrasterplatinen. Ich habe diese gegenüber Lochraster bevorzugt, weil sie für komplexere Sachen einfach übersichtlicher sind, da man bequem längere und vor allem mehrere Busleitungen über die Platine führen kann, der Preis dafür ist dann halt, dass man mehr Platz braucht.
Die Schnittstellen zwischen Software und Hardware (in erster Linie ist das ja der I²C-Bus) sind fertig, die MIDI-Out-Kommunikation ebenfalls, ich muss jetzt "nur" noch das Benutzerinterface schreiben, inklusive Presetverwaltung etc.
Für das Pflichtenheft des Controllers habe ich mich an den gängigen Top-Produkten, die auf dem Markt erhältlich sind, orientiert. In erster Linie waren das das Ground Control Pro von VoodooLab und die RS-T Controller von Custom Audio Electronics. Diese Controller vereinigen die Möglichkeiten eines klassischen Pedalboards mit den Komfortfunktionen eines programmierbaren Systems.
Der Controller wird in zwei Modi betrieben werden können. Im Preset Modus können pro Bank 16 Presets angewählt werden. Wieviele Bänke der Controller haben wird muss ich noch mal nachrechnen, ich habe den Speicherbedarf bisher nur ganz grob überflogen. Ich habe allerdings ein 64kB-EEPROM vorgesehen, da sollte einiges gehen. Pro Preset sollen bis zu acht Program Change Befehle gesendet werden können, außerdem wahrscheinlich auch der Status der 16 Taster (als CC). Welche Latenzen das erzeugt, muss ich noch mal nachrechnen und ggf. einfach ausprobieren. Ältere Looper wie das GCX von VoodooLab kommen ja komplett ohne Presets aus und hören ausschließlich auf CCs, also kann es so schlimm nicht sein.
Über den Taster "DIRECT" wird der Controller in den Stompbox-Modus geschaltet ("Direct Access"), in diesem Fall senden die Taster ausschließlich CC-Befehle, um per Midi einzelne Loops am Looper oder Effektblöcke am Multieffekt oder ähnliches zu schalten. Das ist der Modus, den ich persönlich am meisten benötige, da ich nur ab und zu Presets brauche, aber ganz oft spontan mal Effekte ein- oder ausschalte und so weiter. Über die Taster Up und Down kann innerhalb des Direktmodus' auf ein anderes "Basispreset" umgeschaltet werden. Beim CAE-Controller ist das ein getrennter Speicherbereich mit von den übrigen Presets unabhängigen Patches, ob ich das auch so mache oder einfach die "normalen" Presets damit "durchsteppe" habe ich noch nicht entschieden.
Was sonst an Komfortfunktionen untergebracht wird hängt wohl nur von meiner Kreativität und meiner Laune, die Funktion zu programmieren ab. Das steht mir jetzt bevor. Wann die Software fertig wird, vermag ich nicht zu sagen. Da ich immer nur kleine Zeitabschnitte dafür habe, werden es aber eher Monate als Wochen sein. Vielleicht im Sommer oder so. Parallel werde ich irgendwann anfangen den passenden Looper zu bauen.
Wenn die Software fertig ist, werde ich den Quelltext vermutlich auch veröffentlichen. Nicht weil er besonders gut ist (was er vermutlich nicht sein wird), sondern weil alles Know How dafür eh aus dem Zwischennetz kommt. Wenn alle alles für sich behielten, wäre ich gar nicht erst so weit gekommen.
Anbei noch zwei Bilder.
Gruß, Nils
-
Hi Nils,
kannst du mir sagen warum du dich gegen Arduino entschieden hast, der bietet doch eigentlich alles was du brauchst inkl. MIDI Befehlssatz.
Gruß
Gunther
-
Hi Nils,
kannst du mir sagen warum du dich gegen Arduino entschieden hast, der bietet doch eigentlich alles was du brauchst inkl. MIDI Befehlssatz.
Gruß
Gunther
Der Hauptgedanke war, dass ich so viel wie möglich selbst machen wollte. Der Grund für dieses Projekt war nur zu einem Teil, dass ich sowas "haben" wollte. Es geht mir zu einem ganz großen Teil auch immer darum, mein Wissen zu erweitern, solche Projekte sind für immer immer "nur" der Aufhänger. Ich wollte mich schon länger mit Mikrocontrollern beschäftigen, aber ich setze mich nicht hin und lese tonnenweise Literatur (naja...), um eine LED zum blinken zu bekommen.
Die Arduino-Umgebung mit ihren vielen, fertigen Bibliotheken sind gut, um schnell Erfolge zu erzielen und zum fertigen Produkt zu kommen; der Lerneffekt ist dabei aber möglicherweise bescheiden. Ich will nicht behaupten, ich könnte das selbst besser, ganz im Gegenteil, und es ist auch unökonomisch, das Rad selbst immer wieder neu zu erfinden; mir geht es aber, wie gesagt, auch um das Erwerben von Wissen und das Erweitern von Fähigkeiten. Die Arduino-Umgebung "verbirgt" mir zu viel vor dem Benutzer.
Ein anderer Punkt war, dass ich beim rumexperimentieren gemerkt habe, dass die Arduino-Umgebung seeeehr großzügig mit Speicherplatz umgeht - ein einfaches Blink-Hallo-Welt-Beispiel belegt mal eben eineinhalb Kilobytes im Flash. Ich habe mit dem 328P zwar Speicher genug (32 kB), aber trotzdem, muss ja nicht sein.
Gruß, Nils
-
Hallo Nils,
Hut ab, ich habs bis jetzt nur auf Arduino Basis gemacht und ohne den Luxus von LCD bzw dedizierten Leds bzw Programmierbarkeit durch Taster.
Für mich war es aber am schwierigsten nicht Code oder eine Schaltung zu finden sondern ein konsistentes Bedienkonzept (in meinem Fall für 5 Analoge Potis, 15 Taster und einen Schalter, PC Mode und CC Mode). Vielleicht können Dir meine Varianten ja etwas helfen.
Programmwahl: Ich hab einen eigenen PC Modus, da werden die Taster zu einer numerischen Tastatur, die Bank wird nachdem ich nur den gmaj2 damit steuer vorgewählt und wenn nicht geändert (oder max oder min limits überschritten) bleibt sie wie sie ist. Der patch wird wie eine Telefonnummer eingegeben.
Annahme patch ist am Beginn 0 und patch soll von 0-99 gehen (für die Eingabe von 0 - 127 oder 1 - 128 müsste man das if und den Modulo etwas abwandeln):
patch = patch*10+newInput;
if (patch>100)
{
patch=patch%100;
}
Weiters könnte man wenn man den aktuellen Patch speichert auch Modi vorsehen in denen man man 10 oder 1en Patch weiterschalten kann und bei erreichen der Höchstzahl eine Bank weiterschaltet...
Wenn dann send gedrückt wird, wird Bank und Patch versandt und als actualPatch gespeichert bzw patch auf 0 zurückgesetzt.
Du könntest vorallem nachdem Du ein LCD hast, ja auch die Programmierung über so eine Tastatur lösen.
BTW zum Taster auslesen. Ich machs soweit ich mich erinnere in etwa so:
* für jeden Pin/Taster gibt es einen state speicher (array mit Anzahl der Taster speicherplätzen
* zusätzlich gibt es zwei arrays changeRise changeFall (hier landen pin/taster nummern die sich geändert haben)
* ich gehe per for schleife über alle Taster (zuvor alle Counter auf 0)
* sollte sich ein state ändern , wird geprüft ob es rising oder falling edge ist und das der jeweilige Counter RiseCount bzw FallCount um 1 erhöht
* der geänderte pin im passenden change* array an der passenden Stelle (*Count) gespeichert
* und letztlich noch im state Array geupdated
Weiters liesse sich zB in holdState array zusätzlich die Anzahl der loops speichern in denen keine Änderung auftritt.
Nach der For schleife brauche ich nur noch durch die beiden change* arrays zu gehen (Anzahl der aktuellen änderungen in beiden ist ja auch gespeichert RiseCount und FallCount) und diese abarbeiten bzw mit dem holdArray bewerten.
Damit könntest Du bei kurzem Betätigen eine andere Aktion als bei langem Betätigen auslösen...
Auf jeden Fall noch viel Erfolg mit Deinem Projekt, von so einer Universallösung (bei mir aber sicher auf Arduino Basis, viellleicht mir mehreren MIDI Ausgängen und ein paar programmierbaren looper/switcher) träum ich auch schon länger, aber bis jetzt fehlt einfach die Zeit. BTW für Arduino muss man ja nicht die Arduino IDE verwenden ;)
Auf jedenfall landet der Thread jetzt einmal in den Lesezeichen ;)
Gruß,
Sepp
-
Moin Sepp,
das Taster auslesen ist bei meinem Controller schon fertig. Hier habe ich in der Tat nicht das Rad neu erfunden, sondern diese (http://www.mikrocontroller.net/articles/Entprellung#Timer-Verfahren_.28nach_Peter_Dannegger.29) bewährte Routine verwendet. Ich habe sie für die Abfrage über I²C angepasst und außerdem auf bis zu 32 Taster aufgebohrt. Die Taster werden entprellt, und ich kann zwischen kurzem Druck, langem Druck und loslassen unterscheiden, außerdem auch das gleichzeitige Drücken mehrerer Tasten berücksichtigen.
Die Taster werden zyklisch über eine Timer-ISR abgefragt. Für eine sichere Entprellung muss der Taster vier mal hintereinander einen stabilen Zustand haben. Die ISR läuft alle 8ms, es dauert also 32ms plus Prellzeit, um einen (oder mehrere) Tastendrücke zu erkennen. Ich denke, das ist schnell genug.
Gruß, Nils
-
Danke für den Link Nils, ich Idiot hab mir damals noch selbst so einen Mist überlegt der im Endeffekt genau die selbe Funktionalität wenn auch undokumentiert liefert *grml*. Ist jetzt ebenfalls in den Lesezeichen ;) Die numerische Tastatur ala Telefon kann ich zumindest zum Programmieren des Kontrollers trotzdem nur empfehlen, ok ich verwende es zu direkten Patchwahl. Es funktioniert und ist intuitiv.
@8ms bzw 32ms plus Prellzeit: Da sollte sich ja auch Taptempo per Midi realisieren lassen ;)
Gruß,
Sepp
-
Die numerische Tastatur ala Telefon kann ich zumindest zum Programmieren des Kontrollers trotzdem nur empfehlen, ok ich verwende es zu direkten Patchwahl. Es funktioniert und ist intuitiv.
Mal sehen, ob ich das brauche. Meinen bisherigen Spielgewohnheiten entsprechend brauchte ich nicht mal eien Bankwahl... da käme ich mit 1x 16 Presets wahrscheinlich dicke hin :) .
@8ms bzw 32ms plus Prellzeit: Da sollte sich ja auch Taptempo per Midi realisieren lassen ;)
Da gehe ich aus von... Tap Tempo ist ein absolutes Muss-Feature bei mir. Schon weil unser Drummer kein Tempo halten kann :devil: .
Gruß, Nils
-
Mal sehen, ob ich das brauche. Meinen bisherigen Spielgewohnheiten entsprechend brauchte ich nicht mal eien Bankwahl... da käme ich mit 1x 16 Presets wahrscheinlich dicke hin :) .
Ok dann soll er vermutlich auch gar nicht offline ohne PC programmierbar werden? Ich denke wahrscheinlich schon wieder zu oversized, um dann im Nachhinein feststellen zu müssen, eigentlich braucht man es so nicht ;)
Nur wer weiß was noch kommt, wenn man dem Trend folgt und auch die DIY Amps midifiziert und basteln hat ja auch seinen Reiz.
Da gehe ich aus von... Tap Tempo ist ein absolutes Muss-Feature bei mir. Schon weil unser Drummer kein Tempo halten kann :devil: .
>:D
Gruß und viel Erfolg,
Sepp
-
Ok dann soll er vermutlich auch gar nicht offline ohne PC programmierbar werden?
da halte ich eh nix von. Das Bedienkonzept des Controllers muss so einfach sein, dass man ihn ohne Probleme "on the fly" programmieren kann. Wenn ich merke "Die Soundkombination brauche ich öfter" - Zack, drei Tasten drücken, Speichern, fertig. Ich werfe doch nicht dem Computer an, um meine Sounds einzustellen ;) . Da bin ich vermutlich zu alt für. Abgesehen davon schleppe ich keinen PC oder Laptop mit in den Proberaum.
Gruß, Nils
-
da halte ich eh nix von. Das Bedienkonzept des Controllers muss so einfach sein, dass man ihn ohne Probleme "on the fly" programmieren kann. Wenn ich merke "Die Soundkombination brauche ich öfter" - Zack, drei Tasten drücken, Speichern, fertig. Ich werfe doch nicht dem Computer an, um meine Sounds einzustellen ;) .
Ah dann hast Du noch ein anderes Konzept, bin auf das Ergebnis gespannt. Ich wuerde ATM, hab mich aber noch nicht im Detail mit Programmierbarkeit auseinander gesetzt, einen Editiermodus vorsehen, in dem die PC und/oder CC Nachrichten frei numerisch programmiert werden koennen... Du scheinst ja eher Richtung, eines festen PC/CC Nachrichtensatzes zu tendieren und diese einzeln zu aktivieren bzw deaktivieren und diese States zu speichern. Ich glaub jetzt verstehe ich Dich.
Auf jeden Fall bin ich auf Deine Loesung gespannt. Meiner Meinung nach ist es auch das Schwierigste, sei es hier oder in Amps, ein vernuenftiges Bedienkonzept zu erstellen.
Gruss,
Sepp
-
Du scheinst ja eher Richtung, eines festen PC/CC Nachrichtensatzes zu tendieren und diese einzeln zu aktivieren bzw deaktivieren und diese States zu speichern. Ich glaub jetzt verstehe ich Dich.
Genau so isses. Es sollen im Controller bis zu acht Geräte definiert werden können, und pro Preset kann ich dann auswählen, ob und welcher PC an welches Gerät gesendet werden soll.
Außerdem wird es ein globales Setup geben, wo jedem Taster ein vordefiniertes Gerät und ein CC# zugewiesen wird. Zusätzlich will ich noch einstellen können, ob's ein Schalter (toggle) oder ein Taster (momentary) ist, und ob - im Falle von Toggle - der gespeicherte Status beim anwählen eines Presets mitgesendet werden soll oder nicht.
Das ist auch der Grund, warum ich so viele CC-Taster vorgesehen habe; macht man die Taster vollständig frei programmierbar, dann käme man ja theoretisch mit deutlich weniger Tastern aus, weil man in Preset A das eine Gerät X und in Preset B ein anderes Gerät Y mit ein und demselben Taster steuern könnte. Das ist programmiertechnisch flexibler, Performance-technischer verliert man aber eher Flexibilität. So ist man deutlich dichter am "echten" Pedalboard dran, das dann aber den Bonus der Programmierbarkeit hat. Ich will halt einen Controller für "Player" (also mich ;D ) bauen, nicht für Programmierer.
Ich hab mir das natürlich nicht alles selbst ausgedacht, das ist im Prinzip die Basisfunktionalität aller "großen" Midi-Floorboards, die ich mir angesehen habe.
Gruß, Nils
-
Moin,
mal ein (langes) Statusupdate von mir. Ich hatte gerade Urlaub und habe in den letzten zwei Wochen intensiv an der Firmware des Controllers weitergearbeit, nachdem die fertige Hardware jetzt ein halbes Jahr im Regal verstaubte.
Bis auf die Routinen zum bearbeiten, speichern und kopieren/verschieben von Presets ist alles fertig. Der Controller kann jetzt folgendes:
- Speichern und abrufen von 800 Presets in 50 Bänken zu 16 Presets. Die Grenze wir im Prinzip nur von der Größe des EEPROMs gesetzt, ich habe ein AT24C512 mit 64 kB verbaut, da ist noch etwas Luft nach oben. Ein Preset ist im Moment 29 Byte groß.
- Im Controller können bis zu acht MIDI-Geräte angelegt werden. Jedem gerät kann ein achtstelliger Name sowie ein MIDI-Kanal zugeordnet werden, außerdem kann jedes Gerät dezidiert aktiviert oder deaktiviert werden.
- Im Direktmodus arbeitet der Controller wie ein Pedalboard, die 16 Presettaster arbeiten als an/aus für einzelne Effekte oder Einstellungen, die Taster senden CC# ("binär", entweder 0 oder 127). Ob ich das mit Zwischenwerten noch mal konfigurierbar mache, muss ich überlegen. Eigentlich ist das aber unnötig. Jeder Taster kann einem hinterlegten Gerät zugeordnet werden, außerdem können CC# und Betriebsart eingestellt werden. Die drei Betriebsarten eines Tasters sind Normal (an/aus), Taster und "Senden mit Preset" (wie Normal, aber der im Preset gespeicherte Zustand wird beim Presetabruf mit raus gesendet). Insgesamt stellt der Controller 32 Taster zur Verfügung, die Taster 17-32 sind "virtuell" und über die 16 physischen Taster per "Shiftfunktion" erreichbar.
- Auch im Direktmodus ist der Presetwechsel möglich, hier können die Presets per "UP"/"DOWN"-Taster durchgesteppt werden, auch bankübergreifend, also auf Preset 16 in Bank 1 folgt bei "UP" Preset 1 in Bank 2. Andere Controller (z.B. die CAE Controller) nutzen hier getrennte Preset-Speicherbereiche, das fand ich aber unnötig.
- Redundante Midinachrichten werden vom Controller gefiltert, d.h. beim Abruf eines Presets wird nur das gesendet, was sich zum vorher aktiven Preset unterscheidet. Auch der erneute Abruf eines Presets z.B. bei versehentlicher doppelter Betätigung eines Tasters wird herausgefiltert. Über langes Drücken eines Tasters kann der Filter übergangen werden, dann sendet der Controller das komplette Preset (ggf. erneut).
- Das LCD zeigt im Presetmodus die aktuelle Bank, die Presetnummer und den Namen des Presets an. Im Direktmodus zeigt es bei Tasterbetätigung den Namen und den Zustand des Tasters an. Letzteres ist eigentlich überflüssig, denn jeder Taster hat ja eine LED.
Weggelassen habe ich ein MIDI-IN und die Anschlussmöglichkeit von Expression Pedalen. Sollte ich das doch mal brauchen, muss ich das halt nachrüsten. Was noch fehlt sind wie gesagt die Presetroutinen, außerdem wäre es vermutlich nicht unklug, Konfiguration und Presets irgendwie extern sichern zu können. Das muss also auch noch.
Der Mikrocontroller ist in der Schaltung programmierbar. Auf der Platine sitzt eine ISP-Wannenstecker, außerdem habe ich einen Bootloader auf dem µC installiert, so dass er per USB bzw. MIDI programmiert werden kann. Praktisch ist das im Moment so, dass ich eine kleine USB-to-UART-Bridge habe, die am Board angeschlossen ist und deren Kabel aus dem Gehäuse raushängen. Ob und wie ich die Firmware per MIDI-Schnittstelle updaten kann, muss ich noch mal rausfinden. Gegebenenfalls baue ich entweder eine USB-Flanschbuchse ein und belasse die UART-Bridge im Controller, oder ich löte einfach mal einen MIDI-Stecker an die Bridge.
Ich habe den Controller bisher nur zu Hause am Audio/MIDI-Interface getestet. Ich habe mir den Output mit der Software MIDI-OX angesehen, bisher passt das alles. Der Controller sendet ja theoretisch bis zu 40 Nachrichten pro Preset, im Moment sind es maximal 17, da ich die virtuellen Taster deaktiviert und nur ein Gerät eingerichtet habe. Die Nachrichten erscheinen bei Tastendruck im Prinzip sofort auf dem Bildschirm, die Performance scheint also sehr gut zu sein. Die meisten Rackgeräte reagieren vermutlich deutlich langsamer. Ob der Controller ggf. sogar zu schnell ist, muss ich noch rausfinden.
Heute Abend nehme ich den Controller mal mit zur Probe und steuere mein G-Sharp damit. Habe ich letzte woche schon mal gemacht, aber da war die Leistung der Firmware noch deutlich reduziert und ich hatte nur ein paar MIDI-Befehle hart gecoded eingebaut. Heute will ich mal schauen, ob der Controller, so wie er jetzt ist, den ganzen Abend stabil und ohne Abstürze durchläuft.
Im nächsten Schritt baue ich dann noch das Rackgegenstück. Hier habe ich mich gegen den kompletten Neubau eines Rackloopers/Switchers entschieden, da ich ja einen voll funktionierenden Relaislooper habe. Stattdessen werde ich eine Steuereinheit bauen, die dort anflanscht, wo das vorhandene Steuerpedal des Loppers angeschlossen wird.
Die Steuereinheit wird wohl auch sehr viel einfacher und "dümmer" als der Controller werden. Kein Display, keine Taster, keine LEDnn womöglich nicht mal Presets. Die Rackeinheit wird vermutlich ausschließlich per CC# gesteuert werden. In meinem Ansatz ist also der Bodencontroller das Gehirn des Setups, nicht der Racklooper, wie das in vielen anderen Projekten ist. Der vorhandene Relaislooper hat 12 Loops und 7 Schaltausgänge, passend zum Controller werde ich die Rackeinheit auf 32 Schaltausgänge auslegen.
Ich hoffe, ich bekomme die Controllerfirmware nächste Woche soweit fertig, dann versuche ich zeitnah, auch die Rackeinheit zu bauen. Die Bauteile dafür habe ich alle schon zu Hause, lediglich ein Gehäuse muss ich noch kaufen - und die Platinen bauen / bestücken.
Ich muss mal sehen, wie es mit der Veröffentlichung des C-Quelltextes hier steht. Es ist fast alles von mir, die Entprellroutine basiert auf obigem Link, sonst habe ich, glaube ich, keinen fremden Quelltext benutzt; muss ich noch mal prüfen. Wer sich direkt bei mir meldet, kann aber - wenn ich komplett fertig bin - den Quelltext gerne von mir bekommen. Er ist sicherlich nicht der eleganteste, schönste, kompakteste, speicherschonenste oder perfomanteste Code, aber er funktioniert. Die kompilierte Firmware ist derzeit 11 kB (!!!) groß, es braucht also schon einen der größeren ATMEGA dafür.
Mein persönliches Fazit ist auf alle Fälle schon mal, das sich das Projekt absolut gelohnt hat. Ich habe quasi bei Null angefangen und sehr viel dabei gelernt, und wenn man die investierte Zeit nicht mitrechnet (was man ja eh nicht machen darf) habe ich vermutlich einige hundert Euro im Vergleich zu komerziell erhältlichen Controllern gespart, vor denen sich meiner nicht zu verstecken braucht. Außerdem habe ich - wie beim Ampbau auch - einiges an Respekt vor den im Handel erhältlichen Produkten verloren. Die kochen auch nur mit Wasser, und einige Preise und auch einige Defizite sind, wenn man's erst mal selbst gemacht hat, kaum mehr verständlich.
Gruß, Nils
-
Hallo Nils,
:topjob: Du bist ja schon um einiges weiter, meiner verstaubt noch, wenn auch teil genutzt im Rack.
Im nächsten Schritt baue ich dann noch das Rackgegenstück. Hier habe ich mich gegen den kompletten Neubau eines Rackloopers/Switchers entschieden, da ich ja einen voll funktionierenden Relaislooper habe. Stattdessen werde ich eine Steuereinheit bauen, die dort anflanscht, wo das vorhandene Steuerpedal des Loppers angeschlossen wird.
Mir schwebt genau das Gegenteil vor, intelligentes Rack, dummer bis maximal mit Grundschulkenntnissen ausgestatteter Footswitch. Wie hast Du die Verbindung und Stromversorgung geloest. Ich wuerde ATM noch zu 2 XLR Verbindungen tendieren.
Außerdem habe ich - wie beim Ampbau auch - einiges an Respekt vor den im Handel erhältlichen Produkten verloren. Die kochen auch nur mit Wasser, und einige Preise und auch einige Defizite sind, wenn man's erst mal selbst gemacht hat, kaum mehr verständlich.
Yepp, vorallem bei den einfacheren Markengeraeten, zB nur PC Nachrichten, sind die Preise wirklich ein Witz.
Gruss,
Sepp
-
Moin Sepp,
Mir schwebt genau das Gegenteil vor, intelligentes Rack, dummer bis maximal mit Grundschulkenntnissen ausgestatteter Footswitch.
Das sind ja so die beiden konkurrierenden Ansätze, dummer rein presetbasierter Controller und möglichst ausgefeilter Racklooper vs. einfacher Looper vs. intelligenter Controller. Meine Entscheidung für letzeres basiert auf der Tatsache, dass der Pedalboardbetrieb für mich wichtiger als der Presetbetrieb ist. Mir ist es sehr wichtig, im Prinzip alle geloopten Effekte nach Gusto ein- und ausschalten zu können und gleichzeitig auch mein 19"-Rackgerät vernünftig steuern zu können. Daneben habe ich ab und zu mal das Bedürfnis danach, den einen oder anderen Sound als Preset abzuspeichern. Dafür brauchte ich eben viele CC-fähige Taster und die meisten bezahlbaren Controller können das eben nicht leisten. Wenn der Controller aber eh so programmiert ist, dass er die CC's beim Presetwechsel mit rausschickt (und das machen alle großen, die ich mir angesehen habe; primär waren das das Ground Control Pro und der RS-T von CAE), dann braucht's den Presetkram im Looper eigentlich nicht.
Das ist auch der Grund, warum ich bei Dirks MIDI-Kanalumschaltung nach CCs gefragt hatte, und das stört mich auch an so Projekten wie dem JimKim Switch - nur auf PC reagieren ist halt doof für mich.
Wie hast Du die Verbindung und Stromversorgung geloest. Ich wuerde ATM noch zu 2 XLR Verbindungen tendieren.
Ich bin mir nicht sicher, was Du meinst. Der Controller hat als einzigen Anschluss eine normale MIDI-Out-Buchse. Auf so Spezialkram wie 5-polige XLR wollte ich verzichten, um den Bedarf nach Spezialkabeln zu vermeiden. Die Spannungsversorgung erfolgt entweder per Phantompower über die freien Pins 1 und 3 im MIDI-Kabel oder per DC-Buchse. Der Controller hat eine gemessene Stromaufnahme von 67 mA (Display und alle LED an), ist also einigermaßen sparsam. Der Löwenanteil entfällt auf die Displaybeleuchtung.
Yepp, vorallem bei den einfacheren Markengeraeten, zB nur PC Nachrichten, sind die Preise wirklich ein Witz.
Zustimmung.
Gruß, Nils
-
... bezahlbaren Controller ...
Ja da wirds so duenn dass eigentlich nichts ubrigbleibt. Auf der anderen Seite, die Bauteilkosten fuer eine DIY Loesung mag zwar niedriger sein, aber die Arbeitszeit inkl einarbeiten ist schon enorm. Das ist aber auch die schoenste Zeit daran ;) wenn man sie den hat.
Ich bin mir nicht sicher, was Du meinst. Der Controller hat als einzigen Anschluss eine normale MIDI-Out-Buchse. Auf so Spezialkram wie 5-polige XLR wollte ich verzichten, um den Bedarf nach Spezialkabeln zu vermeiden. Die Spannungsversorgung erfolgt entweder per Phantompower über die freien Pins 1 und 3 im MIDI-Kabel oder per DC-Buchse. Der Controller hat eine gemessene Stromaufnahme von 67 mA (Display und alle LED an), ist also einigermaßen sparsam. Der Löwenanteil entfällt auf die Displaybeleuchtung.
Nein ich meinte, ich stelle mir vor zwischen Rack und Pedal nur normale XLR verbindungen zu benutzen, vielleicht einmal male und einmal female. Eines fuer die Stromversorung, eines zur Kommunikation. Mikrokabel sollten doch immer aufzutreiben sein und normale MIDI-Geraete koennten ja ueber die Rackunit angeschlossen werden.
Gruss,
Sepp
-
die Bauteilkosten fuer eine DIY Loesung mag zwar niedriger sein, aber die Arbeitszeit inkl einarbeiten ist schon enorm. Das ist aber auch die schoenste Zeit daran ;) wenn man sie den hat.
Zeit: Das ist der Punkt, warum das hier schon so lange dauert. Der Thread hier ist ja schon mein zweiter Anlauf, das Thema beschäftigt mich ja schon seit mehreren Jahren. Die fertige Controllerhardware hat jetzt ja auch wieder ein halbes Jahr im Regal staub angesetzt, weil ich keine Zeit hatte, die Software zu programmieren. Weil mich das genervt hat, bin ich letzte Woche dann mal im :urlaub: in Klausur gegangen und hab fast nichts anderes gemacht ;D
.
Die Kosten sind ein Witz. Ich habe direkt auch die Bauteile für die Rackeinheit eingekauft und dazu den einen oder anderen µC und PCF in Reserve, also einiges an Redundanzen, und ich habe, glaube ich, weniger als 180 Euro für die ganze Hardware bezahlt. Und da sind 'n Zwanni für's Gehäuse, 40 Euro für Taster und 40 für's Display mit drin. Der Controller, der für meinen Pate stand, schlägt beim großen T mit 450 oder so zu Buche, und der kann in einigen Bereichen weniger als meiner (unter anderem nur 8x Direktzugriff, und ich hab keinen Einfluss auf die Software). Andere ähnlich teure Controller können sogar noch weniger.
Neu entdeckt habe ich den MIDI Raider von Rocktron, der ist etwas günstiger und hat eine ähnliche Ausstattung.
Aber vom Geld sollte man eh nicht reden. Viel wichtiger ist der Zugriff auf die Software. Wenn mri was nicht passt oder fehlt, kann ich das jederzeit ändern.
Gruß, Nils
-
Salü,
Erstmal gratulation, dass dein Projekt (erfolgreich) dem Ende entgegen geht. :)
Wobei man ja immer noch eine Idee hat, was man an der Software ändern/verbessern könnte ;)
Was noch fehlt sind wie gesagt die Presetroutinen, außerdem wäre es vermutlich nicht unklug, Konfiguration und Presets irgendwie extern sichern zu können. Das muss also auch noch.
Hast du noch nen SPI-Port an deinem µC frei? Dann wäre eine SD-Card evtl. eine Lösung. Es gibt auch eine FAT-Lib für 8Bit-µC (http://elm-chan.org/fsw/ff/00index_p.html).
mfg sven
-
Hallo Nils,
prima, das du dich da jetzt soweit durchgebissen hast und ein (fast) finales Produkt geschaffen hast. Ich drücke die Daumen das es beim Praxistest stabil läuft.
Sicherlich könnte man mit Assembler noch ein wenig zaubern(Speicherplatz etc.) aber scheint ja nicht nötig zu sein. Viel wichtiger ist ja das Programm einfach zu halten und das es gut erweiter-/veränderbar ist.
Presets/Konfiguration evtl. auf USB Stick abspeichern?
Grüße,
Robin
-
Salü,
Presets/Konfiguration evtl. auf USB Stick abspeichern?
Dazu müsste der µC USB OTG können und das kann der von Nils verwendete ATmega328P laut Herstellerseite nicht.
mfg Sven
-
Moin,
zum Thema EEPROM/Presets sichern: Ich hab mich ein wenig in die Themen SysEx und Bulk Dump/Load eingelesen, ich denke, ich werde das so machen. Die Routinen hierfür dürften überschaubar sein, Softwareseitig geht das ganz gut z.B. mit MIDI-OX. Allerdings müsste ich fürs zurück sichern doch noch einen MIDI-Input einbauen. Kein großes Problem, auf dem µC-Board ist die Beschaltung bereits vorgesehen. Müsste nur noch mal 'n Lock für die Buchse bohren.
Von fertig bin ich allerdings doch noch ein Stück weg, ich hab doch noch einiges an Baustellen gefunden. Wenn die Presetbearbeitung und -speicherung fertig ist, ist der Controller aber auf jeden Fall schon mal produktiv nutzbar.
Ansonsten hab ich beim erneuten Überfliegen des Marktes noch ein paar Inspirationen gefunden und ein paar andere Ideen entwickelt.
Eine davon ist: Es gibt eigentlich kein Midiboard, welches eine MIDI Beat Clock senden kann; warum eigentlich nicht? Protokollseitig ist das, wenn ich das richtig verstanden habe, relativ simpel: 24 mal pro Beat das Statusbyte F8 senden, fertig. Der Empfänger (in meinem Fall mein Delay) leitet dann aus dem zeitlichen Abstand der ankommenden Statusbytes das Songtempo ab.
Ich spiele 90% aller Songs in meiner Band mit dem gleichen Preset in meinem TC G-Sharp, nämlich ein Hall und ein Delay. Das einzige was sich von Song zu Song unterscheidet ist das Delay Tempo (falls das Delay denn benutzt wird). Normalerweise passe ich das Delay per Tap Tempo an, kein Problem. Aber lustig wäre es doch, wenn ich in den Presets eine BPM Angabe hinterlegen könnte. Der Controller sendet dann die passende MIDI Clock, und das Delaytempo (oder andere Parameter) wird automatisch angepasst.
Ein netter Nebeneffekt wäre, dass ich das auch gleich auf eine LED umlegen könnte und dann so eine Art Metronom im Board hätte. Wäre ganz praktisch z.B. zum einzählen.
Ich frage mich, warum das nie so umgesetzt wird. Wenn man mit einem µC ohne großen Aufwand eine Uhr bauen kann, wird's für eine MIDI Clock und eine Tempo LED doch wohl reichen. Das ganze könnte dann mit einem "Song Mode" kombiniert werden, wie ihn einige Controller bieten, was ja wohl nicht vielmehr als eine Preset-Map ist. Hier könnte ich dann auch die BPM hinterlegen.
Eine weitere Idee ist, vor dem Hintergrund, den Looper relativ dumm halten zu wollen und auf Display und Taster verzichten zu wollen, die Möglichkeit der Remote-Konfiguration des Loopers. Also vom Controller aus per SysEx z.B. den MIDI-Kanal des Loopers einstellen oder sowas.
Also, Ideen gibt's vermutlich noch genug. Am Wochenende werde ich wohl mal die Platinen für den Looper zusammenlöten.
Gruß, Nils
-
Hi Nils,
Ein netter Nebeneffekt wäre, dass ich das auch gleich auf eine LED umlegen könnte und dann so eine Art Metronom im Board hätte. Wäre ganz praktisch z.B. zum einzählen.
Die midiclock Idee gefällt mir. :topjob: Eigentlich schlimm auf wie viele Ideen man kommt wenn man sich so etwas selbst macht.
BTW vielleicht hast Du es schon geschrieben, aber wie hinterlegst Du den Status der Effekte im Board (Annahme: Gmaj oder Gmaj als Gegenstück). Ich speichere sie ATM nicht und damit kann es sein daß das erstemal schalten nach Presetwechsel 127 statt 0 sendet und erst beim zweiten mal findet der Wechsel statt? Speicherst Du alles in Deinen Presets im fußcontroller oder hast Du eine Möglichkeit gefunden den Status beim Gmaj(2) zu erfragen?
Gruß,
Sepp
Gruß,
Sepp
-
BTW vielleicht hast Du es schon geschrieben, aber wie hinterlegst Du den Status der Effekte im Board (Annahme: Gmaj oder Gmaj als Gegenstück). Ich speichere sie ATM nicht und damit kann es sein daß das erstemal schalten nach Presetwechsel 127 statt 0 sendet und erst beim zweiten mal findet der Wechsel statt? Speicherst Du alles in Deinen Presets im fußcontroller oder hast Du eine Möglichkeit gefunden den Status beim Gmaj(2) zu erfragen?
Der Controller ist der Master für alle Presets. Im Presetsatz finden sich die Program Changes für alle Geräte (1 Byte pro Gerät = 8 Byte, MSB als "deaktiviert"-Flag). Außerdem wird der Status der 32 CC-Taster in 4 Byte abgespeichert, für jeden ein Bit. Die CC-Taster sind global konfiguriert, wenn sie als "Senden mit Preset" markiert sind, werden sie beim Presetwechsel mitgesendet.
Das Erstellen von Presets mit z.B. einem G-Major, liefe dann so:
1. Im Controller Program Change festlegen
2. Im Effektgerät Preset aufrufen
3. per CC-Taster die gewünschten Effektblöcke ein- und ausschalten
4. Preset im Controller speichern.
Rufe ich jetzt ein Preset ab, passiert folgendes:
1. Der Controller überprüft den PC-Befehl. Wenn er gleich dem letzten gesendeten Befehl ist, ignoriert er ihn. Ansonsten sendet er den PC ans Effektgerät, das Effektgerät reagiert auf den PC und lädt das Preset.
2. Der Controller sendet alle als "Senden mit Preset" konfigurierten CCs raus. Wenn im G-Major-Preset Chorus, Delay und Hall aktiv sind und die entsprechenden CCs im Controllerpreset als 1 gespeichert sind, passiert nichts. Ist z.B. das Delay im Controller als 0 gespeichert, wird es über den CC-Befehl im G-Major ausgeschaltet.
Statt also zwei Presets im Effektgerät vorzuhalten, die bis auf das Delay identisch sind, brauche ich nur eines, und die Umschaltpause zwischen den Presets fällt weg. Auf diese Weise brauche ich den Status des G-Major nicht zu kennen, weil der Controller den empfangenden Geräten immer seinen Stand "aufzwingt".
Ich hab kein G-Major, aber ein G-Sharp. Ich liebe es, aber es hat Preset-Umschaltzeiten jenseits von gut und böse. Noch dazu speichert es den Status der beiden Effektblöcke nicht mit ab; wenn ich per CC die FX-Engine ausschalte und das Preset speichere, ist das Delay nach dem Laden des Presets wieder aktiv ::) . Noch ein Grund, um den Controller alles steuern zu lassen.
Das war jetzt lang. War's auch verständlich ;D ?
-
Danke für die Ausführlichkeit, also Du speicherst mit und ja das war mehr als verständlich. Eigentlich hätte ich ja nur mit denken müssen, Du empfängst ja nichts *grml*
Gruß,
Sepp
-
Danke für die Ausführlichkeit, also Du speicherst mit und ja das war mehr als verständlich. Eigentlich hätte ich ja nur mit denken müssen, Du empfängst ja nichts *grml*
Kein Problem. Ist meiner Meinung nach die einzige sinnige Lösung. Außerdem Stand der Technik ;D .
-
Kein Problem. Ist meiner Meinung nach die einzige sinnige Lösung. Außerdem Stand der Technik ;D .
Schade ein undokumentiertes Feature im Protokol wäre ja cool gewesen ;)
-
Moin,
gestern Abend hab ich so eine Art Meilenstein erreicht - der Controller ist jetzt mit seinen Grundfunktionen produktiv nutzbar. Heißt: Ich kann jetzt endlich auch Presets bearbeiten.
Nächstes wichtiges Feature ist das kopieren und verschieben/tauschen von Presets, im Moment kann ein Preset nur "in place" bearbeitet werden.
Ich musste im Verlauf feststellen, dass meine keine-Ahnung-einfach-losprogrammieren-Strategie schon seine ersten Opfer fordert: Als erstes drohte mir, der SRAM auszugehen ::) . Stellte sich raus: Alle statischen Strings im Arbeitsspeicher abzulegen ist doof ;) . Diese sowie den Zeichensatz fürs LCD habe ich jetzt ins PROGMEM verlagert, das hat den SRAM-Bedarf wieder auf die Hälfte reduziert. Eienr der kleineren ATMEGA hätte es trotzdem nicht sein dürfen, der Flash-Bedarf liegt derzeit bei 15k.
Darüber hinaus habe ich noch ein paar unerklärliche Abstürze in den Menüs, wenn man verschiedene Tasten zu schnell drückt. Ich vermute, dass der I²C-Bus dann hängt, weil sich Tastendrücke, LCD-Ausgaben und EEPROM lesen in die Quere kommen - vermutlich muss ich in den Menüs einiges noch atomisieren. Zusätzlich werde ich wohl den Watchdog aktivieren, damit er in so einem Fall den Controller automatisch neu startet. Die Abstürze muss ich natürlich trotzdem finden.
Bevor ich weitere Features in den Controller programmiere, kümmere ich mich jetzt erst mal um die Schaltung und die Software für den Looper. Das sollte allerdings deutlich unaufwendiger werden.
Parallel zeichne ich noch vernünftige Pläne, die ich dann zusammen mit den Layouts und der Software beizeiten veröffentliche.
Gruß, Nils
-
Nils, halte durch ..... :devil:
-
Nils, halte durch ..... :devil:
;D . Kein Problem (mehr)... nach mehreren Jahren und diversen Neuanläufen ist die Zielflagge in Sicht. Der Controller ist ja so gut wie durch, was jetzt noch kommt, sind Komfortfunktionen und "nice to have"-Kram.
Die Mikrocontrollerfizierung meines Rackloopers halte ich nur noch für Kinderkram... ;D
Das ist wie der Bau meines ersten eigenen Amps.... voll geil, wenn man sich zusammen stricken kann, was man braucht und haben will, und das funktioniert dann auch noch... :devil: .
-
Hallo Nils,
Das ist wie der Bau meines ersten eigenen Amps.... voll geil, wenn man sich zusammen stricken kann, was man braucht und haben will, und das funktioniert dann auch noch... :devil: .
schön zu hören, daß Du zu einem erfolgreichen Ende kommst und das ganz auch noch dokumentieren willst. Hätte ich bei meine Ausgeburten nur dokumentiert, bei meinen hab ich wirklich keine Ahnung mehr was ich verbaut hab lediglich die Ideen dahinter :( ist aber OT
Hier noch ein paar Ideen zu Deinen Bugs, vielleicht hilft ja etwas:
Vielleicht könnte man konsequentes Queueing einführen und nicht auf jede Eingabe sofort reagieren. Je nach Modus dürften hier aber verschiede Regeln zur Bewertung der Queues nötig sein. (Pedal mode: sofort reagieren, Batch mode: Bank (optional) + sinnvolle Kanalangabe...)...
Viel Erfolg,
Sepp
-
Salü,
Ich vermute, dass der I²C-Bus dann hängt, weil sich Tastendrücke, LCD-Ausgaben und EEPROM lesen in die Quere kommen - vermutlich muss ich in den Menüs einiges noch atomisieren.
Läuft das über Interrupts? Sperrst du alle anderen Interrupts, wenn du ein Ereignis bearbeitest? Evtl. gibt es auch die Möglichkeit Prioritäten für die Interrupts zu vergeben? Kenn mich da bei AVRs nicht so aus.
mfg Sven
-
Salü,Läuft das über Interrupts? Sperrst du alle anderen Interrupts, wenn du ein Ereignis bearbeitest? Evtl. gibt es auch die Möglichkeit Prioritäten für die Interrupts zu vergeben? Kenn mich da bei AVRs nicht so aus.
mfg Sven
Die I²C-Kommunikation läuft insofern nicht mit Interrupts, als dass die INT-Leitung des Busses nicht ausgewertet wird. Die Taster am Bus werden über eine Timer-ISR aber regelmäßig (alle 8 ms) abgefragt. Außerdem läuft noch eine ISR für den 16-Bit-Timer.
Grunsätzlich sollte es so sein, dass ich vor jedem Buszugriff die Interrupts sperre und hinterher wieder freigebe. Ich muss mal überprüfen, ob das konsequent immer so ist oder ob ich das irgendwo in einer Routine vergessen habe.
Gruß, Nils
-
hmm, bisher sind keine Crashes mehr aufgetreten.... komisch das.
Ich habe gerade die ersten "Komfortfunktionen" implementiert, nämlich das kopieren und tauschen von Presets, außerdem Shortcuts zum editieren und speichern von Presets. War erstaunlich leicht, hat keine halbe Stunde gedauert. So schlecht scheint mein Programmierunterbau doch nicht zu sein, musste nur ein paar Variablen umspeichern und ein paar bereits fertige Funktionen aufrufen... ich bin stolz auf mich ;D .
Der Weg zum editieren eines beliebigen Presets ist Menü > Edit Preset > Preset auswählen, loseditieren. Anschließend kehrt der Controller zum vorher geladenen Preset zurück. Das gerade aktive Preset kann jetzt über langes Drücken des Edit-Tasters direkt editiert werden. Außerdem lässt sich im Direct-Mode die gerade gedrückte Tasteranordnung ebenfalls über langes Drücken von Edit abspeichern. So langsam bekommt auch die Bedienung Struktur.
Ich habe überlegt, jedem CC-Taster mehr als eine CC-Zuordnung zu spendieren. Platz im EEPROM für die Daten ist genug, ich denke, das könnte ganz praktisch sein. Mögliches Szenario: Im Direktmodus bei einem Tastendruck im Looper mehrere Loops gleichzeitig aktivieren, oder z.B. beim Umschalten des Amps auf den High Gain Kanal automatisch im Multieffekt das Noise Gate aktivieren - und eben ohne lästige Presetwechsel.
Ich mus nur aufpassen, dass ich nicht die Featuritis bekomme... wobei: Da geht noch was. Mein neues Vorbild: http://www.youtube.com/watch?v=bLKo8cQcxcc .
Gruß, Nils
-
Moin,
BTW vielleicht hast Du es schon geschrieben, aber wie hinterlegst Du den Status der Effekte im Board (Annahme: Gmaj oder Gmaj als Gegenstück). Ich speichere sie ATM nicht und damit kann es sein daß das erstemal schalten nach Presetwechsel 127 statt 0 sendet und erst beim zweiten mal findet der Wechsel statt? Speicherst Du alles in Deinen Presets im fußcontroller oder hast Du eine Möglichkeit gefunden den Status beim Gmaj(2) zu erfragen?
was ich rausgefunden habe: Das G-Major 2 sendet die entsprechenden CCs beim Presetwechsel über MIDI-Out raus. Wennn Der Controller das also kann, bekommt er vom G-Major den aktuellen Status mitgeteilt.
Gruß, Nils
-
Merci Nils,
wenn ich einmal Zeit finde, werde ich mitsniffen was da so raus kommt. Leider ists ATM sehr eng. Aber Danke für den Hinweis.
Gruß,
Sepp
-
Hab kurz mitgesnifft :)
scheinbar werden alle aktivierten, CC Nachrichten beim Wechsel am Out rausgeschrieben (für mich heißt das ATM alles was man per Midi konfigurieren kann :) ). Danke für den Tip... Jetzt weiß ich auch warum es mir nicht aufgefallen ist, er macht es nur wenn eine CC Nummer definiert ist, sonst schreibt er nichts raus. Als ich das letzte mal mitgesnifft hab war noch nichts konfiguriert :( BTW er sendet jeden Midi-steuerbaren/konfigurierten Tastendruck.
Wird Zeit daß ich ein Midi-In nachrüste, bzw meinen noch einmal überarbeite. Leider wirds etwas warten müssen, aber das eröffnet dann noch ganz andere Möglichkeiten.
Cool und danke noch einmal,
Sepp
Addon: Am Out kommen nur die Befehle vom Bedienpanel an aber nicht die per Midi gesendeten. Trotzdem nice, Du solltest so eigentlich ein TC electronic Teil auch zur Konfiguration Deines Controllers nutzen koennen, zumindest für Teile.
Addon2: Mods werden nicht versandt, zB in meinem Fall global in level... Am Gmaj2 funktioniert zumindest in meiner Konfig:
* Stati aller 6 Blöcke
* NoiseGate
* Bank
* Preset
* Mute
* Bypass
* Relay ring/tip
Was nicht funktioniert:
* EQ Status
* Modifier
-
Moin,
im folgenden mal der aktuelle Stand meiner Dokumentation für den Controller. Wie immer übernehme ich keine Garantie dafür, dass die Pläne und Layouts einhundertprozentig mit dem übereinstimmen, was ich gebaut habe.
Gruß, Nils
-
Hallo Nils,
Danke für die Pläne.
Du hast ja noch viele Anschlüsse am Controller frei.
Ist es nicht einfacher das LCD direkt anzuschliessen und kein I2C zu nutzen ?
Gruß
-
Hallo Nils,
Danke für die Pläne.
Du hast ja noch viele Anschlüsse am Controller frei.
Ist es nicht einfacher das LCD direkt anzuschliessen und kein I2C zu nutzen ?
Gruß
Klar wäre das gegangen. Es gab irgend einen Grund, warum ich's über I²C gemacht habe, an den ich micht nicht erinnere - möglicherweise war's auch nur der übliche "weil's geht"-Grund ;D , zusammen mit der Tatsache, dass eh alles über den Bus läuft. Nachdem die Busebene programmiertechnisch abstrahiert war, machte das, glaube ich, ehe keinen Unterschied mehr.
Geschwindigkeit ist kein Problem. Der Bus läuft mit 100 kHz (mehr machen die PFC nicht), aber das verwendete LCD ist eh um mehrere Größenordnungen langsamer, von daher ist's egal (wenn man das LCD zu schnell beschreibt, sieht man nix mehr, weil die Kristalle zu träge sind).
Gruß, Nils
-
Moin,
in Plan und Layout hat sich ein Fehler eingeschlichen. Das Ausgangssignal des 6N139 liegt an Pin 6 an, nicht an 7. Dementsprechend gehören die eingezeichneten Verbindungen um einen Pin nach unten verschoben.
Gruß, Nils
-
Hallo!
Nachdem ich Nils H. angeschrieben hatte, weil ich extrem angetan von seinem Midi Controller Projekt bin und eine kleine Gruppe derzeit ebenfalls an einem ähnlichen projekt arbeitet, meinte Nils, es wäre doch nett, wenn ich darauf hier kurz verlinken würde, vielleicht interessiert es ja einige. Dem will ich jetzt hiermit nachkommen:
Wir bauen derzeit auf Arduino Basis einen Midi Controller. Wobei ich gleich sagen muss: Das Zugpferd, was die technische Programmierung angeht bin nicht ich, sondern der OSon aus dem axefx.de Forum.
Anyhow: Wer vielleicht genauso ein "Greenhorn" in Sachen Elektrotechnik und Software-Programmierung ist, wie ich, aber trotzdem vielleicht Interesse an einer solchen Eigenkonstruktion hätte, der kann ja gerne mal bei "uns" vorbeischauen, denn ich denke, das Projekt ist auch für absolute Einsteiger zumindest Nachbaubar ...
Hier zu den Infos:
Diskussion im axefx.de Forum: http://www.axefx.de/showthread.php/1040-DYI-MIDI-Fu%C3%9Fleiste-selber-bauen-! (http://www.axefx.de/showthread.php/1040-DYI-MIDI-Fu%C3%9Fleiste-selber-bauen-!)
Software auf github.com: https://github.com/oson/midi_board_ONE (https://github.com/oson/midi_board_ONE)
(Nochmals größten Dank an den "Konstrukteur" OSon!!!
Video-Dokumentation auf youtube: http://www.youtube.com/watch?v=dIs-Xt1zd-U&list=PLT2sYJRe7JGzRZjYknhBgOrFEbOZDuBH5 (http://www.youtube.com/watch?v=dIs-Xt1zd-U&list=PLT2sYJRe7JGzRZjYknhBgOrFEbOZDuBH5)
Liebe Grüße
Markus
-
Moin,
es gibt neues zu vermelden. Das Floorpedal verrichtet jetzt ja schon 'ne Weile seinen Dienst im Proberaum (Steuerung eines G-Major 2), über den Weihnachtsurlaub hatte ich jetzt mal Zeit, mich dem Racklooper zu widmen. Die Hardware ist heute (fast - siehe unten) fertig geworden, jetzt muss ich "nur noch" die Firmware schreiben.
Das sollte aber recht schnell gehen, denn ich werde die Software sehr "dumm" halten - Empfang auf MIDI-Kanal 1, 18 CCs für 18 Relais - fertig. Presets oder anderen Firlefanz brauche ich nicht, und ich will bis Sonntag fertig sein ;D .
Zur Hardware: Ich habe meinen alten TB-Relaislooper geschlachtet und neue Platinen eingebaut. Daher bleibt es bei der alten Ausstattung - 3 Chains zu je 4 Loops, dazu 6 potentialfreie Schaltkontakte. Zu jedem Relais gibt es eine Status-LED, die sind hartverdrahtet parallel zu den Relaisspulen, also nicht programmierbar. Vorne gibt es ein Pedal In mit Phantompower, hinten MIDI-Through und -Out (im Moment nicht bestückt, weil auch nix gesendet wird). Die I/O-Platine ist so vorbereichtet, dass bis zu 32 Schaltsignale verarbeitet werden können, genutzt werden aber wie gesagt jetzt erst mal nur 18.
Was noch fehlt: Einschaltverzögerung für die Relais, Grund: Habe ich total vergessen :devil: . Ich hatte das früher schon mal angesprochen, die Portexpander schalten beim Hochfahren einmal die Masse durch und alle Relais ziehen an. Ich habe auf dem AVR erst mal nur die Initialisierung des I²C-Busses programmiert; das Initialisieren des Controllers und des I²C-Busses dauert dann doch 2(!) Sekunden, d.h. für 2 Sekunden ziehen alle Relais an. Das ist natürlich doof.
Frage: Warum ist das so, dass das so lange dauert? Das Programm macht wirklich nichts außer den Bus zu initialisieren und in alle Expander eine 0 zu schreiben. Braucht der AVR wirklich so lange? (unabhängig davon braucht's natürlich trotzdem eine Einschaltverzögerung).
Anbei mal zwei Bilder, wie das Ding gerade neben mir steht, wie man sieht, hat das Chassis schon arg gelitten. Die LED-Leitungen muss ich noch strapsen und verlegen.
Gruß, Nils
-
Hi,
wann wird denn der I2C initialisiert und kannst Du nicht auf die Portexpander verzichten ? 18 Ports gehen auf alle Fälle über den Atmega, oder müssen es am Ende wirklich 32 Ports sein ?
Ich habe mal eben bei mir getestet mit einem Programm, dass per I2C auf einen 24C... zugreift und eines ohne I2C Bus und in beiden Fällen ist der Atmega gleich ansprechbar ohne irgendwelchen Müll auf dem I2C zu produzieren. Zumindest konnte ich nichts feststellen.
Programmfehler ? Taktrate erhöhen oder Bus-Zugriff anders umsetzen ?
Gruß, Dirk
-
Moin Dirk,
18 Digitale Pins wird mit einem ATMEGA im DIL-Gehäuse aber eng... theoretisch hat er 23. Praktisch bleiben weniger über: zwei weg für serielle Schnittstelle, zwei für externen Oszillator, einen für Reset, dann ist man bei 18. Und dann ist keiner mehr frei für Status-LED oder so was. Finde ich doof.
Darüber hinaus war die Zielvorgabe, als ich die Platinen gebaut habe, mal: 16 Loops und 8 Schalter, da reicht ein ATMEGA eh nicht mehr aus. Ich hab das dann etwas runterskaliert, weil ich mein vorhandenes Material weiter nutzen wollte.
Jedenfalls: Wenn, dann kann ich auch eh gleich vier Expander verbauen, da kommt's dann eh nicht drauf an ;D . Und: Weil's geht ;) .
Das Programm führt im Moment nur die i2c_init()-Routine aus - Zwei Register beschreiben und alle PFC low setzen. Ich vermute, dass die PCF8574 so lange brauchen bis sie das erste Mal auf ein Telegramm vom AVR reagieren - lese gerade noch mal das Datenblatt. Der Bus läuft mit dem Maximum (vorgegeben durch die PCF) von 100 kHz.
Die Initialisierung kommt im Prinzip ausm Atmel-Datenblatt, sollte also korrekt sein. Ich hab wie gesagt die PCF8574 im Verdacht. Das alles ändert aber eh nix dran, dass erst mal alle Relais kurz anziehen, also Verzögerung muss eh sein.
Gruß, Nils
-
Hi,
zum PCF8574 kann ich nichts weiter sagen. Ich habe auch leider keinen hier um mal selbst auszuprobieren. Hatte zwar auch mal an eine Porterweiterung gedacht, aber verworfen und zwischenzeitlich angefangen mir ein "Mainboard" für einen Mega128 zu entwerfen.
Keinen Atmega16 in der Schublade liegen ;-)
Du programmierst in C ?
Stelle doch mal das Programm hier ein.
Gruß, Dirk
-
und ganz vergessen: versuch mal Hans direkt zu kontaktieren. Der macht einiges mit den µC und kann vielleicht etwas dazu sagen - falls er nicht hier mit liest.
Gruß, Dirk
PS: da fällt mir noch ein konntest Du das Dumpen der Bank/Preset-Daten vom und zum µC realisieren ?
-
Du programmierst in C ?
Stelle doch mal das Programm hier ein.
Kein Problem. Ist überschaubar ;D . Ich denke, an der markierten Stelle ("HIER HÄNGT'S") entstehen die 2 sekunden, hab's aber noch nicht genauer ausgeforscht. Mache ich aber noch. Mein Verdacht ist wie gesagt, dass der µC auf die erste Antwort des ersten Expanders wartet. Danach läuft alles wie Atze, will sagen: Für menschliche Wahrnehmung gehen dann alle Relais und LEDs gleichzeigig aus ;D .
main.c:
#include "i2c.h" // Routinen für I²C-Bus einbinden
int main( void )
{
i2c_init(); // I2C-Bus initialisieren
return 0;
}
i2c.c:
void i2c_init (void)
{
/* Bus Geschwindigkeit einstellen
* Formel: F_CPU/(16+2*TWBR*Prescaler)
* Prescaler Default: 1
* TWBR = 0x48 = 73 ergibt 100 kHz bei 16 MHz CPU-Frequenz
*/
TWSR=(0<<TWPS1)|(0<<TWPS0);
TWBR = ((F_CPU/SCL_CLOCK)-16)/2;
// Port Expander initialisieren
// ***** HIER HÄNGT'S? ***** //
PCF8574_set_outputs(0,0x00);
PCF8574_set_outputs(1,0x00);
PCF8574_set_outputs(2,0x00);
}
/*
* START senden, Adresse senden, RW senden
* Rückgabewert: 1 = gescheitert, 0 = ok
*/
uint8_t i2c_start (uint8_t typ, uint8_t adresse, uint8_t rw)
{
uint8_t twst;
TWCR = (1<<TWINT) | (1<<TWSTA) | (1<<TWEN); // START Condition senden
while (!(TWCR & (1<<TWINT)));
twst = TW_STATUS & 0xF8; // Statusregister überprüfen
if ( (twst != TW_START) && (twst != TW_REP_START)) return 1; // Slave reagiert nicht
uint8_t adressByte = 0;
adressByte = adresse << 1;
adressByte |= rw; // R/W-Bit setzen
/* Basisadresse ergänzen
*
* PCF8574A: 0 1 1 1 A2 A1 A0 RW = 0x70
* EEPROM: 1 0 1 0 A2 A1 A0 RW = 0xA0
*
*/
switch (typ)
{
case IOEXPANDER:
{
adressByte |= 0x70;
break;
}
case EEPROM:
{
adressByte |= 0xA0;
break;
}
}
// Slave-Adresse senden
TWDR =adressByte; // Slave-Adresse senden
TWCR = (1<<TWINT) | (1<<TWEN);
// warten bis Übertragung beendet
while(!(TWCR & (1<<TWINT)));
// Statusregister überprüfen
twst = TW_STATUS & 0xF8;
if ( (twst != TW_MT_SLA_ACK) && (twst != TW_MR_SLA_ACK) ) return 1;
return 0;
}
/*
* START senden, Adresse senden, RW senden
* Wenn Slave beschäftigt, warten bis frei
*/
void i2c_start_wait( uint8_t typ, uint8_t adresse, uint8_t rw)
{
uint8_t twst;
while ( 1 )
{
TWCR = (1<<TWINT) | (1<<TWSTA) | (1<<TWEN); // START Condition senden
while(!(TWCR & (1<<TWINT))); // warten bis Übertragung beendet
twst = TW_STATUS & 0xF8; // Statusregister prüfen
if ( (twst != TW_START) && (twst != TW_REP_START)) continue;
uint8_t adressByte = 0;
adressByte = adresse << 1;
adressByte |= rw; // R/W-Bit setzen
/* Basisadresse ergänzen
*
* PCF8574A: 0 1 1 1 A2 A1 A0 RW = 0x70
* EEPROM: 1 0 1 0 A2 A1 A0 RW = 0xA0
*
*/
switch (typ)
{
case IOEXPANDER:
{
adressByte |= 0x70;
break;
}
case EEPROM:
{
adressByte |= 0xA0;
break;
}
}
// Slave-Adresse senden
TWDR =adressByte;
TWCR = (1<<TWINT) | (1<<TWEN);
// warten bis Übertragung beendet
while(!(TWCR & (1<<TWINT)));
// Statusregister überprüfen
twst = TW_STATUS & 0xF8;
if ( (twst == TW_MT_SLA_NACK )||(twst ==TW_MR_DATA_NACK) ) // Slave beschäftigt, STOP senden
{
TWCR = (1<<TWINT) | (1<<TWEN) | (1<<TWSTO);
while(TWCR & (1<<TWSTO)); // warten bis Bus frei
continue;
}
break;
}
}
/*
* STOP senden
*/
void i2c_send_stop (void)
{
/*
* STOP Condition senden:
*
* TWINT durch setzen von 1 löschen
* TWSTA = TWI STOP Condition Bit
* TWEN = TWI Enable Bit
*
*/
TWCR = (1<<TWINT) | (1<<TWSTO) | (1<<TWEN);
while(!(TWCR & (1<<TWSTO))); // warten bis STOP gesendet
}
/*
* Datenbyte senden
* Rückgabewert: 1 = gescheitert, 0 = Byte übertragen
*/
uint8_t i2c_send_byte (uint8_t byte)
{
uint8_t twst;
TWDR = byte; // Datenbyte in TWI Datenregister schreiben
TWCR = (1<<TWINT) | (1<<TWEN); // Inhalt des Datenregisters senden
while (!(TWCR & (1<<TWINT))); // warten bis gesendet
twst = TW_STATUS & 0xF8; // Statusregister prüfen
if( twst != TW_MT_DATA_ACK) return 1;
return 0;
}
void PCF8574_set_outputs (uint8_t adresse, uint8_t byte)
{
i2c_start(IOEXPANDER,adresse,0);
i2c_send_byte (byte);
i2c_send_stop ();
}
-
Hossa,
warte mal 200-300ms, bevor Du den I2C-Bus und den PCF8574 initialisiert.
Der PCF8574 ist manchmal etwas ... störrisch.
Grüßle
Bernhard
-
und ganz vergessen: versuch mal Hans direkt zu kontaktieren. Der macht einiges mit den µC und kann vielleicht etwas dazu sagen - falls er nicht hier mit liest.
Gruß, Dirk
PS: da fällt mir noch ein konntest Du das Dumpen der Bank/Preset-Daten vom und zum µC realisieren ?
Wenn mir das richtig Sorge bereitet, mache ich das. Das prinzipielle Problem bleibt, die Expander sind nach demStartup High und somit schalten die ULN2803 durch, was die Relais anziehen lässt. Auch für 'ne halbe, viertel Sekunde oder weniger ist das doof, deswegen löte ich gerade eine kleine Einschaltverzügerung für die Relaisspannung zusammen.
Mit dem Thema EEPROM-Dumping hab ich mich beim Controller erst mal noch nicht weiter beschäftigt. Der grobe Fahrplan scheint zu sein, das mit geeigneter Software (MIDIOX oder selbst geschrieben) per Sysex zu machen. Umgesetzt habe ich da aber noch nix.
-
Hossa,
warte mal 200-300ms, bevor Du den I2C-Bus und den PCF8574 initialisiert.
Der PCF8574 ist manchmal etwas ... störrisch.
Grüßle
Bernhard
Danke für den Hinweis. Das Grundproblem bleibt aber, die sind nach dem Einschalten erst mal High. Ob das dann 300ms oder 2s dauert ist latte, ich darf die Relaisspannung erst nach dem initialisieren freischalten.
-
Versorgungsspannung der Relais über ein Relais frei geben welches vom µC direkt geschaltet wird und erst nachdem der Expander fertig ist ?
Du könntest auch mal die Demo von Bascom laden und damit das Programm erstellen um zu sehen ob es an Deinem Programm oder wirklich der Hardware liegt.
In Bascom müsste das Programm so aussehen (die Taktrate $crystal muss aber noch auf Dein Qarz eingestellt werden und das Beispiel ist für einen Atmega816)
$regfile "m168def.dat"
$PROG &HFF , &HCF , &HDF , &HF9
$crystal = 7372800
Config Sda = Portd.5
Config Scl = Portd.4
Const Pcf8574write = &H70
Const Pcf8574read = &H71
Do
I2cstart
I2cwbyte Pcf8574write
I2cwbyte 0
I2cstop
Waitms 500
Reset Portd.6
I2cstart
I2cwbyte Pcf8574write
I2cwbyte 255
I2cstop
Waitms 500
Loop
End
Gruß, Dirk
-
Versorgungsspannung der Relais über ein Relais frei geben welches vom µC direkt geschaltet wird und erst nachdem der Expander fertig ist ?
Gruß, Dirk
Genau so mache ich's jetzt, ich gebe nach der Businit-Routine über einen freien Pin (gut, dass noch einer da ist ;D ) die Spannung für die Relais frei. Zwischen Pin und Relais ist noch ein kleiner Schalttransistor, damit der µC die Last nicht direkt schalten muss. Sind zwar nur 12,5 mA, aber 2,2 mA finde ich entspannter.
Gruß und gute Nacht
Nils
-
Das Hirn funktioniert besser, wenn man 'ne Nacht geschlafen hat.
Die zwei Sekunden entstehen natürlich durch den Bootloader, der auf ein Programm wartet und erst dann die Software startet.
Gruß, Nils
-
Die zwei Sekunden entstehen natürlich durch den Bootloader, der auf ein Programm wartet und erst dann die Software startet.
Was für ein Bootloader ? Verwendest Du einen Arduino Atmel ?
Gruß, Dirk
-
Moin Dirk,
ich hatte das weiter oben schon mal geschrieben, ich habe auf dem µC einen Arduino Bootloader installiert, um den Controller über den UART / per USB programmieren zu können (außerdem habe ich beim Rackgerät eh den ISP-Wannenstecker weggelassen). Ich hab allerdings keinen Arduino-Atmel gekauft, sondern den Bootloader mit meinem Programmiergerät selbst auf den nackten Controller gebrannt. Sonst sind die ja viel zu teuer ;D .Ich hab den Bootloader außerdem selbst kompiliert, weil ich irgendwas anpassen musste - kann mich aber nicht mehr erinnern, was.
Wenn ich das Teil endgültig zusammen- und ins Rack baue, kommt der Bootloader vorher wieder runter. Ich hab das auch mal ausprobiert, ohne Bootloader kommt das Relais für die Einschaltverzögerung quasi sofort nach dem Einschalten. Ob die Einschaltverzögerung jetzt sinnlos war oder nicht, lasse ich mal dahin gestellt. Schaden tut's nicht, wenn man die Relaisspannung per µC überwachen kann.
Ich nutze die Gelgegenheit dann gleich mal für ein Resümee, denn gestern ist die Software für die Rackeinheit quasi fertig geworden. Zusammenfassend hat meine Anlage jetzt folgende Features:
Floorboard
Features:
- 16 numerische Taster zur Programm- (Presetmodus) bzw. Effektwahl (Stompboxmodus), dazu Up/Down/Edit/Direct, 20 LED und ein großes 2x16 Zeichen LCD
- Preset- und Stompboxmodus
- 400 Presets in 25 Bänken zu 16 Presets
- Für jeden der 16 Midikanäle ein Gerät namentlich anlegbar
- über die 16 Taster Zugriff auf 32 Instant Access Taster, jeder Taster also doppelt belegt (Shiftfunktion)
- Presetwechsel im Stompboxmodus über Up/Down möglich
- Pro Preset können bis zu 16 PC- und 32 CC-Befehle gesendet werden
- Vier Modi für die Fußtaster: Taster, Schalter, Schalter mit senden des gespeicherten Status bei Presetwechsel, Tap Tempo[1]
Fehlende Features / To Do:- Mischbetrieb aus Preset- und Stompboxmodus, also z.B. Vier Preset- und 12 IA-Taster: Weiß nicht ob ich das noch realisiere, mal abwarten, ob ich's brauche. Mein Bedarf, Presets zu schalten, ist überschaubar, der Stompboxmodus ist zu 95% der, den ich brauche.
- Tastergruppen: Taster, die sich gegenseitig zurücksetzen, z.B. für Kanalwahl am Amp - Kanal 1 / 2 / 3, und immer nur einer darf aktiv sein. Mache ich evtl. noch
- Die Software hat im Bereich des Editierens noch ein paar Bugs / Inkonsistenzen in der Menü- und Benutzerführung. Funktionell ist alles top, von daher bleibt das wahrschinlich liegen ;D .
- Zugriff auf die Shiftfunktion der Taster: Bisher schalte per dezidiertem Taster zwischen 1-16 und 17-32 um. Schön wäre, durch langes Drücken die Sekundärfunktion des Tasters auslösen zu können. Funktioniert auch, beißt sich aber, wenn ein Fußtaster als Tastfunktion eingerichtet ist. Habe ich noch keine Lösung für, ist mir aber das wichtigste fehlende Feature und wird daher bestimmt irgendwie noch kommen.
- Eventuell baue ich beim Presetabruf noch mal eine Verzögerung von ein paar Milisekunden zwischen dem Senden von PC und CC ein. Bei meinem G-Major2 habe ich festgestellt, dass die CCs für die Effektblöcke ohne Probleme ausgewertet werden, die CCs für die Modifikatoren (ich nutze z.B. MOD2 zur Geschwindigkeitsumschaltung des Vibe) scheinen aber verloren zu gegen.
Rackeinheit
Features:
- 12 Loops organisiert in drei Ketten zu je vier Loops
- 6 potentialfreie Schaltkontakte
- Anzeige des Loop-/Schalterstatus per LED [2]
- Hardwareseitig vorbereitet für bis zu 32 Relais, 18 bisher genutzt
- Empfang auf Midikanal 1
- Schalten der Relais über CC#
Fehlende Features / To Do:- Keine Presets, keine Programmierung
- Midikanal nicht[3] konfigurierbar
- CC# nicht[3] konfigurierbar
[1] Die Tap Tempo Funktion ist noch unausgereift. Ein Tap Taster arbeitet wie ein Schalter, aber die LED blinkt dann im getappten Tempo. Derzeit gibt es nur eine Timerroutine dafür, also auch nur einen LED-Blinkrythmus. Außerdem verschluckt sich das ganze manchmal. Ist also noch Überarbeitungsbedarf da.
[2] Die LED sind nicht programmierbar, sondern den Relais einfach parallel geschaltet
[3] Nicht ohne Eingriff in die Software. Für den Midikanal baue ich evtl. noch ein Mäuseklavier ein, Einstellbarkeit der CC# bringt für mich keinen Mehrwert.
An der Floorboardsoftware mache ich auf jeden Fall noch was, die Rackeinheit ist für meinen Bedarf, glaube ich, fertig, die kommt diese oder nächste Woche wieder ins Rack.
Insgesamt bin ich sehr zufrieden mit dem vorläufigen Ausgang des Projekts, weil ich auch sehr viel dabei gelernt habe - für mich immer fast wichtiger als die Fertigstellung der eigentlichen Gerätschaft. Mein Ziel, meine Anlage zu midifizieren und so die Bedienung meiner Pedale unter einen Hut zu bringen mit 19"-Gerätschaften habe ich, wenn auch erst nach sehr langer Zeit, erreicht. Beide Geräte sind sehr schnell. Latenzen konnte ich bisher nicht feststellen, zumindest sind sie nicht spürbar.
Dem aktuellen Stand der Technik hinken meine Gerätschaften natürlich schon wieder hoffnungslos hinterher - siehe z.B. die Entwicklung der RJM- oder der Axefx-Controller. Andererseits bieten meine Teile schon jetzt deutlich komplexere Möglichkeiten als ich brauche, insofern: Who cares.
Die nächsten Tage gehe ich noch mal über alle Platinen und Pläne und schaue, wie komplett und fehlerfrei die sind, und dann stelle ich die noch mal ein. Wie immer gilt bei mir aber, dass das Zeug eher als Infomaterial nutzbar denn nachbaubar ist, weil beim Aufbau auch wieder einiges improvisiert wurde.
Wer die Software haben will, kann sich bei mir melden. Den (letzten?) Softwarestand werde ich dann wahrscheinlich auch hier einstellen. Auch hier gilt: Nur bedingt zum Nachbau geeignet. Und, ich hab's schon mal gesagt, ich bin programmiermäßig eher ein Rookie, weshalb der Code weder schön noch resourcenschonend oder besonders performant ist. Besserer Code käme möglicherweise mit einem kleineren Controller als dem 328P aus, aber da ich nicht in Serie gehe noch mal: Who cares.
In diesem Sinne,
Nils
-
ich hatte das weiter oben schon mal geschrieben,
das habe ich doch jetzt glatt übersehen... ;D
Aber mal eine bescheidene Frage: braucht man wirklich solch ein grosses Board ? Bei meinem Controller der fast fertig ist habe ich mich auf 8 Patches pro Preset festgelegt und 5 Presets pro Bank. Damit kann ich dann mit einem Tastendruck 8 verschiedene MIDI-Befehle (PC oder CC) auf 8 verschiedenen Kanälen raus schicken, was nach meiner Ansicht gut 95% der Anforderungen erschlägt.
Außerdem ist der Controller so kompakt wie möglich ausgelegt und in der Grundfunktion bereits mit 3 Tasten (7 Tasten maximal) zu bedienen damit zu wenig Platz wie möglich auf dem Board verwendet werden muss.
Na ja, es sind halt zwei total unterschiedliche Konzepte, aber hast Du wirklich so viele Midi-Geräte ?
Gruß, Dirk
-
Moin Dirk,
das habe ich doch jetzt glatt übersehen... ;D
Aber mal eine bescheidene Frage: braucht man wirklich solch ein grosses Board ? Bei meinem Controller der fast fertig ist habe ich mich auf 8 Patches pro Preset festgelegt und 5 Presets pro Bank. Damit kann ich dann mit einem Tastendruck 8 verschiedene MIDI-Befehle (PC oder CC) auf 8 verschiedenen Kanälen raus schicken, was nach meiner Ansicht gut 95% der Anforderungen erschlägt.
Außerdem ist der Controller so kompakt wie möglich ausgelegt und in der Grundfunktion bereits mit 3 Tasten (7 Tasten maximal) zu bedienen damit zu wenig Platz wie möglich auf dem Board verwendet werden muss.
Na ja, es sind halt zwei total unterschiedliche Konzepte, aber hast Du wirklich so viele Midi-Geräte ?
Gruß, Dirk
Naja wer braucht das schon.... ;) das ist auch viel "weil's geht" dabei.
Das Midiboard an sich muss schon so "groß" sein, weil es eben mein Ersatz fürs Pedalboard ist. Ich hab's oben schon angedeutet, bin kein Presetspieler, sondern klassischer Stompboxer. Im Rack habe ich 8 Pedale, dazu ein G-Sharp und seit ein paar Monaten ein G-Major 2. Das G-Sharp nutze ich im Prinzip als Einzeleffekt, am G-Major so drei oder vier Presets, von denen eines mein "Standardpreset" ist, bei dem ich per CC die Effektblöcke ein- und ausschalte. Dazu kommen noch die sechs Schaltausgänge, die ich alle nutze - drei für Kanalwahl und Boost am Amp, einmal Speed am Rotosphere und zwei für einen selbstgebauten Phase45, bei dem ich zwischen zwei Geschwindigkeiten und Vibrato umschalten kann. So erklärt sich mein Bedarf an physischen Tastern.
Natürlich habe ich keine 16 Midi-Geräte. Ob ich in der Boardsoftware aber nun 2, 8 oder 16 unterbringe macht keinen Unterschied (naja ein paar Bytes im EEPROM), und die Geräte 3-16 sind ja auch deaktiviert. Von den 32 (virtuellen) Tastern nutze ich aber tatsächlich die erste Ebene vollständig und die zweite zur Hälfte.
Zum Rackgerät: 10 der 12 Loops sind in Benutzung, und alle der 6 Schaltausgänge, insofern war es schon sinnvoll, bei der Auslegung der Mikrocontrollersteuerung von vorneherein Raum für Erweiterung zu lassen. Außerdem kommt's auch hier nicht drauf an, ob ich drei Portexpander mit ULN2803 verbaue, oder gleich vier davon.
Wie gesagt, mein Setup läuft zu 95% im Stompboxmodus, weswegen ich den großen Controller tatsächlich brauche. Der Rest ist "nur" Software und frißt kein Brot, und die Stellen, an denen ich ohne Verluste hätte herunterskalieren können haben keinen großen Programmieraufwand gekostet. Und einiges ist halt auch "Proof of Concept", weil's geht und meine übliche Gigantomanie :devil: .
Gruß, Nils
-
damit zu wenig Platz wie möglich auf dem Board verwendet werden muss.
Um das noch mal heraus zu stellen: Der Controller IST ja mein Board.... ich hab sonst nix vor den Füßen außer Wah und Tuner.
-
Hi,
Danke dir für die Ausführung.
Wie schon oben angedeutet geht es in der Tat um zwei verschiedene Konzepte. Und da ist man in der Tat mit den µCs sehr flexibel.
Gruß, Dirk
-
Und da ist man in der Tat mit den µCs sehr flexibel.
Ich bin da im Moment auch sehr begeistert von. Die Midigeschichte war jetzt das erste Mal, dass ich was mit Miktrocontrollern gemacht habe, aber bestimmt nicht das letzte ;D . Wenn man's erst mal begriffen hat, wie's geht, macht's auch echt Laune.
-
Moin Dirk,
PS: da fällt mir noch ein konntest Du das Dumpen der Bank/Preset-Daten vom und zum µC realisieren ?
um das noch mal aufzugreifen: Im Moment läuft's gerade recht gut (gestern Abend konnte ich erstaunlich problemlos die Routinen für das Abfragen von zwei Expressionpedalen implementieren), habe ich mir vorgenommen, die Bulk-Dump-Baustelle als nächste anzugreifen. Sofern man keine eigene Software schreiben will (ich jedenfalls nicht), funktioniert das ja wohl über Sysex, unter Windows geht das wohl ganz gut mit MIDI-OX, für OS-X und Linux gibt's da bestimmt auch Entsprechungen. Die Grundlagen zum Protokoll liefert ja der entsprechende Abschnitt (http://de.wikipedia.org/wiki/MIDI#Systemexklusive_Meldungen) im Wikipedia-Artikel, ich werde die Tage da mal dran basteln.
Gruß, Nils
-
Moin,
weil ich gerade alles im Wohnzimmer stehen habe stelle ich mal zwei Bilder ein. Dem Controller habe ich heute mal eine etwas hübschere Beschriftung verpasst. Ansonsten hat das System morgen seinen ersten Liveeinsatz auf der Geburtstagsparty unseres Keyboarders. Ich hoffe, es stürzt nicht zwischendurch ab :devil: .
Gruß, Nils
-
:topjob: nice, vorallem scheinbar den hinteren Deckel als Pedalboard zu benutzen :) wollte ich auch immer aber bei meinem geht es sich leider nicht aus (6HE und hinten ist die Steckerleiste im Weg :( )
Gruß,
Sepp
-
den hinteren Deckel als Pedalboard zu benutzen
nope, ist ein separates Pedalcase. Der Karm würde in den Deckel auch gar nicht reinpassen, und dann ginge der Deckel auch gar nicht zu ;) .
-
Ah ich dachte schon, dann hast du das gleiche Problem...
-
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 ;D . 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 8) .
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 ;D , 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 ;D . 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ß 8) 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 ;D . 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 ;D . 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...
-
Genau. In und Thru sind durch den Opto getrennt. Im Prinzip ist das ja ein Midi-Out, der am RXD statt TXD hängt...
Eine Idee habe ich noch: Ich hab ja am Midi-Thru die Schmitt-Trigger weggelassen; kann irgendwie passieren, dass der AVR aus irgend einem Grund nach einer gewissen Laufzeit das Signal am RXD "verschmutzt"? Ein Reset hilft ja offensichtlich. Die Schmitt Trigger sollen ja wohl das Signal konditionieren und wieder steilflankig machen...
-
P.S.: Oh, ich sehe gerade, der Midi-Out ist doch bestückt. Ich könnte also mal einen Software-Midi-Thru implementieren und sehen, was passiert. Zumindest hängen die anderen Slaves dann nicht mehr (belastend) parallel zum Opto am RXD des AVR...
-
Keiner 'ne Idee, woran's liegen kann? Ich hab letzte Woche schnell den Midi-Thru-Code in die Firmware programmiert, bisher läuft damit alles einwandfrei...
-
Hi,
Ich an 'verschmutztes' Signal (Rauschen etc.) glaub ich weniger, eher dass die 1-Bits nicht mehr erkannt werden. Ist bei MIDI auch die +5V wie beim TTL?
Jedenfalls müsste es hier einen Schwellenwert geben bei dem die "Flanken" der Bits erkannt werden, wenn die dieser nicht erreicht wird wird auch kein Signal erkannt.
daher:
könnte sein dass hier ein Potenial 'wegdriftet'?
- Masse(Pin2) am "Through" die ja als Referenz für Rx(Pin4) und Tx(Pin5) gilt.
- bzw sind die 5V an R10 stabil oder sackt diese irgendwann mal ein?
vl kann man mit einem Singalgenerator ein passendes Rechtecksignal am MIDI-In anlegen, und dann am Midi-thru beobachten was passiert. (mit einem 2Kanal Oszi beide Signale vergleichen)
Womöglich wäre nach 4h ein mitrecorden im Normalbetrieb von Ein & Thru gang zum Vergleich der Pegel sinnvoller.
Gruß
Dominik
Edit: hätte hier nochmal was gefunden: http://www.midi.org/techspecs/electrispec.php
hier ist wenn ich das richtig sehen nochmal ein Pegel-Verstäker vord em MidiThru, ob das solche Probleme vermeiden soll - oder für längere Kabel am thru nötig ist.
Edit2: Midi arebeitet mit 5mA bzw. 0mA...
http://www.personal.kent.edu/~sbirch/Music_Production/MP-II/MIDI/midi_physical_layer.htm
-
Moin,
Ist bei MIDI auch die +5V wie beim TTL?
jepp.
könnte sein dass hier ein Potenial 'wegdriftet'?
möglich. Müsste ich über längeren Zeitraum mal messen.
- Masse(Pin2) am "Through" die ja als Referenz für Rx(Pin4) und Tx(Pin5) gilt.
Angeschlossen.
- bzw sind die 5V an R10 stabil oder sackt diese irgendwann mal ein?
Kann ich natürlich mit Sicherheit nicht sagen. Der Looper wird von einem geregelten und stabilisierten Steckernetzteil versorgt, ich glaube 12V 2A. Auf jeden Fall ist es fett genug um alle 20 Relais, das Floorboard und dessen LED zu versorgen. Und der Fall, dass alle Relais geschaltet sind ist ja eher die Ausnahme...
vl kann man mit einem Singalgenerator ein passendes Rechtecksignal am MIDI-In anlegen, und dann am Midi-thru beobachten was passiert. (mit einem 2Kanal Oszi beide Signale vergleichen)
gute Idee.
Womöglich wäre nach 4h ein mitrecorden im Normalbetrieb von Ein & Thru gang zum Vergleich der Pegel sinnvoller.
Scheiss Fehlersucherei. Dafür muss ich halt das Rack immer auseinander reißen. Mit dem Software-Midi-Thru über den Midi Out am TXD des AVR lief der Kram jedenfalls schon 'ne ganze Weile stabil. Das muss irgendwie am "Poor Man's Design" des Midi-Thru liegen.
Danke für Deinen Input!
Gruß, Nils
-
Ist bei MIDI auch die +5V wie beim TTL?
jepp.
Edit2: Midi arebeitet mit 5mA bzw. 0mA...
http://www.personal.kent.edu/~sbirch/Music_Production/MP-II/MIDI/midi_physical_layer.htm
die Spannung +/- 5..15V sind RS232 bei MIDI sinds anscheinend doch Ströme 5mA sofern die Specs im obigen link stimmen...
-
Recht hast Du natürlich... MIDI arbeitet mit einer Stromschleife. Hab ich gestern auch nicht richtig nachgedacht.
Theorie: Vielleicht stellt sich irgendwann ein Zustand ein, wo der µC des Floorboards (da ist auch ein AVR drin) durch die Doppelbelastung (Midi-In am Looper und davon parallel abgegriffener Thru) nicht mehr genug Strom liefert, so dass der den Opto im Receiver des GM2 den entsprechenden Spannungspegel für den RXD des Prozessors erzeugen kann.
Mal schauen, ob ich irgendwas über das HW-Design des GM2 finde. Der Opto in meinem Looper (6N139) scheint jedenfalls weiterhin den Strom in einen ausreichenden Spannungshub umzusetzen, dass der AVR das als high erkennt...
-
Hi,
wie genau hast du das MIDI In Signal zum Thru gemacht? Wenn du die Schmittrigger weggelassen hast, muss das Midisignal ja wie du sagst den Opto vom Looper und den vom GM2 bedienen. Die Schmittrigger nehmen das Signal hochohmig ab. Ich denke auch das da das Problem liegt.
Gruß
Chris
-
Hi,
wie genau hast du das MIDI In Signal zum Thru gemacht? Wenn du die Schmittrigger weggelassen hast, muss das Midisignal ja wie du sagst den Opto vom Looper und den vom GM2 bedienen. Die Schmittrigger nehmen das Signal hochohmig ab. Ich denke auch das da das Problem liegt.
Gruß
Chris
Jepp, volle Zustimmung. Wie oben gesagt: Poor Man's Design ;D . Rächt sich immer... es wäre so geil, wenn man davon Ahnung hätte und vorher nachdenkt :devil: . Insofern erstaunlich, dass es überhaupt über Stunden funktioniert... ca. ein halbes Jahr lang hab ich gar nix gemerkt und hatte keine Probleme...
-
... es wäre so geil, wenn man davon Ahnung hätte und vorher nachdenkt :devil:
ach dann wärs doch langweilig ;D
-
Moin
da ich gerade Urlaub habe, habe ich an dieser Baustelle mal wieder rumgeschraubt. Anlass war, dass mir in den letzten Wochen der Controller mehrfach ausgestiegen ist - spontaner Reset. Gefunden habe ich, dass der Spannungsregler sich losgerappelt hatte und ein Bein angebrochen war - ich hoffe, das war's.
Jedenfalls, ich habe dann noch ein paar Bugs gefixt und eine gaaaanz wichtige Sache nachgerüstet: Sysex-Dump und Reload!
Hier hatte/habe ich aber ein paar Probleme. Ich konnte relativ leicht mit MIDI-OX das komplette 64k-EEPROM auslesen. Das zurück schreiben bereitet mir aber etwas Probleme.
Erst dachte ich, mein Algorithmus wäre Schrott, weil nicht das im Controller ankam, was MIDI-OX rausschickte. Ich hab dann aber mal mit der Sendepuffergröße rumgespielt, jetzt geht's - dauert aber ewig ??? .
Das zurück schreiben läuft nur dann zuverlässig, wenn ich den Sendepuffer auf 1 Byte Größe (!) stelle. Bei der Pause zwischen den Puffern kann ich auf 15 ms runtergehen, trotzdem dauert das zurück schreiben der Daten ewig.
Okay, das I2C-EEPROM ist nicht das schnellste, und es kostet etwas Zeit, dass ich noch ein paar Debug-Ausgaben auf dem LCD habe. Die Schreibgeschwindigkeit liegt aber nur bei ca. 80 Byte/s - klar, dass da massig Daten verloren gehen, wenn MIDI-OX die zu schnell rausschickt. Daran ändert sich auch nix, wenn ich die LCD-Ausgaben abklemme.
Meine Frage: Jemand 'ne Idee, ob ich irgendwas radikal falsch machen könnte, oder ist das halt so, dass das I2C-EEPROM vom AVR nur relativ langsam beschrieben werden kann? der I2C läuft mit 100 kHz (mehr machen die Expander nicht), ich nutze die UART-Lib von Peter Fleury mit einem Ringpuffer von 512 byte - trotzdem gehen mir massig Daten verloren, sobald ich nur etwas schneller werde :-\ .
Am Ende egal, weil's ja funktioniert - ich habe mein EEPROM jetzt schon zweimal erfolgreich kopiert, Konfiguration und Presets sichern ist also endlich kein Problem mehr. Trotzdem doof...
Wenn ich mit dieser Runde fertig bin, stelle ich - wie versprochen - endlich mal meinen Quelltext ein.
Gruß, Nils