Ich brauche einen 88x2 Eingang und Ausgang = 360 Leitungen für einen Microprozessor und möchte auf fertige Module zurückgreifen. Ich denke da an einen Port-Expander mit Logikbausteinen wie PLDs. Gefunden habe ich auch welche, es braucht aber mehrere parallel. Ich gehe von 4 Modulen aus.
Die Module sind per JTAG programmierbar. Jedes hat seinen eigenen Flash-Baustein und seinen eigenen Stecker.
Frage: Kriegt man die irgendwie verschaltet, daß es möglich ist, sie mit einem Kabel ohne Umzustecken zu programmieren?
(Etwas Leitenbahnkratzen und Umlöten an den Modulen wäre i.O.)
Das Ziel wäre alle 4 Module und ihre Flashes in einer chain. Oder wenigstens jeweils 2?
Ich brauche einen 88x2 Eingang und Ausgang = 360 Leitungen für einen
Microprozessor
Wie schnell müssen die Eingänge und Ausgänge aktualisiert werden können? Und wofür brauchst du denn diese 360 EA? Müssen die tatsächlich alle auf 1 zebntralen Punkt gesammelt sein? Oder brauchst du die EA auf einen größeren Raum verteilt?
Ich denke da an einen Port-Expander mit Logikbausteinen wie PLDs
Ja, aber wozu brauchst du dann JTAG und eine Funktion zum "Umprogrammieren" der Bausteine? Die PLDs/FPGAs programmiert einmal mit der nötigen EA-Funktion und danach werden sie nur noch vom Prozessor per UART/I2C/SPI oder über einen parallelen Port angesteuert.
Warum?
I²C Port Expander, SPI Port Expander, Serielle Shift Register mit Parallel out am SPI.
Es gibt zahllose Möglichkeiten bei denen die MCU kaum mehr als 2-3 Pins braucht.
Der TO braucht das wohl fuer seinen Farfisa Klangkadaver.
Wenn die Pegel passen, kaemen fuer die Eingaenge 74HC165
und fuer etwaige Ausgaenge 74HC595 in Frage.
Kaskadiert natuerlich. :)
Der TO braucht das wohl fuer seinen Farfisa Klangkadaver.
Wenn die Pegel passen, kaemen fuer die Eingaenge 74HC165
und fuer etwaige Ausgaenge 74HC595 in Frage.
Kaskadiert natuerlich. :)
Eher so was, wäre auch deutlich billiger, aber ist ein IC ein Fertigbaustein im Sinne des Fragenden ?
Naja, schon an der Fragestellung des TO sieht man, dass er
(noch?) ueberhaupt keinen Plan hat. Vermutlich kennt er noch
nicht mal die "vorherrschenden" Logikpegel. Womoeglich ist das
alles noch in pMOS. :)
Er soll erstmal Fotos, Oszillogramme, etc. herausruecken.
Verher ist es sinnarm sich ueberhaupt Gedanken zu machen.
Wenn die Pegel passen, kaemen fuer die Eingaenge 74HC165
und fuer etwaige Ausgaenge 74HC595 in Frage.
Kaskadiert natuerlich. :)
Wurde überlegt, nein. Ich will keine Baugruppe aufbauen sondern die Funktion kompakt haben. Die Module haben den benötigten 3,3V-Logikpegel zum Ansteuern der Analogschaltergruppen.
Es geht wirklich um die Frage, wie das verschaltet werden muss/kann, damit ich an einem Programmieradapter alle diese Module sehe. Im Grunde reichen die Flashes.
Aha. Wieder ein Puzzleteil mehr.
Noch reicht es aber nicht fuer das gesamte Bild.
Es bleibt also weiterhin spannend.
sondern die Funktion kompakt haben
Allerdings dann mit einem "Zopf" an dem 360 IOs haengen.
Das sind, wer sowas schon mal gesehen hat, fast 4 Kabel mit 100 DA.
Aber wenn es so Spass macht. :)
Und wenn deine Schaetzung richtig ist. Es koennten auch
noch ganzzahlige Vielfache von 360 werden.
Du darfst mir zutrauen, dass ich entscheiden kann, was ich benötige. :-)
Ich frage wohl am besten der Hersteller direkt.
Das wird wohl zweifellos das Allerbeste sein.
Die werden sich geradezu darum reissen, dir ihre "Module" zu verkaufen.
Du solltest dann auch gleich einen Betrag fuer "Support" einplanen.
Deren Geduld ist naemlich auch endlich, und erschoepft sich dann bei
Fragen recht schnell. Fuer Supportfragen ist naemlich der Hersteller
zustaendig, und nicht das Forum hier.
Tu das. Und ein Tipp: denk dir eine Stückzahl mit vielen Nullen aus...
Ich habe schon geschrieben, wie das im echten Leben geht: msch ribe HDL-Beschreibung, die dir aus dem FPGA diesen Portexpander mit SPI Schnittstelle macht. Mit sehr hoher Wahrscheinlichkeit rät dir das auch der FAE.
Es ist absurd, zu versuchen, für die "Entwicklung" diese Bausteine als
riesige Portexpander verwenden zu wollen.
Nach so vielen Jahren hier kannst Du Dich über sowas noch ärgern?
Klar ist das absurd.
SPI, Shiftregister mit Parallelausgang, Miso, Mosi, Clk, Output Enable und die MCU hätte fast garnichts zu tun.
180bit schreiben, zeitgleich einlesen u.U. per DMA, dann kann die MCU die meiste Zeit im Tiefschlaf verbringen.
Aber man kann natürlich auch 14 Raspis programieren und per Wlan Daten auf ihren 26 IOs verteilen oder ein FPGA KI Portexpander bauen.
Macht einfach mehr her, als ein paar popelige shift Register und eine sich langweilende 8bit MCU im SO8.
Aber:
Manni T. schrieb im Beitrag #7464716:
Du darfst mir zutrauen, dass ich entscheiden kann, was ich benötige. :-)
Dort steht aber nicht drin, wie man die IO-Pins der FPGAs/CPLDs einlesen
oder ansteuern kann.
Davon schrub ich ja auch nichts. Aber man kann ja mit Sgnaltap/Chipscope
sich behelfen.
Es ist absurd, zu versuchen, für die "Entwicklung" diese Bausteine als
riesige Portexpander verwenden zu wollen.
Vermutlich soll es ein "distributed LA/Debugger" werden. :)
Anscheinend durchschaut der TO die zugrundeliegende Logik der
benötigten 3,3V-Logikpegel
zum Ansteuern der Analogschaltergruppen
doch noch nicht zur Gaenze. Das erste was seltsam ist, sind 3.3 V
Logikpegel in einem "alten" Instrument. Und wie man im parallelen
Thread nachlesen kann, dass bereits "gefilterte" Signale geschaltet
werden. Aber der TO weiss ja nach eigenem Bekunden was er tut. :)
Er sollte vielleicht besser ein paar Jahre Klavierstunden nehmen
statt das Instrument zu verhunzen.
Ich habe schon geschrieben, wie das im echten Leben geht: msch ribe
HDL-Beschreibung, die dir aus dem FPGA diesen Portexpander mit SPI
Schnittstelle macht.
Ich sagte ja schon: mit JTAG und Boundary Scan ist es ein ungeschickter und unheimlich umständlicher Plan.
Denn kein anderes Interface ist einfacher anzusteuern als SPI, weil SPI kein Protokoll hat und einfach nur gekoppelte Schieberegister verwendet. Da wird kein großartiger Automat zur Verwaltung der Kommunikation gebraucht.
Wenn dein Plan ist, lediglich für die Entwicklung des HDL Designs die JTAG-Chain aufzubauen, dann ist auch das unnötig. Ich würde hier 1 Modul mit 90 EA entwickeln und wenn das funktioniert in die anderen 3 Module die selbe Konfiguration einprogrammieren.
Es gab hier ja schon viele Freds, in denen die Nutzung einer
vorhandenen Klaviatur diskutiert wurde. Ueber Ergebnisse hat
man immer reicht wenig gehoert. Auch 90 I(O(s wollen erstmal
mit dem "Erzeuger" verbunden werden.
Und das geht am "kabelsparsamsten" immer noch mit kaskadierten
Schieberegistern. Da reicht es Daten und Takt von Schieberegister
(modul) zu Schieberegister(modul) durchzureichen, und die
Anschluesse an die Klaviatur kurz zu halten.
88 Tasten sind bei einem Klavier Standard, und belegen die
volle Breite des Instruments. :)
Diese 88 Leitungen sind ja gleichzeitig auch 88 Antennen
die sich Dinge aller Art einfangen koennen. Man muesste also
scho abgeschirmtes Kabel verwenden.
Um "Auslesen" und "Ansteuern" zu testen, reichen eigentlich
2 popelige Schieberegister. Schon ein Modul waere
Verschwendung.
Der Ansatz die IOs mit JTAG :) auszulesen und anzusteuern,
wird ja (deutlich) erkennbar nichts werden. Dafuer ist die
Faktenlage ueber die JTAG-Internas viel zu prekaer.
Aber soll er mal machen. :)
Weitere Ratschlaege werde ich wohl nicht mehr geben.
Dafuer traegt mir der TO seine Nase zu hoch.
Es gab hier ja schon viele Freds, in denen die Nutzung einer
vorhandenen Klaviatur diskutiert wurde. Ueber Ergebnisse hat
man immer reicht wenig gehoert.
Ich midifiziere gern mal ein Orgelvollpedal (grade stehen wieder 2 recht brauchbare hier herum). Das kann ein AVR mit ein paar Schieberegistern tadellos erledigen. Der Witz an den Schieberegistern ist, dass jedes nur 8 Eingänge hat und so die Hardware recht fein granuliert werden kann. Ich bringe also die Elektronik an die Kontakte und eben nicht den Kontakt über einen dicken Kabelbaum zur Elektronik.
"Dafuer traegt mir der TO seine Nase zu hoch."
LOL, was soll den do ein Kommentar, dann klemm dir deine komplette Antwort doch gleich.
Das gleiche kann man nämlich auch über dich sagen, fällt dir aber offenbar nicht mal auf
Ich habe mal bei einem echten Roland E-Piano nachgeruestet.
Das hatte ein "balanced Keyboard". Per Taste waren es
2 Hallschaltkreise (B461?) und 1 Magnet. Auch die liessen sich
natuerlich am einfachsten per Schieberegister "einsammeln".
Ganz ohne Eingriff in die Elektronik des Instruments.
Nir die Justierung war etwas muehselig.
Dir ist scheinbar noch nicht aufgefallen, dass es vom TO
nicht mal die Andeutung einer Aussage wozu das Ganze gut
sein soll, gibt. Statt dessen gibt es "Geschwafel":
Wurde überlegt, nein. Ich will keine Baugruppe aufbauen
Ich kann im uebrigen meine Nase so hoch tragen wie ich will.
Das muss Mann sich aber auch leisten koennen.
Edith:
Max M. (max_mueller)
Wenn du weiter nichts inhaltlich beizutragen hast, solltest
du einfech dein
halten.
Nachdem das dann zur allerseitigen Zufriedenheit diskutiert wurde: bitte zurück zum Thema. Und wenn zur Höhe der Nase noch was unklar ist: klärt das per PN.
Ich midifiziere gern mal ein Orgelvollpedal (grade stehen wieder 2 recht
brauchbare hier herum). Das kann ein AVR mit ein paar Schieberegistern
Diese Schieberegister laufen typisch mit 10 MHz, wenn man sie sicher betreiben will. Auf der langen Strecke, geht das gerade mit 1MHz. Das entspricht einer update-Rate von gerade 10kHz. Das geht nur für Pedale, wenn maximal 2 getreten werden. Nutzt man alle Finger, müssten in diesem Paket 8 Werte ausgewertet und gesendet werden. Man bekommt dann keine echte Gleichzeitigkeit mehr, wenn diese über 2 Pakete verteilt werden.
Im PLD kann man voll parallel arbeiten und nur die weiterreichen, die auch gedrückt sind. Das ist ein Entscheidungsbaum mit 7 Stufen = maximal 1/10 der Tatkfrequenz. Ein einfaches 10MHz PLD reagiert also mit 1MHz.
Wie man JTAG-Chains aufbaut, findet man in den Usermanuals der PLDs.
Die musst "nur" lesen (und verstehen).
Dort steht aber nicht drin, wie man per Boundary Scan via JTAG Interface
die IO-Pins der FPGAs/CPLDs einlesen oder ansteuern kann.
Die PLD-Bausteine sollen noch mehr tun, als nur Schalten und MIDI interpretieren. Die PLDs sind gesetzt.
Es geht nun wirklich um die Eingangsfrage, ob ich die JTAGs einfach Außen irgendwie verschalten kann, so wie sie geliefert werden, oder ob ich das Umlöten muss oder kann.
Verwendet man geeignete Verkabelung und differentielle Übertragung, sind auch andere Datenraten möglich, und das auch über Strecken, die ganz erheblich länger sind als so eine Tastatur breit ist.
Auf den sehr kurzen Strecken in Deinem Keyboard ist größerer Aufriss mit Schirmung etc. nicht erforderlich. Ja, das sind sehr kurze Strecken, lang wären Entfernungen > 10m. Und wenn Du übergründlich sein willst, dann nimmst Du halt geschirmte Kabel. Die gibts kostengünstig fertig konfektioniert mit Steckverbindern an beiden Enden -- als Ethernet-Kabel.
Du suchst Dir Probleme, die einfach nicht existieren.
Ein voellig obsoletes 74AC165 schafft bei 5 V auch Minimum 100 MHz.
Das ist kein differentieller Leitungstreiber. Aber in Kombination mit einem (noch etwas besseren als dem von mir rausgesuchten) sicher gut einzusetzen.
Aber hey, PLDs mit JTAG-Chain klingt natülich viel mächtiger und ist "gesetzt". Für ein von Menschen bedientes Gerät, das, auch wenn es ein Eingabegerät für ein Musikinstrument ist, nur sehr endliche Ansprüche an zeitliche Auflösung hat.
Wenn man sich das Leben unnötig schwer machen und solche HF-Probleme einfangen will. Bei mir laufen die Schieberegister wesentlich langsamer im 10kHz Bereich. Das reicht ja locker aus, schneller kann keiner die Tasten drücken oder das entsprechende Midi Kommando gesendet werden.
Merke: so schnell wie nötig und so langsam wie möglich.
Das entspricht einer update-Rate von gerade 10kHz. Das geht nur für
Pedale, wenn maximal 2 getreten werden.
Überleg dir das nochmal. Du hast da ganz grundlegende Verständnisprobleme.
Und denk auch drüber nach, wie oft pro Sekunde jemand eine Taste drücken und loslassen kann und wie schnell die entsprechende Mechanik ist. Ich denke, schneller als 20 mal pro Sekunde schafft das nicht mal ein Profizitterer. Und du willst das gut 5000 mal schneller abtasten? Warum?
Mit meinen obigen 10kHz Schiebetakt kann ich zur Zufriedenheit aller Organisten alle(!!) 40 Taster und Kontakte des Pedals gut 250 mal pro Sekunde einlesen.
Normalerweise bin ich der, der sagt "nimm ein FPGA". Aber eben nur dort, wo ein uC überfordert ist. Ich kenne FPGAs (such einfach mal mit Google nsch meinem Namen) und weiß, dass eine steile und anspruchsvolle Lernkurve vor dir liegt. Du wirst viel lernen (müssen).
Die PLD-Bausteine sollen noch mehr tun, als nur Schalten und MIDI
interpretieren.
Dann fang klein an und wünsche dir nicht zu viel in das FPGA rein.
Wenn man nicht vorhat, meterweise Kabel damit zu treiben, reicht
eine auf beiden Seiten seriell terminierte verdrillte Doppelader.
Also z.B. die 20 cm zwischen zwei Baugruppen.
Fuer die Terminierung kann man entweder auf Erfahrungswerte
zurueckgreifen oder man muss messen.
Ground muss man natuerlich nicht seriell terminieren. :)
Ausserdem reicht es, Ground nur einseitig anzuschliessen.
Das Ganze gehoert natuerlich in ein geschirmtes Gehaeuse.
wie oft pro Sekunde jemand eine Taste drücken
und loslassen kann und wie schnell die entsprechende Mechanik ist.
Das Thema hatten wir schon mehrfach. Es kommt am Ende auf die Genauigkeit an, mit der erfasst wird. Verzögerungen durch Mechanik und Elektronik (teilweise sogar Klangerzeugung) wird von den Musikern oft unbewusst vorkompensiert. Aus meiner Sicht müsste die Erfassungsgenauigkeit immer eine 10er-Potenz besser sein, als die Ungenauigkeiten durch den Abspieler.
Dazu hatte ich vor Jahren einst Untersuchungen bei Pianisten gemacht, wie genau diese die Tasten führen und Tonfolgen reproduzieren. Im Gegensatz zu Hobbymusikern tun die das erstaunlich genau! Ich bin auf eine minimale Abtastrate von 10kHz gekommen, um den Verlauf der Tasten so genau abbilden zu können, dass die Abtastung an sich keine musikalisch wirksamen Fehler erzeugt.
In der Größenordnung oder nicht viel schlechter bewegen sich auch die heutigen Keyboard-Schaltungen:
Der Hersteller, der diese aufklebbaren XY-Tasten für Klaviere vertreibt (touchkeys) arbeitet laut eigener Aussage mit 5kHz. Der muss sogar virtuell analoge Werte transportieren und nicht nur ein "An-Aus-Bit". Von einem Mitbewerber eines meiner Kunden habe ich gemessene Werte von über 20kHz.
Taster und Kontakte dwa Pedals gut 250 mal pro
Sekunde einkesen.
Das finde ich jetzt allerdings etwas knapp! Bis zu 4ms Jitter bei einer Latenz von MIDI um 1ms ist eigentlich unnötig. Was ist der Grund, nur 10kHz Takt zu verwenden?
Ein voellig obsoletes 74AC165 schafft bei 5 V auch Minimum 100 MHz.
Entweder hast du eine Null zuviel, oder die neueren scheinen langsamer geworden zu sein. Laut Datenblatt schafft meins von TI 20MHz, das von Reneasas 25MHz, laufen aber nur bei 3.3V :-)
Ist aber nicht zwingend ein Hinternis:
Wenn die Abtastrate für alle Schieberegister nicht reicht, kann man mehrere parallele Ketten benutzen. Einige Keyboards deren digitale Funktion ich kenne, machen das so: Die Abtastung erfolgt mit z.B. 400kHz (I2C) vergleichsweise langsam, erstreckt sich aber nur auf eine Tastergruppe mit 11/12 Tönen. Die ASICs mit denen das getrieben wird, haben eben eine ausreichende Anzahl an I2C-Ausgängen.
Mit einem Micocontroller lässt sich das auch leicht manuell aufbauen: Alle Schieberegister bekommen den gleichen Takt und man liest 2 oder 3 8-Bit-Ports ein. Der Rest ist Datendrehung. Sollte den µC nicht sonderlich belasten.
Du musst auch den Rest der Tabelle posten und die nachfolgenden Zeilen interpretieren. Als Einzelbaustein geht das natürlich schneller. Aber nicht in der Kaskade. Die Ausgänge müssen zudem auch geschaltet werden und nicht nur die Information intern weitergetaktet werden.
Wie gesagt: da geht es um ein Orgelpedal. Da sind schon die Betätigungswege im Original recht undefiniert und schwammig.
Und wie gesagt: es hat sich noch keiner beschwert.
Natürlich kann man das auch 10 oder 20 mal schneller machen, aber dann muss eben auch der Rest (Mechanik und Klsngerzeugung) dazu passen. Und ein Klavier ist da schon einiges agiler unterwegs als eine Orgel, wo Latenzen im ms-Bereich allein durch die unterschiedlichen Pfeifenabstände zum Hörer auftreten.
programmer.jpg
(34 KB)
