Hallo, komischer Beitragstitel, ich weiss - aber mir ist nichts besseres eingefallen. Mich würde interessieren, ob es irgendwo gute Quellen gibt, die die C-Programmierung (GCC?) auf uC etwas näher erläutern. Mich interessiert vor allem sowas wie: Warum kann ein Interrupt bei einem 16Bit Zugriff (8-Bit Architektur) etwas zerstören? Hinterlässt ein Interrupt nicht die Umgebung genauso wie er sie vorgefunden hat? Dies nur als Beispiel, ich bin nicht direkt an der Beantwortung interessiert, sondern an Quellen und Beispielen zur Programmierung speziell von uCs. Kosten sollten möglichst keine entstehen, da ich dieses Wissen momentan nciht "brauche" und in Geld umwandeln kann ;-) Naja, is halt Hobby. Danke, Torsten.
Aaaahhh, das was du suchst nennt sich Buch. Früher gabs die auf bedrucktem Papier aber heutzutage findet man auch papierlose Formen. Spaß beiseite, du machst leider keine konkreten Angaben daher kleine Auswahl: http://www.hitex.co.uk/c51primer/c51primer.pdf http://www.mikrocontroller.net/articles/AVR-Tutorial
> Hinterlässt ein Interrupt nicht die > Umgebung genauso wie er sie vorgefunden hat? Du machst hier einen Denkfehler: Von alleine macht ein Prozessor so gut wie gar nichts. Er hat seine 100 oder 200 Befehle und die werden ausgeführt (Ein Interrupt ist kein Befehl, zumindest nicht auf µC Ebene) Jeder Befehl für sich ist sehr einfach und erst die Abfolge der Befehle in der richtigen Reihenfolge sorgt für den Aha- Effekt beim Laien. Deshalb hinterlässt ein Interrupt nicht die Umgebung so wie er sie vorgefunden hat. Er sollte es tun, ja ich würde sogar sagen, wenn er es nicht tut (ausser natürlich den dokumentierten und gewollten Änderungen) dann ist Ärger vorprogrammiert, aber von alleine macht er es nicht. Da gibt es immer noch den Faktor Programmierer, der letztendlich entscheidet was zu tun ist und dessen Aufgabe es ist, dies sicherzustellen. "Computer, die Schilde remodulieren. Ich geh mal schnell eine neue Subroutine schreiben" gibts halt nur bei Star Trek. > sondern an Quellen und Beispielen zur Programmierung > speziell von uCs Solche Quellen gibt es, keine Frage. Das Tutorial hier ist zb. eine Anlaufstelle. Aber: Lesen ist super. Lesen ist eine unabdingbare Voraussetzung zum Einstieg. Aber nichts wiegt einen Erfahrungsschatz auf. Das ist wie Radfahren oder Schwimmen. Du kannst Unmengen an Büchern darüber lesen. Lernen wirst du es erst wenn du es tust. Und es ist ganz normal, dass man dabei auch ein paar mal kräftig auf die Schnauze fällt (beim Schwimmen vielleicht nicht so). Das muss auch so sein. Letztendlich lernen wir Menschen am meisten immer noch durch die Fehler die wir machen. Ich würde sogar soweit gehen zu sagen: Etwas programmieren kann man schnell lernen. Aber ein Profi-Programmierer wirst du erst nach Jahren. Ich verdiene jetzt etwas mehr als 20 Jahre lang meine Brötchen mit programmieren. Ob ich alles weiß? Noch lange nicht!
Karl Heinz, nicht tiefstapeln, deine Beiträge sind in der Regel absolut
klasse. Ich jedenfalls lerne immer wieder etwas.
> Aber ein Profi-Programmierer wirst du erst nach Jahren.
Das kann ich bestätigen, bin allerdings erst ca. 15 Jahre dabei.
Learning by doing ist in der Tat der beste Weg. Ich finde es immer
wieder interessant wie wenig man die Dinge voraussehen kann. Der Aha
Effekt kommt also nur durch Fehler zustande.
Aber noch einmal zur Frage, du willst doch nicht nur Theorie ? ebenso
war meine Frage nach ein paar mehr Angaben nicht ohne Grund. Wenn du zum
Beispiel einen konkreten MC angeben kannst dann gibt es auch Literatur.
Der C51 Primer behandelt z.B. die 8x51 Familie. Das Ding ist lesenswert
wenn man wissen will wie's geht.
Hi, danke für die Antworten. Also ich arbeite (auch) mit AVRs und weiss selbst nicht so genau, was ich eigentlich suche. Das Tutorial ist wirklich ein sehr guter Anlaufpunkt, allerdings mit sehr vielen Informationen, die ich schon kenne (lange nicht alle, nur um keine Missverständnisse aufkommen zu lassen), die Standardsachen halt. Ich hab mehr an sowas gedacht wie eine Sammlung von "Standardfehlern oder Tipps" o.ä. wo dann nur so Sachen drin stehen, wie die Interruptbearbeitung (z.B. im Tutorial die Sache mit dem cli, sei und SREG...) oder das man einzelne Bits am besten mit "REGISTER = (1 << BITNAME1) | (1 << BITNAME2) setzt oder (als weiteres Beispiel) die Sache, dass man Divisionen in einer Berechnung am Ende machen soll (Ziel = Variable * 122 / 10). Es gibt sicherlich noch tausende solcher Kleinigkeiten, die man vielleicht nicht im Tutorial findet (zuviel gehört da auch nicht rein!), die aber gute Programme erst möglich machen. Achja, hier mitlesen finde ich auch sehr interessant und informativ. Torsten
Gast wrote: > Ich hab mehr an sowas gedacht wie eine Sammlung von "Standardfehlern > oder Tipps" o.ä. wo dann nur so Sachen drin stehen, wie die > Interruptbearbeitung (z.B. im Tutorial die Sache mit dem cli, sei und > SREG...) oder das man einzelne Bits am besten mit "REGISTER = (1 << > BITNAME1) | (1 << BITNAME2) setzt oder (als weiteres Beispiel) die > Sache, dass man Divisionen in einer Berechnung am Ende machen soll (Ziel > = Variable * 122 / 10). > > Es gibt sicherlich noch tausende solcher Kleinigkeiten, die man > vielleicht nicht im Tutorial findet (zuviel gehört da auch nicht rein!), > die aber gute Programme erst möglich machen. Achja, hier mitlesen finde > ich auch sehr interessant und informativ. Nun ja, da kenn ich jetzt nix passendes, Vielleicht einen Braindump von einem der Meisterprogrammierer hier besorgen? Spass beiseite, viel kann man durch Lesen von Sourcecode lernen. Allerdings kann hier geposteter Sourcecode sowohl als negativ als auch positiv-Beispiel gelten... Ansonsten: Start halt hier im Wiki ne "C - Tips & Tricks" Seite, füll ein paar schomal ein, vielleicht füllt sich die ganz gut und kann genau das gesuchte werden ;) /Ernst
Gast wrote: > vor allem sowas wie: Warum kann ein Interrupt bei einem 16Bit Zugriff > (8-Bit Architektur) etwas zerstören? Hinterlässt ein Interrupt nicht die > Umgebung genauso wie er sie vorgefunden hat? Er zerstört doch garnichts. Das Problem gibts nur, wenn der Interrupt einen Wert übergibt und Du ihn gerade auslesen willst. Du must beide Bytes nacheinander lesen, aber genau dazwischen könnte der Interrupt ja einen neuen Wert schreiben. Dann hast Du ein Byte vom alten und ein Byte vom neuen Wert, was weder der neue noch alte Wert ist, sondern irgendeinen Blödsinn, z.B.: alt: 256 neu: 255 genau zwischen dem Lesen der Bytes geändert liest: 0 Man macht dann einfach das Lesen atomar (unter Interruptsperre) und schon hat man immer einen gültigen Wert. Peter
Bitte 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.