mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Welcher Microcontroller


Autor: Alex Tricktronic (tricktronic1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe verschiedene Anforderungen, was mein Controllersystem können 
muss und möchte dazu den passenden Microcontroller finden.
Welchen Controller kann ich hier verwenden?
- Taktfrequenz min. 40MHz - max. 200MHz
- 8 GPIO, 100kHz sollen möglich sein
- I2C (hi-speed) Slave möglich
- FPU (mul/div)

Gibts im Netz so eine Art Konfigurator den man einstellen kannwas man 
haben will der anzeigt welche Typen passen würden?
Wisst ihr einen Controller der das alles kann?

Danke,
Alex

P.S.: Er soll natürlich dann auch nicht zu viel können (Graphik, 
Ethernet usw. ist preislich nicht erwünscht)

Autor: Jörg S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> P.S.: Er soll natürlich dann auch nicht zu viel können (Graphik,
> Ethernet usw. ist preislich nicht erwünscht)
Und wozu dann 40MHz?

Autor: Weisnix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Google??? Datenblätter wälzen???
Oder bist du zu Faul??? Dann lass dein Projekt am besten gleich sein.

Autor: Alex Tricktronic (tricktronic1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Programm muss ich ziemlich viele Berechnungen innerhalb kürzerster 
Zeit machen und die Ausgänge danach setzen.
Bei der Aussage "er soll natürlich nicht zu viel könenn" habe ich die 
peripheren Schnittstellen gemeint.

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn Du schnell rechnen mußt, könnte ein DSP in Frage kommen.

Autor: Alex Tricktronic (tricktronic1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe mit DSPs noch nie was gemacht und weiss auch ehrlich gesagt 
nicht zu was die in der Lage sind.
Ich habe auch schon an FPGAs gedacht, aber ich kann VHDL nicht und das 
soll ziemlich umfangreich sein.

Auf was sollte man beim DSP achten, um den richtigen zu bekommen und 
gibt es gute Gratistools zum Programmieren?

Danke für diesen ersten ergebnisorientierten Post.
Alex

Autor: Peter S. (psavr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die heutige Auswahl an Prozessoren und Controller ist riesig, ich würde 
noch weitere Faktoren berüksichtigen.

8, 16 oder 32 Bit Prozessor?
Wieviel RAM und ROM schätzt Du zu benötigen?
Mit internem oder externem ROM/RAM?
Preis für den Controller
SW-Entwicklungsumgebung (Kentnisse? Preislage? Vorhandenes?)

Vermutlich wären die ARMs etwas für Dich, aber ich denke nicht, dass 
diese eine FPU haben.

http://www.mikrocontroller.net/articles/ARM

Wenn Due wirklich eine FPU wegen der Rechenlestung brauchst, solltest Du 
auch einen Blick auf DSP's werfen.

MfG  Peter

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Controller mit integrierter FPU?!

Oftmals lassen sich FP-Berechnungen durch sinnvolle Betrachtung der zu 
erwartenden Werte auf Fixkomma-Berechnungen umstellen, und die wiederum 
sind auch mit integer-Arithmetik in den Griff zu bekommen.

Autor: Dirk Hofmann (arm-dran)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alexander Födinger wrote:
> Im Programm muss ich ziemlich viele Berechnungen innerhalb kürzerster
> Zeit machen und die Ausgänge danach setzen.
> Bei der Aussage "er soll natürlich nicht zu viel könenn" habe ich die
> peripheren Schnittstellen gemeint.

In welcher Sprache willst Du den Programmieren?

Assembler ? C ?
Mußt Du Analogwerte auswerten?

Kennst Du Dich überhaupt in Richtung Controller Technik und 
Programmierung aus?

Wenn Du Assembler nimmst, reicht ein schneller 8051, bei C nimm lieber 
ne Pentium DUO Core, mit DSP Einsteckkarte :-)

Autor: Alex Tricktronic (tricktronic1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In meinem Fall ist der Wertebereich zu hoch sodass eine Aufspreizung der 
Werte auf 32 bit zu kompliziert werden würde.

Ok, fangen wir mal so an:
Ziel meines Projektes ist es, eine Bahnsteuerung für 3 Achsen mit 
Schrittmotoren zu bauen. Dabei muss ich jeden Schrittmotor mit 100kHz 
takten können. Dazwischewn muss ich im worst case Ellipsen fahren 
können. Das heißt Berechnung von Winkelfunktionen, Quadratwureln und ein 
paar Multiplikationien und Additionen innerhalb der Taktzeit bei eben 
diesen 100kHz-Takten.

Da die Berechnungen für mindestens 3 Achsen auf meinen aktuellen 
Controllern (Coldfire MCF5206e 40MHz und MCF5270 86MHz) zu langsam sind 
will ich die Achsen auslagern.
Jede Achse soll also ihren eigenen Controller haben der evtl. sogar 
schneller ist als ein Prozessor der jetztigen Hardware.

Alex

Autor: Alex Tricktronic (tricktronic1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
RAM: Ca. 8MB
ROM: Ca. 2MB
int. RAM am besten ca. mindestens 8k für Stack.

Das Programm ist bis jetzt in C geschrieben, das will ich wenn geht auch 
nicht ändern da ich da schon eine Zeit lang gesessen bin.

SW-Entwicklung bis jetzt Codewarrior, AVRC, AvrAsm, Linux. Ich wills 
aber wegen Performance unbedingt ohne Betriebssystem bauen!

Autor: Dirk Hofmann (arm-dran)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
8K für Stack ?

Dann brauchst Dich nicht wundern, daß Coldfire nicht ausreicht.
Das sind doch nur einfache Geometrische Berechnungen.

Wechsle die Programmiersprache und Du wirst erstaunliches feststellen.

Autor: Alex Tricktronic (tricktronic1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich habe beim 5206e die gesamten 8k für den Stack verwendet.
Wie viel ich wirklich brauche weiss ich nicht, da ich den Stackverbrauch 
ohne os nicht so einfach bestimmen kann. Wahrscheinlich brauche ich 
nicht annähernd so viel!

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Dirk Hofmann

>Dann brauchst Dich nicht wundern, daß Coldfire nicht ausreicht.
>Das sind doch nur einfache Geometrische Berechnungen.
>Wechsle die Programmiersprache und Du wirst erstaunliches feststellen.

Auf was sollte er denn wechseln? Vielleicht ASM. Na dan mal viel Spass 
bei dem ganze Floating Point Gerechne.

10 us ist schon heftig, da hat ein 100 MHz Prozessor gerade mal 1000 
Takte. Da sollte man erstmal überlegen ob

a) Festkomma mit 32 bzw 64 nicht nicht schneller ist
b) ob es Optimierungspotential durch Tabellen anstatt Winkelfunktionen 
gibt
c) ob generell ein guter Algorithmus vorliegt

MfG
Falk


Autor: Alex Tricktronic (tricktronic1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gute Idee, hab ich schon gemacht:
64 Bit ist beim MFC5206e genau so schnell wie Floating Point (da ja 
beides umgerechnet werden muss). Beim 5270 ist sowiso fp schneller 
(wegen FPU).
Die Winkelfunktionen habe ich schon in Tabellen hinterlegt - da lässt 
sich einiges herausholen, das stimmt.
Gewisse Wurzelwerte habe ich auch schon in Tabellen gelegt und meine 
eigene Wurzelberechnung programmiert. Da fängt man an zu schwitzen beim 
Wertebereich von float.
Durch die Tabellen habe ich auch den großen RAM-Bedarf.
Ein Teil davon wird bei der Initialisierung berechnet, ein Tei davon 
nach der Parametrisierung und ein Tei ist als Konstante hinterlegt.

Trotzdem - nach aller Performanceverbesserung stehe ich vor dem großen 
Problem dass ich mit meinen Controllern nicht auskomme.

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Alexander Födinger

>64 Bit ist beim MFC5206e genau so schnell wie Floating Point (da ja
>beides umgerechnet werden muss).

Was muss bei 64 Bit Festkomma umgerechnet werden?

MfG
Falk

Autor: Gast2 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein FPGA würde sich dann auf jeden Fall eignen, wenn du noch weitere 
Logikbausteine damit ersetzen kannst. Mit ein bisschen Werte berechnen 
bei 100 kHz langweilt sich die Kiste.

Das hängt natürlich ganz von dem Projekt ab. Bei einem kommerziellen 
Produkt wäre wohl Preis/Leistung das wichtigste, wenns ein (wohl sehr 
anspruchsvolles) Bastlerprojekt ist kannst du den "Lernfaktor" für FPGA 
zählen lassen. Und ein FPGA lässt sich universeller einsetzen als ein 
DSP.

Autor: Alex Tricktronic (tricktronic1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, ich glaube mittlerweile auch dass ein FPGA die vernünftigste Lösung 
wäre.
Und dass ihm nicht so fad wird könnte ich die Bahnsteuerung ja auf 5 
Achsen erweitern...

Danke für die konstruktiven Vorschläge!


P.S.: Was muss bei 64 Bit Festkomma umgerechnet werden? beantworte ich 
hier sicher nicht. @see math.c

Autor: Dirk Hofmann (arm-dran)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Auf was sollte er denn wechseln? Vielleicht ASM. Na dan mal viel Spass
> bei dem ganze Floating Point Gerechne.

Hast Du dich schon mal mit Assembler beschäftigt ??? Jedes C Programm 
besteht im Grunde genommen aus Assembler Befehlen.
Floating Point spielt im Binären Raum von ASM sowieso keine Rolle.
Wie man die Werte nachher behandelt ist eigene Sache.

Ich habe schon mehrfach C-Programme disassembliert.
Wenns Dumm läuft sinkt die Effizienz so ab, daß man gleich einen 
Controller
mit nem 10-30tel der Taktrate verwenden kann.

Außerdem ein reproduzierbares Timingverhalten herzustellen, naja, oder 
bezweifelt das jemand.

Man kann auch mit Kanonen nach Spatzen schiessen.

Autor: Zacc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein bisschen Achsen drehen sollte noch keine FPU bedingen. Der 
Werteberich ist nicht vorhanden. Allenfalls kann man sich mit 
Quaternionen behelfen. Auch wenn die Schrittmotoren mit 100kHz getaktet 
sind, kann ich mit kein System vorstellen, das physikalisch derart 
schnell waere, dass die neuen Werte mit 100kHz berechnet werden 
muessten. Das wuerde reichen um ein mechanisches System mit einer 
Grenzfrequenz (Tiefpass) von 10kHz zu kontrollieren. Da wird massiv 
Rechenpower verschleudert.

Z

Autor: Alex Tricktronic (tricktronic1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir ist schon klar dass ich meine 2 MB Source-Code auf Assembler 
übersetzen kann.
Aber ist dieser Rieseige Brocken Software dann noch gut lesbar?

Ein paar Funktionen habe ich eh schon in asm geschrieben, andere habe 
ich mit dem compiler und optimierer auf höchster Strufe disassemblieren 
lassen und festgestellt dass nicht recht viel Unterschied besteht - im 
Gegenteil, ich denke bei der Vielfalt an möglichen Assemblerbefehlen 
beim 68k ist der integrierte Optimierer sicher besser als ein 
durchschnittlicher bis guter Programmierer.
Da muss man sich schon für 400 asm-Befehle ein paar Stundn hinsetzen um 
die beste Performance heraus zu holen. Der Optimierer schaffts in einer 
10tel Sekunde.


Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch ich kann nicht nachvollziehen, wieso in welchem mechanisches System 
100.000 mal pro Sekunde ein Richtungsupdate notwendig sein sollte. Bei 
einer angenommenen Genauigkeit von 1mm pro Update würde das einer 
Bewegungsgeschwindigkeit von 100 m/s entsprechen, d.h. 1/3 
Schallgeschwindigkeit. Allein aufgrund der auftretenden Trägheitskräfte 
dürfte jedes mechanische System damit überfordert sein, es sei dem du 
programmierst eine Steuerung für einen Transrapid, doch der fährt nicht 
auf komplexen Ellipsenbahnen.
Bei Roboterarmen wird im Allgemeinen eine mehrstufige Positionierung 
verwendet: Schnelle, möglichst geradlinige Bewegung bis nahe an die 
Endposition und anschliessend langsam, aber präzise an die Endposition. 
In beiden Fällen dürften ca. 1000 Update pro Sekunde ausreichen. Die 
eigentliche Ansteuerung der Schrittmotoren würde ich einer intelligenten 
Peripherie (Timer mit PWM) oder einem externen IC überlassen.

Gruss

Mike

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Dirk Hofmann

>Hast Du dich schon mal mit Assembler beschäftigt ??? Jedes C Programm

Durchaus.

>besteht im Grunde genommen aus Assembler Befehlen.

Was du nicht sagst! Und Apfelmus ist Mus aus Äpfeln.

>Ich habe schon mehrfach C-Programme disassembliert.
>Wenns Dumm läuft sinkt die Effizienz so ab, daß man gleich einen
>Controller
>mit nem 10-30tel der Taktrate verwenden kann.

Und ASM kann mit einem Befehl sämtliche Operationen ausführen, wo C 
10..30 braucht?!? Aha.

>Außerdem ein reproduzierbares Timingverhalten herzustellen, naja, oder
>bezweifelt das jemand.

C ist auch ganz gut reproiduzierbar, wenn gleich nicht auf den Takt 
genau wie Assembler.

>Man kann auch mit Kanonen nach Spatzen schiessen.

Ja eben, und komplexere Berechnungen "per Hand" in Assembler zu 
programmieren ist so eine Kanone.

MfG
Falk

Autor: Alex Tricktronic (tricktronic1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Zacc warum weiss du denn dass der Wertebereich nicht vorhanden ist? 
Kennst du mein Projekt im Detail?

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dirk Hofmann wrote:

> Ich habe schon mehrfach C-Programme disassembliert.
> Wenns Dumm läuft sinkt die Effizienz so ab, daß man gleich einen
> Controller
> mit nem 10-30tel der Taktrate verwenden kann.

Also 1/30 ist total übertrieben, max 1/2 ist real.

Wenn man C programmieren kann, d.h. nur die nötigen Datentypen 
verwendet, lokale Variablen (d.h. in Registern) bevorzugt und nicht alle 
Schleifenzähler als double float definiert, dann ist C vielleicht 20% 
langsamer, im äußersten Fall auch mal 50% (also max 1/2).


Peter

Autor: Martin Schneider (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, mal ein Einwurf aus der Praxis:

Delta Tau benutzt in der PMAC-Serie (Motioncontroller bis 8 Achsen)
einen DSP aus der 56K-Serie mit anfangs 40MHz, inzwischen 80..240MHz.

256k RAM/ROM, eigener ASIC für das Achs-Interface.

Die Teile sind zwar Sch.. zu programmieren (eigene Sprache), aber
schon potent.


Ahoi, Martin

Autor: Dirk Hofmann (arm-dran)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alexander Födinger wrote:
> Mir ist schon klar dass ich meine 2 MB Source-Code auf Assembler
> übersetzen kann.
> Aber ist dieser Rieseige Brocken Software dann noch gut lesbar?
>
> Ein paar Funktionen habe ich eh schon in asm geschrieben, andere habe
> ich mit dem compiler und optimierer auf höchster Strufe disassemblieren
> lassen und festgestellt dass nicht recht viel Unterschied besteht - im
> Gegenteil, ich denke bei der Vielfalt an möglichen Assemblerbefehlen
> beim 68k ist der integrierte Optimierer sicher besser als ein
> durchschnittlicher bis guter Programmierer.
> Da muss man sich schon für 400 asm-Befehle ein paar Stundn hinsetzen um
> die beste Performance heraus zu holen. Der Optimierer schaffts in einer
> 10tel Sekunde.

Hallo Alexander,

wir können ja mal ein einfaches Example statuieren (und übrigens, die 
meisten Programmierer in C verstehen von Assembler soviel wie eine Kuh 
vom Eierlegen).

Einfache Aufgabe:

Nimm einen 8 Bit Port. An dem hängen 8 Tasten.

Erzeuge 2 Byte: Das eine Byte zeigt welche Tasten gerade gedrückt wurden 
(aber nur in dem Moment, nicht permanent) und in dem anderen welche 
losgelassen wurden.

Wer Lust hat kann mitmachen

Lösung in Assembler und in C und disassemblierten C.
Zeig mir ein Assemblerprogramm für so eine Anwendung, welches 2MB 
braucht.
Wieso hat man früher in 32KB ROM ein komplettes Betriebssystem gebracht?

Man sollte nur von etwas reden, was man versteht.
Ich programmiere seit 20 Jahren in Assembler und weiß wovon ich rede.








Autor: Dirk Hofmann (arm-dran)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

den Beweis würde ich gern antreten.
Es ist garnicht möglich, in einer Programmiersprache, die jetzt bald 40 
Jahre alt ist und vom Syntax auf eine ganz andere Anwendung ausgelegt 
war was gescheites zu programmieren.

Warum werden heute Prozessoren mit 3-4 GHz gebaut, Duo, Quadcore usw.
und die effektive Leistung nimmt kaum zu. Und wenn dann macht es zum
großen Teil die Hardware, DMA, Grafikchips, Chipsets.

Als Beispiel: Ich mußte für einen Kunden ein Handbediengerät für 
Maschinen
nachbauen, weil die es abgekündigt haben. Darin sitzt ein 16/32 Biter 
von Hitachi mit 128KB Flash. Die habe sogar noch Timingprobleme mit der 
Verarbeitung der Daten über die RS232 bei NUR!!! 9600 Baud. Das neue 
Gerät
hat einen AT89S52 für 1€ und erfüllt die gleiche Funktionalität???

Und ??? Noch Fragen???

Autor: tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also mal aus der Praxis. Ich programmiere seit 10 Jahren in Assembler 
und C.
Mein Entwicklungsleiter seit 20Jahren immer nur in Assembler. Letztens 
kamm es dann auch mal zum Streit. Er hat dann das Programm in Assembler 
gemacht und ich in C.   Codeumfang in C war ca. 20% größer, 
Geschwindigkeit eigentlich nicht zu unterscheiden. Nur... Er hat 
20Stunden gebraucht und ich nur 4. Ausserdem ist mein C Programm leicht 
lesbar, das Assemblerprog. ehr nicht.
Fazit, wenn ich nochmal was in Assebler mache muss ich schon sehr 
wichtige Gründe anbringen.  Ach ja war nen PIC Controller.

Autor: Dirk Hofmann (arm-dran)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
tom wrote:
> also mal aus der Praxis. Ich programmiere seit 10 Jahren in Assembler
> und C.
> Mein Entwicklungsleiter seit 20Jahren immer nur in Assembler. Letztens
> kamm es dann auch mal zum Streit. Er hat dann das Programm in Assembler
> gemacht und ich in C.   Codeumfang in C war ca. 20% größer,
> Geschwindigkeit eigentlich nicht zu unterscheiden. Nur... Er hat
> 20Stunden gebraucht und ich nur 4. Ausserdem ist mein C Programm leicht
> lesbar, das Assemblerprog. ehr nicht.
> Fazit, wenn ich nochmal was in Assebler mache muss ich schon sehr
> wichtige Gründe anbringen.  Ach ja war nen PIC Controller.

ahja,

naja, verstehe dann bloss nicht, warum überall im Forum steht:
Ich brauche eine Ansteuerroutine für dies und für das. Für ein 
Textdisplay, für eine I2C-Peripherie, sogar für die 
Bausteininitialisierung.

Seit wann braucht man für sowas Treiber?
Eh, die gefunden sind, bin ich fertig mit der Programmierung.
Übrigensm das Handterminal hatte 120KB verbraucht, ich nur 5. Warum ???

Autor: tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
du bist halt der größte Assembler-GOTT hier am Platz.

Werde glücklich damit,...

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dirk Hofmann wrote:

> Seit wann braucht man für sowas Treiber?

Es ist halt schön, wenn man Sachen, die man öfters braucht, etwas 
universeller schreibt, damit man sie nicht jedesmal neu schreiben muß.

Ich hab da auch einige, die ich ohne groß nachdenken zu müssen einfach 
mit dazu linke. Man kann sowas Treiber nennen, muß es aber nicht.


> Übrigensm das Handterminal hatte 120KB verbraucht, ich nur 5. Warum ???

Na dann könnte ich es in C vielleicht in 4,5kB schaffen.

Es ist ne altbekannte Tatsache, daß man Programmieren nicht in der 
Schule lernen kann, sondern nur durch programmieren, programmieren und 
programmieren.

Es kann daher nicht verwundern, daß es da Effizienzunterschiede von 
100:1 und mehr gibt.

Diese Unterschiede haben aber überhaupt nichts mit C oder Assembler zu 
tun.


Peter

Autor: Dirk Hofmann (arm-dran)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry Tom,

so redet jemand, dem die Argumente ausgehen. Mit Gott hat das nix zu 
tun.
Ich bin in der Industrie tätig. Und da zählt, was unter dem Strich 
rauskommt.
Und wenn ich ständig mitbekomme, daß Maschinensteuerungen sich 
aufhängen,
abstürzen etc. und das heute im Industrie und Privatbereich eigentlich 
schon zum guten Ton gehört, dann weiß ichs auch nicht mehr.

Bei Autos ist mittlerweise die größte Ausfallstatistik auf Software 
zurückzuführen.
Es wurde ein Ausdruck geprägt:
KISS

Keep It and Short and Simple
Das heißt soviel wie, orientiere Dich an dem was gebraucht wird.
Und man wird es Dir danken. Ich spreche aus Erfahrung.

Natürlich stecken hier ganz andere Interessen der Hard und 
Softwareindustrie dahinter, um zu verkaufen.

Aber auch bei der Programmierung ist es so. Um ein Verständniss für 
Abläufe und Problemlösungsstrategien zu bekommem, sollte man beim 
Grundwissen anfangen.

Ich kam auch nicht als Erwachsener zur Welt.

Autor: Dirk Hofmann (arm-dran)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

da hast Du schon recht.

Das bedingt aber eigentlich, wie in jedem Bereich, daß ,man in seinem 
Bereich gut sein muß.
Das heißt, wenn man (wie es heute gang und gebe ist) Leute auf Projekte 
mit Verantwortung loslässt, kann das bös enden.

Wie Du weisst, kann man sich in ASM genauso eine Bibliothek aufbauen.
Kommt ein neues Bauteil wie Display dazu, wie lange soll ich dann warten 
und Suchen, ob mal jemand nen Treiber schreibt.

Ich hatte mal nen Bekannten der hat behauptet C wäre viel schneller als 
Assembler und wusste nicht mal, daß Assembler die Ursprache ist.

Ich will garnichts gegen C sagen. Aber jeder der dies Programmiert 
sollte auch Assembler können. Warum soll man sich sonst was 
disassembleieren lassen.

Warum hat eigentlich noch niemand auf meine kleine Aufgabenstellung oben 
reagiert ?

Autor: Sabine (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Dirk Hofmann

Hör doch endlich auf, mit Deinen an den Haaren herbeigezogenen 
Beispielen hier im Forum herum zu miespetern! Ich denke Du bist einfach 
nur frustriert, weil Du zu doof bist, richtig C zu lernen und zu 
verstehen!

Ok, es komm sicher mal vor, dass ein erfahrener ASM-Freak ein C-Neuling 
recht alt ausehen lassen kann!

Aber Fakt ist: Gut geschriebene C-Programme mit vernünftigem Compiler 
übersetzt sind nur ca. 10..30% grösser bzw. langsamer, als man es mit 
Assembler hinkriegen würde. Dafür ist der C-Programmierer 10 x schneller 
fertig, der Code ist viel besser lesbar und einfacher auf andere uC zu 
protieren.

Klar gibt es auch schlechte Beispiele, in C wie auch in ASM. Und es gibt 
vermutlich 100 mal mehr C-Programmierer als ASM-Freaks, logisch dass es 
im Forum auch 10..100 mal mehr C spezifische Fragen und Problemchen 
gibt!

Autor: Mr. G-Code (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Alexander,

>Ok, fangen wir mal so an:
>Ziel meines Projektes ist es, eine Bahnsteuerung für 3 Achsen mit
>Schrittmotoren zu bauen. Dabei muss ich jeden Schrittmotor mit 100kHz
>takten können. Dazwischewn muss ich im worst case Ellipsen fahren
>können. Das heißt Berechnung von Winkelfunktionen, Quadratwureln und ein
>paar Multiplikationien und Additionen innerhalb der Taktzeit bei eben
>diesen 100kHz-Takten.

ich habe so etwas mit 4 synchronen Achsen bei einem Takt von max. 
20kHz/Achse auf einem C167/20MHz implementiert. Genauigkeit der 
Berechnungen 0,5µm! Alle Rechnungen werden im Long (4Byte) Integerformat 
ausgeführt. Winkelfunktionen sind in einer Lookup-Table hinterlegt! 
Alles in C, mit ein bischen ASM-Optimierung an zeitkritischen Stellen. 
Wo liegt das Problem?

Schnelligkeit (Takt, Busbreite) von Controllern ist nicht alles. 
Peripherie und richtige Programmierung sind nicht zu unterschätzen!

Ich weis nicht was Du für Schrittmotoren hast, die 100kHz unter Last 
folgen können? Oder bist Du in der Nanotechnik zuhause?

Autor: Dirk Hofmann (arm-dran)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sabine wrote:
> @Dirk Hofmann
>
> Hör doch endlich auf, mit Deinen an den Haaren herbeigezogenen
> Beispielen hier im Forum herum zu miespetern! Ich denke Du bist einfach
> nur frustriert, weil Du zu doof bist, richtig C zu lernen und zu
> verstehen!

Tja Sabine,

wie gesagt, wenn die Argumente fehlen. Aber leider geht es um die 
Realität.
Wer sagt, daß ich kein C kann.

Schau Dir mal den Beitrag von G-Code an.
Ich denke, dort steht was gemeint ist. Mit Kanonen nach Spatzen 
geschossen.
Es werden Sachen aufgeblasen, wo es eine ganz einfache Lösung gibt.

Warum redest Du gegen Mich und gibst nicht dem Author dieses Artikels 
fundamentierte Unterstützung?

Autor: Jemand Anders (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Google nach LPC3180; würde den Anforderungen genügen ist aber als 
Microcontroller mit I/O Funktionen eher mittelprächtig und entspricht 
somit wiederum den Anforderungen, hat vieles nicht.


Autor: Zacc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>@ Zacc warum weiss du denn dass der Wertebereich nicht vorhanden ist?
Kennst du mein Projekt im Detail?

Drehen ist 0..2Pi, die wenigsten Amwendungen benoetigen einen 
dynamischen Bereich groesser als 10^9, Das kann man mit 32 bit abdecken. 
Strom und Spannung ist selten genauer als 10^-3, die anderen 
physikalischen Groessen
sind auch im Bereich 10^-3. Statische Skalierungen zieht man raus.

Nein ?

Z

Autor: NaYthan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ah, die leidige Diskussion C oder ASM...

In den Anfängen der Computergeschichte hätten die Programmierer für 
assembler getötet (ja die haben noch ihren eigenen Machinencode mit DIP 
Schaltern eingegeben), heutzutage kaufen sich faule HLL (High Level 
Language) Programmierer lieber einen schnelleren Controller als nochmal 
auf ASM zurück zu greifen.

Ans Ziel kommt man heutzutage sicherlich mit beiden Methoden, Fakt ist 
jedoch:

Assembler ist die Machinen-nächste Sprache. In ASM schreibt sich der 
schnellste und knappste code. Allerdings dauert das schreiben in 
Assembler auch recht lange (insbesondere wenn man einen komplexen 
Controller wählt).

C ist die schnellste und grundlegenste der HLL's. Schneller und kurzer 
code lässt sich mit C entwickeln, die aufgewendete Zeit diesen zu 
schreiben ist gegenüber assembler auch viel geringer. Da C eine High 
Level Language ist, lässt sich derselbe C code auch viel leichter auf 
verschiedene Controller anwenden. Für komplexere Projekte ist C durchaus 
vorzuziehen.

Jetzt wird fertiger C code natürlich compiliert, also in Machinensprache 
überführt. Dabei verwendet der compiler aber standard Wege. Standard 
Wege sind nicht immer die schnellst möglichen. Hinzu kommt der Syntax 
unterschied zwischen C und Machinencode, der vom compiler verarbeitet 
werden muss. Das alles geht zu Lasten der Effizienz(Bequemlichkeit geht 
immer zu Lasten der Effizienz)...

Autor: Alex Tricktronic (tricktronic1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mr. G-Code wrote:
> ich habe so etwas mit 4 synchronen Achsen bei einem Takt von max.
> 20kHz/Achse auf einem C167/20MHz implementiert. Genauigkeit der
> Berechnungen 0,5µm! Alle Rechnungen werden im Long (4Byte) Integerformat
> ausgeführt. Winkelfunktionen sind in einer Lookup-Table hinterlegt!
> Alles in C, mit ein bischen ASM-Optimierung an zeitkritischen Stellen.
> Wo liegt das Problem?

O.K. vielleicht sollte ich meine Berechnungen kontrollieren und 
nachsehen ob ich wirklich auf 32Bit int umsteigen kann - wird sich mit 
gewissem Aufwand auch machen lassen.

> Ich weis nicht was Du für Schrittmotoren hast, die 100kHz unter Last
> folgen können? Oder bist Du in der Nanotechnik zuhause?

Nein, aber wenn ich 1 Schritt auf 1/100 mm habe und v=s/t dann ist vMax 
bei 10 us 1000mm/s und diese Geschwindigkeit brauche ich schon. Was hat 
das mit Nanotechnologie zu tun?

Danke dass sich endlich wieder jemand dem beabsichtigten Thema widmet...
Ewig dieses geplänkel was die ultimative Programmiersprache ist...
Natürlich Perl, oder ;-)

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
NaYthan wrote:
> Jetzt wird fertiger C code natürlich compiliert, also in Machinensprache
> überführt. Dabei verwendet der compiler aber standard Wege. Standard
> Wege sind nicht immer die schnellst möglichen.

Das klingt ein wenig nach Binsenweisheit. Auch der 
Assembler-Programmierer verwendet Standardwege um eine Iteration oder 
ein select-case-Konstrukt in Assembler abzubilden. Um diesen Standardweg 
zu verbessern wird optimiert. Der Assembler-Programmierer kann das sehr 
gut, aber er braucht dafür sehr viel Zeit und opfert Lesbarkeit des 
Codes, deshalb wird er es nur in wenigen Fällen tun. Der C-Compiler kann 
das (noch!) nicht ganz so gut, dafür kostet es ihn praktisch nichts.

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!
>Nein, aber wenn ich 1 Schritt auf 1/100 mm habe und v=s/t dann ist vMax
>bei 10 us 1000mm/s und diese Geschwindigkeit brauche ich schon.
Nun deine Überlegung mag stimmen, nur mit den 60m/min und deiner 
Auflösung komme ich auch noch nicht ganz klar. Ich kenne auch keine 
Schrittmotoren die diese Geschwindigkeit mitmachen oder deine Def. von 1 
Schritt ist eine andere als wir denken.Ich kenne Dynamikantriebe aus der 
Industrie, aber das sind Synchronmotoren die über das Drehfeld gesteuert 
werden. Da könnte ich mir sogar vorstellen das die PWM für jede Phase 
mit 100kHz neu berechnet wird, aber Schrittmotoren???... ne ne die 
reagieren nicht auf 100kHz, die lachen dich aus. Kannst du das mal mit 
den Schrittmotoren etwas genauer erklären.

Viel Erfolg, Uwe

Autor: Alex Tricktronic (tricktronic1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Mr. G-Code (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Alex Tricktronic
Da verwechselst Du Äpfel mit Birnen. An der Steuerung kann die 
Schrittzahl von 200 ... 10000 pro Umdrehung einstellen. Und die 
Steuerungseingänge können bis max. 200 kHz betrieben werden.
Beim Schrittmotor handelt es sich um einen 3-Phasen Schrittmotor, besser 
3 Phasen Synchronmotor, also eigentlich um keinen Schrittmotor. Die 
Ansteuerung  produziert modifizierte Sinuskurven (je nach Schrittzahl) 
und erlaubt so die Ansteuerung ähnlich eines Schrittmotors.

Mich würde mal interessieren, ob die Steuerung + Motor diese 
rechnerischen Genauigkeiten wirklich ereichen, oder nur bei Motoren mit 
Untersetzungen?

Kurz gesagt:
Motor 3-Phasen Synchronmotor.
Ansteuerung Schrittmotor like.

Dies macht die ganze Sache noch leichter. Wo liegt das Problem ;-)

>Was hat das mit Nanotechnologie zu tun?
Schon mal was von Massenträgheitsmoment gehört?
Was glaubst Du, warum ein Modellbau Verbrennungsmotor Drehzahlen von 
18000 1/min mühelos erreicht, und Dein Auto gerade mal ca. 6000 1/min.

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Der unbelastete Motor startet und stoppt mit der Start-Stopp-Frequenz.
Wenn externe Trägheitsmomente auf den Motor wirken, müssen Sie für
die Start-Stopp-Phase eine niedrigere Frequenz wählen."

MfG
Falk

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!
Deine Motoren sind also im gehobenen Speilzeugbereich angesiedelt.
Habe gerade mal die Datenblätter studiert und ich glaube das solltest du 
auch mal machen. Deine Eingänge vertragen zwar 200 kHz aber selbst der 
kleinste Motor hat bei 50kHz fast kein Drehmoment mehr. Beim grössten 
ist bei 10kHz Feierabend. Das wäre dann schonmal wenigstens Faktor 5-12 
wenn du noch etwas Drehmoment haben willst. Des weiteren würde ich sagen 
du solltest für jede Achse einen eigenen Controller einsetzen der kurze 
(1/10mm)Achsbewegungen selbstständig verarbeitet. Willst du eigentlich 
mit 60m/min irgendwas bearbeiten oder nur Positionieren. Wenn nur 
Positionieren gefragt ist, werden im Industriebereich 3 Bereich 
realisiert: Anfahren, Eilgang, Bremsen. Beim Eilgang wir dann nicht mehr 
auf 1/100 geschaut. Vorschub, also Bearbeitung, kenne ich aber auch blos 
bis 10m/min was natürlich Rechenzeit schafft. Du solltest dein ganzes 
Projekt also nochmal gut überdenken und realistische Grenzen festlegen.
Solltest du tatsächlich solche hohen und präziesen Anforderungen haben 
wirst du um ein Multiprozessorsystem nicht rumkommen.

Viel Erfolg, Uwe

Autor: Alex Tricktronic (tricktronic1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Uwe,

ich steuere schon solche Motoren mit 100kHz in einem 2-Achs-System an - 
mit gleichmäßiger Beschleunigung auf Maximalgeschwindigkeit.
Wenn ich aber keine geraden sondern Kurven fahren will ist die 
Beschleunigung nicht mehr konstant und die Berechnungen dauern viel 
länger.
Ich bewege kein bearbeitendes Werkzeug sondern spezielle 
Laserentfernungsmessgeräte die Objekt vermessen sollen.
Ich brauche also - vereinfacht gesagt - eine rückfreie Bewegung bei der 
ich zu jedem Lasermesswert die aktuelle 5-Achsen-Position habe. Und das 
im besten Fall mit einer Auflösung von 1/100 mm damit ich keine unnötige 
Messwertabweichung erhalte.

Die Motoren bzw. deren Interface kann ich mit 100kHz ansteuern, die 
Entfernungswerte nach z.B. 15 Schritten (=0.15mm) stimmen lt. 
Laderdistanzmessung dann auch! - Also das funktioniert bestimmt.
Die Maximalgeschwindigkeit brauche ich nur zum Positionieren, aber die 
Messgeschwindigkeit ist nicht allzu weit von dieser Geschwindigkeit 
entfernt.

Meine Überlegungen haben mich auch schon zum Multiprozessorsystem 
geführt.
Oder eben zu einem FPGA oder DSP, wobei ein FPGA sicherlich mehr arbeit 
abnehmen könnte als nur die Achsansteuerung.

MFG
Alex

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!
Aja, jetzt lichtet sich der Nebel langsam. Du brauchst also fast kein 
Drehmoment. Du willst also recht genau messen hmmm... würde ich mit 
Multiprozessor machen weil du ja auch noch messen willst. Die 
Achsprozessoren bekommen ihre kleinen Wegwerte und mit dem Fahrtakt wird 
gleichzeitig ein Timer von Extern getaktet. Dein Lasersignal kommt an 
den entsprechenden IC-Pin und bei Signal hast du den genauen Wert der 
Impulse im ICP-Register. Dann noch eine schnelle Unterhaltung zwischen 
Proz. und du hast eine recht genaue und schnelle Regelung + Messung.
Ist aber jetzt glatt aus dem Ärmel geschüttelt und bedarf noch etlicher 
Überlegungen, aber ein Mega macht bis zu 20MHz, da wird einiges fertig.

Viel Erfolg, Uwe


Autor: Alex Tricktronic (tricktronic1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
da der mega nur 8 bit hat und auch keine fpu wirds mit denen wohl kaum 
funktionieren.
Auf die Wurzelberechnung kann ich nicht verzichten (zumindest wüsste ich 
nicht wie) und die dauert in einem AVR ewig (0.1-300ms, je nach Wert).
Aber ich bin mir sicher dass ich die geeigneten Controller bzw. Hardware 
finde!

Danke,
Alex

Autor: Mr. G-Code (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Auf die Wurzelberechnung kann ich nicht verzichten (zumindest wüsste ich
>nicht wie) und die dauert in einem AVR ewig (0.1-300ms, je nach Wert).

Versuchs mal damit:

//***************************************************************************
//ADG:! Integer Wurzelfunktion: Routine to do a fast square root of a 16 bit integer
unsigned int uiMyMath_SquareRoot(unsigned long Square)
{
  unsigned char i;
  unsigned long int  root       = 0;            /* 16 bit answer */
  unsigned long int  square1    = 0;            /* 32 bit storage */
  unsigned long int  try        = 0;            /* 32 bit storage */

  for (i=1; i <= 16; i++)                       /* 16 = #bits /  2  */
  {
    square1 = (square1 << 2) + (Square >> 30);  /* 30 = #bits - 2 */
    Square  = (Square << 2);
    root    = (root << 1);
    try     = (root << 1);

    try++;
    if (try <= square1)
    {
      square1 -= try;
      root++;
    }
  }
  return((unsigned int) root);
}


Autor: another Assembler Freak (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das einzig Wahre und die hohe Schule es Programmierens IST UND BLEIBT 
einzig Assembler. Es gibt keinen Grund, darauf zu verzichten, wenn es um 
kompakte & schnelle Programme geht. Der ganze Hochsprachenmüll hat 
letztlich dazu geführt, daß ein beispielsweise Windows Vista heute GB in 
RAM und auf HDD benötigt. Aber es ist ja so schön bequem...

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na wenn du das sagst...

Autor: another Assembler Freak (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das sag nicht nur ich, Andreas. Wollte mich nur dem Dirk Hofmann in 
diesem Thread anschließen. Nun ja, möge jeder mit dem Werkzeug glücklich 
werden, das er beherrscht. Allerdings sollte man sich auch mal bewußt 
darüber werden, welche Unmengen an Ressourcen wie Speicherplatz und 
Prozessorleistung durch ineffiziente Hochsprachenprogrammierung auf 
diesem Planeten verschleudert werden! Da ließen sich viel Geld und auch 
so einige Kraftwerke einsparen- um mal den Bogen zur aktuellen 
Klimadebatte zu schlagen.

Autor: Dirk Hofmann (arm-dran)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich kann meinem Vorredner da nur noch was zufügen,

Ist ist heutzutage schon normal geworden, bessser gesagt, man nimmt es 
in Kauf wenn Programme regelmäßig zum Absturz führen.

Wenn mir jemand erklären kann, warum Maustreiber aus MEGABYTE (nicht 
KILOBYTE) bestehen, so möge er sprechen oder schweigen.

Na klar, kann man auch in Assembler Fehler machen. Dewegen hatte ich 
auch geschrieben nicht auf vielen Hochzeiten tanzen, sondern das was man 
macht gut machen.
Da wird doch niemand dagegensprechen.

Natürlich muß man folgendes mit einbeziehen.

Es wird nie im Interesse der Halbleiterindustrie oder Softwarehersteller 
sein, daß zu unterstützen.
Stellt euch vor, viele Programmierer würden effizient mit dieser Sprache 
arbeiten, Microsoft Intel blabla wären tot, weil wir immmer noch beim 
Pentium I wären.

Soviel mal dazu

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@another Assembler Freak

>werden, das er beherrscht. Allerdings sollte man sich auch mal bewußt
>darüber werden, welche Unmengen an Ressourcen wie Speicherplatz und
>Prozessorleistung durch ineffiziente Hochsprachenprogrammierung auf

Ineffiziente Programmierung? JA. Viele programmierende sind keine guten 
Programmierer.

Aber Hochsprachen an sich müssen nicht ineffizient sein, und gerade die 
C-Complier für uCs sind da VERDAMMT nah am Assembler (in Geschwindigkeit 
und Speicherplatzverbrauch)

MfG
Falk

Autor: another Assembler Freak (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Falk: Die "ineffizienten" Programmierer sind sicher ein anderes Thema. 
Ineffizient programmieren kann man jedenfalls auch in Assembler :-) Was 
aber die Programmiersprache an sich betrifft, ist "verdammt nah" sicher 
relativ. Das mag im Einzelfall und vor allem bei den ganz kleinen Mikros 
durchaus einmal zutreffen. Wird Programm & Prozessor größer, relativiert 
sich das ganz ganz schnell.

Gib ruhig zu, daß Du in Hochsprache aus purer Bequemlichkeit und 
Gewohnheit programmierst :-))

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk wrote:

> Aber Hochsprachen an sich müssen nicht ineffizient sein, und gerade die
> C-Complier für uCs sind da VERDAMMT nah am Assembler (in Geschwindigkeit
> und Speicherplatzverbrauch)

Zustimm !

Der für Ineffizienz eines Programms verantwortliche Teil sitzt zu 99% 
vor dem Bildschirm.


Ich hab früher mal 10 Jahre Assembler gemacht und kann die 
Assemblerverfechter verstehen.

Ich mache aber schon einige Jahre C und kann ihnen daher jetzt nicht 
mehr zustimmen.

Es sind nur extrem wenige Fälle, wo sich einige Zyklen Zeiteinsparung 
auch signifikant auf die gesamte Programmausführungszeit auswirken.


Peter


P.S.:
Ich hab mal den C51 Compiler gegen meine in vielen Wochen mühsam 
optimierte Divisionsroutine antreten lassen, um dann enttäuscht 
festzustellen, daß er mehr als doppelt so schnell war. Und bei der 
Multiplikation war er nur leicht besser.

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@another Assembler Freak

>durchaus einmal zutreffen. Wird Programm & Prozessor größer, relativiert
>sich das ganz ganz schnell.

Das sagte ich doch, oder?

>Gib ruhig zu, daß Du in Hochsprache aus purer Bequemlichkeit und
>Gewohnheit programmierst :-))

Der Herr irrt gewaltig! ;-)
Ich bin Hardwerker, und als solcher ein "niederes Wesen" was sich 
vonehmlich in Assembler und VHDL austobt. Ich hab keine Ahnung von Java, 
C++ und weissdergeierwasgeradetrendyist. Was aber nicht heisst, dass ich 
vollkommen ignorant, starrköpfig und lernresistent bin und meine kleine 
Betätigungswelt als das Universum ansehe.
Ich habe viele Jahre AVRs (im Hobbybereich und Studium) in Assembler 
programmiert. Vor eingen Wochen hab ich mir mal den WinAVR angeschaut 
und war sehr positiv überrascht!

MfG
Falk

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter Dannegger

>Es sind nur extrem wenige Fälle, wo sich einige Zyklen Zeiteinsparung
>auch signifikant auf die gesamte Programmausführungszeit auswirken.

Alte Programmiererregel.

90% der Rechenzeit werden in 10% des Programms verbraucht.

Diese 10% müssen optimiert werden, der Rest muss "nur" solide gemacht 
sein.

>Ich hab mal den C51 Compiler gegen meine in vielen Wochen mühsam
>optimierte Divisionsroutine antreten lassen, um dann enttäuscht
>festzustellen, daß er mehr als doppelt so schnell war. Und bei der

"Der für Ineffizienz eines Programms verantwortliche Teil sitzt zu 99%
vor dem Bildschirm."
;-)

MfG
Falk

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wenn mir jemand erklären kann, warum Maustreiber aus MEGABYTE
> (nicht KILOBYTE) bestehen, so möge er sprechen oder schweigen.

Wenn du denkst dass diese x Megabyte zu einem nennenswerten Teil aus 
Programmcode bestehen, dann irrst du dich ganz gewaltig.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
another Assembler Freak wrote:
> @Falk: Die "ineffizienten" Programmierer sind sicher ein anderes Thema.
> Ineffizient programmieren kann man jedenfalls auch in Assembler :-) Was
> aber die Programmiersprache an sich betrifft, ist "verdammt nah" sicher
> relativ. Das mag im Einzelfall und vor allem bei den ganz kleinen Mikros
> durchaus einmal zutreffen. Wird Programm & Prozessor größer, relativiert
> sich das ganz ganz schnell.

Genau umgekehrt. Je kleiner das Programm und je einfacher der Prozessor, 
desto mehr lässt sich mit Assembler rausholen; je größer das Programm 
und je komplexer der Prozessor, desto weniger macht es Sinn sich mit 
Assembler zu beschäftigen, weil der Programmierer bei Dingen wie 
Instruction Scheduling einfach nicht mehr mit vertretbarem Zeitaufwand 
mit einem Compiler mithalten kann.

> Gib ruhig zu, daß Du in Hochsprache aus purer Bequemlichkeit und
> Gewohnheit programmierst :-))

Was du Bequemlichkeit nennst nennen andere Entwicklungskosten.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk wrote:

> 90% der Rechenzeit werden in 10% des Programms verbraucht.
>
> Diese 10% müssen optimiert werden, der Rest muss "nur" solide gemacht
> sein.


Wenn es denn bloß so einfach wäre.

Leider bestehen MC-Programme oftmals zu 90% aus Delayschleifen und diese 
90% verbrauchen dann 99% der CPU-Zeit.

Und Delayschleifen sind definitv nicht optimierbar.

Man muß sie konsequent rauswerfen, was ein Wegschmeißen dieses 
Programmierstils und aller damit erstellten Anwendungen bedeutet.


Ich bin mir sicher, ich könnte viele Projekte aus meiner 
Assembler-Anfangszeit mit einem 10* kleineren Quarztakt unter C 
realisieren, die Erfahrung machts.
Man weiß einfach besser, wie lange was dauert und kann besser 
abschätzen, wie oft muß ich eigentlich was machen.


Peter

Autor: Wolfram (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Auf die Wurzelberechnung kann ich nicht verzichten (zumindest wüsste ich
>nicht wie)
@Alex Tricktronic:
Versuchst du wirklich von Punkt zu Punkt während der Bewegung deine 
Kurve zu berechnen?
Dann kann ich mir gut vorstellen das dein Mikrocontroller das nicht 
schafft.
Ich denke auch sehr "potente" Mikrocontroller werden da ins Schwitzen 
kommen.
Hast du eigentlich schon mal eine Fehlerbetrachtung gemacht wo du dich 
im Bezug auf die Maschinengenauigkeit befindest?
Warum zerlegst du deine Kurve nicht in eine Aneinanderreihung von 
Geraden, wie fein die Untergliederung sein muss, kannst du ja dynamisch 
festlegen. (Je nach Kurvenradius). Dann sinkt die benötigte 
Rechenleistung beträchtlich, da jeweils nur die Verbindungspunkte der 
Geraden berechnet werden müssen, dazwischen wird ein 
Bresenhamalgorithmus gemacht. Das dürfte dein derzeitiger 
Mikrocontroller locker schaffen.

Autor: Alex Tricktronic (tricktronic1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Versuchst du wirklich von Punkt zu Punkt während der Bewegung deine
> Kurve zu berechnen?
> Dann kann ich mir gut vorstellen das dein Mikrocontroller das nicht
> schafft.
> Ich denke auch sehr "potente" Mikrocontroller werden da ins Schwitzen
> kommen.
> Hast du eigentlich schon mal eine Fehlerbetrachtung gemacht wo du dich
> im Bezug auf die Maschinengenauigkeit befindest?
> Warum zerlegst du deine Kurve nicht in eine Aneinanderreihung von
> Geraden, wie fein die Untergliederung sein muss, kannst du ja dynamisch
> festlegen. (Je nach Kurvenradius).
Das haben wir hier schon genug durchgekaut - ich brauche diese 
rechnerische Genauigkeit wegen Messabweichung.

> dazwischen wird ein
> Bresenhamalgorithmus gemacht.

Der Breseham-Algorithmus bei Ellipsen kann beim Schrittmotorfahren nicht 
gemacht werden, da er die einzelnen Quadranten in Sektoren aufteilt die 
von verschiedenen Richtungen gezeichnet werden. Der Schrittmotor fährt 
logischerweise eine Linie durch.
Dieser Algorithmus lebt aber davon den Error zu kummulieren, den kann 
man leider nicht in einer Richtung betreiben - eben so, wie ein Motor 
fährt.

Autor: Wolfram (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Das haben wir hier schon genug durchgekaut - ich brauche diese
>rechnerische Genauigkeit wegen Messabweichung
das haben "wir" noch überhaupt nicht "durchgekaut", weil du keine 
Angaben zur geforderten Genauigkeit gemacht hast. Du sprichst von 
"besten Fall 10um"
getestet hast du mit 0.15mm und da stimmt die Genauigkeit.
Lege dich doch mal auf eine hinreichende Genauigkeit fest! Betrachte 
dabei die mechanischen Ungenauigkeiten, die durch deine Wellen mit 
reinspielen. Ich kenne Linearaktuatoren die haben 10um pro Vollschritt 
und die Welle ist mit 20-30um möglichen Fehler angegeben.
Wenn du die Kurve in Geraden zerlegst, das solltest du das unter dem 
Aspekt machen, daß deine noch festzulegende Genauigkeit erreicht wird, 
das war mit dynamische Zerlegung gemeint. Im 2-ten Schritt wird für 
jeden Verbindungspunkt der Geraden die Geschwindigkeit der einzelnen 
Achsen berechnet. Die Geraden werden an eine drunter liegende Schicht 
gegeben, die für jede Achse entscheidet ob sie die angegeben 
Geschwindigkeit in Voll/Halb oder xtel Schritt löst. Kriterium ist dabei 
die Schrittzeit, denn du hast ja nur beschränkt Rechenkapazität.
Ich denke ich erzähle dir nichts neues, wenn ich dich darauf hinweise 
das bei xtel Schritt beim Anfahren nicht unbedingt ein Schritt 
garantiert ist, wenn das Drehmoment nicht ausreicht. Wenn man erstmal 
fährt kann man auch die Schrittfrequenz über die Start/Stopfrequenz 
steigern. Für hohe Geschwindigkeiten mußt du sowieso in den 
Vollschrittmodus gehen.
Das funktioniert sehr gut für den beschriebenen Weg mit moderatem 
Rechenaufwand. Das einzige was festzulegen ist, ist die hinreichende 
Genauigkeit.


Autor: Alex Tricktronic (tricktronic1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mein Text:
Entfernungswerte nach z.B. 15 Schritten (=0.15mm) stimmen lt.
Laderdistanzmessung dann auch!

z.B. heißt dann aber nicht dass ich NUR 0.15 getestet habe - lesen und 
denken.

Meine Frage war aber auch nicht wie ich das berechnen kann und ob das 
eurer Meinung nach überhaupt Sinn macht sondern welchen Microcontroller 
ich verwenden könnte - vielleicht gibts ja welche an die ich noch gar 
nicht gedacht habe.

Die hinreichende Genauigkeit ist in meinem Fall - oh welch Überraschung 
10um.
Außerdem reicht das Drehmoment aus. Und den algorithmus hab ich auch 
schon geschrieben - getestet & funktioniert einwandfrei.
Sicher könnte ich die Auflösung der Achsen runterstellen aber das war 
nicht meine Frage!

Autor: Wolfram (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok. Beantwortung deiner Frage:
Auch wenn du deinen Algorithmus nicht vorgestellt hast, ich schätze als 
Mikrocontroller ist sowas von der Klasse Pentium 4 ab 1,8 GHz nötig.
Vielleicht wirst du auch bei Renesas fündig, die haben da gerade was 
neues.
Optimierungen hast du schon im jetzigen System probiert, die haben aber 
nicht zu der notwendigen Leistungssteigerung geführt. Du könntest ja mal 
angeben (in Bewegungsgeschwindigkeit) wo du dich derzeit befindest.
Das dein Algorithmus funktioniert, bezweifle ich nicht, ich denke nur du 
verbrennst für die Aufgabe (die du nicht sehr genau spezifizierst) mehr 
Rechenleistung als nötig ist. Das du eine Abneigung dagegen hast, jetzt 
den Algorithmus zu wechseln, kann ich nachvollziehen, es wird aber 
höhere Hardwarekosten nötig machen. Ob die gerechtfertigt sind mußt du 
entscheiden.
Da ich auch schon einen Meßtisch mit 10 um Vollschrittraster gemacht 
habe stellt sich für mich die Frage warum du von Punkt zu Punkt 
arbeitest und dabei rechnest. Ich habe Probleme mir vorzustellen, daß 
das sehr schnell geht und daß sich beim resultierenden Algorithmus die 
mechanischen Probleme von Wellen und Schrittmotoren lösen lassen. Bis 
200 um kann man sowas machen ohne sich mit den mechanischen 
Gegebenheiten auseinandersetzen zu müssen. Bei 10 um geht das nicht, 
zumindest nicht bei der Dynamik die du vorgibst. Hauptproblem dürfte die 
ruckfreie Bewegung sein, da ein Ruck zu Schwingungen führt.
Das läßt sich mit dem vorgeschlagenen Algorithmus wesentlich 
übersichtlicher kontrollieren.
Die andere Frage die sich mir stellst ist, ob du bei float überhaupt 
eine hinreichende Genauigkeit erreichst. Da sagtest das du mit 64bit Int 
Probleme hattest. Bei float sind nur 23bit mantisse.

Autor: Alex Tricktronic (tricktronic1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wolfram wrote:
> Ok. Beantwortung deiner Frage:
> Auch wenn du deinen Algorithmus nicht vorgestellt hast, ich schätze als
> Mikrocontroller ist sowas von der Klasse Pentium 4 ab 1,8 GHz nötig.
Deshalb habe ich mir auch gedacht dass ich eine Zentral-CPU und für jede 
Achse eine eigene HW verwenden könnt.

> Vielleicht wirst du auch bei Renesas fündig, die haben da gerade was
> neues.
kannte ich bis jetzt noch nicht . guter Tip!

> Das dein Algorithmus funktioniert, bezweifle ich nicht, ich denke nur du
> verbrennst für die Aufgabe (die du nicht sehr genau spezifizierst) mehr
> Rechenleistung als nötig ist. Das du eine Abneigung dagegen hast, jetzt
> den Algorithmus zu wechseln, kann ich nachvollziehen, es wird aber
> höhere Hardwarekosten nötig machen. Ob die gerechtfertigt sind mußt du
> entscheiden.
Höhere Hardwarekosten sind nicht ganz so das Problem - ein Motor kostet 
sowiso mehr wie die gesamte Elektronik (Materialpreis)

> Die andere Frage die sich mir stellst ist, ob du bei float überhaupt
> eine hinreichende Genauigkeit erreichst. Da sagtest das du mit 64bit Int
> Probleme hattest. Bei float sind nur 23bit mantisse.
Ich habe nicht geschrieben dass ich mit int64 Probleme hätte - aber 
23bit mantisse reicht mir bei der range von float. Wenn der Controller 
eine FPU hat dann spielt es zeitlich keine Rolle ob man 64Bit oder float 
rechnet.

DANKE

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.