Servus allerseits Also der Sprung vom AVR zum STM32 ist machbar. Bin nicht der Hellste, auch nicht mehr der Jüngste; aber es klappt. Zuerst habe ich von Olimex ein Board mit einem LPC2148 und einen JTAG gekauft. Liegt sicher 2 Jahre zurück. Reinfall. Dann habe ich von Stellaris ein DevBoard gekauft. Reinfall. (Will jetzt diese Reinfaelle nicht weiter aufzaehlen, ist echt peinlich.) Ich kam dann zum Schluss: Mangel an IQ und Durchhaltewillen. Vergiss es. Irgendwie (vermutlich verletzte Eitelkeit) kam ich von diesem Thema nicht ab. Ich habe mir dann dieses Board gekauft http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=200473154529&ssPageName=ADME:X:RTQ:US:1123 (ohne Display) und dann ein ST-Link. Und zusammen mit der Std-Lib und Iar KickStart hat es plötzlich geklappt. Und wenn man alles statische auslagert (SD-Karte oder DataFlash), ist es erstaunlich, was man so alles mit 32kB anstellen kann. Also Leute, nicht aufgeben. Entweder mit viel Gehirnschmalz oder mit viel Durchhaltewillen, aber wie auch immer, es ist machbar. MfG aus Istanbul PS-1: Eine Zeilang habe ich auch mit Crosswork gearbeitet. Hat auch wunderbar geklappt. Aber irgendwie verwirrend bunt das Ganze. Wenn ich mal die 32k von IAR sprengen sollte, werde ich damit weiterarbeiten. PS-2: Ich habe mir spaeter einen J-Link zugelegt. Aber irgendwie gefaellt mit der ST-Link besser. Vielleicht die Macht der Gewohnheit. Der J-Link liegt in der Schublade bei all den unbenutzten Boards.
wenn man keinen spagetticode auf dem AVR produziert indem man immer konsequent alle registernamen breit im code verteilt .. ( und das machen hier viele .... ) und sich nur halbwegs an ANSI C hält kannste du beliebigsten Code auf AVR , STM , LPC und sonstwo laufen lassen. die LIB nimmt einem bei ein paar einstellungen gut arbeit ab das ist das schöne aber wenn man zB einen LPC11 13 17 nimmt ( Cortex kern ) ist es hier aber genauso einfach wenn man sich jedoch etwas damit auseinandersetzt .. kann man problemlos ein BSP bauen was per #define für vercshiedene µC sein kann beim AVR haben sich viele angewöhnt den registernamen in cen Code zu pinseln ist sicher auf dem kleinen 8bitter effizienter ... wenn man jumps vermeiden kann hat man nun eine lib wie die STM32.. nimmt man für eine registerabfrage mal 10 jumps und calls in kauf der geschwindigkeitunterschied STM >>> AVR ist immernoch da wird erst messtechnisch schlechter ausfallen ..
Ohne die 32K Grenze geht es mit dem Atollic TrueStudio und ST-Link Debugger: Beitrag "STM32 Einstieg mit Atollic TrueStudio und ST-LINK Jtag"
gahst schrieb: > wenn man sich jedoch etwas damit auseinandersetzt .. > kann man problemlos ein BSP bauen was per #define für vercshiedene µC > sein kann Portabilität ist keine Frage der Verwendung der STlib, die es für AVRs nicht gibt und die auch zwischen den Controllerfamilien von ST selbst völlig unterschiedliche Datenstrukturen und Funktionen enthält. Die STlib mag die Nutzung des Controller vereinfachen, die Portierung erleichtert sie nicht. Es ist vielmehr eine Frage der Modularisierung des eigenen Codes. Der Code mit direktem Bezug zur verwendeten Hardware kommt in ein eigenes Modul, beispielweise für die Bedienung einer UART- oder einer I2C-Schnittstelle, oder für die PWM-Timer-Programmierung einer Motorsteuerung. Wird das Interface dieser Module einigermassen sauber konzipiert, dann muss man für den Übergang zu einer anderen Controllerfamilie hauptsächlich diese Module anpassen. Um diesen Schritt kommt man allerdings nicht herum, egal ob man auf der STlib aufsetzt oder direkt auf dem Registern. Andererseits ist es dann auch kein Problem, in diesen Modulen unter Umgehung der STlib direkt auf die Register zu gehen. Das ist dann eine Sache indivudueller Vorlieben.
Guten Morgen Mehmet, freut mich, dass es dir am Ende doch gelungen ist. Kann deine Freude wirklich nachvollziehen. Am Ende wird alles gut :-) Was mich wundert, dass da solche Unterschiede zwischen dem ST-Link und dem J-Link sein sollen. Wenn ich richtig informiert bin, sind beide aus dem gleichen Hause. (?) Der St-Link wird sich er nur eingeschränkt auf die ST-Produkte sein. Ich nutze hier den J-Link (no commercial) und bin super zufrieden. Ich nutze auch eine freie Toolchain (Code Sourcery Lite-Version) + Eclipse mit dem ARM-Plugin. Das geht eigentlich auch recht problemlos. Habe bei meinen Anfängen noch eine Std-Lib von ST benutzt, die den Startup-Code noch in fast reinem 'C' geschrieben enthielt. Unter Project Templates von ST war auch ein Project für die RIDE von RAISONANCE dabei, die nutzen ja auch GNU kompatible Tools. Von dort habe ich das Linkerscript genommen. Von ST gab es nichts für den GCC. Viele Infos von der Seite von M. Thomas und auch ucnet hab ich auch genutzt. Am Ende hat es dann funktioniert. War aber deutlich aufwendiger als ein AVR :-) Da können die Nutzer den WinAVR-Machern nur danken, dass es mit der Toolchain so einfach ist, einen AVR zum arbeiten zu bewegen. Die oben erwähnte Atollic-IDE wird auch nicht schlecht sein. Ich bevorzuge lieber das reine Eclipse + CDT und einer beliebigen GNU-Toolchain. Damit kann ich alles erledigen und brauche nicht verschiedene Toolchains. Unter Eclipse nutze ich AVRs, ARMs, Cortex-M3 und auch SPARC. Klappt alles prima. Wenn Du mal die 32kB-Grenze sprengst, wolltest du die IAR-IDE weiter nutzen? Recht teuer. Falls du doch mal einen Versuch mit der Code Sourcery Lite-Toolchain starten möchtest, dann frag mal ruhig per PN, ich hab noch 'n LED-Blinker aus den Anfängen, damit und ein paar Tips könnte ich helfen. Wenn das erstmal läuft, dann ist der Rest auch nicht schwerer als mit IAR denke ich. Gruß 900ss PS. Und ich beneide dich ein wenig, du hast in Istanbul ja noch super Temperaturen draußen. Hier in Norddeutschland ist es schon recht ungemütlich, aktuell 5°C. ;-)
gahst schrieb: > und sich nur halbwegs an ANSI C hält kannste du beliebigsten Code auf > AVR , STM , LPC und sonstwo laufen lassen. Ein bischen krass formuliert. Das geht natürlich nur insoweit, wie diese Controller sehr ähnliche Funktionsmodule wie UARTs bieten. Diese kann man dann wie eben beschrieben verkapseln. Nicht immer ist das jedoch der Fall. So kann für das Design eines Codes von Bedeutung sein, ob das USB- oder Ethernet-Modul eines Controllers mit eigenem separaten dual ported Memory arbeitet, oder direkt im normalen Hauptspeicher. Oder ob ein CAN-Controller mit Mailboxen oder FIFOs arbeitet und wieviele Filter er überhaupt verarbeiten kann. Eine vorherige Verkapselung solcher Eigenschaften setzt ein bemerkenswertes Mass an Allwissenheit voraus und verliert möglicherweise entscheidend an Performance oder fügt eine erhebliche in vielen Fällen überflüssige Komplexität hinzu. Es kann sinnvoll sein, solche Unterschiede auch ausserhalb des betreffenden Funktionsmoduls zu nutzen. Die Vorstellung, mit ANSI C liesse sich alles im Handumdrehen zwischen Controllerfamilien umstellen, ist also etwas utopisch.
900ss D. schrieb: > Falls du doch mal einen Versuch mit der Code > Sourcery Lite-Toolchain starten möchtest, dann frag mal ruhig per PN, > ich hab noch 'n LED-Blinker aus den Anfängen, Danke für Dein freundliches Angebot, auf das ich spaeter sicher zurückkommen werde. Aber zu Zeit wage ich es noch nicht, mein bestehendes Gerüst anzutasten; alles laeuft wie geschmiert. Einen erneuten Rückfall in das dunkle Mittelalter will ich nicht riskieren. Uebrigens verwende ich die Std-Lib nicht mehr. D.h., wenn ich eine neue Funktion vom STM32 aktiviere, dann mache ich das mit der Lib und verfolge dann den Ablauf mit dem Debugger. Nach dem Aha-Erlebnis schreibe ich dann meinen eigenen Code. Die Lib ist aber schon eine gewaltige Erleichterung.
900ss D. schrieb: > Was mich wundert, dass da solche Unterschiede zwischen dem ST-Link und > dem J-Link sein sollen. Ich hatte das Gefühl, dass der ST-Link schneller ist. Vermutlich aber auch nur was Falsches eingestellt. Und bei jedem Upload dieses Fenster mit den License-Bestimmungen, das man wegklicken muss, hat auch genervt.
Mehmet Kendi schrieb: > Und bei jedem Upload dieses Fenster > mit den License-Bestimmungen, das man wegklicken muss, hat auch genervt. Hmmm... ich muß nichts wegklicken. Merkwürdig. Kann es gerade aber auch nicht testen, da meine Arbeitsecke das Zimmer gewechselt hat und noch nicht wieder alles aufgebaut ist (das Chaos tobt) :-( Und gerade scheint hier die Sonne, ich will raus, auch wenn es kalt ist. :-) Gruss 900ss
Man muss nur einmal was wegklicken, dann das Nicht-Nerven Häckchen setzen. Solange man den JLINK GDB Server nicht beendet weiß er das dann. Ich habe auch viele Anlaufe für die 32 Bit benötigt. Schlussendlich muss ich sagen es lag daran, dass vor 5-8 Jahren es noch nicht so viele Infos im Netz gab wie heute und daher war das Scheitern fast schon vorprogrammiert. Heute mit Yagarto, Eclipse, der STM FW-Lib und die große fülle an Infos im Netz kann es jeder schaffen, vor 5 Jahren musste man richtig Geld in die Hand nehmen um teure Debugger und Compiller kaufen was für mich nicht in Frage kam. Schaue doch mal was vor 5 Jahren der JLink kostete (mit GDB Server Lizenz), da gab es noch keine EDU-Privat-Version! Die Parallel-Port-Wiggler sind auch nicht wirklich lauffähig. Daher ist auch der Artikel STM32 entstanden um den Ein-/Umstieg zu erleichtern.
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.