Beiträge von ThomasWest

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Vorsicht! Mikroschritt erhöht nur die Auflösung, nicht die Genauigkeit. Vom Drehmoment mal ganz abgesehen. Ob man damit wirklich die Getriebeuntersetzung reduzieren kann, wird man bei jedem Hardware-Setup testen müssen.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

Da kann ich nur zustimmen. Geringere Getriebeauflösung geht damit kaum. Allerdings wird der Motorlauf deutlich ruhiger bei der normalen Nachführung. Man sollte allerdings bei schnellem GoTo tunlichst auf Fullstep schalten, weil sonst Drehmoment und Geschwindigkeit verloren gehen.

Ich würde sowas heute irgendwie mit einem guten Videobeamer machen.
Also nen Beamer und da eine art umgekehrtes Fischauge drauf setzen um es auf 180° zu projezieren.

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Siehe HW-Pflichtenheft. Der soll die Eingangsspannung (12V) auf die 30V für den Antrieb wandeln und auch ordentlich Leistung bringen (120W), damit auch Schrittmotoren mit 56-Flansch, welche so um die 50W peek benötigen, betrieben werden können.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

Sportlich! Da bin ich gespannt wer das auf einer 80x100mm Platine unterbringt (also incl. Kühlkörper)

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Man könnte den DC-DC Wandler bereits auf der CPU-Platine mit unterbringen <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

Da muss ich doch mal nachfragen, welche Aufgabe der DC-DC Wandler haben soll. Spannungsversorgung der Steuerungelektronik (kein problem) oder als Stepupfür die Motoren. Ich nehme mal an, sowas wie aus 12V &gt;30V für die Motoren zu machen. Bei der Littlefoot wird das ja als V40Booster verkauft. Das geht sicher auch bis zu einer gewissen Stromstärke. Wenn man aber so in den Bereich von 3-4A pro Spule, somit also 8A/Motor (bzw. 16A für RA und DE zusammen) kommt, dann werden die Teile erstens teuer und zweitens auch groß. Ich weiß nicht welchen Strom das Teil der Littlefoot kann, aber ich denke das geht sinnvoll da auch nur bei geringeren Strömen (&lt;2A). Allerdings muss ich zugeben, daß ich mich mit dem Problem noch nicht befasst habe, da wir auf der Sternwarte eh überall schon 24V haben und so das Thema für mein Projekt nicht steht.

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Entscheidend dürfte aber eher sein, wie viele potentielle Entwickler damit Erfahrung haben oder Willens sind, sich einzuarbeiten.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

Also bei mir hat es nicht sehr lange gedauert um mich von Eagle auf KiCad einzuschießen (nur ein paar Tage). Die Bedienung ist ähnlich und zudem ist auch das KiCad Wiki eine gute Infoquelle.
Inzwischen ist KiCad erwachsen geworden. Es gab Zeiten, da musste man wirklich aufpassen ob man Werte mit Punkt oder mit Komma als Dezimaltrennzeichen eingegeben hat, aber wie gesagt, das waren Kinderkrankheiten. MAn darf bei KiCad nicht außer acht lassen, daß es auch ein Open Source Projekt ist und da auch eine Commuinity dahinter steht, die ständig weiterentwickelt. Sehr viel Bewegung gibt es auch in der zugehörigen Yahooh gruppe (allerdings nur in Englisch).
Ebenso wie Eagle läuft es auch unter Linux.

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Generell ist die Frage nach dem PCB-Programm aber eher nebensächlich, oder?<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
Nicht unbedingt. Wenn man dann immer hin und her konvertieren muss, nur weil einer Eagle, der andere XYZ und der nächste ABC verwendet, dann birgt das immer Fehlerquellen.

Da kann ich mich meinem Vorredner nur anschließen.
Mit Eagle habe ich auch mal angefangen. Dann bin ich aber ganz schnell zu KiCad gewechselt. Es gibt für KiCad auch ein Tool zum Konvertieren der Eagle-Bibliotheken. So kann keiner sagen es gäbe keine Bibliotheken. Hinzu kommt, daß man auch mit Kicad den Autorouter unter http://www.freerouting.net nutzen kann (Ok Eagle geht inzwischen auch mit dem). Der taugt meines Erachtens wesentlich mehr als der in Eagle integrierte. Inzwischen bin ich beim Altium Designer angekommen, aber der dürfte für ein Open Source Projekt außer Frage stehen weil zu teuer.

Also ich arbeite als Wissenschaftler bei der Fraunhofer Gesellschaft und ich würde es analog zum Auspruch in der Feuerzangenbowle mit Heinz Rühmann sagen - "Fraunhofer mit einem e"

BlueScreen?
Welches Betriebssystem? Welche MaximDL Version?

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Ganze Generationen von Astrofotografen haben mit mechanischen Uhrwerken oder elektronischen Motorsteuerungen, die durch stabilisierte Quarze getaktet wurden, nachgeführt<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

Ja klar, das kenne ich doch auch noch. Aber ab und zu musste man dann doch mal nachkorrigieren oder beim Fotografieren mit dem Fadenkreuzokular manuell nachführen. Wenn man aber shcon elektronische Hilfen hat, dann sollte man das doch gleich mit erledigen lassen. Der Sinn dieses Threads soll doch sein etwas neues zu entwickeln. Wenn man das nicht mcöhte, dann kann man doch auch gleich so was kaufen http://www.teleskop-express.de…ng-EQ-3---zweiachsig.html
Das ist dann die einfache Variante. Sowas muss man nicht wirklich neu entwickeln.

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Wenn ein AutoGuider angeschlossen wird sind solche - eh nur näherungsweisen - Korrekturrechnungen sowieso egal ...
Ein Interface für gängige Planetariumsprogramme muß solche Effekte dann einkalkulieren (können)<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

Mit dem Autoguider gebe ich Dir recht, wenn man nur nachführen will. Für andere Probleme geht es aber halt nicht mit Autoguider. Wenn ich von einem Objekt auf das nächste fahren will und das möglichst genau, dann wirds eng mit Autoguider. Das sind aber alles sachen, wie Steuerungen wie die FS2 oder auch andere können. Also nichts Neues.
Die Sache mit dem intelligenten Interface sehe ich allerdings kritisch. Soll das im ASCOM treiber auf dem PC gemacht werden. Der müsste dann aber auch genaue infos über die Montierung haben udn in beide Richtungen kommunizieren können. Da bin ich dafür, daß gleich in die Steuerung zu integrieren.

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">damit gibt es keine 'kleine Lösung', die nur aus programmiertem Steppermotor und Tastern besteht.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
Wie sollte das denn aussehen? Motor mit konstanter geschwindigkeit und einfach nachfrühren?
Du wirst es nicht schaffen ein Objetk einfach durch Nachführen mit einer konstanten Geschwindigkeit im Bildfeld zu halten. Da macht dir schon die Refraktion im Laufe der Nacht einen Strich durch die Rechnung. Die beträgt am horizont etwa 15 Bogenminuten, nimmt zum Zenit hin auf 0' ab und ist dann bis zum anderen Horizont 15 Bogenminuten in die andere Richtung. Das macht in Summe maximal 30 Bodgenminuten was etwa dem doppelten Monddurchmesser entspricht. Dabei ändert sich zu allem übel noch der Richtungsvektor und vom Luftdruck und der Beobachtungshöhe (Hochgebirge oder Meeresspiegel) ist sie auch noch abhängig. Man muss also zwangsläufig Koordinatenkorrekturen vornehmen, was eine gewisse intelligenz voraussetzt.
Da kommen wir dann zum Problem der Ansteuerung mittels Laptop oder PDA. Die gängigen Astroprogramme steuern meist das Teleskop nämlich meist nur per RA/DE Koordineten aus dem internen Katalog, sagen also der Steuerung daß sie diese Koordinaten anfahren soll. Diese Koordinaten entsprechen aber nicht der wahren position des Objektes am Himmel. Eine einfache Korrektur mittels aktueller Sternzeit in RA ist war usus, aber halt allein gesehen nicht 100%-ig genau. Da muss in jedem Falle die Steuerung ran und entsprechend der Beobachterposition, der Ausrichtung usw. entsprechende Umrechnungen vornehmen. Die Steuerung muss wissen, wie die Montierungsachsen zum entsprechenden astronomischen Koordinatensystem stehen und alle Fehler korrigieren.

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Was für neg. Erfahrungen hattest du mit dieser Kombination?
Wir würden von deinen Erfahrungen sicher profitieren.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

Die Kombination von TMC428 mit dem TMC249 ist im Prinzip nicht schlecht. Sie hatte aber für mich den Nachteil, daß der 428 in der Grundschaltung nur 16-fach Microstepping kann. Will man 64-fach Microstepping, dann muss man einen zusätzlichen 74HCT4094 verwenden. Will man dann noch das Chopsync(TM) verwenden um sehr hohe Motordrehzahlen zu bekommen dann kommt noch ein 74HCT4049 dazu. Wenn man jetzt noch eine sehr feine Regelung des Spulenstromes haben will sind noch ein OPV und 4 Transistoren und ein paar Widerstände nötig.
Das waren so die Hauptmankos, weshalb ich jetzt den TMC457 verwende. Der hat das alles integriert. Allerdings ist de rmit seinem BGA gehäuse halt nicht von jedermann lötbar (aber das hatten wir schon). Zudem kann der TMC457457 bis zu 2048-fach MNicrosteppung und er kann automatisch (also ab einer definierbaren Geschwindigkeit) mit einer kleinen Zusatzschaltung von Microstep auf Fullstep schalten. Damit hat der Motor dann volle Leistung bei hohen Geschwindigkeiten.

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Ich fürchte, man wird bei so einem Konzept keine Spezial-ICs direkt an die interne Schnittstelle hängen können, <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
Warum nicht? die Trinamic ICs ( z.B. 428 oder 457) haben einfach nur register in die mittels SPI hinein geschrieben werden kann. Das ist sehr universell. OK wenn man dann einen Servotreiber ran hängen will braüuchte man einen kleinen µC der das nachbildet. Sollte aber nicht schwer sein.

Schlagt euch die Torqemotoren für einen portablen Betrieb im Feldeinsatz aus dem Kopf. Ich habe selbst in der Gegend hier einen User mit einer ASA DDM-60. Die Teile brauchen ordentlich Strom und eignen sich daher nur für den stationären Bereich in Sternwarten. Im Feld sind die Akkus eins-zwei-fix leer. Im stationären Einsatz sind sie allerdings spitze
Schrittmotoren haben den vorteil, daß sie erstens billig sind, zweitens sich auch ohne Encoder genau positioniern lassen und die Ansteuerelektronik recht einfach gestrickt ist. Servomotoren haben den Vorteil, daß sie deutlich höhere Drehzahlen fahren können. Dafür sind sie teurer. Ein Servomotor ist ja im Prinzip ein DC-Motor mit einem Encoder dran und einer internen Regelung.

Mit einem modularen Design könnte man prinzipiell auch Servomotoren ansteuern. Die werden sich meiner Meinung eh irgendwann durchsetzen. Allerdings wird es dann teurer, insbesondere die Encoder kosten wenn man genau sein will eine Unmenge.
Dazu müsste dann der Motorcontroller und die Treiberstufe ein extra Modul sein. Ich ziehe das gerade bei mir durch. Man muss dann nur sicherstellen, daß das Protokoll vom Hauptcontroller zum Schrittmotorcontroller so ausgelegt ist, daß wirklich nur eine Positionsangabe bzw. Geschwindigeit und Richtung übertragen wird.

Was den Betrieb von Alt/AZ bzw. deutschen Montierungen angeht, so sehe ich da eigentlich kein Problem. Auch muss man nicht irgendwelche Modelle integrieren. Die Steuerung muss eh über Koordinatenrechnungen verfügen, umd die Koordinaten aus den Katalogen in wahre Himmelskoordinaten umzurechnen. Zudem mus auch immer ein Misalignment der Polachse mit korrigiert werden wenn das Teleskop nicht ordnungsgemäß gescheinert ist. Da sind zwangsweise Umrechnungen vom Äquatorialsystem ins Alt/AZ System und zurück nötig. Es fallen also beide Koordinatentypen an. Ich nutze sie zum Beispiel zur Steuerung der Kuppel obwohl wir eine deutsche Montierung haben. Wenn man einen Dobsen steuern will, dann schickt man einfach die wahren ALT/AZ Koorinaten des Objektes an den Motorcontroller und bei parallaktischer Montierung halt die wahren Äquatorialkoordinaten. Man muss halt nur in den Grenzbereichen (Meridan oder Zenit) aufpassen.

Also ich verwende bei meinem neuen Prototypen als Hauptprozessor einen ATXMega128 als Hauptptozessor. Dieser steuert per SPI jeweis einen TMC457 für RA und DE (oder ALT und AZ) an. Über einen Expansionsstecker auf der Platine lassen sich 3 weitere Stufen ansteuern. Der TMC457 macht genau das was martin.c mit den Slaveprozessoren (mega8 oder Mega16) machen will. Den Vorteil des TMC457 sehe ich allerdings darin, daß er erstend das GAnze Hardwaremäßig macht und zudem genau auf die Trinamic Treiberstufen abgestimmt ist. Im Falle eines Slave-Prozessors müsste man für den dann auch wieder eine Firmware schreiben.
Von einer Direkten ansteuerung einer Schrittmotorstufe vom Hauptprozessor aus halte ich überhaupt nichts. Bei hohen Geschwindigkeiten kommt der dann irgendwann an seine Grenzen. Wenn er dann auch noch encoder auswerten muss wirds noch mal etwas enger.

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Im übrigen sehe ich mit etwas Sorge, daß sich 95% der Diskussion um Software und Schnittstellen dreht, aber fast keiner konkret sagt, wie die Ansteuerung der Motortreiber sein soll. <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
Sehe ich genauso. Deshalb hab ich mich erst mal raus gehalten. Man sollte erst mal eine Hardware haben und sehen, daß die läuft. Ich bin da auch shcon mal drauf rein gefallen, und hatte dann einen prototypen, der zwar lief, aber leider nur mehr schlecht als recht. Das ist dann frustrierend, wenn man eine Treiberstufe nochmal umkonstruieren muss, nur weil man eine Kleinigkeit nicht beachtet hat.
Oft höre ich so Sätze wie 'na das mache ich dann in der Firmware'. Ich denke es ist ein großer Irrtum, den ich leider immer wieder bei Programmierern antreffe, zu glauben, man könne alles was man in der Hardware versäumt haben dann softwaremäßig realisieren. Deshalb denke ich auch, daß als erster Schritt die Hardware fertig sein sollte. Dann kann man da nen Prozesssor drauf setzen und sich an die Kommunikation machen.

Bevor man sich über UDP/TCP unterhält sollte man vielleicht mal klären, welche Programme sowas überhaupt unterstützen. Ich denke Guide, Starrynight, TheSky usw. sollten das nicht können. Da müsste man dann auf jeden Fall wieder einen ASCOM Treiber schreiben.

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Diese beiden Komponenten brauchen zwar ein definiertes Interface, aber das wird sicher keinen Webserver brauchen :)<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
Der XPORT von Lantronix hat zwar auch einen Webserver, aber auch einen "Serial Tunnel". Der ist für den Anfang interessanter. Für den PC gibt es einen Treiber, der einen virtuellen COM Port erstellt. Damit kann dann zum Beispiel jedes LX200 kompatible Programm von irgendwo augf der Welt per Internet auf den hinter dem XPORT hängenden Prozessor zugreifen, so als wäre er per RS232-Kabel angeschlossen. Man kann die Verbindung auch verschlüsseln und somit die Sicherheit erhöhen.
Also bei mir klappt das Super. Man muss nur die entsprechenden Ports vom DSL-Router an den XPORT im lokalen Netzwerk weiterleiten.

Hallo lorchi.
Da hast du mich falsch verstanden.
Das ist nicht die Platine die dann in der Steuerung drin ist. Mir ging es einfach nur mal darum die Einzelkomponenten (Prozessorboard, V-DIP2, Lantronix XPort usw.) auf ihr Zusammenspiel zu testen. Da aber leider das Prozessorboard kein Standardraster hat passt es nicht auf ein Breadboard. Deshalb habe ich halt dieses Platinchen geäzt und alles mal drauf gepackt. Man sieht ja auch schon, daß das Display einfach da hinten rum hängt und nur ein paar Taster dran sind.

Also ich will mich mal wieder in die Geschichte rein hängen.
Zum Thema USB gibt es fertige Lösungen, die auch Speichersticks usw unterstützen. mit dem FTDI kommt man dann nicht mehr weit. Ich habe bei mir im Prototyp das vinculum V-DIP2 Modul drin.
Was Ethernet angeht, setze ich voll auf den Lantronix XPORT Pro. Der ist kaum größer als eine Netzwerkbuchse, hat aber einen kompletten prozessor mit Flash usw drin. Da läuft ein Webserver drauf. Zur kommunikation mit dem XMEGA den ich verwende gibt es eine Serielle schnittstelle. Lest euch einfach mal die Doku durch.
Zum Testen hatte ich das ganze mal auf eine kleine Leiterplatte gebaut. Das schaut dann so aus. Zu einer fertigen Steuerung fehlt da nur die Motorstufe und das Netzteil

Der Xport sitzt unter dem Prozessormodul und das Vinculum-Modul daneben. Für die eile muss man auch nicht SMD löten können.

Hier kam ab und zu mal der Anstoß mit dem Touch-Panel. Auch wenn es das Display welches ich verwende für 10€ mehr als Touch variante gibt habe ich diese Idee so ziemlich am Anfang verworfen. Gerade im Winter wenn es kalt ist und man wenn mannoch dicke Handschuhe an hat ist sowas nicht zu bedienen.
Stellt euch vor Ihr schaut durch das Okular und wollt umher fahren. Wenn Ihr ein Touch panel nehmt müsstet ihr immer wieder auf das Panel schauen, und die augen vom Okular lösen. Tasten die man "ertasten" kann sind da eingeutig im Vorteil. Am besten noch mit spürbarem Klick oder Druckpunkt. Ob man eine numerische Tastastur mit Zahlenfeld wie bei mit einbaut oder nur die Cursortasten nimmt und dann über schalterchen die Menüsteuerung macht wie bei der Littlefoot ist letztendlich eine Frage der Philosophie.

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">sehe ich nur bei den derzeitigen Steuerungsherstellern, die glauben, dass ihre 08/15 Schaltungstechnik und Programmlösungen die Krone der technischen Schöpfung seien, die vor der Öffentlichkeit geschützt werden müssten.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

Nun ich glaube nicht,daß die das selbst so sehen. Das wiurde eher von andern personen so dargestellt und hat sich leichder zur weitläuftigen Meinung etabliert. IcH denke, und zum Teil weiß ich es auch, daß es da durchaus auch andere Gründe gibt, weshalb sich da nicht viel tut.

Also GPS ist wirklich einfach, das kann ich bestätigen.
In meiner ersten Version hatte ich einfach eine GPS-Maus für nen PDA dran gehängt. Die hatte 5V Pegel und RS232 und ich konnte sie sogar direkt an den Controller anklemmen. Da war aber eine Mini-Din-Buchse nötig. Dann bin ich auf USB-Maus gewechselt, habe das aber wieder verworfen, weil aufgrund der Preisentwicklung die Internen Module günstiger waren. Jetzt habe ich ein schnuckeliges kleines und wirklich richtig gutes im Handcontroller drin. Das hat nur was um die 34.-€ gekostet und hat den neusten Chipsatz.

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Pascal älter als C, Java ein C-Nachfolger etc.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
Pascal wurde von Niklaus Wirth an der ETH Zürich 1972 als Lehrsprache eingeführt, um die strukturierte Programmierung zu etablieren. C wurde 1971–1973 von Dennis Ritchie in den Bell Laboratories für die Programmierung des damals neuen UNIX-Betriebssystems entwickelt. Gut da kann man sich streiten.

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Da es heutzutage nichts mehr gibt, was man mit anderen Sprachen nicht besser lösen könnte, ist Pascal zu Recht in den 90ern ausgestorben<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
Das überrascht mich jetzt aber sehr, weil mir das noch gar nicht aufgefallen ist! Und etliche anderen leuten auch nicht. Es gibt für wirklich jedes System, egal ob Hardware oder Betriebssystem mindestens einen passenden Pascal-Compiler. Bei Windows ist das am weitesten verbreitete Produkt Delphi von Embarcadero (ehemals Borland). Das kann übrigens nicht nur Einfachen Windows Code erzeugen sondern auch Unix und .NET. Zudem gibts noch einige ander kleinere Pascal Compiler. Im Bereich der Mocrocontroller hat sich bei den AVR-Controller E-Lab's AVRCo und MicroPascal durchgesetzt. Selbst die vorher im Thread gemachte Aussage, daß es für ARM kein Pascal gibt ist absolut Nonsens. FreePascal kann ARM Code erzeugen und nicht nur das. FreePascal unterstützt IA-32 (Intel 80386 und Kompatible),PowerPC,PowerPC64,ARM,Sun SPARC v8 und v9,AMD64 (x86_64) und als Betriebssysteme AmigaOS (Version 4.0), MorphOS,Linux (alle CPUs),FreeBSD,Mac OS X und Darwin (PowerPC und Intel),DOS (Go32V2 extender),Win32 und Win64,OS/2 (EMX und nativ),Novell NetWare,ZETA/Haiku,Windows CE,Game Boy Advance
Nintendo DS. IM embedded Bereich gibt es für Pascal Multitasking Systeme. Bei denen muss ich nicht erst das RTOS irgendwie zurecht stricken und anpassen. Alles fix und fertig.
Es ist erstaunlich, daß ein "totes System" soviel Eigenleben entwickelt. Zudem weiß ich aus eigener Erfahrung, daß es viele Dinge gibt, die man in Pascal deutlich komfortabler machen kann als in C und es gibt sogar einen C To Pascal Converter für Leute, die die Lager wechseln wollen.

Was Java angeht, so ist diese in der Tat aus C hervorgegangen und daß nicht nur durch die Syntaxähnlichkeit. In Java finden sich viele Einflüsse aus C++, Smalltalk, Objective C und C#. Nur hat man dort versucht eben die Defizite aus C zu beseitigen und das auch konsequent umgesetzt. So werden die häufigsten Dinge, die in C Probleme machen, wenn der Programmierer nicht sorgfältig ist wie beispielsweise Operator Overloading, Pointer, Mehrfachvererbung nicht unterstützt. Das bietet mehr Sicherheit schon vom Comipler aus.

Wie ich bereits schon mal geschrieben habe, bin ich in beiden Welten zu Hause, aber mein Favorit ist halt Pascal.

Übrigens an welcher Uni lernt man heute noch C? Also unsere Informatiker setzten inzwischen sehr auf Java. C machen bei uns nur die die Embedded Systems entwickeln. Da kosten die Compiler halt nix.

Übrigens gib mir mal ein Beispiel was man mit C besser machen kann als mit Pascal.

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">
zur Diskussion C oder nicht C:
Schaut z.B. mal auf http://www.trinamic.com/tmc/render.php?sess_pid=292
Da gibt es z.B rechts Code zur Mikroschrittansteuerung - natürlich in C...
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

Naja also ich hab ne Trinamic Bibliothek in Pascal
Aber hast schon recht, viele Hersteller liefern halt C code weil das irgendwo der kleinste gemeinsame Nenner ist.
Halt nicht mehr Maschinencode aber halt auch keine richtige Hochsprache.
Ich denke die Diskussion üb C, Pascal, BASCOM oder Schlagmichtodirgendwas ist für das projekt irrelevant und sollte auf einen eigenen Thread verlegt werden. Ansonsten läuft man gefahr vom eigentlichen Threadthema abzuweichen.

Vielleicht macht man ja hier ein Unterforum " Astrotreff-Steuerungsprojekt" auf in dem dann alle Threads zum Thema gesammelt werden.

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Jede CPU kann damit bestens umgehen und die Verwendung selbiger ergibt meistens auch den effektiveren und schnelleren Code.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

Klar kann jede CPU damit umgehen, aber für das Gehirn eines Menschen gibt es bessere Darstellungsformen. Man muss nicht wirklich wissen, wo eine Variable liegt um auf sie zuzugreifen. Man handelt sich aber durch Zeiger oft Fehlerquellen ein, wenn man nicht aufpasst wohin man zeigt. Die meisten Windows Sicherheitslecks sind auf unsaubere Zeigerroutinen zurückzuführen. Wenn man da nicht aufpasst, dann kann man schnell in Bereiche schreiben, wo eigentlich keine Daten sondern Code liegt und somit kann man Fremdcode einschleusen.
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Wenn man das Prinzip verstanden hat, ist es eigentlich ziemlich Genial :-)<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
Aber genau da liegt das Problem. Man muss es erst mal verstehen und halt höllisch aufpassen.

Letztendlich ist es eine Frage des Compilers. Der erzeugt den ja Code der auf der CPU ausgeführt wird und bestimmt damit die Effizienz des Codes unabhängig von der verwendeten Hochsprache. Auch Pascal verwendet übrigens im generierten Code Zeiger! Die eigentliche Hochsprache, mit der man es aber als Entwickler zu tun hat, kommt gänzlich ohne aus (aus Kompatibilitätsgründen sind die aber auch mit drin). Dafür ist Pascal wesentlich weniger fehleranfällig. Viele Fallstricke von C läßt Pascal per se nicht zu. So ist es zum Beispiel überhaupt nicht möglich, auf Elemente außerhalb eines Array zu schreiben. Auch die Stringverarbeitugsfunktionen von Pascal sind um Klassen besser.

Ob ein Code hingegen schnell und effizient ist hängt nicht von der Verwendung von Zeigern ab. Das ist eine Mär, die gern von C Entwicklern verbreitet wird, C rzeuge pauschal den schnelleren Code. Moderne Pascal Compiler sind was den generierten Code angeht ebenbürtig.

Hier mal ein Vergleich der Sprachen und der Mythen um C
http://www.bernd-leitenberger.de/pascal-und-c.shtml
Es reicht für das grobe Verständnis die Abschnitte "Zusammenfassung" und "Warum ist C so erfolgreich" zu lesen.
Wer es genauer wissen will der sollte kann auch alles lesen.

Letztendlich kommt es doch auf eines an: Jeder Entwickler ist mit irgendeiner Sprache groß geworden und diese beherrscht er. Eine andere Sprache zu lernen ist meist schwierig und man ist immer geneigt in der neuen Sprache genauso zu programmieren wie in der alten die man in- und auswändig kennt. Letztlich ist es eine Frage der Entwicklereffizienz. Was man kennt, geht schneller.
Ich selbst entwickle sowohl in Pascal, Java als auch in C (obwoh ich es nicht mag ;-), aber weil ich es muss). Pascal ist mein Favorit, weil es sehr strukturiert, sehr leicht zu lesen und auch nach Jahren immer noch verständlich ist. Ich kenne genug C Programmierer, die nach Jahren Ihren eigenen Code nur noch mit Mühen verstehen können, weil sie geneigt waren alles so "effizient" wie möglich zu programmieren.

Mal ganz abgesehen davon, was spricht dagegen in beiden Systemen zu entwickeln. Wenn die Hardware einmal steht, dann kann man verschiedne Firmware-Systeme drauf setzen. Das klappt beim PC doch auch. Da gibt es auch Windows und UNIX auf einer Hardwareplattform.