Seite 1 von 1

Embedded Controller, Protokollsammlung

Verfasst: 11.07.2007 14:55
von 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ß

Embedded Controler, Protokollsammlung

Verfasst: 11.07.2007 21:15
von macoio
sehr gute Idee, und bitte die Aufgabenstellung dabei nicht vergessen :-O

Embedded Controler, Protokollsammlung

Verfasst: 12.07.2007 00:01
von mrpiggi

Embedded Controler, Protokollsammlung

Verfasst: 23.07.2007 14:18
von raily
neues Protokoll (PWM Signale mit CAPCOM und Hex-Tastatur erzeugen) hinzugefügt.

Embedded Controler, Protokollsammlung

Verfasst: 24.07.2007 19:32
von 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

Embedded Controler, Protokollsammlung

Verfasst: 24.07.2007 21:47
von Andi80
Kannst Du die obligatorische Frage nach der Raumaufteilung evtl. auch gleich noch beantworten?

Dank Dir im Voraus!

Embedded Controler, Protokollsammlung

Verfasst: 24.07.2007 21:51
von Quentin
A - K im POT 81 H
L - Z im HSZ 04

Embedded Controler, Protokollsammlung

Verfasst: 24.07.2007 22:23
von Andi80
* thumbs up *

Embedded Controler, Protokollsammlung

Verfasst: 25.07.2007 09:25
von sgl
Und wann geht es eigentlich los?;-)

Embedded Controler, Protokollsammlung

Verfasst: 25.07.2007 09:32
von Quentin
Ist die Frage ernst gemeint?

Embedded Controler, Protokollsammlung

Verfasst: 25.07.2007 09:41
von sook_netaction
Klausur: 26.07.2007
11.10 Uhr - 13.10 Uhr (120 min)

Embedded Controler, Protokollsammlung

Verfasst: 25.07.2007 11:05
von 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?

Embedded Controler, Protokollsammlung

Verfasst: 25.07.2007 13:04
von 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 -

Embedded Controler, Protokollsammlung

Verfasst: 25.07.2007 14:40
von mrg007
Also entweder ich hab deine Frage nich richtig verstanden oder die Antwort ist, dass alle Register standardmäßig auf Eingang gesetzt sind.

Gruß

Embedded Controler, Protokollsammlung

Verfasst: 25.07.2007 14:56
von 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.

Embedded Controler, Protokollsammlung

Verfasst: 25.07.2007 15:30
von 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)

Embedded Controler, Protokollsammlung

Verfasst: 25.07.2007 16:25
von Quentin
:kopfkratz:


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