Was meint ihr, sinnvoll oder Spinnerei? - Neulingsfragen :)

[Felix G]

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.

[ErNa]

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ß!

[DIN1234]

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.


Momentan habe ich wenig Zeit, ich melde mich wieder, wenn ich einen Schritt weiter bin.

grüße

[ErNa]

Jeder ist seines Glückes Schmied! http://propellerforum.sps-welt.de/vi...r=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.

[DIN1234]

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)
...und die Fehler ja machen darf.

[Felix G]

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.

[ErNa]

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.

[DIN1234]

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.

[DIN1234]

@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ß

[Felix G]

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)