Hallo an Alle, ich bin gerade auf der Suche nach einer neuen µC-Familie/Hersteller/Typ für anspruchsvollere Projekte. Bis jetzt habe ich ausschließlich mit atmega gearbeitet und war soweit damit zufrieden. Da in meinem neuen Projekt aber viel Rechnerei mit 16 bit Zahlen zu erwarten habe, bin ich mir unsicher ob ein 8 bitter da noch schnell genug sein wird. Zumal es eher recht zeitkritische Anwedungen sein werden. Meine Möglichkeiten die ich bis jetzt so sehe wären folgende: Atmel ATxmega Atmel AVR32 Atmel ARM ST ARM Die AVR32 sehe ich irgendwie auf einem toten Ast bei Atmel und fallen deshalb schon für mich raus. Die ATxmega hätten war höheren Takt aber wenn ich da eine 16 bit MUL 16 bit Operation veranstalte wird das vermutlich auch eine kleine Sauerei. Ich muss sagen das ich zu den Atmel ARM's tendiere. Und genau da wären meine Fragen angesiedelt: Kann ich die Atmel ARM's mit AVR Studio programmieren? Können sie noch mit SPI/PDI programmiert werden? Cortex-A5 hab ich schon gesehen wohl nur mit JTAG. Und welcher Typ wäre wofür geeignet Cortex-M3, Cortex-M4 oder Cortex-A5? Sehe ich das richtig, dass bei Cortex-A5 extra ein Flash-Baustein an den EBI dranmachen muss damit da überhaupt was läuft? Diese Fragen sind irgendwie trotz recherche immer noch offen geblieben. Danke schon mal für eure Mühen! MfG. Litos
Reich mal die Tuete und ein Glas rueber.... bis wir dann nach N posts herausfinden, dass im Wesentlichen nur Tasten abgefragt werden, plus ein LCD oder so. Zuerst daher : was soll's werden ?
:
Wiederhergestellt durch Admin
Püh, da gehe ich auch lieber schnell einkaufen :D Rumrechnen - STM32F4xx, mit Coprozessor. Billig, gute Verfügbarkeit, solide. Programmieren etwa über UART im Bootloader, also mit USB-zu-Seriell-Wandler. Oder per billigem ST-Link, billige Clone-Adapter schon ab 4 Euro inklusive Versand vom China-Händler zu bekommen.
Der Cortex-A ist eher für Betriebssysteme wie z.B. Linux gedacht und weniger als µC Anwendung. Der Cortex-M ist vergleichbar wie ein AVR oder ATxmega, nur dass er mehr Datenbits & Speicher hat und schneller ist. Da es nur um mehr Leistung ohne Betriebssystem geht ist der Cortex-A nicht zu empfehlen, wegen dem aufwändigeren Speicher (MMU). Lese mal dazu in diesem Artikel: STM32 für Einsteiger Darin sind verschiedene Hersteller auch verglichen. ST bietet mit der STM32 Reihe eine enorme Auswahl an µC mit Cortex-M CPU, ST ist eine der Firmen die die größte Auswahl an Cortex-M µC haben, daher ist die Wahl auf ST schon mal keine schlechte. In einem halben Jahr liefert ST auch den Cortex-M7 als Pinkompatiblen Chip zum STM32F4xx. Andere wie z.B. NXP bieten ebenfalls eine gute Auswahl und sollte man auch in betracht ziehen. Die meisten Softwareumgebungen wie z.B. Coocox unterstützen mehrere µC Hersteller, bei einer Cortex CPU ist man somit nicht Herstellergebunden.
@ Litos (Gast) >Projekt aber viel Rechnerei mit 16 bit Zahlen zu erwarten habe, Wieviel denn? > bin ich >mir unsicher ob ein 8 bitter da noch schnell genug sein wird. Das wird von den meisten Leuten unterschätzt bzw. ist die Programmierung der meisten Leute so schlecht, dass auch gute Hardware in die Knie geht. > Zumal es >eher recht zeitkritische Anwedungen sein werden. Beispiel? >Atmel ATxmega >Atmel AVR32 >Atmel ARM >ST ARM >deshalb schon für mich raus. Die ATxmega hätten war höheren Takt aber >wenn ich da eine 16 bit MUL 16 bit Operation veranstalte wird das >vermutlich auch eine kleine Sauerei. Bitte? Das macht der C-Compiler für dich. Ausserdem haben die Xmega nahezu die gleiche CPU wie die normalen AVRs. Bei gleichem Takt sind sie exakt gleich schnell. > Ich muss sagen das ich zu den Atmel >ARM's tendiere. Und genau da wären meine Fragen angesiedelt: >Kann ich die Atmel ARM's mit AVR Studio programmieren? Ja. >Können sie noch mit SPI/PDI programmiert werden? Keine Ahung, schau auf die Homepage. Ich tippe aber eher auf JTAG. >Sehe ich das richtig, dass bei Cortex-A5 extra ein Flash-Baustein an den >EBI dranmachen muss damit da überhaupt was läuft? >Diese Fragen sind irgendwie trotz recherche immer noch offen geblieben. Naja, wenn man nicht mal rausfindet, ob ein COntroller internen Flash hat oder nicht, dann will ich mal lieber nicht an deine anderen Fähigkeiten denken . . . 8-0
Die STM32F4 können schon was! Aber du müsstest schon etwas mehr Details rausrücken, denn > Zumal es eher recht zeitkritische Anwedungen sein werden. und > viel Rechnerei mit 16 bit Zahlen sind sehr subjektiv Ingo
:
Bearbeitet durch User
Also die Cortex A sind keine Mikrocontroller mehr sondern gehen eher in Richtung Prozessor. Die Cortex M dürften eher sein, was du brauchst. Ob du M0...4 brauchst, hängt von deinem Rechenleistungsbedarf ab. Bei Fließkomma sollte es wegen der FPU ein M4 sein. Wenn du Atmel Studio nutzen willst, bietet sich ein Atmel uC an. Guck einfach mal, welche von denen recht verbreitet sind. Vielleicht gibts auch gute Evalboards.
Litos schrieb: > Da in meinem neuen > Projekt aber viel Rechnerei mit 16 bit Zahlen zu erwarten habe, bin ich > mir unsicher ob ein 8 bitter da noch schnell genug sein wird. Zumal es > eher recht zeitkritische Anwedungen sein werden. Definiere "viel" und "zeitkritisch". Ich benutze häufig auf AVRs float und 64Bit integer ohne Probleme. Der AVR-GCC unterstützt leider kein double.
einen AVR mit einem Cortex M3 zu vergleich, ist das nicht fast wie einen trabant / Iseta mit golf, was die leistung angeht? Bei bergleich mit nem Cortex M4 würd ich fast sagen mit nem Porsche? M4 geht doch bis zu 180MHz? oder sogar drüber? und dann noch FPU. was schaft ein AVR? Und beim Cortex ist nicht JTAG die wahl sondern SWD. die meisten können auch JTAG. muss aber nicht sein. bzw kann per software sogar deaktiviert werden. ich würd jetzt mal sagen STM32F0?
Danke für die doch meist hilfreichen Beiträge. Ich hatte mich schon ein Wenig auf den AVR ARM eingeschossen und wollte die paar Punkte halt nochmal aus erster Hand wissen. Taktzyklus sollte unter 50ms sein, hat aber auch ein bischel zu tun: Kalmanfilter, diverse Integrationen aber so explizit kann man das noch nicht sagen. Doch zu Herrn Oberklug Falk: Falk Brunner schrieb: > Bitte? Das macht der C-Compiler für dich. Ausserdem haben die Xmega > nahezu die gleiche CPU wie die normalen AVRs. Bei gleichem Takt sind sie > exakt gleich schnell. 16 bit MUL 16 bit auf einer 32 bit ALU = 2 Befehle für das Register füllen und einen Befehl für MUL...fertig 16 bit MUL 16 bit auf einer 8 bit ALU = sehr viele Befehle, da mehr Register in anspruchgenommen werden müssen. Mehr Schieberei als Rechenen könnte man sagen. Und ja falk, das macht der C-Compiler. Und bitte Falk 20 MHz ist für dich fast 32 MHz. Falk Brunner schrieb: > Naja, wenn man nicht mal rausfindet, ob ein COntroller internen Flash > hat oder nicht, dann will ich mal lieber nicht an deine anderen > Fähigkeiten denken . . . 8-0 Tja, du hast deine Fähigkeit insofern in Frage gestellt, dass du über so einen Beitrag doch einfach hättest drüber wegschauen können und dich deinen so wichtigen und fachlich überragenden Themen hättest widmen können. MfG Litos
@Litos (Gast) Nach deinem Beitrag von 10.11.2014 13:31 denke ich, daß auch ein 16-Bit-uC zu deinen "anspruchsvolleren Projekten" nicht passen wird. Gruss
Litos schrieb: > Taktzyklus sollte unter 50ms sein Das sind auf nem AVR @ 20MHz 1 Million Takte, das ist ne Ewigkeit!!! Was spricht denn dagegen das mal auf nem AVR und nem Breadboard zu testen (die Rechnungen)? Das dürfte doch recht fix gehen. Mit nem IO und nem Oszi dann mal messen wie lange es wirklich dauert... Probieren geht manchmal über studieren.
123 schrieb: > was schaft ein AVR? Und das ist, wie immer, die falsche Frage! Richtig lautet es: - Was muss der AVR schaffen? - Wie groß ist der Entwicklungsaufwand? - braucht man die Leistung des ARM? - Wie sieht der Kosten-/Nutzenvergleich aus? Wenn man nur einen Temperatursensor alle 100ms auslesen will, reicht der AVR problemlos aus. Wenn man komplexe Vektoren berechnen will, macht sich ein mC mit FPU bezahlt. Jemand, der überall Stur einen 180MHz Arm benutzt, nur weil es preislich eh wenig unterschied macht, hat das Thema Microcontroller nicht verstanden. Bill Gates hat Milliarden auf der Bank - trotzdem wird er bei seiner Haussteuerung nicht überall Octacore-Xeons benutzen um nen Touchscreen zu steuern - obwohl es für ihn preilich kaum Unterschied macht. Es gibt keinen Glaubenskriege bei der Entwicklung - man sucht sich den besten Controller für die jeweilige Aufgabe aus.
:
Bearbeitet durch User
An Deiner Stelle würde ich zunächst versuchen, eine Abschätzung der Leistung der bisher verwendeten ATmega zu bekommen. Wenn die Leistung reichen sollte, wäre die Entwicklung sicherlich am einfachsten. Das haben ja auch schon Andere hier geschrieben. Gestern war hier eine Anfrage bezüglich eines STM32F334 zu finden, für den es auch ein kostengünstiges Discovery-Board gibt. Mit 32-64 pol. TQFP-Gehäuse, 12(+4)kB RAM und bis zu 64KB Flash ein kompakter Umstieg von ATmega auf deutlich mehr Rechenleistung. Die Besonderheit: der µC hat eine FPU auf dem Chip! http://de.futureelectronics.com/de/technologies/development-tools/development-tool-hardware/Seiten/7044984-STM32F3348-DISCO.aspx?IM=0 Wenn es 'mainstream' sein soll, dann macht man mit dem großen Bruder STM32F407 nichts verkehrt; den gibt es ab 64-pol. TQPF, sauschnell und im 100-pol. Gehäuse recht günstig: http://de.futureelectronics.com/de/technologies/semiconductors/microcontrollers/32-bit/Seiten/3012643-STM32F407VET6.aspx?IM=0 ABER: die Einarbeitungszeit ist nicht zu unterschätzen, auch wenn einige Zeitgenossen dies mit genialer Selbstdarstellung kleinzureden versuchen!
Ingo L. schrieb: > Das sind auf nem AVR @ 20MHz 1 Million Takte, das ist ne Ewigkeit!!! Nicht vergessen, es sollte schon auch Reserve eingeplant werden, so dass der µC nicht schon beim Testprogramm voll ausgelastet ist. wenn der die Berechnung in 10ms hin bekommt, so hätte man noch 40ms Reserve, falls man doch noch deutlich mehr rechnen müsste.
Markus Müller schrieb: > Nicht vergessen, es sollte schon auch Reserve eingeplant werden, so dass > der µC nicht schon beim Testprogramm voll ausgelastet ist. Ich zumindest unterschätze die Rechenleistung meist immer und freue mich dann das ich doch noch sooo viel Reserve habe...
@ Litos (Gast) >Taktzyklus sollte unter 50ms sein, hat aber auch ein bischel zu tun: >Kalmanfilter, diverse Integrationen aber so explizit kann man das noch >nicht sagen. Gelaber! Solche Aussagen kannst du dir sparen! Wenn dun nichtmal ANSATZWEISE abschätzen kann, wieviel Rechenleistung WIRKLICH gebraucht wird, ist jegliche Diskussion über einen Prozessor UNSINN!! https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Prinzipien_der_Optimierung >16 bit MUL 16 bit auf einer 8 bit ALU = sehr viele Befehle, da mehr WIEVIELE?!!!! Dein qualitatives Geplapper ist sinnlos. >Und bitte Falk 20 MHz ist für dich fast 32 MHz. Mit dem sinnerfassenden Lesen hast du es nicht so, oder? "Ausserdem haben die Xmega nahezu die gleiche CPU wie die normalen AVRs. Bei gleichem Takt sind sie exakt gleich schnell." Das hat mitnichten was mit deinem Gurkenvergleich von 20 Mhz zu 32 Mhz zu tun. Bei 32 MHz ist ein XMEGA doppelt so schnell wie ein normaler AVR bei 16 MHz oder, um bei der Kümelkackerei zu bleiben 1,6 Mal so schnell wie ein AVR @ 20 MHz.
Ruuuuuuhig, Falk! Es ist doch erst Montag Mittag ! <:-) Was war denn am Wochenende bei Dir los? ;-) @Litos: Ich würde auch vorschlagen, erstmal einen ATmega zu nehmen und darauf zu programmieren. Wenn Du in C schreibst, ist es bei einem eventuellen Engpass relativ einfach, z.B. zum STM32 zu wechseln. Aber erstmal würde ich schauen, ob das nicht mit einem AVR erschlagen werden kann. Die Einarbeitung in eine neue Prozessorfamilie dauert schon etwas.
:
Bearbeitet durch Moderator
Litos schrieb: > Hallo an Alle, > > ich bin gerade auf der Suche nach einer neuen µC-Familie/Hersteller/Typ > für anspruchsvollere Projekte. Bis jetzt habe ich ausschließlich mit > atmega gearbeitet und war soweit damit zufrieden. Da in meinem neuen > Projekt aber viel Rechnerei mit 16 bit Zahlen zu erwarten habe, bin ich > mir unsicher ob ein 8 bitter da noch schnell genug sein wird. Zumal es > eher recht zeitkritische Anwedungen sein werden. Meine Möglichkeiten die > ich bis jetzt so sehe wären folgende: > > Atmel ATxmega > Atmel AVR32 > Atmel ARM > ST ARM Du kannst auch einen dsPIC33EP (140 MHz/70 MOPS, 16 Bit mit DSP-Erweiterungen) oder einen PIC32MX (32 Bit 80 MHz/80 MOPS, MIPS-Kern) verwenden. Die gibts von klein (28 Pin DIL) bis 144 Pin TFQP/121 Pin FBGA. und sollten Dir genug "Spielraum" verschaffen. Zum Programmieren brauchst Du ein PICKIT3, das Du für 50€ als Original und für 20€ als China-Kopie bekommst. Damit kannst Du brennen UND Debuggen, so wie bei den AVRs über JTAG. IDE und Compiler gibts kostenlos von Microchip. fchk
@ Chris Ich werde mir deinen Rat mal zu Herzen nehmen und bei mega bleiben und dafür das Platinenlayout aber für 3.3V auslegen und etwas modularer gestalten. Dann kann ich ggf. immernoch mal wechseln. Danke dir und den Anderen. The Running Gag: Falk Brunner schrieb: > Gelaber! Solche Aussagen kannst du dir sparen! Wenn dun nichtmal > ANSATZWEISE abschätzen kann, wieviel Rechenleistung WIRKLICH gebraucht > wird, ist jegliche Diskussion über einen Prozessor UNSINN!! Das liegt einfach daran, dass man manchmal einfach nicht weiß was auf einen zukommt. Zum Beispiel muss ich das Signal der Sensoren wirklich nochmal Filtern oder eben nicht. Und meist kommt es immer anders als man denk und ja ich weiß bei dir ist das Anders. Falk Brunner schrieb: > Mit dem sinnerfassenden Lesen hast du es nicht so, oder? > > "Ausserdem haben die Xmega nahezu die gleiche CPU wie die normalen AVRs. > Bei gleichem Takt sind sie exakt gleich schnell." Ich glaube wir sprecheneinander vorbei oder meine Bewusstseinsebene scheint deiner nicht ebenbürtig zu sein. Ich sage, dass der xmega einen höheren Takt hat als ein mega. Und unter der Auffassung das die CPU-Architektur nahezu, wie du sagt, die Gleiche ist. Heißt das richtigerweise das "mehr" Takt mehr , nennen wir es, "funktionsorientierte" Operationen pro Zeit sind. So aber der Takt ist nicht gleich, daher mein 20 Mhz zu 32 Mhz Vergleich/Unterstelleung. Deine Umschalt-Taste klemmt manchmal. MfG Litos
Litos schrieb: > bei mega bleiben und > dafür das Platinenlayout aber für 3.3V auslegen ... und die max. Geschwindigkeit halbieren. Was soll das denn jetzt?
m.n. schrieb: > ... und die max. Geschwindigkeit halbieren. > Was soll das denn jetzt? mega auf 5V | Optokoppler | Peripherie 3.3V
Wobei der Xmega bei 3,3V höherer Taktfrequenzen unterstützt, als ein ATmega. Wenn Du einen Wechsel auf andere Controller möglichs einfach machen willst, dann würde ich alles mit 3,3V betreiben und mit einem Xmega anfangen.
Eher entscheidend als die Wahl der Familie ist mMn die gewünschte unterstützende Hardware rund um den Kern. Brauchst du z.B. einen integrierten LCD Controller, eine BLDC Engine, Quadratur Dekoder in Hardware, viele Ports, externes RAM, Ethernet PHY, viele UARTs usw. Das schränkt die grosse Auswahl ganz schnell auf ein paar Chips ein. Positiv bei den STM32 ist der geringe Preis, auch für die Eval Boards, und für die XMega spricht die geringere Einarbeitungszeit und z.B. eine AWEX oder UARTs bis der Arzt kommt. Übrigens kann m.W. jedes der STM32 Discovery Boards später auch als ST-Link Prgrammer arbeiten.
Falk Brunner schrieb: >>16 bit MUL 16 bit auf einer 8 bit ALU = sehr viele Befehle, da mehr > > WIEVIELE?!!!!
1 | int a = 0xfedb4561, b = 0x12345678; |
2 | long c = 0; |
3 | |
4 | c = ((long)a)*((long)b); |
5 | |
6 | |
7 | macht 85 zyklen auf einem mega128 |
Ich hab vor wenigen Wochen mit nem Stm32f429i discovery angefangen. War ein klarer fall von Selbstüberschätzung; war alles viel zu komplex. Und es gibt noch keine breite Nutzermasse, das lernt man auch erst zu schätzen, wenn man es nicht hat. Ich hab jetzt erstmal aus Fernost nen Arduino-Starterset *ja, schäm- da gabs aber beim 11. November Sale auf aliexpress 20% Rabatt druff* bestellt.
346623574 schrieb: > macht 85 zyklen auf einem mega128 da ist mir ein Fehler unterlaufen ;) es sind 128 Zyklen.
>Jemand, der überall Stur einen 180MHz Arm benutzt, nur weil es preislich >eh wenig unterschied macht, hat das Thema Microcontroller nicht >verstanden. Das siehst du falsch. Selbst wenn der nur ne LED blinken lassen soll wird der billigere genommen. Wenn die 180MHz CPU das für weniger Geld tut ist das doch ok;)
holger schrieb: > Das siehst du falsch. Selbst wenn der nur ne LED blinken lassen > soll wird der billigere genommen. Nö. Das Einfachere.
@Selbstüberschätzer: Mein STM32-Einstieg war mit dem F0-Discovery - nachdem ich drei Wochen vorher Warmmachübungen mit Arduino/avr-gcc in Eclipse gemacht hatte. Das ist kein schlechter Anfang, nur begrenzt einen der ATmega oft sehr. Die Lernkurve ist beim avr genauso steil wie beim stm. Der AliExpress-Sale findet in etwa 11 Stunden statt, also morgen früh ab 9 Uhr unserer Zeit. Die Kombination dieser beiden Aussagen von dir lässt mehrere Schlüsse zu. Möge die jeder selber ziehen.
:
Bearbeitet durch User
>> Das siehst du falsch. Selbst wenn der nur ne LED blinken lassen >> soll wird der billigere genommen. > >Nö. Das Einfachere. Falsch, das billigere. So ist das Leben. Da wird dir der Einkauf schnell nen Einlauf verpassen wenn du zu den ewig gestrigen gehörst. Und es ist keine Raketentechnik einen Cortex M0 zum laufen zu bringen.
holger schrieb: >>> Das siehst du falsch. Selbst wenn der nur ne LED blinken lassen >>> soll wird der billigere genommen. >> >>Nö. Das Einfachere. > > Da wird dir der Einkauf > schnell nen Einlauf verpassen Und Dir der Boss wenns Projekt nicht fertig wird. Merke: Simpel minimiert Aufwand & Fehlermöglichkeiten. Ingo L. schrieb: > Was spricht denn dagegen das mal auf nem AVR und nem Breadboard zu > testen (die Rechnungen)? Würde ich auch erst mal vorschlagen. Denn: Stefan us schrieb: > Wenn Du einen Wechsel auf andere Controller möglichs einfach > machen willst, dann würde ich alles mit 3,3V betreiben und mit einem > Xmega anfangen.
>> Da wird dir der Einkauf >> schnell nen Einlauf verpassen > >Und Dir der Boss wenns Projekt nicht fertig wird. >Merke: Simpel minimiert Aufwand & Fehlermöglichkeiten. An die ganze Welt vom grossen Moby: MERKE! Buhahahahaha;) Merkt euch das gefälligst bevor ihr mit Moby redet. Aber redet nicht bevor er euch dazu aufgefordert hat!
holger schrieb: >>> Da wird dir der Einkauf >>> schnell nen Einlauf verpassen >> >>Und Dir der Boss wenns Projekt nicht fertig wird. >>Merke: Simpel minimiert Aufwand & Fehlermöglichkeiten. > > An die ganze Welt vom grossen Moby: MERKE! > > Buhahahahaha;) > > Merkt euch das gefälligst bevor ihr mit Moby redet. > Aber redet nicht bevor er euch dazu aufgefordert hat! Schön gesagt Holger. Danke, so kann der Tag angenehm ausklingen. Bloß nicht noch irgendwelche echten Argumente...
Welchen µC sollte ich nehmen um 64 Bit Fliesskomma berechnen zu können? (ohne gleich mit dem sw double64 den Speicher zu 80% auszufüllen?)
Martin G. schrieb: > Welchen µC sollte ich nehmen um 64 Bit Fliesskomma berechnen zu können? Da würde ich als erstes fragen: wofür meinst du das zu brauchen?
>Schön gesagt Holger. Danke, so kann der Tag angenehm ausklingen. >Bloß nicht noch irgendwelche echten Argumente... Deine Argumente gehen doch schon ins esoterische und Bauernweisheiten. Heisse Luft, mehr nicht. Dich einfach zu ignorieren wird wohl das beste sein. Mach halt weiter, dann haben wir wenigstens ab und zu mal was zum lachen;)
holger schrieb: > Dich einfach zu ignorieren wird wohl das beste sein. Das schaffst - DU - nicht ... Und zieh mir die Bauernweisheiten nicht ins Lächerliche, da bin ich echt empfindlich ;-)
Schon wieder so ein komplett vergurkter Beitrag mit Inhaltslosen reden.
Litos schrieb: > Kalmanfilter, diverse Integrationen aber so explizit kann man das noch > nicht sagen. Kalman-Filter ist ein weites Feld. Das kann ein simpler Vierzeiler sein, i.e. der Rechenaufwand hängt sehr davon ab, was du rechnen möchtest. Und du weißt schon, dass Integrationen einfache Summationen sind?
Planeten- und Sonnenbahnberechnungen brauchen 64 bit double wenn man halbwegs genau sein möchte. Alle anständigen im Netz verfügbaren Algorythmen dieser Art nutzen Double (also 64 bit FLießkomma). Wenn man aber nun einen Soft Float benutzt, ist der Flash ja sofort voll mit dem Müll... HW FPU wäre da mir lieber.
Litos schrieb: > Atmel ATxmega > Atmel AVR32 > Atmel ARM > ST ARM Die NXP ARM sind hier leider nicht so populär, aber das spricht dafür: - alle Packages von DIP-8 bis LQFP-208 (hat weder Atmel noch ST) - einfache Programmierung der Register (Atmel ASF und ST Standard Peripheral Library sind komplex und RAM-hungrig, laufen auf kleinen Controllern gar nicht) - ROM-Treiber für USART, SPI, I2C, USB minimieren Fehler und sparen Flash
K.-B. schrieb: > Kalman-Filter ist ein weites Feld. Das kann ein simpler Vierzeiler sein, > i.e. der Rechenaufwand hängt sehr davon ab, was du rechnen möchtest. Das wird die Praxis zeigen was ich brauche und was nicht. Ich habe halt nur lieber zu viel Reserven als zu wenig ;). K.-B. schrieb: > Und du weißt schon, dass Integrationen einfache Summationen sind? Ja, wobei Summationen nicht immer das einfachste/sinnvollste sind. Bei mir ist er eher x MUL y + v MUL w + s MUL t + ....
Lothar schrieb: > - einfache Programmierung der Register (Atmel ASF und ST Standard > Peripheral Library sind komplex und RAM-hungrig, laufen auf kleinen > Controllern gar nicht) Wenn du so eine Aufzählung glaubwürdig machen willst, solltest du bei den Fakten bleiben. ST Standard Peripheral Lib läuft auf dem kleinsten STM32, den ich kenne, problemlos: STM32F030 im TSSOP20-Gehäuse. Sie führt zu erhöhter Flash-Auslastung, bläht das Programm im Vergleich zu direkter Registermanipulation auf, ja. Anhand des Datenblattes kannst du aber genau wie bei allen anderen µCs direkt mit Registern arbeiten; du stellst es dar, als ginge das nicht. Das liest sich viel mehr wie: Zu NXP kannste nicht mal eine vereinfachende Klassenbibliothek bekommen.
:
Bearbeitet durch User
Martin G. schrieb: > Planeten- und Sonnenbahnberechnungen brauchen 64 bit double wenn man > halbwegs genau sein möchte. Die Frage ist auch, wozu das auf einem Mikrocontroller laufen soll. Wenn du damit dann ein Teleskop steuern willst, nützen dir 64bit double gar nichts, weil die Mechanik gar nicht zu solcher Genauigkeit fähig ist. Macht man also doch lieber auf dem Notebook, was sowieso auf dem Beobachtungsplatz dabei ist. Oder man überlässt es der Mathlib eines embedded Linux Rechners. Selbst die Rosetta Sonde wird von der Erde aus gesteuert und braucht keine 64 bit double an Bord.
Martin G. schrieb: > Welchen µC sollte ich nehmen um 64 Bit Fliesskomma berechnen zu können? > (ohne gleich mit dem sw double64 den Speicher zu 80% auszufüllen?) Ich weiß ja nicht, wie Du auf imaginäre 80% kommst. Selbst auf einem ATmega gehen double Berechnungen speicherschonend und zügig. Ein Beispielprogramm mit einem GPS-stabilisierten Frequenzzähler bleibt bei < 4KB und kann mit einer IAR Kickstart-Version übersetzt werden. http://www.mino-elektronik.de/fmeter/fm_software.htm#bsp2 Auf einem STM32F4xx sieht die Situation noch viel besser aus. Ein paar Zahlen finden sich hier: Beitrag "Re: Controller mit FPU" Martin G. schrieb: > HW FPU wäre da mir lieber. HW FPU findest Du auf Renesas Controllern. Spontan fällt mir da der SH7216 ein.
Martin G. schrieb: > Welchen µC sollte ich nehmen um 64 Bit Fliesskomma berechnen zu können? > (ohne gleich mit dem sw double64 den Speicher zu 80% auszufüllen?) Einen µC mit Cortex-M7 Kern. Gibt es in einem STM32F7xx leider erst in einem halben Jahr. Die Entwicklung kannst Du dennoch mit einem Pinkompatiblen STM32F4xx starten. Ob andere µC Hersteller auch den Cortex-M7 so schnell in einen Chip bekommen weiß ich jetzt nicht. Atmel hat sowas auch geplant.
Markus Müller schrieb: > Einen µC mit Cortex-M7 Kern. > Gibt es in einem STM32F7xx leider erst in einem halben Jahr. Ich fürchte, Du kennst nur STM32 µCs und der Tellerrand ist zu hoch ;-) Genau so könnte ich sagen, nimm einen ATtiny85 im 8-pol. DIL.
Ich befürchte, der Cortex-M7 hat eine FPv5 enthalten, die doppelte Genauigkeit unterstützt. Ich befürchte auch, du hast überlesen, dass mein Beitrag die Antwort auf "Martin G." war.
Markus Müller schrieb: > Ich befürchte, der Cortex-M7 hat eine FPv5 enthalten, die doppelte > Genauigkeit unterstützt. Na und? Die Renesas-Teile sind schon ein paar Jahre alt und sofort verfügbar. Es bleibt aber immer noch die Frage, welche Leistung überhaupt notwendig ist. So kann der Ruf nach Cortex-M7 zwar sehr laut sein, aber auch auf die Ohren gehen ;-) > Ich befürchte auch, du hast überlesen, dass mein Beitrag die Antwort auf > "Martin G." war. Keine Angst, so senil bin ich noch nicht. Und das 'Markus Müller' ein strikter Kämpfer für STM32 ist, zuweilen auch ein bißchen penetrant, ist mir auch nicht entgangen.
In letzter Zeit schreibe ich nicht sooo arg viel. Nur da wo es auch Sinn machen könnte. Ich bin ja kein Moby. Ich zeige die Möglichkeiten und Links wonach sich jeder selbst eine Meinung bilden kann. Was schlussendlich für den Fragestellenden die beste Möglichkeit ist, kann ich nicht entscheiden, da ich wohl niemals alle Umstände erfahren werden. Litos hat explizit nach einem "ST ARM" gefragt! Außerdem hat sich Litos schon lange für einen XMega entschieden: Beitrag "Re: Welchen µC-Typ für neues Projekt?" Was für seine Problemlösung wohl das Beste ist, und ich finde das ist auch OK. Oder habe ich danach noch irgend was anderes gegen einen XMega geschrieben? Ich bin ein Kämpfer für die beste Lösung, mit Vorzugstyp STM32. Ich kann mich auch nicht erinnern den Renesas oder NXP schlecht geschrieben zu haben. @Mods: Ihr könnt den Thread jetzt auch dicht machen. Litos ist geholfen und ansonsten gibt es eh keine neuen Infos die Litos helfen würden.
:
Bearbeitet durch User
Martin G. schrieb: > Planeten- und Sonnenbahnberechnungen brauchen 64 bit double wenn man > halbwegs genau sein möchte. Alle anständigen im Netz verfügbaren > Algorythmen dieser Art nutzen Double (also 64 bit FLießkomma). > Wenn man aber nun einen Soft Float benutzt, ist der Flash ja sofort voll > mit dem Müll... HW FPU wäre da mir lieber. Nimm Dir einen BeagleBone Black. Die Cortex A haben alle die NEON VFP Einheit, und die kann double. Wenn Du was kleineres haben willst: Atmel SAMA5 mit Cortex A5. fchk
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.