Embedded Controler, Protokollsammlung

[mojo777]

Hallo.
Möchte alle bitten deren Protokolle über das Praktikum im Fach Embedded Controller hier hochzuladen, so dass man auch andere Themen schnell überblicken kann ohne sich das Datenblatt von c167 für die klausur reinkloppen zu müssen.

Gruß

[macoio]

sehr gute Idee, und bitte die Aufgabenstellung dabei nicht vergessen :-O

[mrpiggi]

Bitteschön. Und hier gleich noch der Link.

[raily]

neues Protokoll (PWM Signale mit CAPCOM und Hex-Tastatur erzeugen) hinzugefügt.

[frankne]

Is zwar kein Protokoll aber trotzdem hilfreich, einige waren ja nich in der VL:

- Besonderheiten Begriff Embedded Controller
- Unterschied MikroController und MikroProzessor, FPGA etc.
- Was ist ein mechatronisches System? Was kennzeichnet es, wo wird es eingesetzt? Beispiele (Verteilte Systeme)
- Verwendungsmöglichkeiten heutiger MikroController
- Welche Einheiten hat ein MikroController, Aufbau, Wirkungsweise, Bussysteme
- Analog/Digital-Wandlung! Berechung anhand Diagramm wie C 167
- Echtzeit, was ist das, Klassifikation
- Zahlen Darstellungen Hexa <-- Dezimal <-- Binär
- Grundelemente der Rechenarchitekturen, Mikrorechenarchitektur
- Speicher Grundlagen, Halbleiter, Funktion ( C166/C167)
- Programmieren – Adressieren, Takt ( Clock), Power Mode, Stack (was ist das), Pipeline, Timer, PWM, out/in, interrupt, PEC-transfer, capture compare
- Betriebssysteme
- Testverfahren
- V-Model

[Andi80]

Kannst Du die obligatorische Frage nach der Raumaufteilung evtl. auch gleich noch beantworten?

Dank Dir im Voraus!

[Quentin]

A - K im POT 81 H
L - Z im HSZ 04

[Andi80]

* thumbs up *

[sgl]

Und wann geht es eigentlich los?;-)

[Quentin]

Ist die Frage ernst gemeint?

[sook_netaction]

Klausur: 26.07.2007
11.10 Uhr - 13.10 Uhr (120 min)

[Quentin]

Mal ne Frage. Kapitel 7 ... Absatz Rapid Prototyping.

[quote][...]auch sollten Funktionen, die aus Leistungsgründen in Hardware ausgeführt werden müssen, automatisch in Hardwarebausteine geladen werden können.[/quote]

Was zur Hölle soll das heißen?

[raily]

Das ganze Kapitel 7 kommt mir ziemlich eigenartig vor.
Zu deiner Frage:
Kann mir das nur so erklären, dass es bei besagten Rapid-Prototyping wichtig ist, alles möglichst nahe am späteren Einsatzsystem zu haben. Dazu gehört dann anscheinend, dass man direkt in Hardware realisierte Funktionen (zb. AD Wandlung) auch im Prototyp in Hardware implementiert.

Ich hab mal ne Frage zum Programmbeispiel GPT im Skript:

Code: Alles auswählen

int main(void)
{
     DP2=0xFFFF;   //P2 ist Ausgang
     P2=0;                 // Rücksetzen des Zählers
     richt =1;             //Port 3.3 ist Ausgang
     daten= 1;          //P3.3 Daten sind high
[...]

Muss nicht P7.0 als Eingang initialisiert werden?

Vielleich hab ich da auch einen Verständnisfehler.
Zu der Problematik mit den Ports sieht es in den Blockschaltbildern (siehe C167 manual) ja so aus, dass man von der Softwareseite in das Port-Output-Latch schreibt, wenn man einen Ausgang setzen will. Falls dieser Port nun als Ausgang definiert ist, wird durch den Muxer eben dieses durch Software geschriebene Latchsignal beim Auslesen des Ports gelesen.
Ich will doch P7.0 hier aber als Eingang haben! wenn ich das nicht explizit definiere, kann es doch sein, dass ich aus dem Output-Port-Latch lese, statt wie gewünscht direkt den Pin. Oder nicht?

Mir fällt gerade noch was ein:
Wie bekomme ich aus nem C-Programm heraus den Prozessor in den Idle- bzw. Suspend-Mode? Im Skript stehen ja nur die Assemblerbefehle und bis jetzt habe ich nicht herausgefunden, ob und wie der Compiler von Keil inline-assembler unterstützt.
- Editiert von raily am 25.07.2007, 14:13 -
- Editiert von raily am 25.07.2007, 14:18 -

[mrg007]

Also entweder ich hab deine Frage nich richtig verstanden oder die Antwort ist, dass alle Register standardmäßig auf Eingang gesetzt sind.

Gruß

[Fipps der Affe]

Ich würde den Port 7.0 auch anfangs lieber definieren.
Wofür brauch ich eigentlich den Port 3.3, also das T3OUT? Was geb ich denn auf dem einen Pin aus? Das Ergebnis kommt ja auf dem P2.

[raily]

@MrG007: ja hast meine Frage richtig erkannt.

@Fipps:

T3 ist ja so konfiguriert, dass er die alternative Output-Funktion von P3.3 nutzt ( T3OE = 1), deshalb wird dort bei jedem Timerüberlauf der Pegel getoggled. Somit könnte man mit einem Oszi an P3.3 mitzählen und überprüfen ob in P2 der richtige Wert steht.
Und nur aus diesem Grund wurde P3.3 = 1 gesetzt (der Kommentar ist für mich nicht gerade hilfreich). Denn es findet eine VerUNDung von AltDataOut und Port-Output-Latch statt (siehe Blockdiagramm zu Port 3 im Handbuch)

[Quentin]

:kopfkratz:


Wie sagte einmal jemand?
[quote]Ich verstehe das irgendwie alles nicht.[/quote]