Selbstbausteuerung mit open source fw?

Ha,
was für eine Frage ...

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*

Display More

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

Steffen

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.

Naja, ich denke auch dass sowas durch aus auch mit dem xmega möglich ist. Aber welche Vorteile hat der dann gegen den ARM? Preislich sind die µC ja eh alle in der selben Klasse.

Quote

... natürlich das ELT steuern, wenn es färtsch ist!

Quote

bisher haben wir 'nur' eine 32 Bit MCU!

Quote

Aber welche Vorteile hat der dann gegen den ARM?

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.

Wenn Ihr Fixed Point MAthematik unterstützt.

Quote

<i>Original erstellt von: ThomasWest</i>
– Eight-channel Event System
– 8x 16-bit Timer/Counters
– 8x USARTs
– 4x Two-Wire Interfaces with dual address match (I2C and SMBus compatible)
– 4x SPI (Serial Peripheral Interface) peripherals
– AES and DES Crypto Engine
– 2x Eight-channel, 12-bit, 2 Msps Analog to Digital Converters
– 2x Two-channel, 12-bit, 1 Msps Digital to Analog Converters
– 4x Analog Comparators with Window compare function
- EBI Interface mit DMA für Displays,SRAM,SDRAM

Display More

Im Vergleich mal dazu der LPC1768:
1 Ethernet MAC,
1 USB Device/Host/OTG interface,
8-channel general purpose DMA controller,
4 UARTs,
2 CAN channels,
2 SSP controllers,
SPI interface,
3 I²C-bus interfaces,
2-input plus 2-output I²S-bus interface,
8-channel 12-bit ADC,
10-bit DAC,
motor control PWM,
Quadrature Encoder interface,
four general purpose timers,
6-output general purpose PWM,
ultra-low power Real-Time Clock (RTC) with separate battery supply,

Tja,
das ist halt der große Unterschied!

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.

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

Quote

<i>Original erstellt von: selste</i>
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;

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

Hallo,
vielen Dank für den Link!

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

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

Es ging mir nicht darum euch zu bekehren. Wenn ihr euch für de LPC2148 entscheiden habt, dann zieht das durch!
Es ist halt nur in der Diskussion so raus gekommen, daß heutzutage überaupt nichts mehr für einen 8-Bitter sprechen würde. Dafür wollte ich nur eine Erklärng haben. Wenn dem so wäre, dann dürfte Atmel überhaupt kein Interesse dran haben die Xegas zu entwickeln. ARMs haben die ja schon länger. Wenn also die Zeiten der 8-bitter vorbei sind warum invesiert Atmel dann noch in diese Prozessorfamilie?

Hi,

Quote

Es ging mir nicht darum euch zu bekehren. Wenn ihr euch für de LPC2148 entscheiden habt, dann zieht das durch!
[...]

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

Ja wobei der Beitrag aus dem Jahre 2007 stammt und da die Xmegas noch nicht am Markt waren. Bei denen ist ja auch durch das EBI der Zugriff auf extrenen SDRAM möglich. Ich hab bei mir einen 4MByte SDRAM dran. Zudem liegt bei den XMegas der Takt höher als bei den alten AVR. Ich denke mit den Xmegas wollte ATMEL einfach ein Bindeglied zwischen den alten AVR und den ARM schaffen.
Der Post von Peter Danegger im selben Thread kurz nach Robert Teufel ist auch nett
Let bringt meine Meinung auf den Punkt. Wer in die Materie einsteigt ist mit einem AVR besser bedient als mit einem ARM.

Quote

<i>Original erstellt von: ThomasWest</i>
Let bringt meine Meinung auf den Punkt. Wer in die Materie einsteigt ist mit einem AVR besser bedient als mit einem ARM.

So, nachdem ich nun ne Weile mit den CortexM3 gearbeitet hab, muss ich sagen die Programmierung ist eigentlich genau so einfach wie bei einem ATMega. Klar, die Funktionen sind Umfangreicher und daher sind nicht alle Register so schnell klar, aber so groß ist der Unterschied nicht.

Ich werde wohl in Zukunft nur noch ARMs einsetzten
Mit den CortexM0 gibts auch Preislich keinen Nachteil zu den ATMegas.

Hallo an Alle, Hallo Michael

Interessantes Projekt !

Ich bin gerade eben auf diesen Thread gestoßen und habe die 25 Seiten in Riesenschritten "durchgelesen".
Im Rahmen meiner Möglichkeiten könnte ich mich gerne in das Projekt einbringen. Ich entwickle Firmware, allerdings für Atmels 8 Bitter und ich entwickle in Modula [^]
Ich arbeite mit einem professionellen Leiterplatten CAD System ...
Vielleicht könnte mich jemand auf den Stand der Dinge bringen.
und... wo klemmt es denn am meisten?

Michael, Werner,
ich hatte mich damals aus der Software-Entwicklung zurückgezogen, nachdem - in der damaligen Aufbruchstimmung - alle gleichzeitig losgestürmt sind und ich nur wenig Sinn darin sah, unabgestimmt weiter zu machen..
Schade, dass da anscheinend fast alle Aktivitäten eingeschlafen sind aber ich tät schon noch mitmachen, die Architektur zu definieren - und ich würd auch was umsetzen wollen

Ich denke, es wäre nun an der Zeit, erst mal ein wenig zu diskutieren, um zu einem Ansatz zu kommen, von dem alle glauben, dass er funktionieren kann und dann miteinander abgestimmt die einzelnen Komponenten anzugehen.

Ich poste heute abend mal (von zu Hause aus) mal was ins Wiki...

Grüße
Holger

Michael,
als potentieller Interessent und Nachbauer einer Selbstbausteuerung möchte ich mich hier mal kurz melden.

Leider reichen meine vor vielen Jahren erworbenen Kenntnisse hint' und vorn nicht, um euch aktiv bei der Firmware- oder Softwareentwicklung zu unterstützen. Daher kann ich für das Projekt in der jetzigen Phase nur sehr begrenzt von Nutzen sein.

Die Idee, erst mal mit einer kleinen Variante auf AVR-Basis zu starten, finde ich sehr gut. Die Treiberplatine hat ja schon einen hervorragenden Eindruck gemacht. Es wäre schade, wenn die nun lange nicht zum Einsatz käme.

Darren Hutchinsons Steuerung scheint ja vom Aufwand her durchaus geeignet, eine quick-and-dirty-Zwischenlösung zu bauen.

Ohne nennenswerten Anpassungsaufwand wird das aber nicht gehen:
Die Lowlevel-Ansteuerung der Portbits fällt natürlich weg, dafür müssen die Stepperkommandos für die Treiberplatine geeignet übersetzt werden.
Eine Neuprogrammierung der Lowlevel-Treiberroutinen wird dadurch nötig sein, ebenso die Implementierung einer geeigneten Schnittstellenroutine. Es werden jede Menge Portbits frei.

Hardwareseitig wäre eine Prozessorplatine fällig, die nach außen zumindest ST4, RS232 und Handbox-Interface bieten sollte. Leider kann man wohl die EQ6-Steuerbox nicht einzeln nachkaufen. Daher müssten wir uns einigen, ob wir eine "dumme" Handbox unterstützen oder eine mit integrierter CPU und serieller Übertragung, und welche bzw. woher wir die nehmen. Das Handbox Elektronik- und Mechanikdesign könnte ja auch jemand ohne spezielle µC-Kenntnisse bewältigen.

Nachdem kleine CPUs nur noch ein paar Cent kosten, wäre eine einfache Prozessor-Handbox sicher das Beste, weil sie nur 3-4 Kabeladern bräuchte. Das wär dann genau das Richtige für ein kleines AVR-Einsteigerprojekt, denke ich.
Zunächst nur unidirektionale Datenübertragung und mit 6-8 Tasten, als Erweiterung evtl. bidirektional und ein paar Status-LEDs. Später aufbohren mit Display zur Positionsanzeige ginge dann immer noch.

Vielleicht kann mal jemand die zu erledigenden Aufgaben ("Gewerke"?) auflisten. Dann melden sich vielleicht eher Freiwillige, die Teilaufgaben in Angriff nehmen.

Habe ich das eigentlich richtig verstanden, dass bei Darren Hutchinsons Steuerung ebenso wie bei der original EQ6-Steuerung komplett auf Beschleunigungsrampen verzichtet wird? So wird natürlich nur ein Bruchteil des Leistungspotentials der Treiberplatine ausgenutzt.

Gruß,
Martin

So, wie angekündigt habe ich gerade mal was ins OpenDrive-Wiki (Software/Architektur-Thread) gepostet. Für alle, die nicht abwarten können, bis der dortige Moderator meinen Artikel freischaltet: Ihr dürft meinen Top-Down-Ansatz auch gerne schon mal unter http://www.smolinski.name/Astronomie/OpenDriveSW.pdf anschauen und zerreissen...oder mir einfach Feedback geben, wie ich den noch (inhaltlich ode strukturell) verbessern kann, oder ob ich ihn am Besten gleich in die Tonne kloppe...
DS, Holger

Hi Michael,
naja, das Aufschreiben war in 3-4 Stunden heute abend getan - am längsten hat es noch gedauert, die Grafik zu zeichnen, weil mit zwischendrin immer wieder auffiel, dass da noch was fehlte.
Allerdings hatte ich ja auch schon damals mir eine Menge Gedanken gemacht, wie das Ganze funktionieren kann und in welcher Art und Weise ich so eine Software bauen würde...diese zahllosen Stunden sind natürlich nicht mitgezählt.
Achso, noch ein kleiner Hinweis, das Ding ist jetzt ja 20 Seiten groß und wird sicher noch viel größer werden, je mehr Details aufgenommen werden. Das muss natürlich niemand ganz lesen, es reicht, wenn jeder nur das liest, was ihn gerade interessiert (und das, was damit zusammenhängt).
DS, Holger