Selbstbausteuerung mit open source fw?

Hallo liebe Leute,

ein paar Tage nicht in den Astrotreff geschaut, und schon gibt es hier eine sehr spannende Diskussion. Ich habe großes Interesse daran. Hier mal ein paar Gedanken dazu:

- die Trennung von Hardware und Intelligenz ist bisher das wichtigste. Wie die Intelligenz dann aussehen kann, ist erstmal frei, von 4 Richtungstasten in einer Streichholzschachtel bis zur Steuerung komplett als Computersoftware wäre alles drin.
- beim Lesen der 9 Seiten dachte ich immer wieder: und was ist mit meinem Fokussierer? Den Endlagenschaltern? Dem Filterrad? Den soundso? Dann kam Steffens Vorschlag mit vernetzten Einzelmodulen. Ja bingo, das konsequente Weiterdenken in Richtung Modularisierung (HW, SW, Interfaces) macht alles zwar abstrakter, aber besser zu handhaben und zu entwerfen und zu debuggen und anzupassen, man muss sich nur entschließen den initialen Aufwand zu schultern und gewinnt dann, war schon immer so...
- es wurden hier schon diverse Richtwerte genannt (Maximalspannung, -strom, ...). Die sind ja gut fürs erste Verständnis der Idee, aber worauf gründen sie sich? Ins Pflichtenheft gehört also erstmal noch das Sammeln von Anforderungen!
- Entwicklungsstandards gemeinsam setzen (Sprache, Austauschformate, Doku, Entwicklungsumgebung inkl. Versionskontrolle und Anforderungsmanagement, Rechte und Zuständigkeiten, Best Practices, Funktions-/ Unit-/ Regression-Tests). Es reicht nicht, ein paar Details davon hier im Thread zu fordern. Klingt zwar hart und bürokratisch, ist m. E. nach aber unerlässlich. Alles was man hier vergisst, wird stillschweigend angenommen und Missverständnisse sind vorprogrammiert. Es unterstützt auch bei evt. Änderungen im "Personal"...

Ich möchte mich auch gerne anbieten. Was ich Euch bieten kann, sind ein nutzloser Dipl.-Ing.-E-Technik-Titel (weil ich seit 10 Jahren fast nichts mehr mit Strom mache, aber immerhin als Background), stattdessen 10 Jahre Programmiererfahrung im Bereich Forschung, Algorithmik, Signalverarbeitung, Schnittstellen für Industrie, ESO, DLR, teilweise mit Echtzeithintergrund. Sprachen hauptsächlich C, C++, IDL, Matlab. Wichtig sind mir modulare, verständliche, wartbare und sauber definierte Geschichten. Zeit habe ich nicht unbegrenzt, aber Bereitschaft für verschiedene Aufgaben. Ansonsten bin ich Techniker, kein Betriebswirt...

Jo, soweit dazu...

Schöne Grüße, Henning

<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.

Schöner Thread!

Arduino ist übriges offen, preiswert und spricht etwas wie C, wobei man auf etliche Fertiglösungen zugreifen kann.

Man wird sich sicher schnell daruaf einigen, daß das Projekt ein Schichtenmodell irgendeiner Art abbilden wird und daß man die untersten Schichten (Motorsteuerung evtl. bis hin zur Positionierung) wohl auf Mikrocontrollern realisieren kann, während alles darüber vielleicht auf Netbook oder ähnlichem läuft.

Henning hat aber vollkommen Recht. Selbst für den einsamen Bastler im stillen Kämmerlein macht es wenig Sinn, einfach loszuentwickeln - und Ideen sind einfach, der Teufel sitzt aber in Realisierung und Detail.

(Dilbert: "Welche Farbe soll die Datenbank haben?" Chef: "Rosa, hat am meisten RAM!")

Aber was man vorher klären könnte: Welche Standards existieren eigentlich bezüglich der Kommunikation mit und innerhalb von Montierungen? Wenn sich die "lower layer"-Komponente verhält wie der Motorteil beispielsweise der CAM und der Rest wie die Handbox, kann man wunderbar auf bestehenden Entwürfen aufbauen und beispielsweise bestehende Steurung oder Motorisierung mit neuen Komponenten weiterverwenden.

Aber gut, Schall und Rauch. Verdammt. Macht einfach zu viel Spaß!

Für mich die ersten Fragen:

- Was soll mit der Steuerung genau gesteuert werden?

Gruß,
Jens

Hallo Thomas,
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: ThomasWest</i>
<br />Ich denke die Diskussion üb C, Pascal, BASCOM oder Schlagmichtodirgendwas ist für das projekt irrelevant und sollte auf einen eigenen Thread verlegt werden.
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
Tschuldigung, aber wenn sie so fachfremd:
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Halt nicht mehr Maschinencode aber halt auch keine richtige Hochsprache.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
geführt wird, ist es besser, diese Diskussion gleich ganz zu lassen (und C zu verwenden [;)]). Was du über Pascal und C schreibst entbehrt jeder fachlichen Grundlage - auch das, was in dem von dir verlinkten Pamphlet dazu erzählt wird, ist nachweisbar falsch (Pascal älter als C, Java ein C-Nachfolger etc.).

Die Sprache muß nach den Anforderungen gewählt werden. 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. Sogar im akademischen Bereich, in dem es noch als einfache Erstsemester-Sprache zur Implementierung der eigentlich zu erlernenden Algorithmen herhielt. Programmstruktur und weiterführende Datenstrukturen erlernt man bereits in anderen Sprachen (Scheme, C). Das hat schon seine Gründe.

Grüße,
Michael

<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"><i>Original erstellt von: a_treff</i>
<br />Hallo Jens,

vergleich mal:
http://www.watterott.com/de/Arduino-Duemilanove
mit z.B.
http://shop.embedded-projects.…ikel&action=artikel&id=69

Da hat der ARM, bezüglich SRAM, Flash, etc. aber mehr zu bieten...

Großer Vorteil ist auch der eingebaute Bootloader (USB u. seriell) der AT91-Reihe von Atmel. (SAM-BA)
Wie bereits geschrieben kostet der AT 91SAM7S256 bei Reichelt 7,30 EUR.

Ganz wichtig für mich ist der freie Zugang zu der Entwicklungsumgebung und günstige Dev-Boards, damit möglichst viele am Projekt partizipieren können.

Grüße
Michael

<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

Hallo Michael,

Vergleiche nicht Äpfel mit Birnen. Natürlich ist die gesamte Arduino-Umgebung Open Source.
Die Arduinos sind Entwicklungsboards, nachher braucht man nur noch den ATMEGA (auch übrigens mit Bootloader), der DEUTLICH billiger ist.

http://www.watterott.com/de/ATMEGA328P-PU

Auch den Arduino kann man recht billig selber bauen!

http://blog.makezine.com/archive/2009/05/paperduino.html

Den ATmega1280 als großen Bruder bekommt man auch noch für unter 10€, wobei ja die CPU des motornahen Teils nicht allzuviel können muß.
Dazu gibt es bei der Arduino-Plattform noch jede Menge an "Shields", gewissermaßen Erweiterungskarten, die man dann ebenso als Ausgangspunkt für eigene Erweiterungen nutzen kann.

Hier mal ein Beispiel:

http://www.adafruit.com/index.…Path=17_21&products_id=81

Ich behaupte mal, daß für den angegebenen Zweck schon der 328 vollkommen ausreichen sollte - wobei zur Motorsteuerung ja auch noch ein bissl Sensorik kommt

WAS man nachher einsetzt, wird sicherlich die Fraktion entscheiden, die die Hardware designt, wenn es sonst softwaremäßig keine Ausschlußkriterien gibt. Die werden wissen, was sich am einfachsten implementieren läßt - oder was aus Gründen der Stabilität oder des Stromverbrauchs Vorteile hat. Laufen würde es auch auf 8080 oder 6502.

Zur Frage "Pascal oder C" - wir hatten in den frühen 80ern mal eine Pascal-Fraktion, die vor einem Projekt erst einmal anfing, jede Menge Räder neu zu erfinden. Eine Lehrsprache ist genau das, ein enges Korsett, in dem man explizit alles mögliche selbst ausformulieren muß.

Und ja, ich habe mit FORTRAN IV angefangen (paßte perfekt zur Anwendung), kenne den Zusammenhang der C-Syntax mit Assembler-Befehlsvorrat der PDP-11 und natürlich auch diesen Artikel:

http://www.pbm.com/~lindahl/real.programmers.html

Aber im Prinzip ist es ziemlich egal, wir sind sicherlich noch ein Jahr vor der Zeit, in der man sich über Implementationsdetails Gedanken machen sollte...

C bietet sich für die meisten Projekte mit Hardwarekontakt irgendwie an - und für das Frontend kann es sicher mehrere verschiedene Implementationen geben...

Gruß,
Jens

(==&gt;) Michael:

Leider habe ich keine Erfahrung mit einer offenen Entwicklergemeinde.

Was Kathedrale oder Basar angeht (erstmal Wikipedia bemüht...): wenn ich mal kurz darüber nachdenke, dann gefällt mir die Einordnung in diese Schubladen nicht, denn die Wahrheit liegt wahrscheinlich in der Mitte.

Soll heißen: die unteren SW-Schichten brauchen Stabilität. Zuerst müssen ein paar hieb- und stichfeste Grundlagen gelegt werden, auf denen dann aufgebaut werden kann. Das meint vor allem die Schnittstellen-Definitionen, da muss noch gar kein Code existieren. Dann wird man in der Anfangsphase wahrscheinlich noch Fehler oder Schwächen in den Schnittstellen und / oder Protokollen finden. Solange das passiert, muss das eine konzerzierte Aktion sein. Das kann man ja durchaus später weiter öffnen. Es kommt auch keiner auf die Idee, den offiziellen Linux-Kernel aus dem Ruder laufen zu lassen. Das soll nicht heißen, da keinen anderen ranzulassen, oder das nicht offenzulegen. Insofern keine Kathedrale.

Nebenbei bemerkt, ist das Setzen von Entwicklungsstandards noch keine Entscheidung für oder gegen die Kathedrale/Basar.

Oder irre ich mich?

Grüße, Henning

Hallo Micha,

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">- Entwicklungsstandards gemeinsam setzen (Sprache, Austauschformate, Doku, Entwicklungsumgebung inkl. Versionskontrolle und Anforderungsmanagement,
Rechte und Zuständigkeiten, Best Practices, Funktions-/ Unit-/ Regression-Tests). Es reicht nicht, ein paar Details davon hier im Thread zu fordern. Klingt zwar hart und bürokratisch,
ist m. E. nach aber unerlässlich. Alles was man hier vergisst, wird stillschweigend angenommen und Missverständnisse sind vorprogrammiert. Es unterstützt auch bei evt. Änderungen im "Personal"...<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
Das hört sich schwer nach "Kathedrale" und klassischem Kunden-/Dienstleisterverhältnis an.
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

so verkehrt ist das gar nicht - auch wenn mir die Formulierungen etwas zu 'bürokratisch' angehaucht sind
Coding Conventions/Guidelines sind unerlässlich, wenn in einem größeren Team gearbeitet wird; auch wirst bei sehr vielen Projekten ausführliche Tests finden, z.T. mit eigener 'Infrastruktur' in Form von z.B. Mini-Webservern o.ä. ...
Aber von konkreten Anforderungen und deren Umsetzung sind wir noch ein ganzes Stück entfernt.
Gruß,

Steffen

Hallo Thomas,
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: ThomasWest</i>
<br /><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.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">Der Autor redet von "deutlich älter" - da kann man nicht streiten, das ist falsch [;)]

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Ü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.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
Ich habe die Uni zwischendurch gewechselt, an beiden ist C Pflicht gewesen, neben C++, Java und Scheme. Auch Informatiker spielen mit eingebetteten Systemen herum, daher natürlich auch C (sowie Assembler, in meinem Semester glücklicherweise m68k). Als es in mein Hauptstudium ging, wurde die Vorstudiumsvorlesung Pascal durch ein vorgezogenes C++ ersetzt.

Man denkt sich so Dinge wie Templates, Patterns, Polymorphie oder Abstracts nicht einfach nur so aus, damit man eine neue Programmiersprache benötigt oder die Compiler dann halt nix kosten! Das hat Bezug zu den Problemen, die die immer komplexeren Softwareprojekte eben mit sich bringen. Man braucht EINE Sprache, die alle etablierten Paradigmen erlaubt und im Standard unterstützt. Die einzige, die das derzeit bietet, ist C++. Mal salopp ausgedrückt hält sich die Informatik angesichts einer so mächtigen Sprache nicht mit einer aufgepimpten Lehrsprache auf, die zum Erlernen strukturierter Programmierung gedacht war. Das heißt nicht, daß man keine Projekte damit durchziehen könnte. Aber wie gesagt, man denkt sich die komplexeren Programmierweisen ja nicht aus Jux und Dollerei aus. C bietet sich als Sprache für kleine bis mittlere Anwendungen schon alleine deshalb an, weil man leichter zwischen C++ und C als zwischen C++ und Pascal springt [:D]

Deine Lieblingssprache sei dir natürlich gelassen (war auch mal meine), ich finde nur, du sortierst sie falsch ein. Zurück zum eigentlichen Thema?

Grüße,
Michael

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: a_treff</i>
<br />
Lasst uns doch einfach die Entscheidungen treffen; ausschlaggebend nach der Verfügbarkeit von "freien" Entwicklungstools, Codebeispielen, Headerfiles, etc.
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

... oder ganz pragmatisch nach der Anzahl der verfügbaren Programmierer die C und/oder Pascal können.

Zum Thema "Coding conventions":

Hier die Dokumentation eines "simplen" Drucksystems, welches überwiegend als Solo-Projekt anfing:

http://www.cups.org/documentation.php

Man beachte den kleinen Block unten rechts.

Der Code ist nicht umsonst einer der lesbarsten, mit denen ich jemals gearbeitet habe. Inzwischen ist CUPS das Standard-Drucksystem für OSX und Linux. Aber wenn Mike Sweet irgendwann keine Lut mehr hat, bleibt alles pflegbar.

SO gute Software habe ich nie geschrieben

Gruß und CS,
Jens

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">[i]
Coding Conventions/Guidelines sind unerlässlich, wenn in einem größeren Team gearbeitet wird
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
hi!
wenn mans gscheit macht - dann macht man ein struct, das alle daten enthält, und auf das funktionen zugreifen.

das war in den neunzigern im mac os so ... und das ist objektorinetiert im einfachen sinn.

und bitte hörts mit dem pascal-quargel auf

lg
wolfi

Servus!
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">und bitte hörts mit dem pascal-quargel auf :D<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote"> [:D][:D]

Das hier hat eine recht tolle Oberfläche: http://www.mikroe.com/eng/prod…w/228/mikroc-pro-for-avr/
Halt speziell "nur" für AVR's und kosten tut's auch net wenig, aber die Demo runterladen und damit herumprobieren zahlt sich aus.
(War nur so eine Randbemerkung, weil ihr grad so schön drin seid in der Materie und ich mich grad damit herumspiele. [:o)] )
Gruß
Gerhard

Hi,

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">
Das hier hat eine recht tolle Oberfläche: http://www.mikroe.com/eng/prod…w/228/mikroc-pro-for-avr/
Halt speziell "nur" für AVR's und kosten tut's auch net wenig, aber die Demo runterladen und damit herumprobieren zahlt sich aus.
(War nur so eine Randbemerkung, weil ihr grad so schön drin seid in der Materie und ich mich grad damit herumspiele. [:o)] )
Gruß
Gerhard
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

... ja, und dann liest man weiter unter auf der Seite:

Technical Details

* Host Platforms:
Windows® 98/2000/NT/XP/2003/Vista/7

Nicht wirklich prickelnd ... :-O
Gruß,

Steffen

Hallo Michael,

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">
wollen wir das volle LX200, wie hier unter [1] beschrieben:
http://de.wikipedia.org/wiki/LX200-Protokoll implementieren?
Falls ja, dann brauchen wir 'ne SD-Karte mit Objektdatenbank am Motorsteuerung-Controller.

Mein Wunsch wäre auch in dem Zusammenhang auch die Nutzung von GPS.
Es gibt ja GPS-Mäuse mit RS232 und NMEA Ausgabe.
[...]
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
ich sag einfach mal 'Ja'!

GPS-Module gibt es inzwischen auch für wirklich wenig Geld - für meine Arduino-Basteleien hab mir so ein Teil zugelegt, ist nicht wirklich kompliziert (sowohl das Layout der Platine als auch die Programmierung).
Ist aber die Frage, ob sowas in den Controller gehört, wenn wir den minimalistischen Ansatz wirklich ernsthaft verfolgen?
Das Bus-Konzept könnte da - vielleicht - in die Bresche springen ...
Gruß,

Steffen

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Nicht wirklich prickelnd ... :-O<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">Fröhliches Weiterprickeln die nächsten 30 Seiten! [:D]
Gruß
Gerhard

Hallo Michael,

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">
- im obigen LX200-Protokoll ist eine Objektdatenbank -&gt; SD-Karte
- GPS ist nützlich für das Star-Alignment
- falls wir die Trinamic Motorcontroller nehmen, brauchen wir eine gute SPI-Anbindung, ev. auch zwei.
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

ja schon, bleibt aber trotzdem die Frage, ob das in den Controller reingehört, oder also separates 'Zubehör' über einen Bus rankommt, und damit auch den Part des Protokolls abdeckt?!

(==&gt;)Gerhard:
Sorry, das mit den 30 Seiten hab ich net verstanden ... wenn das Werkzeug was kostet, ok - aber dann sollte es wenigstens für die verbreiteten Plattformen verfügbar sein; und dazu gehören u.a. OS X und Linux-Distros wie Debian und Derivate, Red Hat und SuSE

Gruß,

Steffen