Hallo an alle

Habe vor mir ein Board mit einen ARM Controller zu besorgen! Dachte
zuerst an einen ARM 7. Habe nun aber ein Board gesehen mit einen ARM
Cortex M3. Dieses heist:

Luminary LM3S6965 Ethernet Eval board

Habe im Forum schon gelesen das manche das Board schon haben und wollte
Fragen was die Leute so dazu sagen! Ich will einerseits ganz normal fürs
Board Programmieren (mit Interrupts, usw.) als auch versuchen mittels
eines RTOS zu arbeiten und wollte daher Fragen ob das jemand schon
versuht hat??

Danke schon mal im vorhinein für die Antworten und Erfahrungsberichte!

MFG Harald

Hallo

Hat keiner Erfahrungen mit diesen Board? Das ist doch ein schlechtes
Zeichen!

MFG Harald

Ich habe das Kit hier (inkl. dem kleinen CAN "Tochterboard"). Macht
einen guten Eindruck. Beispielanwendungen recht schick (v.a. das Spiel
mit Status über Ethernet) und vieles gut Wiederverwendbar. Dokumenation
der DriverLib findet man bei Luminarymicro, man kann sich also darüber
schon vor dem Kauf informieren. Fehlfunktionen bisher keine festgestellt
aber auch noch nicht viel damit gemacht ausser einige
Beispielanwendungen compiliert, "geflasht" und getestet.

Ich habe ebenfalls das EK-LM3S6965. Ist an sich ganz in Ordnung und man
kann es als normalen JTAG-Adapter benutzen.
Mit Hilfe der DriverLib von Luminary kommt man auch sehr schnell zum
Ziel beim Programmieren. Als IDE benutze ich CrossWorks.
Als RTOS gibt es einen Port von FreeRTOS für die Cortex-M3.

Hier auch eine Bezugsquelle :-)
http://watterott.net/shop/index.php?cat=c12_Entwic...

@ Martin Thomas
Du hast bestimmt das EK-LM3S8962 mit CAN und den 8000er Stellaris
Controllern?

Hallo

DANKE für eure Erfahrungsberichte! Das Board ist anscheinend für den
Hobbygebrauch wirklich gut und vorallem auch sehr preiswert (55€)!

Vielleicht hat ja noch jemand erfahrungen mit den Board gesammelt!

MFG Harald

Ich nutze das 1968er. Ist allerdings ohne Ethernet.

Ich programmiere das mit dem freien GCC von Codesourcery und FreeRTOS.
Dank der guten Library von Luminary ist das für den Einstieg ein
Kinderspiel.
Den ARM7 hatte ich zuerst auch im Auge, der ist aber mit zu vielen
Nachteilen behaftet.
Seit kurzem gibt es von Luminary übrigens auch Controller mit USB OTG
sowie DMA. Ist also für fast jeden was dabei.

Kauf Dir das Board, ist keine Fehlinvestition.
Fragen kannst Du hier immer stellen, sind ja einige Leute hier, die sich
damit auskennen.

Hallo

Ja denke mir auch das das board keine Fehler ist vorallem sind auch alle
ADC undPWM Anschlüsse herausgeführt so das sie verwendet werden können!
Es sollte ja auch möglich sein über eine zusatzplatine eine weitere RS
232 Schnittstelle zu erhalten und mittels eines CAN Phy Can zu
integrieren falls man es mal braucht!? Hatte bisher nur mit C167
Controllern zu tun sowohl mit OS als auch ohne!

MFG Harald

>@ Martin Thomas
>Du hast bestimmt das EK-LM3S8962 mit CAN und den 8000er Stellaris
>Controllern?
Ja stimmt, Bezeichnung des Kits hier ist EKC-LM3S8962. Habe also nicht
ueber das Kit geschrieben, nach dem gefragt wurde. Sorry.

Hallo

Habe dieses Board mit CAN jetzt auch gesehen! Wenn ich das ganze richtig
verstehe ist da ein zweites Board dabei welches auch über can verfügt
mit den ich dann ein kleines CAN Netzwerk aufbauen kann mit den Eval
Board!? Ist zwischen den controllern selber auch ein Unterschied ausser
CAN?!

MFG Harald

Der Unterschied liegt eigentlich nur im CAN und dem zweiten Board.

Die 55 Euro für ein EK-LM3S6965 weiter oben sind aber ohne MWSt. oder?

Wir haben uns letztlich auch die Boards in einer Sammelbestellung
organisiert.
Jeder hat 59,- Euro inklusive Versand, Zoll, EUSt gezahlt. Je nach Kurs
kommen die 55,- also schon hin, wenn das über eine Sammelbestellung
läuft.

Hallo
Ja die Preise sind ohne MwSt und ohne Versand (der ist jedoch bei einer
Bestellung ab 150€ auch Gratis!). Zusätzlich gibt es nochmals 12% Rabatt
für Studenten! Daher überlege ich mir schon das LM8962 mit CAN und
zusätzlichen CAN Board zu nehmen! Kostet zwar nochmals 20€ also ca 70€
aber es kann halt auch mehr!

Die Preise sind übrigens bei Farnell.

MFG Harald

Alles klar. Dann sind die Preise bei meinem Bruder doch nicht so
schlecht:
EKK-LM3S6965 - 60 Euro
EKK-LM3S8962 - 80 Euro

@Andreas

Ja die Preise bei deinem Bruder sind eh in Ordnung aber ich wohne in
Österreich und daher ist für mich Farnell günstiger!

MFG Harald

Was haltet ihr denn von der Architektur des LM3S6965? Ich überlege seit
einiger Zeit, mich für ein netzwerkfähiges Projekt mit einem
Cortex-Prozessor anzufreunden, kann mich aber nicht so recht zwischen
STM32 und Luminary entscheiden. Meine bisherige Version läuft auf AVR
mit ENC28J60.

Was mich am LM3S6965 etwas skeptisch macht, ist die Kombination von
100Mbit LAN und nur 2k FIFO ohne DMA-Controller. So können Daten von
außen im Vergleich zum ENC ziemlich schnell angeliefert werden, die
Puffergröße ist jedoch nur ein Viertel des ENC-Puffers. Die restliche
Applikation ist relativ rechenintensiv und muß auch größere Datenmengen
an SPI-Peripherie ausgeben (auch dafür wäre ein DMA nett...), deshalb
befürchte ich, das Fehlen eines DMAs könnte dazu führen, daß der
Prozessor zu viel Zeit damit beschäftigt sein könnte, ohne Datenverlust
den Netzwerkverkehr abzuarbeiten. 10 MBit würden mir eigentlich reichen,
deshalb tendiere ich zu einer Kombination von STM32 und ENC28J60.

Daß Luminary jetzt auch Controller mit DMA angekündigt hat, ist schön,
die Kombination DMA und Ethernet fehlt jedoch leider - oder hab ich das
was übersehen?

Der LM3S6965 hat aber 64kb RAM und läuft mit bis zu 50 MHz. Damit kann
man jede Menge Daten zwischenspeichern. Alle Schnittstellen (SPI, UART)
haben auch einen FiFo...

Warum willst Du eigentlich umstellen? Ist AVR + ENC zu langsam?

Eine Alternative wäre auch AVR32 AP7000?
Entweder von ATMEL NGW100 z.B. oder dieses hier:
http://www.ic-board.de/product_info.php?info=p75_I...

Das NGW läuft vorkonfiguriert schon als Router (Beispielanwendung) mit
embedded Linux.
Auf dem IC-Nova läuft auch embedded Linux.
Der AVR32 hat DMA zu seiner Peripherie und auch sonst jede Menge auf dem
Chip.

Umstellen will ich, weil für neue Features etwas mehr Dampf unter der
Haube nötig wäre.

NGW u.ä. wären für ein Hobbyprojekt natürlich nett, es handelt sich aber
um ein kommerzielles Produkt, wo ich mich nicht drauf verlassen müssen
will, daß Atmel oder jemand anderes ein bestimmtes Entwicklungsboard
auch noch in 5 Jahren und zu ähnlich subventionierten Preisen herstellen
wird. Und im Vergleich zum AVR32 gefällt mir an dem LM, daß eben die PHY
schon mit integriert ist (sowohl aus Platzgründen als auch, weil PHYs in
kleineren Stückzahlen mindestens so teuer wie ein ganzer ENC28J60 sind).

Haltet ihr das Fehlen eines DMAs also nicht für einen Mangel/ein
Problem? Ich meine, 2K Fifo ist natürlich besser als nichts, aber wenn
ein eingehendes Netzwerkpaket per Interrupt einfach nur einen
DMA-Transfer des neuen Pakets auslöst und der Controller sich inzwischen
wieder anderen Dingen zuwenden kann, das käme mir schon irgendwie
eleganter vor als jedesmal den Programmfluss für eine manuelle
Kopieraktion unterbrechen zu müssen?

Noch eine andere Frage: Wie seht ihr denn die Zukunftssicherheit bei so
einem Startup-Hersteller wie Luminary? Für mich macht das schon etwas
den Eindruck, daß da momentan ein paar finanzkräftige Investoren den
Betrieb am Laufen halten. Wie gut es LM (aktuell oder zukünftig)
schafft, auch echte Marktanteile zu erobern, ist mir bisher noch nicht
klar. Wenn also in zwei Jahren die Investoren beschließen sollten, den
Hahn zuzudrehen, dann hätte ich ein kleines Problem. Gut, ST oder Atmel
oder... können natürlich theoretisch auch mal beschließen, eine
Produktlinie einzustellen, das ist aber denke ich schon wesentlich
unwahrscheinlicher. In meinem Bereich gibt es sehr lange Produktzyklen
und ich habe wenig Interesse, alle zwei Jahre die Platform zu wechseln
:) Deshalb: Haltet ihr es für kommerzielle Produkte für riskant, auf
Luminary zu setzen?

>Noch eine andere Frage: Wie seht ihr denn die Zukunftssicherheit bei so
>einem Startup-Hersteller wie Luminary? Für mich macht das schon etwas
>den Eindruck, daß da momentan ein paar finanzkräftige Investoren den
>Betrieb am Laufen halten.

Tja, hellsehen kann hier wohl keiner...
Momentan ist Luminary aber Marktführer im M3-Bereich, sie sind ja auch
die ersten und haben die meisten Controller, mindestens 106
verschiedene.
Konkurrenz kommt wohl erst mit NXP im 4. Quartal dieses Jahres auf den
Markt.
ST hat (noch) nicht viel zu bieten, insbesondere wenig RAM, und Toshiba
hat noch nichts vorzuzeigen.

Was die Investoren angeht:
http://www.luminarymicro.com/about_luminary/investors.html


>Wie gut es LM (aktuell oder zukünftig) schafft, auch echte Marktanteile
>zu erobern, ist mir bisher noch nicht klar. Wenn also in zwei Jahren
>die Investoren beschließen sollten, den Hahn zuzudrehen, dann hätte
>ich ein kleines Problem.


Wenn bis dahin der Laden brummt, können die Investoren den Hahn ruhig
abdrehen... ;)
Aber auch hier: Hellsehen kann keiner.
Alternative ist für Dich wohl nur, auf die NXP-Controller zu warten.
Allerdings kostet Dich das dann mindestens 1 Jahr.
Ob es das wert ist, kannst nur Du beurteilen.

Ich weiss nicht so recht ob Luminary Marktfuehrer ist, die haben zwar
die meisten Derivate aber bei ST laeuft schon jetzt ne ganze Menge. Das
Fehlen der Ethernet Schnittstelle ist allerdings nicht so schoen.

Mir ist trotzdem entgangen, was denn sooo toll ist am M3. Keine Frage,
er stellt eine graduelle Verbesserung des ARM7 dar aber definitiv keinen
Sprung. In Punkto Performance ist es sehr wenig, der STM32 kann sich so
gerade mal mit dem LPC23xx messen. Ein grosser Unterschied beteht dann,
wenn der halbe Benchmark aus Divisionsbefehlen besteht (wie viele der M3
Benchmarks), denn der M3 hat den in Hardware, der ARM7 muss das mit
einen LIB Funktion erledigen.
Es ist richtig, dass der Interrupt Controller des M3 besser ist als der
des ARM7 aber entschuldigt meine Frage, wo benoetigt ihr eine
Reaktionszeit <1uSekunde?
Solltet ihr ein OS benuetzen, dann sprechen wir sowieso von anderen
Dimensionen in der Taskwechselzeit.

Das Code (In-)Kompatibilitaet kommt irgenwie nie hoch hier im Forum. Der
M3 ist nicht kompatibel zu allen enderen existierenden ARM Bausteinen am
Markt, denn er unterstuetzt den ARM Mode nicht. Das macht ihn einfacher
in der Handhabung, ein nicht zu unterschaetzender Vorteil, doch all die
Terrabytes an existierender ARM Software laufen nicht ohne Aenderungen.

Meine ehrliche Meinung:
Die LPC23xx und SAM7X bieten ein besseres Preis/Leistungsverhaeltnis als
die existierenden M3 Teile und sie sind auch etwas (nicht viel ;-)
ausgereifter.
Leider wurde das Feature Power Saving von den bestehenden Bausteinen
noch nicht so richtig genuetzt, die Atmel SAM7 und NXP LPC2000 koennen
da durchaus noch mithalten.

fwiw, Robert

>die meisten Derivate aber bei ST laeuft schon jetzt ne ganze Menge.
>Das Fehlen der Ethernet Schnittstelle ist allerdings nicht so schoen.


Das Fehlen von mehr RAM ist auch "nicht so schön"!


>Mir ist trotzdem entgangen, was denn sooo toll ist am M3. Keine Frage,
>er stellt eine graduelle Verbesserung des ARM7 dar aber definitiv keinen
>Sprung. In Punkto Performance ist es sehr wenig, der STM32 kann sich so
>gerade mal mit dem LPC23xx messen. Ein grosser Unterschied beteht dann,
>wenn der halbe Benchmark aus Divisionsbefehlen besteht (wie viele der M3
>Benchmarks), denn der M3 hat den in Hardware, der ARM7 muss das mit
>einen LIB Funktion erledigen.
>Es ist richtig, dass der Interrupt Controller des M3 besser ist als der
>des ARM7 aber entschuldigt meine Frage, wo benoetigt ihr eine
>Reaktionszeit <1uSekunde?
>Solltet ihr ein OS benuetzen, dann sprechen wir sowieso von anderen
>Dimensionen in der Taskwechselzeit.


Klar, wenn ich Windows CE einsetze, ist mir alles Wurst.

Andernfalls möchte ich schon wissen, wann ein Interrupt bearbeitet
werden kann. Und mich nicht mit spurious interrupts rumschlagen.
Zudem hast Du noch ein paar andere wesentliche Verbesserungen
unterschlagen:
- bit banding
- ich muss mich nicht zwischen Geschwindigkeit oder Platz entscheiden
- Speicherschutz (gerade bei OS-Nutzung wichtig)

"Graduelle Verbesserung" ist also stark untertrieben. Die meisten
Designfehler sind raus!


>Das Code (In-)Kompatibilitaet kommt irgenwie nie hoch hier im Forum. Der
>M3 ist nicht kompatibel zu allen enderen existierenden ARM Bausteinen am
>Markt, denn er unterstuetzt den ARM Mode nicht. Das macht ihn einfacher
>in der Handhabung, ein nicht zu unterschaetzender Vorteil, doch all die
>Terrabytes an existierender ARM Software laufen nicht ohne Aenderungen.


Natürlich ist das ein Thema. Aber die Krücke Thumb/Nicht-Thumb sollte
man lieber gestern als heute loswerden, das ist doch ein totaler
Anachronismus. Thumb2 wird auch in den anderen Cortex-Controllern (M1,
A8/9) eingesetzt, ist somit kompatibel!
Damit ist das auch keine Sackgasse.


>Meine ehrliche Meinung:
>Die LPC23xx und SAM7X bieten ein besseres Preis/Leistungsverhaeltnis als
>die existierenden M3 Teile und sie sind auch etwas (nicht viel ;-)
>ausgereifter.


Immerhin hat NXP auch - wenngleich sehr spät - die Zeichen der Zeit
erkannt und steigt in den Markt ein.
Die Zukunft gehört definitiv den Cortex-Controllern. In 5 Jahren werden
die Arm7/9 eine Randgruppe bilden.
Warum also jetzt noch auf Altmetall setzen?

@Dirk,

ich hab noch viele andere Verbesserungen unterschlagen wie z.B. deutlich
bessere Debug Unterstuetzung. Meine Einschaetzzung von einer graduellen
Verbesserung belibt allerdings bestehen wenn man bedenkt, dass sich
zwischen dem M3 und dem ARM7 ca. 16 Jahre Entwicklung befinden und
dafuer eine Performance Steigerung von nahe "0" erreicht wird!?

Mir ist bekannt, dass der M3 nicht fuer Performance gemacht wurde,
allerdings ist das mit dem Speicherschutz auch eher Kosmetik als ernst
zu nehmen fuer OSs.

Bezueglich ST, also ich habe bereits einen 512k/64k chip in der Hand
gehalten.

Ich denke mal, dass der ARM7 in 5 Jahren aehliches "Altmetall" ist, wie
der seit 20 Jahren totgesagte 8051, der inzwischen stolze 29 Jahre alt
ist und immer noch in vielen neuen Designs Einsatz findet.

Der Cortex M3 ist in erster Linie eine grosse Einnahmequelle fuer ARM,
nicht eine technische Notwendigkeit fuer den Anwender.

Nur zur Klarstellung, ich habe vor 3 Jahren bereits bei NXP bzw. damals
Philips fuer die baldige Einfuehrung des Cortex M3 gekaempft, allerdings
gab es damals eine Mehrheit dafuer, noch eine Weile mit dem ARM7
weiterzumachen. Diese Entscheidung war aus heutiger Sicht vielleicht
nicht mehr so werbewirksam aber wohl dennoch nicht verkehrt.

Kompatibilitaet: Der M3 ist kompatibel, richtig, mit allem was kommen
wird und mit nichts was bereits existiert. Kompatibilitaet ist
normalerweise mit "backwards compatible" definiert. Das ist so aehlich
wie einen x86 zu bauen, der mit allem was kommt kompatibel ist aber mit
allem was bereits da ist nicht!?!?

ARM / Thumb mode versus Thumb2. Ich gebe Dir vollstaendig recht, Thumb2
gehoert die Zukunft, ist fast so klein wie Thumb und fast so schnell wie
ARM mode, also ein sehr gelungener Kompromiss. Aller existierender Code
beinhaltet auf jeden Fall ARM mode, denn damit startet der Prozessor und
dieser Mode ist genau der, den der M3 nicht hat. Also ist er mit aller
existierenden Software inkompatibel, wir sprechen von tausenden von
Mannjahren. Jetzt muessten also hunderte von Mannjahren investiert
werden um diese Codesammlungen auf eine Architektur zu bringen, die in
vielen Bereichen, meist kleine Verbesserungen bringt. Glaubst Du allen
Ernstes, dass die Grossunternehmen, die bereits viele Programme auf dem
ARM7 haben zum M3 wechseln?

Fuer voellig neue Projekte wuerde auch ich den M3 empfehlen, doch der
ARM7 wird meiner Meinung nach auch in 10 Jahren noch in vergleichbarem
Volumen gefertigt wie der M3.

May be we should agree to disagree ;-) (Ist in deutsch zu lang)

<EOM> Robert

Hallo

Na das ist hier ja richtig zu einer Grundsatzdiskussion geworden! Ich
benutze das Board nur Privat daher werde ich gleich zum M3 greifen da er
ja doch der logische Nachfolger des ARM 7 ist! Hatte bis jetzt nur mit
den C167 von Infinion zu tun und da ist der M3 sicherlich ein großer
schritt nach vorne! Vorallem sind die Luminary Boards recht günstig und
man benötigt kein extra Netzteil und keinen JTAG Programmer!
MFG Harald

Die Stellaris Controller sind sicher eine gute Wahl für den
Einstieg. Luminary ist mit den Teilen für den Kampf gegen die
8/16 Bitter ins Feld gezogen und irgendwann werden sie auch
die eigentlichen Einsatzgebiete des ARM7 erreichen. Der Privatmann
kann hier die Zeit für sich arbeiten lassen.

Aber noch gehört die untere 32Bit Welt dem ARM7. Die Daten der
genannten Luminary Teile lesen sich zwar auf den ersten Blick
sehr gut, doch handelt es sich bei denen um die Flagschiffe der
Stellaris Reihe.
256k/64k, 100Pins mit max. 56 GPIOs - das war es dann. Wem das nicht
reicht hat Pech gehabt. I2S? externer Speicher? Gibts nicht.
Zahlreiche Projekte wo es wirklich drauf ankommt lassen sich
Stand heute nicht mit den M3 Derivaten nicht realisieren.
(Zum Vergleich: Der LPC2468 hat 160 GPIOs und ein EMI)

Nicht vergessen sollte man auch die Erratas. Das Dokument zum
M3 umfaßt stolze 48 Seiten. Hier stehen Fehler gegen Designschwächen.

Stichwort Geschwindigkeit: Bei einem Desktop PC sollte die CPU
so schnell sein wie möglich.
Doch bei Mikrocontrollern gilt eine andere Regel: Er muß nur schnell
genug sein. Jedes bißchen mehr bringt keinen Vorteil, wodurch sich
der vermeintliche Geschwindigkeitsvorteil des M3 wieder relativiert.
Denn so viel schneller ist er nicht.

Aber wie gesagt, der Privatanwender kann das alles sehr gelassen
sehen und sich die Rosinen herauspicken.
Bei der Frage PIC vs. AVR geht es mir nicht viel anders. Privat
verwende ich nur AVRs. PICs kommen mir nicht ins Haus. In der
Firma arbeiten wir fast ausschließlich mit Microchip. Warum?
Weil wir vor sechs Jahren damit angefangen haben und nicht so
ohne weiteres davon loskommen. Ein AVR bietet nicht die entscheidenen
Vorteile.

Hallo

Also ich gedenke nicht ein grosses Projekt mit den Board zu machen! Ich
will einfach mein wissen ein wenig erweitern und Erfahrung sammeln!
Vielleicht ist auch mal geplannt ein kleines Projekt zu machen wo dann
halt Ethernet, PWM, ADC usw zum Einsatz kommen. Habe gehört das Luminary
eine große Bibliothek an Funktinen mitliefert mit der die ersten
Schritte sehr einfach sind. Mein Ziel ist es aber eigentlich ohne diese
Bibliothek zu arbeiten und mich mit den Registern usw zu beschäftigen!

Mir sprechen die Luminary deswegen so zu weil sie wirklich günstig sind
ethernet haben und keinen eigenen JTAG Debugger benötigen!

MFG Harald

Na prima! Dann ist das LM3S6965 Board ja genau das Richtige.
Angesehen habe ich mir das auch schon, war auch drauf und dran
mir das zu bestellen aber mir fehlt einfach die Zeit für ein
neues Projekt. Die DriverLib sieht sehr ordentlich aus. So
einfach machen es dir NXP und Co. nicht. Das Schöne an dieser
Bibliothek ist das sie sehr einfach gestrickt ist. Man kann
sich also genau ansehen wie die Peripherie angesprochen
wird und danach seine eigene Wege gehen. Die Beispiele von
Keil und NXP für die LPCs wirken dagegen etwas verbastelt.

Ich habe so meine Zweifel an diesem JTAG Adapter (schlechte
Erfahrung mit FT2232) aber man kann ja (anscheinend) auch ein
externes Gerät anschließen.

Eigentlich wollte ich mich gar nicht äußern, konnte es mir dann
aber dann doch nicht verkneifen ;)

Ich wollte lediglich klarstellen das 'besser' relativ ist. In der
Industrie sehen die Dinge eben oft etwas anders aus.
Für den ARM7 hatte ich mich erst rein privat interessiert. Dann
habe ich ihn in der Firma für neue Projekte vorgestellt.
In einem Jahr oder so werde ich privat vielleicht nur noch mit M3s
zu tun haben die in der Firma aber keine Chance haben werden, weil
wir da ja ARM7 verwenden....

Du hast die Zeit die wir nicht haben. Wie auch immer der M3 sich
entwickeln wird, I2S und EMI brauchen wir heute.

PS: Ich glaube nicht das es sich lohnt auf NXP zu warten.
Meines Wissens nach haben die ihre M3 Controller noch nicht
einmal offiziell angekündigt. Das es dann im 4. Quartal bereits
Controller geben soll erscheint mir sehr unrealistisch.

@let:

die neuen STM32F103 ( Cortex M3 ) von ST haben einen externen
Speicherport für SRAM, NAND, NOR, PSRAM etc. Der I2S ist auch integriert
und noch vieles anderes ( 12Bit DAC, 12Bit ADC 1µs SD/MMC Port) . Ich
habe heute das ersta Datenblatt von den Teilen gesehen. Die ersten
Muster kommen aber erst Anfang Mai.

>Nicht vergessen sollte man auch die Erratas. Das Dokument zum
>M3 umfaßt stolze 48 Seiten. Hier stehen Fehler gegen Designschwächen.

Wo finde ich das denn?
Meins hat nur 12 Seiten, davon 3 Seiten Fehlerbeschreibung. Schummelt
ARM hier und beschönigt neuerdings was?
http://infocenter.arm.com/help/topic/com.arm.doc.e...


>Stichwort Geschwindigkeit: Bei einem Desktop PC sollte die CPU
>so schnell sein wie möglich.

Naja, gerade im gewerblichen/industriellen Bereich ist das auch nicht
mehr der Fall. Wieso unnötig Strom verbrauchen?


>PS: Ich glaube nicht das es sich lohnt auf NXP zu warten.
>Meines Wissens nach haben die ihre M3 Controller noch nicht
>einmal offiziell angekündigt. Das es dann im 4. Quartal bereits
>Controller geben soll erscheint mir sehr unrealistisch.

Nein, das ist realistisch. Angekündigt wurden die Anfang Februar:
http://www.standardics.nxp.com/news/arm.cortex-m3/

Interessant ist, daß:
"The NXP microcontroller family based on the Cortex-M3 processor will be
pin-compatible with, and offered in addition to its ARM7 and ARM9
family-based microcontrollers."

Man kann also auch seine ARM7-Designs schnell umstellen.

Wenn NXP also nicht so schlampig ist wie bei den ARM7-Controllern,
werden sie den Markt wohl aufrollen.

Hallo

Habe noch eine Frage zu den EvalBoard. Es gibt ja drei verschiedene
Varianten was die Software angeht (Keil/CodeSourcery/IAR). Gibt es
zwischen diesen Versionen ausser den Unterschied der IDE noch andere
Unterschiede?

MFG Harald

Hallo Harald,

Die Kits unterscheiden sich nur durch eine andere CD und das
"Start-[Bei]Spiel" hat ein anderes Logo.

@ Harald

es sind ja wohl eher 4 Varianten verfügbar.
(code_red wurde unterschlagen)

Hallo,
ich habe mir das Board nun gekauft und frage mich wo ich das
"start-(bei)spiel" herbekomme. ich habe die software installiert aber
bei examples kann ich dies nicht finden...
gruß timo

ok, wer suchet der findet - war leider doch zu voreilig.

die cd ist ja mal gar nicht so schlecht gemacht (hab des mit keil)

dann nun ma schaun wie das einbinden klappt. also überspielen der
software

gruß

Nur blöd, dass es unter KEIL net geht.
da ist extra ein keil projekt file aber der linker macht net mit, da
23kb....
die iar version würde ja 32kb mitmachen, die habe ich nun auch
installiert aber leider bekomm ich es nicht ohne fehler hiin ein projekt
zu erzeugen

nun also die frage
hat von euch jemand das start game vom board als IAR projekt und kann
dies hochladen???

gruß timo

Das Startbeispiel ist doch auf einem neuen Board bereits drauf?
Wenn du die bin Files suchst, die sind mit bei der Driverlib dabei.

Ja es ist bereits drauf,
aber wenn ich nun meine eigenen programme drauf spiele und das test
propgramm in paar wochen wieder drauf machen möchte dann brauch ich ja
die files.
ja genau auf der cd habe ich die driver liv gefunden und installiert
dort ist die workbench drin aber ers tretet beim compilieren dennoch der
fehler auf:;

Error[Li005]: no definition for "EthernetIntStatus" [referenced from
E:\DriverLib\boards\ek-lm3s6965\qs_ek-lm3s6965\ewarm\Obj\enet.o]

dies kommt für alle erstellten dateien ...

gruß

Bei der Driverlib (Version von der Luminary Internetseite) sind auch die
fertig compilierten BIN-Dateien dabei - direkt zum flashen.

alles klar, danke für den tip, dann werde ich das mal testen, würd ja
auch schon reichen.

gruß

oh man ... die bin datei die ich besitze geht nicht ;(
"hello" "graphics" etc geht aber nicht die im ordner qs_ek-lm3s6965_revc
und das sollte es ja eigentlich sein

gruß

Das funktionierende HelloWorld ist aber auch aus dem rev. C Pfad?
Es gibt 2 Versionen vom Board.

Mein Board ist auch eingetroffen. Nur: bei mir tut's auch nicht. Ich
kann zwar compilieren, linken, flashen; dann drücke ich auf run ... und
das war's.

Mfg

Hast du die richtige Version (rev. C) der Bespiele gewählt?
Wie in meinem vorherigen Beitrag bereits geschrieben, gibt es 2
Versionen des Boards. Die C-Version hat ein Display von RiT und die
älteren von OSRAM.

Und woran sieht man, ob es Rit oder Osram ist? :)
Vermute mal, dass es die C-Version ist.
Ich habe mal 2 Bilder angehaengt. Dank im voraus.

und Bild 2

Ja, deins ist ein rev. C Board.
Auf der Rückseite steht ganz oben auch nochmal EK-LM3S6965 - C.

Haett' auch nicht gedacht, dass mir Dein Bruder was anderes schickt :)

"Hast du die richtige Version (rev. C) der Bespiele gewählt?"
Unter D:\Prg\MCU\Arm\Keil\ARM\Examples gibt es keine weitere
Unterteilung. Ich gehe in den Ordner HELLO und auch dort ist keine
weitere Unterteilung.

MfG

Naja, was da bei Keil für Beispiele dabei sind, weiß ich leider nicht.
Ich kenne nur die Sachen aus der Driverlib und da gibt es diese
Unterteilung.

In der Tat, in der Driverlib habe ich diese Unterteilung gefunden. Mal
schauen, ob ich das dem Keil schmachhaft mache. Danke für die
Unterstützung.

Ich habe gerade mal die Keil-Eval-Version installiert das Hello-Beispiel
ist für eine andere Hardware gedacht. Es gibt aber auch ein Bsp. für das
Luminary Board in: /Keil/ARM/Boards/Luminary/ek-lm3s6965
und halt die Sachen aus der Driverlib.

Super! Blinky hat zwar nicht hingehauen, aber mit Hello hatte ich mein
Erfolgserlebnis! Nochmals vielen Dank.

Hi,
bei mir genauso. habe auch rev C und blinky ging nicht aber das hello
bzw. graphics geht ....

ich würde aber gerne mit IAR arbeiten .. und auch wenn ich die
entsprechende Workbenck öffne und compilieren will kommt nach dem
compilieren immer ein fehler vom linker
Error[Li005]: no definition for "SysCtlClockSet" [referenced from
E:\Eigene Dateien\DriverLib\boards\ek-lm3s6965_revc\graphics\ewarm\Obj\

usw...

Weiss jemand wie man es unter IAR zum laufen bringt?

Gruß

blinky prog is nun auch gelöst.
zu mehmet: im schaltplan sieht man, dass die led über die jumperleiste
gewht.
am portausgang kommt die spg an --> 0ohm widerstand bei jmp15 reinmachen

nun nur noch unter iar zum laufen bringen, hoff des hat einer schon
gemacht oder besitzt IAR version und kann mir da mal ein bsp programm
schicken

gruß

@Timo
Danke für den Tip.
Wieso bestehst Du auf IAR? Ob nun 16k oder 32k Beschraenkung, ich finde,
mit beiden kommt man bei einem ARM nicht allzuweit.
Also ich bleib' - bis ich den Durchblick habe - mal bei Keil. Falls ich
das Handtuch nicht werfe, werde ich mit Crossworks weitermachen.
Bei mir ist nur das Problem, dass ich für diese Leistungsklasse einfach
kein Project zur Hand habe. Und ohne eine solche Motivation wird der
Einstieg vermutlich sehr schleppend sein.

Timo wrote:
> blinky prog is nun auch gelöst.
> zu mehmet: im schaltplan sieht man, dass die led über die jumperleiste
> gewht.
> am portausgang kommt die spg an --> 0ohm widerstand bei jmp15 reinmachen
Die Jumper sind bei einem neuen Board bereits gebrückt. Ansonsten würde
das LCD auch nicht laufen.

zu IAR:
Ich glaube er findet die Library nicht. In meinen Graphics-Beispiel
steht als Library in der EW-Projekt-Datei:
$PROJ_DIR$\..\..\..\src\ewarm\Exe\driverlib.r79
In der Driverlib selbst gibt es aber nur eine:
$PROJ_DIR$\..\..\..\src\ewarm\Exe\driverlib.a

Ersetze mal deine Projekt-Datei mit der im Anhang.

@Mehmet: Ich möchte gerne mit IAR arbeiten, da ich bereits in der HS und
in der Arbeit damit arbeite.

@Andreas: Nun findet er folgende datei nicht:
Fatal Error[Li001]: could not open file "E:\Eigene
Dateien\DriverLib\src\ewarm\Exe\driverlib.a"

Bei mir ist es grad andersrum ich hab die *.r79 datei im ordner, aber
nicht die *.a

Gruß

zu den jumpers noch kurz: ok ich seh sie sollten gebrückt sein ...
aber bei der led dann nicht richtig, da auf dem einen pad spannung
anliegt und beim anderen schon nicht mehr...werde da lieber nachhelfen

Verwendest du eigentlich IAR EW 4 oder Version 5?
Die Projekte sind für Version 4.

hm .. ich hab natürlich die neuste version 5 .. der frägt ja auch am
anfang ob er die dateien updaten soll. ich dachte des würde
aufwärtskompatibel gehen ....
mit den ganzen verlinkungen find ich eh alles bissel blöd und hät nun
einfach gern ein eigenes projekt in das ich meine include und source
files mach und gut ist .

bin nun dabei ein eigenes projekt zu erstellen, vielleicht bekomm ich es
ja hin oder es lädt einer einfach das grundgerüst mal hoch, wäre
natürlich auch was ;)

gruß

Soweit ich weiß, muss man irgendwas beachten, wenn man ältere Projekte
compilieren will. Such am Besten mal bei Google.

Ja lag wohl echt an der IAR Version
Immerhin gehts nun .. find es mit den vielen einzelnen header files nur
lästig :|


gruß