Hallo liebes Forum, dies ist mein erster Artikel auf dieser Plattform und ich möchte mich erstmal vorstellen: ich heiße Andreas, lebe in Langenfeld (Rheinland) und bin 50 Jahre alt. Beruflich habe ich mit Einbruch- und Brandmeldezentralen zu tun. Das Hobby Elektronik pflege ich seit ich denken kann...das andere Steckenpferd ist Orgelspiel - und da beginnt dieser Beitrag: Ich habe aktuell eine 4-manualige Hauptwerk Samplingorgel im Bau. Zum Verarbeiten der Registerschalter und Anzeigen und zum Speichern von Registrierungen (Setzerspeicher) soll ein kleiner Z80 Rechenknecht mit nichtflüchtigem NVRAM dienen. Jetzt kommt das Problem: im Orgelgehäuse sind zum Anschluss roundabout 120 Eingabeschalter (Digitast mit LED) räumlich verteilt, deren Zustände über viele I/O Bausteine (in: 74244/ out:74373) am Datenbus des Z80 angeschlossen sind. Es werden also mehrere einzelne Platinen mit I/O Bausteinen, Entprellschaltungen, Flipflops und LED-Treibern am Datenbus und paar Steuerleitungen I/O-Adressdekodierung kaskadiert. Der Datenbus kann auf diese Weise vom Prozessor bis zum letzten I/O Baustein bis einen Meter lang werden... Kann das bei einer 4MHz CPU zum Problem werden? Geschwindigkeit ist bei diesem Projekt Nebensache... Es wäre schön, wenn ich vom Forum einen Tipp zum Thema bekäme Gruß Andreas
Andreas S. schrieb: > bis einen Meter lang werden... > Kann das bei einer 4MHz CPU zum Problem werden? Die erste Frage die sich mir stellt ist: Warum muß es dafür unbedingt ein Z80 sein?
Moin, Andreas S. schrieb: > Kann das bei einer 4MHz CPU zum Problem werden? Ja, natuerlich. Solche Prozessorbusse sind nicht fuer grosse raeumliche Ausdehnungen gedacht. Beim ZX81 hats gereicht, an 2 Datenleitungen 30cm Flachbandkabel zu loeten, und schon ging nix mehr...OK, der hatte auch die el-cheapo-Busuebersteuerung mit Serienwiderstaenden eingebaut. Trotzdem: bei vielen IO Signalen sollte man auf jeden Fall die Schnittstellenbausteine nah' am Prozessor gruppieren und die Leitungen zu den Schaltern/Verbrauchern laenger machen. Und auch dann hab' ich meine Zweifel, ob so ein Haufen 74xx an einem Bus gut funktioniert. Gruss WK
Da es ja elektronische Orgeln gibt, die sowas können, sollte es Wege geben, um so einen Bus aufzubauen. Aber mehrere grosse Probleme treten da schon auf. Für das alte Z80 Dings wirst du kräftige Bustreiber brauchen, eine saubere Verharfung mit dazwischengelegter Masse und viele, viele Vorkehrungen gegen EMI, die dein Apparat sonst ausstrahlt. Buslängen von einem Meter sollte man ohne besondere Buffer und Filter nicht mit 4MHz fahren, vor allem, wenn man so etwas noch nie gemacht hat.
Moin WK, weil der Schaltungsaufwand minimal ist und ich glaube, dass ich den Code dafür verstehe und die Schaltung ans Laufen bringe... Gruß vom schweiky
schweiky schrieb: > weil der Schaltungsaufwand minimal ist und ich glaube, dass ich die > Schaltung ans Laufen bringe... Ich fürchte dann hättest Du hier auch keine Frage gestellt... Ob 1 Meter Datenbus zu Problemen führt dürfte hier und heute ohne Kenntn is der Umstände nicht so einfach zu beantworten sein. Aber Gnade Dir Gott wenn es zu Problemen kommt- da möchte ich nicht der sein der der auf Fehlersuche gehen muß. Statt dessen würde ich von vornherein auf eine überschaubare modernere Lösung setzen die HF-Problemstellungen von vornherein aus dem Wege geht.
Hallo, der gute alte Z80... Bustreiber auf CPU-Seite und am anderen Ende. 74244 und 74373 könnten das schon stabil schaffen. Die aktuellen Versionen (HC/HCT) machen da eher Probleme, die sind zu schnell mit den Flanken. In den alten Bussystemen war man von 1m auf Backplane und Leiterkarten nicht soweit entfernt. Gruß aus Berlin Michael
:
Bearbeitet durch User
schweiky schrieb: > weil der Schaltungsaufwand minimal ist Nun, wo der Z80 mindestens drei grosse Zusatz-ICs und jede Menge Hühnerfutter braucht, um zu laufen, hat ein moderner Mikroprozessor alles in einem Gehäuse. > und ich glaube, dass ich den Code dafür verstehe Nun, soviel schwieriger ist die Assemblersprache moderner µCs auch nicht. Schau Dir doch mal das Tutorial auf den µC.net- Seiten an. Falls Du beruflich mit C arbeitest, kannst Du das auch mit µCs verwenden.Bei Deinen Einbruch- und Brandmelde- zentralen musst Du doch auch jede Menge Schalter auswerten. Wenn Du da die möglicherweise dort verwendete Schaltungs- technik kennst, kannst Du die ja vielleuicht auch für Deine Orgel verwenden. > und die Schaltung ans Laufen bringe... 74er-ICs sind von vornherein problematischer, weil sie wesentlich störempfindlicher als CMOS-ICs sind. Natürlich brauchst Du Zusatz- ICs zur Auswertung Deiner vielen Schalter. Aber auch da gibt es modernere Lösungen, z.B. I2C-Bus
:
Bearbeitet durch User
Michael U. schrieb: > In den alten Bussystemen war man von 1m auf Backplane und Leiterkarten > nicht soweit entfernt. Wenn man nur EINEN Bus hat, reicht auch ein Fehler um ihn lahmzulegen. Warum hat sonst die Tastatur eine eigene CPU und liefert nur ein Teil davon zur zentralen Verarbeitung? Wahrscheinlich wäre es für Andreas sinnvoller einzelne Aufgaben dezental zu erledigen und nur Ergebnisse über Peripheriebausteine wie PIOs CPU-nah zu verarbeiten. Damit verkürzt sich die echte CPU-Buslänge auf einige cm. Jedenfalls haben mir Verlängerungsadapter mit langem Kabel meist nur Ärger eingebracht obwohl sie aus Ohmscher Sicht total in Ordnung waren. Signallaufzeit, Masseprobleme und Busterminierung sollte man nicht unterbewerten.
Was davon existiert schon? Bzw., was davon ist nur Plan? Um 120 verteilte Taster abzufragen, die ja sicher in Gruppen angebracht sind, würde ich diese an Schieberegister Parallel->Seriell hängen und diese von einem 3€ China-Arduino-nano-Clone Auslesen lassen. Die Entprellung macht der aus Langeweile gleich mit, in seinem EEProm kann der sich die Zustände der Orgelregister leicht merken und der hat grob die Größe eines Z80, etwa DIL34. Die "Rückmelde"-LEDs bekommen auch Scieberegister, nur eben Seriell->Parallel. AVR-Tutorial: Schieberegister Per SPI kann man damit die 120 Taster in unter 20μs einlesen und gleichzeitig die LED ausgeben. Für die Dannegger Entprellung braucht man alle 5..20ms neue Daten, es bleibt also noch viel Luft.
Michael U. schrieb: > In den alten Bussystemen war man von 1m auf Backplane und Leiterkarten > nicht soweit entfernt. Ich habe jahrzehntelang Z80-Systeme im 19-Zoll-Einschub verkauft, etwa 50 cm davon für Einsteckkarten mit Z80 Bus, da gab es nie Probleme. Allerdings: da gab es Treiber (LS245 usw., 4 ICs) und der Bus wurde nur für I/O verwendet, kein Memory, DMA und so Zeugs, aber I/O-Messwertkarten, Schrittmotortreiber usw. ist ja auch das was man braucht. Alternativ gab es Rückwände mit Siemens-SMP-Bus, und ein Kunde hat sich für meine CPU-Karten welche mit ECB-Bus konstruiert, hat auch alles problemlos funktioniert, auch gemischt. Das Bus-Knowhow scheint heute völlig verlorengegangen zu sein, sieht man auch an manchen Kommentaren hier. Georg
Hallo, ich stimme Dir ja zu, die eigentlich Frage hat Carl Drexler (jcw2) ja nach mit gestellt: >Was davon existiert schon? Bzw., was davon ist nur Plan? Wenn es bisher nur Plan ist, hat er auch recht. Billige Arduino-Nano. Falls ein Zwischenweg günstiger wäre: ein Nano und ein paar MCP23S17 schaffen zusätzliche Ein- und Ausgänge. Zur Geschwindigkeit: der Mensch kann verdammt sensible Ohren haben, wenn ein Ton zu spät einsetzt und "zu spät" ist weniger als man oft meint. Gruß aus Berlin Michael
Harald W. schrieb: > schweiky schrieb: > >> weil der Schaltungsaufwand minimal ist > > Nun, wo der Z80 mindestens drei grosse Zusatz-ICs und > jede Menge Hühnerfutter braucht, um zu laufen, hat ein > moderner Mikroprozessor alles in einem Gehäuse. > >> und ich glaube, dass ich den Code dafür verstehe Es gibt ja auch moderne Z80-CPUs. http://www.zilog.com/index.php?option=com_product&Itemid=26&task=parts&BL=1&familyId=119&productId=EZ80L92 Da ist die Peripherie auch gleich mit drin, JTAG/ZDI zum debuggen auch, und Du musst nur noch Speicher anschließen. Läuft bis 50 MHz und kann linear 16GB adressieren.
Frank K. schrieb: > Es gibt ja auch moderne Z80-CPUs. eZ80 habe ich auch als Next Generation verwendet, der hat den Vorteil, einen weitgehend Z80-kompatiblen Bus zu haben und auch einen kompatiblen Software-Modus. Fürs Basteln ist bloss schlecht, dass er im TQFP-Gehäuse ist. Aber ein Chip mit vollständigem Bus UND jeder Menge I/O braucht halt seine 100 Pins, und die gibt es nicht als DIP. Wenn man das so lieber hat, kann man den eZ80 als einzigen SMD-Chip einsetzen und alles andere konventionell, ev. auch den eZ80 auf Adapter und sonst Lochraster. Die Unterstützung durch die IDE ist auch i.O., für ein altes Z80-System gibt es nichts Vergleichbares, da geht das noch mit Makefiles zu Fuss assemblieren - compilieren - linken und dann Eproms/Flashs programmieren. Aber wir sind so früher ja auch ans Ziel gekommen. Georg
> Zur Geschwindigkeit: der Mensch kann verdammt sensible Ohren haben, > wenn ein Ton zu spät einsetzt und "zu spät" ist weniger als man oft > meint. Es soll sich um die Orgel-Register handeln und nicht um die Manuale. BTW, bei einer echten Kircheorgel muß man "im Voraus" spielen, denn es dauert gefühlte Ewigkeiten, bis ein "angeschlagener" Ton erklingt. Aber wie geschrieben: Register, das sind die Holzknubbel rund um den Spieltisch, die die "Klangfarben" festlegen.
Servus, den minimalsten Schaltungsaufwand und günstigsten Bauteilepreis erhält man sicher mit einer dezentralen Lösung, bei der mehrere bis viele, kleine Mikrocontroller die Ansteuerung der LEDs und Abfrage der Tasten (z.B. in Gruppen zu je 16 oder ähnliches) übernehmen. Außer den Controllern, ein paar Widerständen und evtl. noch Entkopplungsdioden braucht man keine weiteren ICs. Alle kommunizieren über einen Bus (z.B. I2C) mit der zentralen Steuer-CPU und auf allem µC läuft das gleiche Programm, nur erhält jeder Controller eine eigene ID. Oder die ID wird durch eine serielle Verschaltung der Module durch die Hardware automatisch festgelegt. Die EMV-Probleme, die man sich einfängt, wenn man direkt den CPU-Bus auf das gesamte Bedienpanel verteilt, mag ich mir gar nicht vorstellen...
:
Bearbeitet durch User
Hallo liebes Forum, danke für die rege Beteiligung - da kommt ja schon einiges an "Futter" zusammen. Es kristallisiert sich heraus, dass eine vernünftige Lösung mit einem der aktuellen Minis (Raspberry/Arduino & Co.) gegeben ist. Daran ein 2-Draht Datenbus (I2C,CAN,RS485) mit Interface-Bausteinen, welche parallele Ein- und Ausgaben ermöglichen. Idealerweise ein IC, an welches man nur den Bus und Spannungsversorgung anschließt, mit Mäuseklavier für die Busadresse und das mindestens 8 Bit parallel ein- oder ausgeben kann. Diese Sorte Käfer könnte man dann schön gemütlich hintereinander- bzw. parallelschalten. Damit keine Mißverständnisse entstehen: die Abfrage der Klaviaturen und des Pedals erfolgt mit speziellen Interfacebaugruppen, die an einer MIDI Schnittstelle gruppiert sind. Es geht bei meiner Anfrage wirklich nur um die 0V oder 5V Potenziale der "Knöppe und Lampen". Gruß vom schweiky
schweiky schrieb: > aktuellen Minis (Raspberry/Arduino & Co.) Das was du da so locker mit einem "/" trennst, sind grundlegend verschiedene Dinge, alleine schon vom Betriebssystem.
Andreas S. schrieb: > Ich habe aktuell eine 4-manualige Hauptwerk Samplingorgel im Bau. Ähem... Hauptwerk? DAS Projekt (www.hauptwerk.com), wo schon vor Jahren begonnen wurde, Orgeln aufzunehmen und deren Klang als Samples zu speichern? Wow! Also die Idee mit dem Z80 finde ich nicht wirklich gut. Guck dir lieber einen Mikro-Controller dafür aus. Heutzutage laufen die mit Taktraten jenseits von 20 MHz und stören dennoch nicht, weil alle schnellen Aktivitäten auf dem Chip stattfinden und nicht über lange Drähte (Antennen) in die Welt gestrahlt werden. schweiky schrieb: > Es geht bei meiner Anfrage wirklich nur um > die 0V oder 5V Potenziale der "Knöppe und Lampen". Also kann das ein ganzes Stück langsamer laufen und ne größere Latenzzeit haben als die eigentlichen Klaviaturen, richtig? Dann kannst du die Tasten über TTL-Schieberegister (74HC... parallel-->seriell) seriell abfragen und die Lampen ebenfalls über TTL-schieberegister (diesmal seriell-->parallel) ansteuern. Die Abfragen brauchen ja nicht wirklich schnell zu sein, so alle 10 ms dürfte ausreichen. Das nette dabei ist, daß du für all die Tasten und Lampen nur ganz wenige Leitungen brauchst und daß die Signale darauf auch mit relativ geringer Flankensteilheit daherkommen können. W.S.
also ein Z80 reicht zum Abfragen von Schaltern allemal aber der Bus hat in dieser Länge nix zu suchen. Entsprechende Anzahl von Eingangstreibern und Ausgang Flipflops, vorzugsweise noch galvanisch getrennt oder zumindest mit hochhochigen Widerständen am 5 Volt Teil angekoppelt. Da machen dann ein paar Meter nix aus. Ansonsten empfiehlt sich bei einer höheren Anzahl I/O eine Schaltung mit Reihen und Spalten gemultiplext (auch in Software). Darüber hinaus gibt es heute natürlich auch passendere Controller als der Z80 aber das eigentliche Problem bleibt fast gleich und hat damit überhaupt nichts zu tun
120 Schalter kann man über 15 74LS244 und 120 LEDs über 15 74LS373 und 120 Vorwiderstände anschliessen, oder man macht es geschickt über 1 74LS244 und 4 Adressleitungen und einen 74LS154 für die Schalter und 1 CAT4016 und 1 74LS138 und 4 IRF7314 für die LEDs oder noch intelligenter alles über EINEN ATmega16, 1 CAT4016 und 4 IRF7314 laufen lassen und per SPI steuern.
Aber wer will denn in der Praxis eine riesige, vielleicht 1,50 lange Platine designen und herstellen lassen, wo nur 3 Chips drauf sind, aber alles in einer riesigen Matrix verschaltet ist? Auch wenn ich wieder Minus-Punkte kassiere: Dezentral, mehrere gleiche, kleine Boards, über wenige (3-4) Leitungen miteinander verbunden, halte ich für die bessere Lösung. Zudem könnten Microcontroller dem Hauptprozessor die stupide Arbeit des ständigen LED-Multiplexens und Taster-Abfragen abnehmen. Jede LED und jeder Taster/Schalter bekommt eine ID und der Hauptprozessor schickt "Messages" auf den Bus, um LEDs umzuschalten und bekommt Messages vom Bus, wenn sich an den Tastern/Schaltern etwas ändert.
> Dezentral, mehrere gleiche, kleine Boards, über wenige (3-4) Leitungen > miteinander verbunden, halte ich für die bessere Lösung. Ja, sehe ich auch so. Wenn es einfach sein soll und Kosten nicht allzu wichtig sind, dann würde ich eine Hand voll Crumb644 Boards (http://www.chip45.com/products/crumb644-1.1_avr_atmega_module_board_atmega644p_usb_rs485.php) über RS485 vernetzen. Auf einem davon kann dann auch gerne das Hauptprogramm laufen. Bestelle Dir welche mit vorinstalliertem Bootloader, dann kannst du die Software einfach per USB aufspielen. Unterm Strich hast du dann warscheinlich trotz verschwenderischem Umgang mit Mikrocontrollern sogar weniger IC's, als mit dem Z80. Der Z80 war ein wirklich toller Mikroprozessor, aber heute würde ich ihn nicht mehr verwenden. Da kann jedes kleine 3 Euro Arduino Board in vielerlei Hinsicht (nicht in jeder Hinsicht) mehr.
Stefan U. schrieb: > (http://www.chip45.com/products/crumb644-1.1_avr_atmega_module_board_atmega644p_usb_rs485.php) > über RS485 vernetzen. Naja, das Geld würde ich dann lieber in etwas Entwicklungs- und Programmierhardware stecken. Für die 25 Euro, die nur ein Board davon kostet, kriegt man bestimmt schon ein PICKit Clone oder AVR-Programmierhardware, und der freundliche Chinese macht einem für soviel Geld auch gleich 20 Custom-Boards für die Digitasts und LEDs, wo dann jeweils ein Standard-Controller für <1 Euro die Tasten/LEDs bedient und über SPI mit dem Host kommuniziert.
:
Bearbeitet durch User
Hallo liebes Forum: MaWin: der CAT4016 wäre genau meine Lösung - allerdings nur für die LEDs und die Parallelschnittstelle zum MIDI-System. Gibt's hiervon auch eine 16 Eingänge Version?? Others: ich gehe davon aus, dass es folgendermaßen aussehen wird: Platine 1 mit 48 Schaltern/LED und dazu gehörigen Entprellschaltungen und Ausgangstreibern, linke Seite, neben den Klaviaturen --> Register für Pedal, Manual 1 und Manual 2 Platine 2 mit 48 Schaltern/LED und dazu gehörigen Entprellschaltungen und Ausgangstreibern, rechte Seite, neben den Klaviaturen --> Register für Manual 3 und Manual 4 sowie Koppler Platine 3 mit 24 Schaltern, 16 LED und 2 Siebensegmentanzeigen und dazu gehörigen Entprellschaltungen und Ausgangstreibern, Mitte, unter den Klaviaturen --> Steuerung des Setzerspeichers, Plenumm, Stumm, etc. Platine 4 mit Z80 CPU, 2764 EPROM, M48T02 NVRAM und 15 Ausgangstreibern ULN2803 für 96 Relaisausgänge (parallele MIDI-Schnittstelle) und die 120 LEDs in den Digitastern + 7S-Anzeige, 15 74244 Bustreiber für die 120 Eingänge. Montage im Abschirmgehäuse. Das Ganze mit Flachbandkabeln sternförmig von den Platinen 1,2,3 nach der Platine 4 verkabelt. Stromversorgung "oldschool" mit Ringkerntrafo und Linearregler und ausreichender Verdrosselung. Ich poste die Schaltungen + mehr Details zum MIDI-Aufbau, wenn sie fertig sind... Danke für Euer Interesse, Andreas
Respekt, wer sich heutzutage noch so ein TTL Grab antut aber jedem Tierchen sein Plaisierchen. Viel Spaß und Glück bei der Umsetzung. Habe gerade erst ne Schublade voller zugehöriger I/O Chips wie 8255 und 8251 den Müll geworfen. Für mich war nach dem 6809 der Z80 ein toller Wegbegleiter durch die Schulzeit.
schweiky schrieb: > Gibt's hiervon auch eine 16 Eingänge Version?? Nein, der hätte ja ein 40 poliges Gehäuse, so was kauft doch niemand.
da könnte er dann auch einen Z80-PIO nehmen, der hat 2 8-Bit Ports. Sascha
Sascha W. schrieb: > da könnte er dann auch einen Z80-PIO nehmen, der hat 2 8-Bit > Ports. Er möchte nicht 16 Eingänge, sondern 16 kanalige 100mA Konstantstrom-Leistungstreiber statt seriell über SPI lieber parallel über 16 (TTL-Kompatible) Eingänge steuern. Wozu auch immer, vermutlich weil er SPI nicht verstanden hat.
Andreas S. schrieb: > Jetzt kommt das Problem: im Orgelgehäuse sind zum Anschluss roundabout > 120 Eingabeschalter (Digitast mit LED) räumlich verteilt, deren Zustände > über viele I/O Bausteine (in: 74244/ out:74373) am Datenbus des Z80 > angeschlossen sind. Ich habe dafür und für das Pedal einfach einige Schieberegister hintereinander geschaltet. Damit hat mein "Bus" nur 3 unidirektionale Leitungen. Und 3 Leitungen kann man leichter verteilen und sogar auffrischen. Aber einen bidirektionalen AD-Bus auf über 1m auszudehnen erscheint mir sehr gewagt...
Es gibt für solche Sachen das Projekt Midibox. Die Daten bekommst du per Midi rein und raus, und du hast recht schnell eine plug&play Lösung. Homepage: www.ucapps.de
@ Andreas Schweikard (schweiky) >Ich habe aktuell eine 4-manualige Hauptwerk Samplingorgel im Bau. Zum >Verarbeiten der Registerschalter und Anzeigen und zum Speichern von >Registrierungen (Setzerspeicher) soll ein kleiner Z80 Rechenknecht mit >nichtflüchtigem NVRAM dienen. Naja, würde ICH nicht machen, aus mehreren Gründen. Wenn du mit dem Z80 vertraut bist, OK. > Jetzt kommt das Problem: im Orgelgehäuse >sind zum Anschluss roundabout 120 Eingabeschalter (Digitast mit LED) >räumlich verteilt, deren Zustände über viele I/O Bausteine (in: 74244/ >out:74373) am Datenbus des Z80 angeschlossen sind. Schon mal ein Fehler. Solche Dinge löst man anders, z.B. über einen seriellen Bus mit verteilten IOs. Selbst mit I2C ist man da deutlich besser dran. >Es werden also >mehrere einzelne Platinen mit I/O Bausteinen, Entprellschaltungen, >Flipflops und LED-Treibern >am Datenbus und paar Steuerleitungen I/O-Adressdekodierung kaskadiert. 2. Fehler. Man braucht keine Entrpellschaltungen udn FlipFlops für so einen Kram, das macht man mühelos in Software. >Der Datenbus kann auf diese Weise vom Prozessor bis zum letzten I/O >Baustein bis einen Meter lang werden... MÖÖÖP!! So nicht, auch nicht bei 4 MHz. Der Prozessor und seine IOs gehörten kompakt zusammen auf eine Platine, BESTENFALLS mehrer Platinen im Stapel. Alles andere ist Unsinn. Mit einem modernen uC ala AVR, MSP430, PIC und so Gott will ARM braucht man das alles nicht, es reicht EIN kleiner IC + bisschen Außenbeschaltung. Das ist nicht nur detlich kleiner udn komfortabler, sondern auch deutlich störresistenter und funktionssicher.
Leute, der TO hat sich doch bereits entschieden. Der Thread sollte also geschlossen werden.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.