Hi,
Ich habe da eine Problem mit der 8051 Variante DS89C450 von Maxim.
Programmieren über RS232 funktioniert. Ich habe nun eine LED an P0.4
angschlossen und ein kleines blinkprogramm geschrieben, ganz einfach nur
mit for schleifen als verzögerung.
Solange alles in main drinnen steht funktioniert es aber sobald ich
versuche die for schleife in eine delay-Funktion auszulagern geht nichts
mehr und auf auf der auf Port P0.4 angeschlossenen LED ist nur ganz
leichtes glimmen zu sehen. Habe mir das mit dem Ozi angeschaut und da
sind ganz komische RC-mässige Funktionen zu sehen mit ca 4V und 200kHz.
Weis nicht woran es liegen kann, dachte zuerst an einen externen
adresszugriff aber EA ist auf High gezogen und das erklärt auch nicht
die komischen Analogsignale auf dem Port 0
Hoffe es kann mir wer tipps geben.
mfg Jonny
Ähm, ist der Stack-Pointer vernünftig gesetzt? Wenn er das nicht ist, so
kannst Du nichts auf den Stack legen und somit nicht aus Unterprogrammen
zurückkommen. (Entschuldigung falls Dir das schon klar ist, aber oft
sind es gerade die ganz einfachen Dinge die fehlschlagen)
Hi,
Also Stack is glaub ich nicht dran schuld, hab den Startupcode
eingebunden.
Ich programier das Ding übrigends in C mit Keil uVision.
Kann mir keinen Reim auf die komischen analogspannungen machen, die
Versorgung ist vollkommen sauber.
mfg Jonny
Hi,
Hab mir auch schon überlegt das die schleifen wegrationalisiert werden
aber das erklärt nicht das komische ausgangssignal am Port, selbst wenn
ich mit maximaler geschindigkeit toggle hab ich ein sauberes
rechtecksignal von ca. 1MHz.
Aber sobald ich das toggeln in ein unterprogramm lege hab ich ein einige
undefineirte RC-Ladefunktionen periodisch mit ca 200kHz 4V
Hab mir schon alles angeschaut, Versorgung sauber, Quarz schwingt wie er
soll, EA pulldown...
Ich weis einfach nicht mehr weiter :(
lg Jonny
Hi,
Die LED ist über einen Vorwiderstand an +5V geschaltet, auch wenn ich
die LED weggeb und nur einen pullup draufhäng ist das selbe zu sehen.
Das komische ist ja das das blinken funktioniert wenns nur toggeln im
main ist. Sobald was aufwenigeres gemacht wird (unterprogramme, if
abfagen...) geht nichts mehr und diese analogsignale treten auf.
mfg Jonny
Hi Jonny,
muss doch mal einen loader für den ds89 in meinem MacroAssembler
reinschreiben, dann werde ich das mal testen.
Bin aber mehr Assembler-Freak, eventuell auch sdcc.
Was passiert, wenn man z.B. P2.4 toggelt?
mfg
Pieter
Hi,
Habs jetzt auch mit Port 1 und 2 auspropiert, das gleiche Problem, nur
die analogspannung schaut etwas anders aus. Weil ich dachte der uC ist
hinüber hab ich auch noch einen DS89C420 ausprobiert, das gleiche
Problem. Also müsste es wohl an der Software liegen, aber welcher
Prorammierfehler kann eine Analogspannung an einem Digitalport
verursachen...?
lg Jonny
Die Projekteinstellungen von µVision sollten überprüft werden:
*Prozessortyp?
*Speichermodell?
*zum Speichermodell passender Rambereich und Startadresse?
*zum Speichermodell passender Programmbereich und Startadresse?
Wenn diese Einstellungen nicht im Widerspruch zueinander stehen, und
innerhalb des Programms keine weitere(n) Modifikation(en) der
Variablenspeicherklasse(n) stattfindet, sollte es eigentlich
funktionieren.
mfg
Hallo Jonny,
mach 's doch nicht so spannend. Wenn 's mit µV v. Kei* gemacht wurde,
dann pack das ganze Projekt mal ein und poste es hier in den beiden
Varianten.
Es lassen sich Code u. Einstellungen einfachst prüfen.
tschü Dude
PS:
Die Startup-Datei muss ggf. ans eigene Projekt angepasst werden.
(Aber das weisst Du sicherlich, manchmal sieht man den Wald ...)
Hi Jonny,
sorry, hat etwas länger gedauert, muste erst noch eine Kiste voll
Kohlrouladen "bauen"...
Softwareloader läuft und dann dieses kleine Prog laufen lassen:
;-------------------
Model DS89C450.MCU
Loop: Call Blick
JMP Loop
Blick: CPL P0.4
CLR A
DJNZ ACC, $
RET
END
;-------------------
P0.4 geht auf 2K3, der auf Kathode LED und Anode auf 5P. Das Signal an
P0.4 ist ein Rechteck, nix mit analog.
Was nun?
mfg
Pieter
Hi,
Tut mir leid das ich mich so lange nicht gemeldet hab, hatt viel zu tun.
Im Keil Simulator funktionierts mit und ohne Unterprogramm, die Ports 0
und 2 blinken abwechselnd.
Hab jetzt die beiden Projekte raufgeladen;
Projekt ist das Blinken was funktioniert, direkt mit Schleifen
ProjektmPU ist das gleiche aber die Werteschleifen in Unterprogramme
gelegt.
Wave.jpg ist das was am Port P0.4 wo die LED dranhängt bei ProjektmPU
rauskommt.
Hoffe es kann mir jetzt jemand weiterhelfen, bin schon leicht am
verzweifeln, habe vor Jahren schonmal mit dem Teil gearbeitet da hat
alles perfekt funktioniert.
mfg Jonny
Hi,
Danke für den Hinweis, habs geändert, aber funktioniert tus leide rimmer
noch nicht. Die Analogspannung sieht nur leicht anders aus (etwas
Sägezahnmässiger)
mfg Jonny
Servus,
wie hast du denn die LED angeschlossen? Port P0 hat hat keine internen
Pullups, und kann auch nicht nach High treiben.
Ich vermute mal, so hat so verdrahtet:
Plus - Widerstand - LED - Portpin
Setzt Du nun P0.4 auf 1 so wird er hochohmig, und deine LED wirkt quasi
als Pullup und zieht den Pin nach VCC. Das erklaert das Oszibild.
Bei P0.4=0 sollte allerdings die LED dann laeuchten.
Gruss,
rweber
Hallo Jonny,
das ist ja wirklich ein interessantes Phänomen ;))
Hast Du externes RAM bei Deiner HW? Wahrscheinlich nicht, sonst könntest
Du ja keine LED an P0 hängen.
Schau Dir mal die beiden "main.lst" Dateien an. Bei der Varinate mit dem
UP-Aufruf wird XDATA verwendet. Erzeuge mal Assemblercode (z. B.
"#pragma CODE" am Anfang des Quelltextes), da dürften dann "movx"
Befehle enthalten sein. Also wird extern adressiert und P0, P2 werden
durch den µC selbst verwendet!
Ändere das Speichermodell für RAM auf "SMALL" und lege damit die (alle)
Variablen auch bei der Version mit den UP-Aufruf ins interne RAM.
Dann alles wir gut :)))
tschü Dude
12er Dude wrote:
> Ändere das Speichermodell für RAM auf "SMALL" und lege damit die (alle)> Variablen auch bei der Version mit den UP-Aufruf ins interne RAM.
Ja, steht im Listing, er verwendet LARGE, was für ein Unsinn.
Die Keil-Entwickler haben sich schon was dabei gedacht, daß sie als
Default SMALL eingestellt haben.
LARGE ist nur in Ausnahmenfällen zu empfehlen, wenn man die Vor- und
Nachteile weiß.
In der Regel ist man mit den Memory-Spezifier idata, pdata, xdata
deutlich effizienter als mit der Brechstange LARGE (alles xdata).
Peter
@Peter
Die Sinnfälligkeit möchte ich gar nicht duskutieren. Geschwindigkeit und
Optimierung sind ein anderes Thema. Hier soll das Ding erstmal laufen.
Aber wo liegt "xdata"? Der gute Jonny hat Speicher adressiert, der
physikalisch nicht vorhanden ist.
=> Die Speichereinstellung muss zur HW passen!
Was auch immer als default angegeben wird, ist egal. Man sollte es eh an
die eigene Umgebung (HW) anpassen.
tschü Dude
12er Dude wrote:
> Aber wo liegt "xdata"? Der gute Jonny hat Speicher adressiert, der> physikalisch nicht vorhanden ist.
Nö.
Der DS89C450 hat 1kB xdata, bloß ist das wohl nicht richtig
konfiguriert.
Bei meinem alten C51 mußte man dazu im startup.a51 einige Änderungen
vornehmen.
> Was auch immer als default angegeben wird, ist egal. Man sollte es eh an> die eigene Umgebung (HW) anpassen.
Wenn man aber nicht weiß, was man tut, sollte man es auf default lassen.
Viele lassen sich einfach nur durch das Wort blenden, SMALL klingt
mickrig, LARGE klingt besser.
Bloß LARGE bedeutet eben auch automatisch LANGSAM.
Peter
@Peter
Sorry, da hast Du natürlich recht! Habe mir den µC nicht genau
angesehen. Das Scope-Bild passte so schön zu der Vermutung.
Es wird so sein, wie Du es beschreibst: unzureichende Konfiguration.
Warten wir mal auf Jonny ...
tschü Dude
Hi,
Danke für das rege Interesse an meinem Problem.
Ich habe das Model nur auf large gestellt weil es von Maxim so empfohlen
wird. (http://www.maxim-ic.com/appnotes.cfm/an_pk/3267)
Werde es wenn ich heimkomme gleichmal mit small versuchen.
Bezüglich der Adressen bin ich mir nicht sicher was ich da einstellen
muss, hab einfach die werte der oben erwähnten application note
verwendet.
mfg Jonny
Hi,
Vielen, vielen Dank an Peter und Dude !
Mit Small als Memorymodell funktionierts, mit Compact und Large nicht.
Wäre da wohl nicht so schnell draufgekommen weil in den Application Note
von Maxim steht ja man solls auf large stellen.
Weis eventuell noch jemand woran das liegen könnte? Würden den XData
gern benutzen wenn ich den schon draufhab.
mfg Jonny
Hi,
> Wäre da wohl nicht so schnell draufgekommen weil in den Application Note> von Maxim steht ja man solls auf large stellen.
Da steht aber nicht nur drin, dass man es auf LARGE stellen soll,
sondern auch wann, du hast es nicht richtig gelesen:
Memory Model — Set to Large: Variables in XDATA. This tells the compiler
to locate variables in external MOVX RAM. This is appropriate when
using a hardware setup, such as the High-Speed Microcontroller
Evaluation Kit, which provides external data memory for the
DS89C430/440/450.
Du hast nirgends erwähnt, ob du ein DevKit oder ne eigene Hardware
verwendest, die einen externen RAM-Speicher verwendet.
> Würde den XData gern benutzen wenn ich den schon draufhab.
Das geht auch, wenn du auf SMALL stehst. Die Speichermodelle sagen dem
Compiler nur, wo er Variablen standardmäßig ablegen soll, wenn nicht
extra spezifiziert wird, wo sie abgelegt werden sollen.
Guckst du da:
http://www.keil.com/support/man/docs/c51/c51_le_memmodels.htmhttp://www.keil.com/support/man/docs/c51/c51_le_memtypes.htm
Du kannst sowohl für einzelne Variablen als auch komplette Code-Module
sagen, dass sie sich in einem anderen Speicher befinden. Das bietet sich
z.B. an, wenn du große Buffer hast, die legst du dann in den externen
Speicher. Oder Interrupt Variablen werden meistens im internen Speicher
gehalten, damit der Zugriff schnell gemacht werden kann, denn ein
Zugriff auf externen Speicher dauert länger als bei einem internen
Zugriff.
Ich lasse das Modell immer auf SMALL, und passe für spezielle Fälle
entweder die Variablen bzw. Module an.
Ralf
PS: Weiss jemand, wo aufgeführt ist, wie man Forumstexte formatiert?
