Archiv verlassen und diese Seite im Standarddesign anzeigen : Was meint ihr, sinnvoll oder Spinnerei? - Neulingsfragen :)
Listplatz
28.11.2007, 00:48
Hallo,
ich bin in der Materie Neuling, habe folgende Idee und bitte um eure Meinungen ob ihr eine Lösung mit Microcontrollern für sinnvoll haltet. Es handelt sich um keine Roboter-Anwendung, aber ich hoffe dass ich mit meinem Anliegen hier trotzdem richtig aufgehoben bin.
Ich möchte gern eine Modelleisenbahn mittels Gleisbildstellwerk steuern. Die dazu im Vorbild verwendeten Relais sind aber schon aus energetischer Sicht nicht mehr zeitgemäß. Nun könnte man alles an einen großen Rechner anschließen, ist aber nicht mein Fall. Stattdessen überlege ich jeder eisenbahnsicherungstechnischen Funktionseinheit (z.B. Signal, Weiche) je einen Microcontroller zuzuordnen und diese entsprechend des Gleisbildes, auch Spurplan genannt, zu vernetzen. Soll nun z.B. eine Einfahrt in einen Bahnhof stattfinden ist auf dem Gleisbildpult die Starttaste am Einfahrsignal sowie die Zieltaste im Zielgleis des Bahnhofs zu betätigen. Die Vernetzung der Microcontroller soll nun dafür sorgen dass das Stellwerk selbsttätig aus den 2 Tastendruckimpulsen den richtigen Fahrweg "ermittelt", diesen auf frei sein prüft, richtig einstellt (Ansteuerung wahlweise elektromagnetischer oder motorischer Weichenantriebe) und überwacht, sowie nach erfolgter Einfahrt des Zuges wieder auflöst. Die Rückmeldung an den Bediener erfolgt über die Ausleuchtung des Gleisbildpultes mit gelben und roten LED. Ich hoffe diese kurze Beschreibung genügt fürs erste, bei Unklarheiten bitte einfach rückfragen.
An Microcontrollern kämen nach erster Recherche wohl der ATtiny 26 oder 2313 in Frage, da sie bei hinreichend Ports recht preisgünstig zu haben sind, ich nur einen einfachen Funktionsumfang für die Logik benötige und Schnelligkeit denke nicht ganz so entscheidend sein wird. Haltet ihr, wenn überhaupt, diese für empfehlenswert? Wenn ja liebäugle ich für erste Erfahrungen mit dem Experimentierboard myAVR. Ob man dieses zum Programmieren der für das Board eigentlich nicht vorgesehenen tiny-Serie "missbrauchen" kann?
Nun bin ich sehr gespannt auf eure Antworten.
Viele Grüße vom Listplatz
hallo,
ich denk schon dass es geht was du da vor hast wobei ich halt nich so die ahnung von modelleisenbahnen habe.... was das myavrboard betrifft so hab ich mir für meins mal einen adapter für einen tiny gebaut. war recht simpel einen ic sockel und ne kleine leiterplatte (der erste prototyp sogar frei verdrahtet) und vcc, gnd, miso, mosi, sck und rst an die richtige stelle die restlichen protpins dahin wo es mir günstig erschien ... das ganze konstrukt war dann sozusagen pinkompatibel zum m8 und ich konte es einfach in den sockel des myavrbord stecken... hat prima funktioniert...
cu BT
thewulf00
28.11.2007, 09:15
Hi!
Also Dein Vorhaben klingt sehr interessant und ich denke schon, dass Du hier richtig aufgehoben bist, denn unser Horizont hört nicht nach Robotern auf. ;-)
Wenn Du die Tiny2313 in Betracht ziehst, ist das mal ne gute Wahl. Das ist übrigens einer der schnellsten... ;-) Und ich würde mir keine myAVR-Platinen o.ä. zulegen, sondern einfach die paar Grundelemente selbst löten. Das ist 10mal billiger und funktioniert genauso.
Die einzige Schwierigkeit sehe ich nur in der Koordination. Denn wenn Dus Dir einfach machen willst, solltest Du einen großen µC oder einen PC als "Gehirn", d.h. Zentralmodul, dass die Berechnung macht, einsetzen.
PS: Wenn das mal funktioniert, bitte ich um ein Video!!! :-)
Listplatz
28.11.2007, 20:16
Hallo,
besten Dank für eure ersten Antworten. Ich freue mich dass ich mit meinem Lösungsansatz wohl auf Gegenliebe stoßen könnte und bin sehr gespannt ob und wie es funktionieren wird. Aber ein großes Gehirn soll es definitiv nicht geben da ich damit meine stellwerksbauart-spezifischen Ziele nicht verwirklichen kann.
Viele Grüße vom Listplatz
Hallo, im Prinzip ist dies nichts anderes als die heutige Digitaltechnik bereits leistet, nur dass Du das ganze als „Multiprozessorsystem“ planst. Ich halte es technisch für aufwendiger, anspruchsvoller, teurer und nicht so flexibel. Ich sehe also noch nicht den Vorteil gegenüber der normalen zentral vernetzten Digitaltechnik, bei der dies alles über Bussysteme gehändelt wird. Die Zeiten der Relais wie Du Sie scheinbar meinst sind doch schon lange Geschichte. Ich selbst habe vor x-Jahren mal mit BBC angefangen, da war das auch schon so. Du musst am Ende beachten, dass Du nach dem Schema erstmal „nur“ die Fahrstrasse Freischalten kannst. Interessanter weise kommt aber dann die gesamte Überwachung der Fahrstrasse hinzu, also „welcher“ Gleisabschnitt ist belegt, wo befindet sich „wann“ „welcher“ Zug. Zu welchem Zeitpunkt kann die Fahrstrasse, bzw. Abschnitte wieder aufgelöst werden, nicht zu vergessen die Steuerung der Lok selbst usw. usw. Das waren nur ein paar wenige Dinge die da zu beachten sind. Zentralisiert kann ich das zumindest im Moment definitiv besser händeln und schneller anpassen, aber vor allen Dingen mehr Faktoren einfliesen lassen und ich bin obendrein noch flexibler. Wobei die meisten Artikel ja sowieso schon einen eigenen Prozessor haben, der aber „nur“ dazu dient den Bus zu überwachen und entsprechende Befehle an Ihn umzusetzen, eine Beispiel sind die vielen verschiedenen Signaldecoder usw. Oder eben umgekehrt Überwachung und Meldung. Wobei dies ganze auch über Stellwerkstechnik möglich ist, erfordert halt einen etwas größeren Aufwand als nur am Monitor.
Wenn Du, nach Deinem Schema, von A nach C über B fahren möchtest und ein anderer Zug von D nach B, musst Du immer warten und selbst überwachen bis der erste Zug soweit ist, dass Du die Fahrstrasse D nach B schalten kannst, da Du ja keinerlei Überwachung hast. Auch wenn Du nur dies möchtest, also das Dir die Technik die 3-4 Weichen abnimmt, nach betätigen des Start/Zieltaster, selbst dann halte ich es noch für aufwendiger als Zentral gesteuert.
Gruß André
Listplatz
29.11.2007, 14:19
Hallo Andre,
die Steuerung der Loks selbst interessiert das Stellwerk gar nicht, und auch alles andere ist weit weniger dramatisch als von Dir beschrieben. Ich werde digital fahren und analog schalten! Nur im Stellwerk selbst gibt es digitale Logik. Aber diese dient nur dem Fahrweg, nicht den Fahrzeugen. Dazu kommen ein paar Rückmelde- sowie Gleisbesetztmeldeschaltungen, aber diese sind so oder so notwendig. Die Ausgaben für die nötigen Mikroprozessoren und ihr Beiwerk relativieren sich, da ich weder Weichen- noch Signaldekoder benötige. Und unflexibel werde ich durch die Spurplantechnik mit Sicherheit nicht, eher im Gegenteil. Wenn Du etwas wirklich unflexibles und teures sehen möchtest empfehle ich dir den Besuch eines modernen ESTW. Einmal aufgestellt sind nachträgliche Veränderungen an den Außenanlagen, wirtschaftlich gesehen so gut wie untragbar ...
Viele Grüße vom Listplatz
Wie Du meinst, ich bin halt anderer Meinung. Ich habe mir das auch nicht aus den Fingern gesogen, sondern programmiere schon beruflich viele Jahre MC-Technik, zufälligerweise wurde ich in den letzten 3-4 Jahren auch mit Digitalanlagen konfrontiert. Natürlich habe ich nicht von einer Analog/Digitalkombination gesprochen, sondern von der Zielstellung eines automatisierten oder nach Fahrplan laufenden Gegenzugbetriebes, zumindest aber nach Fahrstraßenvorwahlverfahren. Und in dem Falle interessiert sehr wohl welcher Zug sich wann, wo befindet. Im Gegenteil, da gibt es sogar noch genügend andere Faktoren. Ich möchte das aber jetzt gar nicht im Detail ausweiten, wer damit intensiv zu tun hat, kennt die Problematik und deren Probleme.
Für mich ist halt noch schleierhaft, wie Du die Logik der Belegung, Richtung, Position und der eigentlichen Aufgabe jeder einzelnen Weiche, jedem Meldeabschnitt (Signal mal außen vor, ist sowieso nur „Optik“) beibringen möchtest, so dass diese alle miteinander vernetzt, alle im „Masterbetrieb“ also ohne Zentral-MC oder Rechner, das tun was Du erwartet. Und wenn Du das dann doch geschafft hast, dies dann auch noch flexibel sein soll, so dass das ganze auch noch schnell änderbar ist. Wir sprechen jetzt aber nicht von 3-4 Weichen mit 2 oder 3 Fahrstrassen hoffe ich.
Ich bleibe weiterhin der Meinung, dass diese „abgespeckte“ Variante, von einem zentralen MC, der Kenntnisse über das Gleisbild hat, besser zu händeln geht. Und das wäre sicher nicht teurer.
Ich wünsche Dir aber für Dein hoch gestecktes Ziel trotzdem viel Erfolg!
Gruß André
Listplatz
29.11.2007, 18:35
Vielen Dank für Deine bzw eure Wünsche, ich werde zu gegebener Zeit meine Erfahrungen berichten.
In der Tat, einem kompletten Automatikbetrieb wäre mein Lösungsansatz nicht dienlich, aber dieser soll ja nicht dabei herauskommen. Wäre doch langweilig ... :)
Viele Grüße vom Listplatz
roboterheld
02.12.2007, 10:54
.....sondern einfach die paar Grundelemente selbst löten. Das ist 10mal billiger und funktioniert....
nicht immer, aber immer öfter.
du solltest dich auf deine bahn konzentrieren und einen hersteller(privat) für die platinen aussuchen. sind nicht teuer. mache ich auch so.
mein power liegt dann nicht mehr in der fehlersuche auf der platine sondern kann mich ganz auf mein projekt stürzen.
es gibt viele selbstgebastelte mistplatinen hier im forum, vor lauter fehlersuche kommen die garnicht zum arbeiten mit dem eigentlichen sensoren.
im Prinzip könnte man doch einfach für jedes Gleis, bzw. für jede Weiche
ne Elektronik basteln, die detektiert ob Gleis besetzt und welche Fahrtrichtung
der Zug hat. dementsprechend dann die Weiche stellen bzw. wenn
n neuer Zug kommt diesen stoppen damit das nicht kollidiert.
N Fahrplan währ dann klaro nicht drinn, und höhere Logik natürlich
auch nicht.
Das währen dann Insellösungen und ziemlich Teuer auch, weil ja
für jedes Stellglied mehr oder weniger aufwändige Technik
nötig währe. N Bus hätt dann nur den Zweck die Stellungen abzufragen
um sie auf m Diagramm anzuzeigen.
Für alle "einfacheren" und günstigeren Installationen brauchts dann
doch ne Steuerzentrale, die den Slaves ihre Funktion zuordnet
und die "Übersicht" hat würde ich denken.
Prinzipiell könnte man auch jedem Busteilnehmer den ganzen
Plan rüber schicken, so ala LANGEMARK aber die Busteilnehmer
werden dann doch recht aufwändig von der benötigten Hardware
(Rechenleistung / Speicher) her.
Der Thread ist ja schon älter, aber vielleicht schaut ja doch noch jemand rein. 8-[
Ich bin zur Zeit an einem ähnlichen Projekt beschäftigt, allerdings nicht mit Microcontrollern, sondern mit nem PC, älteres Modell. Ein Microcontroller wäre wohl auch ausreichend, damit habe ich aber noch nix gemacht...
Zunächst möchte ich nur die Weichen stellen, Gleisbesetzt und ähnliches soll später kommen(wenn das einfache mal funktioniert). Die Eingabe erfolgt über eine (Numerische-) Tastatur, indem man die Start- und Zielposition als jeweils 2-Stellige Zahl eingibt. Das Auswerteprogramm habe ich bereits geschrieben, an der Ausgabe hängt es noch ein bisschen. Wenn man die Auswertung sauber programmiert ist dieses System auch gar nicht so unflexiebel, wie Listplatz vielleicht denkt. Die Bedingungen, bei welcher Zahlenkombination eine Weiche stellt, stehen aufgelistet in einer Datei. Kommen Weichen dazu, oder ändert sich die Gleisführung, bleibt das eigentliche Programm unverändert.
Zur Ausgabe möchte ich die Parallelschnittstelle verwenden, ist wohl die unkomplizierteste Möglichkeit.
Frage:
Wenn ich "von-4-auf-16" -Logikbausteine verwenden möchte, und möchte einen "sperren", genügt es dann, nur die Stromversorgung dieses Bausteins zu unterbrechen, oder muss ich dann alle (4) Datenleitungen unterbrechen?
naja ich arbeite im moemntn an was ähnlichem, für Lehmann Garten/Gross Bahn, ein haufen mega8, könnten auch tinys sein und RS485 controller über eigenes UART protokoll, geschwindigkeit reicht völlig aus, addressierungsbreite ist frei wählbar und die verkabelung mach ich über 50m LAN-Kabel das ich punktuell entisoliere und dann mit flachband-klemm buchsen/steckern(SUB-D 9pol , so hat man alle 8 adern zur verfügung, 4 kanäle oder 3 und die stromversorgung) versehe, also mit 5 "abgriffen" 50m Kabel zu ner hübschen spule gerollt hab ich bis dato keine probleme bei der übertragung, jetzt muss ich mr nurnoch überlegen wie ich die züge kodiere, es sind 2 verbundene kreise auf denen 3 züge fahre sollen nach der bei der bahn üblichen anmelde-genehmigungsverfahren, also zug kommt, fordert segmentfreigabe, ist 1 segment weiter vorne KEIN zug schaltet das nchste segment frei
EDIT wie ist das mit dem stromabfall ? 50m kabel sollten hoffentlich nicht zu problematisch werden oder ?!
welcher querschnitt welche spannung und welcher strom?
http://de.wikipedia.org/wiki/Spezifischer_Widerstand
damit kannst du dir deinen spannungsabfall berechnen und dann selber entscheiden ob dir das zuviel ist. (achtung, der strom muss 2x durch das kabel, damit steigt der widerstand um das doppelte)
mfg clemens
Zur Ausgabe möchte ich die Parallelschnittstelle verwenden, ist wohl die unkomplizierteste Möglichkeit.Glaub mir, mit einem Mikrocontroller geht es noch viel viel einfacher.
Die Ansteuerung von irgendwelcher Elektronik über die Parallele Schnittstelle ist ein Krampf, das habe ich genau einmal gemacht und danach nie wieder. Wenn du einen Mikrocontroller nutzt, kannst du ihn über die serielle Schnittstelle mit dem PC verbinden und ihm dann, z.B. mit irgendeinem x-beliebigen Terminal-Programm, deine Befehle übermitteln.
Je nachdem wie du die Intelligenz verteilst, kann das Programm auf dem µC sehr einfach ausfallen (du hast ja schon deine Software als "Gehirn", der µC müsste also nur seine digitalen I/O-Ports deinen Befehlen entsprechend ansteuern).
Mit welcher Programmiersprache hast du deine Software geschrieben?
C wäre optimal, aber auch Basic ist in Ordnung, denn für die AVR-Mikrocontroller gibt es für beide Sprachen passende Compiler
Hallo Felix,
zur Programmierung habe ich Assembler verwendet. Ich kann noch Fortran und ein bissle Java, da ich für beides nichts gefunden hab (was auch funktioniert hätte) um auf den Parallelport zuzugreifen, hab ich mir noch Assembler angeeignet, C wäre vielleicht klüger gewesen...
Wie gesagt habe ich mit Microcontrollern noch nicht zu tun gehabt. Ein Programmierboard bräuchte ich ja dann auch noch. Ein fertiges würde ich mir schon aus Prinzip nicht kaufen O:)
aber eines Aufzubauen ist wohl auch nicht ganz einfach, die I/O Probleme sind ja dann die gleichen wie bei der Zugsteuerung!?
Was glaubst du, wie lange würde ich ungefähr brauchen, um das mit den Microcontrollern und der seriellen Schnittstelle zu beherrschen?
Kannst du mir Tutorials/Infos empfehlen?
uart ist völlig simpel,
ich rate hier DRINGEND zum studium des datenblatt des entsprechenden controller
du musst zunächst die steuerregister laden, mit baudrate, datenbit stoppbit und parität wie es dir am liebsten ist
dann zum senden, warten bis ein bestimmtest bit in dem uart flag register "frei" wird, und ein byte das gesendet werden soll in das datenregister schreiben
empfangen kannst du ebenfalls über wiederholtes auslesen des flag register, wenn ein empfangenes byte signalisiert wird, einfach das byte aus dem datenregister kopieren
ODER
den interrupt für uart revceive programmieren und in der interrupt routine das byte in einem array zwischenspeichern und im hauptprogramm das/die bytes auswerten
Also Mikrocontroller sind wirklich einfacher zu handhaben als man denkt...
Die Grundschaltung für einen AVR (zu finden im RN-Wissen Bereich) besteht nur aus wenigen Bauteilen, und kann schnell und problemlos z.B. auf einer Lochrasterplatine aufgebaut werden.
Die Programmierung ist auch nicht weiter tragisch, bei den AVR Controllern hast du im wesentlichen die Wahl zwischen C, Basic und selbstverständlich auch Assembler. Dabei beginnt eigentlich jedes Programm erstmal mit der Konfiguration der Hardware des Controllers, da legst du also z.B. fest welche Ports als Eingänge und welche als Ausgänge verwendet werden sollen, oder du stellst eben die serielle Schnittstelle deinen Anforderungen entsprechend ein.
Das geht alles über Register, die man prinzipiell erstmal so behandeln kann als wären es Variablen. Welche Bits in welchen Registern was bewirken, steht ganz genau im Datenblatt, das muss man also nicht auswendig wissen.
Die wichtigsten Grundlagen zu den hier sehr beliebten AVR Controllern von Atmel, bzw. Mikrocontrollern im Allgemeinen, findest du in RN-Wissen. Da ist eigentlich alles sehr gut erklärt und die Artikel sollten dir zumindest insofern helfen, daß du besser einschätzen kannst was Mikrocontroller können und wo sie sich sinnvoll einsetzen lassen.
Im einfachsten Fall kann so ein µC z.B. seine I/O-Ports zur Verfügung stellen um damit ferngesteuert irgendetwas schalten zu können. Damit sind zwar selbst kleine Mikrocontroller eigentlich völlig unterfordert (zumindest was die benötigte Rechenleistung betrifft), aber es ist eben eine einfache Möglichkeit einen PC (oder einen anderen µC) mit einer großen Anzahl zusätzlicher digitaler I/O-Ports auszustatten.
Die wichtigste Grundlagen zu den hier noch nicht so beliebten Propellern findet am übrigens hier: http://forums.parallax.com/forums/default.aspx?f=25. Das englische soll nicht schrecken, es gibt auch schon deutsche Seiten. Jedenfalls hat mich dieser Controller dazu gebracht, meine Frustrationen zu überwinden und wieder anzufangen. Denn die Welt ist parallel und alles Serialisierte ist eigentlich unnatürlich.
Ich hab heut einige Zeit damit verbracht, (mehrere) Tutorials zu lesen, hört sich echt interessant an und auch nicht so schwer, allerdings weiß ich nicht, wie ich am besten Anfange. Beim Microcontroller gibts ja kein Bildschirm, oder so was, wo ich sehe, mir zeigen lassen kann, was passiert...
Gibt es da Simulationen für den PC, wo ich sehen kann, ob das Programm funktioniert, beispielsweise sich bestimmte Registerwerte anzeigen lassen?
Ich möchte zunächst das mit der Software gebacken kriegen, bevor ich den Lötkolben auspacke.
danke für eure Tipps!
Also für die AVR Mikrocontroller gibt es von Atmel das AVR-Studio...
Das ist eine Entwicklungsumgebung mit Simulator, die in erster Linie zur Entwicklung von Assembler-Programmen ausgelegt ist. Man kann damit aber auch C-Programme simulieren, die man zuvor mit dem AVR-GCC Compiler erstellt hat.
Ich muss allerdings ganz ehrlich sagen, daß ich sowas in der Regel nie nutze. Letztendlich ist es bei einem Mikrocontroller meist leichter irgendwelche Debug-Ausgaben in das Programm einzubauen. Im Einfachsten Fall könnte man z.B. einige an den Ports angeschlossene LEDs einschalten, z.B. um festzustellen ob ein bestimmter Programmteil überhaupt ausgeführt wird. Und wenn man die serielle Schnittstelle zum laufen gebracht hat, bietet sich diese natürlich ebenfalls zum debuggen an. Da kannst du ja dann so ziemlich alles an Informationen an den PC senden, was dir bei der Fehlersuche hilft, wie z.B. die Werte irgendwelcher Variablen.
Mein Meldung ist in sofern in eigener Sache, dass eine Gemeinschaft stärker wird, wenn sie größer wird ;-)
Die großen Hersteller promoten ihre Prozessoren, weil sie sich eine große Basis von Entwicklern beschaffen wollen und dann ihre Prozessoren in Massenanwendungen bringen. Das ist nicht negativ zu sehen. Als Amateur kommt man an billige, industrielle Hardware und wenn man es kann, ist man sogar ein Spezialist und kann eventuell Geld verdienen.
Der Propeller ist da anders, denn er ist der umgesetzte Traum eines Unternehmers, der sich mal zum Ziel gesetzt hat, billige Hardware für Schulen zu machen, da er als Schüler privilegierter Besitzer eines Apple II war und somit recht allein.
Nun hat man für ca 10 Eus eine 8-core Rechner mit 32K + RAM, 160Mips, ... und einem Konzept, das viele Freiheiten hat. Die Entwicklungssystemumgebung ist einfach. Bei Mikrocontrollerstarterkits gibts für 50€ eine Hardware mit vielem drum und dran und nichts ist aufregender als echtes Leben. Es gibt zwar auch eine Simulationsumgebung, aber die habe ich nie ausprobiert, aus obigem Grund. Man stelle sich vor: einen Controller, einen VGA-Bildschirm, Tastatur, Maus und Kopfhörer anschließen und schon kann man alles mögliche ausprobieren, auch vierchörigen Gesang, Graphik, usw. Nach dem Spielen kommt die Arbeit und es ist einfach so, dass viele Roboterfreaks heute Erfahrungen haben mit bekannter Hardware und man soll ja ein erfolgreiches Pferd nicht wechseln. Wenn es nicht unbedingt nötig ist. Ob es nötig war, weiß man erst später. Also, auf später!
also wenn du wissen magst WAS auf deinem rs485 bus passiert, nix leichter als das, einfach einen max232 nehmen, die tx und rx mit dem rx485 wandler verbinden und an den PC anschliessen .... entweder du arbeitest mit klartext, dann kannst du es mit dfem hyperterminal machen ODER
du frickelst dir ne kleine anwendung die den com port ausliesst, ich hab mal eine gemacht die übertragene bytes in hex, dezimal und wenn möglich schriftzeichen ausgibt, ausserdem über mehrere eingabefelder mit entsprechendem button auch einzelne eingegebene bytes senden kann
wenn du service pack und den ganzen krempel installiert hast, den man für visualstudio anwendungen braucht, kann ich dir das ding gern zuschicken
Ich bin jetzt so weit, dass ich doch die ganze Steuerung per Microcontroller machen möchte. Ist vom Platzbedarf doch wesentlich besser.
Welcher Microcontroller ist geeignet? Der Propeller sieht von der Rechenleistung recht gut aus. AD-Wandler bräuchte ich ja auch nicht.
Allerdings: Kann man wirklich nur 2k große Programme in die Cogs stellen? Gibt es schon fertige Lösungen, die z.B. zu gegebener Zeit den Code nachladen?
Die Verwaltung der Cogs kann ich mir auch nicht ganz vorstellen, was tut ein Cog, wenn er nichts zu tun hat, wer (de-) aktiviert ihn, ein anderer Cog?
Vorteile des AVR, anderer Controller?
Sorry, das soll jetzt nicht ausarten, ich möchte mir nur einen kleinen Überblick verschaffen. 8-[
Was hat es mit der Herstellerangabe der 100.000 (Speicher-Schreib-) Zyklen auf sich? Die könnte ich doch ggf. schon nach einer halben Stunde für manche Speicherstellen verbraucht haben?
@Ceos: Genau das hatte ich mich gefragt! Wenn ichs jetzt aber komplett mit dem Microcontroller mache, brauche ich eine serielle Verbindung (zunächst) nicht.
vielen Dank für eure Hilfe!
doch, wenn du rs485 nimmst schon, denn rs485 wird schliesslich an den uart des µC angeschlossen!
Zu deiner frage, würde es da nicht EIGENTLICH schon nen mega32 oder 64 tun ?
zumal du ja auch ne computereinspeisung machen kannst über die max232 lösung um programmabläufe zu testen / simulieren oder sogar die komplette steuerung und ein paar attinys oder mega8 als clients, die befehle entgegennehmen und aktionen ausführen (gleise ausschalten, weiche stellen ...) oder sensoren(zugmelder, weichenstellung ...) auswerten ... ich wollte zunächst nen programmablauf mit meinem PC steuern und den ablauf über ne art script, den ich in den eeprom schreibe dann von einem mega32 ausführen lassen, der dann so um die 25 mega8 steuert, die wiederum die signale und weichen steuern, bzw. auswerten ... 1 mega8 kann je nach segmentabstand 1-3 gleissegmente übernehmen oder mehrere weichen gleichzeitig bedienen, für die langen strecken zwischen 2 megas benutz ich halt rs485
Will mal versuche, etwas Ordnung zu schaffen:
RS232, 485 oder was auch immer ist nur die Definition einer Hardware, die mit einem bestimmten Aufwand über eine bestimmte Entfernung eine bestimmte Datenmenge von Punkt zu Punkt oder über einen Bus Master/ Slave/Multimaster übertragen kann. Auf dieser Basis gibt es dann Protokolle wie Sand am Meer. Mit Standard ist da wenig.
Was aber nun ist der Propeller? Zuerst mal 8 Prozessoren, die alle parallel laufen. (Wenn sie nichts zu tun haben, machen sie auch nichts). Einer der Prozessoren bearbeitet in der Regel ein Hauptprogramm, das in einer Schleife den Überblick bewahrt. Die anderen Prozessoren können primitive Aufgaben oder hochkomplizierte Übernehmen. Z.B. könnte der Propeller einfach als Hub laufen, indem er 8 RS232-Schnittstellen realisiert, wobei er an allen Schnittstellen Daten in Empfang nimmt und sie an andere wieder aussendet. Der Vorteil ist also: kein Prozessor hat so wenig vorbestimmte Peripherieelemente und kann gleichzeitig für alles mögliche eingesetzt werden.
Bei der Programmierung muss man grundlegend unterscheiden: SPIN-Programme liegen im Byte-Code im gemeinsamen Speicher. In den COGS sind die SPIN-Interpreter geladen (vergleichbar zu einer Java-Engine). Diese laden sich Befehl für Befehl aus dem globalen Speicher und arbeiten ihn lokal, also echt parallel mit anderen, ab. Regelschleifen mit 10, 20 kHz kann man damit abarbeiten. Wenn es aber richtig schnell werden soll (und 2MBit über Seriell in Software oder die Ausgabe eines Videosignals sind schon schnell), dann programmiert man in Assembler. Assemblerprogramme werden direkt in die COG geladen anstelle des SPIN-Interpreters und laufen dann mit 20 MIPS. Die 2K speicher im COG sind für das Programm und die Daten da. Selbstverständlich kann dieses Programm auch auf die 32K Hauptspeicher und alle I/O zugreifen sowie auf private Zähler usw. Wer es ganz trickreich machen will, kann sogar aus dem Globalspeicher Assemblercode in den Cog nachladen und so dessen Funktion modifizieren. Oder, auch tricky, das Assemblerprogramm modifiziert sich selbst! Aber das ist hohe Kunst am Trapez, nichts für Anfänger.
Was das Gerücht angeht, es gäbe wirklich billige Prozessoren: das teuerste am Prozessor ist die Zeit, die man sich mit ihm beschäftigt. Eine Stunde ist schnell vorbei.
Ich selbst habe schon mal mit folgendem Gedanken gespielt: Der Propeller braucht einen externen 32 K Speicher (Flash). Und natürlich gibt es Controller mit sehr interessanter Peripherie für wenig Geld. Man könnte doch einen solchen als Coprozessor verwenden, indem man ihn als serielles Flash-Eprom programmiert, das heißt, beim Booten simuliert der "Billigprozessor" ein Flash.Eprom und läd den Propeller, anschließend stellt er ihm über I²C seine Peripherie zur Verfügung. Dann stellt man fest, dass Prozessoren mit 32-64K Flash, guter Leistung und Peripherie nicht häufig und nicht wirklich billig sind. Die Typen, die nur Cent kosten, sind auch nur Cent wert! Also alles nicht so einfach.
Es bleibt die Frage: warum sollte der Amateur über eine Debugger in einen Prozessor hineinschauen, wenn er einen Multiprozessor hat, der seinen Speicherinhalt als Life-Bild auf einen VGA-Monitor bringen kann.
@Ceos: Nee,eine serielle Übertragung bräuchte ich nicht unbedingt, hab "nur" HO, da ist das mit der Verdrahtung kein Problem. Letztendlich müsste mir ein Controller reichen, dass heißt beim Stückpreis kommt es auch nicht auf ein paar Euro an. Das mit dem Debugging ist ein Argument...
Wie weit bist du denn schon mit deiner Steuerung?
@ErNa: Das mit dem VGA-Bildschirm stell ich mir nicht so einfach vor und günstig wird das dann wohl auch nicht. Beim Programmieren/Programm aufspielen wird ja auch eine serielle übertragung verwendet, das heißt, von der Hardware müsste es schon gehen?!
ich hab versuchsweise einen etwa 25m langen(wegstrecke) kreis mit 5 controllern bestückt und ein CSMA/CD ähnliche kommunikation mit den 8 beinigen controllern aufgebaut über CAT5e Kabel mit klemmbuchsen SUB-D 9pol. (scheiss frickelarbeit die adern zu entdrillen und zu ordnen) ...
funktioniert super, die stromversorgung ist aber im moment noch separat verkabelt, und das ganze macht auch net mehr als 2 züge so zu kontrollieren das sie mindestens immer 2 segmente abstand halten, insgesammt hab ich erstmal "nur" 5 segmente und eben 2 züge, da kommen aber nochmal ca. 20 meter in form eines 2ten kreises hinzu, also etwa 9-10 segmente, 4-8 weichen 4 bahnhöfe 3 züge 2 fahren auf ihren separaten kreisen der 2te fährt ne art 8ter schleife, ursprünglich wollte ich ne reine logiksteuerung machen, aber bin an der verschaltung gescheitert
Das mit dem VGA-Bildschirm ist echt geschenkt! Man kann den Bildschirm (es geht auch ein normaler Videomonitor) über ein paar Widerstände an den Microcontroller anschließen und schon hat man das Bild. Also etwa ein Textterminal oder aber eine eingeschränkte Graphik (Graphik braucht viel Speicher, und wir haben nur 32 K) Ich habe mal schnell gegoogled: http://www.selmaware.com/propeller_video_app_board.htm zeigt eine solche Anwendung.
Und wenn wir schon mal dabei sind: http://de.wikipedia.org/wiki/Parallax_Propeller
http://propellerforum.sps-welt.de/viewtopic.php?t=144
oh, ein "Fremdgänger" ;))
http://www.dk2gt.de/index.php?projektparallaxentwicklerboard
http://www.ipsymcon.de/forum/showthread.php?p=41342
Ja. Wofür? Gilt aber für alles. Antwort: für mehr!
http://www.mikrocontroller.net/topic/73015
Andreas Jakob hat das System entwickelt, das es bei Mike Schaub für einen schlappen 50ger gibt. Inklusive Mausanschluss, um einen Ton zu steuern.
http://www.rayslogic.com/propeller/propeller.htm
http://diydrones.com/profiles/blog/show?id=705844%3ABlogPost%3A6607
http://www.franzis.de/elo-das-magazin/weblog-und-news/neue-bauteile/der-propeller-von-parallax-inc
Nochmal: das Entwicklungssystem einfach runterladen und starten. Wenn man eine echte RS232 hat, kann man über einen Pegelwandler direkt an den Prozessor. Ansonsten brauch es noch eine USB-RS232 Wandlung.
Es gibt auch noch Propterminal, eine Windows-Anwendung, in der man den PC als Terminal nutzt, auch mit Graphik-Fähigkeit. Ein Debugmodul erlaubt die Darstellung gewählter Variablen. Aber man sollte eigentlich keine Fehler machen, dann erübrigt sich der Debugger!
naja mir persönlich zumindest graut es ein wenig vor dem assembler, ich bin c verwöhnt und liebe c++ java c# ... assembler ist nicht ganz syntax-kompatibel ^^ da müsst ich mich erstmal reinfinden und DARAUF habe ich zumindest keine lust im moment
EDIT: verzeihung, ich hab den vorhergehenden post falsch interpretiert, ignorier meine aussage :p
Na ja, ist auch nicht immer einfach zu verstehen, was man so hinschreibt. Aber zum Assembler: der für den Propeller ist so ziemlich der ungewöhnlichste und best aufgebaute, den ich kenne (oder erinnere).
Man schreibt etwa einen Befehl:
Mov a, b und damit geht Inhalt Register B nach Inhalt Register A. Hinter dem Befehl gibt man an, welches Bedingungsbit beeinflusst wird, als z.B wz für with zero.
Vor den Befehl schreibt man if_c, das heißt, der Befehl wird nur ausgeführt, wenn durch einen vorigen Befehl mit wc das Carry beeinflusst und gesetzt wurde.
Es gibt also nicht unterschiedliche Befehle, die die Bedingungsbits beeinflussen, sondern alle Befehle können mit allen Bits versehen werden.
Und was natürlich noch ganz besonders ist: man kann Befehle gezielt verändern, damit kann man etwa quell oder Zieladressen verändern, etwa wenn man einen Ringpuffer abarbeitet. Der Assembler ist also eigentlich recht schön.
Ein wunderbares Beispiel ist das Auswerten eines Quadratursignals von einem Drehgeber. Man schafft locker 2Mio Inkremente/sekunde
Also, so interessant der Propeller auch ist...
für einen Anfänger würde ich ihn eher nicht empfehlen. Die Fehlersuche ist schon bei Controllern mit nur einem Kern nicht immer ganz einfach, und beim Propeller hat man gleich 8 Kerne die unterschiedliche Programme abarbeiten und miteinander interagieren.
Daher wäre meine Empfehlung ganz klar ein AVR, denn die kann man in C programmieren (schade daß es keinen C-Compiler für den Propeller gibt) und sie sind wunderbar einfach aufgebaut. Dazu kommt noch die erstklassige Dokumentation, ich habe selten so gute Datenblätter gelesen wie die von Atmel.
Also: fang erstmal mit einem AVR an (z.B. mit dem Mega32). Wenn du dann auf den Geschmack gekommen bist und genügend Erfahrungen gesammelt hast, kannst du ja auch komplexere Projekte angehen bei denen ein Propeller wirklich sinnvoll ausgelastet werden kann.
Da ist ein Knoten in der Argumentation. Niemand zwingt einem, mehrere Cores zu nutzen. Man kann ein Problem also mit einem Core lösen. Wenn es sich dann herausstellt, dass es mit mehreren besser geht, nimmt man mehrere.
Nun ist die Argumentation: nehme zuerst etwas einfaches, das ich kenne und dann, wenn es nicht mehr geht, dann nimm etwas anderes einfaches, was du auch am Anfang hättest nehmen können.
Man kauft sich sein Traumauto nicht, weil es noch nicht nutzen kann, sondern weil man es sich nicht leisten kann. Kann man es sich leisten, warum es nicht nehmen und noch nicht völlig nutzen.
Gerade für Amateure, die NICHT von ihrem Chef schon gezwungen werden, den letzten Pfennig zu sparen, bevor die erste Mark ausgegeben ist, ist der Propeller ideal.
Viel Spaß!
Nach einigem rumsuchen habe ich mich jetzt für den AVR entschieden (Mega32 wegen der vielen I/Os). Was mich dazu bewogen hat, war doch der Preis. In die Assemblerprogrammierung beider Chips habe ich mich nun so weit eingearbeitet, dass ich glaub, beide als machbar und von der Schwierigkeit gleichwertig beurteilen zu können. Bei einem einzelnen Controller wäre der Preisunterschied nicht dramatisch, wenn ich einen zerstör sieht es schon anders aus...
Das debugging-Problem ist wohl bei beiden das Gleiche. Ich muss mir wohl als erstes eine (funktionierende Zahlen-) Ausgabemöglich schaffen, auch bei C macht man ja fehler. 8-[
Momentan habe ich wenig Zeit, ich melde mich wieder, wenn ich einen Schritt weiter bin.
grüße
Jeder ist seines Glückes Schmied! http://propellerforum.sps-welt.de/viewtopic.php?t=5&postdays=0&postorder=asc&start=15 zeigt, wie ein glücklicher Schmied die Sache sieht.
Wenn man sich Gedanken darüber macht, wie man Variablen ausgibt, hat man wirklich noch nicht verstanden, was etwa das Debugmodul von Ariba macht. Also dann, viel Spaß!
Gerade wenn man keine Zeit hat, muss man langsam und überlegt handeln. Das ist da gute am Ältersein: man hat nicht mehr so viel Zeit, aber man hat schon die Erfahrung, um die Fehler zu vermeiden, die andere noch stolz machen!
PS: so macht man dann auch Sätze, die doppelt zu gebrauchen sind: einen Fehler stolz zu machen bedeutet: ich kann es mir leisten, mit Ressourcen zu schleudern. Oder man macht einen Fehler und ist noch stolz drauf weil man nicht sieht, dass andere ohne diesen Fehler schneller, eleganter und billiger zum Ziel kommen.
Hallo ErNa,
du solltest nicht unfair werden, den Debugger kannte ich nicht, wie kann ich ihn dann verstehen!?
Ich hab die halbe Dokumentation gelesen, aber die 2K-Cog-Speicher haben mich (zus. mit dem Preis) abgeschreckt. Das Problem ist ja, dass man durch die 32bit Architektur nur 500 Speicherstellen hat. Die Befehle für die einzelnen 9bit zählen für mich nicht, wenn ich diese Speicherstellen nutzen möchte, wird das Programm kompliziert und unübersichtlich. Pro Weiche brauche ich etwa 15byte (15 Speicherstellen) Speicher, beim Propeller also 60byte. Bei 20 Weichen sind das schon 1200byte. Dazu kommen noch einige Signale und natürlich der Code. Es wird wohl reichen, aber nicht mehr sehr ausbaufähig sein. Die Daten vom gemeinsamen Speicher zu laden sehe ich als unsauber an. Andererseits könnte man die Auswertung auch auf mehrere Cogs verteilen.
Du siehst, ich habe mir durchaus gedanken gemacht (obwohl ich noch relativ jung bin) O:)
...und die Fehler ja machen darf.
Also ich möchte an dieser Stelle nochmal anmerken, daß der Propeller durchaus ein sehr leistungsfähiger µC ist...
das bedeutet aber noch lange nicht, daß damit automatisch alle anderen Mikrocontroller ihre Daseinsberechtigung verlieren. Ein Propeller muss nicht zwangsläufig für jedes Problem die beste Lösung sein, im Gegenteil.
Mit manchen Aufgaben wäre ein Propeller z.B. völlig unterfordert, da wäre es reine Geldverschwendung ihn trotzdem einzusetzen.
Umgekehrt gibt es natürlich auch Aufgaben mit denen ein Propeller überfordert wäre, dort sollte man dann sinnvollerweise zu einem leistungsfähigeren Controller greifen, anstatt sich an den Propeller zu klammern.
Das g,leiche gilt natürlich auch für alle anderen Mikrocontroller...
Ich z.B. mag die ATmegas von Atmel und verwende sie sehr gern, dennoch würde ich nie auf die Idee kommen sie für Aufgaben einzusetzen für die sie nicht geeignet sind.
DIN1234, nicht böse sein, war ja nicht so gemeint. Habe halt nur selbst schon ausreichend viele Fehler gemacht, um andere zumindest darauf aufmerksam zu machen. Und auch etwas beim Verstehen zu helfen.
Was die Cogs angeht:
Jeder Cog hat 2 KByte Speicher. Diese nutzt man nur, wenn man in Assembler programmiert. Das Assemblerprogramm liegt in diesem Speicher, wird von dem Cog ausgeführt und nutzt auch Speicherstellen des Speichers. Es kann aber jederzeit -natürlich langsamer- auf die 32 K gemeinsamen Speicher zugreifen und sich mit anderen austauschen. Es können also insgesamt 8 Prozessoren parallel laufen und auf einen gemeinsamen Datenbestand arbeiten.
Werden aber Spinprogramme geladen, dann sieht die Sache anders aus. Dann sind die Cogs mit ihrem Speicher nicht direkt zugänglich. Vielmehr ist dann in den 2 K jeweils die virtuelle Spin-Maschine geladen (wie etwa eine Javamaschine oder ein Basicinterpreter) und der eigentliche Programmcode steht im 32K gemeinsamen Speicher also Byte-Code. Der Compiler übersetzt also SPIN in sehr kompakten Bytecode, der wird in den Globalen Speicher geladen und von der Spin Maschine Befehl für Befehl gelesen und ausgeführt.
Während man in Assembler Programmschleifen mit weit mehr als 1 MHz Zyklen schreiben kann, sind Spin-Programme irgendwo 10 bis 20 KHz schnell.
Ich will die anderen Prozessoren nicht schlecht machen ( das ist nicht nötig ;-> ) der Propeller kann einfach Dinge, die man ansonsten nicht erträumen kann und der Preis ist sicher nicht das wichtigste. Ich habe mir mal andere Prozessoren mit 20 Mips und 32 K angesehen, die sind auch nicht wirklich billig.
Und, wie bereits gesagt: man ist einfach der Herr der Cogs. Man hat alles im Griff, mit Stärken und Schwächen.
Hallo zusammen,
ich möchte die Eingabe über ein Tastenfeld mit 8mal2-Matrix machen(das Tastenfeld habe ich schon). Wenn ich die Interruptfunktion verwende, heißt das, mein (Haupt-)Programm läuft erst weiter, wenn ich die Taste wieder los lasse. Das möchte ich aber nicht, sondern die Auswertung und die Ausgabe sollten direkt nach der steigenden Flanke folgen und nicht erst, wenn ich wieder los lasse. (@ ErNa, ich weiß, beim Prop. wäre das kein Problem...)
Ich habe mir zwei möglichkeiten überlegt:
1. Zwei Controller, einer für die Eingabe, der andere für die Auswertung und Ausgabe.
2. Timerinterrupt, der beispielsweise jede 30 Takte die Tastatur auf Veränderung abfragt, sodass man nie ganz aus dem Auswerteprogramm rauskommt.
Was meint ihr dazu? Bessere Lösung(en)?
Also noch ist bei mir alles Gedanklich, richtig angefangen habe ich noch nicht.
@ErNa
Die Funktionsweise weiß ich, die Vorteile kenne ich auch, aber zwischen 17EUR und 3 liegt doch ein Unterschied, für das, dass man (hoffentlich) das selbe Ergebnis bekommt.
Des weiteren muss ich mich als Student auch an das Verbreitetere halten (Warum, um die Standards zu kennen?). Aber ich vergess den Propeller bestimmt nicht, nur momentan ist die Entscheidung gefallen.
gruß
Wenn ich die Interruptfunktion verwende, heißt das, mein (Haupt-)Programm läuft erst weiter, wenn ich die Taste wieder los lasse.Also das kann ich nicht nachvollziehen...
normalerweise sollte z.B. bei der steigenden Flanke die ISR betreten werden, und wenn sie abgearbeitet ist geht es sofort im Hauptprogramm weiter.
Bei einer ganzen Matrix würde ich es aber ohnehin anders machen, nämlich ähnlich wie dein zweiter Vorschlag:
- Timer ISR erzeugt einen Takt von z.B. 1ms
- Tastatur wird im Hauptprogramm gepollt
- Wenn Tastendruck erkannt wurde: warte n Timer Intervalle ab und schau nach ob die Taste immernoch gedrückt ist (entprellen)
Früher gab es mal einen Witz: Der Professor gibt den Studenten auf, das Telefonbuch auswendig zu lernen. Fragen die Studenten: "bis wann", waren's Mediziner, fragen sie "wozu", waren es Physiker.
Zwischenzeitlich muss man diesen Witz erklären.
Der Erfolg der Prozessoren liegt natürlich darin, dass die Lehre nicht mehr frei ist, sondern auf die Wirtschaft ausgerichtet. Aber man muss nicht alles mit und mit sich machen lassen.
@ Felix
zur Auslösung des Interrupt müsste die Matrix als ganzes betrachtet werden (Alle Matrixeingänge high, Ausgänge zusammenfassen zum Int) und sobald der Interrupt ausgelöst wird Zeilen- oder Spaltenweise, dadurch fällt der Pegel am Interrupteingang wieder. Sobald die ISR durchlaufen ist, würde diese wieder aufgerufen, da ich ja länger (als die ISR braucht) auf die Taste drücke. es wäre bestimmt ein gewisser (Löt-) Aufwand, den Interrupt weiterhin hoch zu halten. Die Timermethode ist wohl am geschicktesten.
PS:Teile hab ich bestellt, kann bald losgehen... O:)
Stimmt glaub doch nicht, was ich gesagt habe. Wenn der Int-Eingang wieder auf high ist, bevor die ISR zuende ist, löst ja der Interrupt nicht mehr aus.
Es ist ja nicht so, als hätte ich nicht selbst schon Interrupts gequält. Und dann beißen die halt zurück. Und so sieht eine Problemlösung in SPIN aus, die mit 8 Pins 16 Tasten und Dioden bedient. Das ist eben genau der Punkt: eine Stunde Lebenszeit ist nicht mit Geld aufzuwiegen. Und wenn dann mal so nebenbei noch ein VGA-Monitor, eine Tastatur und eine Maus, inklusive Kopfhöhrer und Mikrofon von einem Chip gemanaged wird, dann ist das eben mehr wert als 3 Euro. Man kauft sich ja ein Auto auch nicht zum Fahren, sondern als zweite Haut.
''*****************************
''* IOMatrix 0.0 *
''* (C) 2007 Nascma GmbH *
''*****************************
{{ Dieses Programm bearbeitet 16 Taster und 16 Leuchtdioden in einer Matrixschaltung.
Es werden 4+4 Pins benötigt zum Treiben von Reihen und Kolonnen. Die Dioden sind von
den Reihen zu den Kolonnen geschaltet, die Schalter sind mit Widerständen 1 K in Serie
parallel zu den Dioden geschaltet. Die Reihen sind mit Widerständen 10 K nach Masse
gelegt.
Die beiden Gruppen der Pins müssen zu je 4 aufeinanderfolgen.
Die Eingänge sind entprellt.
Die Schalter werden gescannt und das Ergebnis erhöht (gedrückt) oder erniedrigt (offen)
die Variable Button (Intervallgrenzen 0 - Entprellwert). Erreicht die Variable einen
Grenzwert, wird geprüft, ob sich sich verändert hat (ButtonStatus). Falls ja, wird der
Status aktualisiert und ein Trigger ausgelöst (ButtonTrigger). Der Trigger wird
durch die verarbeitende Routine quittiert.
Die Ausgänge repräsentieren den Wert der Variablen LEDStatus.
}}
CON
_clkmode = xtal1+pll16x
_clkfreq = 80_000_000
RowD = 0
RowC = 1
RowB = 2
RowA = 3
Col4 = 4
Col3 = 5
Col2 = 6
Col1 = 7
Deboun = 2 ' Zählerstand fürs Entprellen
VAR
long vga_status 'status: off/visible/invisible read-only (21 contiguous longs)
byte Button[16]
byte ButSta[16]
byte ButTog[16]
byte LEDSta[16]
OBJ
vga : "vga"
PUB begin | Index, RowIdx, ColIdx
bytefill (@Button, 0, 64)
dira[Col4..Col1]~~ 'Spalten sind immer Ausgänge
outa[Col4..Col1]~~ 'Spalten sind immer Ausgänge
' dira[8]~~ 'Trigger nur zum testen!
repeat ' Eine Schleife auf ewig
' outa[8] := 1 nur zum Testen, Oszi Trigger
' waitcnt(clkfreq/5000 + cnt) '1 ms warte
' outa[8] := 0
Index := 0 ' Index geht von 0 bis 15
repeat RowIdx from RowA to RowD ' Für die 4 Zeilen, = PinNummer
repeat ColIdx from Col1 to Col4 ' Für die 4 Spalten, = PinNummer
' Taster testen
dira[ColIdx]~~
outa[ColIdx]~~ ' Ausgang setzen
dira[RowIdx]~ ' Die Reihe wird gelesen
' waitcnt(400 + cnt) 'Minimales Warten
if ina [RowIdx] ' Schalter ist geschlossen!
Button[Index] := 0 #> Button[Index] - 1
' LEDSta[Index] := LEDSta[Index] ^ %1
else ' Schalter ist offen!
Button[Index] := Deboun <# Button[Index] + 1
case Button[Index]
0:
if ButSta[Index] == 1
ButTog [Index] := 1
ButSta[Index] := 0
Deboun:
if ButSta[Index] == 0
ButTog [Index] := 1
ButSta[Index] := 1
' LEDStatus togglen
if ButTog[Index] == 1
ButTog[Index] := 0
if ButSta[Index]
LEDSta[Index] := LEDSta[Index] ^ %1
' LED schalten
dira[RowIdx]~~
outa[ColIdx] := LEDSta[Index] 'Ausgang setzen LOW
outa[RowIdx] := !LEDSta[Index]
waitcnt(clkfreq/1000 + cnt) '1 ms warte
outa[RowIdx] := 0
dira[ColIdx]~
Index ++
Der Code ist natürlich etwas tricky, da die Pins als Eingänge und Ausgänge genutzt werden. Aber doch noch ganz überschaubar.
ja, das ist eine gute Idee. Wenn ich das Programm richtig verstanden habe, werden die Taster in Sperrrichtung der LEDs abgefragt. Allerdings sind 8 Pins ja auch nicht wenig. Für mein Matrix(2x8)-Tastenfeld verwende ich einen 3zu8 Decoder, dann brauche ich noch 2 Eingänge, insgesamt also 5 Pins. Mir scheint, dass sich manche (Mikrocontrollerprogger) nicht recht an Hardware "trauen" und alles über Softwarelösungen machen möchten. Ich kann bei meinem Projekt nicht so verschwenderisch sein (mit den I/O-Pins).
Die Zeit seh ich nicht so als Problem (auch wenn ich gerade wenig davon habe), der Weg ist schließlich das Ziel. Und jedes Problem hilft einem, ein späteres viell. von vornherein zu umgehen.
Gibt es auch schon ein On-Controller-Compiler, wenn du schon Monitor, Maus, Tastatur... hast. *späßle
@ErNa
Das Problem lässt sich nicht nur mit Spin, sondern mit so ziemlich jeder Programmiersprache schnell und einfach lösen...
jetzt mal abgesehen von Sprachen wie Whitespace oder Brainfuck, aber damit ist nichtmal hello world einfach ;)
@Din1234
Es hindert dich Niemand daran den verwendeten Interrupt in der ISR (also nachdem die erste Flanke erkannt wurde) abzuschalten, und ihn erst in der Timer ISR (nach der vollständigen Auswertung inkl. Entprellung) wieder zu aktivieren.
Es gibt immer mehrere Wege zum Ziel
Natürlich. Aber es gibt so einen schönen Effekt: das Programm läuft full speed und immer, also keine ISR und damit auch keine Timingprobleme. Das ist der Vorteil von Multicore
@ErNa
Ich glaub wir drehen uns hier im Kreis
klar, das ist eben der Unterschied zu Multitasking oder Interrupt, da ist das eine Sünde, hier Vergnügen. PS: Wenn man Pins zählt, dann muss man sich klarmachen, dass in Mux natürlich ein zweites Gehäuse ist, und wenn man schon rechnet, dann richtig. Denn ein zweites Gehäuse ist recht viel teurer. ;-)
das hab ich jetzt nicht ganz verstanden. was braucht ein neues Gehäuse? Der Decoder? Der kostet 15ct + 5ct Sockel + 6cm^2 Platine. Das Problem ist nicht dieses Tastenfeld mit von-mir-aus 8 benötigten Pins, sondern alles in allem. Für jede Weiche brache ich 2 Ausgänge, für die LED-Statusanzeige nochmals jeweils 2. Bei 25 Weichen sind das schon 100 Ausgänge (Zahlen nur als Rechenbeispiel). da hilft dann auch kein Multicore.
Ich sag auch nicht, dass ich die beste Lösung habe, ist halt eine.
grüße
Nichts gegen die Lösung, erlaube nur, dass ich ein solches Projekt "integral" betrachte, wegen mir auch transgalaktisch oder über den Wolken schwebend. Jede Stunde kostet Zeit und Zeit ist irgendwo Geld, auch wenn man einem Hobby nachgeht. Und es ist eben einfach schön, wenn man alles mit einem Werkzeug, mit einer Systematik erschlagen kann. Das erlauben die modernen Mikrocontroller sehr weitgehend. Am Ende steht aber doch irgendwo ein Stecker, ein Schalter, ein Magnet oder sonst was. Mit verteilten Prozessoren arbeiten ist eine sehr interessante Sache, die sozusagen auf Augenhöhe mit den Forschern von Begeisterten betrieben werden kann, denn die Forschung ist auch noch nicht so richtig durch. So wie früher die Radioamateure den Rundfunk beflügelt hatten.
Hallo ErNa,
sag uns doch mal, was du mit dem Propeller schon gemacht hast. Es ist doch nicht alles auf das Ergebnis ausgerichtet. Wenn du so genau auf die Zeit achten würdest, hättest du einiges wohl gar nicht gemacht, wegrationalisiert. Das wichtigste ist doch, dass man Probleme löst. Das macht doch Freude. Dich lockt der Multicore. Mich auch, aber momentan geht es mir nur um die Steuerung. Warum soll man mit Assembler programmieren, wenn man doch mit einer hohen Sprache effizienter sein kann? Ich glaube, gerade für Mikrocontroller im (gemäßigten)Hobbybereich ist das ideal, weil man damit doch tiefer drin steckt. Dich begeistert der Propeller ja auch gerade deshalb, weil du den Ablauf selbst bestimmen kannst und die Cogs verwaltest, und nicht weil du einfach nur weißt, dass 8 Stück zusammenarbeiten.
Lange Rede kurzer Sinn: Am Schluß muss es funktionieren und darf nicht frustrieren. Ich glaube, dass der AtMega dafür geeignet ist. Ob ich den einen oder anderen Controller nehme, ist letztlich nur eine Entscheidung, die zwar Konsequenzen hat, aber weder positive noch negative.
Erfahrung ist durch nichts zu ersetzen außer durch Erfahrung. Ich habe meinen erste 8080 noch mit 1000 DM bezahlt, und war stolz wie ein Wutz mit drei Ohren, dass ich den Hex-code eintippen konnte in den Monitor, das war so was wie das Bios.
Dann habe ich mit z80 und einer selbst gebauten Interruptkarte mehrere Messwerte erfasst, zwei Bildschirme bearbeitet und auf Disketten die Daten physisch weggeschrieben auf Spur und Sektor. Der Witz war: das z80 programm hatte nur interruptroutinen, kein "Hauptprogramm". Wenn eine Routine eine andere starten wollte, hat sie eine über einen Multiplexer ein Signal ausgegeben, das von einen Demultiplexer wieder eingelesen wurde. Und dann kommt MSDos und man erzählt den Leuten, ein Programmaufruf über eine bestimmte Adresse wäre ein Softwareinterrupt!
Dann gab es einen Transputer mit OCCAM als Programmiersprache mit Sprachelementen zur Synchronisation paralleler Prozesse. Das hat man dann auch wieder mit C kaputtprogrammiert, indem man Sockets machen musste für Funktionen, die eigentlich in der originalen Sprache elementar waren! Ich bin einfach der Meinung, dass es sehr viel Blendwerk gibt und dass dieses die eigentlichen Prinzipien einer guten Soft- und Hardware verdeckt. Und der Propeller ist hier eine Offenbarung, auch wenn er Schwächen hat. Vom Standpunkt der "Alten" ist eigentlich jeder Controller eine Offenbarung, denn zum Preis einer Schachtel Zigaretten bekommt man etwas, für das man früher eine Urlaubsreise einsetzten musste. Ok, genug gejammert! :-({|= :-b :wink:
Sodele, jetzt bin ich einen Schritt weiter! Nach einigen Unwegbarkeiten funktioniert die Tastenfeldabfrage einigermaßen, bis jetzt kann ich nur unterschiedliche Tasten nacheinander Drücken und manchmal 'rutscht' ein falscher Wert mit rein. Ein LCDisplay hab ich auch zum Laufen gekriegt! Manche Fehler, die ich gemacht hab, waren echt ärgerlich! Und weitere folgen noch...
Ich möchte eine größere Menge Binärwerte in den Programmspeicher schreiben, gibt es dafür eine einfache Möglichkeit? Bis jetzt öffne ich die hex-Datei mit Ponyprog, speichere sie binär ab, und setze dann mit Hilfe eines kleinen Programms meine Binärwerte an das Ende des Programmcodes. Da müsste es doch eine [edit:] einfachere Möglichkeit geben!?
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.