Ich wollte mal zum Lernen und auch weil es mir für mein "Projekt" sinvoller erscheint mir einen 32Bit µC zulegen. Leider war kaum ein Beitrag der SuFu aktuell genug um auch die AVR32 gescheit abzubilden, oder aber es verlief wie bei dem Beitrag über die Vorteile von 32Bittern bei starker Nutzung von 32Bit Werten und Multiplikationen relativ im Sand. Da ich die Treads auch nicht exhumiern möchte hier der neue Beitrag. Vorhanden ist die Erfahrung: 8-Bit µC (Schreib grade ne Ansteuerung für PATA nach dem ATA-8 Standart) PC Programmierung C / C++ / C++ Cli/.net sowie Grundkentnisse DirektX mehr schlecht als recht leider =/ Platinen ätzen kann ich und werde auch die für die 32Bitter selbst erstellen, was allerdings schon eine Bedingung mit sich bringt: µC soll in einer lötbaren Form daher kommen also kein BGA! Ich hab mal die gesammten ARM Artikel durchgelesen und bin am überlegen ob ich mir einen AT91SAM7S256 nehme, da er schöne Perepherie hat, sowie preislich sehr günstig und gut erhältlich ist. Nachteil: Er hat einen ARM7 Kern, der bereits in verbesserter Form als ARM9 zu haben ist. Andere Möglichkeit wäre ein ARM9 Prozessor (AT91SAM9260 z.B.). Auch hier wäre die Perepherie Spitze, was allerdings leider auch den Nachteil bringt, dass ich nicht weiß wie ich einen PQFP 208 gescheit auf eine Platine bringen soll zumindest mit Hobbyausrüstung. Hat jemand sowas schonmal gelötet? Noch eine Möglichkeit wären AVR32 µC der AT32UC3A1512 hat zum Besenstiel einen 100 pinout also wahrscheinlich noch gescheit lötbar, wie der ARM7. Auch die Perepherie hier spricht eigendlich nicht gegen den Chip. Kosten auch nicht alle 3 Chips bewegen sich unter 13€ und sind somit für Einzelprojekte, wo es mal auf eine starken µC ankommt finanzierbar. Jetzt kommt aber die Sache warum ich diesen Epilog schreibe: Welchen µC könnt ihr empfehlen / bzw würdet ihr einen Anderen empfehlen und welche Hard und Software brauch ich. Ich wollte für die ARMs einen Wiggler Clone bauen, was ja im Zusammenhang mit WinARM gehen soll. Beim AVR32 gibts ja das AVR32Studio bei Atmel, aber welche Hardware wird benötigt? STK600 ist ja eigendlich nicht bezahlbar bzw ich will es grade nicht ^^ Werde vllt mal später drüber nachdenken. Ich will eigendlich auch kein vorgefertigtes Board haben, da ich meine Hardware gerne selbst in Form zwänge. Also welches bezahlbare oder nachbaubare Programmiergerät, dass mit dem AVR32Studio arbeitet gibt es? WICHTIG: Ich will nicht wissen, dass ich es bestimmt auch in 8-Bit hinbekommen würde, denn das stimmt aber besonders USB und möglicherweise mal ein Massstorage braucht da schon was größeres mit Hardware USB. Außerdem will ich die Möglichkeit haben auch recht einfach auf einen größeren µC zurückzugreifen, wenn er mal nötig sein sollte, was nur geht, wenn man sich schonmal eingearbeitet hat. Ich hoffe ich hab alles klar formuliert und dann sag ich schonmal Danke für die Mühe das zu lesen und Gruß ErgoProxy p.s. Rechtschreibfehler darf der Finder behalten =) €: Ach kennt jemand eine Bezugsquelle für log-digital Potis? Habs bisher immer nur normale gesehen. Notfalls funktionier ich halt eins mit 1000 Steps per Software um.
Nix für ungut, aber aus den anderen Threads solltest Du wissen, daß ARM7 sicherlich verschwendete Zeit ist. Der wird gerade abgelöst durch den Cortex M3. Auch die 9er stehen zur Ablösung an. Das sind halt alles "alte Eisen" mit vielen Nachteilen. Was Du Dir überlegen musst, ist, wieviel Leistung der 32bitter haben soll. Wenn die ARM7-Klasse reicht, dann rate ich Dir auf jeden Fall zum M3. Die gibt es jetzt schon in vielen Varianten, auch im kleinen 48er QFP-Gehäuse. Und in einem Jahr, wenn dann neben Luminary und ST auch NXP und Atmel mit Derivaten dabei sind, gibt es sicherlich nichts mehr, was man braucht, aber nicht erhält. Der AVR32 ist sicherlich nicht schlecht, aber wenn man, wie Du, sich nur "vorbereiten" will auf einen möglichen Einsatz eines 32bitters, dann sollte man darauf achten, daß man einen möglichst großen Einsatzbereich abdeckt und der ist beim AVR32 sicherlich jetzt schon deutlich kleiner als beim M3, und das schon ohne NXP- und Atmel-Derivate. Zu programmieren ist der M3 sehr schön, ich nutze den auch. GnuC und los geht es. Selbst die Startup kann man vollständig in C schreiben, abgesehen vom .bss Segment vielleicht. Auch Interrupts sind simple C Funktionen. Also ideal für Einsteiger.
Da man heutzutage sowieso nur noch in C programmiert, erst recht dicke Prozessoren mit hunderten kB Flash, ist es vollkommen egal ob man einen 8, 16 oder 32Bit Proz unter dem Compiler liegen hat. Man merkt das nur in der Geschwindigkeit. Daher waehlt man seinen Controller nach der Eignung fuer ein bestimmtes Projekt aus. Olaf
Schau Dir mal die Controller der Flexis Familie von Freescale an. Da gibt es ein günstiges Eval-Board und Pin- und code-kompatible 8- und 32-Bit MCUs. Außerdem besitzen die ein USB-Master/Slave und OTG. Die 32-Bit Controller sind Coldfire V1. Das Eval-Board: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=DEMOJM&fsrch=1 Noch günstiger, JMBADGE: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=JMBADGE&fsrch=1
Was ich noch vergessen habe: Freescales CodeWarrior gibt es dazu in einer kostenlosen Version. Bei der ist allerdings der C-Compiler auf 32/64kB beschränkt.
Hallo, auch ich fange gerade mit 32Bittern an. Allerdings habe ich mich für die PIC32-Familie von Microchip entschieden. Dafür sprechen drei Gründe: - sehr gute Verfügbarkeit und guter Preis - sehr preiswerte Entwicklungsumgebung (bzw. Starter Kit), incl. kostenloser C-Compiler - Controller-Technik und -Funktionen auf dem aktuellen Stand (kein alter Kram, der auf 32 Bit umgemodelt wurde!)
> ...mich für die PIC32-Familie ...
Wie sieht es hier mit der Errata-History aus? "Überschlägt" die sich,
oder ist diese Familie schon Serienreif?
@Gast: >- sehr gute Verfügbarkeit und guter Preis Was heißt für Dich "sehr gut"? Den Cortex M3 wird es bald in jedem Krauterladen geben. Und wie ist der Preis >- sehr preiswerte Entwicklungsumgebung (bzw. Starter Kit), incl. >kostenloser C-Compiler Schön wär es. Die kostenlose Version ist aber leider limitiert. Soweit ich weiß, schon in der Größe, aber auf jeden Fall, was sowas wie Optimierung angeht. Das ist wohl für die meisten Hobbyisten ein großes Manko. Der M3 wird offiziell vom GCC unterstützt und weiterentwickelt, daher keine Abhängigkeit vom Hersteller. Für mich wäre das ein Ausschlußkriterium. >- Controller-Technik und -Funktionen auf dem aktuellen Stand (kein alter >Kram, der auf 32 Bit umgemodelt wurde!) Das trifft auch auf alle Konkurrenten zu. Technisch betrachtet, sind sich PIC32/MIPs und ARM recht ähnlich, so daß alleine aufgrund des Kernvergleichs keine eindeutige Empfehlung herausarbeiten läßt. Entscheidend dürfte aber für die meisten sein: - Unbeschränkte und volle Gnu-Unterstützung nur für den M3 - Etliche Hersteller von Derivaten, daher für jeden Zweck etwas dabei, beim PIC32 Abhängigkeit von Microchip - Daraus resultierend auch keine Herstellerabhängigkeit Im Gegensatz zum ARM7 hat ARM beim M3 auch mehr auf Vereinheitlichung des Chips geachtet, d.h. die Hersteller können wichtige Teile in ihren eigenen Produkten nicht so stark variieren, so daß eine Portierung von Software für einen M3 eines Herstellers auf den eines anderen wesentlich einfacher ist. Wenn man sich dann noch ansieht, wie viele hier im Forum mit dem ARM7 arbeiten - trotz aller Krücken -, dann dürfte die M3 Fraktion bald richtig groß sein. Beim PIC32 wird das sicherlich nicht der Fall sein.
Hallo Andreas, wenn's mal was anderes sein darf: www.glyn.de Die vertreiben Renesas, Fujitsu, Toshiba,... Wie's da mit Verfügbarkeit, Lieferung an Privat, Tools usw. aussieht kann ich allerdings nicht sagen. Im Februar soll Elektor einen Kurs mit R32C Starterkit anfangen... Bin nicht verwandt, verschwägert noch sonstwie mit Glyn verbandelt. Gruß, Thorsten
> Und wie ist der Preis z.B. bei Farnell (je nach Typ) zwischen 5...15 EURO incl. MWSt für 1 Stück > Schön wär es. Die kostenlose Version ist aber leider limitiert. Soweit > ich weiß, schon in der Größe, aber auf jeden Fall, was sowas wie > Optimierung angeht. Das ist wohl für die meisten Hobbyisten ein großes > Manko. Limitiert heißt, dass beim Compilieren nicht mehere Optimierungszyklen durchlaufen werden. Für die allermeisten Projekte dürfte das aber absolut egal sein. Weitere Einschränkungen gibt es nicht. > Beim PIC32 wird das sicherlich nicht der Fall sein. Was hast Du denn für eine Glaskugel?
Also ich habe mit PIC24 und PIC32 gearbeitet. Ganz cool ist das PIN-Mapping, man kann sich wie bei einer FPGA (ist wahrscheinlich eine :) ) die PINs umlegen. ALso ein Design-Fehler im Schaltplan läßt sich softwaremäßig ausbügeln. Ansonsten sind die Dinger scheisse langsam und nicht empfehlenswert. Mit dem C30-Compiler habe ich einen doppelten so schnellen Quarz benötigt, wie bei einem AVR mit der gleichen Firmware.
Ich denke die Eignung für dein Projekt sollte weniger ein Kriterium sein, denn vermutlich wirst du, einmal eingearbeitet und in Entwicklungstools (HW oder SW) investiert, dein gewähltes System auf für zukünftige Sachen nutzen. Da du dich Einarbeiten musst, ist das wichtigste Kriterium wohl der Support, sowohl an Doku, Tools, als auch User-Gemeinde. Verfügbarkeit, Preis, wäre eher für Firmen wichtig, denn ob der uC am Ende 5 oder 15 Euro kostet spielt bei Einzelstücken hinsichtlich Aufwand keine Rolle (Die Arbeitszeit sollte der eigentliche Kostenfaktor sein, wenn man sich 50 Mannstunden für die Einarbeitung mit 10€ entlohnen würde...). Zum Einsteigen brauchst du eigentlich nur ein Mini-Entwicklungsboard, denn die AVR32 können per mitgeliefertem Bootloader über USB programmiert werden. Für den AP7 gibts ja schon Erschwingliche Kits wie NGW100 oder Grasshoper, die allerdings auf Linux basieren. Für den UC3 scheint es außer den EVK11xx von Atmel noch nicht viel fertiges zum spielen zu geben, das sollte aber nur eine Frage der Zeit sein bis die Bausatz-Anbieter im Embedded/Hobbybereich da auch nachziehen. Ich habe auch kürzlich beschlossen mich mit 32bit zu befassen, ich habe mich eigentlich sofort für AVR32 entschieden, weil ich vorher mit Atmels AVRs gearbeitet habe. Obwohl ich noch immer begeistert bin, und ihn von den Leistungen her im Vorteil zu Cortex sehe bezüglich Integrationsdichte und Leistungsaufnahme, und auch davon Ausgehe das Atmel noch einiges nachschießt, bin ich zur Zeit recht enttäuscht von dem Support hinsichtlich Dokumentation. Auch die Usergemeinde hat noch nicht vieles an Tutorials oder Beispielprojekten veröffentlicht, es scheint noch sehr wenig Erfahrung zu geben, so das man in Foren nicht immer Antworten bekommt. Weiterhin sind die Entwicklungstools noch nicht ganz Ausgereift. Wenn du von 8 Bittern an einen Simulator gewöhnt bist, wirst du beim AVR32 Studio noch ziemlich entäuscht. Es gibt zwar einen, aber ohne jegliche Peripherieunterstützung, so das er man fürs Debugging wohl vorerst nicht ohne "In System Lösung" auskommt, sprich JTAG(clon) oder für Verwegene gesunden Optimismus zusammen mit selbstgestrickten Debugausgaben über UART und Prinzip Versuch/Irrtum. Bei der den Eval und Develkits gibts zur Zeit wohl auch noch Anfahrtsschwierigkeiten bei Atmel, bei den Devices sind bisher erst einige Lieferbar. Diese Dinge sind aber eher eine Frage von Monaten. Daher wirst du es beim Einarbeiten vermutlich einfacher mit ARM haben. Auch wenn ich keine ARM/AVR32 Praxis Erfahrung habe sieht mir der AVR32 aber noch vielversprechender aus. Einmal denke ich die Usergemeinde, Doku und Support wird in einem Jahr schon eine ganz andere sein. Zweitens hoffe und glaube ich, das mit dem AVR32 Studio aufbauend auf dem Eclipse-Framework und dem Software-Framework in Zukunft eine sehr mächtige und komfortable Entwickungsumgebung vorhanden sein wird, vorallem aus einem Guß. Bei ARM gibt es neben dem opensource Flickwerk rund um GCC keine vergleichbare Umgebung oder? Drittens denke ich, das aus diesen Gründen dann auch Hobbyanwender langfristig tendentiell eher zu AVR32 tendieren als zu ARM, so wie bei den 8Bittern die AVR Familie sich gegenüber den lange etablierten Industriestandards dort durchgesetzt hat, sofern Atmel die vielversprechenden Ansätze in Richtung AVR32 Studio, Software Framework, und Linuxsupport konsequent weiter verfolgt. Dann wird mit Bausätzen im Hobbybereich und Opensource Projekten auch mehr low-Budget Lösungen geben. Schließlich macht für mich der Reiz des Neuen, hinsichtlich der technischen Innovationen (wenn auch nicht so drastisch wie damals beim AVR), aber auch hinsichtlich des Neuland-Charakters der einem zur Zeit als AVR32 User noch darbeitet, aber den Unterschied aus. Daher als Fazit: Wenn es dir darum geht kurzfristig 2-3 Projekte ohne "viel" Einarbeitung (relativ) auf die Beine zu stellen, nimm ARM, wenn in dir eine todesmutige Abenteuerer und Einzelkämpferseele steckt und gegenüber dem Reiz des Neuen anfällig bist, bring etwas Geduld beim Beschaffen der Hardware mit und nimm AVR32. Langfristig wird sich das denke ich auch Auszahlen Will man die Glaskugel in noch fernere Zukunft blicken lassen, kann ich mir auch gut Vorstellen, das in 5-10 Jahren auch im Hobby und Opensourcebereich die 32bit Embedded Architekturen zusammen mit Linux die Bastlerszene aufmischen werden, so das ein schlankes Linux als OS die Grundlage und Plug n Play Module die Funktionalität für einfache Hobbyprojekte oder auch Quick n Dirty Prototypen darstellen. Am Beispiel der ersten AVR32 Anwendungen auf Linuxebene konnte man das sehr beeindruckend sehen, aufwändige Multimedia oder Netzwerkspielereien waren offenbar nur wenige Monate nach den ersten Toolchain-Releases schon zusammengestrickt. Auf der Hardwareebene wird man mittels Linuxtreibern sich auch an ganz andere Dimensionen bezüglich Standardperipherie gewöhnen, als die bei 8 bit üblichen handvoll Leds, Tasten, UART und 4x20 LCD. Ich denke daher auch, das der AVR32 über die AP7-Reihe und Linux schnell viel Fahrt aufnehmen wird, indem er die open source Szene anzapft. Wer also im Hobbybereich von AVR32 und ARM das rennen macht, dürfte sich daran entscheiden welche Architektur sich besser portieren lässt. Auch wenn im Moment da der ARM noch vorne liegt, denke ich das die vielen verschiedenen ARM Implementationen mittelfristig die Portierungsanstrengungen im Vergleich zu Atmels Lösung aus einer Hand behindern werden. Wenn sie klug sind, werden sie die Portierung in den Open-Source Projekten auch weiterhin aktiv antreiben. Wenn Arm das verschläft haben sie zumindest den Hobbybereich verloren.
Da ich mich erst seit kurzem damit Beschäftige ist das aber mehr "erster Eindruck von außen" als Expertenmeinung. Ich lass mich gerne von der ARM-Fraktion belehren was die Linuxunterstützung angeht.
Also erstmal Danke für die vielen Beitrage und leider war ich eute länger nicht da sonnst hätte ich früher geantwortet: @Jakob (Gast) - Genau aus dem Grund habe ich eigendlich diesen Tread eröffnet. Ich wollte wissen, ob ARM7 noch zu gebrauchen ist, oder ob ARM9 oder aber AVR32 besser ist, da sie sich preislich nicht unterscheiden oder nur etwas. Den Cortex hatte ich ganz vergesen als ich den Tread erstellt hab und wollte ihn eigendlich auch erwähnen, wobei ich immernoch Probleme habe eine Bezugsquelle für nicht Industrielle zu finden oder Shops die nicht verlangen dass man für ziemlich viel Geld einkäuft weil sonnst horende aufschläge auf die Versandsumme vorgenommmen werden. -Ich glaub ich hab grade einen gefunden für den STM32F103RBT6 @ 4.61€, falls der Shop was taugt, aber das ist erstmal egal. Ich hab mir grade auch das Datenblatt angesehn und muss sagen es klingt nicht schlecht. @ Olaf - Ich habe leider keine Erfahrung mit 32Bittern und deshalb möchte ich ja welche sammeln. Nur das ich eigene sammeln will heißt nicht, dass ich stupide gegen die Wand laufe und nicht auf die ausgezeichnete Beratung und Erfahrung hier im Forum zurückgreife. @Mathi (Gast) - Wenn ich ehrlich bin die gefallen mir einfach nicht =/ ich wollte eher eine nicht so ganz exotische Familie haben. P.s. Warum sind die unter 8Bit Mcus eingeordnet? Naja das zweite zumindest. @Gast (Gast) - Wie später auch genannt spricht für mich gegen Pic eigendlich diese absolut langsame Abarbeitung von Befehlen, also dass man das doppelte an Takt braucht um den gescheit zu betreiben. Sollte ich mich da irren bitte ich um Berichtigung. @Jakob (Gast) - Sehr gut ist einfach eine Floskel die ich oft schreibe, soll aber einfach nur heißen ich möchte das Ding irgendwo zu Preisen unter 20€ pro Einzelstück kaufen können und dass ohne, dass ich ne Mindestmenge von 1k oder mehr abnehme. Ansonnsten sieht der Cortex M3 schon echt gut aus. Einzig die Verfügbarkeit bei mir bekannten Shops bereitet mir noch ein paar Probleme ich habe bisher nur einen Shop gefunden, der 3 verschiedene im Programm hat. - Hm vergiss es ich hab grade mal bei Farnell geschaut die scheinen ja an Privat zu liefern und die haben doch eine erschlagende Auswahl. Allerdings jetzt eine Frage: Wie sieht es mit der Entwicklungsumgebung aus - Ist die GNU Toolchain für den M3 schon ausgereift genug oder schlägt man sich da noch mit größeren Problemen rum? Hardware wäre ein JTAG-Adapter, wäre der Wiggler geeignet? @Thorsten Simon (thorsim) - Danke für den Link aber auch die µC sind mir zumindes vorläufig etwas zu exotisch. @DrShorsch (Gast) - Hört sich eigendlich nach nem tollen Feautre an aber leider schreckt mich wie weiter oben schon geschreiben die Zyklendauer der Befehle etwas ab. @ Moritz E. (devmo) - Hast Recht es geht nicht um die Projekteignung an sich, da das nur ein relativ simpler MP3-Player wird aber es ist ein Projekt, wo man so einen größeren µC zumindest nicht total verschwendet. Verfügbarkeit und Preis sind nur in soweit wichtig, dass ich die Teile halt in kleinen Stückmengen zu bezahlbaren Preisen bekomme, aber du hast Recht es kann notfalls auch mal etwas teuerer sein, dass ist nicht undbedingt ein KO-Kriterium. Zu der Entwicklungsumgebung des AVR32 ich arbeite immer nach dem Try and Error Verfahren. Erstmal wird was einfaches gebaut wie USART und damit dann jeweils die Routinen abgeklappert bis man den Fehler sieht oder bei jedem Abschnitt wird ein anderer Buchstabe ausgegeben, dann sieht man an den fehlenden Buchstaben wo es denn hakelt. Solange der Compiler geht ist das alles in Ordnung. Mit JTAG kann man sie auch so beschreiben also auch ohne Bootloader auch hier nochmal die Frage geht da der Wiggler? Ich frag nur deshalb falls mir mal irgendwie ein Fehler passiert und z.B. der Bootloader überschrieben wird oder so. Auch wenn die Lockbits das verhindern sollten ^^ ich unterschätze die möglichen Fehler nur lieber ned. Mit den ARM9 hat noch keiner Erfahrungen oder? Gruß ErgoProxy und nochmal Danke an Alle.
DrShorsch wrote: > Also ich habe mit PIC24 und PIC32 gearbeitet. Ganz cool ist das > PIN-Mapping, man kann sich wie bei einer FPGA (ist wahrscheinlich eine > :) ) die PINs umlegen. ALso ein Design-Fehler im Schaltplan läßt sich > softwaremäßig ausbügeln. Ansonsten sind die Dinger scheisse langsam und > nicht empfehlenswert. Mit dem C30-Compiler habe ich einen doppelten so > schnellen Quarz benötigt, wie bei einem AVR mit der gleichen Firmware. den haste des DB aber net gelesen reinteoretisch müsste der avr nur ein viertel der Geschwindigkeit haben so gesehn ist der pic wider schneller wen er nur die Hälfte langsamer ist :P
Hi, kann Cortex M3 von Luminary empfehlen, viel Peripherie, gute Library, gutes Datenblatt. Funktioniert mit Keil und ULink JTag Debugger fast problemlos.
> schnellen Quarz benötigt
Wieso benutzt Du nicht die PLL? Damit kannst Du ihn locker mit 48MHz
takten, wenn Du ihn z.B. gemäß den Microchip-Design-Vorschlägen mit
einem 8MHz-Quarz betreibst. Es geht aber auch ein 4MHz-Quarz für 48MHz
Takt.
Ich kann als kostengünstige Variante den STM32 bzw. den 32 bit Flexis empfehlen. Wenn es etwas anspruchsvolleres sein soll wäre der MPC551x aus der automotive PowerPC Familie etwas. IDE für gcc mit einfachem JTAG Debugger gibt es von PEMicro.
@ Heinz kennst du eine Bezugsquelle für die Cortex M3 von Luminary? ich finde immer nur welche von ST MICROELECTRONICS. Also momentan schwanke ich echt zwischen AVR32 und den Cortex M3. Leider scheint keiner den ARM9 zu kennen =( wie ist eigendlich so der AVR32 verglichen mit den Cortex? Hängt der die wesentlich ab oder sind die in etwa gleich stark? Und noch eine Frage zum AVR32: Performing 1.49 DMIPS / MHz Up to 91 DMIPS Running at 66 MHz from Flash (1 Wait-State) Up to 49 DMIPS Running at 33MHz from Flash (0 Wait-State) Was genau bedeutet das? Mit der Zeile im Datenblatt kann ich nicht wirklich was anfangen. Ist das eine Einschränkung der Geschwindigkeit auf Grund der Zugrifszeiten auf den Flash? €: Hab grade gesehn die Übersetzung bzw die bedeutung von DMIPS ist Million Instructions Per Second ok dann ist es mir klar bis auf was das D also Dhrystone bedeutet ^^ wahrscheinlich der Erfinder / Festlerger dieser Angabe. Gruß ErgoProxy
Grüß dich, als ich kann dir nicht zustimmen, dass es sich bei Flexis Freescale Familie um einen "Exoten" handelt. Ich finde das Demo Board DEMOQE128 mit den 2 Controllern MC9S08QE128 (8 Bit) und MCF51QE128 Cold Fire V1 (32 Bit) sehr interessant für dich. Das nette an der Sache ist, dass die Controller Pin kompatibel sind (64 Pins) lassen sich auch per Hand löten. Das Demo-Board besitzt USB, RS232, LEDs, Taster, Buzzer und einen Chip um die Raumlage des Boards zu ermitteln. Ich habe mit dem 8 Bit Controller eine "Testschachtel" mit PWM, ADC, DAC, Taster, Display, externem EEPROM, Menü, RS232 Protokoll ... realisiert. Das ganze Projekt habe ich dann innerhalb einer Woche mittels CodeWarrior ziemlich problemlos auf den 32 Bitter portiert. Ein paar kleine Änderungen waren nötig (z.b. andere header datei einbinden, aber den großteil nimmt dir codewarrior ab) was für dich noch interessant sein könnte: Die Hardwareinitialisierung kann man sehr komfortabel mittels CodeWarrior vornehmen. Der 32 Bitter ist eine spezielle Low Power Variante und zieht im Vergleich zum 8 Bitter mit der gleichen Applikation weniger Strom. Außerdem ist der MC08 bzw. MC9S08 sehr weit verbreitet... von wegen Exot ;-) gerade im Automotive Bereich wirst du mehr MC9S08 als Atmel finden. Beste Grüße und viel Erfolg Sebastian
@ Andreas K.: Die M3s von ST sind hier schon gut erhältlich, z.B. bei sander electronic. Die Luminaries noch nicht, aber hier laufen eigentlich regelmäßig digikey Bestellungen. Wenn das zeitlich also nicht so drängt, kannst Du Dich auch da dranhängen. >Allerdings jetzt eine Frage: Wie sieht es mit der Entwicklungsumgebung >aus - Ist die GNU Toolchain für den M3 schon ausgereift genug oder >schlägt man sich da noch mit größeren Problemen rum? Hardware wäre ein >JTAG-Adapter, wäre der Wiggler geeignet? Ich nutze als Compilersuite die lite-Gnu-Version von codesourcery. Das funktioniert bei mir wunderbar. Installation ist ein Klacks und ratzfatz das erste Programm erstellt. Da der M3 auch ganz ordentlich durchdacht ist, ist das Erstellen der startup und des Linkerskriptes auch für einen Anfänger simpel, da diese beiden Dateien sehr überschaubar bleiben. Ich kann Dir gerne eine für den Start bereitstellen. Da ich die Luminaries nutze, kann ich nichts über den Wiggler sagen. Die Luminary Dev Boards können auch als JTAG-Adapter für eigene Schaltungen genutzt werden. Daher nutze ich das Dev-Board mit OpenOCD für JTAG. Größere Probleme habe ich keine, einzig die Einrichtung hat ein wenig Zeit gekostet. Man muss halt einiges lesen und ausprobieren. Allzuviel nutzen tue ich das aber nicht, schneller und praktischer sind halt Debug Ausgaben über UART oder LED/Display. Nur in speziellen Fällen ist bei mir JTAG zum Debuggen nötig. Was insbesondere für einen schnellen Einstieg, aber durchaus auch im späteren Einsatz sehr interessant ist, ist die Tatsache, daß sowohl Luminary als auch ST umfangreiche Libraries zu den Controllern mitliefern. Man kann also die Teile programmieren, ohne die Hardware im Detail zu kennen. Mit ein wenig MC-Vorkenntnissen geht der Einstieg sehr schnell. Ich kam jedenfalls deutlich schneller zu ersten Erfolgen als mit dem AVR. Was den AVR32 angeht, so ist der sicherlich auch eine interessante Alternative. Aber das muss jeder für sich selber entscheiden. Für mich war wichtig, daß es eine breite Basis gibt, der MC durch die GNU Suite unterstützt wird und ein Einstieg schnell geht. Alles bietet der M3. Wenn es mal mehr Leistung sein soll, um z.B. ein Linux laufen zu lassen, würde ich eh zu einem wesentlich größerem Controller greifen, z.B. zu einem Cortex A8 z.B., TI hat mit dem OMAP sehr leistungsfähige Derivate mit DSP onboard. Günstig z.B. das Beagle Board http://beagleboard.org/ .
@K. J. und Gast Kann gut sein, daß ich nicht alles über den PIC24 weiss und ich musste mit den Dingern immer ganz schnell das Problem lösen. Die wurden mir aufs Auge gedrückt.Ich hab das Problem jedesmal innerhalb von 1 bis 2 Tagen gelöst. Will mich aber mit den Dingern nicht beschäftigen wenn ich nicht muss. Allein der cryptische Baudratengenerator geht mir bei Microchip generell auf den Keks. Laut Datenblatt hat das nie funktioniert, musste immer mit dem Oszi und per Try and Error nachführen. Jedenfalls fallen mir die Zähne aus, wenn ich wieder einen Auftrag habe einen PIC16,PIC18,PIC24 oder PIC32 programmieren zu müssen... nichts für ungut.
Ich empfehle den AVR32 und das STK 1000... Hab noch eins rumliegen, was ich bereit waere zu verkaufen ;-) Beitrag "[V] Verkaufe STK 1000 Development KIT"
>Ich empfehle den AVR32 und das STK 1000... Hab noch eins rumliegen, was >ich bereit waere zu verkaufen ;-) Musst ja Deine Gründe haben, das zu verkaufen... Bist wohl auf den M3 umgestiegen, was? ;)
Andreas K. wrote: >wie ist eigendlich so der AVR32 > verglichen mit den Cortex? Hängt der die wesentlich ab oder sind die in > etwa gleich stark? Und noch eine Frage zum AVR32: Also viel tut sich da nicht, aber sie Atmel behauptet das im direkten Vergleich der compilierte Code für den Atmel kleiner ist ist und das es mehr DMIPS pro Watt gibt. Atmel geht in seinem Flyer auf diesen Vergleich Cortex und AVR32 ein: [http://support.po-star.com/uploadfiles/2007427165248775.pdf AVR32 UC3 Product Line and Roadmap] (Folie 42 Tabelle] Und hier: [http://www.atmel.com/dyn/resources/prod_documents/doc4092.pdf MCU Architectures for Compute-Intensive Embedded Applications - Whitepaper] hier ohne Cortex. Der Cortex ist also fast gleich auf, aber scheinbar hat er keine DSP-Funktionen? Die anderen Arms steckt der AVR32 aber offenbar in die Tasche. > > Performing 1.49 DMIPS / MHz > Up to 91 DMIPS Running at 66 MHz from Flash (1 Wait-State) > Up to 49 DMIPS Running at 33MHz from Flash (0 Wait-State) > > Was genau bedeutet das? Mit der Zeile im Datenblatt kann ich nicht > wirklich was anfangen. Ist das eine Einschränkung der Geschwindigkeit > auf Grund der Zugrifszeiten auf den Flash? Wenn man schneller als 33MHz taktet muss man einen Clock Waitstate beim lesen von Flash aktivieren, warum es immernoch 91 DMIPS dann sind ist mir auch nicht klar. Vermutlich wird bei dem Wert der Programmcode aus dem RAM ausgeführt? Oder gecachet?
Hallo, Ich habe mich "vorerst" für den AVR32 entschieden. Speziell auf den AP7, weil dieser für meinen Mediaplayer mit Touch einfach perfekt geeignet ist. Ich wollte einfach die Aplikation mit purer Leistung erschlagen und mich (noch) nicht mit Hardwaretreibern rumärgern. Genau das wofür er gebaut wurde. Was ich als großen Vorteil sehe, ist das ich einiges tut im Bereich Opensource was den AVR32 betrifft, das reicht von JTAG Tools(siehe USBProg) über Entwicklungsumgebung und direkter Kontakt mit den "Erstellern" der Toolchain. In der Mailinglist tut sich immer recht viel was Patches usw betrifft. Nebenbei überlege ich parallel mich mehr mit dem Controller auf unterster Ebene zu befassen, das hauptsächlich um mich für den Job weiter zu rüsten. Und ich denke das Industriemäßig sich der M3 eher durchsetzt als der AVR32 auch wegen den Anwendungsgebieten. Wie es in der Community ausschaut kann man nicht sagen, aber zumindest von der AVR32 Seite her weiß ich, das viele Leute gerade am Einstieg sind oder zumindest im Auge behalten. Da tut sich was. Als GANZ großes Plus seh ich die Verfügbarkeit für Tools auch für den kleinen Geldbeutel. Atmel leistet da wirklich super Arbeit, was Libraries, IDE, Toolchains usw angeht. MK2 gibts für Studenten recht billig, sonst gibts Chinanachbau auch für knapp 110€. Ich selbst stehe vor der Entscheidung welchen Controller ich für hardwarenahe Aufgaben einsetzen werde, vom Controller tendiere ich zu M3, von der Verfügbarkeit der Tools zu AVR32. Was mir beim M3 fehlt ist ein klarer Ablauf was ich wie und wo programmieren kann, zig IDEs und Toolchains ich hab da ehrlich gesagt keinen Durchblick was ich als Privat gut udn günstig verwenden kann. Im Endeffekt heißt es: Mehr Geld für Tools,IDE und ws weniger Support für Privat (M3)<->(AVR32) Geringe Controllerauswahl dafür Software mäßig besser unterstützt. Gerade was Toolchain betrifft lass ich mich vom M3 aber gerne eines besseren belehren Michael
Also Danke erst nochmal für die vielen Tipps und Vorschläge. Ich glaube ich werde mich für den Cortex M3 entscheiden, wenn ich mal eine Toolchain finde die ihn unterstützt. Aber da Jakob in seinen Post ja gesagt hat welche er benutzt dürfte sich das als recht einfach darstellen. WinArm und GnuArm (was ist da eigendlich der Unterschied =) scheinen ihn nicht zu unterstützen hab sie mal installiert gehabt und glaube nicht, dass sie ihn integriert haben. Ich muss allerdings auch gestehen ich hab es erst seit ner Stunde auf dem Pc und noch nicht wirklich durchgesehen. Wenn ich mich mit den Cortex M3 angefreundet hab, kann ich ja immernoch mal nen AVR32 anschaffen, lernen schadet ja nie. Also nochmals vielen Dank und wenn ich noch Fragen hab schreib ich nochmal =) Gruß ErgoProxy
@Andreas (ergoproxy)
Beim Durchlesen ist mir aufgefallen, dass du das Wort "eigentlich" immer
falsch schreibst ("eigendlich"). Ist zwar nicht weiter schlimm und man
kann sich ja auch mal verschreiben, aber bei dir scheint das ein
chronischer Rechtschreibfehler zu sein.
http://www.duden.de/duden-suche/werke/fx/537/834/eigentlich.537834691.html
Also: Eigentlich noch viel Spaß mit deinen 32 Bittern.
;-)
@eigendlich (Gast) Sowas ist eigendlich nicht nötig in der sonst hier interresanten Diskussion. @Andreas Könntest du hier in dem Thread dann bitte deine ausgewählte Toolchain und die passenden Tools vorstellen? Schließ mich dann so langsam im laufe der nächsten Zeit vielleicht mal an. Michael
> @ Olaf - Ich habe leider keine Erfahrung mit 32Bittern und deshalb > möchte ich ja welche sammeln. Nur das ich eigene sammeln will heißt > nicht, dass ich stupide gegen die Wand laufe und nicht auf die > ausgezeichnete Beratung und Erfahrung hier im Forum zurückgreife. Was mir nicht einleuchtet ist welche besonderen Erfahrungen ein 32Bit Controller gegenueber einen 8 oder 16bit so bringen kann. Ich sehe da eigentlich nur zwei Unterschiede. 1. Man kann deutlich mehr Ram/Rom addressieren 2. Er ist bei grossen Datentypen erheblich schneller. Ob man das nun benoetigt haengt vom Projekt ab. Es gibt sicher Anwendungen da muss es soetwas sein. Aber ich sehe da keine Erfahrungen die es Wert sind gesammelt zu werden obwohl ich fast jeden Tag mit 32Bittern zutun habe. (68332) Im uebrigen hast du auch Renesas, Hitachi oder Fujitzu vergessen. Aber gerade z.B bei Renesas sind alle Erfahrungen von R8C auf M16C wirklich 1:1 uebertragbar, auf M32 vermutlich genauso. Mit letzeren habe ich aber noch nicht gearbeitet. Solltest du dir uebrigens auch mal ankucken da du eine relativ ausgereifte Umgebung bis maximal 64kb Codegroesse umsonst bekommst, und wenn dir das nicht reicht man genauso problemlos auf den gcc umsteigen kann. Ich wuerde heute wahrscheinlich keinen 8Biter mehr verwenden seitdem ich mit den R8C rummache. (intern 16bit) Um das zu verstehen braucht man nur mal zu schauen wie oft man 16Bit Datentypen in seinen Programmen verwendet. Ein gutes Beispiel sind z.B Regler wo man am Eingang einen 8Bit Wert vom AD-Wandler hat und am Ausgang wieder einen 8Bit Wert fuer seine PWM benoetig. Dazwischen aber wird gerechnet und das sind 16Bit schon angesagt. Da merkt man erstmal so richtig was fuer ein Krampf das frueher war als man noch 8Bit Controller genutzt hat weil man aus Geschwindigkeitsgruenden jede Menge verrenkungen gemacht hat. Von 16 nach 32Bit sehe ich aber nur einen deutlich kleineren Gewinn. Jedenfalls fuer die meisten Anwendungen, ausnahmen gibt es immer. Ich verwende z.B einen 32Bit Controller nur weil 1MB externes Ram zwingend fuer Daten brauche, und dann brauche ich einen Controller mit ganz vielen Beinen. Das will ich aber auf keinen Fall haben wenn man es nicht wirklich braucht. zum Beispiel weil die 6lagen Multilayerplatine so teuer ist. .-) Olaf
Hallo alle DMIPS sind nicht Million Instructions Per Second!!! Sondern um wieviel der Prozessor schneller ist als die VAX 11/780. z.B. nehmen wir den die hiergenanten werte Up to 49 DMIPS Running at 33MHz from Flash (0 Wait-State) also der µC ist 49 mal so schnell wie der VAX. Wobei der VAX 1757 Dhrystones scheffte. Also so ein AVR32 schaft 1757*49 D =86.093 Dhrystones. Jetzt denken sich einige von euch nur 86.000 bei 33MHz? ²Der Dhrystone-Code besteht im Wesentlichen aus einfacher integerer Arithmetik, aus String-Operationen, logischen Entscheidungen und Speicherzugriffen, wodurch die meisten universellen Computer-Anwendungen abgedeckt werden. Bei dem Testergebnis wird die mittlere Zeit ermittelt, die ein Prozessor für viele Iterationen einer einzelnen Schleife benötigt. Die Dhrystone-Leistung wird in DMIPS oder Dhrystone MIPS/MHz angegeben. MFG Patrick ²Zitat: ITWissen http://www.itwissen.info/definition/lexikon/Dhrystone-MIPS-DMIPS.html
@ eigendlich: Leider scheint mein Gehirn da in diesem Punkt lernresistent zu sein. Ich versuch es immer wieder ^^ aber ich bekomme in jeder Deutsch Klausur fast diesen Fehler hin ^^ bei dem Wort denkt man einfach nicht mehr nach wie man es schreibt. @ Michael: Sobald ich die Hardware hab und es hinbekomme die Dinger zu flashen und dann noch etwas Zeit neben dem Abi hab mach ich das gerne. Leider sind meine Ferien die Woche rum ^^ das wird mich aber nicht hindern noch etwas mit µCs am Wochenende oder wenn ich mal nix zu tun hab zu machen. @ Olaf: Hm also so gesehen unterscheiden sich die µCs nur etwas in ihren Eigenarten, da ich ja in C schreibe, aber die Perepherie ist doch um einiges größer als beim AVR z.b.. Ich meine zum Beispiel den Hardware USB. Im großen und ganzen sind sie gleich bzw sehr ähnlich, allerdings muss man sich trotzdem einarbeiten um sie nutzen zu können und vllt die ein oder andere Sache wird sicherlich für 8Bit nutzer an Fallstricken vorhanden sein ^^. Das ist genau wie mit der Pc Programmierung. Eigendlich schreibt man in Consolenanwendungen und auch in graphischen Benutzeroberflächen C/C++ Code, was aber nicht heißt, dass ein Consolenprogrammierer sich einfach so hinsetzen kann und eine schöne Fensteraplikation erstellt. Dauert leider auch seine Zeit das zu lernen. Gruß ErgoProxy
Olaf wrote: > Was mir nicht einleuchtet ist welche besonderen Erfahrungen ein > 32Bit Controller gegenueber einen 8 oder 16bit so bringen kann. > > Ich sehe da eigentlich nur zwei Unterschiede. > > 1. Man kann deutlich mehr Ram/Rom addressieren > > 2. Er ist bei grossen Datentypen erheblich schneller. > Also wenn du dir mal den AVR32 AP7 anguckst, oder auch andere mit Chache und MMU und allem hat es mehr mit einem 486er zutun als mit einem 8Bitter. "Zufuss" kann man die ja fast schon garnicht mehr programmieren so komplex wie sie werden. Das zeigt sich halt auch daran, das man dort ein Linux laufen hat. Auf der anderen Seite sehe ich da einen großen Unterschied in der Integrationsdichte, was da schon alles an Schnittstellen drin ist entspricht mehr einem SoC. Man hat deutlich mehr Rechenpower, er ist bei allen Datentypen erheblich schneller, hat dazu noch DSP Instructions. Der Anwendungsbereich ist schon in einer anderen Dimension als bei 8Bit. (Grafik, Netzwerk, Multimedia/DSP) Von Daher denke ich das die Programmierphilosophie dahinter auch eine ganz andere ist, als in der 8/16 Bit Welt, da man auf diesen komplexen Dingern mehr mit Vorhandenen OS und Bibliotheken/Frameworks/Treibern die Software "zusammensteckt".
> Im großen und ganzen sind sie gleich bzw sehr ähnlich, allerdings > muss man sich trotzdem einarbeiten um sie nutzen zu können Das gilt auch fuer kleinere Prozessoren wenn sie eine leistungsfaehige Peripherie haben. Ich verwende z.B auch den M16C29 und hatte eine ungeahnte Steigung meines Blutdrucks bis ich das I2C laufen hatte weil der Controller SPI, Uart, I2C Master und Slave mit einem seriellen Block machen kann und man da bergeweise Bits setzen muss. Aber ob ich da bei jetzt etwas tolles gelernt habe? Eher nicht. > und vllt die > ein oder andere Sache wird sicherlich für 8Bit nutzer an Fallstricken > vorhanden sein Hm..man kann lernen wenn man zwischen Intel und dem Rest der Welt. (Reihenfolge der Bytes) hin und her rennt. :-) > Consolenprogrammierer sich einfach so hinsetzen kann und eine schöne > Fensteraplikation erstellt. Dauert leider auch seine Zeit das zu lernen. Da kann ich mal nur uneingeschraenkt zustimmen. > Also wenn du dir mal den AVR32 AP7 anguckst, oder auch andere mit Chache > und MMU und allem hat es mehr mit einem 486er zutun als mit einem > 8Bitter. "Zufuss" kann man die ja fast schon garnicht mehr programmieren > so komplex wie sie werden. Das zeigt sich halt auch daran, das man dort > ein Linux laufen hat. Soweit sicher richtig. Aber nicht automatisch ein Vorteil. Es stoert mich gewaltig das man damit die impliziete Echtzeitfaehigkeit oder die Vorhersehbarkeit von zeitlichen Aufloesungen aufgibt. Mit anderen Worten man braucht dann ploetzlich eine sehr fette Hardware um Dinge zutun die man vorher mit weniger Aufwand und 1/10 Stromverbrauch genauso geloest hat. Geschenkt bekommt man nur komplizierte Zusatzfunktionalitaet die man von anderen kopieren kann. (z.B die Linuxtreiber, TCP/IP usw...) Olaf
So hab gleich mal eine Frage ^^ wo bekomme ich das "richtige" Datenblatt für die µCs von ST Micro. Die 80 Seiten die immer als Datasheeet überall sind, sind eher ein schlechter Witz bzw. nur die elektrischen Grundregeln und Schaltungen zur Nutzung der Perepherie. Irgendwie finde ich in dem Gewirr der vielen PDFs auf deren Seite auch keins. Um genau zu sein suche ich eigendlich nur die Auflistung der Register usw., dass man mit dem Chip überhaupt irgendwas anfangen kann. Kaufen wollte ich 2 von denen hier STM32F103RBT6. Die Produktseite wäre diese hier: http://www.st.com/mcu/modules.php?name=mcu&file=devicedocs&DEV=STM32F103RB Leider finde ich wie gesagt dort nicht das richtige Blatt bzw ich hab noch ned alle durch aber vllt weiß es hier ja jemand, dann spar ich es mir die alle runterzuladen. So bin dann mal am weitersuchen. Vllt hab ich aber auch Tomaten auf den Augen =/ Gruß ErgoProxy
Hm ich hab jetzt nahezu alle durch und finde da nix. Kann es sein, dass es bei ST kein Datenblatt über die Controller eigenen Register gibt, sondern nur ihre Codelibarys die man dann verwenden kann. Erinnert irgendwie an Pc-Programmierung, wo man auch nie direkt an die Hardware kommt. Fänd ich aber etwas blöde. Schreib ganz gerne meine Funktionen selbst. Naja wenns ned anders geht wirds auch so irgendwie funktioniern. Bisher habe ich es auch leider noch nicht wirklich hinbekommen irgend ein noch so einfaches Programm zu kompilieren ^^ bin leider die kompletten IDE umgebungen gewöhnt und nicht die Komandozeilentools. Mal wieder meine DOS kentnisse ausgraben und die Datenblätter durchsuchen wird es irgendwie schon gehn. Momentan bin ich so weit, dass ich Sourcery G++ Lite installiert hab und es ist auch richtig eingetragen, also "arm-none-eabi-g++ -v" leifert dass zurück was es laut Anleitung soll. Nur was schreib ich jetzt hinter das -T im make command ? -T soll ja wenn ich das richtig verstehe dann als nächstes das Linkerfile angeben. Hier ist noch der Ausschnitt aus dem Helpfile Building an Application This chapter explains how to build an application with Sourcery G++ Lite using the command line. As elsewhere in this manual, this section assumes that your target system is arm-none-eabi, as indicated by the arm-none-eabi command prefix. Using an editor (such as notepad on Microsoft Windows or vi on UNIX-like systems), create a file named hello.c containing the following simple program:
1 | #include <stdio.h> |
2 | |
3 | int
|
4 | main (void) |
5 | {
|
6 | printf("Hello World!\n"); |
7 | return 0; |
8 | }
|
Compile and link this program using the command:
> arm-none-eabi-gcc -o hello hello.c -T script
Sourcery G++ requires that you specify a linker script with the -T
option to build applications for bare-board targets. Linker errors like
undefined reference to `read' are a symptom of failing to use an
appropriate linker script. Default linker scripts are provided in
arm-none-eabi/lib. Refer to Chapter 6, CS3™: The CodeSourcery Common
Startup Code Sequence for information about the boards and linker
scripts supported by Sourcery G++ Lite.
There should be no output from the compiler. (If you are building a C++
application, instead of a C application, replace arm-none-eabi-gcc with
arm-none-eabi-g++.)
Falls mir einer helfen kann wäre sehr nett =/
Gruß ErgoProxy
Helfen kann ich Dir zumindest beim Datenblatt, da warst schon sehr nahe dran, schau mal unter Referenz Manual(RM0008). Gruß Reiner
Das Linkerfile sagt dem Linker, wo welche Daten (Code, Flashdaten,
RAMdaten, etc.) hingehört.
Ein einfaches Beispiel - ist allerdings für einen Luminary-M3, aber mit
Codesourcery GCC:
*****************************************************
MEMORY
{
FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 256K
SRAM (rwx) : ORIGIN = 0x20000000, LENGTH = 64K
}
SECTIONS
{
.text :
{
KEEP(*(.isr_vector))
*(.text*)
*(.rodata*)
_etext = .;
} > FLASH
.data : AT (ADDR(.text) + SIZEOF(.text))
{
_data = .;
*(vtable)
*(.data*)
_edata = .;
} > SRAM
.bss :
{
_bss = .;
*(.bss*)
*(COMMON)
_ebss = .;
} > SRAM
}
*****************************************************
Anmerkungen:
- MEMORY ist ja selbsterklärend, der Controller hat 256K Flash startend
bei 0x0 und 64KSRam startend bei 0x2..., Bis auf die Größe sollte das
beim STM32 genauso aussehen.
Auch die sections sollten genauso sein, bis auf .isr_vector, da Du keine
eigene Vektortabelle nutzt. Bei mir ist die halt mit
_attribute_ ((section(".isr_vector")))
definiert.
_etext, _data, _edata, _bss, _ebss werden vom Linker definiert, das sind
halt die Anfangs und Endadressen der jeweiligen Bereiche.
Die genaue Syntax eines Linkerfiles kannst Du in der Gnu-Dokumentation
durchlesen. Beim M3 braucht man aber davon nicht soviel, so daß das
Linkerfile recht überschaubar und durchsichtig wird.
Angehängte Dateien:
-
Deskt.PNG
240 KB
@Reiner L. Danke schon mal für das Manual =) Genau das hab ich gesucht ^^ Ich liebe es wenn Firmen sowas so schön verstecken. Es ist ja auch zu schwierig das bei der ganzen Familie für die es gilt irgendwo dazu zu setzen. @Jakob Auch dir Danke ich werde mir mal den Aufbau der Linkerfiles ansehn und schauen, wie ich das hinbekomme. Die enden doch alle auf ".ld" oder? Ich hab das jetzt so versucht: arm-none-eabi-gcc -o hello hello.c -T arm.ld hello.c ist das Prog:
1 | #include <stdio.h> |
2 | |
3 | int
|
4 | main (void) |
5 | {
|
6 | printf("Hello World!\n"); |
7 | return 0; |
8 | }
|
und arm.ld ist das etwas veränderte File, dass du gepostet hast. Laut
Datenblatt ist der Flash ab 0x0800 0000 und der Sram ab 0x2000 0000
MEMORY
{
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 128K
SRAM (rwx) : ORIGIN = 0x20000000, LENGTH = 20K
}
SECTIONS
{
.text :
{
KEEP(*(.isr_vector))
*(.text*)
*(.rodata*)
_etext = .;
} > FLASH
.data : AT (ADDR(.text) + SIZEOF(.text))
{
_data = .;
*(vtable)
*(.data*)
_edata = .;
} > SRAM
.bss :
{
_bss = .;
*(.bss*)
*(COMMON)
_ebss = .;
} > SRAM
}
Im Anhang (sry ist etwas groß)ist ein Bild der Console, also die Fehler
die ich bekomme, im Hintergerund ist außerdem der Abschnitt aus dem PDF
mit den Memoryeinteilungen. Es ist hoffentlich das wichtigste sichtbar.
Der Ordner C:\Arm ist auch da, in dem sich die Files befinden. Falls
einer einen groben Fehler findet, den ich mache bitte melden ich werd
dann auch mal weiterprobiern. Irgendwie wird das ja wohl hinzubekommen
sein. Außerdem hab ich beschlossen ich mach n Tutorial darüber, sobald
ich Zeit hab und es hinbekommen hab =/ es kann ja wohl ned sein, dass
das so kompliziert ist ^^ ich hab für den AVRGcc ganze 10 min und nen
Neustart gebraucht. Dann lief er. Ich weiß das jetzt echt zu schätzen =)
Gruß ErgoProxy
Ergoproxy ist das Vista? irgendein bestimmtes Theme? sieht hübsch aus
Ne das ist ne Eigenkreation ^^ das ist XP mit nem Thememanager und n paar Anpassungen. Die standart Themen von Xp find ich nerven mit der Zeit. Leider hab ich bisher auch keine weiteren Fortschritte gemacht was das Compilieren betrifft. Gruß ErgoProxy
könntest du mir das themenmanager prog verraten und das theme von dem du es abgeleitet hast? :)
Mach ich wenn ich es nachgeschaut hab ^^ hab es vor über nem Jahr erstellt. Leider weiß ich nicht mehr so genau was für ein Theme das war oder woher ich es hatte. Ich weiß nur ich hab irgendwas auch noch dran verändert wobei das glaub ich nur die Farben und die Icons waren. Na mal sehn ich schau es nacher nach. Werds schon wieder finden. Mal ne Frage noch: Braucht man beim ARM ein makefile und woher bekomm ich ein Grundmakefile? Ich glaube mir fehlt das die ganze Zeit. Gruß ErgoProxy
Hm hab grade mal geschaut es müsste das Prog "StyleXP" von TGTSoft sein. Das Theme muss ich mal suchen leider stürzt das Programm dauerhaft ab wenn ich versuche es zu öffnen =/ außerdem ist es leider keine Freeware aber soviel ich weiß gab es mal ein Programm, dass es erlaubte die Themes auch ohne StyleXp zu öffnen und zu nutzen. Ursprünglich war es wohl mal von ThemeXP.org und hatte möglicherweise den Namen "Wisp" leider finde ich darunter nix mehr und die genauen Einstellungen kann ich nicht mehr nachsehn, da das Prog leider streikt. Gruß ErgoProxy
Zwar benutze ich (fast) ausschließlich veraltete, langsame, tückische, praktisch schon ausgestorbe und vor allem unbeherrschbare Controller. Einen Link habe ich trotzdem anzubieten: http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/index_cortex.html (Ganz unten)
@Andreas K.: Probier mal: arm-none-eabi-gcc -o hello hello.c -T arm.ld -Wl,--gc-sections
Vielen Dank ^^ er macht etwas, ohne Beschwerden. Er hat eine Datei ohne
Endung angefertigt (befindet sich im Anhang). Eigendlich dachte ich es
wöre die Datei die er zum testen erstellen sollte aber
>arm-none-eabi-run hello
gibt ein:
arm-none-eabi-run: no loadable sections "hallo"
Sry wenn die Frage blöd ist aber ich bin relativ am Ende mit meinem
Latein werde jetzt erstmal nach den Erweiterungen schauen die du mir
geschreiben hast und was sie bedeuten( -Wl,--gcsections )
Falls jemand Zeit hat könnte er mir schreiben was für eine File das ist?
Hexfile scheint es nicht zu sein. Dafür scheint mir das Hex etwas zu
"komisch" zu sein. Irgendwie muss ich dringend mein Wissen über
Komandozeilen aufbessern. Nach dem Abi wird erstmal ein Intensivkurs
Linux eingelegt ^^
Gruß ErgoProxy
Das ist ein ausführbares Programm. Damit kann man erstmal gar nichts tun, da es kein Betriebssystem gibt das diese Datei ausführen könnte. Aber was soll das hello.c deiner Meinung nach tun bzw. wohin soll der Text geschrieben werden? Ohne Betriebssytem gibt es kein stdout. Das "gc-sections" kannst du erstmal vergessen. Damit wird der Linker angewiesen nicht verwendete Sektionen wegzulassen. Das ist eine Optimierung um (Flash-)Speicher zu sparen, was auch nur dann sinnvoll ist wenn die Objektdateien mit "-ffunction-sections" und/oder "-fdata-sections" erzeugt wurden. Besorge oder baue dir erstmal ein Testboard - ob nun M3 oder ARM7 ist zunächst egal - und bringe eine LED zum Blinken. Der M3 ist etwas schneller (bei gleichem Takt) und auch etwas einfacher aber dafür wesentlich weniger verbreitet und dementsprechend gibt es weniger Beispiele und Hilfe in den Foren sodaß du mit einem ARM7 wahrscheinlich schneller ins Ziel kommst. Andererseits gibt es gerade von Luminary (M3) sehr günstige und leistungsfähige Boards für den Einstieg (LM3S6965). Der STM32 ist IMHO für den industriellen Einsatz besser geeignet als Luminary (die Umsatzzahlen zeigen das auch) aber für den Hobbylöter sind die Stellaris Controller vermutlich angenehmer. Wenn du Platinen für SMD (0.5mm Raster) selber machst hat der ARM7 den Vorteil das er leichter zu beschaffen ist (Reichelt, csd-electronics). Verfügbare Derivate wären hier LPC21xx und AT91SAM7xxx, wobei sich die LPCs durch ihre fest installierten Bootloader unkompliziert und ohne besondere Hardware (JTAG) programmieren lassen. Als Hobbybastler hast du die freie Auswahl. Als Profi kommst du am ARM7 Stand heute nicht vorbei (wir reden über 32Bit Controller). Es gibt einfach zu wenige M3 Derivate. Dem M3 mag die Zukunft gehören, doch wir leben in der Gegenwart. Das der M3 einfacher zu handhaben ist bringt nur oberflächlich betrachtet einen Vorteil. 32Bit Controller setzt man üblicherweise dort ein wo sie auch gebraucht werden. Und da hat man es i.d.R. mit einer Komplexität zu tun wo die Unzulänglichkeiten des ARM7 gegenüber dem M3 geradezu lächerlich erscheinen. Oder anders ausgedrückt: Wem der ARM7 zu kompliziert ist, dem hilft auch ein M3 nicht. PS: Ein Vorteil des M3 gegenüber dem ARM7 wird von den M3 verfechtern erstaunlicherweise gerne vergessen: Der M3 kann auf ungerade Adressen zugreifen. Beim ARM7 würde man sich ein "Data abort" einhandeln. Die kürzere Interruptlatenz wird dagegen ständig erwähnt obwohl sie in der Praxis eine untergeordnete Rolle spielt. Meiner Meinung nach ist das ein Indiz dafür das diese Leute sich nie wirklich mit dem ARM7 befaßt haben, sondern nur den Kaufleuten von ARM nachplappern.
Also als Erklärung warum ich versuche die Software hinzubekommen: Die hardware habe ich leider noch nicht und die Software muss ich eh irgendwann installieren und außerdem muss das Compilieren auch ohne Targetboard gehen. Wenn das die Hexfile ist, die später nur in den µC muss, dann ist das alles was ich will. Ich wollte nur ein sehr einfaches (Das Programm ist aus der Doku der Toolchain sollte also gehen) kompilieren, was mir ja schon einige Schwierigkeiten beschert hat. Ich bin leider nicht gut mit Komandozeilen Tools, da die etwas vor meiner Zeit waren und ich auch niemand hab wo ich es lernen könnte bzw ich habe es bisher nur 2 mal gebraucht um ne zerschossene Bootscreendatei von XP per Dos auszutauschen. Aus der Doku der Chain hab ich außerdem, dass es eigendlich einen art Debugger geben soll der diese Hexfiles einlesen können soll. Brauchen tu ichs nicht und gehen tut es wohl auch nicht ^^ ist mir aber egal solange die Hexfile da ist. Ich hab prinzipiell weniger Probleme mit der Hardware oder den Programmen, als mit dem Aufsetzen der Toolchain, da ich wie gesagt da die wenigste Erfahrung hab. Wollte einfach die Zeit etwas sinnvoll nutzen =) Na bis die Hardware da ist werd ich dann wohl mal an meinem IDE interface weiterarbeiten. Das Sektorlesen fehlt noch. Bisher hab ich nur die ganzen Register usw. Aber es stimmt EIDE ist echt sehr simpel =) Gruß ErgoProxy p.s. Vielen Dank nochmal an Alle hier =)
let wrote: > Das ist ein ausführbares Programm. Damit kann man erstmal gar nichts > tun, da es kein Betriebssystem gibt das diese Datei ausführen könnte. Aber einen in GDB integrierten Simulator, der mit *-run aufgerufen wird. Siehe auch Using arm-elf-run.
@Andreas K. Die Fehlermeldungen bekommst Du, weil du die stdio.h eingebunden hast. Für die stdio.h benötigst Du einige syscalls für _read_r, _write_r, ... Ein Beispiel hier: http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/index.html#gcc_stdio
Beitrag #6768140 wurde von einem Moderator gelöscht.
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.