Hallo an Alle, kurz zu mir und meine Plattform. Ich bin Einsteiger im Micropozessor-Programmierung stehe schon vor dem ersten Fels. Ich habe mir kürzlich von der Firma Mouser Electronis ein EVB Board von Luminary Micro LM3S8962 zugelegt. Dazu habe ich mir die Evaluation-Entwicklunsumgebung von Keil mit 16KByte Limitierung liefern lassen. Da ich das Board nich nur zur Evaluierung nutzen möchte sondern auch einige Kleine Tools und evtl. Treiber entwickle wär es für mich wichtig Programme auch im SRAM debuggen zu können. Aus dem Bekanntenkreis erfuhr ich bereits dass der interne Flash des Prozesseors nach unzähligen Beschreiben irgendwann mal den Geist aufgibt. Bei den MC Preisen ja eigentlich kein Problem aber da es sich um ein EVB Board handelt ist der Prozessor auf keinem Sockel oder Adapter montiert. Um das vorzubeugen möchte ich die Programme eben direkt aus dem internen SRAM vom Prozessor anstarten wenn das möglich ist !? So nun seit ihr lieben Forenuser gefragt. Für weitere Anregungen, Tipps & Tricks bin ich gerne offen, alles rund um Tools, Debugging usw.
Tom wrote: > Aus dem Bekanntenkreis erfuhr ich bereits dass der > interne Flash des Prozesseors nach unzähligen Beschreiben irgendwann mal > den Geist aufgibt. Nehmen wird mal an, dass du alle 5min eine neue Version flashst, und dies 8 Stunden lang 5 Tage die Woche. Wenn du das 4 Jahre lang ohne Urlaub so durchhältst, dann hast du das Flash-ROM vermutlich ausgelutscht. Sowas wird eigentlich erst zum Problem, wenn du mit einem Debugger arbeitest, der seine Breakpoints und Single-Steps per Flash-Progammierung abwickelt. Dann kannst du leicht auf mehrere Programmiervorgänge pro Sekunde kommen.
Erstmal danke für die schnelle Antwort. Woran merk ich das ob der Debugger im Single Step Mod ins Flash schreibt ? Ist es also nicht möglich die Startup.s so zu modifizieren dass er das Program in SRAM lädt und von dort aus startet ? Prinzipiell würde mich auch interssieren ob das Debuggen überhaupt ohne jeglichen ULink JTAG Adapter oder so möglich ist !?
Tom wrote: > Ich bin Einsteiger im > Micropozessor-Programmierung Dann ist es natürlich "superklug" einen absolut brandneuen IC zu nehmen, mit dem kaum jemand Erfahrung haben dürfte. Schnuckelig ist er ja (internes Ethernet). Aber ich bin davon weg, grüne Bananen zu nehmen. Ich lasse ICs erstmal mindestens 2 Jahre reifen und andere die Bugs finden. Ich hab einfach nicht mehr die Zeit dazu. Ich hab auch schon ICs gesehen, die sind nach 2 Jahren wieder verschwunden, glücklicher Weise hatte ich an denen keine nennenswerte Zeit verschwendet. Wie man Programme in den SRAM legt, sollte aus den Compiler-, Linker-Manuals Deines C-Compilers hervorgehen. Peter
Tom wrote: > Woran merk ich das ob der Debugger im Single Step Mod ins Flash > schreibt ? Wenn du Glück hast, steht im Kontext vom Debugger irgendwo ausdrücklich drin, dass er nur oder bis zu irgendeiner begrenzten Anzahl Hardware-Breakpoints verwendet. Wenn nicht: Durch eingehende (mehrfache) Lektüre sämtlicher zugänglicher Handbücher wächst die Chance, das selber rauszufinden. Womit nicht nur die Dokus des Compilers gemeinst sind, sondern auch diejenigen des verwendeten ARM-Cores bzw. dessen Debug-Moduls (diese PDFs sind eher bei ARM zu finden als bei LM). > Ist es also nicht möglich die Startup.s so zu > modifizieren dass er das Program in SRAM lädt Doch. Aber die Chancen auf eine detaillierte Auskunft wächst mit dem Alter des eingesetzten Controllers. Lies: brandneue Typen kennt keiner. > und von dort aus startet ? Prinzipiell würde mich auch interssieren > ob das Debuggen überhaupt ohne jeglichen ULink JTAG Adapter oder so > möglich ist !? Ja. Mit anderen JTAG-Adaptern. Oder indem du mit dem JTAG einmalig einen Bootloader in den Controller verfrachtest. Gibt es zumindest für andere LM3s bei LM selbst. Und das Debugging nicht mit Debugger, sondern mit Trace-Ausgabe machst (ich benutze selten Debugger, sobald LED-Ausgabe oder UART funktionieren). PS: Begriffe: Software-Breakpoints = Flash-Programmierung, Hardware-Breakpoints kommen hingegen ohne Flash-Programmierung aus.
Ich glaubs ja nicht, das Ding hat Bitbefehle und Division! Ist quasi ein 32Bit 8051-er. Könnte mir schon gefallen. Blöd ist nur, daß wir uns schon auf den LPC eingeschossen haben. Peter
> Ist quasi ein 32Bit 8051-er.
Hehe... Welch ein Lob ;-).
Ja, der Cortex M3 ist ein deutlicher Schritt vorwärts. Schau dir mal die
Interrupt-Handhabung an. Ist die einzige mir bekannte Kiste, bei der ein
Interrupt-Handler weder einen speziellen Stack-Frame noch einen
speziellen Return-Befehl benötigt, also eine ganz normale C Funktion
ist.
Der Cortex M3 ist sozusagen nach den Alpha-Arm7/9-Versionen die Release-Version... Fehlen nur noch ein wenig höhere Taktfrequenzen und mehr Speicher, dann ist die Arm7-Familie obsolet.
Dieter wrote: > Der Cortex M3 ist sozusagen nach den Alpha-Arm7/9-Versionen die > Release-Version... Du meinst, nach gut 2 Jahrzehnten Jahren Beta kommt nun die Release? ;-) > Fehlen nur noch ein wenig höhere Taktfrequenzen und mehr Speicher, dann > ist die Arm7-Familie obsolet. Freu dich nicht zu früh, x86 ist seit knapp 30 Jahren obsolet.
Also die Krücke mit den Set- und Reset-Registern des LPC hat mir noch nie gefallen. Wenn dann noch diese blöden spurious Interrupts weg sind, ist das wirklich ein goiles Teil, mit dem man auch arbeiten kann. Und 64kB RAM ist auch schön, die LPC (>48Pin) haben ja leider nur max 16kB. Der LM3S8970 könnte bei mir ein komplettes Board ersetzen. Peter
Peter Dannegger wrote: > Also die Krücke mit den Set- und Reset-Registern des LPC hat mir noch > nie gefallen. Wenn du die Bitadressierung des RAM- und I/O-Bereichs meinst: Es ist damit etwas schwierig, ein I/O-Modul mit Adresse oder Nummer eine I/O-Kanals oder einer Portnummer zu versehen, da sich die Bitadresse nur vergleichsweise aufwendig aus der Adresse berechnen lässt, wenn die als Parameter übergeben wird und nicht als Konstante. An den Set/Reset-Registern von den LPCs hat mich bisher nur gestört, dass sie bei der Richtungssteuerung fehlten (z.B. 1-Wire), Atmel ist da bei den SAM7 konsequenter. Von den LM3 kenne ich bislang nur die Doku der kleinsten Exemplare. Da finde ich die Möglichkeit, Portpins als O.C. definieren zu können, zwar ganz nett, aber was nützt das, wenn man nicht in der Lage ist bei solchen Pins den aktuellen Zustand des Pins auslesen zu können ohne zunächst die Richtung umschalten zu müssen? Ein über die verwendete ARM PrimeCell geerbtes Problem, das mir schon beim STR9 auffiel.
Tom wrote: > Ich habe > mir kürzlich > von der Firma Mouser Electronis ein EVB Board von Luminary Micro > LM3S8962 > zugelegt. Wo bestellt man denn bei Mouser? Direkt in USA ist ja immer blöde. Ich werds wohl bei Atlantik bestellen, stolze 89,-€. Auch endlich mal ein ordentliches SPI ist drin (16Bit*8 FIFO, 25MHz). Peter
Peter Dannegger wrote: > Auch endlich mal ein ordentliches SPI ist drin (16Bit*8 FIFO, 25MHz). Die ARM PrimeCell PL022. Philips hat bei den LPC2000 ziemlich viel selber gebaut, die Stellaris Dinger hingegen sind eher ein Baukasten aus ARM PrimeCells.
Danke für die vielen Anregungen und Spezifikationen. g Als Ersteller diesen Threads würde mich doch noch mehr Informationen über das Thema des Beitrags interessieren. Wenn sich hier also kompetente Embedded Entwickler aufhalten würde es mich doch sehr freuen wenn sich hier weitere Details im Bezug auf das "Debuggen im internen SRAM" befinden. Hat das vielleicht mal Jemand mit einem anderen Board und einer anderen Entwicklungsumgebung gemacht ?
Ich denke du machst du zuviel Sorgen wegen nichts. Natuerlich leidet Flash irgendwann, aber zuerst wird wohl die Vergesslichkeit zunehmen. Es kann dir doch bei einem Entwicklungsboard egal sein ob das sein Programm noch 10-30Jahre haelt, oder bereits nach ein paar Monaten vergisst. Wenn das wirklich ein ernstes Problem waere dann wuerde man dir gleich auf Seite 2 des Handbuchs zum Board davon erzaehlen und der Prozessor waer gesockelt. Ich hab jedenfalls noch nie Ruecksicht auf soetwas genommen und hatte auch noch nie ein Problem. Olaf
Tom wrote: > Wenn sich hier also kompetente Embedded Entwickler aufhalten > würde es mich doch sehr freuen wenn sich hier weitere Details im Bezug > auf das "Debuggen im internen SRAM" befinden. Hier sind ne ganze Menge kompetenter Embedded Entwickler. Allerdings bedeutet Kompetenz nicht, immer mit nem 32Bit Boliden auf jede kleine Aufgabe draufzuhauen oder immer den allerneuesten Chip zu benutzen, den noch kein anderer hat. > Hat das vielleicht mal Jemand mit einem anderen Board und > einer anderen Entwicklungsumgebung gemacht ? Die meisten MCs haben garkeinen Code-SRAM oder nur sehr wenig SRAM, da stellt sich so ein Problem nicht. Der Flash läßt sich in der Regel auch schnell genug programmieren. Ich werd ihn mal bestellen und sehen, wie er sich so programmieren läßt (Toolchain). Allerdings werde ich nicht den 2.Schritt vor dem 1. tun, sondern erstmal mit den Beispielen anfangen. Wenn die laufen und man merkt, daß die Programierung langsam oder umständlich ist, kann man dann mal nen eigenen Flash- oder SRAM-Bootloader basteln. Ich kann mir auch gut vorstellen, daß bei so einem brandneuen Chip das Luminary-Forum die beste (einzige ?) Anlaufstelle ist. Peter
Peter Dannegger wrote: > Ich werd ihn mal bestellen und sehen, wie er sich so programmieren läßt > (Toolchain). So, das Ding steht jetzt bei mir aufn Tisch. Eigentlich sinds ja 2 Bords, damit man CAN ausprobieren kann. Versorgt wirds über USB, da liegt auch JTAG und die RS232 mit drauf. Ist schon mächtig beeindruckend, was das alles kann. Ist ein kleines Spielchen drauf auf dem 128*96 OLED-Display und als Webseite (Java). Und auch massig Beispiele (Grafikdisplay, SD-Card, CAN, Ethernet, Interrupts, ...) Also erstmal ne ganze Menge zu lesen. Peter
Oh das hört man ja gerne einen Kompagnon zu haben. Wo hast du das Board den bestellt. Ich musste 4 Tage auf meins warten da es aus den USA kam. Welche Entwicklungsumgebung hast Du dazu bestellt. Vielleicht löst sich so auch die Frage ob der Keil Debugger Hardware Breakpoints in Flash verlagert oder nicht !? Würde mich freuen wenn Du deine Erkenntnisse weiterhin in diesen Thread posten würdest. Wär sicherlich interessant für alle die sich mit dem Board auseinandersetzen möchten.
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.