www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Einstieg 32Bit µC - Welche "Familie"


Autor: Andreas K. (ergoproxy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jakob (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mathi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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_summ...

Noch günstiger, JMBADGE:
http://www.freescale.com/webapp/sps/site/prod_summ...

Autor: Mathi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!)

Autor: Frohnatur (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ...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?

Autor: Jakob (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Thorsten S. (thorsim)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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?

Autor: DrShorsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Moritz E. (devmo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Moritz E. (devmo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas K. (ergoproxy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: K. J. (theborg0815) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, kann Cortex M3 von Luminary empfehlen, viel Peripherie, gute 
Library, gutes Datenblatt. Funktioniert mit Keil und ULink JTag Debugger 
fast problemlos.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Karl M. (movex)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas K. (ergoproxy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Sebastian B. (mircobolle)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jakob (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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/ .

Autor: DrShorsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: escapete (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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"

Autor: Jakob (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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? ;)

Autor: Moritz E. (devmo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/... 
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?

Autor: Michael B. (bubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas K. (ergoproxy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: eigendlich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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/e...

Also: Eigentlich noch viel Spaß mit deinen 32 Bittern.

;-)

Autor: Michael B. (bubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> @ 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

Autor: Patrick Weinberger (seennoob)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/Dhryst...

Autor: Andreas K. (ergoproxy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Moritz E. (devmo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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".

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Andreas K. (ergoproxy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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=de...

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

Autor: Andreas K. (ergoproxy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
#include <stdio.h>

int
main (void)
{
  printf("Hello World!\n");
  return 0;
}

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

Autor: Reiner L. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Helfen kann ich Dir zumindest beim Datenblatt, da warst schon sehr nahe 
dran, schau mal unter Referenz Manual(RM0008).

Gruß Reiner

Autor: Jakob (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas K. (ergoproxy)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@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:
#include <stdio.h>

int
main (void)
{
  printf("Hello World!\n");
  return 0;
}

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

Autor: devmo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ergoproxy ist das Vista? irgendein bestimmtes Theme? sieht hübsch aus

Autor: Andreas K. (ergoproxy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Moritz E. (devmo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
könntest du mir das themenmanager prog verraten und das theme von dem du 
es abgeleitet hast? :)

Autor: Andreas K. (ergoproxy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas K. (ergoproxy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Moritz E. (devmo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Info, ich guck mal was ich darunter finde :)

Autor: let (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

(Ganz unten)

Autor: Jakob (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andreas K.:

Probier mal:
arm-none-eabi-gcc -o hello hello.c -T arm.ld -Wl,--gc-sections

Autor: Andreas K. (ergoproxy)
Datum:
Angehängte Dateien:
  • hello (3,38 KB, 118 Downloads)

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: let (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas K. (ergoproxy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 =)

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mario Pieschel (mariopieschel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.