für mich hieße das einen spezialisten darum bitten mit das zu proggen.
Wieso? Du könntest doch einfach mal selbst anfangen dich da bischen reinzuhängen. Scheinbar hast du ja ab und zu mal ein digitales Problem...
Die Hardware is für dich kein Problem und digital denken kannst du ja offensichtlich, wenn du hier nen Haufen XORs und FFs zusammenschalten willst.
XOR: Doppler
Wie genau realisierst du den?
Hallo,
sowas riecht nach PLL. Also BPM- Sniffer wie oben vorgeschlagen, dazu ein Taktgenerator, der mit der vierfachen Frequenz läuft, über einen Teiler an die PLL, da gabs doch 'nen IC dafür, 4066? Hätte den Vorteil, daß der Generator weiterläuft, auch wenn ein Beat mal fehlt, zwar nicht synchron, aber was solls.
Gruß Jörg
Ich setze da nen kleinen Atmel entgegen. Kosten etwa 1e und ca. 30 Zeilen C.
Verstehe auch noch nicht so ganz wie man mit XOR den Takt verdoppeln kann. Aber ich habe ja auch schon feierabend..:-)
ist für mich auch Neuland, deswegen hochinteressant 
Wenn man eine Schaltung hat die bei abfallender und auch bei steigender Flanke einen Impuls rausrückt ist der Krieg doch gewonnen. Das ist Verdoppelung. Man verdoppelt von mir aus bis 8-fach und setzt ein Flipflop nach damit es wieder gleichlage Tast-und-Pausenzeiten hat (dann 4 fach) und fertig.
Wieso? Du könntest doch einfach mal selbst anfangen dich da bischen reinzuhängen.
Das Problem sind nicht die paar Zeilen C-Code, sondern, das ganze drumherum, bis man sich ein Programmieradapterchen gelötet hat, sich die Software zusammensucht....und das alles zum laufen kriegt und zurechtkommt -das war bei mir ein verdammter Eiertanz, weil erstmal nix ging und ich anfangs halt nicht wusste welche der Zahlreichen Fehlermöglichkeiten ich wahrgenommen hatte...
Dass man da nicht bei der ersten Gelegenheit ran will -versteh ich.
Hab auch lange gebraucht, und kenn mich weissGott noch nicht aus.
Wie genau realisierst du den?
Is mir jetzt auch nicht klar.
Man kann mit nem XOR die Flanken in Rechtecke wandeln, deren Breite hängt von der Verzögerung zum 2. Eingang ab (1. Direkt)
Wenn sich aber die Frequenz arg ändert ->Essig.
Dann sind sie zu schmal oder zu breit.
Möglichkeit Analog: PLL (wie auch immer das vorstellbar sein möge)
Möglichkeit Digital: Adapter bauen, Proggen
Wer die Muße hat sich sowas hier auszudenken, der schafft es auch mit
nem uC klarzukommen - geht halt nicht immer alles gleich auf Anhieb,
und die Datenblätter sind z.T. gewöhnugsbedürftig, daher vielleicht nicht gerade mit dem Dicksten anfangen :wink:
Ok, wenn man ohne Investitionen ins Thema einsteigen will hat man natürlich mehrere Fehlerquellen.
Wer aber 99 Euro investiert bekommt eine Atmel Entwicklungsumgebung die auch gut funktioniert.
Also Moment, das ganze drumherum besteht bei nem modernen ATtiny oder mega aus ner 5V Spannungsversorgung, fertig. Was so ein Controller allgemein zum Laufen braucht ist eine Resetschaltung und eine Taktquelle, haben die neuen AVRs beides eingebaut. Da eine genaue Zeitbasis hierbei nicht so wichtig ist wird der interne RC Oszillator reichen.
Natürlich braucht es Zeit sich mit einem (neuen) Controller auseinanderzusetzten. Aber man macht das ja nicht nur für ein Projekt. Wenn man mal drei Projekte mit Controller gelöst hat is das vierte im Nu auch geklärt. Ich kann mich erinnern, dass Manu letztens schonmal so nen Fall hatte, wo ein Controller nicht ganz doof gewesen wäre.
Für die ersten Schritte gibt's genug Infos im Web (z.B. http://www.mikrocontroller.net) und die ein oder andere Frage liesse sich sicherlich auch hier mit Hilfe einiger Leute klären.
Ein Entwicklungskit für 99€ zu kaufen is aber wohl Quatsch. Sucht euch nen beliebigen Programmer eurer Wahl für 2€ und gut. Die ganzen Flipflops und XORs sind vermutlich mehr Arbeit als Controller und Progadapter zusammen zulöten.
und die ein oder andere Frage liesse sich sicherlich auch hier mit Hilfe einiger Leute klären..
wie zB "wie proggt man in C?"
Manu würde das Ding direkt nach dem Einbau mit Assembler attackieren mangels Alternativen... Solange ich nur Speicher lesen, verknüpfen, schreiben und schieben muß krieg ich jeden MC in den Griff, aber Hochsprachen? *PUUH
C ist für deine bisherigen Probleme sicherlich nicht nötig...
Mit Assembler kann man auch einiges machen. Ich hab das ganze USB Interface auch in Assembler geproggt 
Wenn du mal in C programmieren willst solltest du natürlich erstmal C können und das lernst du am Besten am PC. Und wenn du C kannst und Assembler aufm AVR kannst is das Problem C und AVR vermutlich in nem halben Tag gegessen.
Wenn du mehr mit Controllern machen willst kann sich C durchaus lohnen... so _ein_ if konstrukt is einfach besser zu schreiben und zu lesen als _zehn_ cmp und br?? befehle...
Wenn du mehr mit Controllern machen willst kann sich C durchaus lohnen... so _ein_ if konstrukt is einfach besser zu schreiben und zu lesen als _zehn_ cmp und br?? befehle...
unbestritten ja !
Die Praxis assemblersüchtiger Basteltanten hat allerdings eine Library auf den Platten die die meisten Probleme vorgekaut im Lager hat, man kopiert sich also erstmal das Nötigste zusammen, versiehts mit Labels und schustert dann die Ergänzungen rein, Rad muß immer nur 1x erfunden werden. Für manche Dinge würde ich mir aber wirklich eine Hochsprache wünschen ! Vor allem wenn ein Farbdisplay im Gelände ist, da gehts dann richtig zur Sache. ´Hab da in letzter Zeit lange Nächte für geopfert
Na klar braucht man nicht unbedingt ein Evaluation Board, aber manchmal ist es schon praktisch.
Ich habe zwar eins, benutze es aber kaum noch, sondern programmiere fast alles mit dem ISP in der Zeilhardware.
Aber es schadet auch nicht wenn man schnell mal Schaltungen mit verschiedenen µC entwerfen will. einigen wir uns so:-)
Man muss auch nicht in Assembler programmieren, sollte es aber wenigstens schonmal gemacht haben. Aber ich bin meist zu faul dazu:-)
Wer will mich vervielfachen? :lol:
Gruß
Beat Indicator
rofl
ich brauch dich unbedingt.
Danke Manu, das geht runter wie Öl!
Beste Grüße
Beat Indicator
Manu: Irgendwie werd ich aus dir nit schlau. Du hast ja scheinbar schon Erfahrungen mit Controllern, sogar wesentlich kompliziertere Sachen. Und da erkennst du nicht selbst, dass hier ein Controller die Aufgabe einfach lösen könnte?
sven:
Klar schadet ein Eval Board nicht, aber überleg nur mal, wieviele AVRs man sich dafür kaufen kann Und viel kann es doch auch nicht, paar Taster, paar LEDs... Da hat mein FPGA Eval Board hier schon mehr zu bieten
Micha ich sträube mich nur dann gegen MCUs wenn die Aufgabe sackprimitv ist so wie in diesem Falle. Dafür einen Controler einzusetzen ist dasselbe wie ein Rechenzentrum zum Versenden einer Email 
Tja, wenn man von folgendem Teil den Schaltplan hätte
dann wäre man schon ein ganzes Stück weiter. Diese Funktion, die du
suchst, Manuela, heißt bei dem Gerät Delay. Schau dir die Abbildung
mal in groß an. Ist umschaltbar auf 1,2,3 oder 4 Blitze pro beat/ Takt.
Tja, wenn man von folgendem Teil den Schaltplan hätte
dann wäre man schon ein ganzes Stück weiter. Diese Funktion, die du
suchst, Manuela, heißt bei dem Gerät Delay. Schau dir die Abbildung
mal in groß an. Ist umschaltbar auf 1,2,3 oder 4 Blitze pro beat/ Takt.
Und da kommen wir beim Eprom brennen an
Das wird einfach aus nem Eprom abgerufen, auch ziemlich simpel 
Wenn ich mich recht entsinne werden bei dem Steinigke-Controller nur 1...4 Blitze mit einstellbarem Abstand getriggert, das hilft hier auch nicht weiter.
manuela:
Das Problem, eine saubere Triggerung mit dem vierfachen Beat hinzubekommen würde ich keinesfalls als "sackprimitiv" bezeichnen, zumindest mit einer diskreten Schaltung wird das so leicht nicht gelingen. Eine PLL kann man bei diesen Frequenzen gleich vergessen, und deine Lösung mit Flipflops und XORs wird, so sie denn überhaupt funktioniert, ein hübsches Bauteilegrab werden. Wo ist das Problem mit dem µC? Oder hat's da noch keine Library für? :wink:
