mikrocontroller.net

Forum: Compiler & IDEs Quellen für Mikrocontrollerspezifische Programmierung


Autor: Gast (Gast)
Datum:

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

Autor: Joe (Gast)
Datum:

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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

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

Autor: Joe (Gast)
Datum:

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

Autor: Gast (Gast)
Datum:

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

Autor: Εrnst B✶ (ernst)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [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.