Der uVision Debugger (5.38.00 Eval Version) kommt in der Simulation nicht mit PowerDown klar, wenn ich den AT89LP51RB2 als Device verwende. Diese simple Loop kann ich im Single Step (F11) durchgehen, obwohl beim PCON |= 2 die Simulation sofort anhalten sollte, weil die Clock steht.
1
int count = 0;
2
void main(void) {
3
EA = 0; // Interrupts aus
4
while (1) {
5
PCON |= 2; // PD an
6
count++;
7
}
8
}
1
3: void main(void) {
2
4: EA = 0;
3
C:0x088C C2AF CLR EA(0xA8.7)
4
5: while (1) {
5
6: PCON |= 2;
6
C:0x088E 438702 ORL PCON(0x87),#0x02
7
7: count++;
8
C:0x0891 0508 INC count(0x08)
9
8: }
10
9: }
11
C:0x0893 80F9 SJMP C:088E
12
C:0x0895 22 RET
count wird munter hochgezählt. Ironischerweise zeigt das Command Window sogar das an, sobald ich auf PCON schreibe:
*** Power Down Mode invoked. Continue with RESET ***
Ich bin ratlos. Laut Keil sollte eigentlich alles funktionieren, keine Hinweise auf Powerdown Probleme:
Hat jemand schon den Atmel Chip in uVision erfolgreich simuliert und einen Tipp für mich?
Hintergrund siehe hier:
Beitrag "Programmer/Debugger für Silicon Image EFM8"
Ich verfüge (noch) über keine Hardware, ich will den AT89LP51 erst anschaffen, wenn ich weiß, dass die Simulationen funktionieren. Ich versuche gerade, ein existierendes Design vom LPC767 (längst abgekündigt, außerdem OTP) auf einen passenden anderen Chip zu portieren und bin auf den AT89 gestoßen. Der Code des LPC767 funktioniert in uVision perfekt, die Simulationen zeigen genau das erwartete Verhalten. Unter anderem kommt es dabei auch zu Powerdowns und Aufwecken aus demselben. Genauso wie es sein soll. Passt übrigens locker in 2KB Code, deshalb reicht mir die Eval Version.
Die Simulation mit dem AT89 sahen erst vielversprechend aus, es stimmte nur etwas mit den Interrupt Abläufen nicht. Naja, und bei der Suche nach der konkreten Ursache bin ich auf das o.a. grundlegende Problem gestoßen.
ich hab das gerade ausprobiert das ist bei mir genauso, Es ist wohl so, dass wenn man im RUN Mode startet, der Simulator automatisch beim Powerdown anhält.
Dann kann man einen Reset auslösen.
Im Single Step zeigt PD keine Wirkung.
Frank: Unter dem von dir geposteten Text steht aber:
The following on-chip peripherals are simulated by the Keil Software µVision Debugger.
Clock Generation
Interrupts 6S/4L (Including External)
Port 0
Port 1
Port 2
Port 3
Power Saving Modes (Idle and Power Down)
Serial UART (Enhanced Interface)
Timer 0
Timer 1
Timer 2 (Standard Timer 2)
Nur diese Funktionen benötige ich. Ich benötige nicht die weiteren Zusatzfunktionen, die der Chip bietet.
Thomas: das kann ich nicht bestätigen.
Korrektes Verhalten:
Wenn ich RUN (F5) drücke, müsste er in den PD laufen und stehenbleiben bis ein Reset oder Interrupt kommt. In der Zeit sollte der RUN-Button disabled sein, ein Abbruch ist nur mit Stop möglich.
Dem ist aber leider nicht so. Es wird zwar angezeigt, dass der PD Modus aktiv ist, der Debug Stepper befindet sich aber nach Drücken auf RUN in der Zeile 7. Was eigentlich völlig unmöglich ist.
Such Dir einen passenden Chip mit Debug-Fähigkeit aus und ordere Dir ein
Eval-Board und entwickle damit. Dann hast Du die Probleme nicht mehr.<<
Genau das habe ich ja gemacht. Zuerst hatte ich mir einen Silabs EFM ausgesucht, Super-Features, aber sagt die Keil-Website, dass alle von mir benötigten Peripherals nicht unterstützt werden. Daraufhin habe ich weitergesucht und den AT89LP51 gefunden, bei dem steht:
"The following on-chip peripherals ->are<- simulated ..."
und nicht wie beim Silabs
"The following on-chip peripherals ->are not<- simulated ..."
So langsam habe ich die Vermutung, dass Keil das kleine Wörtchen "not" vergessen hat :-(
Such Dir einen passenden Chip mit Debug-Fähigkeit aus und ordere Dir ein
Eval-Board und entwickle damit. Dann hast Du die Probleme nicht mehr.<<
Genau das habe ich ja gemacht.
Nein, das hast Du nicht gemacht. Du versuchst immer noch, den Simulator zu verwenden. Vergiss den. Besorge Dir echte Hardware, auch wenn es nicht die Zielhardware ist, und einen USB-Debugadapter, und teste damit.
Denke auch daran, dass Keil seit mehr als einem Jahrzehnt zu ARM gehört. Die machen für nicht-ARM Prozessoren (8051, 80251,...) nicht mehr viel.
Du meinst Hardware-Debug-Möglichkeiten, ich rede von SW-Debug. Ich möchte in SW simulieren und habe meine Gründe dafür. Kann ich gerne darlegen, aber damit kommen wir vom Thema ab.
Ich glaube, ich komme der Ursache näher (was sicherlich mit der Aussage "machen nicht mehr viel mit 8051" zu tun hat):
Der ursprünglich Chip, den ich bisher in der Simulation verwende und bei dem alles bestens funktioniert, ist ein LPC767 von NXP, früher Philips. Uralt und soll ersetzt werden. Bei diesem Chip ist die Liste der unterstützten Peripherals wesentlich länger:
Simulated Features
The following on-chip peripherals are simulated by the Keil Software µVision Debugger.
A/D Converter
Analog Comparator
Brownout Detection
CPU Clock Output
I²C Interface
Interrupts 12S/4L (Including External)
Keyboard Interrupt
Oscillator Control
Port 0 (Quasi-bidirectional, Push-Pull, Input Only, Open Drain)
Port 1 (Quasi-bidirectional, Push-Pull, Input Only, Open Drain)
Port 2 (Quasi-bidirectional, Push-Pull, Input Only, Open Drain, 2-bits)
Power Saving Modes (Idle and Power Down)
Power-On Detection
Serial UART (Enhanced Interface)
Software Reset (SRST Bit)
System Configuration Byte UCFG1
Timer 0 (Standard Timer + Pin Toggle)
Timer 1 (Standard Timer + Pin Toggle)
Watchdog Timer
Ich vermute, es hat beim Atmel mindestens mit dem Fehlen von
Oscillator Control
zu tun. Das Ding bleibt einfach nicht stehen. Und damit scheidet es aus. Schade.
Da ich den Code inzwischen in C portiert und verifiziert habe, wäre ein Portierung auf ARM durchaus denkbar. Der bisherige Controller hat 10MIPS, 4KB ROM, 128Byte RAM, bis zu 16 I/O und PowerDown Möglichkeiten. Ein Cortex M0 sollte reichen, oder?
Welche Hersteller / Chips könnt ihr mir empfehlen:
Verfügbar in Kleinmengen zB bei Mouser oder Farnell, preiswert, für Protozwecke handlötbar, gute Unterstützung durch Keil UVision. Für Inbetriebnahme im Zielobjekt wird auch ein kleines Evalboard benötigt, das man auf einen DIL20 Sockel adaptieren könnte (da ist der jetzige LPC767 drin).
In der Hochzeit des 8051 gab es etwa 500 Typen von 50 Herstellern.
Für jedes Feature einen Simulator zu bauen, wäre ein Wettrennen zwischen Hase und Igel geworden.
Ich bin recht gut ohne Simulator oder Debugger klar gekommen. Die Datenblätter waren damals noch recht ausführlich und korrekt.
Wird mir tatsächlich nichts mehr anderes übrig bleiben, als mich nach einer neuen Architektur umzuschauen. ARM und die zugehörigen Tools habe ich mir die letzten Tage angesehen und versucht, etwas zum Laufen zu bringen, Ergebnis: das ist mir viel zu sehr mit Kanonen auf Spatzen geschossen. Bevor ich da eine Taste eingelesen oder LED angesteuert habe, muss erst ein RT Betriebssystem installiert werden (bewusst übertrieben). Ich habe nicht vor, IOT Devices mit Wifi / Bluetooth, Webserver und MQTT zu bauen, es geht nur um einfache Steuerungen. Könnte man auch mit einem kleinen FPGA machen, will ich aber nicht.
Momentan bin ich bei PIC/MPLAB gelandet, habe IDE V6.2 installiert und ausprobiert - das scheint zumindest halbwegs in die Richtung zu gehen wie ich es bei uVision mit alten Legacy 8051 gewohnt bin und was ich sehr vermissen werden, da die Simulation dort echt Klasse ist - wenn die ausgewählte Device unterstützt wird und funktioniert. Und die gibt es leider nicht mehr, ausgestorben.
Bevor ich tiefer ins PIC Universum einsteige: es gibt ja eine Unmenge an verfügbaren PICs. Welche Familie bzw Typ würdet ihr mir empfehlen? Ist 16F ok oder sollte ich auf 18F gehen? Gibt es etwas zu beachten, was in den Werbeprospekten nicht so steht?
Minimalkriterien:
18 5V tolerante I/O, 3 Interrupts, 4KB Code flashbar, 256 Byte RAM, 2 Timer, 8 bit ADC auf 4 Eingänge gemuxt, 1x I2C, sehr gute Simulationsunterstützung (!), gute langfristige Verfügbarkeit, gute Auswahl an Programmern / Eval Boards, In Circuit Debugging wäre nice to have.
nun ja du kannst für deine Simulation ja auch den LP767 weiterverwenden dort funktioniert die Simulation des PD korrekt. Später schaltest du dann auf den ATMEL um.
Braucht vielleicht ein paar #ifdefs und ein 2. Projekt um die CPU umzuschalten. So würde ich das jedenfalls machen wenn ich unbedingt simulieren will.
Minimalkriterien:
18 5V tolerante I/O, 3 Interrupts, 4KB Code flashbar, 256 Byte RAM, 2
Timer, 8 bit ADC auf 4 Eingänge gemuxt, 1x I2C, sehr gute
Simulationsunterstützung (!), gute langfristige Verfügbarkeit, gute
Auswahl an Programmern / Eval Boards, In Circuit Debugging wäre nice to
have.
Da gibts jede Menge PIC16, die Deine Anforderungen erfüllen. Je mehr Stellen hinter dem F in der Typenbezeichnung sind, desto neuer ist der Typ. Neuere Typen haben auch einen besseren CPU-Kern, der besser für C geeignet ist.
Debugger/Programmer: Du hast letztendlich die Wahl zwischen einem PICKIT3-China-Nachbau oder einem neuen PICKIT5. Das wars. PICKIT 3 und 4 gibts nicht mehr enu zu kaufen. Wenn da irdwendwer mit einem MPLAB Snap um die Ecke kommt - nein, der geht nicht, der hat keinen High Voltage Programmiermodus, den Du für diese Teile brauchst (zumindest das erste Mal).
Simulationsunterstützung: Das wird der große Haken sein, weil das aktuell niemand mehr benutzt. Hab ich ja schon öfters gesagt. Der Trend geht zu HIL - Hardware in the Loop, d.h. echte Hardware, Signale per Signalgenerator reinfüttern und messen, was am Ausgang rauskommt. Nur so bekommst Du das echte Systemverhalten.
Die Powerdown Simulation sehe ich überhaupt nicht als kritisch an. Das ganze Stromsparen baut man ja erst ganz zum Schluß ein, wenn die Hauptfunktionen alle korrekt laufen. Und dann kann man ja einfach den Verbrauch messen und feststellen, ob er jedesmal beim Interrupt wieder aufwacht oder sich tot stellt.
Fängt man sofort mit der Nebensache Stromsparen an, verzettelt man sich nur.
Thomas: genau das habe ich mir auch schon überlegt. Wenn meine Versuche nicht erfolgversprechend sein sollten, werde ich so vorgehen. Aber ich habe zum Glück reichlich Zeit (Rentner, ich mache das quasi als Nachbarschaftshilfe) und rein interessehalber will ich mal schauen, ob und was mit anderen Tools & Chips geht. Ist schon faszinierend, was alles inzwischen für ein paar Cent machbar ist. Mit Tools für Umme und alles mit einem Notebook.
Frank: danke für die Tipps zu PICs und PICKIT. Ich habe mir den 18F14Q41 ausgesucht. Was HIL angeht: kenne ich aus meinem Berufsleben sehr gut, ist aber eine deutliche Nummer zu groß für meine Applikation. SIL reicht mir.
Peter: stimmt, wenn es letztendlich nur der Powerdown / Idle ist, der nicht richtig simuliert wird, könnte ich damit leben. Mal schaun...
Ich werde aber noch ein wenig mit MPLAB spielen und dann wahrscheinlich den von Thomas vorgeschlagenen Weg gehen. Auf dem 767 kann ich die Funktionen testen, die beim Atmel nicht gehen, ansonsten benutze ich identischen Code auf beiden Plattformen mit ein paar #ifdef.
Derzeit kämpfe ich mit dem Stimulator in MPLAB. Entweder mache ich da grundsätzlich irgendwas falsch oder das Ding ist buggy wie sonstwas. Nach jeder kleinen Änderung im Code klappen primitivste asynchrone Stimuli nicht mehr, erst nach Schließen und Neustart der App geht es wieder. Außerdem werden die Stimuli nur übernommen, wenn die Simulation steht. Im Run Modus werden sie ignoriert. So wird das nichts. Aber noch habe ich nicht aufgegeben.
Soweit bin ich inzwischen: MPLAB-X kann die Watch/Variable Anzeigen nicht im RUN Modus aktualisieren, der virtuelle µC muss dazu stehen. Das ist schon ein heftiger Unterschied zu uVision. Dadurch wird das Debugging wesentlich unkomfortabler.
Aber wenigstens wirken die Stimuli im RUN Modus - das ist schon mal was.
Tendenz geht bei mir inzwischen doch wieder Richtung AT89C - die Nachteile bez. Simulation sind da deutlich geringer. Und der PIC läuft mir ja nicht weg.
