Hallo alle zusammen, ich habe vor 2 Jahr mein Minimalziel bei meinem Tricopter Project geschafft. Hier hat sich leider herausgestellt das die Power meines Controllers geradeso dazu gereicht hat Controller --> Atmel ATmega328 Nach zwei Jahren Pause möchte ich jetzt mein Copter komplett verbessern und suche deshalb einen neuen leistungsfähigen Controller. Meine Suche ist aber voll in die Hose gegangen und finde nur normal schnelle Controller. Daher meine Frage wie schnell sind so die schnellsten Controller? Welche kann man empfehlen ? Anforderungen sind eigentlich Simpel. I2C Min 2 Serielle Schnittstellen 10 Bit ADC's gerne auch höher C oder Bascom Kompatibel
Die schnellsten? Vermutlich sowas wie die Cortex-A50 wie sie in Top-Smartphones verwendet werden. Falls das noch als Controller zählt...
Ratzfatz78 schrieb: > es soll schon ein Mikrocontroller sein und kein Prozessor ;) Kannst du das spezifizieren? Wo ist das Problem beim Cortex-A50? Zu groß? Zu teuer? Zu viel stromverbrauch? Zu kompliziert? Ohne weitere Angaben kann dir kein Mensch helfen.
was heißt schnell? Und vor allem, was muss der berechnen? Bei Fließkomma hast du mit nem avr schlechte Karten, da brauchst du was mit FPU. Und dass du gesucht hast wird dir wohl keiner abnehmen, einfach mal auf Atmels Website gucken hätte gereicht.. Ich würde das Problem einfach mit nem Cortex M4 mit FPU erschlagen, z.b. Stm32f4 Reihe oder Atmels SAM4, ich bevorzuge die Stellaris/Tiva Controller von TI
Hallo Das ist etwas unpräzise ;) Wie schnell soll es denn sein? Welches Package kannst du noch löten? Welche Abmessungen? Wie viel IOs? Wie viel RAM/Flash? etc. ARM Cortex-M4 basierte gibt es z.B. bis ~200MHz Beispiel: http://de.farnell.com/nxp/lpc4313jbd144e/mcu-32bit-cortex-m4-204mhz-144lqfp/dp/2320709 da1l6
Vielleicht muss es ja auch gar nicht der allerschnellste "Mikrocontroller" der Welt sein. Wenn 100x so viel Rechenleistung wie vom AVR reicht, dann reicht vielleicht auch ein "kleiner" Cortex-M4 wie die LPC oder STM32 oder Atmel SAM4.
XMOS. 32-Bit Core mit bis zu 8 taktweise verschränkt laufenden Threads à 100 MIPS, zusammen bis 400/500 MIPS. Davon 1-2 Cores pro Chip. Mehrere Chips sind über Highspeed-Links verschaltbar. Zentrales Boot-Image fürs gesamte System in einem SPI-Dataflash. XMOS verwendet etwas andere Begriffe dafür als ich. http://www.xmos.com/
:
Bearbeitet durch User
> XMOS. 32-Bit Core Von solchen exotischen Prozessoren/Architekturen sollte man eher Abstand nehmen, weil den viel zu wenig Leute einsetzen. Bei gängigen Prozessoren wie ARM und PIC32 hat man dagegen gute Chancen Programmcode von anderen Entwicklern zu übernehmen.
:
Bearbeitet durch User
Ratzfatz78 schrieb: > Hier hat sich leider herausgestellt das die Power meines Controllers > geradeso dazu gereicht hat > Controller --> Atmel ATmega328 Es gibt aber ein paar OSS Projekte die genau das schaffen.. (Multiwii, Ardupilot usw.)
Helmut S. schrieb: >> XMOS. 32-Bit Core > Von solchen exotischen Prozessoren/Architekturen sollte man Abstand > nehmen, weil den viel zu wenig Leute einsetzen. Ja, wenn man langfristig Produkte gewerblich entwickelt, die man locker auch mit anderen Controllern zurecht bekommt. Bei einem persönlichen Projekt kann das anders aussehen. Ich habe das gebracht, weil der "schnellste µC" gefragt war und es schwer fallen wird, ohne CPLD/FPGA eine Controller-Lösung zu finden, die hinsichtlich Tempo (ohne FP-Rechnung) und insbesondere Reaktionsfähigkeit mit XMOS mithalten kann. Das ist nicht für jedes Problem brauchbar und als Upgtade für Mega328 sicherlich etwas extrem. Übrigens habe die mittlerweile einen Hybrid aus einem Cortex-M3 mit 1MB Flash sowie einem von deren Cores im Anmarsch.
:
Bearbeitet durch User
habe auch schonmal einen Quadro mit Atmega realisiert. Geht, ist aber nicht so toll (Divisionen = bäh). Meinen zweiten habe ich mit einem cortexM3 (stm32F103) realisiert. Fazit: Der ist so schnell, dass ich sogar während dem Fliegen noch Musik abspielen kann und ein FreeRtos Betriebssystem läuft auch noch drauf. Ich würde mir aber gleich einen CortexM4 nehmen, dann kann man auch so Sachen wie Autopilot locker drauf realisieren. Gruß
Infineon tricore Freescale Qorivva Reichen wird dir der schon: http://www.embeddedartists.com/products/lpcxpresso/lpc1769_xpr.php
Nimm einen Arduino Due. Den kannst auch in der Arduino Spache programmieren. kosten für aufgebaute Platine < 50 Euro Arm 3 Prozessor mit 84 MHz
Walter von der schrieb: > kosten für aufgebaute Platine < 50 Euro > Arm 3 Prozessor mit 84 MHz STM32F4-Discovery: kostet ca. 15€ Cortex M4 mit 168 MHz Debugger ist auch mit auf der Platine. Da kann man dann auch richtig debuggen, ganz ohne printf oder SerialWrite. Und es sind alle Pins rausgeführt, was bei dem Arduino bei weitem fehlt. Und wenn man den Due ohne den Arduino scheiß programmieren will (weil der Arduino dreck der Innbegriff von unperformant ist!), dann steht man schnell nackt im Wald, weil es für den SAM3X kaum Code-Beispiele gibt. Für die STM32 hingegen wird man mit Code-Beispielen praktisch zu tode geworfen. Der Arduino verliert in allen Punkten und ist die schlechteste Wahl.
Hallo erstmal vielen dank für die vielen Antworten, sorry das es anscheinend zu Irritationen gab. Ich suche natürlich nicht den allerschnellsten Controller. Suche halt einen Schnellen Controller umdie 80 Mhz oder schneller. Und wenn das Teil 50 Euro kostet ist das halt so. Was ich jetzt mitbekommen habe ist der Cortex-M3 / Cortex-M4 die Wahl. So auf den ersten Schuss sieht das Board sehr gut aus http://www.alpha-crucis.com/de/microcontroleurs/654-arm-mbed-nxp-lpc1768-development-board-3700386721502.html @Ast Sorry was andere machen interessiert mich nicht ich gehe eine andere Richtung bei dem Thema. Hat damit aber auch zu tun das ich Bascom verwendet habe und das 5 mal langsamer ist als C und wenn man dann aufeinmal alles auf I2C umgestellt hat machts das nicht besser. Wenn ich aber den M3 / M4 hole bleibt mir nix anderes übrig C zu schreiben :)
Ratzfatz78 schrieb: > So auf den ersten Schuss sieht das Board sehr gut aus > http://www.alpha-crucis.com/de/microcontroleurs/654-arm-mbed-nxp-lpc1768-development-board-3700386721502.html Nö :-) Das STM32F4 Discovery sieht doch viel besser aus. Schneller, umfangreicher, günstiger, verbreiteter. http://www.mikrocontroller.net/articles/STM32 http://www.mikrocontroller.net/articles/STM32F4-Discovery
@ Frank M hatte inzwischen das Board gefunden ( ist fast das selbe ) --> http://www.adafruit.com/products/834 Aber Ethernet ist erforderlich und Online browser geht ja mal garnet Aber dein Einwand ist natürlich richtig. Schneller und Billiger klingt sehr gut aber ich glaube das Board ist etwas groß für mein Copter :( Das prüfe ich aber nochmal Was hälst du von dem Teil? http://www.mikroe.com/mini/stm32/
aaalso ... der Geschwindigkeitsvorteil von C gegen Bascom kommt auf Deinen Programmierstil an und was I²C damit zu tun haben soll erschließt sich mir nicht direkt. Man kann Bascom Highevelbefehle verwenden, dann geht mitunter die Rechenleistung etwas runter, man muss aber nicht. Du hast in Bascom wie in C auch direkten Zugriff auf die Register des µC, das schenkt sich nichts. Ich vermute, Du hast die Bascom I²C-Routinen verwendet ohne die I2C-Lib, also nicht die Hardware-I²C sondern die Soft-I²C, die ist in der Tat langsamer ... Du kannst aber auch die Interruptgesteuerte Hard-I2C nehmen, dann wird das wieselflink. Auch bei Rechenoperationen ist das so eine Sache. x=y/10 ist langsamer als x=y*0.1 aber im Ergebnis gleich. Manche Dinge lassen sich sehr gut in ne Datentabelle vorberechnen, dann geht der Abruf des Wertes oftmals schneller als die ständig neu zu errechnen. Mit tausche mäßigen Programmierstil gegen Megaherz wirst Du auch mit nem i7 onboard scheitern.
@ Fhutdhb Ufzjjuz Ich wusste das ich mit dem Satz von Bascom zu C in ein Hornissennest steche. Ich hab aber damit nicht dich angegriffen, es ist halt meine persönliche Entscheidung!!!!!!!!!! Schon alleine das ich nur x =y/10 und dann W = x * z schreiben darf und nicht x=y/10*z NERVT!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1 Und ich lasse mir nur ungern von einem Programm vorschreiben wie ich Programmieren muss nur das es irgendwie schneller funktioniert wenn es schon anders geht PUNKT. Und bitte woher willst du wissen wie Programmiere? Es reicht ja das ich ein Tricopter zum fliegen bekomme?? Und der letzte Satz ist mal lächerlich und am rande der Beleidigung. Ich habe hier anständig gefragt und kann wohl normale Anständige Antworten b.z.w. Tipps erwarten. @Harry Den hab ich auch schon gesehen aber wenn ich für etwas mehr Geld den STM32F4 Discovery bekomme der einfach mehr bietet ist der Controller schon draußen.
Ratzfatz78 schrieb: > @ Fhutdhb Ufzjjuz > > Ich wusste das ich mit dem Satz von Bascom zu C in ein Hornissennest > steche. > Ich hab aber damit nicht dich angegriffen, es ist halt meine persönliche > Entscheidung!!!!!!!!!! > > Schon alleine das ich nur x =y/10 und dann W = x * z schreiben darf und > nicht x=y/10*z NERVT!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1 > > Und ich lasse mir nur ungern von einem Programm vorschreiben wie ich > Programmieren muss nur das es irgendwie schneller funktioniert wenn es > schon anders geht PUNKT. > > Und bitte woher willst du wissen wie Programmiere? Es reicht ja das ich > ein Tricopter zum fliegen bekomme?? Und der letzte Satz ist mal > lächerlich und am rande der Beleidigung. > > Ich habe hier anständig gefragt und kann wohl normale Anständige > Antworten b.z.w. Tipps erwarten. Jetzt machst du dich lächerlich. Ich fasse Fhutdhb Ufzjjuz's Beitrag absolut nicht angreifend auf und er hat absolut nichts mit Bascom vs. C geschrieben. Er hat sachlich mögliche Probleme die bei allen uC und allen Programmiersprachen auftauchen können aufgezeigt. Er hat aufgezeigt, dass eine Aussage wie 'Hat damit aber auch zu tun das ich Bascom verwendet habe und das 5 mal langsamer ist als C' falsch ist. Und auch mir ist es ein Rätsel was diese Aussage soll: 'alles auf I2C umgestellt hat machts das nicht besser'. Was hat I2C damit zu tun? Das läuft im Hintergrund, ist in der Hardware integriert. Warum soll das einen negativen Einfluss auf die Geschwindigkeit haben? Es kommt sehr wohl auf den Programmierstil mit an. Wenn du blockierend programmierst dann bringt dir auch der schnellste uC mit dem besten Compiler nichts. Die Rechenoperation von Fhutdhb Ufzjjuz sollte von einem guten Compiler in der Optimierung zur selben Geschwindigkeit führen. Niemand muss sich verrenken. Falls du natürlich absichtlich und unnötigerweise mit Dezimalzahlen rechnest oder andere Dinge machst die das Programm ausbremsen, so machst du dir das Leben selber schwer. Wir wissen es nicht, und Fhutdhb Ufzjjuz auch nicht. Er hat auch nur darauf hingewiesen, dass man diese Fallstricke nicht übersehen und unterschätzen darf und nicht erhoffen kann, dass ein Wechsel auf C plötzlich das Programm rasend schnell macht. Niemand kann ahnen, dass du sachliche Feststellungen falsch verstehst und als persönlichen Angriff wertest. Wie dem auch sei, das Modul das du raus gesucht hast sieht auch gut aus. Da aber auch noch die ganzen Sensoren fehlen, was spricht dagegen, dass du die Leiterplatte einfach selber machst? Dann hast du die Kontrolle über die Spannungsversorgung und du kannst es viel kompakter bauen.
Ratzfatz78 schrieb: > Aber Ethernet ist erforderlich und Online browser geht ja mal garnet Dann nimm das hier: - LPC4000 ist der Nachfolger vom LPC1700 (pin und SW kompatibel) - M4 und FPU - Ethernet ist bestückt - Xbee Sockel (für Fernsteuerung) Denn MBED Online-Compiler muss Du nicht nutzen. Du kannst entweder den MBED-Bootloader drauf lassen, dann meldet sich das Board als USB-Stick, und Du kannst ein Binary von jedem anderen Compiler (LPCXpresso, Keil, IAR) drauf ziehen. Oder Du flasht direkt mit FlashMagic über USB-seriell. Oder per JTAG mit LPC-Link2: http://www.conrad.de/ce/de/product/1027647/LPC4088-Quickstart-Board-Embedded-Artists-EA-QSB-016 http://www.flashmagictool.com/ http://www.conrad.de/ce/de/product/1027653/LPC-LINK-2-Embedded-Artists-EA-XPR-200?queryFromSuggest=true
@all Vielleicht war ich beim letzten Kommentar etwas gereizt :( Wollte mich dafür entschuldigen Der letzte Satz hat mich halt etwas aufgeregt @Frank M. Ich hab was Elektrik angeht "fast" null Ahnung hab nur Mechanik studiert. Ich hatte mir aus diesem Grund das Arduino nano geholt und das auf mein Board aufgesetzt.Das war einfach, ging schnell und hat für meine Bedürfnisse super gepasst und ich konnte mich mit dem beschäftigen was ich lernen wollte und zwar Microkontroller programmieren. Zum I2C Thema Auch im Programmieren bin ich nicht Perfekt. Mir ist nur aufgefallen das meine Schleife immer langsamer wurde mit jedem I2c Bauteil was ich da dran angeschlossen habe. Hatte dann komplett Probleme mit dem Mpu6050 da ist alles in den Keller gegangen. Zur Schnelligkeit 99% meiner Variablen sind INTEGER b.z.w. mit Long deklariert. Dezimalstellen habe ich fast komplett vermieden. Vielleicht hab ich ja ein Problem mit dem I2C gehabt und hab das auf den langsamen Controller geschoben. Ist ja auch jetzt egal, ich will in der zweiten Ausbaustufe nur mein Controller und GPS Module verbessern. @Lothar Danke schau ich mir mal an
Du musst nicht auf C umsteigen. Es gibt auch Pascal und Basic Compiler für den ARM: http://www.mikroe.com/mikroc/arm/ Schaue an welche µC die unterstützen. Kostet natürlich was.
Ob die Suche nach einem schnelleren Controller die Lösung ist... 1. Höhere Taktfrequenz bedeutet nicht automatisch, dass der Controller auch schneller arbeiten kann. 2. Ich betreibe hier einen Qudrocopter mit einem 16-Bit PIC der mit 16MHz läuft und könnte da noch Problemlos mehr reinpacken... Vielleicht solltest du dir auch noch einmal Gedanken machen, ob man eventuell deinen Code besseren schreiben könnte, anstelle von einem neuem Controller.
lutz schrieb: > Meinen zweiten habe ich mit einem cortexM3 (stm32F103) realisiert. > Fazit: Der ist so schnell, dass ich sogar während dem Fliegen noch Musik > abspielen kann und ein FreeRtos Betriebssystem läuft auch noch drauf. Na Klasse. Hättste 'n Intel I7 genommen, hättest du auch noch Windows und Linux gleichzeitig laufen lassen können, ein Video abspielen können und gleichzeitig auch noch ein Ballerspiel spielen können. Erkennst du wenigstens jetzt, wie schwachsinnig deine Wahl war? Das ist die Wahl von unfähigen Schwanzlängenvergleichern, nicht die von kompetenten Entwicklern! Und Leuten wie denen haben wir die Tatsache zu verdanken, daß heute trotz mehr als 10000facher Rechenleistung gegenüber 1990 die tägliche Arbeit am PC weder nennenswert schneller noch nennenswert komfortabler von der Hand geht als 1990...
c-hater schrieb: > lutz schrieb: > >> Meinen zweiten habe ich mit einem cortexM3 (stm32F103) realisiert. >> Fazit: Der ist so schnell, dass ich sogar während dem Fliegen noch Musik >> abspielen kann und ein FreeRtos Betriebssystem läuft auch noch drauf. > > Na Klasse. Hättste 'n Intel I7 genommen, hättest du auch noch Windows > und Linux gleichzeitig laufen lassen können, ein Video abspielen können > und gleichzeitig auch noch ein Ballerspiel spielen können. > > Erkennst du wenigstens jetzt, wie schwachsinnig deine Wahl war? > > Das ist die Wahl von unfähigen Schwanzlängenvergleichern, nicht die von > kompetenten Entwicklern! > > Und Leuten wie denen haben wir die Tatsache zu verdanken, daß heute > trotz mehr als 10000facher Rechenleistung gegenüber 1990 die tägliche > Arbeit am PC weder nennenswert schneller noch nennenswert komfortabler > von der Hand geht als 1990... ich hatte durch die Wahl des CortexM3 gegenüber dem Atmega nur Vorteile. - Ich musste mich nicht mehr um effiziente Programmierung kümmern und konnte alle Regelgleichungen 1:1 mit 32bit Float hinschreiben, ohne auf Bitshifts oder Tabellen zurückgreifen zu müssen. Der Atmega brauchte hunderte Rechenschritte nur um simple Divisionen durchzuführen. - Der Cortex war preiswerter als der Atmega64 den ich vorher nutzte (bei Reichelt) - Der Programmer war sehr günstig (7,90) und konnte debuggen - Das kleine Betriebssystem hat das Handeln verschiedener Prozesse enorm erleichtert (ok ist jetzt nicht Controllerspezifisch). - Dank der Leistung konnte ich eine Sprachausgabe mit implementieren (Der Copter meldet sich wenn Batteriestand kritisch ist oder die Rotoren gestartet werden etc...) Fazit: Es gibt keine Nachteile (jedenfalls konnte ich keine finden). Die Programmierung wird einfacher, wenn mehr Leistung zur Verfügung steht. Ich bin mittlerweile komplett von Atmegas auf die Cortexe umgestiegen. lg lutz
Angehängte Dateien:
-
TFT2.png
330 KB
Relativ unwichtig ist der Preis des Controllers. (außer bei einem Seriengerät). Wichtig ist, dass es geeignete Software gibt. Z.B ich entwickle ein EKG und verwende ein TFT Display. Ein Treiber für das Display interessiert mich im Detail nicht - benötige aber einem. Mit einem Arduino Due und einem Shield konnte ich das ohne eine Verdrahtung zu verlegen in einer kurzen Zeit ansprechen.
Ein kleiner ARM (etwa Cortex M3 / M4) ist schon eine passende Wahl. Einen kleinen Vorteil haben die AVRs aber ggf. schon noch: die Ausgänge können 5 V mit relativ viel Strom liefern - die ARMs eher nur 3,3 V oder so.
Walter von der schrieb: > Ein Treiber für das Display interessiert > mich im Detail nicht - benötige aber einem. > Mit einem Arduino Due und einem Shield konnte ich das ohne eine > Verdrahtung zu verlegen in einer kurzen Zeit ansprechen. Da hast Du völlig recht, andererseits liefert eigentlich jeder uC Hersteller solche Treiber z.B. für LPC1700/LPC4000 für verschiedene Touch-LCD: https://www.olimex.com/Products/Modules/LCD/MOD-LCD4.3%27%27/ Und man bekommt mit dem Kauf des uC auch eine Lizenz für eine Grafik-Bibliothek: http://www.lpcware.com/content/project/emwin-graphics-library Und es gibt aufwendige Demos für fast alles: http://www.lpcware.com/content/project/lpc4088-pos-demo
lutz schrieb: > Ich musste mich nicht mehr um effiziente Programmierung kümmern Damit ist das ganze Elend hochsprachenvollgepumpter, immer rechenstärker geforderter Hochleistungscontroller voll umfänglich beschrieben.
Moby schrieb: > Damit ist das ganze Elend hochsprachenvollgepumpter, immer rechenstärker > geforderter Hochleistungscontroller voll umfänglich beschrieben. ARM2 BASIC von 1989 läuft auf einem ARM11 in 2014 richtig zügig :-) http://roevalley.com/newsbrowser/pi_projects/2xPi_pwm.html
Lothar schrieb: > ARM2 BASIC von 1989 läuft auf einem ARM11 in 2014 richtig zügig :-) Wie schnell würde auf dem Arm11 erst ordentlicher Asm-Code laufen? Nur daß sich dann herausstellt, ein Attiny täte es in der konkreten Anwendung eigentlich auch :-)
Ich möchte da gerne mal etwas anfügen zum Thema der Controllerwahl: Klar sollte möglichst darauf geachtet werden, einen Optimalen Controller zu wählen. Es ist aber auch nicht immer einfach, diesen zu finden. Gerade wenn man in ein neues Gebiet einsteigt (Hier Beispielsweise Modellbau) ist es nicht immer einfach abzuschätzen, wieviel Leistung der Controller haben sollte. Schliesslich findet man kaum wirklich Brauchbare Referenzen. Desweiteren muss man auch einsehen, dass bei einem solchen Projekt das Geld wohl nicht unbedingt an erster Stelle steht, so dass man schnell mal mit Kanonen auf Spatzen schiesst. Merken wir bei unserem aktuellen Projekt gerade selbst, dass wir viel zu viel Leistung übrig haben. Doch schlussendlich spieltr es doch eine verschwindend kleine Rolle. Schliesslich stört es ja keinen von 8 Milliarden Menschen auf dem Planeten, wenn in einem selbstgebauten Quadro zuviel Rechenleistung vorhanden ist. Wo ich allerdings zustimmen kann: Moby schrieb: > lutz schrieb: >> Ich musste mich nicht mehr um effiziente Programmierung kümmern > > Damit ist das ganze Elend hochsprachenvollgepumpter, immer rechenstärker > geforderter Hochleistungscontroller voll umfänglich beschrieben. Das ist in meinen Augen ein weitaus wichtigerer Punkt. Die Effizienz des eigenen Codes. Denn hinter diesem liegt das Geheimniss eines jeden guten Produktes.
Moby schrieb: > lutz schrieb: >> Ich musste mich nicht mehr um effiziente Programmierung kümmern > > Damit ist das ganze Elend hochsprachenvollgepumpter, immer rechenstärker > geforderter Hochleistungscontroller voll umfänglich beschrieben. Daß er sich ganz auf die eigentliche Aufgabe konzentrieren kann und sich nicht gleich von Anfang an in irgendwelchen Optimierungen verlieren muss, würde ich nicht als "Elend" bezeichnen.
Beim Überfliegen habe ich ein Themengebiet noch gar nicht gesehen. Es hilft einem nicht nur pure Rechenleistung weiter, sondern auch Dinge wie DMA und Eventsysteme, über welche z.B. die ARM verfügen. Diese Systeme nehmen einem mittels Hardware Dinge ab, für die ein AVR CPU Zeit braucht, ADC Wert holen, SPI Wert holen etc. Es gibt da das stm32F3 discovery mit Beschleunigungssensor, Gyro und Magnetometer - alles 3D versteht sich :-) Dazu schöne Firmware Examples für einen ersten Einstieg. Allerdings haben die stm32 der F3´er Familie keine FPU. Ob man die braucht, ich nix weiß. Aber ich meine zu wissen, dass es bereits Koppterprojekte auf Basis dieses F3discovery Boardes gibt.
Rolf Magnus schrieb: > sich ganz auf die eigentliche Aufgabe konzentrieren Heißt wohl: Was schert mich irgendein Ressourcenverbrauch? Was bitte anderes als immer höhere, unnötige Anforderungen und Threads wie dieser sollen aus dieser Bequemlichkeit resultieren? Asm-Code ist mehr als "irgendwelche Optimierungen". Er ist die einfachste, kleinstmöglichste, schnellste, paßgenaueste Lösung jeder Aufgabe.
Moby schrieb: > Asm-Code ist mehr als "irgendwelche Optimierungen". Er ist die > einfachste, kleinstmöglichste, schnellste, paßgenaueste Lösung jeder > Aufgabe. Stimmt, nur macht ASM aus meiner Sicht nur Sinn, wenn der Programmierer auch weiss, was er macht. Ansonsten ists genauso ressourcenvernichtend. Ausserdem habe ich noch nie jemanden gesehen, der ARMs mit ASM programmiert (eben weil die Leistung vorhanden ist, und wenn man DMAs und FPUs geschickt einsetzt, kommt man wohl nie an an Grenzen: Wir haben schon Mit Cortex M0 eine Positionsregelung für 3-Phasen Synchronmotoren realisiert (3 kaskadierte Regelkreise pro Phase, wobei der äusserste mit 10kHz lief), und der hatte immer noch Reserve. Einzige Bedingung ist ein schlauer Compiler und auch gute Programmierer (wenn man natürlich die überladene Std_Periph_Lib von ST nutzt anstelle der CMSIS bremst man sich selber aus).
Moby schrieb: > Heißt wohl: Was schert mich irgendein Ressourcenverbrauch? > Was bitte anderes als immer höhere, unnötige Anforderungen und Threads > wie dieser sollen aus dieser Bequemlichkeit resultieren? Soll es wohl indirekt auch heissen, aber ganz unrecht hat er damit ja nicht. Schau dir Arduino an... die ganzen Libs die man dort verwenden kann sind bestimmt auch nicht das Gelbe vom Ei, trotzdem reicht es für sehr viele Anwendungen im privatgebrauch. Da krazt es auch kein Mensch. Moby schrieb: > Asm-Code ist mehr als "irgendwelche Optimierungen". Er ist die > einfachste, kleinstmöglichste, schnellste, paßgenaueste Lösung jeder > Aufgabe. Dem Stimme ich nicht zu. Ich gebe dir recht, ASM ist mehr als nur eine Optimierung. Ich gebe dir auch recht, dass man ein Programm welches in perfektem ASM geschrieben ist, nicht besser machen kann. Spätestens bei EINFACHSTE und vor allem KLEINSTMÖGLICHE hört es aber auf. ASM ist weitaus weniger verbreitet, gerade bei der jungen Generation. Kleinstmöglich vielleicht, was der Ressourcen verbrauch angeht. Aber Programmier mal in ASM eine Floating Point Division mit paar Kommastellen auf einem 8-Bitter und mach das selbe mal in C. Kannst mir kaum erzählen, dass ASM da einfacher sein soll. Eine Zeile gegen ein paar Dutzend.
STM32F3 /4 mit CMSIS-RTOS oder einem anderem RTOS (ChibiOs ist sehr zu empfehlen) bringt genügend Rechenleistung um deterministisches Verhalten zu garantieren. Ausserdem bin ich mir sicher dass bisjetzt noch genug CPU-Fresser wie Pollroutinen verwendet werden. Da helfen natürlich Pipes in den ISRs oder Signals viel Rechenleistung einzusparen. Und plötzlich landet man einen Grossteil der Rechenzeit im idle-thread.
Patrick B. schrieb: > wenn man natürlich die > überladene Std_Periph_Lib von ST nutzt anstelle der CMSIS bremst man > sich selber aus Nanu? CMSIS ist doch nur ein Wrapper. Dahinter hängt schon noch die Lib von ST! Hörnsemal!
Moby schrieb: > Asm-Code ist mehr als "irgendwelche Optimierungen". Er ist die > einfachste, kleinstmöglichste, schnellste, paßgenaueste Lösung jeder > Aufgabe. Viel wichtiger sind die verwendeten Algorithen, die Softwarearchitektur und natürlich die Wartbarkeit und Wiederverwendbarkeit. Ein gscheiter C Compiler macht mit Optimierung sehr performanten Code. Ich kann Softwaremodule in C die über der uC Abstraktionseben sind einfach weiterverwenden... Und ja ich benutze auch ASM, aber wirklich nur da wo es notwendig ist. Z.B. RAM Test oder wenn noch keine C-Runtime zu Verfügung steht. Oder auch in der OS-Programmierung. Mini Projekterl auf einem 8-bitter kannst eh in ASM machen.
Patrick B. schrieb: > Stimmt, nur macht ASM aus meiner Sicht nur Sinn, wenn der Programmierer > auch weiss, was er macht. Ansonsten ists genauso ressourcenvernichtend. Wer Asm gelernt hat und die Hardware so vor sich sieht wie sie ist macht ganz sicher eines nicht: Ressourcen verschwenden. Der Hochsprachen-Programmierer weiß im Unterschied dazu leider nicht immer, was er macht. Weil er den verwendeten fertigen Bibliothekscode inklusive aller Nebenwirkungen nicht hinterfragt, weil er Compilereigenheiten hinnehmen muß. Patrick B. schrieb: > Ausserdem habe ich noch nie jemanden gesehen, der ARMs mit ASM > programmiert Gerade dafür sind sie auch ungeeignet. Patrick B. schrieb: > wenn man DMAs > und FPUs geschickt einsetzt, kommt man wohl nie an an Grenzen Ok, FPU hat mein AVR keine, aber ansonsten hab ich mit meinem Xmega das genau gleiche Gefühl! Wenn vorhandene Spezialperipherie auf eine passende Aufgabe trifft, und aus betrieblichen Anforderungen heraus, dann mag die Controllerwahl anders ausfallen. San Lue schrieb: > Schau dir Arduino an... die ganzen Libs die man dort verwenden > kann sind bestimmt auch nicht das Gelbe vom Ei, trotzdem reicht es für > sehr viele Anwendungen im privatgebrauch. Da krazt es auch kein Mensch. Zum Einstieg ist Arduino absolut geeignet. Für viele Anwendungen auch! Doch dann kommt der Punkt wo die Ressourcen ausgehen wie hier und/oder dicke Shieldstapel nicht mehr unterzubringen sind... San Lue schrieb: > Spätestens bei EINFACHSTE und vor allem KLEINSTMÖGLICHE hört es aber > auf. ASM ist weitaus weniger verbreitet, gerade bei der jungen > Generation. Einfachste- von der Syntax her. Kleinstmöglichste- von der erreichbaren Codegröße her. Und den Verbreitungsgrad steigert man nur durch eigene Aktivität. Jung & bequem- das muß doch nicht sein. Die Erfahrung, alles selbst in der Hand zu haben, alle Codefreiheiten zu haben, auf nichts und niemand für optimalen Code angewiesen zu sein entschädigt für alles! San Lue schrieb: > Aber > Programmier mal in ASM eine Floating Point Division mit paar > Kommastellen auf einem 8-Bitter und mach das selbe mal in C Das Schöne an Software ist doch, einmal und von irgendwem geschrieben kann man es nutzen sooft es beliebt. Ich hab dafür (fast) auch nur eine Zeile: ein einfaches Call (mit vorab geladenen Parametern). Nix mit ein paar Dutzend... das wird genauso included.
Moby schrieb: > Jung & bequem- das muß doch nicht sein. Ich empfehle ausdrücklich sich so ein Denkmuster nicht dogamtisch anzueignen. Klingt unglaublich nach Fortschrittsfrust ;)
foo schrieb: > Viel wichtiger sind die verwendeten Algorithen, die Softwarearchitektur > und natürlich die Wartbarkeit und Wiederverwendbarkeit. Der Bastler kann bei seiner Architektur bleiben. Innerhalb derer ist alles genauso wartbar und wiederzuverwenden. foo schrieb: > Ein gscheiter C Compiler macht mit Optimierung sehr performanten Code. Und es geht immer noch besser... foo schrieb: > Ich kann Softwaremodule in C die über der uC Abstraktionseben sind > einfach weiterverwenden... Ja wenn man unterschiedliche Architekturen verwenden MUSS foo schrieb: > Mini Projekterl auf einem 8-bitter kannst eh in ASM machen. Und nicht nur die! Alles eine Frage von System und Vorbereitung, glaub mir.
Moby schrieb: > San Lue schrieb: >> Aber >> Programmier mal in ASM eine Floating Point Division mit paar >> Kommastellen auf einem 8-Bitter und mach das selbe mal in C > > Das Schöne an Software ist doch, einmal und von irgendwem geschrieben > kann man es nutzen sooft es beliebt. Ich hab dafür (fast) auch nur eine > Zeile: ein einfaches Call (mit vorab geladenen Parametern). Nix mit ein > paar Dutzend... das wird genauso included. Ist aber auch nicht schneller als z.B. die C Runtime. Und die C runtime float-division ist garantiert 10 mal besser getestet und fehlerfreier.
ARM schrieb im Beitrag #3734797: > Nanu? CMSIS ist doch nur ein Wrapper. Dahinter hängt schon noch die Lib > von ST! > Hörnsemal! Sorry, hab was durcheinander gebracht. Ich meinte die fertigen Funktionen für alles gegen direkten Registerzurgiff: GPIO_SetBits(GPIOA, GPIO_Pin_0); GPIOB->BSRR = GPIO_Pin_0; Eigentlich ists das gleiche, nur braucht die eine Zeile mehr als doppelt so lange zum ausführen, da die Funktion aufgrund der Assertations nicht mehr als Inline intepretiert wird (zumindest beim IAR Compiler).
Udo Schmitt schrieb: > Und die C runtime > float-division ist garantiert 10 mal besser getestet und fehlerfreier. Ich bestreite daß dies auf die Routinen von M.Schwabl-Schmidt in "Systemprogrammierung II für AVR-Mikrocontroller" zutrifft ;-)
Patrick B. schrieb: > Eigentlich ists das gleiche, nur braucht die eine Zeile mehr als doppelt > so lange zum ausführen, da die Funktion aufgrund der Assertations nicht > mehr als Inline intepretiert wird (zumindest beim IAR Compiler). #undef USE_FULL_ASSERT bussi :)
ist zwar mitlerweile OT, aber... mhm, habe ich bei mir nie drinn, aber vieleicht gehts ja
1 | #ifdef USE_FULL_ASSERT
|
2 | |
3 | /**
|
4 | * @brief Reports the name of the source file and the source line number
|
5 | * where the assert_param error has occurred.
|
6 | * @param file: pointer to the source file name
|
7 | * @param line: assert_param error line source number
|
8 | * @retval None
|
9 | */
|
10 | void assert_failed(uint8_t* file, uint32_t line) |
11 | {
|
12 | /* User can add his own implementation to report the file name and line number,
|
13 | ex: printf("Wrong parameters value: file %s on line %d\r\n", file, line) */
|
14 | |
15 | /* Infinite loop */
|
16 | while (1) |
17 | {
|
18 | }
|
19 | }
|
20 | #endif
|
1 | void GPIO_SetBits(GPIO_TypeDef* GPIOx, uint16_t GPIO_Pin) |
2 | {
|
3 | /* Check the parameters */
|
4 | assert_param(IS_GPIO_ALL_PERIPH(GPIOx)); |
5 | assert_param(IS_GPIO_PIN(GPIO_Pin)); |
6 | |
7 | GPIOx->BSRR = GPIO_Pin; |
8 | }
|
So wie ich das sehe, wird die Funktion assert_param immer vorhanden sein, egal ob das #undef drin ist oder nicht. Es wird einfach nicht auf ein falscher Wert reagiert (z.B. über USART etwas senden oder was weiss ich).
:
Bearbeitet durch User
So wie ich das sehe, wird ohne USE_FULL_ASSERT da ein ((void)0) eingesetzt:
1 | /* Exported macro ------------------------------------------------------------*/
|
2 | #ifdef USE_FULL_ASSERT
|
3 | /**
|
4 | * @brief The assert_param macro is used for function's parameters check.
|
5 | * @param expr: If expr is false, it calls assert_failed function
|
6 | * which reports the name of the source file and the source
|
7 | * line number of the call that failed.
|
8 | * If expr is true, it returns no value.
|
9 | * @retval None
|
10 | */
|
11 | #define assert_param(expr) ((expr) ? (void)0 : assert_failed((uint8_t *)__FILE__, __LINE__))
|
12 | /* Exported functions ------------------------------------------------------- */
|
13 | // void assert_failed(uint8_t* file, uint32_t line);
|
14 | #else
|
15 | //#define assert_param(expr) ((void)0)
|
16 | #include "Assert.h" |
17 | #endif /* USE_FULL_ASSERT */ |
Gruß, Stefan
Patrick B. schrieb: > So wie ich das sehe, wird die Funktion assert_param immer vorhanden > sein, egal ob das #undef drin ist oder nicht. Es wird einfach nicht auf > ein falscher Wert reagiert (z.B. über USART etwas senden oder was weiss > ich). Hast du geglaubt wir schauen nicht noch eine Ebene tiefer? :) Stefan schrieb: > So wie ich das sehe, wird ohne USE_FULL_ASSERT da ein ((void)0)
Walter Tarpan schrieb: > OT: Gibt es dazu eine Doku? klaro. http://www.st.com/st-web-ui/static/active/en/resource/technical/document/user_manual/DM00068049.pdf Seite 19
@ Ratzfatz78: Lass Dich nicht beirren, Du machst das schon richtig. Das von Dir vorgeschlagene Board: http://www.mikroe.com/mini/stm32/ sieht ganz gut aus. Das Einzige, was fehlt, ist ein fertig konfigurierter jtag-Stecker, aber das kann man an den Pins ja noch nachrüsten. Für einen Tricopter würde ich jedenfalls nicht freiwillig auf Rechenleistung verzichten, wenn es die für das gleiche Geld und das gleiche Gewicht woanders gibt. Der STM32F4xx ist richtig klasse, die 168Mhz stehen nicht nur auf dem Papier. Und die DSP-Erweiterung ist bei einem Regeltechnik-Projekt auch nicht verkehrt. Die kommt zwar nicht ganz an einen "echten" DSP heran, ist aber deutlich leistungsstärker als mit einem "normalen" mcu-Befehlssatz. Viel Erfolg, Stefan
Stefan schrieb: > Der STM32F4xx ist richtig klasse, die 168Mhz stehen nicht nur auf dem > Papier. Und die DSP-Erweiterung ist bei einem Regeltechnik-Projekt auch > nicht verkehrt. Die kommt zwar nicht ganz an einen "echten" DSP heran, > ist aber deutlich leistungsstärker als mit einem "normalen" > mcu-Befehlssatz. Oh ja! Die CMSIS-DSP ist da Pfeilschnell! http://www.keil.com/pack/doc/CMSIS/DSP/html/index.html
OK, ist bei mir standartmässig auskommentiert. Also demnach spielts keine Rolle. Die Funktion kann der Compiler trotzdem nicht inlinen (auch bei entsprechender Optimierung, habs gerade mal wieder gemessen).
Patrick B. schrieb: > OK, ist bei mir standartmässig auskommentiert. Also demnach spielts > keine Rolle. Die Funktion kann der Compiler trotzdem nicht inlinen (auch > bei entsprechender Optimierung, habs gerade mal wieder gemessen). Unverständlich. Bei mir ist das einerseits NICHT auskommentiert und der Compiler (Keil) macht das brav mit --autoinline und -Ospeed
Angehängte Dateien:
-
compiler.jpg
71 KB -
linker.jpg
57 KB
Mhm, komisch. Habs nochmals geprüft(siehe Bilder). Anscheinend ist der Compiler nicht für viel. Hast du das wirklich mit einem Oszilloskop gemessen und verglichen? BT: Persönlich würde ich dir ein STM32F4 Discovery empfehlen, da Leistung und auch DMAs vorhanden sind. Die nehmen dir die ganze Arbeit mit den ADCs und Kommunikationen ab. Ebenso ist die FPU nicht zu unterschätzen (hatte mal den Vergleich bei einem Display gesehen -> ~Faktor 4), sowie die erwähnten DSP Funktionen. Ausserdem ist das ganze sehr gut Dokumentiert und es gibt viele gute IDEs.
> Daß er sich ganz auf die eigentliche Aufgabe konzentrieren kann und sich > nicht gleich von Anfang an in irgendwelchen Optimierungen verlieren > muss, würde ich nicht als "Elend" bezeichnen. Der effiziente Code für den Atmega war schlechter lesbar. Ist ja logisch, wenn man Tabellen vorberechneter Werte benötigt, Bitshifts und lauter Tricks um das Timing einzuhalten. Mit dem stm32 wars einfach. Die drei PID Regelformeln passten in 3 Zeilen so wie sie im Tabellenbuch stehen. Ganz einfach, ohne Handstände und ohne Probleme. Und das Schönste: Es ist jede Menge Luft nach oben. Es sind keine Handstände nötig, wenn das Ganze mal erweitert werden muss. Der Spaß geht ja erst so richtig los, wenn ein durch und durch "abgetimtes" System plötzlich mehr können muss. Mein Fazit ist ganz eindeutig. Atmegas kommen mir nicht mehr in die Bastelkiste. Die wurden längst ersetzt. :-)
Patrick B. schrieb: > Mhm, komisch. Habs nochmals geprüft(siehe Bilder). Anscheinend ist der > Compiler nicht für viel. Hast du das wirklich mit einem Oszilloskop > gemessen und verglichen?
1 | 68: GPIO_InitStructure.GPIO_OType = GPIO_OType_PP; |
2 | 0x080002B6 2100 MOVS r1,#0x00 |
3 | 0x080002B8 7181 STRB r1,[r0,#0x06] |
4 | 69: GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL ; |
5 | 0x080002BA 71C1 STRB r1,[r0,#0x07] |
6 | 70: GPIO_Init(GPIOB, &GPIO_InitStructure); |
7 | 0x080002BC 4601 MOV r1,r0 |
8 | 0x080002BE 4620 MOV r0,r4 |
9 | 0x080002C0 F000F87C BL.W GPIO_Init (0x080003BC) |
10 | 71: GPIO_SetBits(GPIOB,GPIO_Pin_8); |
11 | 0x080002C4 F44F7180 MOV r1,#0x100 |
12 | 0x080002C8 4620 MOV r0,r4 |
13 | 0x080002CA 6181 STR r1,[r0,#0x18] |
14 | 0x080002CC BF00 NOP |
15 | 72: while (1) |
hast du eh nicht vergessen dem LINKER auch beizubringen dass er inlinen soll? bei mir ist das --inline_type=all
Ratzfatz78 schrieb: > @all > Vielleicht war ich beim letzten Kommentar etwas gereizt :( > Wollte mich dafür entschuldigen > Der letzte Satz hat mich halt etwas aufgeregt :) > @Frank M. > > Ich hab was Elektrik angeht "fast" null Ahnung hab nur Mechanik > studiert. > Ich hatte mir aus diesem Grund das Arduino nano geholt und das auf mein > Board aufgesetzt.Das war einfach, ging schnell und hat für meine > Bedürfnisse super gepasst und ich konnte mich mit dem beschäftigen was > ich lernen wollte und zwar Microkontroller programmieren. learning by doing :) > Zum I2C Thema > > Auch im Programmieren bin ich nicht Perfekt. > Mir ist nur aufgefallen das meine Schleife immer langsamer wurde mit > jedem I2c Bauteil was ich da dran angeschlossen habe. > Hatte dann komplett Probleme mit dem Mpu6050 da ist alles in den Keller > gegangen. Das sagt uns, dass Du mit hoher Wahrscheinlichkeit die Software I2C verwendetest und der Controller dann bei den Befehlen Warterunden drehte während der Verarbeitung. Da I2C, speziell die Bascom Soft-I2C nicht besonders schnell ist bleibt natürlich dann keine Rechenleistung mehr übrig, da der µC Daumen dreht in der Warteschleife. Das ginge aber jedem anderen Controller bei dieser Programmierung so. Der AVR har diverse Interrupts und I2C in Hardware ... nutze diese und Du wirst Dich wundern wie flott der Käfer auf einmal sein kann. Oft wird der Fehler auch bei der Verwendung von "Print" auf der UART gemacht. > Zur Schnelligkeit > > 99% meiner Variablen sind INTEGER b.z.w. mit Long deklariert. > Dezimalstellen habe ich fast komplett vermieden. > Vielleicht hab ich ja ein Problem mit dem I2C gehabt und hab das auf > den langsamen Controller geschoben. Ist ja auch jetzt egal, ich will in > der zweiten Ausbaustufe nur mein Controller und GPS Module verbessern. Dann sollte das Ding eigentlich flott rechnen können ... wenn die I2C nicht alles ausbremst.
Patrick B. schrieb: > Die Funktion kann der Compiler trotzdem nicht inlinen (auch > bei entsprechender Optimierung, habs gerade mal wieder gemessen). probier mal folgendes: - Schau mal ob du multi-file-compilation andrehen kannst. --mfc laut: http://supp.iar.com/FilesPublic/UPDINFO/004342/manuals.htm - gibt es möglicherweise getrennte build settings für das Projekt/Release und global? wird hier bemerkt: http://e2e.ti.com/support/wireless_connectivity/f/155/p/38003/134417.aspx#134417 - komischerweise gibt es die Linkeroption auf deinem Screenshot nicht als Commandline. Wie wird das sonst geregelt? Quelle: http://pessoal.utfpr.edu.br/hvieir/EL08D/EWARM_DevelopmentGuide.pdf - Schalte mal auf c99 und ändere in stm32f37x_gpio.c:
1 | inline void GPIO_SetBits(GPIO_TypeDef* GPIOx, uint16_t GPIO_Pin) |
und in der headerfunktion
1 | extern inline void GPIO_SetBits(GPIO_TypeDef* GPIOx, uint16_t GPIO_Pin) |
wenn das nicht geht hast du ein Problem, denn dann kannst du generell keine Inlinefunktionen aus Modulen verwenden.
Angehängte Dateien:
-
disassembly.jpg
31 KB
Kannst du drehen und wenden, wie du willst. Das Verwenden der Funktion ist nunmal langsamer (selbst bei so einer einfachen Funktion). Ok, gut, bei mir sind noch 2 weitere Operationen drin als bei dir, aber mit dem direkten verwenden komme ich auf 2, anstelle von 3 bei dir. Hier sind mal die Disassemblys der beiden Varianten (mit allen Optimierungen eingeschaltet, selbst mfc)... Hatte auchschon das Phänomen, dass eine CRC-Berechnung über Verknüpfungen schneller war als eine Look-up Tabelle. Habs auch erst mit einem KO beim Prüfen der Software gemerkt (musste die Durchlaufszeiten der einzelnen Funktionen auf ein Minimum reduzieren, und dann sieht man sowas...).
:
Bearbeitet durch User
Moby schrieb: > Rolf Magnus schrieb: >> sich ganz auf die eigentliche Aufgabe konzentrieren > > Heißt wohl: Was schert mich irgendein Ressourcenverbrauch? Es heißt genau das, was ich hingeschrieben habe, daß ich mich auf's wesentliche konzentrieren kann, statt einen Haufen Zeit (und das ist auch eine oft knappe Ressource) mit Optimierung zu verschwenden. In der Entwicklung ist es auch nichts ungewöhnliches, so vorzugehen. Wenn man später mal ein Serienprodukt draus machen will, kann man sich dann damit auseinandersetzen. Aber gleich am Anfang sich zusätzliche eigentlich unnötige Probleme aufzuhalsen ist nicht sinnvoll. > Was bitte anderes als immer höhere, unnötige Anforderungen und Threads > wie dieser sollen aus dieser Bequemlichkeit resultieren? Du hast jetzt immer noch kein Argument gegen die Verwendung des ARM genannt, abgesehen von deiner Paranoia, daß die Welt in Rechenaufwand versinken wird. Moby schrieb: > Wer Asm gelernt hat und die Hardware so vor sich sieht wie sie ist macht > ganz sicher eines nicht: Ressourcen verschwenden. Doch! Er verschwendet die Ressource "Arbeitszeit". Mir kann keiner erzählen, daß ein nichttriviales Programm in ASM schneller geschrieben ist als in C. Und lesbarer/wartbarer wird es auch nicht sein. Von Portabilität reden wir erst gar nicht (wenn man dann merkt, daß auch in Assembler der AVR nicht schnell genug für die geplanten Erweiterungen ist). > Der Hochsprachen-Programmierer weiß im Unterschied dazu leider nicht > immer, was er macht. "Der Hochsprachen-Programmierer", das unbekannte Wesen? Es ist ein etwas komischer Grund, sich selbst dazu zu entscheiden, Assembler zu programmieren, weil Hochsprachen-Programmierer ja keine Ahnung haben. Damit sagst du ja, daß du selbst nur dann Ahnung haben kannst, wenn du Assembler programmierst. Ich habe beides schon gemacht, programmiere lieber in C oder C++ und weiß trotzdem sehr genau, was der Compiler aus meinen Konstrukten macht. Da wo's drauf ankommt, schau ich mir den generierten Code halt an. Aber es kommt auch nicht überall wirklich drauf an, sondern ganz im Gegenteil nur an sehr wenigen Stellen im Code. Es sei denn, man hat einen zu kleinen Controller gewählt. Dann muß man natürlich jedes Byte einzeln rauskitzeln. > Weil er den verwendeten fertigen Bibliothekscode inklusive aller > Nebenwirkungen nicht hinterfragt, weil er Compilereigenheiten > hinnehmen muß. Auf der anderen Seite arbeiten an dem Bibliothekscode in der Regel viele Leute, was oft hoch optimierten und gut getesteten Code zur Folge hat. Natürlich ist das aber nicht immer so. Manche Bibliotheken sind halt einfach Mist. Aber man muß sie ja auch nicht zwingend nutzen. Man kann's immer noch zu Fuß programmieren. Es gibt beide Optionen. Wenn ich keine feritgen Bibliotheken nutze, muß ich dagegen alles komplett selber machen. > San Lue schrieb: >> Spätestens bei EINFACHSTE und vor allem KLEINSTMÖGLICHE hört es aber >> auf. ASM ist weitaus weniger verbreitet, gerade bei der jungen >> Generation. > > Einfachste- von der Syntax her. Allerdings nicht von der Programmierung. Es ist umständlicher, und der Code ist deutlich schwerer lesbar. > Jung & bequem- das muß doch nicht sein. Man muß aber auch nicht alles so machen, wie noch vor 30 Jahren, nur weil's damals halt auch so war. Wie der Opa immer sagte: "Damals im Krieg, da sind wir noch jeden Tag zu Fuß zur Schule gegangen, zwei Stunden hin und zwei Stunden zurück, bei minus zwanzig Grad!" > Die Erfahrung, alles selbst in der Hand zu haben, alle Codefreiheiten zu > haben, auf nichts und niemand für optimalen Code angewiesen zu sein > entschädigt für alles! Da gebe ich dir recht. Wenn man Computer wirklich verstehen will, muß man mal Assembler programmiert haben. Aber deswegen muß ich das ja nicht für den Rest meiner Tage ausschlißlich nutzen. > San Lue schrieb: >> Aber >> Programmier mal in ASM eine Floating Point Division mit paar >> Kommastellen auf einem 8-Bitter und mach das selbe mal in C > > Das Schöne an Software ist doch, einmal und von irgendwem geschrieben > kann man es nutzen sooft es beliebt. Ich hab dafür (fast) auch nur eine > Zeile: ein einfaches Call (mit vorab geladenen Parametern). Nix mit ein > paar Dutzend... das wird genauso included. Sieht aber immer noch umständlicher aus als ein
1 | a = b / c; |
Rolf, vielen dank für diesen Beitrag. Endlich jemand der meine Meinung teilt. Ich habe vor einigen Wochen meine Berufslehre als Elektroniker beendet. In der Berufsschule haben wir die ersten zwei Jahre lang nur Assembler programmiert, danach auf C umgestiegen. Bei einem Kumpel in einer anderen Berufsschule hatten sie von Anfang an nur C. Was sich nun gut abzeichnet nach 4 Jahren: C Programmieren können wir beide einigermassen, was das Verständniss eines Mikrocontrollers angeht, bzw. wie er arbeitet usw ist ihm ein Rätsel. In der Berufsschule haben wir mit PIC's gelernt. Wenn ich meinen Kumpel nach Begriffen wie Status oder Work Register Frage, schaut er mich nur dumm an. Als ich ihm einmal gezeigt habe, was hinter einer Floating Point Division in C steckt, hat er ganz schön dumm geguckt. Trotzdem stimme ich dir voll und ganz zu, C Programmieren ist einfach praktischer und lesbarer. Trotzdem bin ich sehr froh darüber Assembler gelernt zu haben, bringt einem die Hardware VIEL näher als C.
Rolf Magnus schrieb: > Es heißt genau das, was ich hingeschrieben habe, daß ich mich auf's > wesentliche konzentrieren kann, statt einen Haufen Zeit (und das ist > auch eine oft knappe Ressource) mit Optimierung zu verschwenden. > In der Entwicklung ist es auch nichts ungewöhnliches, so vorzugehen. Ja absolut. Das stelle ich täglich fest, wenn in der Funktion vergleichsweise simple Software selbst aktuelle und gut ausgestattete Hardware in die Knie zwingt. Zum Beispiel betrifft dies die meisten Produkte aus der Haufe/Lexware-Schmiede. > Wenn man später mal ein Serienprodukt draus machen will, kann man sich > dann damit auseinandersetzen. Das macht aber keiner. Wenn sich der Murks trotzdem einigermaßen verkauft, wird dafür keine Zeit investiert, sondern schon der nächste Ressourcenfresser hingeschmiert.
Ich denke das Fazit ist, dass man die entsprechende Sprache für das entsprechende Problem einsetzt. Aus rein wirtschaftlicher sicht her, nimmt man lieber für 20 Cent (oder bei einer 1000er Serie sinds dann noch 2-5 Cent) den nächst besseren Controller als einen Monat mehr Entwicklungszeit für die Software zu "verschwenden", ganz abgesehen von der Wartung und Weiterentwicklung. Bei uns im Betrieb sind wir mittlerweile von 8Bit komplett auf ARM und C++ umgestiegen. So kann der Identische Code quer durch die ganze STM-Familie eingesetzt werden (ausser ganz wenigen Anpassungen) und gleichzeitig können die Module auch auf dem FPGA verwendet werden. Daraus resultiert, dass ein Programmierer ein Modul warten muss, und man kann gleich 10 Produkte oder mehr auf einmal aktualisieren. Betreffend der Optimierung: Wenn man dem Compiler etwas unter die Arme greift, kann der auch sehr guten Code generieren (klar, nicht so wie reines ASM, aber das ist auch nicht nötig). Aber eigentlich sind wir mitlerweile seeehr weit vom Thema abgekommen...
:
Bearbeitet durch User
San Lue schrieb: > Trotzdem stimme ich dir voll und ganz zu, C Programmieren ist einfach > praktischer und lesbarer. Trotzdem bin ich sehr froh darüber Assembler > gelernt zu haben, bringt einem die Hardware VIEL näher als C. Das hat ja mit C mal nichts zu tun. Wenn Du keine fertigen Libs verwendest, musst Du auch in C die Hardware ganz genau kennen.
San Lue schrieb: > Als ich ihm einmal gezeigt habe, was hinter einer > Floating Point Division in C steckt, hat er ganz schön dumm geguckt. Zumindest bei einem uC ohne Hardware FPU.
foo schrieb: > Wenn Du keine fertigen Libs verwendest, musst Du auch in C die Hardware > ganz genau kennen. Nur die Peripherie die du explizit nutzt. Implizite hingegen nutzt du auch Hardware, was du mit C aber eben nicht merkst, bzw. dir keine Gedanken darum machen musst. Nämlich Dinge wie Datentypen/Breiten, Speicher (int/ext), Sprünge (near/far), Stack, FPUs, Registernutzung/Sicherung. Und genau diese Sachen sind die wirklich zeitraubenden und komplizierten Dinge in Assembler. Das setzen von ein paar Bits in einem Register um die UART zu konfigurieren interessieren doch niemanden, weder in C noch in ASM. gruß cyblord
Patrick B. schrieb: > Ich denke das Fazit ist, dass man die entsprechende Sprache für das > entsprechende Problem einsetzt. Aus rein wirtschaftlicher sicht her, > nimmt man lieber für 20 Cent (oder bei einer 1000er Serie sinds dann > noch 2-5 Cent) den nächst besseren Controller als einen Monat mehr > Entwicklungszeit für die Software zu "verschwenden", ganz abgesehen von > der Wartung und Weiterentwicklung. Bei uns im Betrieb sind wir > mittlerweile von 8Bit komplett auf ARM und C++ umgestiegen. So kann der > Identische Code quer durch die ganze STM-Familie eingesetzt werden > (ausser ganz wenigen Anpassungen) und gleichzeitig können die Module > auch auf dem FPGA verwendet werden. Daraus resultiert, dass ein > Programmierer ein Modul warten muss, und man kann gleich 10 Produkte > oder mehr auf einmal aktualisieren. Der Text hätte von mir sein können. Ich starte meine Projekte eigentlich immer mit einem "dicken" STM32, um nicht endlos rumoptimieren zu müssen. Wenn dann alles läuft, schaue ich, welcher kleinere Controller (natürlich mit passender "Luft nach oben") passt und verwende den dann im fertigen Gerät. Üble Klimmzüge mit Optimierungen hatte ich damals mit den AVRs und das muss ich nicht nochmal haben: so etwas frisst endlos Zeit und der Mehrpreis ist keinem Kunden vermittelbar, wenn es nicht um Stückzahlen im 100000er-Bereich geht. > Betreffend der Optimierung: Wenn man dem Compiler etwas unter die Arme > greift, kann der auch sehr guten Code generieren (klar, nicht so wie > reines ASM, aber das ist auch nicht nötig). Richtig. Wenn man sich den generierten Code des gcc anschaut, dann ist der schon sehr gut. Niemand, der ernsthaft Geld verdienen möchte, wird in Assembler schreiben, wenn es nicht absolut notwendig ist. Aber: man sollte auf jeden Fall mal in Assembler programmiert haben, um zu verstehen, was ein Controller überhaupt macht und welchen Aufwand verschiedene Operationen bedeuten. Das fördert übrigens auch die C-Code-Qualität, denn man kennt dann die Flaschenhälse.
foo schrieb: > Das hat ja mit C mal nichts zu tun. > > Wenn Du keine fertigen Libs verwendest, musst Du auch in C die Hardware > ganz genau kennen. Nein. Auch ohne Libs erleichtert C einige Dinge. Siehe: cyblord ---- schrieb: > Datentypen/Breiten, > Speicher (int/ext), Sprünge (near/far), Stack, FPUs, > Registernutzung/Sicherung.
cyblord ---- schrieb: > Nur die Peripherie die du explizit nutzt. Implizite hingegen nutzt du > auch Hardware, was du mit C aber eben nicht merkst, bzw. dir keine > Gedanken darum machen musst. Nämlich Dinge wie Datentypen/Breiten, > Speicher (int/ext), Sprünge (near/far), Stack, FPUs, > Registernutzung/Sicherung. > > Und genau diese Sachen sind die wirklich zeitraubenden und komplizierten > Dinge in Assembler. Das setzen von ein paar Bits in einem Register um > die UART zu konfigurieren interessieren doch niemanden, weder in C noch > in ASM. Mir ging es eher um SPI/Timer/UART/CAN/DMA/Flexray/etc. Diese Module und die richtige Verwendung erfordern schon eine Kenntnis der HW. Vor allem bei etwas größeren uC können die schon sehr komplex und umfangreich sein.
foo schrieb: > cyblord ---- schrieb: >> Nur die Peripherie die du explizit nutzt. Implizite hingegen nutzt du >> auch Hardware, was du mit C aber eben nicht merkst, bzw. dir keine >> Gedanken darum machen musst. Nämlich Dinge wie Datentypen/Breiten, >> Speicher (int/ext), Sprünge (near/far), Stack, FPUs, >> Registernutzung/Sicherung. >> >> Und genau diese Sachen sind die wirklich zeitraubenden und komplizierten >> Dinge in Assembler. Das setzen von ein paar Bits in einem Register um >> die UART zu konfigurieren interessieren doch niemanden, weder in C noch >> in ASM. > > Mir ging es eher um SPI/Timer/UART/CAN/DMA/Flexray/etc. Weiß ich, aber das ist zu kurz gedacht. Genau das will ich mit meinem Post ja sagen. Die Dinge im Hintergrund welche vereinfacht werden sollten nicht ausser Acht gelassen werden. Die sparen meist viel mehr Zeit. > Diese Module und die richtige Verwendung erfordern schon eine Kenntnis > der HW. > Vor allem bei etwas größeren uC können die schon sehr komplex und > umfangreich sein. Relativ. Wie gesagt, ein paar Bits in einem Register um ein paar Dinge zu konfigurieren. Egal obs jetzt 2 Optionen oder 50 Optionen sind, die ich bei einem Hardware-Modul einstellen kann. Das Prinzip bleibt gleich. Sowas kann man gut mit symbolischen Namen und Strukturen vereinfachen, siehe die StdLib bei STMs. Welche Vorteile können denn hier libs bieten? Welche Arbeit nehmen sie sonst ab? Der Anwender muss so oder so wissen, welche Optionen er bei welcher HW braucht. Interessant werden dann erst höhere Konzepte, z.B. einen FIFO den man auf den UART setzt, oder ein Netzwerkstack der auf dem Ethernet-Phy sitzt.
:
Bearbeitet durch User
cyblord ---- schrieb: > Relativ. Wie gesagt, ein paar Bits in einem Register um ein paar Dinge > zu konfigurieren. Egal obs jetzt 2 Optionen oder 50 Optionen sind, die > ich bei einem Hardware-Modul einstellen kann. Das Prinzip bleibt gleich. Deswegen muss man trotzdem verstehen was man setzt. Die Timer Unit bei meinem aktuellen uC hat 100 Seiten Beschreibung, 7 Betriebsarten, Master/Salve, Synchrones Starten etc... Und nicht immer gibt es Libs - oder man kann/darf sie nicht benutzen. > Interessant werden dann erst höhere Konzepte, z.B. einen FIFO den man > auf den UART setzt, oder ein Netzwerkstack der auf dem Ethernet-Phy > sitzt. Tja eine besserer uC hat dann schon FIFO etc im UART oder SPI Hardware. Wieder ein paar Bits in Registern die man richtig setzen/lesen muss.
foo schrieb: > Tja eine besserer uC hat dann schon FIFO etc im UART oder SPI Hardware. > Wieder ein paar Bits in Registern die man richtig setzen/lesen muss. Und trotzdem bringt dir das setzen deiner Bits nicht näher, wie ein uC funktioniert. wie gesagt als Beispiel für PIC: Work Register, Status Register. Nur zwei Beispiele, ohne welche so manch ein uC nicht funkionieren würde. Jemand der nur C Programmiert wird kaum wissen, dass es diese Register überhaupt gibt, geschweige denn was sie tun. In Assembler würde man ohne die beiden Register absolut nichts erreichen. Genau das meine ich mit Hardware nahe. Nur weil du ein paar Bits anhand eines Datenblatts setzen / löschen kannst, bringt es dir noch lange nicht den Aufbau eines uC's näher und schon erst recht nicht wie dieser Code abarbeitet.
:
Bearbeitet durch User
Patrick B. schrieb: > Kannst du drehen und wenden, wie du willst. Das Verwenden der Funktion > ist nunmal langsamer (selbst bei so einer einfachen Funktion). Ok, gut, > bei mir sind noch 2 weitere Operationen drin als bei dir, aber mit dem > direkten verwenden komme ich auf 2, anstelle von 3 bei dir. AHA, geht das inlinen bei dir doch :) Du schwindelst mich doch an mein guter. Ein MOV ersparst du dir weil R4 vorher schon beschrieben wurde. (mit SetBits...). R4 befüllt sich nicht von selbst, um die zwei Cycles kommst du nicht herum. mein Compiler macht das daraus
1 | 91: GPIOB->BSRR = GPIO_Pin_5; |
2 | 0x0800030C 4C36 LDR r4,[pc,#216] ; @0x080003E8 |
3 | 0x0800030E F8C48000 STR r8,[r4,#0x00] |
LDR sind auch zwei Cycles (pipeline refill fällt weg weil STR) Aber he: ich hätt auch bis zum letzten Ende gekämpft :)
cyblord ---- schrieb: >> Diese Module und die richtige Verwendung erfordern schon eine Kenntnis >> der HW. >> Vor allem bei etwas größeren uC können die schon sehr komplex und >> umfangreich sein. > Relativ. Wie gesagt, ein paar Bits in einem Register um ein paar Dinge > zu konfigurieren. Egal obs jetzt 2 Optionen oder 50 Optionen sind, die > ich bei einem Hardware-Modul einstellen kann. Das Prinzip bleibt gleich. Das macht schon einen Unterschied, ob die 2 Optionen zu einander passen müssen oder 50 (und du erstmal verstehen musst, wie die alle genau zusammenhängen). Oder anders: Es macht schon einen gewaltigen Unterschied, ob du einen simplen I/O-Pin ansteuern willst oder einen Ethernet-Controller mit DMA und einem halben Dutzend verschiedenen Interrupts.
Der LPC1549 könnte noch interessant sein für Quadcopter weil der Hardware Unterstützung für BLDC Motoren hat, gibts als LPCXpresso Board für knappe 30€. Oder steuert man die Motoren für Quadcopter heute lieber mit fertigen Modellbau Reglern an?
Kann der 4 BDLC Motore gleichzeitig steuern? Ich bin mir nicht sicher, ob es für die Genauigkeit der Motoransteuerung einen Vorteil bietet, diese in den uC zu integrieren. Ansonsten sehe ich fertig gekaufte Motortreiber eher als Vorteil: billiger wird man die kaum in sein eigenes Projekt integrieren können, und bei einem Defekt ist so nur ein Motortreiber-Modul zu wechseln. Gruß, Stefan
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.