Ich habe bisher schon einige Projekte mit den AVR's realisiert, jedoch
möchte ich einige zukünftige Projekte eher mit einem größeren uC
realisieren, dazu gehört unter anderem eine kleine Heizungssteuerung
o.ä. welche über ein Webinterface gesteuert werden soll, sowie ein BLCD
Motorcontroller für ein Pedelec. Meine Recherchen haben ergeben, dass
sich dafür Cortex M3 Controller eignen würden und diese auch relativ
weit verbreitet sind. Nun stellt sich für mich die Frage ob ich mich
eher für die NXP LPC17xx oder für die STM3 Controller entscheiden
sollte. Da ich im Bereich der 32bit uC bisher keinerlei Erfahrung habe,
wäre für mich interessant welchen Hersteller ich bevorzugen sollte, bzw.
wo der Einstieg am leichtesten fällt.
Da ich im Moment eher zu NXP tendiere, habe ich als eval Board für den
Einstieg an das das "LPC1769 LPCXpresso" sowie das dazugehörige
Baseboard gedacht. Ist dieses und die dazugehörige Programmierumgebung
Code Red zu empfehlen, oder sollte man anders beginnen.
Dass es von NXP nur relativ große Gehäuse gibt stört mich nicht.
Wenn ich allerdings in die Datenblätter schaue, dann sehen die eher wie
Kurzzusammenfassungen aus. Deshalb frage ich mich, ist z.B. der Zugriff
auf den ADC so ein Register gefrickel wie bei den AVR's, oder eher wie
bei den Arduinos.
Ich hoffe ihr könnt mir bei meiner Entscheidung ein bisschen
weiterhelfen.
Für alles was du vorhast reicht ein AVR locker aus.
unknown_soldier schrieb:> der Zugriff> auf den ADC so ein Register gefrickel wie bei den AVR's, oder eher wie> bei den Arduinos.
Dadrüber würde ich nochmal ganz scharf nachdenken.
Wenns denn wirklich ARM sein muss: Das neue TI Launchpad.
Bei dem Preis kann man sich das TI Launchpad sicherlich zulegen, jedoch
würde ich schon gerne den Einstieg in die 32 Bit uC wagen.
Ob man das jeweilige Projekt auch auf einem 8 Bitter hätte umsetzen
können, oder nicht, ist mir dabei relativ egal. Ich habe auch bisher
nicht darauf geachtet immer den kleinst möglichen uC für das
entsprechende Projekt zu verwenden, sondern hatte 3 oder 4 Standard
Typen.
Sorry, war erst beim alten Launchpad. Leider wird es wohl noch ein
bisschen dauern, bis das neue ausgeliefert wird. Außerdem wäre mir
Ethernet mit möglichst wenig (unnötigem) Aufwand wichtig. Gibt es
weitere Punkte die für TI sprechen, außer das fast geschenkte Launchpad?
Ja, ich bin verliebt in TI. Und zwar weil:
- Die Datenblätter gut sind
- Die andere Dokumentation ebenso
- Die Tutorials für das alte Launchpad waren ziemlich gut, ich erwarte,
dass die neuen es ebenfalls sind.
unknown_soldier schrieb:> Deshalb frage ich mich, ist z.B. der Zugriff> auf den ADC so ein Register gefrickel wie bei den AVR's, oder eher wie> bei den Arduinos.
Autsch. Die Arduino's verwenden AVR's. Und verpacken nur das "Register
Gefrickel" in hübsche Libraries. Da die ARM's wesentlich komplexer sind,
ist das bei denen auch die Registerschieberei um einiges schwieriger,
zumal die Dokumentation nicht immer so perfekt wie bei Atmel ist... Die
Timer der STM32 sind zB sehr mächtig, das erfordert kompliziertere
Ansteuerung... Es gibt allerdings auch da Wrapper-C-Methoden (Bei STM32:
StdPeriphal library), aber die macht eigentlich nur den Code schöner,
wirklich einfacher wirds dadurch auch nicht...
Ich hatte mich etwas missverständlich Ausgedrückt bzgl. AVR und Arduino.
Letztendlich wollte ich wissen ob es fertige Funktionen gibt, die man
nur aufrufen muss, oder ob es vergleichbar mit einem AVR Programm in C
ist. Aber diese Frage ist ja nun beantwortet.
Wenn Dein Trend zu NXP geht dann schau Dir doch den mbed an.
Da ist auch ein PHY mit drauf und ein MagJack reicht um Ethernet zum
laufen zu bringen.
Der cloud compiler ist kein Argument mehr, es geht auch CodeSourcery
auf dem heimischen Computer.
Ich habe einige Projekte auf dem mbed entwickelt, und lasse es dann auf
einer eigenen Platine laufen.
Ju
Also von NXP kann ich nur abraten, bin gerade selbst damit am
rumspielen. Die Dokumentation ist mehr als unterirdisch. Der LPC-Link
ist nicht wirklich nützlich, ich habe es jetzt schon einige Male gahbt
das ich den Prozessor nicht mehr flashen mit LPC-Link konnte. Musst dann
auf den Bootloader ausweichen.
Die Entwicklungsumgebung ist ganz OK hat aber auch so ihre
Schwachstellen. Ich durfte Sie schon einmal neu installieren weil ich
ein Simples LED-Blink Progrämmchen nicht mehr mit LPC-Link flashen
konnte, von wegen Codesize > 8K beim Start aber die Meldung bekommen das
die Version "Fully Activated" ist.
Wenn du nicht weist wie man ein Linkscript schreibt, bringen dir
CodeSourcery und Co. leider auch nichts, weil das Linker-Script nicht
bei den Beispielen von NXP dabei ist.
Bei den Beispielen musst du auch aufpassen das du die richtige CMSIS
nimmst sonst kann es dir passieren das du die Beispiele erst einmal
nicht kompiliert bekommst weil sich einige Bezeichner/Funktion geändert
haben, z.B. aus SystemClockUdpdate() wurde SystemCoreClockUpdate() oder
beim I2C heist es nicht mehr LPC_I2C->STAT sondern LPC_I2C->I2STAT.
Alles nur Kleinigkeiten, aber beim Einstieg nerven die einfach.
Beimm STM32 hatte ich solche Startprobleme nicht. Wenn du wirklich mit
32-Bittern anfangen willst, nimm lieber die von ST. Auf Linux wird das
zwar mit der Entwicklungsumgebung nicht ganz so einfach, wenn du aber
Windows nutzt, scheint CooCox ziemlich gut zu sein.
Zu TI kann ich nichts sagen, aber wen die Leute hier sagen die taugen
was, dann kannste dennen das auch glauben.
STM32F4DISCOVERY Board würde ich mir ansehen. Ist bei Watterott vorrätig
für 16,66€ plus Versand.
Dazu gibt es ausserdem eine riesige Softwaresammlung mit Beispielen für
alle möglichen Funktionen, die auch für Motor-Control-Applikationen
interssant sind (PID-Motorregler, Clarke-Transformation,
Park-Transformation,...)
LM3S6965 von TI.
Der hat Ethernet PHI+MAC drinnen. Das bedeutet, du kannst an diesen
Cortex M3 Chip direkt eine Ethernetbuchse klemmen. Sowas gibt es bei den
STMs nicht.
Dazu gibts auch ein Evalboard.
Beim mbed und STM32F4DISCOVERY Board fehlt mir leider das Ethernet
Interface. Da ist mir deshalb wichtig, weil ich gerade am Anfang nicht
überlegen will ob das Problem nun von der Hardware oder von der Software
kommt.
Wenn ich eure Posts richtig lese, dann gibt es anscheinend zum STM32
mehr fertige Librarys als zum NXP.
Jedoch scheint mir die Verfügbarkeit von LPC17xx in Deutschland besser
zu sein.
Über die uC von TI habe ich mich bisher kaum informiert, werde das aber
jetzt noch tun, vor allem weil kein zusätzlicher chip für Ethernet
gebraucht wird.
Wie Problematisch ist das routen von Ethernet, gerade wegen der hohen
Frequenzen. Geht das noch halbwegs wenn die Leiterbahnen nicht zu lange
sind, oder muss man da schon genau schauen wie man welche Leiterbahn
verlegt (Wellenwiderstand o.ä).
Danke für eure bisherige Unterstützung.
Also ich finde die ARM's von NXP und ST ziehmlich gleichwertig.
Bis jetzt hat fuer mich noch keiner der beiden Hersteller eindeutig
gewonnen. Fuer manche Anwendungen ist ein STM32 besser fuer die
andere ein LPC.
Ich entscheide immer am Project selbst welchem Chip ich den Vorrang
gebe.
STM32F4-DISCOVERY ist 'ne feine Sache, fehlt allerdings das Ethernet.
Beim mbed hast Du Ethernet mit einem MagJack und 6 Kabeln auf einem
Protoboard in 2 Minuten am laufen. Absolut problemlos.
Ich programmiere beide unter Linux mit CodeSourcery und eclipse.
Librarys gibt's fuer beide reichlich, vom Hersteller, Third Party und
von der Community.
Allerdings ist es mit denen das gleiche wie mit den Lib's der 8-Bitter.
Hersteller -> taugt nur fuer Demo Zwecke
Third Party -> gut aber nicht fuer lau.
Community -> sehr gut aber nicht immer leicht zu finden.
Beim Routen von Ethernet musst Du Dir schon Gedanken machen wo die
Leiterbahnen hin muessen. Ein PHY ist ein recht stromhungriges Biest, je
nach dem welchen Chip Du da verwendest, musst Du ihm Elko's parallel zu
den ByPass C's spendieren.
Vom uC zum PHY nicht weiter tragisch (so kurz wie's geht), den PHY und
den MagJack aber immer schoen am Rand des PCB.
Ju
Die TI-Luminary-Teile sind recht buggy, zumindest die Teile, die vor der
Übernahme durch TI designed wurden. Ich zitiere aus den Errata zum
LM3S6911:
"3 Hibernation Module
3.1 Hibernation module does not operate correctly
Description:
The Hibernation module on this microcontroller does not operate
correctly.
Workaround:
This errata item does not apply to many Stellaris devices, including the
LM3S1166, LM3S1636, LM3S1969, and LM3S2919. Refer to the Stellaris
Product Selector Guide (www.ti.com/stellaris_search) and Errata
documents to find an alternative microcontroller that meets the design
requirements for your application.
Silicon Revision Affected:
A1, A2"
Krass, was? Wäre da einer der Verantwortlichen in meiner Greifweite
gewesen, hätte der sich ernste Sorgen machen müssen. Ich glaube, in
Texas wurden solche Leute früher geteert und gefedert.
fchk
Danke für die Infos Juergen. Ich denke das mbed wäre ganz gut für den
Anfang. Jedoch bräuchte ich dann, sofern ich nichts übersehen habe, für
Jungfräuliche uC auf eigenen Boards noch einen zusätzlichen Programmer.
Dafür würde sich wieder das LPC1769 LPCXpresso anbieten. Jedoch bin ich
mir da nicht im klaren, ob ich damit an Code red gebunden bin.
Gibt es so etwas wie einen universellen Programmer wie bei den AVRs?
> Da ist mir deshalb wichtig, weil ich gerade am Anfang nicht> überlegen will ob das Problem nun von der Hardware oder von der Software> kommt.
Und wie hilft dir das Ethernet Interface dabei ?
unknown_soldier schrieb:> Jedoch bräuchte ich dann, sofern ich nichts übersehen habe, für> Jungfräuliche uC auf eigenen Boards noch einen zusätzlichen Programmer.> Dafür würde sich wieder das LPC1769 LPCXpresso anbieten.
Brauchst Du nicht unbedingt, die LPC's haben einen Bootloader fest drin,
den man auch nicht (aus Versehen) ueberschreiben kann.
Der Bootloader funktioniert mit dem UART im Zusammenhang mit den Boot
Pins.
Ju
@Uwe
Bei Problemen mit dem Ethernet möchte ich ausschließen können dass es an
der Hardware liegt. Wenn das LCD anders verhält als es soll, bringt mir
das Ethernet Interface natürlich nichts. Vielleicht stelle ich mir das
mit dem Ethernet auch nur zu kompliziert vor. Bei den AVRs hatte ich nie
ein Eval Board o.ä., dafür gab es aber ein ausführliches Tutorial und
die Hardware war nicht so aufwändig.
Selbst bei der Hardware fürs Ethernet (PHY und Mag Jack) weiß ich noch
nicht wirklich auf was man achten sollte, bzw. was wichtig ist. Kennt
jemand sinnvolle Literatur zu diesem Thema, bzw. irgendetwas das einem
den Einstieg erleichtert. Natürlich könnte ich mir eine fertige Ethernet
Beschaltung im Internet raus suchen und nachbauen. Danach weiß ich
leider auch nicht mehr.
Der LPC1769 hat ebenfalls kein PHY an Board, auf dem LPCXpresso-Board
ist ein PHY-Chip(LAN8720) verbaut. Wenn du also eigne Boards baust musst
du dir hier auch etwas suchen.
unknown_soldier schrieb:> Selbst bei der Hardware fürs Ethernet (PHY und Mag Jack) weiß ich noch> nicht wirklich auf was man achten sollte, bzw. was wichtig ist. Kennt> jemand sinnvolle Literatur zu diesem Thema, bzw. irgendetwas das einem> den Einstieg erleichtert. Natürlich könnte ich mir eine fertige Ethernet> Beschaltung im Internet raus suchen und nachbauen. Danach weiß ich> leider auch nicht mehr.
Das wird alles nicht so heiss gegessen wie es gekocht wird.
Wenn Du im Internet suchst was man bei HF Schaltungen zu beachten hat
und wendest das auf den Part nach dem PHY an geht das in Ordnung.
Den IC fuer den PHY und die Beschaltung hatte ich beim ersten Ethernet
Layout mit einem LPC einfach vom Schematic des mbed abgekupfert.
http://mbed.org/media/uploads/chris/mbed-005.1.pdf
Diese Beschaltung laeuft bei mir fast identisch auch mit den STM's.
Welchen MagJack man nehmen muss haengt vom PHY ab. Hersteller von
MagJack's wie Wuerth zBsp. haben in den Datenblaettern die interne
Beschaltung abgebildet. Da suchst Du Dir den aus der zu Deinem PHY
passt.
Ich wuerde Dir aber auf alle Faelle raten mit einem fertigen Modul also
Discovery oder mbed anzufangen. Und dann erst ein eigenes Layout machen
und mit der selben Firmware testen.
Ich war damals zu geizig dazu und habe mir einen STM32 und einen LPC1768
jeweils auf eine Platine geloetet. Nur mit den ByPass C's den Cristallen
und den Buttons fuer die BootPins. Alle anderen Pins auf Stiftleisten.
Auch der JTAG Adapter war selbst gebaut.
Es hat mich 2 Wochen gekostet um die gesamte Entwicklungskette zum
laufen zu bringen und die erste LED blinken zu lassen.
Der Lernfaktor war natuerlich enorm.
Debugger haben mich nie interessiert, ich habe immer meine eigenen
Methoden gehabt um die Fehler im Programm zu finden.
Doch jeder der mit ARM's zu tun hatte schrie nach einem Debugger. Also
habe ich auch gelernt einen Debugger an den Arm oder AVR zu frickeln und
mit OpenOCD die Register unter die Lupe zu nehmen.
Heute weiss ich, das ich immer noch keinen Debugger brauche. Auch nicht
fuer die ARM's.
Ich habe nie gewusst was genau ein Linkerscript tut, und das der
compiler/linker for dem main() noch ne ganze Menge Sachen an das
Programm haengt.
Heute schreibe ich meine eigenen Linker scripts um das mit dem uC machen
was ich will und nicht das was die ToolChain Provider fuer richtig
befinden.
Mir hat's trotz dem ganzen Frust Spass gemacht und das Wissen kann mir
keiner mehr nehmen.
Man muss es aber nicht auf die harte Tour machen.
Deshalb der Rat kauf Dir ein Modul wo alles wichtige drauf ist. Wenn
Deine eigenen Designs irgend eine Macke haben kannst Du immer noch mit
dem Modul Testen ob es die Firmware oder die Hardware ist.
Ju
holger schrieb im Beitrag #2829353:
> "Ich mach mal eben Ethernet" kannste knicken;)
Geht schon. Ein Webserver auf einem mbed macht man in 2 Minuten mit den
mbed Libs.
Die Standard Protokolle gibt's fuer LPC und STM alle als Lib's.
Die Kopfschmerzen kommen wie immer wenn's ans Eingemachte geht.
Ich habe meinen Ethernet Stack fuer Router um Echtzeit Functionen
erweitert.
Uff. Da traeumt man nachts davon bevor es laeuft.
holger schrieb im Beitrag #2829391:
> @Juergen> Wenn jemand so etwas schreibt:>>>Deshalb frage ich mich, ist z.B. der Zugriff>>auf den ADC so ein Register gefrickel wie bei den AVR's, oder eher wie>>bei den Arduinos.>> Dann kann man davon ausgehen das er an Ethernet auf einem> ARM verzweifeln wird. Das kriegt der nie gebacken.
Ich bin zu faul zum suchen, steht das weiter oben hier im Thread?
Ein ARM hat je nach Ausstattung so um die 4k 32-Bit Register um die
Peripherie anzusteuern.
Wenn einer mit den AVR ADC Registern Probleme hat wird er mit einem ARM
wirklich verzweifeln.
Da sollte man sich echt Gedanken machen eine Kommerzielle IDE zu nehmen
wo man fast alles vorgebacken bekommt und es nur aufzuwaermen braucht.
Die Register Beschreibung zum LPC1768 ist 840 Seiten
Die von einem STM32F1XX 671 Seiten + das UserManual 1093 Seiten.
Das sit ne andere Liga als AVR's mit 8Bit
Ich hatte in den Datenblättern der jeweiligen uC nichts über einzelne
Register o.ä. gelesen, weshalb ich fälschlicherweise vermutet hatte,
dass der Zugriff auf die einzelnen Peripherie Module über fertige
Funktionen abläuft, eben so ähnlich wie bei den Arduinos. Inzwischen
habe ich aber bemerkt, dass das alles in den User Manuals steht.
Arduinos habe ich nie für eigene Projekte verwendet, da ich nicht auf
die vorgefertigten Funktionen angewiesen sein wollte und der
Funktionsumfang der Arduinos häufig nicht ausgereicht hätte. Auch hatte
ich nie größere Probleme beim Initialisieren der Hardware (ADC, PWM,
Timer, UART, usw.). Deswegen nicht einfach annehmen ich wäre dafür zu
dumm oder zu unfähig.
Ich werde mich wahrscheinlich erst mal für das mbed entscheiden und
versuchen mich ein bisschen einzuarbeiten und Erfahrung zu sammeln.
unknown_soldier schrieb:> Ich hatte in den Datenblättern der jeweiligen uC nichts über einzelne> Register o.ä. gelesen, weshalb ich fälschlicherweise vermutet hatte,> dass der Zugriff auf die einzelnen Peripherie Module über fertige> Funktionen abläuft, eben so ähnlich wie bei den Arduinos.
Und die Funktionen machen was? Richtig, auf Regsiter zugreifen. Anders
wird kein Controller auf diesem Planeten gesteuert. Wenn dir
Registerfickelei zu blöd ist musst die entsprechenden Funktionen ja
genau einmal selber schreiben und kannst sie immer wieder Benutzen.
Eumel schrieb:> Und die Funktionen machen was? Richtig, auf Regsiter zugreifen. Anders> wird kein Controller auf diesem Planeten gesteuert. Wenn dir> Registerfickelei zu blöd ist musst die entsprechenden Funktionen ja> genau einmal selber schreiben und kannst sie immer wieder Benutzen.
So habe ich das bisher auch gemacht. Aber wie gesagt, die Sache mit den
Registern ist bereits geklärt.
Keine Angst, was ich oben ueber die Hardware geschrieben habe gilt auch
fuer die Software.
Es wird nicht alles so heiss gegessen wie es gekocht wird.
Wenn Du am Anfang die Lib's der Hersteller nimmst siehst Du recht
schnell einen Erfolg. Du darfst nur nicht denken das alles so einfach
ist.
Es ist genau wie mit den Arduinos.
Die IDE versteckt das Register gefrickel in Funktionen, nur kommt man
damit irgendwann nicht mehr weiter und dann kommt das boese Erwachen
wenn man mit den User Manuals in Kontakt kommt.
Das gute an den ARM ist, das man die problemlos in C und/oder C++
programmieren kann und da eine Klassenhierarchie erstellen kann die die
Umstellung von einem uC zum anderen sehr viel leichter macht.
Ich verwende zBsp. fuer die LPC's und die STMs ab einer bestimmten Ebene
die selben Lib's.
Die Basisklassen bauen auf der Newslib bzw. CMSIS auf, je nach dem was
einfacher zu implementieren war.
Das uC spezifische Gefummel ist in einem eigenen Verzeichnis "arch"
meist in C und strukturiert.
Das was darueber kommt dann in "dev" und "lib".
ganz oben drauf kommt dann die App.
dev und lib ist schon zum grossen Teil C++
App dann alles in C++.
Damit bekommt man dann seine Projekte auch relativ schnell fertig ohne
vom uC abhaengig zu sein.
Ju
