Announcement: there is an English version of this forum on 
Moin Zusammen, ich baue derzeit eine Orgel. Es soll eine moderne Nachbildung einer Hammond B3 werden. Eine gut erhalten B3 geht derzeit für 5-10kEuro über den Tisch, abhängig vom Erhaltungszustand und dem mitgelieferten Leslie Cabinet. Das passt nicht so ganz ins Budget, also selbst was bauen. Eine gute Basis ist imho der Hammond XM1 Midi Expander. Der liefert für 3 Manuale (Upper, Lower und Pedal) ziemlich amtliche Sounds. Angesteuert wir das Teil über 3 Midi Kanäle, je Manual 1 Kanal. So ein Teil hab ich kürzlich günstig bekommen weil das Display defekt war. Das Display ist schon getauscht, die Kiste funzt. Dazu gibt es von Hammond einen Controller der einen Satz Zugriegel (Drawbars) hat und mit dem man mit ein wenig tastendrücken jeweils den Sound der 3 Manuale einstellen kann. Das Teil habe ich nicht und ich hab auch nicht vor es anzuschaffen weil es mir zu umständlich zu bedienen ist. Kleiner Exkurs in Sachen Klangsynthese bei Drawbar-Orgeln: In alten Hammond Orgeln sitzt ein riesen Kasten mit "Tone-Wheels". Ein Motor treibt über unterscheidliche Übersetzungsgetriebe eine Reihe von kleinen Rädern an die ähnlich aussehen wie Sterne. Die Zacken der Sterne laufen vor einer vormagnetisierten Spule her und erzeugen durch den Wechsel des magnetischen Flusses eine sinusähnliche Wechselspannung. Damit werden alle Töne erzeugt die es in der Orgel gibt. Jede Keyboard-Taste hat mehrere Schließerkontakte über die die jeweiligen Töne auf eine Sammelschiene geschaltet werden. Auf diese Weise werden zum eigentliche Grundton diverse Ober- und Untertöne dazu gemischt. Das Mischungsverhältnis (..oder der Ober- und Untertonanteil) wird dann schließlich je Sammelschiene über Potis geregelt. Diese Potis sind die Drawbars. Man kann also das Spektrum des Tons den man spielen will über diese Drawbars einstellen. Die B3 hat je Manual 9 solcher Drawbars und für das Pedal noch 2 weitere. Das ist auch der Grund weswegen ich den Controller nicht will, der hat nämlich für alles nur einen Satz Drawbars. Um den Sound schnell wechseln zu können gibt es sogar umschaltbar 2 Stätze Drawbars je Manual. 10 weitere Sounds mit fest verdrahteten Einstellungen sind ebenfalls schaltbar. Mein Projekt: 2 Manuale je 61 Tasten und ein Pedal mit 25 Tasten (alle vorhanden) steuern über einen Midi Controller (Projekt) den Midi-Expander (vorhanden) an. Die Stellung der Drawbars (muss ich noch bauen) werden über Linearfader abgefragt und ebenfalls über einen Midi Controller (Projekt) an den Expander gesendet. Ändert sich der Wert des Faders schickt der Controller neue Werte an den Expander. Ich möchte in meiner Orgel Presets verwalten (Projekt). In jedem Preset ist unter Anderem die Stellung der Drawbars für einen Sound gespeichert. Wird ein Preset aus dem Speicher abgerufen sendet der Controller für alle (20) Drawbars die entsprechenden Werte an den Expander. Leider sieht man jedoch nicht welche Werte ma da gerade aufgerufen hat. Die Stellung der Drawbars ist aber ein wichtiges Mittel für den Spieler um den Sound zu formen. Außerdem gibt es ein Problem beim Einstellen eines Faders: Wenn man die Stellung verändert und der Controller den neuen Wert sendet kann ein Sprung entstehen (vom eingestellten auf den neuen Wert), das klingt unschön. Zur Abhilfe hab ich mir folgendes überlegt: Wenn der Controller die neuen Werte an den Expander sendet werden in der Orgel die Drawbars machanisch auf den entsprechenden Wert gestellt (Projket!). Dazu benutze ich die Motorfader von Alps http://www.reichelt.de/Schiebepotis/RS60N11M9-LIN5K/3/index.html?&ACTION=3&LA=5&ARTICLE=73883&GROUPID=3713&artnr=RS60N11M9-LIN5K Mein ganzes Bauvorhaben besteht, vom mechanischen Aufbau mal abgesehen, also aus folgenden Teilen: - Keyboard Midi Controller - Drawbar Midi Controller - Preset Speicher - Ansteuerung der Motorfader Im Moment bin ich noch damit beschäftigt eine Roh-Version des Gehäuses zu bauen. Wenn technisch alles läuft werde ich das noch mal bauen, dann aber mit allen notwendigen Änderungen und in schön. Irgendwann in den nächsten 2-3 Wochen werde ich anfangen einem Atmega328 ein wenig Midi beizubringen und damit meine ersten Gehversuche zu starten. Ein paar Midi relevante Beiträge hab ich hier schon gelesen. Ich glaube das ich das einigermaßen flott hinbekomme. Auch zum Thema Daten auf irgendwelchen Karten zu speichern hab ich auch schon was gesehen, allerdings war mir die Lösung für mein damaliges Projekt (Datenlogger im Modellflugzeug) zu aufwändig. Hier werde ich also noch was tun müssen. Worauf ich mich schon richtig freue ist die Sache mit den Motorfadern, da ist bestimmt noch ne Menge Kreativität gefragt :-) Soweit meine Vorstellung, ich werde euch aufm laufenden halten. Für gute Ideen bin ich immer zu haben.
Angehängte Dateien:
-
220px-Hammond_B3__Museum_of_Making_Music.jpg
9,6 KB -
m3_twg__closeup.jpg
180 KB -
CIMG0097s.jpg
110 KB -
442094_RB_00_FB.EPS_400.jpg
8,3 KB
Angehängte Dateien:
-
r_b3_1.JPG
83 KB -
r_b3_2.JPG
150 KB -
b4_s.JPG
82 KB
Hallo Peter wow - sehr viel Text sehr viele Infos und ein schönes Projekt oben drauf. Welche Claviaturen verwendest du? Hersteller? Die Motorfader willst du dann auch für Preset's nutzen? Der Hammond XM1 Midi Expander hört sich gut an, darf ich fragen was du bezahlt hast? Um den geht es oder: http://www.kalaydo.de/kleinanzeigen/orgeln/hammond-xm-1-organ-expander-b3-mit/a/64623755/ Deinen Thread hab ich mal unter Beobachtung :) bin gespannt wie es weitergeht; ich verwende den den LS ( Live-Styler ) und B3 von Steinberg. Extern in einem eMbeddedCase und minimal Win, angesteuert dann über WIFI-MIDI und Android APP. Gutes gelingen! lg rudi :) btw: aus welcher Gegend kommst du? edit: kennst du das: Doepfer B3 http://www.doepfer.de/Controller_Organ_8.htm und B4 ( native instruments ) http://www.bergermusic.de/de/b4-controller/home/
Hi Rudi, >Welche Claviaturen verwendest du? Hersteller? Hersteller weiss ich nicht. Die Claviaturen kommen aus 2 Funkey DP61 Digitalpianos. Die gab es letztens 2 Stück defekt für kleines Geld. http://www.ebay.de/itm/DEFEKT-2-STUCK-BASTLER-DIGITAL-KEYBOARD-61-TASTEN-E-PIANO-LED-DISPLAY-100-SOUNDS-/311312713797?pt=LH_DefaultDomain_77&hash=item487baf0845 http://www.kirstein.de/Home-Keyboards/FunKey-DP-61-II-Digitalpiano-mit-Staender-Schwarz-SET-inkl-Bank-Kopfhoerer.html An dem einen war das Display gebrochen, am anderen ein Stecker ab. Die Tasten waren zum Glück tadellos ok. Ich würde die aber nicht noch mal kaufen, der Druckpunkt ist imho zu tief, soll heißen man muss die Taste fast bis an den Anschlag niederdrücken bis der Ton kommt. Könnte aber auch an dem Controller gelegen haben, ich habs noch nicht mim Ohmmeter nachgemessen. Ein paar Tage später gingen 2 61er Fatar Claivaturen incl Matrixscanner für 50€ weg, wie wären wahrscheinlich besser gewesen. >Die Motorfader willst du dann auch für Preset's nutzen? Ähh, fast. Die Motorfader werde ich nur für die Drawbars nehmen. Dann brauche ich noch ein paar Schalter für diverse Effekte, natürlch auch "motorisiert". Ich glaube da werd ich klassische Ersatzteil Wippschalter nehmen und einen elektrischen Weichenantrieb von der Modellbahn dranbauen. Um de Presets abzurufen gibts ne kleine Zifferntastatur. Mal sehn das ich was hinbekomme was nicht sö fürchterlich nach Stilbruch aussieht, das Original ist schliesslich aus den 30ern :-) Vieleicht was mit Nixie Tubes >Der Hammond XM1 Midi Expander hört sich gut an, >darf ich fragen was du bezahlt hast? 30€ incl Versand + 15€ Display >Um den geht es oder: >http://www.kalaydo.de/kleinanzeigen/orgeln/hammond... jepp >[..]ich verwende den den LS ( Live-Styler ) und B3 von Steinberg. https://www.youtube.com/watch?v=5gCUOZK9-A0&index=2&list=PL7EA79A3CB03C32AA Das geht schon in die richtige Richtung >aus welcher Gegend kommst du? Münster / Westfalen >kennst du das: Doepfer B3 Jau. Die hab ich mir wohl ziemlich genau angekuckt. Wahrscheinlich tut die Kiste schon viel von dem was ich vorhabe, aber ich finde sie pottenhässlich, sorry :-o Ich bin da vieleicht ein wenig altbacken. Uuh, ich seh gerade das ich das mit dem Doepfer d3c verwechselt habe. http://www.doepfer.de/Controller_d3.htm Ich hab von Doepfer ein CTM64 Board gekauft um das Pedal zu midifizieren. Das war aber vor meinen B3 Plänen, und so liegt das Teil noch hier rum. An sonsten sind die Doepfer Baugruppen nicht schlecht. Greetinx, Peter
:
Bearbeitet durch User
Systemarchitektur
Da sich die technische Umsetzung meines Projektes wegen Zeitmangel ein
wenig verzögert, habe ich mir in der Zwischenzeit mal Gedanken zu
Systemarchitektur gemacht. Erster Schritt meines Projekts wird sein aus
einen Tastendruck auf dem Keyboard in ein Midi Telegramm zu erzeugen und
auf der Midi Schnitte auszugeben.
Teilschritte:
- schnelles Keyboardscanning der insgesamt 147 Tasten, wenn
möglich ca 10.000 Scans pro Sekunde
- Zwischenspeichern der Informationen
- Ausgabe auf der Midi Schnittstelle
Das Problem sehe ich im Moment beim Scanning, ich erwarte das der
Controller damit ausreichend beschäftigt ist. Ich habe daher geplant für
die beiden Keyboards und das Pedal je einen Atmega328 einzusetzen. Die
wollte ich dann per I2C an einen weiteren 328er hängen der die
Midiausgabe übernimmt. An diesen Bus können dann später auch die
Controller die das ganze Drawbar- Preset- Diaplay- SDKartengedöns
machen.
Alternativ wäre es auch möglich die Peripherie-Controller über je eine
UART Schnittstelle an den Midicontroller zu hängen. Ich weiss aber noch
nicht wie sich das mit den „echten“ und emulierten UARTS im 328er
verhält
Entwurf 1:
+-----------------+
| µC Upper Manual |-----I2C-----+
+-----------------+ |
|
+-----------------+ |
| µC Lower Manual |-----I2C-----|
+-----------------+ |
|
+-----------------+ |
| µC Pedal |-----I2C-----|
+-----------------+ |
|
+-----------------+ |
| µC Drawbar |-----I2C-----|
+-----------------+ |
|
+-----------------+ |
| µC MMI |-----I2C-----|
+-----------------+ |
|
+-----------------+ |
| µC Midi |-----I2C-----+
+-------+---------+
|
+---RS232--- Midi Interface
Entwurf 2:
+-----------------+ +-------+
| µC Upper Manual |-----RS232-----| µC |
+-----------------+ | MIDI |
| |
+-----------------+ | |
| µC Upper Manual |-----RS232-----| |---RS232--- Midi
+-----------------+ | | Interface
| |
+-----------------+ | |
| µC Pedal |-----RS232-----| |
+-----------------+ | |
| |
+-----------------+ | |
| µC Drawbars |-----RS232-----| |
+-----------------+ | |
| |
+-----------------+ | |
| µC MMI |-----RS232-----| |
+-----------------+ | |
+-------+
Unschwer zu erkennen das der Entwurf 1 der ausbaufähigere ist,
allerdings habe ich noch keinerlei Kenntnisse zur I2C Programmierung. So
wie ich weiss gibt es im I2C immer nur einen Master. Das wäre dann der
MIDI Controller denn der ist am wenigsten beschäftigt (nach derzeitgem
Kenntnisstand).
Ich denke das ich übernächste Woche meinen Gehäuserohbau abgeschlossen
habe, dann werd ich mal zwei 328er aufm Steckboard aneinanderhängen.
greetinx
Peter
Kennst Du diesen Ansatz: http://shop.keyboardpartner.de/epages/13705466.sf/de_DE/?ObjectPath=/Shops/13705466/Categories/Category1
Wenn UART, würde ich für den 'µC MIDI' einen mit 2 echten UARTs nehmen, und die Anderen zu einem UART-Ring verschalten: z.B. 'µC Lower Manual' TXD -> RXD 'µC Upper Manual' TXD -> RXD 'µC MIDI' TXD -> 'µC MMI' ... Dann kann man mit den echten UARTS arbeiten, bindet nicht so viel Leistung in (Timing kritische) Soft UARTs, und das System bleibt erweiterbar. Den Ring kann man mit recht hoher Baudrate betreiben, und so auch mit dem Nachteil leben, daß die Daten durch die anderen Controller 'durchgeschleift' werden. Ein Vorteil der UART-Lösung sind die Puffer der UARTs, da siehts bei der SPI der ATmegas schlechter aus. Mit freundlichen Grüßen - Martin
Martin Schlüter schrieb: > Wenn UART, würde ich für den 'µC MIDI' einen mit 2 echten UARTs nehmen, > und die Anderen zu einem UART-Ring verschalten Ich würde für alle uCs Typen mit echten UARTs wählen und die dann MIDI mit einander sprechen lassen, nur mit höherem Bitrate. Dann kann der Kommunikationsteil der Software von allen Controllern weitgehend gleich bleiben.
@Eric B. (beric): Da der TO ja schon den ATmega328 genannt hat, bin ich davon ausgegangen, daß die 'Unter-Baugruppen' ja schon einen echten UART haben, der 'µC MIDI' braucht aber 2, was es nicht bei allen ATmegas gibt. Der, von mir vorgeschlagene, UART-Ring ist ja, von der Struktur her, dem MIDI recht ähnlich. Dort das MIDI-Protokoll zu verwenden sollte gehen. Bei echter MIDI-Hardware kommt halt noch die galvanische Trennung, und die Störsicherheit, weil Stromschleife, dazu. Ob der Aufwand bei der internen Vernetzung nötig ist? Mit freundlichen Grüßen - Martin
@HX3 Jau, HOAX kenn ich von einem Spezi der sich die Midi-Version zugelegt hat. Das HX3 hat ne ganze Menge Funktionen mehr als der Hammond XM1 Expander. Außerdem hat es den Vorteil das man die Scanner direkt anschließen kann und nicht über Midi muss. Da ich aber das XM1 schon habe werde ich wohl dabei bleiben. Hast Du irgendwie einen Draht zu der Firma? Die Website find ich seltsam. cu, Peter
Systemarchitekur II
Eine Kette aus RS232 hätte den charmanten Vorteil das ich die Technik
dazu einigermaßen beherrsche. Es würde zuwar zu höheren Latenzzeiten von
Lower Manual und Pedal führen, aber da muss ich ohenhin nochmal
nachrechnen in welchem Bereich ich mich befinde und ob das überhaupt
Auswirkungen hat. Schließlich muss der ganze Sumps am Ende durch die
Midi Schnittstelle, und das ist nach meiner jetztigen Auffassung das
eigentliche Nadelöhr.
Entwurf 3:
+----------------------+ +-------+
| µC Upper Manual TX |-----RS232-----| RX0 |
| RX |--+ | |
+----------------------+ | | |
| | |
+----------------------+ | | |
| µC Lower Manual TX |--+ | |
| RX |--+ | µC |
+----------------------+ | | MIDI |
| | |
+----------------------+ | | |
| µC Pedal TX |--+ | RX1 |--- RS232----- Midi in
| RX |--+ | TX1 |--- RS232----- Midi out
+----------------------+ | | |
| | |
+----------------------+ | | |
| µC Drawbars TX |--+ | |
| RX |--+ | |
+----------------------+ | | |
| | |
+----------------------+ | | |
| µC MMI TX |--+ | |
| RX |-----RS232-----| TX0 |
+----------------------+ | |
+-------+
Erinnert mich irgendwie an dei Token-Ring Verkabelung die wir Anfang der
90er bei unseren Kunden installiert haben :-)
Da ich möglichst bei DIL Bauweise bleiben möchte käme irgendwas zwischen
ATmega164A-PU bis ATmega1284A-PU in Frage. Den gibt es im handlichen
40Pin DIL Gehäuse mit reichlich IO Pins, so das er sich auch für die
Manual-Scanner anbieten würde.
Natürlich würde auf den Leitungen Midi gesprochen, knapper lässt sich
die Information ohnehin nicht übertragen. Vieleicht liesse sich der
Vel-on und Vel-off Wert noch einsparen da ich die ganze Kiste (zunächtst
mal) ohne Anschlagdynamik betreiben werde.
Zum Thema Baudrate:
Standard Midi Baudrate ist 31250. Ich werde also wahrscheinlich
(zumindest den Midi µC) mit 16MHz betreiben weil sich daraus sauber die
31250Bd generieren lassen. Mach es also Sinn die Periepherie µC mit
20MHz zu betreiben nur um die letzten 25% mehr Performance rauszuholen?
Imho nicht, denn wenn die µC untereinander ein vielfaches von 31250
sprechen sollen wäre es schon gut wenn alle Beteiligten den Takt sauber
(oder wenigstens mit einheitlichem Fehler) hinbekommen würden. Ich hab
nicht genau gekuckt, aber gibt es nicht auch einen ATmegaxx4 mit 32MHz?
Groetjes,
Peter
Zur Geschwindigkeit, ob's mit SPI wirklich viel schneller wird, würde ich bezweifeln, die maximale Datenrate ist zwar höher, aber durch die fehlende Pufferung (im Gegensatz zum UART) verliert man auch Durchsatz. Wenn die Controller nicht zu weit voneinander entfernt sind, kann man mit der Baudrate aufs Maximum gehen, bei 16 MHz und umschalten auf doppelte Datenrate kommt man da auf 2 Megabaud, dann trudelt aber auch alle 80 Taktzyklen (Mit Parity alle 88) ein neues Byte ein, und will verarbeitet werden. Bei hohen Baudraten, und den sich daraus ergebenden kleinen Baudrate-Teilern, müssen die Controller-Taktfrequenzen schon passen. Bei Ausnutzung des Maximums also alle mit 16 MHz (32 MHz gibt es, meines Wissens, nicht bei den ATmegas, da müsste man zu einem ATXmega greifen, den es aber nicht in DIL gibt). Beim mischen von mit 16 und mit 20 MHz betriebenen Controllern gingen maximal 500 Kilobaud (Teiler 4 beziehungsweise 5). Mit freundlichen Grüßen - Martin
Den richtigen µC finden: Um den Entwurf 3 umzusetzten benötige ich mindestens einen Controller mit 2 UARTs, damit ist mein heißgeliebter 328er ausm Rennen. Ich schieße mich also gerade auf den 644 bzw 324 ein. http://www.distrelec.de/de/Mikrocontroller-8-Bit-DIL-40-Atmel-ATMEGA644P-20PU/p/17325149?q=atmega644&page=2&origPos=1&origPageSize=50&simi=96.54 Ich hab mir mal das Kapitel USART ausm Datenblatt durchgelesen. Wenn ich das richtig verstanden habe dann gibt es in den ATmega grundszätzlich keinen Hardware FIFO Buffer so wie es den mal im 16550 (http://en.wikipedia.org/wiki/16550_UART#The_16550_FIFO) gegeben hat. Es gibt diverse Interrups Trigger (TX copmplete, RX complete, Data Register empty) die jeweils eine entsprechenden Interrupt auslösen können. Das Buffen übernimmt dann ein Bascom-Modul. Damit beschränkt sich der Vorteil gegenüber der TWI-Lösung (Entwurf 1) imho auf die einfachere Programmierung. Es wäre also doch noch mal eine Überlegung wert ob sich der I2C eignen würde, vorausgestzt die Programmierung hält sich in vertretbaren Grenzen. Interessanter wäre es schon. Greetinx, Peter
:
Bearbeitet durch User
Peter R. schrieb: > ... gibt es in den ATmega grundszätzlich > keinen Hardware FIFO Buffer ... Das ist so nicht richtig, Die Sende-Seite ist 1-fach gepuffert, man kann also schon das nächste Byte schreiben, wärend das Aktuelle gesendet wird, und die Empfangs-Seite ist sogar 2-fach gepuffert. Diese Technik ist halt vor dem Programmierer verborgen, so daß man sich auch nicht darum kümmern muß, die Vorteile kann man aber trotzdem nutzen. So haben z.B. auch die Fehler-Flags ihr FIFO, sie gelten immer für das gerade anstehende Byte, weshalb im Datenblatt ja auch geraten wird, die Fehler-Flags zu lesen bevor man das Daten-Byte liest. Man kann also problemlos Start- an Stopp-Bit senden und empfangen. Diese Puffer sind übrigens auch aktiv, wenn man die ATmega UARTs als Master-SPI betreibt, da kann man dann lückenlose Bitströme erzeugen, manchmal recht nützlich für irgendwelche Bitbanging-Sachen. EDIT: TWI würde ich für diese Anwendung nicht nehmen, da sind die maximalen Geschwindigkeiten deutlich geringer, und die Programmierung komplizierter. Mit freundlichen Grüßen - Martin
:
Bearbeitet durch User
Ich bin zwar sehr lange aus der digitalen Musik raus, aber ich kenne mich mit I2C und anderen Bussen immer noch gut aus :) Du musst bei Deiner Architektur davon ausgehen, dass viele Tasten gleichzeitig gedrückt werden, also viele Daten gleichzeitig versandt werden wollen. I2C hat keine wirklich tauglichen Kollisionsbehandlungen! Damit wirst Du also einen recht heftigen Overhead an Software haben, die mit dem Erkennen und behandeln von Buskollisionen beschäftigt ist. Aber natürlich ist I2C Multi-Master fähig... Im realen Leben wäre dann aber doch eine art Interrupt-System und ein Master sinnvoller. D.h. jeder Slave setzt eine Interrupt Leitung und wird dann vom Master gepollt. Die 2. Lösung wäre natürlich der UART als Ring und den dann ruhig mit 1MBaud laufen lassen. Der Vorteil ist, dass Du jedem Block deines Systems einen festen Zeitslot in deinem Ring zuweisen kannst. So kannst Du Manuale und Pedale 10x so oft abfragen, wie Drawbars und andere nicht so Echtzeit gebundene I/Os. 1MBaud sind grob geschätzt 100kB/s also könntest du für 100 Tasten 1000 mal pro Sekunde ein Byte übertragen, was ich für mehr als ausreichend halte. Du musste ja auch berücksichtigen, dass mit steigender Frequenz die Führung der Leitungen nicht einfacher wird. Hmmm... Auch viele UARTs kann man in einem Bus zusammen schalten. RS485 mit einem Master... Der sendet immer einen festen Startbefehl und die Slaves antworten dann immer an einer festen Zeitposition oder eben als Antwort auf ihre Adresse. Das wäre jedenfalls ein guter BUS, der auch dafür gedacht ist über ein paar Meter Kabel Daten zuverlässig zu übertragen. Nackter UART (also 5V Pegel) oder I2C sind nicht für das Verlassen der Heimatplatine gedacht. Und ATMEL und I2C sind auch keine zuverlässig Kombination... STM32 wäre noch eine Idee, zumal man mit einem CortexM3 schon eine Menge Vorberechung machen kann, CAN und 3..5 UARTs gleich drin sind und er das gleiche kostet wie ein AVR... Nur halt 10x so leistungsfähig. Die können dann auch UART und DMA kombinieren, oder Tasten-Anschläge per DMA sampeln und für ADSR aufbereiten... Gruß Ulrich
Habe mal einen Spieltisch einer Sakralorgel "Midifiziert". Es gab da einen fertigen Satz an Klaviatur- und Pedalscannern mit einem zenztralen Controller. Wenn es interesiert suche ich nochmal raus von wem das Zeug war. PS: Der Spieltisch steht zum Verkauf. Bei Interesse einfach hier Antworten und ich melde mich per PN.
Irgendwie sieht es aus als wolltest du die Midibox nachbauen. www.ucapps.de Einen Teil deines Projektes, und zwar die Zugriegel und Schalter hab ich mal mit der alten Midibox64 gebaut. Wichtig ist nur die Anpassung der Midi-Befehle. Mittlerweile gibt es dort auch einen Keyboardscanner für Matrixtastaturen. Für ne orgel würde sich die Fatar TP/80 empfehlen. Bassklaviaturen mit 25 Tasten sind eher selten.
Onboard Kommunikation:
nach dem ich mich jetzt mal ein paar Tage mit dem I2c, TWI und SPI
Schnittstellen auseinandergesetzt habe bin ich wohl doch soweit das ich
denke das nix davon für meine Anwendung wirklich zu gebrauchen ist. Es
ist ne ganze Menge Handshake und anderer Overhead auf den Bussen
notwendig das ich so eigentlich nicht machen wollte. Zwischendurch hatte
ich auch ma überlegt ob sich was auf der Basis der RS232 mit
zusätzlichen Hardware-Handshake Leitungen realisieren ließe und so ganz
ist das auch noch nicht vom Tisch.
+-------+
| µC |
+----------------+ | |
| RTS |------------------------------->| IRQ |
| Manual µC | | |
|(Peripherie µC) | +-------+ | |
| TX |---RS232--->| MUX |---RS232-->| RX |
| | |<-select---| |
| | +-------+ | |
| RX |<--RS232--| DEMUX |<----RS232---| TX |
| | ! | |
| | +-------+ | |
| CTS |<-------| DEMUX |<-----select---| |
| | ! ! | |
! ! ! !
Damit könnte man eine Teil der ganzen "wer spricht wann mit wem"
Geschichte in ein paar TTL ICs auslagern. Außerdem gäbes es dann wieder
eine einheitliche "Schnittstelle" zum zentralen µC.
Derzeit beschäftige ich mich mit dem Atmega2560. Der ist zwar etwas
unhandlich (TQFP100 Gehäuse) hat aber ne Menge drauf. Unter anderem hat
er 4 UARTs und ne Menge (86) IO-Pinne, damit könnte man für bis zu 3
Peripeherie µC jeweils ein eigenes RS232 Paar nehmen (plus 1x Midi) und
alles andere wie Display, Tasten, Memorykarte, Faderansteuerung etc aus
dem zentalen µC machen. Den Chip könnte man ggf auf eine Adapterplatine
setzten (gibt es sogar fertig), ich weiss nur noch nicht genau ob sich
dafür auch mit Bascom Code schreiben lässt, aber das werd ich noch
rausbekommen.
Eine andere Überlegung: Gleicher Ansatz wie Entwurf 3, aber die Midi
Schnitte hängt nicht mehr am Midi µC sonder am letzten µC in der Kette.
Entwurf 3a:
+--------------------------+
| Hammond MX1 |---------- Audio Out
| Midi Expander Midi Out |---------- Midi out
| Midi-In |--+
+--------------------------+ |
|
+--------------------------+ |
| µC Upper Manual TX |--+
| RX |--+
+--------------------------+ |
|
+--------------------------+ |
| µC Lower Manual TX |--+
| RX |--+
+--------------------------+ |
|
+--------------------------+ |
| µC Pedal TX |--+
| RX |--+
+--------------------------+ |
|
+--------------------------+ |
| µC Aux (Mem, Drawbar TX |--+
| Display, Tasten, etc) RX |------------ Midi in
+--------------------------+
Da ohnehin jeder der 3 Manualcontroler die Mididaten die er empfängt
mitlesen UND interpretieren muss damit die Daten verschiendener
Midi-Nachrichten nicht vermischt werden, kommen am letzten µC in der
Kette schon gültige Midi Daten raus, die brauchen eigentlich nicht
nochmal irgendwo gelesen und verarbeitet zu werden und könnten
ungefiltert in den Midi-Expander (Sound Modul) gehen. Einziger Nachteil
wäre das alles was in die Kiste an Mididaten reinkäme durch alle
Controller laufen müsste bis es im Expander landet. Das wäre aber nur
dann relevant wenn man die Orgel per Midi ansteuern will. Obwohl das
nicht der primäre Verwendungszweck der ganzen Kiste sein soll würde ich
mir diese Möglichkeit gerne offenhalten. Das sollte aber auch kein
Problem sein, denn wenn von außen Midi reinkommt wird die Orgel
üblicherweise nicht von Hand gespielt, obwohl es möglich und auch
wahrscheinlich kein (Timing-)Problem wäre.
Greetinx,
Peter
jetzt ohne alles gelesen zu haben Wenn du midi Controller bauen möchtest ist eventuell midibox http://www.ucapps.de/ das mittel deiner wahl
Also die Lösung mit den Multiplexern würde ich nicht machen, da wird das mit dem Handshake nicht einfacher, und es braucht zusätzliche Logik, und IO-Pins. Dein letzter Vorschlag ist natürlich eine Möglichkeit, ist aber eine Einbahnstraße, gerade der 'µC Aux' wird da nicht glücklich werden, wo sollen z.B. die Daten für das Display herkommen, und zu dem, von mir vorgeschlagenen, Ring fehlt nur noch eine Leitung. Das Timing und Handshake wird bei dem Ring deutlich eifacher, wenn man eine Handshake-Leitung in engegengesetzter Richtung zu den Daten, auch wieder im Ring, verlegt. Dann kann der empfangende µC seinem Vorgänger Empfangsbereitschaft mitteilen, und eventuell noch den Empfang eines Paketes bestätigen, z.B. durch kurzes 'wackeln' an der Handshakeleitung. Das schöne an dem Ring-Konzept ist, daß immer nur 2 Controller miteinander klar kommen müssen, unabhängig davon, wie viele es insgesamt sind. Wenn man nicht ans Limit geht, mit der Auslastung, kann so ein Ring auch gut ohne Handshake betrieben werden. Mit freundlichen Grüßen - Martin
Also ich finde einen Ring durch viele UARTs hindurch nicht unbedingt einfach. Denn jeder Controller benötigt dann 2 UARTs und muss nicht nur seine eigenen Daten, sondern auch die aller Kollegen händisch durch sich hindurch kopieren. Gerade weil aus mir unverständlichen Gründen immer AVRs genommen werden, ist das doppelt "teuer" denn der AVR kann kein DMA, also muss er jedes Byte von Hand schaufeln. Nutzt man einen STM32, könnte man die Daten per DMA umkopieren, das ist aber weiterhin einfach überflüssig, denn das Manual A braucht keine Informationen vom Manual B oder vom Pedal. Also gibt es doch nur zwei Probleme zu lösen: Alles auf den Bus und das in geordneter Reihenfolge. Lösung: Alle Systeme an einen RS485 Bus anschliessen. Teurer, aber einfacher ist es, einen Full-Duplex Bus zu bauen, also 4 Leitungen zu verlegen. Aber eigentlich sollte man auch einen Half-Duplex Bus leicht programmieren können. (Ein zusätzlicher GPI schaltet den Tranceiver auf Senden) Das "Geordnet" ist auch einfach zu lösen, in dem Client-Platinen immer nur hören, bis sie ihre Adresse empfangen. Dann antworten sie, in dem sie neue Events senden, also gedrückte, oder los gelassene Tasten, geschobene Register oder gedrehte Pitches. Das Problem dabei ist aber, dass man auf den Manualen mehr Events erzeugt, als auf den Pedalen, 10 Finger schaffen mehr als 2 Füße. Aber man will durch die Technik die Pedale nicht asymetrisch / zufällig verzögern. Also speichert jeder Client jedes Event in einem Puffer als FIFO und in jeder Abfragerunde wiird immer nur das älteste Event auf des Bus geantwortet. Wie geht das einfach? Sogar der olle AVR kann 9-Bit UART. Der Master sendet das 9. Bit als 1, dann wissen alle Clients, dass jetzt eine Adresse kommt. Empfängt ein Client bei gesetzten Bit 9 seine Adresse, wird er aktiv und sendet seinen anstehenden Event, oder eben einen Code, der sagt "habe fertig". Und zu allem Überfluss gibt es in vielen Controllern sogar einen Interrupt, wenn der im halbschalf seine Adresse am Bus erkannt hat. Damit kann man diesen Mechanismus sogar per Interrupt laufen lassen. Wie ich oben schon geschrieben habe, kann man einen RS485 mit 1MBit laufen lassen. Das sind fast 100kByte/s. Bei Adresse, Tasten-Code, Aftertouch Wert, von jeweils 1 Byte, wäre das mit etwas Toleranz 100k/4 als 25kHz Samplerate, bei 5 Platinen also 5kHz Abtastrate. Man kann also 5000 Tastenevents mit jeweils Adresse, Tastecode und Zusatzwert pro Sekunde verarbeiten. Da kannst Du vermutlich die Pianoguys alle zusammen an die Manuale setzen... Da der Master ja immer die Cliens mit einer Adresse abfragt, kann man auch noch optimieren, also beispielsweise die Manuale häufiger abfragen als die Pedale oder Register, in dem der Master die Adressen als 1,2,1,2,1,2,3,1,2,1,2,4,1,2,1,2,3... Laufen lässt, also Pedale und Register nur alle 8 Durchläufe abfragt. Dazu programmiert man sich dann einfach eine Tabelle, die abgearbeitet wird. Gruß Ulrich
Meine erste Idee war ganz anders. Du hast ja bei nem echten Clone keine Anschlagdynamik, also würde im Prinzip ein Bit pro Taste und Pedal reichen. Wenn man das direkt per Memory-Mapping z.B. machen würde, wäre der Protokoll-Overhead gleich Null. Dann so ein 32 Bit Arm Controller, und man hätte alles an einer Stelle geregelt? Andererseits bietet Anschlagdynamik halt den Vorteil, dass man vielleicht auch mal Piano-Sounds spielen möchte, bei denen die Dynamik schon essentiell wäre.
Ulrich P. schrieb: > Denn jeder Controller benötigt dann 2 UARTs Das stimmt so nicht, da es ja nur eine Leitung ist, die zum folgenden Controller geht. Da reicht ein UART, TXD geht zum folgenden Controller, RXD zum Vorhergehenden. RS485 ist natürlich eleganter, aber auch etwas mehr Bauteileaufwand. Man kann aber auch UARTs zum Bus verschalten, TXD vom Master geht an alle anderen RXD, die TXDs der Untereinheiten kann man über ein AND mit entsprechender Anzahl Eingängen zusammenfassen, oder, wenn man die Ports per Software auf Eingang schaltet, wenn nicht gesendet wird, auch direkt zusammenschalten. Damit lässt sich dann nach dem selben Prinzip, wie bei Full-Duplex RS485 kommunizieren. Die Leitungen sollten halt nicht zu lang sein, da ist RS485 eindeutig im Vorteil. Mit freundlichen Grüßen - Martin
Hallo, der RS485 kann auf 5V Pegel auch einfach mit einem sog. Wired OR zusammen gefasst werden. Dazu muss man statt der "teuren" RS485 keine "teuren" Logichips einsetzen, eine Diode oder besser ein Transistor tun es auch. Aber wenn man mit Diode und PullUp arbeitet kann man sich sehr viel Aufwand bei der Abstimmung einfangen, weil Dämpfgung, Takt, Einstrahlung... und so weiter... Der Grund halt, warum man Platinenübergreifend auch kein I2C einsetzen soll. Der Preis von ~1€ für einen RS485 Tranceiver Chip ist im Vergleich zu dem Ärger, den ein wackeliger Bus erzeugen kann aber verschwindend gering. Abgesehen davon macht ein standardisierter Bus das Projekt nachbaubar und man kann auch "abgesetzt" arbeiten, also die Pedal-Platine in das Pedalgehäuse verbauen und so mit nur 4 Leitungen anschließen, statt eines Arm dicken Kabelbaumes zum Zentralghäuse. Gruß Ulrich
Vielen Dank erstmal an alle die sich hier beteiligen, ich hätte nicht gedacht das das Thema auf so viel Interesse stößt. In Sachen STM32: Wow, was ne Maschine! Je nach dem welchen man sich da auskuckt steckt der einen AVR schon in die Tasche. Ich hab mich nur mal kurz mit dem CY8C29466-24PXI beschäftigt weil es den bei Reichelt gibt. http://www.reichelt.de/CY-8C29466-24PXI/3/index.html?&ACTION=3&LA=446&ARTICLE=146530&artnr=CY+8C29466-24PXI&SEARCH=DIL Aber Hut ab, der kann was. Allerdings heisst das für mich eine neue Entwicklungsumgebung (naja, das ginge ja noch) und C. Hmm, wie soll ich sagen, ich bin halt mit Basic aufgewachsen, meine Versuche in C sind bisher nicht wirklich vorzeigbar. Aber das kann ja noch kommen. Ist vorgemerkt für spätere Projekte, definitiv. @ Martin Schlüter (led_martin) Du hast Recht, 3a ist ne Einbahnstraße. Das wurde mir auch schon klar als ich das ausgearbeitet hatte, aber manchmal muss man auch mal eine Sache zu Ende denken die offensichtlich nicht ganz in die richtige Richtung geht. Was mich in der Hauptsache stört ist das jedes Byte das weiter unten in die Kette kommt mehrfach gesendet, gelesen, interpretiert, einsortiert, neu zusammengestellt, und wieder gesendet wird. Auch wenn es in mehreren Controllern gleichzeit passiert, schön ist das nicht. @ Sven (Gast) und Michael X. (Firma: vyuxc) (der-michl) Die uCApps (http://www.ucapps.de/) Lösungen hatte ich mir angesehen bevor ich beschlossen habe selbst was zu bauen. Doepfer (http://www.doepfer.de/home.htm) bietet auch das Ein oder Andere und auch die HOAX HX3 Lösung (http://shop.keyboardpartner.de/) habe ich mir angesehen. Alles sehr leistungsfähig, aber alles nicht das was ich haben möchte. Zu wenig bastel halt :-) Atmega2560: Der Controler meiner Wahl, zusammen mit 644ern für die Manuale und ggf den Drawbars. Beide lassen sich tadellos mit Bascom programmieren. Da der 644er genug IO Pins und wahrscheinlich auch genug Performance hat um beide Manuale zu scannen werde ich mir den 2.Controler dafür sparen. Das Pedal wir wohl einen eigenen Controler bekommen, allein schon deshalb weil ich keine Lust habe einen armdicken Tampen zu verlegen. Die Verbindung zwischen Orgel und Pedal solle maximal ein Patchkabel, besser noch ein einfaches Mono-Klinkenkabel sein, ma schaun. Für die Drawbars hab ich noch keine schöne Lösung. Damit sieht das Konzept bisher so aus: Entwurf 4: +-----------------+ +------------+ +----------+ | µC Upper Manual |<------8x Col-----| µC TX |----->| RX | | |-------8x Row---->| Scan (RX |<-----| TX) | +-----------------+ | (644) | | | | | | | +-----------------+ | | | µC Aux | | µC Lower Manual |<------8x Col-----| | | (2650) | | |-------8x Row---->| | | | +-----------------+ +------------+ | | | | +-----------------+ +------------+ | | | µC Pedal |--------25------->| µC TX |----->| RX | | | | Scan (RX |<-----| TX) | +-----------------+ | (644) | | | +------------+ | | | | +-----------------+ +------------+ | | | 20 Drawbars |---20x Spannung-->| TX |----->| RX | | |<--20x Stellwert--| RX |<-----| TX | +-----------------+ | µC | | | | Drawbars & | | | | Schalter | | | +-----------------+ | (644 ?) | | | | 5x Schalter 0-1 |--------10------->| | | | | 1x Schlater 0-5 |<--6x Stellwert---| | | | +-----------------+ +------------+ | | | | +-----------------+ | | | | | | | Display |<-------------8/4Bit + E + RS---------| | | | | | +-----------------+ | | | | +-----------------+ | Midi | | | | | | Mem Card |<--------------------?--------------->| | | | | T R | +-----------------+ | X X | +----------+ | ^ | | +--------------------------+ | | | | | | | Hammond MX1 Midi In +<-------+ | Audio Out <---------| Midi Expander | | | Midi out +--------+ | | | | | +--------------------------+ | | | | V | Midi out Midi in Scanner: Die Keyboards sind als 8x8 Matrix mit Entkopplungsdioden geschaltet. Jede Taste hat 2 Kontakte, einen um den Ton zu erzeugen und einen weiteren der etwas später schließt um zu ermitteln wie schnell die Taste gedrückt wurde. Der 2. Schaltpunkt liegt aber auf meinen Manualen so tief unten das die Taste unangenehm spät reagiert wenn man die Anschladynamik mit auswerten will. Also ist der ganze Sumps mit der Anschlagdynamig gelaufen. Wenn ich ein anschlagdynamisches Gerät spielen will nehm ich ein anderes Keyboard (von denen sich mittlerweile ja einige angesammelt haben :-). Ich werd die zweiten Kontakte für später mal mit auf den µC legen, man kann ja nie wissen, aber das ist nicht Bestandteil dieses Projekts. Bleibt also 1 Kontakt je Taste. Der µC fragt die 8 Zeilen (Row) nacheinander ab und bekommt auf 8 Spalten (Col) die Information welche Taste gedrückt ist. Die Signale für die Zeilen können am upper und lower Manual gleichzeitg anliegen, macht zusammen 8 Zeilen und 16 Spalten = 24 Pinne. Der µC hält nach wie sich die Signale verändern und erzeugt daraus die jeweilige Differenz. Die Daten gehen denn als 1-Byte Nachrichten an den Aux. Aufbau: 1 Bit Taste gedrückt oder losgelassen + 1 Bit upper/lower Manunal + 6 Bit für die Tasten 0-63. Das Pedal stellt 25 Reedkontakte zur Verfügung. Die werde ich ungebremst Byte- bzw Portweise lesen. Verarbeitung und Weiterleitung an Aux wie bei den Manualen. Aufbau wie bei den Manualen, 1 Byte gedrückt/losgelassen + "00" + 5 Bit für die Pedaltasten 0-24, da steckt sogar noch ein wenig Luft für Spielereien drin. cu, Peter
Wäre es nicht eventuell sinnvoller, die manuale mittels einfacher Schieberegister abzugrasen? Das geht mit dem SPI-COntroller des µC (egal welcher), einen Load-Puls erzeugen und anschließend n Bits per SPI empfangen. Der SPI läuft beim AVR iirc mit max f_clock/2, also braucht es bei 16MHz min 2*ceil(n_tasten/8)*8/f_ck, also ca 1µs pro 8 Tasten. Anschließend liegen alle Tasten als Bitmap im Mastercontroller vor.
Armdicke Kabel? Bei den 66 Tasten meines c64 reicht ein kleines Flachbandkabel...
@Andreas Lang (andi84) ich glaube es lohnt nicht dafür extra ein Schieberegister zu nehmen. Ich kann 8 Tasten in ein Byte parallel einlesen, wesentlich scheller gehts imho nicht. Was man überlegen könnte ist für die Ansteuerung der 8 Zeilen einen Demultiplexer (zB 74138) zu nehmen, damit könnte ich noch 5 Pinne sparen, aber bis jetzt sieht es so aus als hätte ich genug Ports dafür auf dem 664er. greetinx, Peter
@Andreas Rückert (daybyter) naja ok, ich hab maßlos übertrieben, du hast mich erwischt :-) Andererseits, welches genormte Kabel mit 26 Drähten gibt es? Ein Db25 Kabel hat immerhin 25 Drähte + Masse, das würde ja schon passen, aber damit ist das Teil auch schon ausgereizt. Für ein Lautstärkepedal müsste ich dann das nächst stärkere (37 pol) oder ein zweites Kabel nehmen. cu, Peter PS: ich musste echt nachzählen, aber der C64 hat tatsächlich 66 Tasten, lang lang ist's her....
@Peter R. (2meter_peter): Das neue Konzept gefällt mir gut, auch wenn der Ring damit gestorben ist, möchte ich das hier Peter R. schrieb: > Was mich in der Hauptsache stört ist das jedes Byte das > weiter unten in die Kette kommt mehrfach gesendet, gelesen, > interpretiert, einsortiert, neu zusammengestellt, und wieder gesendet > wird. Auch wenn es in mehreren Controllern gleichzeit passiert, schön > ist das nicht. kommentieren, lesen ja noch Andere mit: So schlimm ist das gar nicht wenn man es geschickt macht, eine Möglichkeit, die ich schon eingesetzt habe sieht so aus: Die Daten werden in Paketen übertragen, die klein genug sind, im Controller gepuffert zu werden. Wenn man mit Handshake arbeitet (Wie ich, weiter oben, geschrieben hatte), reicht ein Puffer, sinnvoll ist es aber mindestens zwei zu haben. Die Datenpakete bekommen einen kleinen Header, der mindestens die Zieladresse, und die Länge des Pakets (Falls nicht fix) enthält. Kommt ein Paket rein, wird die Adresse angeschaut, ist es für einen anderen Controller, wird es einfach weitergeschickt, ohne den Inhalt zu betrachten. Ist es für diesen Controller bestimmt, wird es nicht weitergesendet, und eventuell sofort verarbeitet. Bei weiterzusendenden Paketen kann man die Übertragung natürlich schon starten, bevor das ganze Paket empfangen wurde, wenn der folgende Controller empfangsbereit ist. Das weiteschicken der Daten erzeugt natürlich einen zusätzlichen Aufwand, der ist aber nicht hoch, und bei einem Bus müssen auch alle mitlesen. Bei Anwendungen, bei denen sich die Datenströme nicht am 'Master' bündeln, sondern eher 'Kreuz und Quer' gehen erreicht der Ring einen deutlich höheren Durchsatz als der Bus (Trifft bei Deiner Anwendung nicht zu). Zwischen den Paketen sollte man kurze Pausen machen, damit sich das System neu synchronisieren kann, wenn die Paketlänge nicht korrekt übertragen wurde. Mit freundlichen Grüßen - Martin
Ansteuerung der Drwabars / Motorfader Die Orgel wird 20 Drwbars haben, je Manual 9 und für das Pedal 2. Ich habe mich für die 5k/60mm Motorfader von Alps (http://www.produktinfo.conrad.com/datenblaetter/425000-449999/442094-da-01-en-MOTORFADER_RS60N11M9_5KB.pdf) entschieden. Der mechanische Aufbau ist noch nicht ganz klar, entweder werden die Fader klassich wie im Mischpult unter der Abdeckplatte montiert und ragen mit den Schiebern durch die Platte, oder (was mir besser gefällt) ich baue eine echte Zugriegelmechanik drumherum, sehr hübsch aber mechanisch nicht ganz einfach. Die Motorfader bestehen aus einem normalen Linearpoti, einem Motor der den Schieber bewegt und einem "Sensor" mit dem man feststellen kann ob der Schieber angefasst wird. Das Poti hat 5k-lin, der Motor wird mit 6-11V Nennspannung angegeben. Der Sensor ist technisch gesehn nur ein Draht. Dahinter verbirgt sich ein zusätzlicher Schleifer der isoliert von allen anderen Potentialen eine leitende Verbindung zum Schieber herstellt. Dazu gibt es passende leitfähige Knöpfe. Mit Hilfe einer Sensortastenschaltung kann man also festsellen wenn jemand den Fader anfasst um zu verhindern das der Motor dagegen ankämpfen muss. Ich bin aber nicht sicher ob ich das nutzen will; wird also erstmal zurückgestellt. Der Motor ist ein normaler Bürstenmotor und treibt über eine Umlenkrolle und eine elastische "Zahnkette" direkt den Schieber an. Das geht ziemlich flott, ich schätze mal das er Motor auf den 60mm Schiebeweg keine 20 Umdrehungen macht, dafür tut er sich aber auch bis zu 800mA Anlaufstrom aufn Zahn. Die Faderstellung lässt sich ziemlich einfach über den Widerstand ermitteln, Spannungsteiler 0-5V (0,2-4,8V) einfachster Bauweise, mit einem ADC einlesen, fertig. Was muss also im Drawbar µC laufen ? - Faderstellungen lesen, mit alten Werten vergleichen, bei Änderung zum AUX µC senden. - Preset-Positionen vom AUX µC emfangen, Motoren ansteuern bis die Sollwerte erreicht sind. Die Presets werden in Form von Ziffernfolgen (sowohl intern als auch Midi-seitig) übergeben, zB für ein Manual "88804002". Gut zu sehen das der gesamte Schiebeweg je Drawbar in gerademal 9 Werte aufgelöst wird. Der Controller muss also den Fader auf eine der 9 Positionen fahren und das möglichst flott und ohne viel Geräusche zu erzeugen. Wenns geht würde ich den Fader auch nicht bis in die Endpositionen fahren sondern nur bis kurz davor. Die Frage stellt sich ob ich den Regelkreis im µC realisiere oder mit einer externen RC-Servo Schaltung. Dazu würde sich das übliche Pärchen aus BA6688L und BAL6686 anbieten. Der Nachteil ist jedoch das dazu nicht nur ne ganze Menge diskreter Bauteile nötig sind sondern vor allem das das Poti irgendwo mitten in der Schaltung hängt und wahrscheinlich keine verwertbare Spannung für den ADC liefern kann. Also vieleicht doch aus dem µC steuern und nur die H-Brücken extern, damit könnte man dann den Motor ggf auch "bremsen". Je Motor werden 2 Pinne (rechts, links, Leerlauf, bremsen) gebraucht, die hat der 664 erstmal nicht. Dazu kämen noch mal 20 ADC Eingänge, der 664 hat nur 16. Also denke ich wenn Regelkreis im µC dann direkt den 2650, andernfalls externe Servoelektronik und ADC Multiplexer. Hat schon mal jemad versucht Motoren im Array zu betreiben ? Bis denne, Peter
Also du nimmst teure Motorfader, die du mechanisch noch umarbeitest, bzw. in eine eigene Mechanik integrierst... Warum? Nimm kleine Stepper die Deine Mechanik bewegen. Lass die Stepper beim Einschalten der Orgel alle einmal an den Anschlag fahren, mit n+x Schritten in eine Richtung, danach fährst Du sie auf die zuletzt eingestellte Position zurück. Je nach Übersetzung durch Zahnstange unter dem Riegel, kannst Du die Stepper minimal bestromt lassen, um eine fühlbare Position zu haben. Es gibt fertige Stepper Chips, denen gibt man noch Richtung und Schritt vor, dann führen sie diesen Schritt aus. damit kann man vielleicht die Richtung auf alle Stepper parallel legen und nur denen einen Schritt geben, die diesen auch ausführen sollen. Während diese dann den Schritt ausführen, kann man anderen schon einen Schritt in die andere Richtung vorgeben, so dass sie sich fast gleichzeitig bewegen. Du brauchst eigentlich kein Poti, denn du könntest einen Dreh-Encoder an die Stepper-Achse anschließen, der einfach nur sagt, in welche Richtung der Riegel bewegt wird. Ich bin mir aber fast sicher, daß wenn man den Stepper minimal bestrom lässt, man anhand der Veränderung der Ströme in der Stepper-Schaltung schon erkennen kann, in welcher Richtung gegen die Haltekraft gearbeitet wird (und wie oft). Vielleicht sollte man da einfach einen ATtiny pro Register einsetzen, das könnte am Ende günstiger sein als alle H-Brücken-Poti-ADC-Multiplexer... Selbst, wenn Du den Motor-Fader nutzen willst, kann es sein, dass eine Kombi aus einem richtig kleinen ATtiny, ein paar FETs und einem ADC-Eingang, die preiswerteste Lösung ist. Man kann beim AVR die Pinne ja auch in trinärer Logik nutzen: Pin = Ausgang-Low: H-Brücke schaltet auf Links Pin = Ausgang-High: H-Brücke schaltet auf Rechts Pin = Eingang Hochohmig: H-Brücke aus. Der ATTiny hätte auch den Vorteil, dass man die Fader später unabhängig mit zusätzlicher Intelligenz ausstatten kann, also z.B. das Anfassen nachrüsten kann. Da das ja lokale Intelligenz ist, muss man nicht jetzt schon 20 nicht ganz triviale Touch-Signale auf einem ohnehin schon überfrachteten ATmega vorsehen. Und zuletzt: Wenn man daraus eine separate Motor-Unit macht, findet man vielleicht Leute, die bei der Bestellung mitmachen, weil sie selber eine Orgel bauen wollen, oder auch nur ein Mischpult. Gruß Ulrich
[WARNING: slightly offtopic !] @Martin Schlüter (led_martin) Ich habe mal mit einem Spezi zusammen so was Ähnliches gebaut. Für unseren Modellflugverein wollten wir mal eine Landebahnbefeuerung bauen. Aufgebaut aus einzenlen Leuchten die auf den Boden gestellt und hintereinander verkabelt wurden. Eine der Aufgabenstellungen war das in jeder Leuchte die gleiche Software läuft damit man beim Aufbau nicht großartig sortieren muss. Konzept war das von PC aus die erste Leuchte in der Kette angesprochen wurde und alle weiteren Daten von Leuchte zu Leuchte weitergereicht wurden. PC----Leuchte_1----Leuchte_2---....---Leuchte_n Es gab einen Initialisierungbefehl mit dem jede Leuchte ihre Position in der Kette ermitteln konnte, danach konnte man jede Leuchte einzeln mit RGB Daten anzusprechen. Aufgebaut war die Leuchte aus einem Atmega168er oder 328, die RS232 als Kette geschaltet wie beschrieben. Aufbau des Telegramms war 1 Byte Adresse (=Position in der Kette + MSB) + 3 Byte Farbdaten RGB (=0..127), da haben wir das auch so gelöst. Der Controller wartet auf ein Byte mit gesetztem MSB und prüft ob es seine Adresse ist. Falls ja werden 3 Byte empfangen und an die LED ausgegeben, falls nein wurde jedes Byte ungefiltet weitergesendet. Die Adressvergabe in der Kette wurde mit einem Initialisierungsbefehl gemacht. An den ersten Controller wurde 0xFF,00 (="Deine Adresse sei 00") gesendet. Der Controller hat sich die Adresse für sich selbst gemerkt, um 1 erhöht und die nächste Leuchte mit dem neuen Wert initialisiert (0xFF,01). Das ging so schnell das man die ganze Kette regelmäßig neu initialisieren konnte falls zwischendurch mal ein Bit verruscht war. Nachdem das Konzept stand haben wir 2 Prototypen und eine Kette aus Dummys aufgebaut. Als dann klar war das es funktionieren wird haben wir das Projekt wieder beerdigt, nicht zuletzt aus Kostengründen :-) Grüße aus dem Münsterland Peter
:
Bearbeitet durch User
Peter R. schrieb: > Andererseits, welches genormte Kabel mit 26 Drähten gibt es? Warum brauchst du 26 Pins für das Pedal? Kannst du das nicht genau so wie die beide Manuale mit einem Matrix (2x8 oder 4x4) abfangen? Mit einem 4-to-16 Demultiplexer reichen sogar 6 Pins! Ich würde mir an deiner Stelle das Konzept mit den Schieberegistern noch mal anschauen. Auch wenn du meinst du hast momentan genügend Pins zur Verfügung; mit weniger Pins für alle Peripherie passt vielleicht das ganze System in einem einzelnen uC.
@Ulrich P. (uprinz)
Zwei Gute Ideen von Dir, aber ich muss glaub ich erst mal was klären.
Ich werde keine teueren Motorfader kaufen, ich habe sie bereits. Das und
die Tatsache das ich billig an das Hammond Soundmodul gekommen bin hat
mich erst dazu bewogen dieses Projekt zu starten.
Einzelcontroller:
Ausgehend von Entwurf 4 mit externer Servoelektronik ist der Drawbar µC
eigentlich nur ein halbintelligenter Multiplxer/Demultiplexer. Bis auf
das generieren und abspeichern der Differenzdaten ist er nur damit
beschäftigt zu verteilen und einzusammeln. Desweiteren muss ich ohnehin
für jeden Fader eine Elektronik bauen, ob nun klein und am Fader
festgleötet oder (ggf zu mehrerer zusammengefasst) auf einer Platine mit
Verkabelung zum Fader. Dann kann ich auch direkt was bauen das sich mit
Daten ansprechen lässt und den Stellkreis beinhaltet. Zudem hab ich
hier noch rund 1m 328er rumliegen die nach passender Beschäfigung
verlangen, es muss ja nicht unbedingt ein Tiny sein.
Für die Kommunikation könnte man wieder eine UART Kette aufbauen oder
einen UART-Multiplexer (worauf ich wirklich mal Bock hätte). Das Timing
ist eher unkritisch, wenn das ganze im 100ms Takt läuft ist das völlig
ausreichend. Den großen Drawbar µC könnte man sich dann sparen, die
Steuerung würde komplett aus dem AUX µC laufen und direkt auf die Kette
der kleinen Drwabar µC zugreifen.
Entwurf 4a:
! !
| AUX µC |
+-----------------+ +-----------------+ | |
| Drawbar n |---| Drawbar µC TX |---------------->| RX |
| |---| RX |<---+ | |
+-----------------+ +-----------------+ ! ! !
. . .
| | |
+-----------------+ +-----------------+ | | |
| Drawbar 2 |---| Drawbar µC TX |----+ | |
| |---| RX |<---+ | |
+-----------------+ +-----------------+ | | |
| | |
+-----------------+ +-----------------+ | | |
| Drawbar 1 |---| Drawbar µC TX |----+ | |
| |---| RX |<---+ | |
+-----------------+ +-----------------+ | | |
| | |
+-----------------+ +-----------------+ | | |
| Schalter |---| Schalter µC TX |----+ | |
| |---| RX |<----------------| TX |
+-----------------+ +-----------------+ ! !
Je mehr ich mir das ankucke umso besser gefällt es mir. Dabei würde
wirklich mal ein universelles Motorfader Modul mit UART rauskommen das
sich noch anderswo einsetzten ließe, zB um ein Mischpult zu
automatisieren. Ich sehe schon kommen das ich den "Anpacksensor" auch
noch mit da reinbaue.
Haptisches Feedback:
Super Idee! In der orginal Hammond Orgel ist es so das die Drawbars
einen Kontaktbügel haben der auf 9 Busleitungen schleift: Die
Postitionen kann man ganz gut fühlen kann wenn man den Schleifer bewegt.
Ich könnte also den Fader ein wenig bremsen wenn er von einer Position
weg gefahren wird oder auch ein wenig anschubsen damit er leichter auf
die nächste Position rutscht. Ich weiss noch nicht genau wie der Fader
das mechanisch verträgt, aber ich halte das ma im Auge, das kann man ja
gut später noch softwaremäßig einstellen.
mit freundlichen Grüßen,
Peter
Eric B. schrieb: > Warum brauchst du 26 Pins für das Pedal? Kannst du das nicht genau so > wie die beide Manuale mit einem Matrix (2x8 oder 4x4) abfangen? > Mit einem 4-to-16 Demultiplexer reichen sogar 6 Pins! Die Überlegung war ob ich die 25 Pedaltasten kabelmäßig in die Orgel führe oder nicht. Die beste Matrix für 25 Tasten ist eine 5x5 Matrix. Damit brauche ich aber immer noch 10 Drähte. Daher der Entschluss dem Pedal einen eigene µC zu spendieren und (per RS485) an den AUX µC zu hängen. Da ich ohnehin schon einen 664er baue der eine 8x16 Matrix abfragt kann ich auf der gleichen Basis ohne allzuviel Mehraufwand auch 5x5 oder 1x25 oder eine beliebige Mischung dazwischen realisieren. Über einen ADC könnte ich noch einen Schweller (das Gaspedal einer Orgel) abfragen, es wäre sogar möglich noch ein paar Preset-Fusstaster wie bei einer Kirchenorgel zu integieren. Ich denke das ein normales Patchkabel ausreicht, das wäre wenigstens einfach zu ersetzen wenn es mal kaputt oder verschütt ginge: 1 +12V (5V ?) 2 +12V (5V ?) 3 TX+ 4 RX+ 5 RX- 6 TX- 7 Ground 8 Ground Schirm Ground > [...] mit weniger Pins für alle Peripherie passt vielleicht das > ganze System in einem einzelnen uC. Hatte ich auch schon mal überlegt. Aber im Moment sieht es für mich so aus das selbst der Atmega2560 damit überfordert wäre. Zumal ich ja noch ein paar mehr Ideen habe und das Teil ausbaufähig bleiben soll. Greetinx, Peter
Hmm... Also ich bin mir sicher, dass die RX-TX Kette als keine besonders gute Idee propagiert wurde... Aber manche Aufgabe muss man wohl erst einmal selber versuchen, bevor man denen glaubt, die es schon hinter sich haben :) Aber da einem immer irgendwann die Busse ausgehen mal folgende von Peter R. schon skizzierte Idee: Nimm für die Verkettung der Drawbars einfach SPI. Da verbindest Du MOSI immer mit MISO und alle SCKs auf eine Leitung. Dann muss eine Master-Platine (z.B. die mit MIDI, LCD, Power-Knopf, Audio PA...) für n Drawbars eben n Bytes senden mit Sollwert und erhält automatisch n bytes mit Istwert. Der große Vorteil von SPI in solch einer Konstellation ist, dass Du die empfangenen Bytes nicht umkopieren musst, da das Schieberegister Ein- und Ausgang ist. Du schiebst einfach für 9 Drawbars 9 Bytes hinein, die dann übernommen werden. Gleichzeitig schreiben dann alle 9 DBs ihren Istwert zurück und es werden wieder 9 neue Sollwerte raus geschoben. Der Master liest jedes empfangene Byte zurück. Man kann das ganze auch automatisch ausmessen, ohne die Anzahl Drabars hart zu programmieren. Da die Drawbars ja nur 9 Werte annehmen können, kann man 0xFF als Sync verwenden. Also schiebt man vom Master aus erst einmal so lange ein 0xFF durch den Bus, bis es wieder empfangen wird. Damit weiß man bescheid. Da das SPI im uC immer ein Interrupt auslöst, wenn ein Byte empfangen wurde, kann man auch da einfach mit zählen und weiß, an welcher Stelle der Verdrahtung man sitzt. Die 0xFF Marke kann man, wie Peter schon beschrieb, auch einfach drin lassen. Natürlich kann man das auch noch beliebig komplexer machen, also das Byte in Bits zerlegen und Sollwert, Sync und so weiter als Bit-Muster senden. So kann man auch prüfen, ob der Bus stabil ist. Wenn man die Bits in Einzelfunktionen aufdröselt, kann man auch Fader-Berührt hinzufügen. Auch kann man auf die Art weitere Potis hinzufügen, also eine Piezo-Manual-Auflage für (gemeinsamen) Aftertouch oder Pitchbends. Ach ja... Wenn man die Register-Bänke weiter auseinander legen möchte, dann kann man problemlos einen RS485 Tranceiver Baustein nehmen und diesen am SPI Bus Betreiben. Dabei braucht man dann einen Full-Duplex Chip für MOSI und MISO und einen fest auf RX geklemmten für SCK (am Master hängt der natürlich auf TX fest). Das obige Beispiel funktioniert aber nur deswegen als Kette, weil der SPI dafür speziell ausgelegt ist, ein einzelnes Byte durch die ganze Kette zu tragen. Datenblöcke von 2 oder mehr Bytes würden wieder Overhead bedeuten, da dann erst einmal blockweise Empfangen und erneut gesendet werden müsste. Controller mit höherer Architekturbreite, also SAM3/9 oder STM32 haben auch gerne mal 16 oder 32 bit breite SPI Register das aäre aber deutlichh overseized :) Langsam bekäme ich echt Lust zum mit basteln, aber ich habe nicht mal ein olles manual herum fliegen und der letzte Klavierunterricht ist auch 30 jahre her...
Mal was anderes... Hast Du das Projekt mal im musiker-board gepostet? Da gibt es bei den Tastendrückern sowohl ein Orgel- als auch ein Bastel-Subforum, wo auch solche Projekte besprochen werden.
Peter R. schrieb: > hat. Schließlich muss der ganze Sumps am Ende durch die > Midi Schnittstelle, und Da gab es doch jemanden hier mit einem Hochgeschwindigkeits - MIDI Protokoll. Das kann auch mehr Bits als nur 8 und damit Controller besser auflösen.
Angehängte Dateien:
-
H-Bridge_2.GIF
1,8 KB
Motoransteuerung Ich glaube ich brauche mal eure Hilfe: Die Ansteuerung der Fadermotoren soll aus einem Atmeg328(davon hab ich reichlich rumliegen) erfolgen. Ich würde 2 PWM-fähige Ausgänge nutzen und eine H-Brücke ansteuern. Aus meinen Modellbau Bastelerfahrungen (lange her) hätte ich mich jetzt für einen BAL6686 entschieden. Der ist aber wohl mittlerweile "out", man bekommt ihn nicht mehr, und er hätte den Nachteil gehabt das man damit, außer durch "Rückwärts" ansteuern, nicht bremsen kann. Also bau ich die Brücke vieleicht diskret auf. Dazu würde ich bipolare Transistoren nehmen die 1A vertragen und als H-Brücke schalten (Bild H-Brücke_2), hier und da noch ne Freilauf Diode, fertig. Schöner wäre jedoch wenn es sowas als IC gäbe, von mir aus auch mit FETs. Daher die Frage: Hat jemand ne Empfehlung zu dem Thema ? Greetinx, Peter
:
Bearbeitet durch User
Kurze Zwischenmeldung hier gibt es eine H-Brücken Übersicht: https://www.mikrocontroller.net/articles/H-Br%C3%BCcken_%C3%9Cbersicht Ich glaube ein L6202 ist für mich das richtige. Greetinx, Peter
Aktueller Stand
Nach dem ich mir noch das ein oder andere Detail überlegt habe ist dies
nun der aktuelle Stand.
Upper und Lower Manual hängen an je einem Scan µC um eine möglichst hohe
zeitliche Auflösung zu erreichen. Das Pedal hängt zusammen mit dem
Schweller, der eine analoge Spannung erzeugt, und ggf einigen Fusstaster
für den Abruf von Presets an einem (mehr oder weniger baugleichen)
Scanner der im Pedalgehäuse sitzt. Die Verbindung zum Aux µC geschieht
über RS485, zunächt einmal unidirektional. Wenn ich mir den Spass
erlaube im Pedalgehäuse eine Anzeige zu integrieren dann auch
bidirektional, an sonsten ist die TX Leitung seitens des Aux µC frei.
Die Drawbars erhalten je Motorfader einen eigenen Controller der über
UART ansprechbar ist. Mit erstaunlich wenig Hardware
(www.mikrocontroller.net/topic/25045) lässt sich darin sogar der
"Anpacksensor" realisieren. Damit stellt der Drawbar µC eine
wiederverwendbare Einheit dar.
Alle weiteren Schalter (Reverb, Vibrato, Percussion etc) hängen direkt
am Aux µC. Ebenfalls direkt am Aux µC hängt das Diplay (wenn es eins
gibt), das Keypad zum Abrufen und Speichern von Presets, die
Schnittstelle zur Mem Karte und die Midischnittstelle(n).
Entwurf 5:
+-----------------+ +------------+ +-----------+
| µC Upper Manual |<------8x Col------| µC TX |----->| RX |
| |-------8x Row----->| Scan | | |
+-----------------+ | (644) | | |
| | | |
+-----------------+ | | | µC Aux |
| µC Lower Manual |<------8x Col------| | | (2650) |
| |-------8x Row----->| | | |
+-----------------+ +------------+ | |
| |
| |
| |
+-----------------+ +------------+ | |
| Pedal |---| µC TX |--------------------->| RX |
| 25x Konatkt | | Scan (RX |<---------------------| TX) |
+-----------------+ | (644) | | |
| | | |
+-----------------+ | | | |
| Schweller |---| | | |
| 1x Spannung | | | | |
+-----------------+ | | | |
| | | |
+-----------------+ | | | |
| Presets |---| | | |
| n Kontakte | | | | |
+-----------------+ +------------+ | |
| |
| |
| |
+-----------------+ +-----------------+ | |
| Drawbar 1 |---| Drawbar µC TX |---------------->| RX |
| 1x Motorfader |---| (328/168) RX |<---+ | |
+-----------------+ +-----------------+ | | |
| | |
+-----------------+ +-----------------+ | | |
| Drawbar 2 |---| Drawbar µC TX |----+ | |
| 1x Motorfader |---| (328/168) RX |<---+ | |
+-----------------+ +-----------------+ ! ! !
. . . .
. | | |
+-----------------+ +-----------------+ | | |
| Drawbar 20 |---| Drawbar µC TX |----+ | |
| 1x Motorfader |---| (328/168) RX |<----------------| TX |
+-----------------+ +-----------------+ | |
| |
| |
| |
+-----------------+ | |
| Schalter |-------------------------------------->| |
| ca 10 Kontakte | | |
+-----------------+ | |
| |
+-----------------+ | |
| Keypad |-------------------------------------->| |
| n Kontakte | | |
+-----------------+ | |
| |
+-----------------+ | |
| | | |
| Display |<-------------8/4Bit + E + RS----------| |
| | | |
+-----------------+ | |
| |
+-----------------+ | Midi |
| | | |
| Mem Card |<--------------------?---------------->| |
| | | T T R |
+-----------------+ | X X X |
+-----------+
| | ^
Aux MIDI Out <---------------------------------------------+ | |
| |
| |
+--------------------------+ | |
| | | |
| Hammond MX1 Midi In +<----------+ |
Audio Out <---------| Midi Expander | |
| Midi out +-----------+ |
| | | |
+--------------------------+ | |
| |
V |
Midi Midi
out in
Erste Baustelle wir der Scan µC sein. Der Aufbau wird so sein das er je
nach Bestückung die Manuale oder das Pedal versorgt. Testweiese wird er
direkt die Midi Schnittslle bedienen, so lässt sich schon mal ne ganze
Menge entwickeln und testen.
Greetinx,
Peter
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.