Forum: Mikrocontroller und Digitale Elektronik Artikel LPC-Tutorial: Kritik und Anregungen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von N. G. (newgeneration) Benutzerseite


Bewertung
3 lesenswert
nicht lesenswert
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.

von W.S. (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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.

von N. G. (newgeneration) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von NanoGeneration (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

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

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.