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????
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
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????
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.
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.
>>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.
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
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
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
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.