Hallo Forum, ich habe in der letzten Zeit während meiner Arbeit an den LPC-Chips von NXP ein Einsteiger-Tutorial erarbeitet, das es dem Leser erlaubt, "from scratch", also ohne Hersteller-Libraries auf Basis der CMSIS seinen Controller programmiert. Dieses ist seit vorhin unter LPC-Tutorial zu finden. Ich würde mich freuen, wenn ihr hier Lob, Kritik, Anregungen, usw. postet, damit der Artikel erweitert/verbessert werden kann. Mit freundlichen Grüßen, N.G.
N. G. schrieb: > Ich würde mich freuen Nun.. hoffentlich. Also, mit deinem Artikel hast du dir ja große Mühe gegeben, aber es gibt von meiner Seite daran einige Bemerkungen: 1. Du hast dich einzig und allein auf den GCC bezogen. Kann man ja machen, aber es ist doch sehr einschränkend und für den Anfänger verwirrend und eigentlich komplizierter, als es sein müßte. 2. Du hast als erstes über ein Linker-Skript referiert. Man kann sich sowas machen, wenn man denn schon den GCC benutzen will, aber selbst für den GCC ist das normalerweise nicht erforderlich. Man muß sich nur beim Startupcode an die im Linker vorgesehenen Sektionen halten. Wenn ich mich recht erinnere, dann müßte das für den Startup etwa so lauten: ".section .text.startup". 3. Du hast versucht, den Startupcode in C zu formulieren. jaja, das ist zwar heutzutage möglich, aber ich halte einen Startupcode in Assembler für wesentlich besser - nicht nur wegen der Klarheit über die tatsächliche Funktionalität beim Aufstarten der ganzen Prozessors, sondern auch, um einem Anfänger die "weak"-Funktionalität so zu erklären, daß er sie versteht. 4. Vielleicht solltest du deinem geneigten Leser nicht sowas vorsetzen:
1 | LPC_SYSCON->AHBCLKCTRLSET0 = SYSCON_AHBCLKCTRL0_GPIO0_Msk | SYSCON_AHBCLKCTRL0_IOCON_Msk; |
2 | LPC_IOCON->PIO0_29 = (0x0 << IOCON_PIO0_29_FUNC_Pos) | /* ! */ |
sondern ihm einen tatsächlichen Rumpf für einen bestimmten kleineren (und gut erhältlichen) Chip an die Hand geben. Heutzutage wäre das einer, der sowohl einen UART als auch USB an Bord hat, und das Minimalsystem würde aus folgendem bestehen müssen: - Batchdatei (Win) oder Skript (Lin) um mit einem Wutsch das Projekt komplett durchzuziehen bis zum funktionablen Hexfile - Startupcode - funktionierende Handler für UART und USB-CDC - Systemuhr auf SysTick-Basis - Kommandoprogramm mit wenigstens einem Kommando implementiert, z.B. Speicher anzeigen (sowas wie "d 0 ff" was meint dump von 0 bis 0xff) - main mit Grundschleife und sonst nix. - in deinem Fall eben auch makefile, Linkerscript oder sonstiges, wo du meinst daß man es zum Übersetzen notwendig braucht. Bei mir wären das nur die .xcl (extended command lines) Ich habe sowas ähnliches hier vor einiger Zeit für nen kleinen STM32F103C8T6 und Keil und Windows schon mal gepostet. Vielleicht guckst du dir das mal an, um zu sehen, wie ich das oben Geschriebene meine. Nun, ich selbst arbeite in allen Punkten nicht so wie du. Ich benutze den Keil, also die Toolchain von ARM selbst, ich habe den Startupcode in Assembler, ich benutze kein Make und keine GCC-Linkerscripts, sondern eine simple Batchdatei, wo die Tools quasi von Hand aufgerufen werden und ich weiß aus langer Erfahrung, daß diese Art auf lange Sicht eben auch systemübergreifend die beste ist, weil man sich eben nicht auf eine IDE oder eine Toolchain oder eine Ziel-Architektur festlegen muß - ich mache das für NEC, Fujitsu und ARM auf diese Weise. Für die Lernbetty hatte ich das zweigleisig durchgezogen, mit Keil und mit GCC (yagarto 4.??) - und das hat beides funktioniert. Also, versuche du mal, nicht ÜBER das Thema zu referieren, sondern einen praktischen Leitfaden zu schreiben. Dazu gehört auch Strategie - und von der habe ich bei deinem main() nichts gesehen. Hardwaregefummel gehört besser in dedizierte Treiber, so daß man sauber zwischen Treibern und Algorithmen unterscheidet. So, jetzt hab ich ernste Zweifel, ob du dich noch immer freust. W.S.
Hallo W.S., tut mir Leid, dass ich mich jetzt erst melde, das hat im wesentlichen 2 Gründe: 1) ich hab den Thread übersehen (Benachrichtigung war wohl nicht aktiv) 2) ich befinde mich zurzeit in der Klausurenphase (Studium), habe also sehr wenig Zeit mich hier um das Forum zu kümmern. Zu deiner Antwort: W.S. schrieb: > 1. Du hast dich einzig und allein auf den GCC bezogen. Kann man ja > machen, aber es ist doch sehr einschränkend und für den Anfänger > verwirrend und eigentlich komplizierter, als es sein müßte. Ja, da hast du durchaus recht, das kann man ja auch auf andere Compiler erweitern. Hintergrund ist, dass ich das Tutorial an das AVR-GCC-Tutorial anlehnen will und ich nunmal bis jetzt nur mit dem GCC gearbeitet habe. Die Erweiterung müsste dann jemand anders einpflegen. W.S. schrieb: > 2. Du hast als erstes über ein Linker-Skript referiert. Man kann sich > sowas machen, wenn man denn schon den GCC benutzen will, aber selbst für > den GCC ist das normalerweise nicht erforderlich. Man muß sich nur > beim Startupcode an die im Linker vorgesehenen Sektionen halten. Wenn > ich mich recht erinnere, dann müßte das für den Startup etwa so lauten: > ".section .text.startup". Natürlich geht es auch ohne (das sollte dann auch in den Artikel, kommt auf die TODO-List), aber ich persönlich mache es mit, weil es dann imho verständlicher ist, was im Linker passiert. Ist ja auch schön das der GCC das anbietet ;-) W.S. schrieb: > 3. Du hast versucht, den Startupcode in C zu formulieren. jaja, das ist > zwar heutzutage möglich, aber ich halte einen Startupcode in Assembler > für wesentlich besser - nicht nur wegen der Klarheit über die > tatsächliche Funktionalität beim Aufstarten der ganzen Prozessors, > sondern auch, um einem Anfänger die "weak"-Funktionalität so zu > erklären, daß er sie versteht. Da können die Meinungen auseinander gehen, ich persönlich finde es für jemanden, der von der PC-Programmierung kommt, einfacher, wenn er bei seinem C bleiben kann. Letzten Endes muss der Code sowieso nur kopiert und etwas angepasst werden, genauso wie die selbe Funktionalität ins Assembler. Aber auch hier könnte man das Tutorial erweitern. Generell muss ich aber noch den Text und vor allem die Erklärungen überarbeiten, da sind zum Teil Sprachkonstrukte entstanden, die ...naja ;-) W.S. schrieb: > 4. Vielleicht solltest du deinem geneigten Leser nicht sowas > vorsetzen:LPC_SYSCON->AHBCLKCTRLSET0 = SYSCON_AHBCLKCTRL0_GPIO0_Msk | > SYSCON_AHBCLKCTRL0_IOCON_Msk; > LPC_IOCON->PIO0_29 = (0x0 << IOCON_PIO0_29_FUNC_Pos) | /* ! */ Ja, da hast du recht, das werde ich nochmal überarbeiten, hat mir selbst auch nicht gefallen. W.S. schrieb: > Nun, ich selbst arbeite in allen Punkten nicht so wie du. Ich benutze > den Keil, also die Toolchain von ARM selbst, ich habe den Startupcode in > Assembler, ich benutze kein Make und keine GCC-Linkerscripts, sondern > eine simple Batchdatei, wo die Tools quasi von Hand aufgerufen werden > und ich weiß aus langer Erfahrung, daß diese Art auf lange Sicht eben > auch systemübergreifend die beste ist, weil man sich eben nicht auf > eine IDE oder eine Toolchain oder eine Ziel-Architektur festlegen muß - > ich mache das für NEC, Fujitsu und ARM auf diese Weise. Naja, Diversität ist ja nichts schlechtes. Wäre ja langweilig wenn alle das selbe machen würden ;-) Gerade Make finde ich aber immernoch eine gute Wahl, um seine Projekte zu kompilieren. Aber wie alles (inklusive Wahl der Toolchain) ist das Geschmackssache. W.S. schrieb: > Also, versuche du mal, nicht ÜBER das Thema zu referieren, sondern > einen praktischen Leitfaden zu schreiben. Dazu gehört auch Strategie - > und von der habe ich bei deinem main() nichts gesehen. Hardwaregefummel > gehört besser in dedizierte Treiber, so daß man sauber zwischen Treibern > und Algorithmen unterscheidet. Ja bei erneutem Durchlesen nach >2 Wochen springt einem das förmlich ins Auge, das wird definitiv noch einmal überarbeitet (Allerdings war das Hardwaregefummel ja nur ein "Hello World"-Beispiel). Ich Moment denke ich darüber nach, gerade die Toolchain-spezifischen Teile in einen Unterartikel auszulagern, damit Leute, die andere Tools nutzen oder das Zeug schon kennen, sich nicht langweilen müssen. > So, jetzt hab ich ernste Zweifel, ob du dich noch immer freust. Naja, jede Rückmeldung ist erst mal positiv und deine ist auch konstruktiv. Danke erst einmal dafür. Meinungsverschiedenheiten bei solchen Themen finde ich auch nicht schlimm, ich verpflichte schließlich keinen, das so zu machen wie ich will ;-) In ca. 2-3 Wochen sollte ich dann das Tutorial überarbeiten/erweitern können und dabei versuche ich, deine Anregungen zu beachten. Es steht aber jedem frei, direkt selbst am Artikel mitzuarbeiten, ist schließlich ein Wiki. Danke und mit freundlichen Grüßen, N.G.
Hi newgeneration, dein Tutorial ist super und in der Kombination (LPC, GCCmit Linker Scrict und Make) auch einzgartig. Laß' Dich von dem Genöle von W. S. nicht entmutigen. Na klar kann man immer alles anders machen. Wer kein Linker Scrict und Make benutzen will braucht es ja nicht tun. Houffentlich hast Du nicht demn Mut verloren, den ich würde gerne die noch roten Links mit Leben erfüllt sehen.
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.