Strings mit Leerzeichen an Makros übergeben

[Bruder_M]

Moin,

ich schreibe grad ne serielle Kommunikationseinrichtung für meinen µc.
Wollte dabei mit Makros arbeiten, die mir dann quasi den Status des Controllers signalisieren. Wenn also ein bestimmter Programmteil erreicht worden ist, soll mir der Controller eine entsprechende Meldung am seriellen Port ausgeben. So viel zur Idee.
Also hab ich mir gedacht, entwerfe ich mir eine Art "PRINT-Routine". An die übergebe ich an gewünschter Stelle den String den ich ausgeben soll und die kümmert sich um Verarbeitung.
Arbeite z.Z. mit dem Metalink-Assembler der eigentlich bequeme Macros unterstützt, aber sobald ich in meinem Text ein Leerzeichen habe, wird nur das erste Wort an das Macro übergeben.
Weiß jemand Rat wie ich das möglichst einfach umgehen könnte?
Quelltext sieht in etwa so aus:



; macro definitions used in programm
SERPRINT MACRO string
; macro for putting out chars on the serial port
; only printable ASCII-chars should be used!

; ... routines handling communications

DB 'string'
DB 00h ; end of string
ENDM


mainprogram:
; ...

SERPRINT Hallo Welt




Ziel ist es also, dass er Assembler überall, wo er ein SERPRINT findet, das Macro einbindet, gefolgt von dem Text als Tabelle.

Beste Grüße, Marek

[Rudo]

...Wenn also ein bestimmter Programmteil erreicht worden ist, soll mir der Controller eine entsprechende Meldung am seriellen Port ausgeben. So viel zur Idee.dann wird das Programm doch irre langsam, vllt. sogar unbrauchbar:confused:
Ansonsten wuerde ich eine Zustandsvariable schaffen und die dann vllt. mit Zeitstempel archivieren. Das kannste ja dann mit e. 'cronjob' uebertragen.

[Bruder_M]

dann wird das Programm doch irre langsam, vllt. sogar unbrauchbar:confused:

No wieso? Ist doch nur Teil einer Kommunikationsroutine und soll zum Debuggen und Konfigurieren dienen. Den Parser muss ich natürlich auch noch dann schreiben.
Ich hatte mir das so gedacht, ich schicke mit nem Terminalprogramm einen vereinbarten String, z.B. "/CONFIG" an den, µC. Der erkennt das und wechselt in den Konfigurationsmous, worüber er mich wieder informiert mit z.B. "Entered CONFIG mode...". Dann kann ich mit weiteren Befehlen das Verhalten des Controllers manipulieren, Registern anschauen etc... Bei einem falschen Befehl sagt er mir dann z.B. "ERROR, wrong command". Also so in etwa wie man das von alten Modems (ja mal wieder *g*) kennt, dass man sich quasi im Klartext mit dem µC unterhalten kann.
RAM hab ich ja genug.

Beste Grüße, Marek

[Rudo]

ja o.k., kommt natuerlich immer drauf an, welche Art von Aufgaben der MC hat bzw. ob dieser immer Zeit fuer solche Senderoutinen hat, sobald sich irgendwelche Variablen aendern. Zum Testen kannste ja auch Breakpoints setzen und dann die interessierenden Stati via RS232 senden...wird ja wohl nicht gleich eine Walzensteuerung fuer ein Stahlwerk werden:D

[Winne]

variante 1

einen Platzhalter anstelle des Leerzeichens einsetzen und anschließend ausfiltern und wieder auffüllen.
Nachteil: kompliziertere Routinen

variante 2

token + parameter verwenden welche erst im anzeigemodul in klartext gewandelt wird

Vorteile: weniger zu übertagende Zeichen, leichtere Sprachanpassung der Mensch-Maschine-Schnittstelle

[Bruder_M]

Guten Abend,

ja das wären natürlich Möglichkeiten, da könnte ich ja gleich auf Hochsprachen umsteigen *g*
Aber mal im Ernst, das mit den Tokens werde ich aufgreifen, spätestens, wenn mir der ROM ausgeht, wenn das Prog zu 80 % aus Textstrings besteht. Ferner ist es dann einfacher, mit automatisierten Scripten zu arbeiten, die auf den µC zugreifen können. Bei ftp werden meines Wissens ja auch nur Zahlenbefehle übertragen und Modems kann man ja auch auf Numerik umschalten.

Ok, hab jetzt endlich meine Ausgabe zustande gekriegt, da die Makros so nicht wollten, musste ich halt ein Makro definieren ohne Parameter und den Textstring dahinter manuell einfügen, muss ich halt mit leben oder ich wechsle schon wieder den Assembler.
Natürlich gibt es viel zu tun, hab mir schon ca. 3 Stunden am Double Buffer die Zähne ausgebissen! Ferner habe ich bemerkt, dass das LPC935 getrennte Interruptvektoren hat für RI und TI, das vereinfacht dann natürlich die Sache, zwischen Sende- und Empfangsbetrieb umzuschalten und lässt sogar vollduplex zu. Natürlich muss ich die Routinen noch verriegeln, nicht dass mir höhere Interrupts die Register oder Pointer kaputt machen, aber ein Anfang ist schon mal getan.

So, muss dann mal drüber schlafen, wie ich den Parser für die empfangenen Daten gestalte.

Beste Grüße, Marek


; simple program for sending strings over serial port
; will use auto-Baud-generator
; will use ram
; has to be extended for receiving

; Controller: Philips P89LPC935
$MOD935

; default serial Baudrate 4800 @ default system clock
BAUD_4800 EQU 1520d ; @ 7,373 MHz

; defnitions of constants used in the program
ser_tx_buf EQU 00h

CR EQU 0Dh ; carriage return
LF EQU 0Ah ; Line feed


; definitions of bits used in program
ser_send_busy BIT 00h ; flag set if serial transmission already running

; macro definitions used in programm
SERPRINT MACRO
; macro for putting out chars on the serial port
; only printable ASCII-chars should be used!
CALL serprint_handler
ENDM

DPTR2ROM MACRO
; this macro activates the DPTR showing to ROM
; DPTR by default if BIT DPS==0
ANL AUXR1, #11111110b
ENDM

DPTR2RAM MACRO
; this macro activates the DPTR showing to RAM
; DPTR active if BIT DPS==1
ORL AUXR1, #00000001b
ENDM

; assembling starts here
org 0000h
JMP init ; neglect interruptvectors

; interupt vectors
org 0023h
SERINT:
; serial interrupt vector
CALL serint_handler
RETI


; initialisation of registers
org 0100h
init:
mov P0M1, #00h ;
mov P0M2, #00h ; Port 0 in quasibidirectional mode
mov P1M1, #00h ;
mov P1M2, #00h ; Port 1 in quasibidirectional mode
mov P2M1, #00h ;
mov P2M2, #00h ; Port 2 in quasibidirectional mode
mov P3M1, #00h ;
mov P3M2, #00h ; Port 3 in quasibidirectional mode
clr SM0 ; serial mode 1: 8 bit UART
setb SM1 ; serial mode 1: 8 bit UART
mov BRGR1, #HIGH(BAUD_4800) ; set baudrate generator
mov BRGR0, #LOW(BAUD_4800) ; set baudrate generator
;orl SSTAT, #11010000b ; enable double transmit buffer
orl BRGCON, #00000010b ; set bit SBRGS -> select baud rate generator source
orl BRGCON, #00000001b ; set bit BRGEN -> enable internal baud rate generator
setb ES ; enable serial interrupt
setb EA ; enable all interrupts

; clear all RAM
mov R0, #00h
clear_int_RAM:
mov @R0, #00h
djnz R0, clear_int_RAM




; now let the controller introduce itself through the serial port
; create therefore an "PRINT"-function,
; this will copy the passed string to the RAM and then it will be
; sent bytewise throught the port

SERPRINT
DB '************************************************* *********', 00
SERPRINT
DB '* * Hello World ! * *', 00
SERPRINT
DB '* * Firmware for Philips P89LPC935 Microcontroller * *', 00
SERPRINT
DB '* * Version: 0.00.04 Copyright 2006 by DB1BMN * *', 00
SERPRINT
DB '* * Watch out for more stuff to come ! * *', 00
SERPRINT
DB '************************************************* *********',00



jmp $ ; at least here to finish

; **************************************
; * *
; * SUBROUTINES *
; * *
; **************************************

serint_handler:
; this routine handles the serial interrupt

; IF BIT RI
JNB RI, ti_handler
; handler for receive interrupt

CLR RI
; END IF BIT RI

; IF BIT TI
ti_handler:
JNB TI, end_serint_handler
; handler for transmit interrupt
CLR TI ; mark interrupt as beeing proceesing
; IF BIT ser_send_busy
JNB ser_send_busy, end_if_bit_ser_send_busy
DPTR2RAM ; toggle DPTR to show on RAM
movx A, @DPTR ; fetch char from RAM to accu
cjne A, #00h, ser_send_no_null ; do not send the NULL but CR LF
mov SBUF, #CR ; send carriage return
jnb TI, $ ; wait until ready for next sending
clr TI
mov SBUF, #LF ; send line feed
jnb TI, $ ; wait until sent
clr TI
clr ser_send_busy ; no more data to transmit
jmp end_if_bit_ser_send_busy ; leave
ser_send_no_null:
mov SBUF, A ; copy from accu to serial send register
; after writing the first byte TI ist set immediatly!
; interrupt will come soon again
inc DPTR ; next ram place
; END IF BIT ser_send_busy
end_if_bit_ser_send_busy:
; nothing more to transmit
; END IF BIT TI
end_serint_handler:

RET

serprint_handler:
; this routine handles the serial output chars
; firstly check if an other serials transmission is running
; if so, stay waiting here to prevent corrupting data!
JB ser_send_busy, $
setb ser_send_busy ; prevent other calls corrupt this job!

; else copy the table from ROM to RAM
; while calling this function the PC was incremented by 3
; so the PC shows directly to the first byte of the table!
; the PC was then pushed to the stack with the L-Byte first then the H-Byte
; the SP shows to the H-Byte of the tables first adress
; copy this adress to DPTR to read out table
DPTR2ROM ; point to ROM
mov R0, SP ; R0 shows now also to the H-Byte
mov DPH, @R0 ; copy H-Byte to DPH
dec R0 ; R0 shows now to L-Byte
mov DPL, @R0 ; copy L-Byte to DPL
; DPTR contains now the tables first adress
; table must now be copied to external RAM!

; switch DPTR and initialize with RAM adress
DPTR2RAM
mov DPH, #00h
mov DPL, #ser_tx_buf
;toggle DPTR again, showing now to table adress in ROM
DPTR2ROM

; read out table
copy_tx_table_to_ram:
mov A, #00h ;initialize accu
movc A, @A+DPTR ; table value now in accu
inc DPTR ; next table place
DPTR2RAM ; toggle DPTR, now showing to RAM
movx @DPTR, A ; copy from accu to RAM
inc DPTR ; next RAM place
DPTR2ROM ; toggle DPTR, now showing to ROM
; do while table end not reached marked by NULL
cjne A, #00h, copy_tx_table_to_ram

; now the whole table is copied from ROM to RAM beginning at adress ser_tx_buf end marked by NULL
; before the chars can be transmitted the return from call must jump over the table
; so the return adress on stack must be manipulated!
; the R0 contains the adress of L-Byte
mov @R0, DPL ; copy L-Byte from DPTR to stack
inc R0
mov @R0, DPH ; copy H-Byte from DPTR to stack

; now the chars can be transmitted from RAM to the serial port
; therefore the ser_send_busy flag is set and the transmit interrupt is generated
; the serial transmit interrupt routine will do the rest, the programm can work on
; initialize DPTR to beginn of TX buffer before
DPTR2RAM
mov DPH, #00h
mov DPL, #ser_tx_buf
setb TI

RET


end


http://www.db1bmn.de/tmp/serprint.png

[guidob]

Ok, hab jetzt endlich meine Ausgabe zustande gekriegt, da die Makros so nicht wollten, musste ich halt ein Makro definieren ohne Parameter und den Textstring dahinter manuell einfügen, muss ich halt mit leben oder ich wechsle schon wieder den Assembler.


Hallo,

du mußt nicht den Assembler wechseln, sondern die Leerzeichen maskieren, sonst
interpretiert er den String als mehrere Parameter. Also " oder ' oder ' oder ` oder was
auch immer um den String rum.

guidob

[Bruder_M]

Hallo,

leider hat das nicht zum Erfolg geführt. Der Metalink Assembler nimmt entweder nur das erste Word bis zum Leerzeichen oder meckert "premature" End of string an.


TEST PAGE 1

1 PRINT MACRO string
2 DB string, 00h
3 ENDM
4
5
6 +1 PRINT 'HALLO'
0000 48414C4C 7 +1 DB 'HALLO', 00h
0004 4F00
9
10 +1 PRINT 'Hallo Welt'
0006 48616C6C 11 +1 DB 'Hallo, 00h
****-------------------------------^
****ERROR #33: Premature end of string
000A 6F2C2030
****-------------------------------^
****ERROR #33: Premature end of string
000E 3068
****-------------------------------^
****ERROR #33: Premature end of string
13
14
15 end

VERSION 1.2k ASSEMBLY COMPLETE, 1 ERRORS FOUND

ERROR SUMMARY:
Line #11, ERROR #33: Premature end of string
TEST PAGE 2




TEST PAGE 1

1 PRINT MACRO string
2 DB 'string', 00h
3 ENDM
4
5
6 +1 PRINT HALLO
0000 48414C4C 7 +1 DB 'HALLO', 00h
0004 4F00
9
10 +1 PRINT Hallo Welt
0006 48616C6C 11 +1 DB 'Hallo', 00h
000A 6F00
13
14
15 end

VERSION 1.2k ASSEMBLY COMPLETE, 0 ERRORS FOUND
TEST PAGE 2


Man kanns drehen wie man will, Hochkommata beim Aufruf prodzieren Fehler, Hochkommata in der Macro geben nur das erste Wort wieder.

Müsste mir mal bei Gelegenheit Plit´s ASEM-51 anschauen.

Beste Grüße, Marek

[guidob]

Naja,

die Fehlermeldung besagt:

ERROR #33: Premature end of string
An ASCII literal string was not terminated properly with an apostrophe.

Das bedeutet wohl falsches Hochkomma, meist ist es Shift+#.

Kann der ev. Strings verknüpfen? Dann kannst du auch was wie:

'Hallo'+' '+'Welt'

probieren.

guidob

[Bruder_M]

Guten Abend,

leider nicht, eine verwendung von Operanden ist zwischen zwei Datenfeldern nicht möglich. Das Hochkomma ist ja schon das richtige, denn das benutz ich ja sonst auch. Das Problem scheint einfach nur zu sein, dass der Assembler an Makros keine Leerzeichen übergibt weil wie gesagt nur ein Parameter erwartet wird.
Na ja was solls ist ja halt bisschen verwunderlich. Früher hatte ich gar keine Makros und bin auch irgendwie zurechtgekommen, aber man ist ja verwöhnt *g*

Beste Grüße, Marek

[Winne]

Sage mal bei makros werden doch bei der Übergabe jedesmal neue Kopien des Strings angelegt oder irre ich mich?

Wie wäre es du bastelst ein Array mit Textelementen und übergibst die Basis, das Offset sowie die Länge des darzustellenden Strings. So kannst du das Array als beliebig oft verwenden und die Zeiger beliebig manipulieren.
Trotzdem favorisiere ich die Tokenmethode

[Arne]

n'Abend,

beim lesen kam mir grade die Idee es mit %20 zu machen. Findet sich sonst auch überall wo Probleme mit Leerzeichen in einem String auftauchen. Vielleicht reicht das ja schon. ;)

Gruß,
Arne

[edgar]

Marek,

erinnere Dich daran,dass Du einen Mikrocontroller in der Hand hast,keine Textverarbeitungsmaschine bzw PC.
Bleibt bei diesem ueppigen Gebrauch von Speicher und Zeit ueberhaupt noch Platz fuer ein sinnvolles Programm ? Sind das nicht alles nur Turnuebungen?

Sorry , spiele ,experimentiere jetzt wo Du vor Begeisterung fast nicht mehr schlafen kannst,gelle :D

[Bruder_M]

Guten Abend,

aber natürlich, ich spiel doch so gern an kleinen Bits rum *löl*
Ne ist aber schon richtig, das eigentliche Programm war für nen 2051 gedacht, je nach Konfiguration tut es alle 30 Sekunden bis 30 Minuten für 2...3 Sekunden was, dann ist wieder Ruhe, da der 2051 aber viel externe Hardware benötigte (EEPROM, R2R-Wandler etc.) hab ich mir gedacht, das ein bisschen zu erweitern und auf nen P89LPC935 zu protieren, da hab ich genug ROM und RAM, EEPROM und ADC/DAC alles on-chip, was will man mehr, und die Konfiguration soll der User eben möglichst einfach per Kommandozeile in Klartext machen können.

Beste Grüße, Marek

P.S. ja, sind auch Turnübungen um die Eigenheiten des neuen Assemblers kennen zulernen, angefangen hatte ich ja so vor 5 Jahren mit dem Batronix ProgStudio, dann kam das Assemblerstudio hinzu und jetzt hab ich mir was eigenes gebaut aus METALINK Assembler im ConTEXT-Editor und FlashGet per Batchdatei...

[edgar]

Prima,

der Schritt vom 2051 zum 935 ist fast traumhaft :) so dass vor lauter Power die Phantasie in Schwung kommt.
Ein angenehmes ,berauschendes Gefuehl :D :D

Have Fun

[Winne]

Marek,

erinnere Dich daran,dass Du einen Mikrocontroller in der Hand hast,keine Textverarbeitungsmaschine bzw PC.
Bleibt bei diesem ueppigen Gebrauch von Speicher und Zeit ueberhaupt noch Platz fuer ein sinnvolles Programm ? Sind das nicht alles nur Turnuebungen?

Sorry , spiele ,experimentiere jetzt wo Du vor Begeisterung fast nicht mehr schlafen kannst,gelle :D

Also, wenn ich mal was einwerfen darf, die heutigen µC sind durchaus früheren Heimcomputern auf z80 der 6502 basis ebenbürtig, wenn nicht überlegen. Die meiste Perpherie haben sie on Chip. Und so gesehen ist es kein Verbrechen ihnen ein paar Gimicks aufzuhelfen.
Lediglich die geringe Zahl der Ports ist ein Flaschenhals für komlexere Aufgaben. Hier hätte ich schon mal gern einen "Tausendvierundzwanzigfüßler" (512 wären schon genug:D ). Aber da habe ich im 74hc373 wohl den richtigen Expander gefunden der aus 2*8 Ports 8*8 machen kann mit Dekodern sogar bis zu 256*8.

[Rudo]

@Bruder_M,
an Deiner Stelle wuerde ich mich nicht zu sehr in Assembler verbeissen, denn nur die wenigsten koennen sich das zeitlich/geldlich leisten bzw. bekommen diesen Luxus vom Chef genehmigt (Ed ist eine der Ausnahmen) ;):p

[edgar]

Er koennte ja den alten 8052 AH-Basic V1.1 benuetzen .

Der wurde damals speziell fuer StringVerwaltung usw gebaut.
Dieses Basic ,etwas erweitert,gibt es auf www.8052.com (http://www.8052.com/)
und kann in die Flashreichen 51 Chips gefuellt werden.
Rudo kennt mich,ich habe Zeit zu verkaufen :D und zu verschenken.

Assembler ist wie eine Impfung ...danach kann man an Hochsprachen nicht mehr erkranken.

[Rudo]

Hi Ed,
es kommt auch auf die Groesse des Projektes an, mit dem Basic wuerde ich mich nicht an grosse Projekte wagen.
Klar, zu Hause oder bei einer kleinen Anlage brauchste nichts mit 10.000 Zeilen oder mehr - aber auf ner Firma wird das oft anders aussehen.

[Arne]

Assembler ist wie eine Impfung ...danach kann man an Hochsprachen nicht mehr erkranken. Ed, schön gesagt und quasi volle Zustimmung! Um mit einer Hochsprache Ressourcen zu verschwenden, eigenet sich der PC einfach besser. :p

Gruß,
Arne

[edgar]

aber auf ner Firma wird das oft anders aussehen

ganz sicher !

die Jungs heute muessen mit Schwung und Wissen + Phantasie an das Werk wenn sie nicht von ihren chinesischen Kollegen gleich in 'Pension' geschickt werden wollen.

Solche Probleme habe ich nie :D
Ich assembliere nur wenn ich aus/mit Prestige spielen will und fuer gewisse Firmen fuer sie Unmoegliches zaubere:D

[Bruder_M]

Guten Abend,

so ich habe nun schon einen kleinen Teil meines "Betriebssystems" für den P89LPC935 geschrieben. Immerhin kann ich den Baustein dann schon so über die serielle Schnittstelle Resetten, das Echo ein- und ausschalten, mir die Versionsnummer der Firmware ausgeben lassen, eine Hilfe der unterstützten Befehle anzeigen und nicht zuletzt den ISP-Modus aufrufen.
Wer hätte gedacht, dass für solche trivielen Dinge schon gut 2 kB ROM draufgehen. Zugeben, die Textstrings fressen das meiste und das Programm hat ja noch etliche Redundanzen, trotzdem ist es interessant.

Beste Grüße, Marek

[Peter Dannegger]

Wer hätte gedacht, dass für solche trivielen Dinge schon gut 2 kB ROM draufgehen.

Naja zu Anfang läßt Du ja schon 140 Byte aus (org 100h).

Und wozu diese Macro PUSHBANK, ein simples "PUSH PSW" häts doch auch getan ?


Peter

[Bruder_M]

Guten Abend,

wenigstens mal einer, der sich den Quellcode angeschaut hat *g*
Ja ich habe die Interruptvectoren großzügig übersprungen, keine Ahnung wieso ausgerechnet 100h, hab das mal in irgendwelchen Büchern gesehen, dass da das Program immer erst bei dieser Adresse beginnt.
Und ja, viele dieser Makros sind mit Redundanzen behaftet, ich wollte erst mal einfach eine handhabbare Sytax einführen, die genau das tut, was der Macroname besagt, auch wenn es erst mal zu Lasten der Performance und des Speichers gilt, darum z.B. auch die ganzen Printmacros, auch wenn hier ordenlich RAM verschleudert wird, weil der String erst mal aus dem ROM in den RAM kopiert wird und dann nach und nach bei jedem TI-Interrupt ein Byte ausgesandt wird. Könnte ja auch direkt aus dem ROM schicken... Das ist mir schon alles bewusst und ich bin sicher, es kommen noch ein paar graue Hare dazu, wenn ich nachher irgenwo noch ein paar Bytes freies ROM gewinnen muss.
Das mit PUSHBANK und POPBANK hatte glaub ich den Sinn, dass ein Pushen des PSW ja auf den Stack erfolgt und somit auch der Stack-Pointer manipuliert wird, so kopiere ich mir nur die Konfiguration der Registerbank in den bitadressierbaren Bereich, leider mit einer Menge MOV-Befehle.
Viele der hier bald hinzuzukommenden Routinen haben auch eher Diagnosecharakter und sollen mich bei der Entdeckung und Beseitigung von Fehlern unterstützen und werden dann wohl zum Schluss ausgeschaltet. So plane ich z.B. in den Parser bestimmte Befehle einzubauen, mit denen es mir möglich sein soll ganz bestimmte Adressen des RAMs einzusehen und ggf. zu manipulieren. Die Anfänge sind mit /RESET und /BOOT ja schon mal gemacht.

Aber trotzdem, für konstruktive Kritik bin ich jederzeit Dankbar :-)

Beste Grüße, Marek

[Peter Dannegger]

Das mit PUSBANK und POPBANK hatte glaub ich den Sinn, dass ein Pushen des PSW ja auf den Stack erfolgt und somit auch der Stack-Pointer manipuliert wird

Genau dazu ist der Stack doch da.

Und das hat den Vorteil, wenn Du mal Interruptprioritäten benutzt, funktioniert es trotzdem.
Beim Schreiben an eine bestimmte Stelle überschreibt dagegen der höhere Interrupt und es kracht.


Peter

[Peter Dannegger]

Assembler ist wie eine Impfung ...danach kann man an Hochsprachen nicht mehr erkranken.

Kann ich überhaupt nicht zustimmen und ich hab 10 Jahre Assembler gemacht.

Wenn man erstmal C kann, macht man nichts anderes mehr.

Ich guck natürlich gerne mal in das Listing rein, ob der Compiler auch alles richtig macht.


Peter

[Rudo]

Wenn man erstmal C kann, macht man nichts anderes mehr.und wenn man davor noch PL/M konnte, macht man noch nicht mal mehr C :D

[edgar]

LOL


Wenn man erstmal C kann, macht man nichts anderes mehr.


und wenn man davor noch PL/M konnte, macht man noch nicht mal mehr C :D


Bedeutet das etwa ...ooops... fuer immer auf SEX verzichten ? :D

[Rudo]

Bedeutet das etwa ...ooops... fuer immer auf SEX verzichten ? :Dmoin Ed,
anfangs hatte ich mir vorgenommen, trotzdem nicht auf Ass.-Hexsex zu verzichten, hab ich aber nie gebraucht, is eben was fuern Ass:rolleyes:
- und mit C51 kannste dann sogar Gleitkommazahlen - tja, fuer dieses 'Gleithilfsmittel' fand ich auch nie Verwendung - siehe oben, dasgleiche in gruen...

[edgar]

Tag Rudo,

die Welt ist heil.
AdvKerze schon an?
Schoene Woche !

Gruss
Edgar

[Bruder_M]

Moin,

hab mal weitergebaut, hab jetzt nen kleinen RAM-Viewer geschrieben, um sich mal den Speicher angucken zu können.
To be continued...

Beste Grüße, Marek

[Peter Dannegger]

moin Ed,
anfangs hatte ich mir vorgenommen, trotzdem nicht auf Ass.-Hexsex zu verzichten, hab ich aber nie gebraucht, is eben was fuern Ass:rolleyes:
- und mit C51 kannste dann sogar Gleitkommazahlen - tja, fuer dieses 'Gleithilfsmittel' fand ich auch nie Verwendung - siehe oben, dasgleiche in gruen...

Du wirst lachen, bei kleineren Projekten hab ich float sogar auf nem AT89C2051 verwendet.

Heutzutage ist ja die Arbeitszeit der Hauptkostenfaktor und wenn float hilft Programmierzeit zu sparen, dann mußt Du es auch nehmen.


Peter

[Rudo]

Heutzutage ist ja die Arbeitszeit der Hauptkostenfaktor und wenn float hilft Programmierzeit zu sparen, dann mußt Du es auch nehmen.
Peterja, o.k., da geb ich dir recht, wenns schon da ist, haette ich es vielleicht auch benutzt oder zumindest mal versucht.
Fuer mich ist die Abkuendigung des Siemens 32bit-coprozessor im 517A ein grosser Verlust, es koennte also sein, dass ich irgendwann auch mal 'float' brauche:mad:

[Bruder_M]

Guten Abend,

diese Nacht war der ROM-Viewer dran, damit kann ich mir den Inhalt des Flash-ROMs ausgeben lassen. Anbei ein Screenshot
Interessant ist durchaus der Bereich von 1E00h bis 1FFFF, also die letzten 512 Bytes, wo sich der Herstellerseitige Bootloader befindet. Es steht euch frei, diese sequenzen zu disassemblieren :D


1DF0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1E00: 43 A2 08 D1 E5 53 91 FC 43 92 01 75 90 FF 75 89
1E10: 10 53 8F EF 75 87 80 E4 F5 8D F5 8B D1 EB 30 91
1E20: FB D1 EB 20 91 FB D2 8E 30 91 FD C2 8E D1 EB 85
1E30: 8D 34 79 34 E5 8B D7 C4 F4 04 F5 8B F5 8D 75 89
1E40: 20 D2 8E 75 98 52 D1 AB B4 55 FB 7D 00 D1 AB B4
1E50: 3A F9 D1 84 85 35 33 D1 84 85 35 31 D1 84 85 35
1E60: 30 D1 84 85 35 34 E5 33 FA 60 09 79 80 D1 84 A7
1E70: 35 09 DA F9 ED FC D1 84 EC B5 35 04 79 80 C1 CA
1E80: 74 58 E1 2B D1 AB D1 B5 C4 F5 35 D1 AB D1 B5 42
1E90: 35 ED C3 95 35 FD 22 D1 EB 30 99 FB C2 99 F5 99
1EA0: 22 D1 EB 30 98 FB C2 98 E5 99 22 D1 A1 D1 97 30
1EB0: E6 02 C2 E5 22 30 E6 02 24 09 54 0F 22 54 0F C3
1EC0: 94 0A 50 03 24 3A 22 24 41 22 E5 34 23 90 1E D1
1ED0: 73 E1 0B C1 F2 E1 90 E1 9B E1 AA E1 BA E1 B6 E1
1EE0: E7 C1 00 E1 2F 75 C1 FF 43 A7 E0 75 C2 A5 75 C3
1EF0: 5A 22 74 04 F1 DB 74 01 12 FF 03 EF F1 DB E1 29
1F00: C1 03 74 52 D1 97 EF F1 DB E1 78 AB 33 EB 60 19
1F10: AD 30 AC 31 7F 80 74 00 78 FF 76 96 C2 D1 75 E4
1F20: 08 86 E5 12 FF 03 20 D5 D9 74 2E D1 97 E1 78 78
1F30: 80 86 83 08 86 82 08 86 31 08 86 30 08 30 98 FD
1F40: C2 98 B6 00 10 F1 D2 7A 10 E5 83 F1 DB E5 82 F1
1F50: DB 74 3D D1 97 AC 83 AD 82 74 07 12 FF 03 EF B6
1F60: 00 04 F1 DB 80 03 B4 00 1D E5 31 B5 83 13 E5 30
1F70: B5 82 0E B6 01 02 E1 29 F1 D2 30 99 FD D2 9C C1
1F80: 4B A3 DA D1 E1 42 E5 83 F1 DB E5 82 F1 DB E1 78
1F90: E7 FF 09 E7 FD 74 02 E1 18 E1 02 E7 FF 74 03 12
1FA0: FF 03 20 D5 F4 EF F1 DB E1 29 E7 FF 09 E7 FC 09
1FB0: E7 FD 74 04 E1 18 74 06 E1 BE E7 FF 74 05 12 FF
1FC0: 03 20 D5 D5 EC F1 DB ED F1 DB EE F1 DB EF F1 DB
1FD0: E1 29 74 0D D1 97 74 0A D1 97 22 FC C4 D1 BD D1
1FE0: 97 EC D1 BD D1 97 22 74 2E D1 97 30 99 FD 75 BD
1FF0: 00 87 BF 09 87 BE 75 BD 03 C1 4B 00 00 00 00 00

Ein weiterer Teil befindet sich auch noch jenseits der FF00h, hab aber noch einen kleinen bug, der mir die letzten 256bytes nicht ausgibt, daher dauert es noch bis ich da rankomme.

Gute Nacht, Marek

[Rudo]

Jo, bist ja recht fleissig - weiter so!:):):)

[Peter Dannegger]

Fuer mich ist die Abkuendigung des Siemens 32bit-coprozessor im 517A ein grosser Verlust, es koennte also sein, dass ich irgendwann auch mal 'float' brauche:mad:

Das eine hat mit dem anderen doch nichts zu tun.

Float macht der C-Compiler und nicht der MC.
Selbst die 32Bitter ARM7 können kein float und noch nicht mal dividieren.

Ich hab noch nie nen 517 benutzt, weil der keinen Flash hat.

Ein Coproz macht nur da Sinn, wo extrem schnell gerechnet werden muß, aber daß ist bei typischen MC-Anwendungen so gut wie nie der Fall.


Peter

[Rudo]

... weil der keinen Flash hat. das hat was mit deutscher Ignoranz zu tun: Grosshersteller brauchen kein Flash, es gibt ja die Romversionen, fuers 'Fussvolk' sind die romlosen gut genug ;)

Ein Coproz macht nur da Sinn, wo extrem schnell gerechnet werden muß, aber daß ist bei typischen MC-Anwendungen so gut wie nie der Fall.PeterIrrtum, es verhaelt sich wahrscheinlich so aehnlich wie du oben im Zusammenhang mit dem C-Compiler und 'float' erwaehntest: wenn erst mal sowas da ist, dann wirds auch eingesetzt. Der Coproz ist super genial einfach zu handhaben: mit der Reihenfolge des Registerladens legt man die Rechenoperation fest (div, mult, norm), mit dem Laden des 'letzten Registers' startet man das Teil, 4µs warten - fertig, 32bit-Ergebnis steht im Register, kein extra Befehl ist notwendig, kein C oder sonstwas.

[Peter Dannegger]

das hat was mit deutscher Ignoranz zu tun: Grosshersteller brauchen kein Flash

Irrtum Deinerseits.

Wir stellen Geräte her, die an Kundenwünsche angepaßt werden müssen, bzw. Kunden wollen oft noch Funktionalität nachkaufen.

Daher gibt es für uns keine ROM-Lösung, es muß Flash sein.
Und es hat sich bestens bewährt.

Außerdem gehen auch Großhersteller massiv zu Flash über (KFZ, Handys, Waschmaschinen usw.).


Peter

[Peter Dannegger]

dIrrtum, es verhaelt sich wahrscheinlich so aehnlich wie du oben im Zusammenhang mit dem C-Compiler und 'float' erwaehntest: wenn erst mal sowas da ist, dann wirds auch eingesetzt.

Da ist aber ein gewaltiger Unterschied.
Float gibt mir der Compiler, egal welche CPU.

Der Coproz gibt mir dagenen überhaupt nichts neues, er macht manches nur ein kleines bischen schneller.

Aber bisher war immer der Mensch mit seiner geringen Ablesegeschwindigkeit weitaus langsamer, als die CPU.

Und wenns doch mal schneller sein muß, nehme ich lieber gleich nen 1-Clocker (Silabs, Atmel) und sämtliche Operationen sind schneller.


Ich finde die Entscheidung daher richtig, wenn man nicht investieren will, um den 517 als Flash zu bauen, kann man in gleich ganz einstampfen.


Peter

[Rudo]

Irrtum Deinerseits.wusstest du, dass Siemens in seiner Verzweiflung (als man einsah, dass die Ignoranz der Entwicklung von Flashspeicher ein grosser Fehler war) versucht hat, Atmel feindlich zu uebernehmen?


Außerdem gehen auch Großhersteller massiv zu Flash über (KFZ, Handys, Waschmaschinen usw.).

Peterdas haette schon vor langer Zeit so sein koennen...

[Winne]

wusstest du, dass Siemens in seiner Verzweiflung (als man einsah, dass die Ignoranz der Entwicklung von Flashspeicher ein grosser Fehler war) versucht hat, Atmel feindlich zu uebernehmen?
das haette schon vor langer Zeit so sein koennen...

Ein Unterfangen, welches hoffentlich nie glücken wird und ein Lichstreif, dass der Monopolist durch sein Zerbrchen endlich Platz für Neues machen könnte.
Achja seine Traditonen hat der Konzern schon lange selbst erstickt, weshalb es auch nicht schade um ihn ist.

[Bruder_M]

So, bitteschön,

hier die "geheimen" IAP-Routinen des P89LPC935, "versteckt" ab Adresse FF00h:


FF00: 75 A2 08 90 FF 08 23 73 E1 4C E1 9E E1 21 E1 18
FF10: E1 37 E1 84 E1 8B E1 44 8F E6 75 E4 6C AF E5 E1
FF20: A3 F1 B1 BF 10 08 75 E4 67 75 E5 96 80 73 8F E6
FF30: 75 E4 6C 8D E5 80 6A F1 B1 8C E7 8D E6 EF 24 70
FF40: F5 E4 80 5D 8C 83 8D 82 E4 93 FF 22 F1 B1 EB FE
FF50: 8C E7 8D E6 75 E4 00 8F F0 A8 F0 20 D1 03 E6 80
FF60: 01 E2 F5 E5 08 DB F4 75 E4 48 F1 A1 40 15 8C 83
FF70: 8D 82 A8 F0 F1 48 66 70 07 A3 08 DE F7 7F 00 22
FF80: D3 7F 08 22 8F E7 75 E4 19 80 03 75 E4 1A AF E5
FF90: 05 E6 AE E5 05 E6 AD E5 05 E6 AC E5 80 05 7F 04
FFA0: 22 AF E4 E5 E4 75 E4 0B 54 0F 70 02 C3 22 FF D3
FFB0: 22 78 FF E6 B4 96 03 76 00 22 E1 00 00 00 00 00
FFC0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
FFD0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
FFE0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
FFF0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Erstaunlicherweise sind auch Lesezugriffe auf den Bereich von 2000h bis FF00h und zwar nicht periodisch, d.h. die Sequenzen wiederholen sich NICHT, wie das bei RAM-Zugriffen jenseits der 0200 h der Fall ist. Es scheint hier also physikalisch tatsächlich noch ein ROM jenseits der 8 kB-Grenze zu liegen, wäre mal interessant, ob man auch Schreibzugriffe drauf ausführen kann...

Beste Grüße, Marek

[Rudo]

Marek,
das kann vielleicht mal interessant werden, mein Emulator rueckt beispielsweise solche Infos erst gar nicht raus (macht nur 0-2000h, waer ja eh nur vom Bondout-Chip).
Ich vermute aber, dass vielleicht noch 'on chip debugging' kommen wird, und dann wird sich da noch einiges mehr im freien Adressbereich abspielen;)

[Bruder_M]

Hi Rudo,

also ich hab mal die ganzen 64 k ausgelesen, über der 2000h ist nichts, nur Nullen, da kommt erst ab FF00h wieder was. Kann ja sein, dass die ja noch ne geheime Page eingebaut haben, die dann über ein noch geheimeres Register aufgeblättert wird, wer weiß. Jedenfalls will ich mal ausprobieren ob ich den Bereich von 2000h bis FEFFh beschreiben kann, was für ein Glück, dass der µC sich auch selbst programmieren kann.

Beste Grüße, Marek

[Peter Dannegger]

Bei den ersten T89C51RD2 von Atmel konnte man auch ganz einfach den Bootloader überbraten.

Das haben aber wohl einige gemacht und waren dann sauer, daß nichts mehr geht ohne Programmiergerät.

Daher hat Atmel bei den Nachfolgern AT89C51RD2 usw. den Bootloader in einen extra Flash gelegt, der nur über nen Parallelprogrammer bei 12V änderbar ist.


Peter