Keil Simulation IO-Ports

[Heinz B. (hez)]

hello,

experimentiere gerade mit Keil herum.
Habe mir angeschaut: 
http://et-tutorials.de/898/start-der-entwicklungsumgebung-µvision/

Mein Programm:

#include <stdio.h>
#include <reg51.h>
void main(void)
{
   // INITIALIZE SERIAL INTERFACE TO 2400 BAUD @12MHz:
   SCON = 0x52;    // SCON
   TMOD = 0x20;    // TMOD
   TCON = 0x69;    // TCON
   TH1 =  0xf3;    // TH1

   P0=4;    // setzt P0 und Pins
   getchar();
   P0=2;
   getchar(); // setzt nur P0 korrekt, aber keinen einzigen Pin
}

Mein Debugger/Simulator verhält sich total seltsam.
-> Debugger gestartet
-> Peripheral -> IO-Ports -> Port0

4 gibt er bei P0 und den Pins korrekt aus.
2 zeigt er bei P0 an, bei Pins jedoch nichts.

Habe schon einiges herumexperimentiert. Ist immer genau dieses Ergebnis. 
Beim ersten mal klappt es, dann aber nie wieder.

Was mache ich denn falsch????

[Peter D. (peda)]

P0 hat keine internen Pullups.

Das Main darf nie verlassen werden, es gibt ja kein OS.
Also entweder als Endlosschleife oder Endlosschleife am Ende.


Peter

[Heinz B. (hez)]

Sehe keinen Grund, warum das Programm nicht ein Ende haben dürfe. Aber 
OK. Hatte ich vorher übrigens auch mit einer Endlosschleife probiert.

Es wird übrigens immer kurioser:

   P0 = 0xAA  ;
   getchar();
   while(1)
   {
      P0 = 0xFF  ;
      getchar();
   }

Statt 11111111 gibt mir der Debugger bei den Pins folgendes aus: 
10101010
Bei P0 passt hingegen alles: 11111111
Echt irre!! Ein Bug im uVision?

EDIT: seltsam ... mit P1 geht es

>>P0 hat keine internen Pullups.

Was bedeutet denn das? Das verursacht diese Problem????

[Heinz B. (hez)]

Also ich habe mir jetzt in einem 8051er-Buch angeschaut, wie ein Pin von 
P0 intern ausschaut. Es scheint nicht, dass die Pins irgendwie 
Verbindung untereinander hätte, sodass bei 0xFF immer nur jedes 2te Bit 
gesetzt wird.

EDIT: Hm ... ich glaube, langsam dämmert mir was. Der kann das dann 
nicht mehr im P0 umändern. Aber wieso, ist mir noch nicht klar.

[Jim G. (jimg)]

Warum ein Programm kein Ende haben darf, ins besonders wenn es so klein 
ist wie deins: Weil der µC so schnell dein Programm durch arbeitet und 
sich "aus schaltet", dass du das ergebnis nicht siehst.

Andere Frage, die mit deine Problemstellung nichts zu tuhen hat:
Fängst du gerade an µC-Technik und ET zu lernen?

Wenn ja, dann würde ich das Tut von den nicht weiter machen.
Da würde ich die AVRs von Atmel empfehlen und das Tut hier im Board.

Kosten weniger und könne genau so viel.


Achja...
Mein Lehrer für µC musste uns die selben Teile rauf und runter predigen. 
Vorgabe aus Düsseldorf wegen ZentralABI.

Ich selber bin dann später auf die AVRs umgestiegen, weil die eben für 
Hobbybastler besser geeignet sind (Preis/Leistung).

EDIT:
die Hex-Code 0xAA ist in Binär: 10101010.
Bei getchar(); wartet er auf ein tasten druck. Daher wird die Schleife 
nicht gestartet und P0 bleib bei 0xAA.

[Heinz B. (hez)]

>>Warum ein Programm kein Ende haben darf

Da wird nichts kaputt, wenn er ein Ende hat. Beim Simulieren kann man 
das machen. Im laufenden Betrieb schaut das dann natürlich anders aus :)

>>Bei getchar(); wartet er auf ein tasten druck.
>>Daher wird die Schleife nicht gestartet und P0 bleib bei 0xAA.

Er warten nicht auf einen Tastendruck, sondern auf Daten von der 
seriellen Schnittstelle (wenn ich das richtig verstanden habe). Und das 
hatte ich ja gemacht. Immer ENTER gedrückt. 'Port 0' hatte sich auch 
geändert, aber die Pins nicht.

EDIT: wie lädt man eigentlich ein Programm mittels uVision ins RAM vom 
uC? Jetzt spiele ich mich schon 5 Stunden lang damit herum, aber so ein 
Download-Button ist mir noch nicht aufgefallen. Nur ein "Download to 
Flash-Mamory"-Button (und der ist dauernd inaktiv). Aber ev. wird mein 
Board kein Flash haben, sondern nur normales RAM.

[Peter D. (peda)]

Heinz B. schrieb:
> EDIT: wie lädt man eigentlich ein Programm mittels uVision ins RAM vom
> uC?

Du hast warscheinlich irgendein Entwicklungsboard. Und da gehört eine CD 
dazu, wo die entsprechenden Tools drauf sind.


> Nur ein "Download to
> Flash-Mamory"-Button (und der ist dauernd inaktiv).

Kannst ja mal nen 8051 mit Flash auswählen, z.B. AT89C51ED2, ob sich das 
ändert.


> Aber ev. wird mein
> Board kein Flash haben, sondern nur normales RAM.

Dann mußt Du mal im Manual zu Deinem Board nachsehen.


Peter

[R. W. (quakeman)]

Heinz B. schrieb:
> Also ich habe mir jetzt in einem 8051er-Buch angeschaut, wie ein Pin von

So wie es aussieht, fängst du mit µC gerade erst an. Dann würde ich dir 
empfehlen, dieses 8051er Buch erst mal komplett durchzulesen um zu 
verstehen, wie die Controller intern arbeiten. Vor allem ist es wichtig 
die Funktionen der Hardware, als Vorraussetzung zum Programmieren, gut 
zu kennen. Denn deine Programmierversuche zeigen, daß du die 
Arbeitsweise noch nicht ganz verstanden hast.
Das ist jetzt nicht negativ gemeint, aber vor der Praxis (Programmieren) 
kommt eben erst mal die Theorie (Bücher lesen). :)

Ciao,
     Rainer

[Ralf (Gast)]

Bezüglich deiner Port/Pin-Problematik im Debugger/Simulator:

Die angezeigten Portbits entsprechen dem Port-Latch, also dem, was du in 
der Software auf den Port schreibst.
Die Pin-Anzeige dient dazu, externe Signale zu s(t)imulieren. Aufgrund 
des internen Aufbaus eines 805x-Ports, welcher ein Low-Signal aktiv 
treibt, aber ein High-Signal i.d.R. nur passiv über einen internen 
Pull-Up erzeugt, ergibt sich daraus die Schlussfolgerung, dass ein Low 
setzen des Portlatches immer auch den Pinstatus entsprechend ändert.
Aber dadurch, dass ein 805x-Portpin nur dann als Eingang fungiert, wenn 
im Portlatch ein High steht, wird der Debugger davon ausgehen, dass der 
_Pin_-Zustand vom vorhergehenden Schreibvorgang auf den Port durch den 
User extern eingestellt wurde, deswegen ändert sich von Low nach High 
der _Pin_-Zustand nicht.

Ralf