Druckbare Version
Hi und Servus, *:-)*
ich bin am überlegen auf C zu wechseln.
Auf die Idee kam ich bei der Suche nach einer neuen CPU.
Ich bin auf den AT91RM9200 (ARM9-µC) von Atmel gestossen.
Das "Ding" würde mich interessieren.
Kann ich so einen µC auch mit "WinAVR" programmieren oder brauche ich dafür ein eigenes "C"
Gruß Manuel
Ein ARM ist kein AVR ;-)
Schon daran erkennbar, daß ARM 32-Bit-Controller sind.
arm-elf-gcc ist verfügbar (Frontend C/C++)
@SprinterSB
Dich trifft man ja überall!!! *:-) grins*
Du scheinst Dich auch überalllll auszukennen.
Hast Du mit einem ARM7 oder ARM9 schon gearbeitet?
Ahh, noch ne Frage:
Ich habe gelesen das ich zum Programmieren gar keinen Prommer brauche, da soll die serielle Schnittstelle langen. Stimmt das???
Aber ein JTAG-Prommer/Debagger ist bestimmt besser - oder???
Sonst findet man ja keinen Fehler.
Kannst Du einen JTAG-Adapter empfehlen und ne Software dazu?
Gruß Manuel
Schau mal da, vielleicht sind da Tipps dabei:
http://www.sparkfun.com/cgi-bin/phpbb/index.php
Empfehlung kann ich keine aussprechen.
Ich nochmal,
hi SprinterSB, noch ne Frage: *Sorry*
Was hälst du von der Software: http://www.rowley.co.uk/arm/index.htm
Gruß Manuel
Sieht ganz brauchbar aus. Evaluiere das doch mal 30 Tage, steckt ja nix drin... Vieles kannst du auch ohne Board schon sehen.
Möglicherweise wird GCC nur extern eingebunden, und du musst den besorgen/generieren zusammen mit binutils und libc.
Daß das unter Win und Linux läuft ist schon mal gut.
Was soll's denn mal werden?
Hmmm, zwei Sachen sollens werden.
Einmal mich interessieren die ARM einfach, hatte sonst immer mit ATTinys und ATMegas gearbeitet (in Basic und a bisserl ASM)
C ist Neuland für mich! (Kenn noch Pascal und Java - aber nur vom PC)
Und ZWEI
Will mir demnächst einen neuen Robi bauen. Meinen Alten hab ich zerlegt! *:-)*
Ich hab da ne ganz neue Idee (für mich zumindest, weis nicht ob jemand anders so etwas schon gebastel hat).
Ich möchte meinen Robo so bauen als ob er intern aus lauter kleinen Robis bestehen würde.
d.h.
Für jede Aufgabe ein eigener µC (z.B. einer für das linke Rad, einer fürs Rechte, einer für die Lenkung, usw.) und der ARM
soll als Gemeinsames "Gehirn" und "Datensamler" arbeiten.
Da jedes Teil selbstlernen sein soll, werden schon ne ganze menge Daten anfallen.
Deshalb möchte ich am ARM ne SD-Karte anschliessen (1GB) um die Daten zu "lagern".
Das ganze soll so funktionieren:
- alle µC können über IC2 miteinander komunicieren
- Verbindung über 5 Adraht-Bus (2 x Betriebsspg., 2 x Daten, 1 x Alarmleitung)
- der ARM stellt die Aufgabe und sammelt die Daten
- und jeder µC versucht für sich die Aufgabe zu lössen
- Kammera System zur orientierung soll auch der ARM verwalten.
Gruß Manuel
Wenn du die AVRs schon kennst und auf GCC umsteigen willst, dann ist es keine schlechte Idee, dir mal den avr-gcc anzuschauen und damit zu arbeiten.
Die Toolchains für verschiedene Targets sind von der Benutzung her praktisch gleich, so daß ein Umstieg auf arm-gcc nicht so holprig wird.
GCC ist zwar ein starker Compiler, aber wenn du von BASCOM oder so kommst, wirst du erst mal Startschwierigkeiten haben. Ganz brauchbar scheint das AVR-Studio 4.12 mit avr-gcc Integration zu sein (nur Windofs).
Mit BASIC schafft man recht gut den Einstieg, hat umfangreiche Bibliotheken, etc. Mit nem GCC ist das zunächst mal nicht so. Aber für dich sind das bestimmt olle Kamellen...
Viele Sachen kannst du schon auf AVR implementieren/testen, etwa ein multimasterfähiges I²C-Netzwerk. Wenn du ne gescheite Implementierung machst und richtig von der zugrundeliegenden Hardware abstrahierst, kannst du viel von dem Code mit zum ARM rüber nehmen. Dito für SD-Card.
Schon mal dran gedacht, das andersrum zu machen? Also die Datensammler sind Master, die zB Sensordaten schicken können, und das Hirn ist Slave (Server). Das spart Rumpollen und macht Bandbreite auf den Sammlern frei.
So was wie 'Alarm' gibt's auch in I²C: Global Call (Adresse 0).
Abend,
also ich fange jetzt mal an mit C auf meinen ATMega32 mit WinAVR bzw. AVR Studio 4.12.
Habe nämlich gesehen das C für den ARM doch ein bisserl verzwickter ist.
Wie verhält sich das jetzt eigendlich genau mit dem prommen von HEX in einen ARM?
Geht das jetzt Seriel oder brauch ich einen JTAG-prommer - die einen schreiben so und die anderen wieder andersrum?
Wenn ich dann auf einen ARM wechsle dann auf einen ATMEL
Danke vorweg
Gruß Manuel
Hi,
noch ne Frage.
Kennt jemand ein gutes Anfängerbuch für WinAVR bzw. einen OnlineKurs.
Soll aber für "echte" Anfänger sein.
Ich kenne mich zwar einigermassen mit Programmieren im algemeinen aus, aber ich kenne weder WinAVR noch die Syntax von C.
Gruß Manuel
Wenn dir C unbekannt ist, dann versuch's mal mit nem (host) gcc, ist ja bei Linux dabei und bei MinGW.
Damit kannst du besser C lernen als auf nem kleinen AVR. Du musst nicht immer den lästigen Download machen und kannst einfach mit printf() Meldungen auf Console ausgeben.
C mit avr-gcc sieht nicht anders aus, nur daß man *etwas* mehr auf den Resourcen-Verbrauch achten sollte und wissen, welche SFRs man anfasst um was zu machen.
Für ARM nimmt man elf zum flashen, da braucht man kein ihex.
zwei fragen noch.
Was ist SFRs??
und
den letzten satz verstehe ich nicht "elf zum flachen, kein ihex"
weis heisst das den - die abkürzungen kenne ich nicht - sorry
gruß manuel
oops, Verzeihung
SFR = special function register (zB SREG und die ganzen Register für I/O, Peripherie, ...) im Gegensatz zu
GPR = general purpose register (bei AVR R0 bis R31)
ihex = Intex HEX-Formal
elf = extended library format
Neue GCCs erzeugen Objects im ELF-Format, auch avr-gcc (genauer:avr-as und avr-ld). Die meisten billigen Tools wollen aber iHEX zum flashen, teilweise auch srec oder bin, alte teilweise noch aout.
In den Toolchains gibt es ein xxx-objdump, mit denen man elf in iHEX und anderes Zeugs umwandeln kann.
HEX ist ein lowlevel-Format und kann eigentlich kaum was. In ELF steckt viel mehr Info, wie debug-Informationen, etc.