Neulingen und Seiteneinsteiger verfügen oft nicht über hinreichendes Grundlagenwissen. Im Netz ist das, bei der Fülle an Informationen, schwer zu finden. Und gute Bücher für Schüler oft schlicht zu teuer. Hier würde ich gerne etwas helfen. Schöner wäre es, wenn es ein Forum "Grundlagen" gäbe. Trotzdem probiere ich es mal testweise in diesem. Mein erster Beitrag besteht aus drei Teilen zum Thema STACK. Andere Themen sind in Vorbereitung und würden bei positivem Echo folgen. Zahlentheorien und -systeme, Mathematik mit µP, strukturierte Programmierung u.s.w. Ich bitte hierzu um Feedback. Allgemein in's Forum, speziell bitte direkt.
als PDF
http://www.mikrocontroller.net/attachment.php/677/Der-Stack-1.pdf http://www.mikrocontroller.net/attachment.php/675/Der-Stack-2.pdf
Dem C-Compiler sind alle Schweinereien erlaubt. In Assembler dagegen würde ich die Parameterübergabe im Stack wirklich nur mit der Kneifzange anfassen. Die Gefahr eines Fehlers ist da einfach zu groß. Und Stack-overflow/-underflows sind Dinge, die einen Wochen kosten können beim Debuggen. Typisches Zeichen solcher Fehler ist nämlich, daß sie sich an einer ganz anderen Stelle auswirken, d.h. man sucht den Fehler erstmal in einem völlig unschuldigen und fehlerfreien Programmteil. Die Registerübergabe ist da wesentlich gefahrloser und auch Code sowie Rechenzeit sparender. Besonders, da der AVR ja massig Register zu Verfügung hat. Wenn da mal ein Register zuviel oder zuwenig abgeholt wird, tritt der Fehler auch direkt an dieser Stelle auf und läßt aber nicht das gesamte Programm abstürzen. Und von eine variablen Parameterzahl im Stack gehen natürlich noch ungleich höhere Gefahren aus. Wie leicht ist da mal die nächst tiefere Returnadresse als Parameter versaubeutelt. Für den Fall der Bearbeitung eines Datenfeldes variabler Länge übergibt man da besser einen Pointer auf das Datenfeld, daß vorher vom Aufrufer irgendwo im RAM angelegt wurde. Zur Sicherheit wird dann dieses Datenfeld mit der maximalen Länge reserviert und genau dieselbe maximale Länge verwendet dann die Unterfunktion zum Abtesten, um keinesfalls darüber hinaus Daten zu verwursteln. Z.B. übergibt bei mir die UART-Empfangsroutine einen Zeiger auf das erste Zeichen an den Kommandointerpreter. Der testet dann alle Zeichen in dem Ringpuffer, indem er nur mit "INC YL" weiterzählt. Der Ringpuffer geht von 0x100...0x1FF, d.h. er kann somit nie überschritten werden. Peter
Ja,eine Ecke für Neueinsteiger wäre gut.
Damit man den Profis nicht in die Quere kommt.
Wo keine Frage zu einfach ist...
z.B.: Entprellen.Suche Erklärung in Worten:Funktionsprinzip,
Varianten ("viele Wege nach Rom").Warum macht es jeder anders?
Entprellen von Tastern kann doch kein so massives Problem
sein? Gibt es keine optimale Lösung für fast alle Fälle?
Was ich kenne:Mehrfachabfrage und Vergleich,Monoflop,
Flankenwechselerkennung.Aber nur im Prinzip.
Fertige Listings sind zwar nett,besser ist zunächst eine
kurze Erklärung in Worten,was zu tun ist.
(Verbaler Algorithmus).Sonst verstehe ich wenig.
Halbwissen rächt sich,klauen und kopieren auch.
Lieber selber austesten und entwickeln.
Bekannt:Die 2-Gatter TTL Schaltung mit Wechsler.
Damit hab ich bisher erfolgreich entprellt.
Wenn ich nochmal lese wie sie genau funktioniert,
könnte ich das auch in Programmform fassen.
Desgleichen ein Monoflop oder Mehrfachabtastung+Vergleich.
uli
@bukongahelas "Gibt es keine optimale Lösung für fast alle Fälle?" Leider nicht! Geht auch nicht, kommt immer auf den Schalter/Taster- Type an und welche Hardware vorliegt. Mit µP und Tastatur muß man anders umgehen als mit µP und einzelnen Tastern oder Schaltern (auch wenn einige das anders sehen mögen). Wenn Gatter übrig sind nehme ich die dafür ansonsten kann man sich auch mit RC Kombination helfen. Alle Möglichkeiten ausschöpfen und einen "eigenen" Stil entwickeln, das führt zusammen mit zunehmender Erfahrung immer zum Ziel. Vorsicht mit der kritiklosen Übernahme von fertigen Schaltungen und Codeschnipseln, die sind zwar meistens sehr gut, lernen aber NIE mehr dazu! Die Schaltung/das Programm soll nicht vornehmlich gut aussehen, sondern gut funktionieren. An manchen Beispielen im Forum sehe ich eher das umgekehrte Wollen. Beides zusammen braucht viel Erfahrung. Grundsätzlich sollten die Fragen so präzise und umfangreich wie möglich gestellt werden (gerade für Neulinge) Redundanzen schaden hier nicht, sondern helfen die Frage zu verstehen. MfG Manfred Glahe
@bukongahelas "Damit man den Profis nicht in die Quere kommt. Wo keine Frage zu einfach ist..." In die Quere kommst Du nicht, Fragen sind sogar erwünscht. Man muß bloß auf den Punkt fragen, nur allgemein "Ich verstehs nicht" hilft keinem weiter. Du must dem Profi also bloß sagen wo Du Probleme hast, je ausführlicher umso besser. Es macht auch einen guten Eindruck, wenn man sich die Fragen in aller Ruhe offline überlegt und erstmal selber durchliest, ob ein andere auch kapieren könnte, was Du meinst. Wenn Du z.B. bei einer Zeile eines Beispielprogramms nicht weiter kommst, dann benenne genau, welche Zeile Du meinst. Sinnvoll könnte auch eine kurze Beschreibung sein, wie Du die Wirkungsweise der vorhergehenden Zeilen verstanden zu haben meinst. Eine Frage, die erkennen läßt, daß man sich damit beschäftigt hat und sei sie auch noch so einfach, beantworten auch Profis gerne, wenn sie nicht gerade schon 10-mal innerhalb der vergangenen Wochen gefragt wurde. Aber auch Kommentare zu den Beispielen sind erwünscht, z.B. welche Punkte nur schwer verstanden wurden und besser etwas ausführlicher erläutert werden sollten. Peter
und weils vielleicht gerade in diese Reihe passt: Versuche doch mal einige Leerzeichen an geeigneten Stellen einzustreuen. In einer SMS hast du nur wenige Zeichen Platz - hier dagegen kannst du dich fast austoben... erhöht auch die Chance gelesen zu werden. So ist das nämlich extrem schwierig zu lesen. Dankeschön, ----, (QuadDash).
Entprellen:Anbei Listing mit int T0 Overflow int zur Tasterabfrage.Wenn ich nur alle 16ms "blitzartig" abfrage, sind Preller zu langsam,nach weiteren 16ms Prellerei beendet. Ja, max 16ms Verzugszeit des Tastendrucks,ist egal,bin eh nur ein lahmer Primat.Sollte ich noch langsamer abtasten? z.B. alle 63ms bei Prescale/1024 ? Quarz: 4194304Hz:1024=4096Hz 4096Hz:256 ($FF)= 16Hz = 62.5ms = 63ms Ist es so korrekt oder sonstige Fehler im Programm ? ----------------------------------------------------------- Ja,Lothar,der Themenkomplex: "Digitale Signalverarbeitung möglichst ohne Mathe" wäre sehr interessant. Muß ich die ganze Theorie kennen,um Bytes mit Koeffizienten nach bestimmtem Algorithmen zu multiplizieren? ----------------------------------------------------------- Gruß Uli
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.