Klick macht alle Bilder größer
Im Zuge der Ermittlung zur sinnvollst eigenen, aber auch dem Geiste Dobsons entsprechend, der erschwinglichsten Eigenlösung für's eigene motorisierte Teleskop, hat unsereiner erst mal seine Bastelbestände in den Tiefen Speicher-orientierter Endlagerung durchwühlt. Was doch schon das meiste auf ein erfreuliches Minimum an möglichen Aufwendungen reduzierte. Danach, war man auf der Suche zur Lösung eines Problems, welches das Vorhandene leider nicht mehr erfüllen konnte. Wobei ich aber auch gleich auf die Schönheiten von Himbeeren aufmerksam wurde und mir dabei einen seltsamen Früchtetick einfing. Jedenfalls, - nach deftiger Erhöhung des Spaßfaktors dabei, sowie weiteren recht umfangreichen Kalkulationen und Überlegungen, war das Konzept klar, - und sieht, ganz simpel, - folgendermaßen aus; Eine in den Außenmaßen zwar sehr kleine, aber rechen-technisch sehr mächtige eingekaufte Himbeere, (auf dem Bild oben), wird mit einer bereits schon länger existierenden Brombeere von mir selbst gekoppelt, (auf dem Bild unten), - welche wiederum, zwei bis drei noch zu züchtende Johannisbeeren ansteuert, die wiederum jede für sich eine eingekaufte Holunderbeere in der eigenen Gartenparzelle gießt. Möglicherweise, muss ich aber jetzt erst einmal die Früchte und den Landschaftsbau näher erklären.

Die kleine große Himbeere, der Raspberry PI3 Bplus

Dieses Teil, erfreut sich mittlerweile großer Beliebtheit und ist im Grunde ein 50x80 mm großes Board mit einer 64-bit Quad-Core-CPU von Broadcom mit Arm Cortex A53-Architektur, die mit 1,4 Ghz läuft und einen bemerkenswert geringen Stromverbrauch aufweist. Hat einen Gigabyte Speicher, 4 Usb-Ports, einen Ethernet-Port, Wlan, Anschlüsse für Displays, Kameras, HDMI, Sound und eine Steckerleiste für Signalports, - inklusive RS232, SPI und I2C. Das Teil bekommt man für ca. 30 Euro bei allen einschlägigen Lieferanten fürs Elektronische, welche auch ein Herz für den Privatgärtner haben. I.d.R. liest man sich erst mal durch die recht guten Erklärungen dafür auf dem Netz durch, - dann kauft man es, - ärgert sich erst mal über einen dämlichen Mini-Usb-Anschluss für den Saft und besorgt sich deshalb noch ein Netzteil 5V/2.4A für ca. 10 Euro dafür, - dann besorgt man sich eine Micro-SD-karte (Möglichst mit Adapter für die normale Größe zum auch Einstecken ins Notebook), - richtet darauf nach den Erklärungen das Image eines Raspian-linux ein, - am besten noch eine leere Datei ssh.txt mit dazu, - und wenn man wlan direkt benutzen will, auch noch eine dem eigenen wlan entsprechende wpa_supplicant.conf ein, - und schon kann man sich per ssh einloggen. Eine Alternative ist, USB-Tastatur und Fernseher anschließen, und ebenfalls loslegen. Sinnigerweise, - erst mal was für Leute mit Linux-Affinität, aber wenn auf dem Ding Windows laufen würde, wäre der eigene erste Gedanke eh der gewesen, wie man es für so ein schönes Teil durch Linux ersetzen könnte, um den Bedarf an einer-, eben auch bis in die Grundfesten der Kernelei, kontrollierbaren Maschinerie haben zu können. Ich selber, verzichte außer auf wlan und einen usb-Anschluss für eben einen USB-Stick,- aber erst mal auf alle zusätzlich ansteckbaren Dinge,- außer den eigenen. Linux ist schließlich auch ein Multiprozesssystem und ich kann nichts brauchen, was mir meine eigene Rechenpower und Zeitsynchronisation stören könnte. Zudem benutzen z.B. auch einige sehr preiswerte LCD-Displays dafür, Signale eben von der Steckerleiste, die ich sinnigerweise auch erst mal für mich haben möchte. Im Moment, spricht aber nicht mal im Entferntem was dagegen, dass alles nicht mit einem normalem Programm in momentaner Umgebung laufen könnte. Im Zweifelsfalle, gibt es aber noch Wege über Kernelmodule bzw. auch noch das Abstrippen bis zu einem Uboot-Linux hin, - wenig nötig, mit nur einem Hauptprozess und dann ist das sonstig angesteckte eh tot. Ich erwähne das nur für den Fall, dass jemand so was ähnlich für sein Scope machen will, das Teil aber gleichzeitig auch als Multimedia-Maschine benutzen will. Es gibt durchaus verschiedene Wege das zu tun, aber die Gleichzeitigkeit mit einem fürs Erste noch in der normalen User-Umgebung laufendem Programm, welches ein Teleskop bis zur 100stel Bogensekunde ansteuern soll, - sollte besser vermieden werden. 1,4 Ghz sind gut, aber in Zeitscheiben geschnitten, hat auch das einfach seine Probleme für stur benötigte sonstige Takte.

Die Brombeere, ein Board mit dem Atmega32 oder 324

Das Teil ist eigentlich meine alte Steuerung. Für Genauigkeiten um die Bogensekunde herum, auch mit Rechenoperationen doppelter Präzision, ist das brauchbar, - aber bei mehr ist es leider überfordert. Ich habe mir dunnemals sogar eine Leiterplatte dafür machen lassen, wenngleich auch nichts dagegen spricht, es sich nach Schaltplan zusammen zu fädeln, um solcherlei Kosten zu vermeiden. Was soll's? Es ist fertig, bereits vorhanden, also warum soll ich es nicht fürs sture Steuerungstechnische und alles sonstige verwenden, was der Himbeere fehlt, während die die Rechnerei macht? Die Brombeere hat eine mit 14,7456 Mhz getaktete Atmega32-CPU, eine LCD-Anzeige, eine batteriegepufferte und auf die hunderdstel Sekunde genaue Echtzeituhr, eine rs232-Schnittstelle mit kompletter Pegelwandlung, SPI, I2C und jede Menge sonstig ungenutzer Signale vom Atmega, die bekannterweise neben Benutzung als I/O oft mehrere programmierbare Funktionalitäten wie z.B. ADC haben und ich bei dem Ding auf eine Portleiste gelegt habe. Einen ADC benutze ich z.B. über entsprechende Widerstände für eine Ein-Signal-Tastatur, für aber acht Tasten über verschiedene Widerstände zur Bedienung. Ich werde zwei davon verwenden, und die Widerstände extern in eine Handtastatur mit 12 Ziffern- und Funktions- sowie vier Richtungstasten legen. Das Schöne an solchen AD-Wandlertastaturen ist, dass man nur sehr wenige Kabel benötigt. Je nachdem, wie lang die als Verlängerung werden, muss man natürlich deren eigenen Widerstand mit kalkulieren. Wird noch eine zweite rs232 Schnittstelle benötigt, kann der Atmega32 durch einen Atmega324 ausgetauscht werden, da die beiden Pin-gleich sind, aber letzterer auf den Pins INT0/INT1 auch noch die Funktionaliät von RXD2/TXD2 hat, für die lediglich noch die Pegelwandlung fehlt, welche ich auf einem kleinen Miniplatinchen wahrscheinlich direkt am Stecker anbringen werde. INT0, kann auf dem Board aber auch stattdessen für einen Interrupt von der Echtzeituhr verwendet werden, was ich aber bei neuer Funktionalität nicht gebrauchen kann. Ansonsten, ist das Teil mittels extra Anschlüssen für In-System-Programming, Jtag und SPI versehen. Die Verbindung zum raspberry, sehe ich über einen schnellen 8-Bit Datenport, und drei Zusatzsignalen vor. Damit bleiben die sonstigen Signale für auch SPI, I2C und rs232 des raspberry's erst mal unberührt. Möglicherweise, gestalte ich mir aber inside für SPI ein kleines Schmankerl, welches bei normaler Benutzung keine Bedeutung hat. Das Raspian, kennt nämlich die Programme uisp und avrdude zur Interprocess-Programmierung der Atmegas, was, wenn ich mit einer passendem Flachbandkabelbrücke den raspberry-spi-port mit dem entsprechendem ICSP-Port meiner Brombeere verbinde, diese sich eben auch einfach direkt vom raspberry aus aufpumpen lässt. (Das ich das Brombeerboard auch vorher schon als Aufpumpboard missbraucht hatte, erkennt man am schönen Schnappverschluss-Sockel der CPU) Jedenfalls, - für meine Astrozwecke als Motorsteuerung, dient dies Board hauptsächlich als knüppelharte Interruptmaschine, die alles in ein exaktes Timing von 1/2400stel Sekunde presst, in derem Frequenzspektrum von 0 ... 2400 Hz sich auch die Motoren genauso im gesamten Bereich zwischen Vollgeschwindigkeit und nach-führendem kleinst möglichem Mikroschritt mit unterschiedlichen Frequenzen sensibel ansteuern lassen, wie alles dadurch bereits schon vom Timing her, in eine theoretische Genauigkeit zum Nachführen, von 2400/15 = 1/160stel Bogensekunde zwingt.

Die Johannisbeeren mit Attiny 4313

Die sitzen, (im Moment noch nicht, - aber bald), letztendlich auf sehr kleinen Platinen direkt bei den Motoren und sind ebenfalls mit 14,7456 Mhz getaktet und bekommen einen rs232, wie auch einen SPI-Anschluss zur Basis. Welcher davon benutzt wird, hängt von der für die Verbindung nötigen Kabellänge ab und ob ich die Basis aus Him- und Brombeere beim Motor am Montierungsfuß oder beim Motor an der Gabelseite aufhänge. In jedem Fall wird es mindestens ein Kabel geben, welches bis zu 2 Metern Länge bedarf. Eine dritte Johannisbeere ist für einen eventuellen Bildfeldrotator vorgesehen. Bei dem tippe ich aber mal auf rs232, da zumindest der Weg vom Fuß der AZ-Achse bis zum Okular auch recht lang werden kann. Die generellen Aufgaben der Attinys ist es, einmal die jeweils zwei Signale des Encoders der betreffenden Achse zu verarbeiten und die Kommandobefehle der großen Brombeere an die Motoren für-, die auf ihrem gleichem Board anwesende Holunderbeere umzusetzen.

Die Holunderbeeren, TMC 260

Dieser Chip von Trinamic, erzeugt letztendlich die modulierten Ströme für die Motoren auch noch in den 1/256stel Mikroschritt hinein und bedarf dafür nur sechs Signalen von außen. Zwei sind fürs Steppen und vier für eine SPI-Kommunikation zum Einstellen. Letztere ist allerdings nicht Byte orientiert, sondern pro Kommando 20 Bit lang. Was aber nichts macht, denn dafür kann er dafür sogar Geschwindigkeiten bis zur eigenen halben Taktfrequenz, was auf die ultrakurze Knutschentfernung zwischen den Holunder- und Johannisbeeren, auch keine Probleme machen sollte, aber durch die Emulation bei 14,7456 Mhz, am Ende wahrscheinlich sowieso bei nicht mehr wie ca. 1-2 Mbit liegen wird. Die Johannisbeere Attiny, wird also auch eine 8 zu 20bit-Spi-Schnittstelle zur Holunderbeere sein.



Drumherum, darüber, - und was sonst noch zu erzählen wäre.

Fürs Erste, habe ich mir für die Basis aus Him- und Brombeere, mal ein solides Gerüst geschaffen, auf dem nichts mehr wackeln kann, sich aber trotzdem noch alles was fehlt oder verbunden werden muss, und dies möglichst ohne frei schwebende Kabel, - noch handlich verlöten lässt.

Überhaupt, - das mit den Kabeln ...

Die Verbindung zwischen Motor und Motortreiber (Holunderbeere), z.B., sollte so kurz wie irgend möglich sein. Das hat mit Frequenzen und Induktionen genauso viel zu tun, wie mit Kabelwiederständen, als auch dem Umstand, dass das Teil für den Mikroschrittbetrieb auch bei 24 Volt, mit nicht mehr wie zehntel Volt hampeln muss. Was eigentlich der Hauptgrund für die kleinen Dinger direkt am Motor ist. Wobei dadurch auch direkt eine kurze Leitung von den kleinen Johannisbeeren zu den Encodern entsteht, was aber angesichts der geringen Frequenzen dabei, auch in längeren Versionen kein Problem darstellen sollte. Bei verkabelten SPI-Leitungen, die über einen Meter hinaus gehen, werde ich aber schwer nervös und würde bereits schon bei dieser Länge, sicherheitshalber nicht schneller als mit max. 100 - 120kHz operieren. Mein Motor für den Antrieb der Gabel in der Horizontalen, ist selbst aber nicht auf der Gabel befestigt, sondern am generellem Fuß der Montierung und treibt von da aus die Gabel an. Was bei 360 Grad den Effekt hat, dass für eine Achse hierfür ein Kommunikationskabel, von CPU zu CPU, bis zu einer Länge von 2 Metern nötig ist. Zu unsicher für SPI, also wird diese Strecke auf jeden Fall per rs232 mit Pegelwandlung und einer Geschwindigkeit von evtl. 115,2 KBps überbrückt. Da ich nicht vorhabe, beim Steuern und Beobachten mit einem CPU-Kasten und mächtig Kabeln in der Gegend rum zu hampeln, sondern ein kleines handliches Handpad mit nicht mehr wie den nötigen Tasten zur zwar nicht ganz kabellosen- aber lediglich nur dünnem Kabelstrang mit auch nur drei Adern zur Fernbedienung bevorzuge, wird rs232 nicht für alles nötig sein, - aber auch dies wäre zur Not möglich. Bei der vorgesehenen Bedienung, wird die Basis entweder am Fuß der Montierung oder an der Gabelseite aufgehängt oder angesteckt werden. Dies auch deshalb, um die Menge an-, per Motorbewegung mit geschleifter Kabel auf dem Minimum des Kommunikationskabels und der 5- wie 12/und/oder 24 Volt Leitung für die Spannungsversorgung der Motortreiber zu halten. Da es in unmittelbarer Nähe eines Motors und seiner Johannis- und Holunderbeere zur Verkabelung nicht mehr als max. 30cm benötigt, kann ich die dortige Johannisbeere also auch per SPI ansteuern.

Wie man sieht, habe ich mir zusätzlich noch gut Platz über den Bedarf hinaus, für evtl. zukünftige Erweiterungen geschaffen. Was allerdings das Gehäuse ganz zum Schluss, bereits jetzt schon zu einer interessanten Herausforderung (Laubsägearbeit?) werden lässt, aber ich hab so Zeugs lieber im Gehäuse, als viele angeschlossene kleine Kästen, die es zum Löten auch alle zu öffnen gilt. Die versenkte LCD-Anzeige, hat damit aber nichts zu tun, sondern wird bewusst später entsprechend eingerahmt werden. LCD-Anzeigen sind für den Sterngucker immer zu hell, aber ist im Dunkeln die Hintergrundbeleuchtung aus, sieht man eben auch nix. (An- abschalten, ist per Software über einen Transistor möglich) Die ist mit entsprechendem Widerstand zwar schon so schwach wie möglich, trotzdem macht es Sinn, sie noch so zu versenken, dass wenigstens seitlich kein störendes- oder gar Streulicht entsteht. Beim Rudelspechteln z.B., reicht es ja nun wirklich, wenn nur der im Licht badet, der auch sein Display sehen will. Eingerahmt, hat man aber auch mehr Möglichkeiten, sie mit farbigen Abdämpffolien abzudecken, ohne die ständig mit Tesa fest kleben zu müssen.

Doch zurück zum Thema, - die Kommunikationsgeschwindigkeiten, mögen dem einen oder anderem vielleicht gering erscheinen, da ich anfangs ja von großen Fließkommazahlen sprach. Nun, - das mathematische Zeugs, bleibt einzig und alleinig im raspberry, welcher dementsprechend alles andere per 1Byte Operationsbefehlen steuert. Belangt die letztendliche Motorsteuerung also überhaupt nicht. Nach mehreren entsprechenden Tests, kann ich mit reinem Gewissen behaupten, dass die Himbeere schnell genug ist, alle nötigen Berechnungen mindestens über hundert mal in einer 1/2400stel Sekunde auszuführen, während sie das in dieser Zeit aber nur einmal machen muss. Die parallele Kommunikation zwischen Himbeere und Brombeere muss dabei kaum berücksichtigt werden, da die oberhalb von einem MByte liegen wird. Aber auch dies, wird bei laufendem Motor dem Takt und der Synchronisation auf 2400 mal in der Sekunde entsprechend ablaufen, während zwischen Brombeere und den Johannisbeeren pro 1/2400stel Sekunde immer nur ein Byte gesendet und empfangen wird. Da bei 100kHz aber minimum auch immer bis zu 10000 Byte pro Sekunde übertragen werden können, würde das bei 2400 pro Sekunde, selbst dann noch immer; "in time", ohne Überläufe oder sonstigem geschehen, wenn man annehmen würde, dass bei zwei Motoren dabei vier Bytes hintereinander verschickt würden. Sinnigerweise, geht das durch die parallel arbeitenden Schiftregister des Atmegas aber gleichzeitig über zwei Schnittstellen. Selbst die Sendung und den Empfang könnte man noch lediglich um ein Bit verschoben parallelisieren, - was aber genauso wenig sein muss, wie gleichzeitig beantwortete gestellte Fragen, einfach ihre Tücken haben können. Letztendlich, sind aber auch das nur worst-case Überlegungen für sehr schlechte Kabelqualitäten oder/und Umgebungsstörungen. Alle über längere Kabel kommunizierenden Cpu's sind gleich getaktet und die Atmegas lassen bei 14,7456 Mhz generell, für rs232 die doppelte Geschwindigkeit von 230,4 Kbps, also 460,8 bei 0 Prozent Fehlerrate zu. Bezüglich SPI und kurzen Leitungen, darf man da ähnlich denken.

Die Cpu's sind jedenfalls dadurch sowieso nicht belastet, sondern brauchen nur Register zu beschreiben oder auszulesen, während die vier Bytes selbst bei 115,2 nicht mal die Hälfte eines 1/2400stel Zyklus benötigen, um durch die Kabel zu segeln. Das von den kleinen Johannisbeeren zurück gesendete Byte, wird übrigens den von ihr selbst gezählten Wert fürs Encodersignal enthalten und in drei aufeinanderfolgende Bytes aufgesplittet sein. Was dann 800 Werten in der Sekunde entspricht, die im motorisiertem Betrieb selbst bei Höchstgeschwindigkeit (1,5 Grad bei einer Encoderauflösung von ca. 16,2 Bogensekunden) immer noch mehr als doppelt so schnell abgefragt ist, wie sich bei laufendem Motor ein Signal ändern könnte. Der Interrupt im Atmega32 wird noch einen eigenen Teiler haben, mit dem man Schrittfrequenzen einstellen kann. (Im Voll- oder Halbschrittbetrieb, sollte man z.B. nicht mit 2400 Steps heizen, aber 1200 vertragen eigentlich alle.) Was aber nicht bedeutet, dass nicht jedes der Attinys trotzdem jede 1/2400stel Sekunde ein Byte erhält und eines zurück senden muss. Es wird lediglich per Inhalt des Bytes die Holunderbeere entsprechend der Frequenz steppen und evtl. die Schrittart ändern. Bei beidem, wie auch beim Stoppen, sehe ich übrigens vor, dies immer nur dann zu machen, wenn eine Vollschrittposition erreicht ist. Das gibt nicht nur Schrittpositionssicherheit, sondern ermöglicht auch ein überschaubares Rasterhandling zwischen allen benötigten Frequenzen für alle benötigten Schrittarten für auch alle benötigten Zwecke inklusive Beschleunigung und Abbremsen.

Was natürlich alles nur die Situationen betrifft, wo die Motoren laufen. Konfigurationen und Sonstiges, bzw. auch die Abfrage der Encoder im manuellem Positionierbetrieb, muss sich nicht an diesen Zeittakt halten, der aber immer noch mehr als genug Platz ließe, auch das LCD-Display mit Leben zu füllen. Dessen 4Bit-Schnittstelle mit einer Zykluszeit von 500 Nanosekunden sollte noch mehr als genug rein passen, - aber da das Teil jetzt nichts relevantes für die Steuerungsfunktionalität ist, kann das auch ein Hauptprogramm im Atmega32 machen. Ist ja nicht so, dass die Brombeere nur aus einem Interrupt besteht, der zudem nicht mal viel machen muss. Irgendwas, darf ja auch ruhig interruptet werden. Hauptsache, - er selber nicht. Der Interrupt wird übrigens eines der Signale zum raspberry betätigen und damit genauso ein Sperrflag für den Zugriff setzen, wie den raspberry mit sich synchronisieren, - welcher darob nur dann seine Kommunikation mit dem Hauptprogramm des Atmegas; "in time" tätigt, bevor der nächste Interrupt los geht und darob der Interrupt dann genauso die aktuellen Befehle vom raspberry hat, wie der vorher die vom Hauptprogramm ausgelesenen Register der empfangenen Bytes über rs232 oder Spi. Klingt verzwickt, - hat aber genauso seine Gründe, wie unsereiner jetzt endlich mit dem Löten und Programmieren des Früchtekuchens beginnen sollte.

Kleiner Nachtrag

Damit durch meine Begeisterungsfähigkeit keiner seiner Himbeere Schaden zufügt, möchte ich darauf hinweisen, dass ich vergessen habe zu erwähnen, dass die Portsignale der raspberry 3.3 Volt Geschichten sind, die als Eingänge nicht tolerant zu den Ausgängen von den 5Volt-Versionen meiner Atmegas sind. Also nicht einfach so verbinden, sondern schon eine Pegelwandlung mindestens für die 5V-Ausgänge zu 3V3-Eingängen vom raspberry dazwischen bauen. Ich selber, sehe für meine Datenschnittstelle die bewährten Puffer der Marke 74LVTH245 vor.

Update: 20.12.18
Der vormals erwähnte Attiny 2313 wird durch den Attiny4313 ersetzt. Der ist vollkommen gleich, hat aber doppelt so viel Speicher wie der 2313 mit nur 2Kb Flashspeicher. (Bin bei 3,5 kb angelangt dafür :-)