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:
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.
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten