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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.