Beiträge von selste im Thema „Selbstbausteuerung mit open source fw?“

selste · 24. Juli 2011

Hallo Tassilo,
über den Anschluss von Encodern ist auch schon das eine oder andere Mal gesprochen worden - allerdings bezogen auf parallaktische Montierungen.
Wir werden versuchen auch die Dobson-Gemeinde zu berücksichtigen - aber alles auf einmal geht einfach net und wenn wir gleich am Anfang ein ganz großes Rad drehen wollen besteht die Gefahr daß es erst gar net in Bewegung kommt!
Gruß,

Steffen

selste · 16. Oktober 2010

Hi,
<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">
Es ging mir nicht darum euch zu bekehren. Wenn ihr euch für de LPC2148 entscheiden habt, dann zieht das durch!
[...]
<hr height="1" noshade id="quote"></blockquote id="quote">
hab ich nicht als Bekehrungsversuch empfunden! Macht Sinn sich über das Für und Wider auszutauschen ... zumal Du - zumindest mir - da einiges an (praktischer) Erfahrung voraus hast.

Ich denke allerdings daß reine 8-Bitter tatsächlich langsam aber sicher ein Nischendasein fristen werden (müssen) - ist ja bei den XMegas zu beobachten, daß Timer u.ä. schon 16 Bit breit ausgelegt sind; der Bedarf ist da offensichtlich vorhanden - gleichzeitig ist es aber natürlich so (sieht man ja an deiner Steuerung), daß es viele Projekte/Lösungen gibt, die nicht nochmal von vorne anfangen wollen.
Atmel MUSS ein Interesse daran haben, diese Klientel zu halten, schon aus dem Grund werden sie die Entwicklung net einfach einstellen.
Gruß,

Steffen

selste · 16. Oktober 2010

Hallo,
vielen Dank für den Link!
<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">Nur kurz dazu: Das ist falsch. Zumindest für die genannten AMD-CPUs weiß ich, dass der 32bit-compat Code (32bit in 64bit Umgebung) u.U. sogar schneller ist als im nativen 32bit mode. Je nach Anwendung kann die 32bit Version im compat Modus sogar schneller als die 64bit Variante sein[1]. Da ist kein Emulator am Werk!

[1] http://www.amd64.org/fileadmin…Linux-Myths_and_Facts.pdf
<hr height="1" noshade id="quote"></blockquote id="quote">
Hmm, also wenn ich mir die Auswertungen der diversen Benchmarks so anschaue, dann ist das richtig was ich gesagt habe:
Nativ 32 Bit ist (wenig) schneller als 32 Bit Compatibility, 64 Bit aber deutlich schneller als 32 Bit, oder?!?
Der Begriff 'Emulator' war aber sehr ungeschickt gewählt, das stimmt!
Es findet ein Mapping von 32-Bit-Befehlen auf 64-Bit statt.
Gruß,

Steffen

selste · 16. Oktober 2010

Tja,
das ist halt der große Unterschied!
<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">
[...]
und für mich das wichtigste, daß ich alle meine bisherigen funktionierenden Routinen, die ich für die
den früeren Prototypen (ATmega) geschrieben habe, weiter verwenden kann.
<hr height="1" noshade id="quote"></blockquote id="quote">
Du hast net auf der 'grünen Wiese' angefangen, sondern wolltest auf bestehender Hard- und Software aufbauen.

Wir hingegen fangen bei Null an - Michael hat, auf Basis der gesammelten Anforderungen (und nachdem er mal in die Runde wg. Präferenzen gefragt hatte) eben den LPC2148 gewählt; und die Entscheidung finde ich nach wie vor gut, auch wenn ich persönlich vielleicht sogar einen noch leistungsstärkeren Vertreter der Familie gewählt hätte.

Bringt meiner Meinung nach net viel wenn jetzt eine 'Mein Haus, mein Auto, meine Yacht'-Runde eingeläutet wird.

Wenn sich herausstellen sollte, daß die MCU net ausreicht (weil zu langsam oder zu wenig Peripherie) können wir immer noch wechseln, wenn wir einigermaßen geschickt bei der Programmierung vorgehen sollte sogar ein Wechsel der Prozessorfamilie machbar sein.
Gruß,

Steffen

selste · 15. Oktober 2010

Ha,
was für eine Frage ...
<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">Hallo!
Was wollt ihr eigentlich mit 64-Bit-Prozessoren an einer Montierung, die aus einer primitiven Schnecke und primitiven Zahnrädern besteht? Wunderdoktor spielen? Eine "Chinafett-Ausgleichs-Routine" schreiben?

Gruss
Gerhard
*duckundweg*
<hr height="1" noshade id="quote"></blockquote id="quote">
... natürlich das ELT steuern, wenn es färtsch ist! [:)]

Kann Dich aber beruhigen - bisher haben wir 'nur' eine 32 Bit MCU!
Gruß,

Steffen

selste · 15. Oktober 2010

Hmm,
<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">
Mache ich auch. Nur mit einem 8-Bitter Ok er hat 32MHz. Hab aktuell nen Xmega128A1 laufen. Es kommt aber in der nächsten Version ein Xmega384A1 rein.
<hr height="1" noshade id="quote"></blockquote id="quote">
na ja, die Prozessorfamilie wird aber als
'8/16-bit XMEGA A1 Microcontroller '
beworben ...
Also ein klein wenig hast da schon geschummelt, oder?!? [:)]
Gruß,

Steffen

selste · 15. Oktober 2010

Hallo,
<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">
Mag schon sein, man sollte aber nicht versuchen eventuell ineffiziente Programmierung mit Rechenpower zu erschlagen.
Ihr baut immerhin eine Teleskopsteuerung und keinen Supercomputer.
[...]
Beim PC ist das doch auch ähnlich. Da wird mit Windows7 x64 geworben und ist es wirklich schneller als x32?
<hr height="1" noshade id="quote"></blockquote id="quote">
vielen Dank für das in unsere Programmierkenntnisse und -fähigkeiten gesetzte Vertrauen! [;)]

Nur kurz zum PC - zumindest für die AMD 64Bitter galt (und gilt, soweit mir bekannt), daß die Ausführung von 32-Bit-Befehlen langsamer ist als die nativen - 64 Bit - Befehle; da werkelt im Inneren i.G. ein Emulator, der kostet halt Leistung.
Keine Ahnung wie sich die Intel-Chips da aufstellen, habe ich keine Erfahrung mit.
Wenn dann natürlich das Betriebssystem die CPU net wirklich ausreizen kann ... schade drum!

Meiner Meinung nach hat sich die Frage nach dem Einsatz eines 8-Bitters einfach dadurch erledigt, daß wir eben KEINE reine Teleskopsteuerung bauen wollen (im Sinne von simpler Ansteuerung zweier Achsen), sondern - in einer Ausbaustufe - 'überflüssigen Schnickschnack' [;)] wie Goto (mit allem, was da so dazugehört) bieten möchten - in einem Gehäuse, auf derselben MCU.

Aber ich lasse mich gerne eines Besseren belehren - welche 8-Bit CPU ist dafür geeignet?!
Gruß,

Steffen

selste · 10. September 2010

Hallo Sebastian,
willkommen im Club - als Ergänzung zu dem, was Michael schon erwähnt hat ...

Wir nutzen das Olimex LPC-P2148 (LPC2148 16/32 bit ARM7TDMI-S) + Ethernet-Adapter (ENC28J60-H).
Entwicklungsumgebung ist Eclipse mit einer GNU-Toolchain - da bin ich gerade am Basteln und Probieren, um Code dann auch mal ordentlich debuggen zu können.
Wir wollen FreeRTOS als Basis für die Steuerungs-Software verwenden, da hakt es aber an einigen Stellen.
Gruß,

Steffen

selste · 5. August 2010

Hi,
<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">
so eine AVR-Zusatz-CPU könnte man schon von der Haupt-CPU aus programmieren.
Ist aber eine Baustelle mehr...
Da ist mir der TMC428 als Controller mit eigener Firmware irgendwie lieber,
da er schon länger auf dem Markt ist und nicht mehr debugged werden muss.
Frage ist, ob man überhaupt eine Zusatz-CPU braucht?
<hr height="1" noshade id="quote"></blockquote id="quote">
klar, ist schöner wenn man ein paar 'Tausendfüßler' hat und weiß, daß sie funktionieren - oder zumindest die Fehler dokumentiert sind!

Auf die MCU verzichten würde ich eher net, auch wenn der ARM Chip sicherlich genug Rechenleistung hat ... denn damit ginge die saubere Trennung zwischen Steuerung und Motortreiber(-platine) flöten; und das rächt sich garantiert über kurz oder lang, könnte ich mir vorstellen.

Steffen

selste · 5. August 2010

Tach,
<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">
Pit meint, glaube ich, einen Mega88 AVR als Zusatz-CPU für die Motorplatine.
Das würde die Sache, bei unserem Ansatz, in der Tat verkomplizieren.
<hr height="1" noshade id="quote"></blockquote id="quote">
ja, so habe ich das auch verstanden
Die angesprochenen Daten (1/128 Microsteps, 7A Peak) gefallen mir schon ... wenn man die MCU auch über die Steuerung programmieren kann?!?
Oder würde sowas zu aufwändig?

Steffen

selste · 4. August 2010

Hallo,
noch als kleine Anmerkung ...

Eine weitere Architektur - durch den AtMega88 - mit völlig anderem Befehlssatz macht die Entwicklung sicherlich nicht einfacher!
Gruß,

Steffen

selste · 7. Juni 2010

Hallo,
da die Steuerung selbst nur aus Standard-Bauteilen bestehen soll, und die Diskussion darüber offen geführt wird, ist es praktisch gar nicht möglich, eine (wie auch immer geartete) kommerzielle Nutzung (von Teilen oder gar der gesamten Steuerung) zu unterbinden.
Geht eigentlich nur über den Preis ... wenn die Marge (beim kommerziellen Vertrieb) einfach nicht groß genug ist, um davon leben zu können!

Eine ganz andere Geschichte ist die Software - durch eine geeignete Lizenz ist sehr gut zu steuern, was damit gemacht werden darf und was nicht ... in der Theorie; in der Praxis stellt sich dann das Problem, wie Verstösse festgestellt werden
Gruß,

Steffen

selste · 2. Juni 2010

Hi,
<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">Original erstellt von: Gamma Ray
 Wenn wir schon bei der Hardware sind:
Wenn das Getriebe der Montierung nichts taugt, hilft die beste Handsteuerung nichts. Womit wir wieder bei der Hardware wären.
<hr height="1" noshade id="quote"></blockquote id="quote">
für die ultimative Open-Source-Montierung machst aber bitte einen neuen Thread auf! [:)]
Gruß,

Steffen

selste · 2. Juni 2010

Hallo Thomas,
<blockquote id="quote">Zitat:<hr height="1" noshade 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.
[...]
Da bin ich dafür, daß gleich in die Steuerung zu integrieren.
<hr height="1" noshade id="quote"></blockquote id="quote">
sehe ich auch so!
Mal 'ins Unreine' gedacht ...

Eine Steuerung nur mit Handbox (4 Richtungstasten + Geschwindigkeitswähler), dazu ST-4 Anschluß für den AutoGuider reicht uns ja net - soll ja mit jeder Hardware/Montierung funktionieren, muß also konfigurierbar sein - im Hintergrund hör ich jetzt schon wieder die 'standardisierten' seriellen Schnittstellen ... ;-)?
Bohren wir das Ding halt ein wenig auf, machen wir es zur 'Schaltzentrale': es kommt eine CPU rein, und ein Ethernetmodul ... WebInterface für den Upload neuer Firmware und die Konfiguration der Motor-/Montierungsparameter; das ist Benutzer-freundlich!
Zweite Platine, Verbindung über SPI, die die ganzen Nettigkeiten bereitstellt - Anschlüsse für Fokussierer, Filterräder, DSLR und-hast-Du-nich-gesehen, CAN-Bus, I2C, was auch immer gewünscht wird; Konfiguration erfolgt über das WebInterface der 'Zentrale' via SPI, ebenso Firmware-Updates.
LX-200 Protokoll via serieller Schnittstelle müßte man sich noch überlegen; die 'Schaltzentrale' könnte nur ein Subset der Befehle bereitstellen ... deshalb vielleicht auf die 'Erweiterung' schieben.

Finde ich noch innovativ genuch - verglichen mit der von Dir angesprochenen EQ-3 Motorisierung zumindest
Gruß,

Steffen

selste · 2. Juni 2010

Hallo Thomas,
<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">Original erstellt von: ThomasWest
 <blockquote 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">
Wie sollte das denn aussehen? Motor mit konstanter geschwindigkeit und einfach nachfrühren?
[...]
Da kommen wir dann zum Problem der Ansteuerung mittels Laptop oder PDA.
[...]
<hr height="1" noshade id="quote"></blockquote id="quote">
ganz genau - das ist die 'kleine Lösung' - und die ist noch nicht vom Tisch, dachte ich?
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), fürs Einnorden ist es auch wichtig; aber das ist dann schon Kür.

Ich geb aber gerne zu, daß ich mir momentan nicht (mehr) so richtig vorstellen kann, wie das alles sinnvoll unter einen Hut zu bringen ist ...

Gruß,

Steffen

selste · 1. Juni 2010

Hallo Michael,

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">
Hallo,

bin dabei mich in die Datenblätter der verschiedenen Motorcontroller und Treiber einzulesen.
[...]
<hr height="1" noshade id="quote"></blockquote id="quote">

macht es Sinn an der Stelle mal einen Zwischenstand zu dokumentieren, ggf. auch schon in einem neuen Thread?
Die Anforderungen zusammentragen, und - versuchen - daraus 2, vielleicht auch 3 ganz grobe Entwürfe für eine Steuerung zu drechseln.
Ich könnte mir vorstellen, daß die Zusammenstellung von einzelnen Komponenten für einen Prototyp dann einfacher ist, und auch Leute wie ich, die von Embedded Systemen wenig bis keine Ahnung haben, nicht komplett abgehängt werden, was ist Deine Meinung?
Gruß,

Steffen

selste · 31. Mai 2010

Hallo Gert,
<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">
Mal eine Frage zur Goto. wie bringt man denn die verschiedenen Montierungstypen unter einen Hut? Also Dobson, Gabel, Deutsche Montierungen usw. haben doch alle an bestimmten Himmelspositionen Probleme.
[...]
<hr height="1" noshade id="quote"></blockquote id="quote">
hab noh keine Steuerung programmiert - aber ich würde mal ganz naiv annehmen, daß der Rechner ein Modell pro unterstütztem Montierungstyp hat; wäre eher ungeschickt, wenn jedes Mal eine neue Firmware aufgespielt werden müßte, wenn die Steuerung an eine andere Montierung angestöpselt würde?!

Steffen

selste · 31. Mai 2010

Hallo Holger,
richtig oder falsch gibt es da eher nicht ... ich fände es halt schade, wenn da jetzt viel Aufwand investiert wird, und die Arbeit - womöglich? - anschließend mehr oder weniger umsonst war.
Michael hat ja den zweiten Thread schon ins Leben gerufen ... vielleicht sollte man ihn mal fragen, was er bevorzugt?
Gruß,

Steffen

selste · 31. Mai 2010

Hallo Thomas,

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">
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.
[...]
<hr height="1" noshade id="quote"></blockquote id="quote">

ich war bisher davon ausgegangen, daß man um einen - wenn auch sehr einfachen - Prozessor für die Ansteuerung der Stepper nicht herumkommt; wenn es aber so hochintegrierte Bausteine gibt ... erleichtert die Arbeit ungemein!

(==>)Holger:
Meiner Meinung nach macht ein Wiki im 'luftleeren' Raum net viel Sinn - ich würd mir - als Programmierer - wünschen, daß eine Lösung zum Einsatz kommt, die Bug Tracker/Issue Management, Milestones und Wiki (vielleicht auch noch Diskussionsforen) vereinigt (beispielsweise Redmine, Trac oder Jira + Extensions).
Momentan würde ich - wie Michael es ja schon angefangen hat, in einem separaten Thread mit der Zusammenfassung der Anforderungen beginnen.
Gruß,

Steffen

selste · 29. Mai 2010

Hallo Volker,

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">
[...]
Layer1: Steppersteuerung mit Direktanschlußmöglichkeit einer Handbox und einer SPI (oder I2C) Schnittstelle zur Bus-Kommunikation.
Dieser Layer bewegt einfach nur die Motoren und macht die kontinuierliche Nachführung.
[Einschub: Bei der Handbox wünsche ich mir übrigens 3 Geschwindigkeiten: schnelles Verfahren, Positionieren im Okulargesichtsfeld, Nachführkorrektur)].

Layer2: Hier sitzt die Intelligenz (Steuerzentrale), also die Steuerung von PEC und Autoguiding, LX-200 Umsetzung in Ansteuerbefehle für die Motoren. Dazu Uhrzeit und Koordinaten (ggf. mit GPS) zur Positionsberechnung fürs Goto. Ebenso das Sicherheitssystem für Sonne.
[...]
<hr height="1" noshade id="quote"></blockquote id="quote">

eigentlich sehe ich das genauso, ist eine gute Zusammenfassung, vielen Dank!
Ich bin mir nicht sicher, wie die Alt-Az Fraktion da geschickt untergebracht werden kann ... Layer 1 reicht net, muß mindestens Layer 2 sein, oder - und wie schaut es dann mit einer Handbox aus?!?

Zur Kommunikation zwischen 4,3 und 2 - wenn wir so Sachen wie Aufspielen neuer Firmware über z.B. http anbieten wollen, dann reicht LX-200 net; Layer 3 muß sicherlich dieses Protokoll samt Schnittstelle nach außen (Layer 4) anbieten, aber intern ... vielleicht einfach auch SPI?!
Gruß,

Steffen

selste · 29. Mai 2010

Hi Michael,
<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">
Hinsichtlich Konfiguration:
Was haellt ihr von einer Art Konfigdatei (xyz.ini) auf SD-Karte,
wo alle wesentlichen Parameter im Klartext lesbar zugaenglich sind?
<hr height="1" noshade id="quote"></blockquote id="quote">
wenn die für den Betrieb der Steuerung notwendig wäre ... net viel!

Wenn man der Steuerung sagen kann, daß sie die gerade verwendeten Parameter doch bitte als Properties-/Konfig-Datei wo ablegen soll, warum nicht?
Gruß,

Steffen

selste · 28. Mai 2010

Hallo Gerhard,

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">
Mann! Jetzt habe ich erst den Link angeschaut!
Nein, ein Netbook habe ich mir angeschafft! [:o)] Wollte nur mal etwas ("smileyfrei oder "sinnfrei", wie es heute so sinnlos heisst), ätzen nach 17 Seiten! [:D]
Gruss
Gerhard
<hr height="1" noshade id="quote"></blockquote id="quote">

ein Netbook mit LED-Display - wo gibt es denn sowas!?
Gruß,

Steffen

selste · 28. Mai 2010

Hi Michael,

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">
SPI -> Ethernet:
http://www.tigal.com/1593

SPI-> CAN:
http://www.tigal.com/1112
<hr height="1" noshade id="quote"></blockquote id="quote">

ganz schön groß, die Dinger ... guckst Du mal da:
http://www.watterott.com/de/WIZnet-WIZ830MJ-Ethernet-Modul

Ich denke mit das größte Problem wird sein, aus dem riesigen Angebot an Modulen auszuwählen ...
Gruß,

Steffen

selste · 28. Mai 2010

Hi Wolfgang,

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">
pf ... da musst Dir dann die hackn auf controllerseite machen, das will ich eigentlich nicht. klicki-bunti mit wx oder besser Qt ist plattformunabhängig, flott und vor allem kontrollierbar ...
<hr height="1" noshade id="quote"></blockquote id="quote">

auf der Controller-Seite mußt Du eh was machen - aber nur EINMAL; auf der anderen Seite (Client) aber für jeden
Bleib'mer mal beim Web-Interface ... auf Benutzerseite ist da nix zu tun - jede Plattform bringt einen TCP/IP-Stack, der Browser macht für uns Socket-Kommunikation UND sogar noch ein 'High-Level'-Protokoll - nämlich http(s).
Controller einstöpseln, Browser starten ... und hat!
Wenn neue Funktionen hinzukommen - Firmware aktualisieren (auch über den Browser, Reset des Controllers, gut is) ... keine Treiber-Orgien/Krampf mit signiert oder nicht-signiert - 32-Bit vs. 64-Bit und was sonst noch alles daneben gehen kann.

Grüsse,

Steffen

selste · 27. Mai 2010

Hi Wolfgang,

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">
geh bitte ... wo ist da das problem? versteh ich echt nicht ...
<hr height="1" noshade id="quote"></blockquote id="quote">

na ja, man muß es machen - wenn stattdessen z.B. ein WebInterface vorhanden wäre würdest einfach einen Browser starten (auch gerne sowas wie lynx - ohne Klicki-Bunti), und färtsch, nimmt dann z.B. LX200-Kommandos entgegen oder stellt eine Art Handbox zur Verfügung, die das abstrahiert, wäre das net Bediener-freundlich?!
Klar ist Socket-Programmierung kein Hexenwerk ... und ich wehr mich ja auch net (sehr;-) dagegen, daß man sowas für Cracks zur Verfügung stellt, aber vielleicht net als primären Kommunikationsweg.
Gruß,

Steffen