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:
https://www.keil.com/dd/vtr/6135/12676.htmhttps://www.keil.com/dd/chip/6263.htm
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.
https://www.keil.com/dd/chip/6263.htm:
"Complete peripheral simulation is not available and is not planned to
be implemented by ARM."
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.
fchk
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.
Frank:
>>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 :-(
Kalle W. schrieb:> Frank:>>>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.
fchk
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.
Kalle W. schrieb:> 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.
fchk
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.
Thread beobachten
Seitenaufteilung abschalten