Hallo Leute, Ich möchte einen großen Hexapod bauen und suche dafür einen schnellen µC. Mein letzter Hexa lief mit zwei ATmega644 (20MHz) und war trotz heftiger optimierung zu 60-70% ausgelastet. Dieses mal möchte ich noch deutlich anspruchsvollere Bewegungen berwerkstelligen und weniger auf Optimierung achten um Zeit zu Sparen und den Code leserlicher zu machen. Dazu brauche ich einen besseren µC. Da ich mich aber bisher nur mit AVRs auskenne, frage ich lieber nach =) Der Controller sollte recht mächtig sein! Um etwas präziser zu werden: - Sehr gerne fpu - mehr als 60MHz - 32bit Architektur - mehrere 16bit Timer - mit C programmierbar - Freier Compiler und Debugger - Umfangreiches Tutorial oder Buch sollte vorhanden und beschaffbar sein. - Preis unter 300Euro Ich hab schon an ARMs gedacht, aber ich hab noch nie mit welchen gearbeitet und kenne mich damit also kein bisschen mit aus. Außerdem solls da nicht so viele von mit einer fpu geben. Fpu ist aber schon wichtig, weil ich dieses mal mit doubles rechnen will (nein, es ist nicht oversized... und ja, ich brauche diese Genauigkeit...) und allgemein auch gerne mal mit einer fpu arbeiten möchte. Ich danke schonmal im Voraus für Tips! Gruß, Yaro
>- Sehr gerne fpu Unsinn. >- Umfangreiches Tutorial oder Buch sollte vorhanden und beschaffbar >sein. Abgelehnt;) >Ich hab schon an ARMs gedacht, Die richtige Richtung. >Außerdem solls da nicht so viele von mit einer fpu geben. Macht nichts. >Fpu ist aber schon wichtig, Nö. >und allgemein auch gerne mal mit einer fpu arbeiten möchte. Ich würde auch gerne mal mit einem Porsche zur Arbeit fahren. Aber eigentlich reicht auch ein Polo.
Hoi Schau mal in Richtung ADUC702x oder ADUC706x schauen. Hat zwar glaub ich keine FPU aber genug Performance für nen Hexa. Für den 7026er gibts ein nettes Tutorial Die haben sogar ein PLA eingebaut. Lukas
Yaro schrieb: > - Sehr gerne fpu Das gibts sicher im ARM9, ARM11 Bereich was. > - mehr als 60MHz Hat jeder 32bitter (jaja, ich weiss, kuriose Ausnahmen gibt's immer... > - 32bit Architektur z.B ARM Cortex-M3, ARM9, ARM11 > - mehrere 16bit Timer Hat auch jeder 32Bitter. > - mit C programmierbar Ist auch jeder. > - Freier Compiler und Debugger Gibt's auch für jeden. --> GCC > - Umfangreiches Tutorial oder Buch sollte vorhanden und beschaffbar > sein. Dafür gibt's das Internet > - Preis unter 300Euro Im Fall eines Cortex solltest Du mit ca. 10 Euro rechnen. ARM9/11 sind ein bisschen, aber nicht viel teurer. Für 100 Euro kriegst Du ein Board mit RAM, Flash etc schon drauf. Gruäss Simon
Wow....das ist zu viel auf einmal =) erstmal zu Markus Müller: hab den Artikel durchgelesen. Scheint ein interessanter Controller zusein, aber eine fpu ist (sofern ich es nicht übersehen habe) nicht drin. Der Rest sieht meinen Anforderungen entsprechend aus. Nur hat mich noch etwas gestört, dass die Open-Source Alternative (libopenstm32) für die Peripherie noch in Entwicklung ist. @holger: Wenn du dir einen Firmenwagen aussuchen dürftest, würdest du immer noch den Polo nehmen? @Lukas: Kennst du zufällig eine Übersichtstabelle mit denen? @Simon Huwyler: Wo könnt ich mich genauer über ARM11 informieren? Wo gibts gute Eval-Boards? Gruß, Yaro
Schau mal auf www.cutedigi.com. Da gibt's ein ARM11-Board mit allem Drum und dran für 100$. Und ein Eval dazu für 250$. Gruäss Simon
Hobby: Cortex-M3 / ARM7 Beruf: ARM9/ARM11 (weil teuer, weil Multilayer usw.) Ja der STM32 hat keine FPU drin, allerdings rechnet der sehr schnell. Am besten mal ein kleines Demo-Board kommen lassen und einen Test programmieren, kostet nicht viel.
Markus Müller schrieb: > Beruf: ARM9/ARM11 (weil teuer, weil Multilayer usw.) Ausser eben Du nimmst so ein Board, auf dem alles schon drauf ist. Kein Eval-Board, sonder ein Subsystem. Die sind 'ne feine Sache und gar nicht so teuer. Die eigene HW kann man dann auf 'nem Mutterbrett mit 2-4 Lagen "selber basteln".
Yaro schrieb: > @Cyclon: FPGA ist etwas oversized =) ..und soweit ich weiß kann man die auch nicht in C programmieren. (oder kann man schon C-code ordentlich synthetisieren?)
typ schrieb: > ..und soweit ich weiß kann man die auch nicht in C programmieren. Wahrscheinlich war FPGA+Softcore gemeint. Edit: Nicht nur wahrscheinlich, steht ja sogar mit dabei. :)
... oder aber ein FPGA mit Hardcore. Z.B. Smart Fusion von Actel. Die haben 'nen Cortex-M3 drin und jede Menge Zellen, mit denen jede Menge Pulspattern für jede Menge Servos für jede Menge Beine synthetisiert werden können. (oder aber ein separates FPGA dafür. Ich kenne mich mit Hexawieheissendienochmal? Hexapods nicht aus, aber was ich auf Youtube gesehen habe, sieht a)cool, b) nach was mit viel so parallel laufendem Zeug aus. Ich sähe da durchaus Möglichkeiten, wie ein FPGA den Prozi unterstützen könnte.
@Simon Huwyler: Ich hab da grad mal nachgeschaut. Ich möchte zwar viel Power haben, aber das ist schon deutlich zu viel! Damit könnte ich ja 10 Hexapoden gleichzeitig steuern =) @Markus Müller: Hab mir grad den Cortex-M3 angeschaut. Sieht ebenso sehr gut aus! Mit 100MHz brauche ich dann nicht wirklich eine fpu (auch wenn cih gerne mal eine auprobieren würde) STM32 und Cortex-M3. Welche Vorteile hat ARM9 gegenüber den beiden anderen? Was ist leichter zum Unstieg von 8-bit AVR?
Also erstmal: STM32 IST ein Cortex-M3. Ein ARM9 ist einfach ein grösseres Kaliber. Hat üblicherweise MMU, (Cortex-M3 in einigen Fällen auch, aber seltener), und ist generell für "Grösseres" ausgelegt. Den solltest Du eigentlich nur mit einem Betriebssystem à la embedded Linux einsetzen. So wie ich das einschätze, bist Du mit einem M3 super bedient. Das kann STM32, NXP oder sonstwas sein. Der Umstieg von 8-Bittern ist definitiv viiiiiiel leichter im Fall Cortex-M3. A propos Betriebssystem: Hast Du schon eins? Ansonsten kann ich Dir FreeRTOS ans Herz legen. Linux bringst Du in 'nen STM32 nicht rein.
@Simon Huwyler: Kennst du vielleich auch ein gutes ARM9 Board? @Daniel: Sind die auch schnell genug? @Stephan: Um ehrlich zu sein, kenn ich mich mit FPGA+Softcore kein bisschen aus. Mit FPGAs wollte ich mich aber noch nicht beschäftigen, das kommt in einem Jahr oder so. Will erstmal den Unstieg auf 32bit machen. Des Prog für den Hexa geht auch ohne FPGA, und was die Servos angeht, so werde ich wahrscheinlich sowieso nicht die Standart-Servos verwenden, die man über PWM anspricht sondern welche die mit RS-485 angesprochen werden. Gruß, Yaro
Auch wenn dies eine vielleicht nicht ganz korrekte Pauschalaussage ist: Der entscheidende Unterschied beim ARM9 zu seinen ARM7-ähnlichen Gegenstücken (STM32, Cortex) ist seine MMU (Memory Management Unit). Die braucht man, um ein vollwertiges Linux laufen zu lassen. Wer lieber ohne Betriebssystem programmiert, profitiert vom ARM9 gar nicht so viel - mal von den mehr MHz abgesehen.
Yaro schrieb: > @Simon Huwyler: Kennst du vielleich auch ein gutes ARM9 Board? Ob's gut ist, weiss ich erst, wenn ich's habe, bestellt ist es schon. :-) Auch auf cutedigi.com. Da gibt's eins für 120$. Aber eben, ARM9 halte ich nicht unbedingt für eine gute Wahl. Das ist mehr was, wenn Du was mit graphischen Oberflächen machst und/oder Linux o.ä. machst. Was Du vorhast, sieht mir wie eine klassische uC-Geschichte aus. Und dazu sind die Cortex-M3 bestens geeignet.
Wow... Das mit dem Betriebssystem kommt schon etwas überraschend. Ich hab zwar schon oft gehört, dass Leute auf ihre µC ein Betriebssystem drauf machen, aber ich habe nie gewusst, wozu das wirklich gut ist =) Brauche ich unbedingt eins? Eigentlich wollte ich den Controller direkt ansprechen. Brauche genaue Timings und Genaue Zeiten, in denen Meine Funktionen ausgeführt werden können. Wird mir da ein Betriebssystem nicht einen Strich durch die Rechnung machen? Tut mir Leid, wenn ich blöde Fragen Stelle, aber ich habe mich bischer nur mit den 8-bit AVRs befasst. Dort zwar mit vielen verschiedenen, aber eben nur 8bit AVR...
Stefan L. schrieb: > typ schrieb: >> ..und soweit ich weiß kann man die auch nicht in C programmieren. > > Wahrscheinlich war FPGA+Softcore gemeint. > > Edit: > Nicht nur wahrscheinlich, steht ja sogar mit dabei. :) so so, softcore... kannte ich noch garnicht... erscheint mir aber auch vom Preis/Leistungsverhältnis nicht wirklich sinnvoll. laut artikel: >Nachteile: > > * Geringere Geschwindigkeit als Hard Cores
Du kannst dir auch mal die C2000 Reihe von TI anschauen. Das sind Mikrocontroller mit DSP Kern laufen mit bis zu 300 MHz sind aber ein bischen anspruchsvoller was die Programmierung angeht.
Im Artikel STM32 sind viele Hersteller von Demo-Boards aufgelistet. Diese lieferan meist auch ARM9 Demo-Boards. http://www.mikrocontroller.net/articles/STM32#Evaluation_Boards
Ich hab nochmal nachgeschaut... ARM9 ist für mich im Moment wohl wirklich noch etwas zu groß... Die Aufgaben, die ich verrichten will, werde ich auch mit deutlich weniger Power schaffen... und eigentlich will ich auch ohne Betriebssystem auskommen =)
PIC32 :) Ist pro MHz schneller als Cortex-M3, hat viel Flash und RAM. Compiler ist kostenlos. Softcore im FPGA ist kompliziert und langsam. Hardcore ist zu viel und teuer. Um mit FPGAs überhaupt klar zu kommen, brauchst du schon paar Jährchen ;) Grüße, Anguel
Also, für die Arbeit ohne Betriebssystem ist der ARM9 nicht so reizvoll. Komplexe Hardware bedeutet viel Initialisierung, und man wird die Ressourcen kaum ausschöpfen. Falls sich die Bestellung noch ändern läßt: STM32 oder Cortex-M3 machen mehr Freude, wenn man direkt auf Hardwareebene arbeitet.
@Nich angemeldeter User: Hört sich feige an, aber wenn sie anspruchsvoller sind, dann nehme ich erstmal den cortex-m =) ... alles mit der Ruhe
Yaro schrieb: >..und eigentlich > will ich auch ohne Betriebssystem auskommen =) wenn du nen 8bit AVR hast dann kuck dir doch mal http://www.femtoos.org/ an, das ist ein Echtzeit-Betriebssystem [RTOS] läuft ohne herum basteln sofort auf so ziemlich allen AVRs und die Funktionen sind sehr gut online dokumentiert.
Von den ADUC'S gibts folgende 702x 712x Schau einfach bei analog.com rein da gibt für jeden Chip ne kurze Übersicht was er kann. Meiner Meinung nach würde ein 7026er reichen 44Mhz 32Bit 12Bit IO Hört sich nicht besonders viel an aber aus eigener Erfahrung weiß ich das die ordentlich Dampf unter der Haube haben und mit dem PLA kann mann echt viel anstellen. Lukas
Betriebssysteme müssen nicht unbedingt riesige Dinos mit 1000 Layern zwischen Anwendungsprogramm und Hardware sein. Im Fall von FreeRTOS reichen Dir wenige kB Flash und ganz wenig RAM. Und Timings kriegst Du genau so gut in den Griff, wie wenn Du den Controller "direkt" ansprichst. Resp. Du SPRICHST ihn immernoch direkt an. Wozu also ist ein Betriebssystem? Ich spreche jetzt nur von FreeRTOS. Das ist nämlich "nur" ein Scheduler. Der macht im Wesentlichen nichts weiter als verschiedene Tasks pseudoparallel laufen zu lassen. Das tut er, indem er sich von einem Timer periodisch ankicken lässt. Z.B. im Millisekunden-Takt. Kannst aber selber einstellen. Jedesmal, wenn er so gekickt wird, entscheidet er, welcher Task jetzt weiterlaufen kann. Ausserdem kannst Du, gesteuert durch Interrupts, FreeRTOS jederzeit dazu bringen, soche Taskwechsel durchzuführen. Oder aber die ganz pressanten Dinge gleich selber in ISRs ausführen. Das war jetzt alles recht schwammig, ich weiss. Auf freertos.org gibt's gute Lektüre dazu. Quintessenz ist aber: Mit einem RTOS bist Du genau so präzise und schnell, wie wenn Du "direkt programmierst". Aber es macht Dir viiiiieles viiiiel einfacher.
Yaro schrieb: > Wow... Das mit dem Betriebssystem kommt schon etwas überraschend. Ich > hab zwar schon oft gehört, dass Leute auf ihre µC ein Betriebssystem > drauf machen, aber ich habe nie gewusst, wozu das wirklich gut ist =) > Brauche ich unbedingt eins? > Eigentlich wollte ich den Controller direkt ansprechen. Brauche genaue > Timings und Genaue Zeiten, in denen Meine Funktionen ausgeführt werden > können. Wird mir da ein Betriebssystem nicht einen Strich durch die > Rechnung machen? Deswegen wurde ja weiter oben FreeRTOS vorgeschlagen. Das bedeutet ausgeschrieben Free Realtime Operating System. Wenn du damit nix anfängst: http://de.wikipedia.org/wiki/Echtzeitbetriebssystem Ich hab in letzter Zeit ein wenig mit dem FreeRTOS gebastel und muss sagen: bei größeren Projekten nie mehr ohne!
@Anguel S: von PICs habe ich nciht wirklich gutes gehört... Die 16bit PICs sollen von der Leistung mit den 8bit AVRs vergleichbar sein... Aber wenn PIC32 schneller ist als cortex-m... warum nicht... Die Programmierung sollte bei den beiden ähnlich sein, oder? @Sebastian: Dann wird der ARM9 schonmal von der liste gestrichen Ehm... "STM32 oder Cortex-M3".... ist das nicht das selbe (sagt Simon Huwyler). Im Moment sind also PIC32 AVR32 und Cortex-M/STM32 im Spiel. Ist das jetzt nur noch Geschmackssache, oder gibts gute Gründe für den einen oder anderen?
Yaro schrieb: > @Anguel S: von PICs habe ich nciht wirklich gutes gehört... Die 16bit > PICs sollen von der Leistung mit den 8bit AVRs vergleichbar sein... > Aber wenn PIC32 schneller ist als cortex-m... warum nicht... > Die Programmierung sollte bei den beiden ähnlich sein, oder? PIC32 hat MIPS Core und ist ganz anders als die alten. Programmiert wird er in C (MPLAB Compiler ist eigentlich ein GCC Compiler). Man muss natürlich dann die Lib-Funktionen lernen, aber das ist wohl überall so. Vielleicht sind die Entwicklungsumbegungen für ARM von Keil und IAR besser als das kostenlose MPLAB, kosten aber mal eben um die 4000 EUR. Um keinen falschen Eindruck zu hinterlassen - ich habe den PIC bisher nicht benutzt, aber vergleiche selbst in der letzten Zeit, was man so als alternativen hat. Sonst ist der neue Cortex-M4 von Freescale auch ganz nett und hat DSP Funktionen, ist aber eben ganz neu und evtl. etwas teurer...
Ich werde mich über FreeRTOS auf jeden Fall informieren. Aber eigentlich kann ich mir noch nciht vorstellen, dass das für mich besser ist. Ich meine, ob ich nun die Programmteile, die ich ausführen muss nach einander oder pseudo-parallel ausführe kann mir ja völlig egal sein... Aber naja, ich werde mich auf jeden Fall da mal schlau machen!
- Die CPU selber ist auch egal, aber die eingebaute Pheriperie der Hersteller sollte man schon genauer anschauen. Und da bietet ST mit dem STM32 sehr viele Chips mit unterschiedlicher Ausbaustufe/Gehäuse usw. Von TI gibt es einen mit eingebauter PHY, falls Netzwerk interessiert. - Software ist kostenlos - JTAG-Interface kostet was, die sind zu den 3 Ausgewählten nicht kompatiebel. Dann: - Demo-Boards / Kosten - Was gibt es im Internet? (dieses Forum hat viel STM32) Ich nutze am liebsten STM32 und habe den schätzen gelernt. ST bietet eine gute FW-Lib mit über 90 Beispielprojekten und alles Dokumentiert, alles in einem Download. Nicht vergessen: Errata's lesen.
Markus Müller schrieb: > - Software ist kostenlos Die Compiler meistens nicht, es sei denn man ist in der Lage, sich alles mühevoll zusammenzubasteln. > Dann: > - Demo-Boards / Kosten Genau - gibt es überhaupt Boards, die in deinen Pod passen. > Nicht vergessen: > Errata's lesen. Besser nicht, sonst kauft man am Ende nix ;)
Uh... der cortex-m4 hat sogar ne fpu... Da der aber ganz neu ist, gibts wohl keinen so großen pool an Erfahrungen damit... da greife ich aus Sicherheitsgründen wohl doch eher auf den m3 zurück. Nochmal um das klarzustellen... Für PIC32 gibt es einen kostenlosen Compiler und Entwicklungsumgebung (beides nicht sehr gut), für cortex-m gibt es auch was mit openSource... aber was die Qualität angeht weiß ich nix..
Aus Markus Müller und Anguel S. folgt: lieber STM32. Richtig? Darum dass das Board nicht in den Hexa passt, mache ich mir eine Gedanken... Er wird richtig groß werden =)
Ein freier Compiler und Entwicklungsumgebung sind für mich wichtig. Werd das auf mehreren PCs in der Firma brauchen...
Yaro schrieb: > @Anguel S: von PICs habe ich nciht wirklich gutes gehört... Die 16bit > PICs sollen von der Leistung mit den 8bit AVRs vergleichbar sein... > Aber wenn PIC32 schneller ist als cortex-m... warum nicht... > Die Programmierung sollte bei den beiden ähnlich sein, oder? JA, hören tut man viel - nur stimmt es meist nicht. Gerade in etwas AVR lastigen Foren ist PIC Bashing von Leuten ohne Hintergrundwissen ein beliebter Sport. Der Pendant zu den AVR sind die Pics der 16F / 18F Reihe. Wobei diejeniegen Bausteine die Leistungsmäßig im Bereich der ATMEGAS liegen eher im 18F Sektor zu finden sind. (Aber alles 8Bit.) Einige davon stecken die ATMEGAS auch in die Tasche. Die 16Bit Pics (sind welten über 8Bit AVR) > @Sebastian: Dann wird der ARM9 schonmal von der liste gestrichen > Ehm... "STM32 oder Cortex-M3".... ist das nicht das selbe (sagt Simon > Huwyler). JAIN Cortex M3 ist die Prozessorachitektur, also der eigendliche Kern. Stsark verwandt mit dem ARM7 Der STM32 ist ein Produkt eines Herstellers das einen solchen Kern hat. Andere HErsteller verwenden aber auch denselben Kern, aber andere Peripherie (daher nur sehr sehr eingeschränkt kompatibel - ein STM32 lässt sich nicht einfach durch einen NXP C-M3 ersetzen. Da sind sowohl in der Harware wie auch in der SW teilweise erhebliche Anpassungen möglich. > > > Im Moment sind also PIC32 AVR32 und Cortex-M/STM32 im Spiel. > Ist das jetzt nur noch Geschmackssache, oder gibts gute Gründe für den > einen oder anderen? Der PIC32 ist eigendlich das Gegenstück zu den Cortex M3. Der Pic32 hat einen MIPS kern. Das ist neben den ARM die zweite große Prozessorarchitektur. Was nun besser ist - das ist eine Glaubensfrage ähnlich wie PIC oder AVR. Funktioniert beides. Und auch der WEchsel von PIC32 MIPS auf STM32 CortexM3 ist nicht komplizierter als der WEchsel von STM32 CortexM3 auf NXP CortexM3. Der Vorteil bei den PIC ist das man bei Microchip einen HErsteller hat der sehr umfangreiche und gut funktionierende LIBs von sich aus zur Verfügung stellt. Man kann alsoe wenn man will alles aus einer HAnd bekommen und muss nicht alles zusammensuchen mit den Nachteilen wei verschiedene nicht genau zuordbare Versionsstände durch parallele Weiterentwicklung usw... Wenn man natürlich gerne OpenSorce oder DrittanbieterSW einsetzt, die gibt es natürlich auch - Nur etwas weniger als bei ARM- halt da die Notwendigkeit nicht ganz so groß ist. (Wer schreibt etwas wenn der HErsteller das schon hat) Aber wie Gesagt: PIC32 und CortexM3 (egal welcher Hersteller) sind an sich gleichwertig. Entscheide was dir am besten erscheint (Preis, Verfügbarkeit, Dev. Tools usw.) AVR32 ist eine absolute Eigenentwicklung von Atmel und spielt im Verlgeich zu den Technologien wie ARM und MIPS keine echte Rolle. Würde ich mich nicht unbedingt als erstes mit beschäftigen. Zuma Atmel ja nun gerade bei spezielleren Bausteinen nicht gerade für gute Verfügbarkeit bekannt ist! Gruß Carsten
Yaro schrieb: > Aus Markus Müller und Anguel S. folgt: lieber STM32. Richtig? ST hat wohl hier viele Fans. Ich mag aber die Boards nicht wirklich. Und ST hat seine Seite so kaputtgemacht, dass man da nix mehr findet.
Yaro schrieb: > "STM32 oder Cortex-M3".... ist das nicht das selbe (sagt Simon > Huwyler). ARM ist eine Firma, die Prozessor IPs an Lizenznehmer verkauft. Die stellen aber selber keine Prozis her. ST, NXP, Atmel etc. kaufen bei ARM diese IPs ein, packen Peripherie drumherum und verkaufen die dann. Wenn Du also einen STM32 kaufst, gibst Du Geld an ST, und die geben einen Teil davon an ARM ab. Das coole an der Sache ist nun, dass, egal, ob Du ein NXP, ST oder Atmel-Teil kaufst, immer der selbe Prozi drin ist. Eben ein ARM Cortex-M3. Also: Gleiche Befehle, gleiches Programmer's Model, gleiche Grundperipherie (wie z. B. ein sog. Tick-Timer, an dem eben dann das Betriebssystem hängt. Somit läuft das Betriebstsystem unverändert auf allen Cortex-M3. Natürlich kannst Du alles ohne Betriebssystem machen. Du kannst auch mit Paintbrush eine Platine zeichnen und mit einem einfachen Texteditor Programme schreiben. Aber es ist halt mühsam. Du wirst Dich zwangsläufig mit Scheduling auseinandersetzen müssen. Denn Du hast ja sicher Dinge, die parallel laufem müssen. 8 (edit: nö, 6, hexa, hiess es ja) Beine wollen gesteuert werden. Die RS232 wartet auf Konsolen-Eingaben. Irgendwo blinkt eine LED. Die Batteriespannung soll überwacht werden.... Natürlich kannst Du das alles hintereinander machen. Ganz schnell einer Endlosschlaufe, so dass es nach aussen aussieht, als ob die Spinne alle Beine gleichzeitig bewegen kann. Sowas nennt man dann Event-Loop. Ein RTOS macht eigentlich genau das. Aber es macht es auf eine Weise, die (das ist nicht böse gemeint) von vielen sehr schlauen Leuten sehr genau durchdacht wurde und Möglichkeiten eröffnet, die Du Dir (wiederum nicht böse gemeint) wohl nicht träumen lässt. Es ist übrigens nicht einfacher, mit einem RTOS zu programmieren, was das Erlernen angeht. Eher im Gegenteil. ABER: Sobald das Projekt ein bisschen grösser wird, hast Du eine Werkzeugkiste in der Hand, die Du nicht mehr hergeben willst. Und das - das muss ich nochmals betonen - ohne irgendein Penalty! Eben, wir sprechen hier nicht von Windows, das - auf einem Cortex-M3 laufend, eine Trillion Jahre bräuchte, um ein Fenster zu öffnen! :-)
Yaro schrieb: > Für PIC32 gibt es einen kostenlosen > Compiler und Entwicklungsumgebung (beides nicht sehr gut), Wie kommst du darauf das die nicht gut sind. Die Entwicklungsumgebung (MPLAB) finde ich einwandfrei, wobei das auch geschmackssache sein kann. Der Compiler ist in der Freien Version nicht mit den maximalen Optimierungsoptionen ausgestattet. Aber ansonsten ist der in Ordnung. Und wenn man den gewerblich mit maximaler Performance braucht dann sind die 900Eur. im Vergleich zu anderen komerziellen Compiler ein echtes Schnäppchen ;-). Wenn man den braucht, dann ist man aber in REgionen wo ein paar Cent unterschied Bauteilkosten zwichen zwei Speichergrößen in der Serienproduktion über die Stückzahl eine Rolle spielt. Aber wie gesagt: Auch mit dem M3 machst du nichts verkehrt. Gruß Carsten
Carsten Sch. schrieb: > Aber wie Gesagt: PIC32 und CortexM3 (egal welcher Hersteller) sind an > sich gleichwertig. Entscheide was dir am besten erscheint (Preis, > Verfügbarkeit, Dev. Tools usw.) Also ein Nachteil von der Microchip Entwicklungsumgebung MPLAB ist, dass sie mal gerne öfters abstürzt. Das ist einfach so. Dafür ist es komplett kostenlos. Alles hat seinen Preis, wobei ich noch nie mit ner 4000 EUR Umgebung gearbeitet habe. Ob die richtig stabil läuft, müssen andere sagen.
Ersteinmal vielen vielen Dank für die vielen Tips! Ob STM32 oder PIC32 werde ich mich noch schlau machen, jetzt habe ich wenigstens eine eingeschränkte Auswahl. Zum Einstieg (umstieg) scheint mir PIC32 leichter zu sein, weil eben de angepriesene Lib. Was Boards angeht, werd ich auch nochmal schlau machen müssen... Wie sieht es denn hier im Forum aus? Was wird präferiert?
Anguel S. schrieb: > Dafür ist es komplett > kostenlos. Alles hat seinen Preis, wobei ich noch nie mit ner 4000 EUR > Umgebung gearbeitet habe. Ob die richtig stabil läuft, müssen andere > sagen. Eclipse, CDT, GCC, OpenOCD Alles konstenlos. Qualitativ ist dieses Gespann top. Und es ist "state-of-the-art". Richtig, mann muss ein bisschen Zeit investieren, um es zum Laufen zu bringen. Dabei lernt man aber wiederum sehr viel. Für den professionellen Einsatz ist das ein Killerkriterium, weshalb auch viele Firmen ein genau solches Päckchen fertig zusammenstellen und für viel Geld verkaufen. Im Hobbybereich aber macht es m.E. keinen Sinn, irgendwas kommerzielles zu kaufen. Ich habe mit einer 4000 EUR Umgebung gearbeitet. So gross ist der Unterschied nicht.
Carsten Sch. schrieb: >> Im Moment sind also PIC32 AVR32 und Cortex-M/STM32 im Spiel. >> Ist das jetzt nur noch Geschmackssache, oder gibts gute Gründe für den >> einen oder anderen? > > Der PIC32 ist eigendlich das Gegenstück zu den Cortex M3. Der Pic32 hat > einen MIPS kern. Das ist neben den ARM die zweite große > Prozessorarchitektur. Was nun besser ist - das ist eine Glaubensfrage > ähnlich wie PIC oder AVR. Funktioniert beides. > Und auch der WEchsel von PIC32 MIPS auf STM32 CortexM3 ist nicht > komplizierter als der WEchsel von STM32 CortexM3 auf NXP CortexM3. > Der Vorteil bei den PIC ist das man bei Microchip einen HErsteller hat > der sehr umfangreiche und gut funktionierende LIBs von sich aus zur > Verfügung stellt. Man kann alsoe wenn man will alles aus einer HAnd > bekommen und muss nicht alles zusammensuchen mit den Nachteilen wei > verschiedene nicht genau zuordbare Versionsstände durch parallele > Weiterentwicklung usw... Dem kann ich nur zustimmen. Ich habe alle Architekturen bereits in den Fingern gehabt, ARM (7,9,M3), PIC*, AVR*, PPC, 68k,... Der CPU-Kern wird immer mehr zur Nebensache. Viel wichtiger ist die Peripherie und die Softwareunterstützung. Und speziell als Anfänger hast Du bei Microchip einfach die besseren Karten. Du nimmst die MPLAB IDE, den C32 Compiler, dazu einen ICD3 Debugger und ein Demoboard Deiner Wahl, und Du wirst das ganze Zeugs innerhalb eines Tages am Laufen haben. Garantiert. Klar, Du kannst auch irgendeinen GCC-Port nehmen, irgendein OpenOCD mit irgendeinem JTAG-Pod, dazu ein Eclipse oder Code::Blocks, und wieder woanders her irgendeinen IP-Stack. Kannst Du machen, kein Thema. Aber ohne entsprechende Erfahrung nicht an einem Tag. Schon bei der Inbetriebnahme des OpenOCD mit dem Billig-JTAG, den Du irgendwo im Netz geschossen hast, kann der einer oder andere Tag bei draufgehen. Und die Portierung des von irgendwoher gesaugten IP-Stacks an Deinen speziellen Controller geht auch nicht von selbst. Natürlich ist das alles machbar. Das haben andere vor Dir auch geschafft. Aber als Anfänger ist es beschwerlich. Du kannst Dir natürlich auch zB bei rowley.co.uk ein Crossworks for ARM und einen dazu passenden JTAG kaufen. Dann hast Du diese Probleme natürlich nicht. Aber kostenlos ist das dann auch nicht mehr. Von daher bist Du eigentlich mit dem PIC32 ganz gut bedient. fchk
Das ausschlaggebende Kriterium ist also wohl der Compiler und Entwicklungsumgebung. Eclipse, CDT, GCC, OpenOCD ist als Ersatz von MPLAB oder als Paket für STM32 gemeint?
Ein Betriebssystem braucht man, um komplexe software die man nicht selbst schreiben will laufenzulassen. Fuer sicherheitsrelevant Projekte moeglicherweise eher nicht. Oder moeglicherweise eher doch.
Also PIC32 mit MPLAB IDE, den C32 Compiler, dazu einen ICD3 Debugger und ein Demoboard meiner Wahl =) Also nur noch einen passenden PIC32 und ein dazu passendes Board aussuchen =) Ein passender wäre z.b. der PIC32MX575F512H.... kennt ihr ein gutes Board dafür?
Yaro schrieb: > Das ausschlaggebende Kriterium ist also wohl der Compiler und > Entwicklungsumgebung. > > > > Eclipse, CDT, GCC, OpenOCD ist als Ersatz von MPLAB oder als Paket für > STM32 gemeint? Eclipse=IDE CDT=C Development für Eclipse GCC ist der Compiler, der Microchip C32 ist auch ein GCC OpenOCD ist der Treiber für den JTAG-Debugger, das Bindeglied zwischen dem GDB (Gnu Debugger) und der Hardware. Der GDB ist Kommandozeile, und Elipse setzt sich da drauf. Nicht unbedingt die eleganteste Architektur. Das obige entspricht beim PIC32 dem MPLAB plus dem C32 Compiler. Der Debugger ist im MPLAB drin. fchk
Yaro schrieb: > Eclipse, CDT, GCC, OpenOCD ist als Ersatz von MPLAB oder als Paket für > STM32 gemeint? Dieses Paket ist für so ziemlich alles, was sich programmieren lässt, gemacht. Mit GCC wurde z.B. Linux programmiert. Und wohl so ziemlich alles, was unter Linux läuft. Und es ist ganz klar die vielfältigste Compiler-Kollektion, die es gibt. Aber eben: Es ist nicht plug'n'play. Eclipse ist eine IDE, die ebenfalls extrem verbreitet ist. Auch open-source. Und so bekannt/beliebt, dass viele Firmen diese IDE nehmen, in ihr Paket integrieren und dann in der Werbung extra erwähnen, dass ihre IDE "eclipse-based" ist. Quasi als Garant dafür, dass sie was taugt. Wenn Du PICs programmieren willst, ist MPLAB natürlich die bessere Wahl (ich weiss gar nicht, ob die PICs zu den wenigen Prozis gehören, die GCC nicht unterstützt). Auf jeden Fall ist in MPLAB wohl alles genau so zusammengebaut, dass es einfach läuft.
Dann nehm ich für den Anfang MPLAB, weil es den Eintieg erleichtert, obwohl ich mir sowieso noch Eclipse (aber für c++ am PC) holen werde.
Yaro schrieb: > Also PIC32 mit MPLAB IDE, den C32 Compiler, dazu einen ICD3 Debugger und > ein Demoboard meiner Wahl =) > > Also nur noch einen passenden PIC32 und ein dazu passendes Board > aussuchen =) > > Ein passender wäre z.b. der PIC32MX575F512H.... kennt ihr ein gutes > Board dafür? Microchip DM320004 plus DM320002 IO-Expansion Board plus AC164126 für Deine eigene Peripherie. Schau es Dir auf der Microchip-Seite an. Hab ich hier auch liegen. fchk
Jetzt fehlt nur noch das richtige Board mit dem Richtigen PIC32. Was die Pins angeht, so reichen mir 64 höchstwahrscheinlich aus. MHz sollten es 80 sein. Flash mind. 256kb. Sram reicht wohl schon 16kb locker aus. Und gerne mehrere Schnittstellen. Was muss ein gutes Board haben, außer dass die Pins nach außen geführt sind?
Yaro schrieb: > Jetzt fehlt nur noch das richtige Board mit dem Richtigen PIC32. Hast Du doch schon. Siehe oben: DM320004. Da ist zwar ein größerer PIC drauf, aber das soll Dich nicht stören. > Was die Pins angeht, so reichen mir 64 höchstwahrscheinlich aus. MHz > sollten es 80 sein. Flash mind. 256kb. Sram reicht wohl schon 16kb > locker aus. Und gerne mehrere Schnittstellen. Was anderes als 80 MHz gibts nicht. Faustregel fürs Entwickeln: den größen Baustein nehmen, entwickeln, und dann schauen, in welchen kleineren das Projekt reinpasst. > Was muss ein gutes Board haben, außer dass die Pins nach außen geführt > sind? Die richtige Peripherie. Oder möglichst gar keine, damit möglichst alle benötigten Pins zur eigenen Verwendung frei sind. Ansonsten hast Du nämlich ein Problem. Das Board hat Ethernet und USB onboard, was auch sinnvoll ist. Alles andere bastelst Du Dir auf einem PICTAIL+ Board AC164126 zusammen. fchk
Frank K. hat gepostet, als ich grad geschrieben hab und die seite noch nciht aktuallisiert war... Ich werd mir die Boards anschauen. Vielen vielen Dank an alle für die Hilfe!
Damit's auch sicher wird ;-) Cortex-R4F in Form der TMS570 von TI (die hätten eine FPU, 1-2MiB Flash, 128 -160 kiB SRAM beide mit ECC, 160 MHz): http://focus.ti.com/docs/toolsw/folders/print/tmdx570ls20susb.html http://www.ti.com/ww/en/mcu/tms570/index.shtml Ansonsten würde ich aber auch einen PIC32 oder dsPIC empfehlen (MPLAB X basiert auf der NetBeans-IDE, falls man die "eigenwilligen" Vorversionen nicht will)
Hi, Anguel S. schrieb: > Also ein Nachteil von der Microchip Entwicklungsumgebung MPLAB ist, dass > sie mal gerne öfters abstürzt. Das ist einfach so. DAs kann ich jetzt absolut nicht bestätigen. Was ich ALLE PAAR Tage mal habe ist das die Kommunikation zwischen MPLAB und dem PicKit aus irgendwelchen Gründen aussteigt. Anscheinend forciert wenn es sowieso schon mit der Kommunikation aufgrund der Schaltung (Nutzung der ICSP Pins auch für Funktionen) etwas wackelig ist. Meist schaft aber schon ein einfaches Abziehen und nach einigen Sekunden wieder neu anstecken des PicKit abhilfe. Ab und an war aber auch mal ein Abspeicher der Arbeit und Neustart des Programms (NICHT des Rechner) nötig. Einen richtigen Absturz ohne die Möglichkeit des Abspeicherns hatte ich schon Monatelang nicht mehr bei MPLAB. Da die Programme ja eh bei jedem Übersetzen gespeichert werden hält sich aber auch in so einen Fall der Ärger in grenzen ;-) Das mit den Abstürzen schein also am jeweiligen System zu liegen - wie fast bei aller Software. Yaro schrieb: > Zum Einstieg (umstieg) scheint mir PIC32 leichter zu sein, weil eben de > angepriesene Lib. Ja, würde ich auch so sehen - für den ersten Einstieg bist du bei Microchip etwas besser bedient. Gerade weil es sehr viel mehr -aus einer HAnd- gibt. Oft incl. Anfängerfreundlicher Doku. Für den STM32 gibt es auch Libs von ST. Allerdings muss ich -insbesonder im Moment- sagen das es ein echter Krampf ist auf deren Seite nach der richtigen Lib zu suchen. Zur Krönung kommt noch dazu das ich seit DREI MONATEN dabei bin zu versuchen eine laut Pressemitteilung kostenlos erhältliche Audio Lib zu erhalten. -ICh habe mich schon quer durch die Niederlassung hier in DL UND Genf telefoniert. Auch habe ich es über einen Distri versucht. Auc gab es einen Emailaustausch mit NAchfragen was ich genau brauche den ich mit Link auf deren eigene Webseite beantwortet habe. Es scheint keiner was zu wissen!!! Für eine Anfänger ist das sicher noch deutlich frustrierender! Soetwas habe ich bei Microchip noch nicht mal Ansatzweise erlebt. Wenn dann wirklich mal keiner die Antwort greifbar hatte habe ich zumindest innerhalb von 48h eine Rückmeldung bekommen. Natürlich gibt es auch noch freie Libs für den STM32 von der Web-Community. Vieleicht sogar mehr als beim PIC32. Aber wie schon von anderen geschrieben ist der Aufwand das zusammenzusuchen und seine eigene Konfiguration zum laufen zu bekommen deutlich höher. > Wie sieht es denn hier im Forum aus? Was wird präferiert? Hier im Forum liegen die Präferenzen allerdings eher bei den AVR (8Bit) und ARM im 32 Bit Sektor. Zumindest schreien deren Anhänger (insbesondere AVR) am lautesten. Aber es gibt auch eine Menge PIC kenner hier. Nur die wirklich PIC lastigen Foren sind andere. Hier noch zwei Dinge von mir: Oben wird der ICD3 als Tool Empfohlen. Das ist definitiv ein gutes Gerät und wenn es auf die (nicht zu viel) Euros nicht ankommt würde ich den auch nehmen. (selber habe ich "nur den ICD2) Wenn du etwas sparen willst funktioniert aber auch der PicKit3 der nur wenig mehr Einschränkungen hat. Den nutze ich für die neueren Bausteine und ich muss sagen der ist echt Robust: Verpolt, Kurschluss, Überspannung (über 12V durch die Schaltung!) und was weiß ich habe ich dem Ding schon zugemutet. Funktioniert immer noch wie am ersten Tag. Und das bei einem Tool mit Debug funktionalität für 30Eur! (Wenn ich mir da anschaue was ATmel für seine AVR bietet... Entweder schweineteuer (JTAGICE MKII) mit dem ungefähr das möglich ist was mit dem PicKit3 möglich ist, oder derart superempfindlich das es beim kleinsten Fehler stirbt (DRAGON - Forensuche!) Als zweites: SPÄTER wenn du mit den Pic32 zurecht kommst würde ich mir aber die ARM zumindest auch mal anschauen. (wenn du mit ARM einsteigen würdest käme die Empfehlung umgekehrt). Das sind halt die beiden großen Architekturen und aus eigener Erfahrung weiß ich -gerade wenn du andere Projekte nachbauen willst oder Teile davon als Ausgangsbasis für eigene Ideen nutzen willst, wird dieses Projekt genau auf der von dir nicht Präferierten TEchnologie basieren. Meist ist es aber leichter sich dann damit abzufinden anstelle das mühsam zu portieren. Halt wegen der Peripherie. Der eigendliche Programmcode hat ja nicht die Unterschiede, das verdecken die Compiler schon ganz ordentlich! Für die STM32 gib es mit dem STLink auch einen günstigen JTAG Adapter (ca. 25Eur), Oder falls es eine private Anwendung ist auch das universellere (merh asl nur STM32) Segger J-Link EDU für ca. 60Eur. Der ST-Link kann ja nur die ST Bausteine 8Bit/32Bit Gruß Carsten
Hallo Yaro, mit dem PIC32 setzt Du ziemlich auf einen Nischenprozessor, sorry die PIC-Fans werden mich gleich zerreissen, jedoch ist mir zumindest in Europa kein anderer MIPS basierter µC bekannt. Bei den ARM's, ob Cortex-M3 oder ARM7, setzt Du auf eine viel breitere Basis. Schau mal dieses an: http://focus.ti.com/docs/toolsw/folders/print/eks-lm3s1968.html Ist relative preiswert, alle IO's auf PinLeiste rausgefuehrt und hat schon einen JTAG Programmer on Board, den man auch fuer eigene Projekte nutzen kann und die Software Libs von TI (ex Luminary Micro) koennen es mit den von ST sicher aufnehmen. Ob man das ccs tool (eclipse basiert) mag, muss jeder selbst entscheiden, ich habe keine grosses Problem damit. Die TI cortex-M3 haben gegenueber den anderen cortex Anbietern die Eigenart, das meist nur zwei verschiedene Funktionen pro Pin moeglich sind. Ob das ein Vorteil ist oder nicht muss jeder fuer sich entscheiden. Um jedoch mal mit dem weiter oben genannten Vorurteil aufzuraeumen, Softcores in FPGA's sehe ich nicht, als viel komplizierter an als simple µC. Man muss ja nicht die SC der Chiphersteller mit Ihren Entwicklungsumgebungen nehmen, unter Opencores gibt es zum Bsp. genuegend Alternativen. Damit kann dann der FPGA seinen entscheiden Vorteil ausspielen: Wenn es mal zeitlich eng wird fuer den µC, kann man leichter dedizierte Hardware an den Softcore anbinden um den µC zu entlasten. Dieses kann sogar soweit gehen, das man extra Befehle für den Zugriff auf diese im Softcore definiert. Schneller geht es dann nicht wirklich mehr. LG ein bastler
Bin jetzt keines falls der Profi, aber ich glaube, dass es ziemlich egal ist welcher Prozessor da verbaut ist. In C merkt man da nicht wirklich den Unterschied bzw. ist es kein großer Aufwand sich in einen anderen Core einzuarbeiten. Da sehe ich eher bei der Peripherie mehr Aufwand. Und die Peripherie ist bei den ARMs sowieso von Hersteller zu Hersteller komplett anders. Also bin ich der Meinung, dass es egal ist ob man jetzt den PIC32 oder einen ARM nimmt. Beim PIC32 kann man sich auch sicher sein, dass der auch noch in einigen Jahren erhältlich ist und falls nicht, ist meist ein pinkompatibler besserer Typ vorhanden. Mfg Kroko
Hi, bastler schrieb: > Hallo Yaro, > > mit dem PIC32 setzt Du ziemlich auf einen Nischenprozessor, sorry die > PIC-Fans werden mich gleich zerreissen, jedoch ist mir zumindest in > Europa kein anderer MIPS basierter µC bekannt. Das liegt aber dann eher an deinem Wissensstand als an der tatsächlichen Verfügbarkeit! DA gibt es schon einiges - Die Tage hatte ich einen von TI in der Hand... Was richtig ist, das ist die Tatsache das es weniger "General Purpose" Prozessoren wie bei den ARM gibt. An "Bastler- Einstiegsmaterial" kenne ich auch nur den PIC32 aus dem Eff Eff. Die anderen sind eher im High End sektor zu finden: Zitat Wikipedia > MIPS-Prozessoren werden auch häufig in eingebetteten Systemen eingesetzt. > Dazu zählen z. B. Cisco-Router, Suns Cobalt-Server bis RaQ/Qube2, BMW > Navigationssysteme, die Fritz!Box, Satellitenreceiver, Dreambox, Konica > Minolta DSLRs und Sony- und Nintendo-Spielkonsolen. Oder bei Heise: http://www.heise.de/ct/artikel/Prozessorgefluester-1102725.html bastler schrieb: > Bei den ARM's, ob Cortex-M3 oder ARM7, setzt Du auf eine viel breitere > Basis. Das halte ich für einen Fehlglauben - denn ich kann diesem hier nur 100% Zustimmen: Stefan R. schrieb: > ... aber ich glaube, dass es ziemlich egal > ist welcher Prozessor da verbaut ist. In C merkt man da nicht wirklich > den Unterschied bzw. ist es kein großer Aufwand sich in einen anderen > Core einzuarbeiten. Da sehe ich eher bei der Peripherie mehr Aufwand. Insbesondere da folgendes Gilt: > Und die Peripherie ist bei den ARMs sowieso von Hersteller zu Hersteller > komplett anders. Also bin ich der Meinung, dass es egal ist ob man jetzt > den PIC32 oder einen ARM nimmt. Es spielt vom Aufwand her ABSOLUT KEINE ROLLE ob ich jetzt von einem STM32 Cortex-M3 auf einen NXP Cortex M3 wechsle, oder ob ich von einem PIC32 zu einem STM32 wechsle (und umgekehrt!) Der Kern spielt fr mich keine Rolle - ich muss sowohl das Pinning wie auch die meisten Lib-Zugriffe ändern. Und der Teil der zwischen allen ARM Plattformen beliebig austauschbar ist kann bei einem Wechsel zwischen MIPS und ARM genauso stehen bleiben. Daher nützt mit die breitere Basis an Hobbyprozessoren bei ARM ÜBERHAUPT NICHTS! Wenn mein ausgewählter Hersteller nicht liefern kann oder die Produktion gar einstellt kann ich trotzdem nicht einfach ausweichen. Ich muss Software und HArdware trotzdem ändern. Das ist ein Argument das stammt noch aus den Zeiten als Assembler die alleinige Sprache der µC war die Prozessoren mit gleichen Kern auch nahezu identisch im Pinning waren - von Periepherie "ON Chip" war da ja noch gar keine Rede... Dazu kommt noch das man -wie geschrieben- mit Microchip einen HErsteller hat der sich (mit ausnahme einer MAssenabkündigung bei Ausgründung ´89) in den letzten 20 Jahren als sehr zuverlässig herausgestellt hat. Vollständige Abkündigungen gab es fast nicht - Und die wenigen die es gab hatten einen 100% kompatiblen Nachfolgetyp der mit einer Programmänderung im Rahmen von 5min Aufwand problemlos anstelle der ursprünglichen Verbaut werden kann. Zudem hat dieser Hersteller viele Einsteigerinformationen einigermaßen gut ausfbereitet zentral bei sich auf den Seiten abrufbar. Das hast du in der Qualität bei den ARM (noch?) nicht. GRuß Carsten
Carsten Sch. schrieb: > Das mit den Abstürzen schein also am jeweiligen System zu liegen - wie > fast bei aller Software. Bei mir stürzt MPLAB komischerweise meist dann ab, wenn ich die Hilfe anschaue :) > Ja, würde ich auch so sehen - für den ersten Einstieg bist du bei > Microchip etwas besser bedient. Gerade weil es sehr viel mehr -aus einer > HAnd- gibt. Oft incl. Anfängerfreundlicher Doku. Naja, bei deren neuem Multimedia Expansion Board hält sich die Doku leider sehr in Grenzen :( > Für den STM32 gibt es auch Libs von ST. Allerdings muss ich -insbesonder > im Moment- sagen das es ein echter Krampf ist auf deren Seite nach der > richtigen Lib zu suchen. Ich kaufe nix von einem großen Hersteller, der so blöd ist, seine Seite so zu verunstalten. > Zur Krönung kommt noch dazu das ich seit DREI MONATEN dabei bin zu > versuchen eine laut Pressemitteilung kostenlos erhältliche Audio Lib zu > erhalten. Solche Sachen wundern mich nicht mehr. Wenn es um Hard- oder Software geht, können sich Hersteller anscheinend alles erlauben. > Soetwas habe ich bei Microchip noch nicht mal Ansatzweise erlebt. Wenn > dann wirklich mal keiner die Antwort greifbar hatte habe ich zumindest > innerhalb von 48h eine Rückmeldung bekommen. Da bin ich jetzt gespannt, wenn die mir meine Frage zum Multimedia Board beantworten, sind sie echt gut. Ich bezweifele es allerdings... > Nur die wirklich PIC lastigen Foren sind andere. Kannst Du da was anderes als das Microchip-Forum empfehlen? Da wird einem nicht wirklich gut geholfen :( > Halt wegen der > Peripherie. Der eigendliche Programmcode hat ja nicht die Unterschiede, > das verdecken die Compiler schon ganz ordentlich! Genau, und bei der Peripherie sind die Libs von ARM zu ARM sehr unterschiedlich. Grüße, Anguel
bastler schrieb: > Bei den ARM's, ob Cortex-M3 oder ARM7, setzt Du auf eine viel breitere > Basis. Und was hat man davon? Der Core spielt wie oben schon gesagt fast keine Rolle. Und MIPS ist kein schlechter Core. Außerdem steht Microchip zu seinen Produkten und ist eine sehr reiche Firma. Ob da Luminary/TI besser sind, wage ich zu bezweifeln. > Ob man das ccs tool (eclipse basiert) mag, muss jeder selbst > entscheiden, ich habe keine grosses Problem damit. Das hat definitiv weniger Nutzer als MPLAB. > Um jedoch mal mit dem weiter oben genannten Vorurteil aufzuraeumen, > Softcores in FPGA's sehe ich nicht, als viel komplizierter an als simple > µC. Da lese ich in dem FPGA Forum hier von den Profis andere Sachen bzgl. Xilinx EDK und auch bzgl.Performance. Da lautet das Motto eher - Hard wenn nur möglich. > Man muss ja nicht die SC der Chiphersteller mit Ihren > Entwicklungsumgebungen nehmen, unter Opencores gibt es zum Bsp. > genuegend Alternativen. Damit kann dann der FPGA seinen entscheiden > Vorteil ausspielen: Wenn es mal zeitlich eng wird fuer den µC, kann man > leichter dedizierte Hardware an den Softcore anbinden um den µC zu > entlasten. Ach was - und mit welchem Aufwand das ganze? FPGAs muss man doch erstmal in- und auswendig kennen, um mit OpenCores überhaupt was anfangen zu können. > Dieses kann sogar soweit gehen, das man extra Befehle für den Zugriff > auf diese im Softcore definiert. Schneller geht es dann nicht wirklich > mehr. Ja möglich ist im Prinzip alles. Ich bau mir mal eben meinen eigenen Cortex-M5. Sorry, aber solche Aussagen verwirren die Anfänger komplett. Welcher Softcore kann den von der Performance her z.B. mit Cortex-M3 mithalten? Mit welchem FPGA? Und was kostet er Spaß dann?
Yaro schrieb: > Ich möchte einen großen Hexapod bauen und suche dafür einen schnellen > µC. Hier ist übrigens ein PIC32 Hexapod, der sogar malen kann;) http://www.youtube.com/watch?v=01vDzLksecc Grüße, Anguel
Hallo Anguel, also rein Leistungsmaessig kann zum Bsp. ein microblaze (hier v7.2) locker mit der cortex-m3 architekture mithalten (1.30DMIPS/MHz zu 1.2.5DMIPS/MHz) Dabei kann selbst auf den "Spar"-FPGAs (spartan) eine core Frequenz von 100MHz ohne groessere Probleme erreicht werden und das auch auf billigen Digilent Ausbildungs-Boards. Einzig im Punkt DMIPS/mw muessen sie sich geschlagen geben, aber das ist ja auch ein Vergleich von Birnen mit Äpfeln (besser noch Eiern). Die Breite Basis der ARM hilft sicher nur bedingt bei der Einarbeitung in ein Derivat eines anderen ARM-Herstellers, da meist leider auch andere Peripherie. Jedoch kann die Entwicklungskette konstant bleiben (armgcc). Selbst beim "Sprung" von ARM7TDMI (NXP LPC2294) auf Cortex-M3 (TI LM3S6965) konnte ich die Kette beibehalten. Die obengenannten Wikipedia Beispiele zu MIPS getriebenen Geraeten, setzen alle keine allgemeinen µC ein, sondern meist spezielle SoC's. Aber die sind ja hier nicht das Thema gerade. LG ein bastler
Falls Du noch in der Evaluation steckst habe ich auch noch einen Kandidaten: Renesas RX600 Serie: http://www.renesas.com/products/mpumcu/rx/rx600/rx600_landing.jsp Die sollten Deine gestellten Anforderungen erfüllen. FPU vorhanden, gehen bis 100MHz, bis 2MB flash, 128kB RAM, ... Als kostenlose Entwicklungsumgebung kannst Du die KPIT GNU Tools nehmen: http://www.kpitgnutools.com/
bastler schrieb: > also rein Leistungsmaessig kann zum Bsp. ein microblaze (hier v7.2) > locker mit der cortex-m3 architekture mithalten (1.30DMIPS/MHz zu > 1.2.5DMIPS/MHz) > > Dabei kann selbst auf den "Spar"-FPGAs (spartan) eine core Frequenz von > 100MHz ohne groessere Probleme erreicht werden und das auch auf billigen > Digilent Ausbildungs-Boards. Hört sich interessant an :) Aber der Aufwand für einen Anfänger ist schon groß :( > Jedoch kann die Entwicklungskette konstant bleiben > (armgcc). Ich dachte, dass der nicht so gut optimiert wie Keil und IAR. Wie sind deine Erfahrungen? > Die obengenannten Wikipedia Beispiele zu MIPS getriebenen Geraeten, > setzen alle keine allgemeinen µC ein, sondern meist spezielle SoC's. Ich glaube auch, dass viele der MIPS-Beispiele eher in Richtung 64 bit gehen. Grüße, Anguel
Johnny B. schrieb: > Falls Du noch in der Evaluation steckst habe ich auch noch einen > Kandidaten: > > Renesas RX600 Serie: Wie sieht es mit Libraries, Evalboards und Kosten aus?
Anguel S. schrieb: > Johnny B. schrieb: >> Falls Du noch in der Evaluation steckst habe ich auch noch einen >> Kandidaten: >> >> Renesas RX600 Serie: > > Wie sieht es mit Libraries, Evalboards und Kosten aus? Der Chip an sich sollte rel. günstig sein. Habe beim RX610 mal Zahlen um die EUR 5...6.- gehört. Evalboards gibts z.B. von Glyn: http://www.glyn.de/content_xl.asp?wdid=2376 http://www.glyn.de/content_xl.asp?wdid=2489 Wie es mit (kostenlosen) Libraries aussieht weiss ich leider nicht. Jedoch wahrscheinlich nicht sonderlich viele.
Johnny B. schrieb: > Wie es mit (kostenlosen) Libraries aussieht weiss ich leider nicht. > Jedoch wahrscheinlich nicht sonderlich viele. "Um die Softwareentwicklung zu erleichtern, gibt es von GLYN neben dem TFT Steuerprogramm auch noch wichtige Funktionen, wie z. B. Kreise, Linien, und Blöcke zeichnen. Auch Fonts können verwendet werden." Naja, nicht sehr überzeugend, was die Graphic-Libs angeht :)
Hallo Anguel, ich kann nur den Vergleich zu einer "Spiel"-Version von Keil und dem Hitex Hitop (aeltere version) ziehen. Und dabei konnte ich keine grossen Unterschiede bezueglich der erzeugten Codequalitaet ausmachen. gut die ide und die debug Moeglichkeiten sind nicht ganz so gerade aus wie in der speziellen IDE's. Da ich jedoch oft bei den target-Plattformen springen muss, ist die geringere Vielfallt der Debugunterstuetzung eher ein vorteil, da ich dann nicht bei einer Plattform ein spezielles debug feature vermissen kann. ;-) Laeuft dann ebend eher alles mehr auf basis debug funktionen hinaus. Die gibt es bei jedem target und ich muss sie nicht erst lange suchen und mich darauf einstellen. ;-) Der gcc ist nebenbei ja auch Grundlage fuer das durch Codesourcey angebotenen Entwicklungspaket. Ob die dort noch etwas daran veraendern/verbessern weiss ich jedoch nicht. Für alle die mal den gcc für arm ausprobieren wollen und kein Problem mit linux haben http://www.lowlevel.eu/wiki/ARM_Cross-Compiler LG ein bastler
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.