-         

Seite 1 von 3 123 LetzteLetzte
Ergebnis 1 bis 10 von 26

Thema: Problem mit Bascom Lib und Assembler

  1. #1
    Erfahrener Benutzer Begeisterter Techniker Avatar von albundy
    Registriert seit
    16.10.2004
    Beiträge
    282

    Problem mit Bascom Lib und Assembler

    Anzeige

    Hallo,
    ich bin dabei eine Lib für Bascom zu schreiben. Dabei habe ich sicher ein Problem mit dem Pointer ?!

    Das Bascom Programm
    Code:
    $regfile = "m8535.dat"
    $crystal = 8000000
    $lib "Test.lib"
    $external Grtxt
    
    Config Porta = Output
    Porta = $ff
    
    Declare Sub Grtxt
    
    Call Grtxt
    
    Do
    Loop
    Und die Test.Lib dazu
    Code:
    [grtxt]
    Grtxt:
      ldi zh,High(Daten)
      ldi zl,Low(Daten)
      ld r22,z
    * out Porta,r22
      ret
    ;
    Daten: 					
    .db &H14,&H7F,&H14,&H7F,&H14,&H00				
    [end]
    Alles noch sehr übersichtlich und trotzdem irgendwo fehlerhaft ?
    R22 bzw. der Porta zeigen $17 anstatt $14 ?
    Wenn ich in der Lib "ld r22,z+1" schreibe, ist R22 / Porta = 0 ?
    Kann mir das jemand erklären ?

    Wie ist das eigendlich mit Push und Pop ? Muß ich vor dem Aufruf der Lib, irgendwelche Register sichern ?

  2. #2
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    20.06.2004
    Beiträge
    1.941
    weist du, wenn so umständlich die lib geschrieben wird ist es doch besser du machst asm in einer sub oder funktion. diese lib in Bascom dauern in der ausführung immer länger als wenn man den code in asm einbinden tut.
    diese lib sind der grösste unfug in Bascom seit menschgedenken. ich hatte damals die lib die ich brauchte direkt in asm-routinen in einer sub oder funktion eingepackt. war übersichtlich und erfolgreich.
    mfg pebisoft
    ps: schau dir von Bascom mal eine grössere lib an, dann kriegst du das schaudern und denkst, was wollen die eigentlich da machen.

  3. #3
    Erfahrener Benutzer Begeisterter Techniker Avatar von albundy
    Registriert seit
    16.10.2004
    Beiträge
    282
    Hallo,

    weist du, wenn so umständlich die lib geschrieben wird ist es doch besser du machst asm in einer sub oder funktion. diese lib in Bascom dauern in der ausführung immer länger als wenn man den code in asm einbinden tut.
    das war eigendlich nicht meine Frage.
    Wenn es eine andere Möglichkeit gäbe, um mehrere Subroutinen mit Parameterübergabe extern auszulagern, würde ich mich auch nicht mit einer Library rumquälen.

    Ich habe inzwischen herausgefunden, dass die Datenbytes in meiner Lib gar nicht mit Assembliert werden ?

  4. #4
    Super-Moderator Robotik Visionär Avatar von PicNick
    Registriert seit
    23.11.2004
    Ort
    Wien
    Beiträge
    6.836
    Bei Push/Pop kann ich dir helfen: Für Bascom solltest du YH,YL, R4, R5 und R6 sichern. Aber nur dann, wenn du sie auch veränderst.
    Das andere müßt ich mir erst anschauen/nachlesen.
    mfg robert
    Wer glaubt zu wissen, muß wissen, er glaubt.

  5. #5
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    22.11.2003
    Beiträge
    991
    Moin,

    probier mal:
    Code:
    [grtxt]
    Grtxt:
      ldi zh,High(2*Daten)
      ldi zl,Low(2*Daten)
      lpm r22,z 
    * out Porta,r22
      ret
    ;
    Daten:                
    .db &H14,&H7F,&H14,&H7F,&H14,&H00            
    [end]
    In Assembler muss man so immer zwischen Word und Byteadressen umrechnen. Kann gut sein, dass es in Bascom genauso ist.

    Außerdem sollte es doch ein "lpm" anstatt des "lp" sein, oder ?? Immerhin liest du die Daten aus dem Flashspeicher und nicht aus dem RAM.

    MfG Kjion

  6. #6
    Erfahrener Benutzer Begeisterter Techniker Avatar von albundy
    Registriert seit
    16.10.2004
    Beiträge
    282
    Hallo Kjion,

    In Assembler muss man so immer zwischen Word und Byteadressen umrechnen. Kann gut sein, dass es in Bascom genauso ist.
    du hast natürlich Recht, das habe ich jetzt geändert.

    Außerdem sollte es doch ein "lpm" anstatt des "lp" sein, oder ??
    ich lese jetzt mit LPM. Aber das gelesene Byte steht doch dann automatisch in R0 ?!
    Also habe ich auch das geändert auf "out Porta , R0".
    Leider funktioniert es trotzdem nicht. Das gelesene Byte ist "0" ???

  7. #7
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    20.06.2004
    Beiträge
    1.941
    es gibt eine viel einfachere lösung um solche dateien fexibel auszulagern und einzubinden du schlaumeier. na denn mach mal weiter...
    mfg pebisoft

  8. #8
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    22.11.2003
    Beiträge
    991
    Zitat Zitat von albundy
    ich lese jetzt mit LPM. Aber das gelesene Byte steht doch dann automatisch in R0 ?!
    Nein.
    Code:
    lpm r16, Z
    Würde den den Inhalt der Speicherzelle auf die der Z Pointer zeigt ins Register r16 laden.

    MfG Kjion

  9. #9
    Erfahrener Benutzer Begeisterter Techniker Avatar von albundy
    Registriert seit
    16.10.2004
    Beiträge
    282
    Hallo,
    es gibt eine viel einfachere lösung um solche dateien fexibel auszulagern und einzubinden du schlaumeier. na denn mach mal weiter...
    mfg pebisoft
    das ist deine Meinung !
    Ich erinnere mich noch an das Thema Videoausgabe ...
    Ich habe es damals in den Griff bekommen und du ?
    Und wenn man nicht weiterkommt, wechselt man einfach die Programmiersprache, oder ?

    Ich jedenfalls werde auch die Library mit Assembler in den Griff bekommen !!!

    PS: Das nächste Mal bitte "Sie Schlaumeier", soviel Zeit muß sein

  10. #10
    Erfahrener Benutzer Begeisterter Techniker Avatar von albundy
    Registriert seit
    16.10.2004
    Beiträge
    282
    Hallo Kjion,

    lpm r16, Z
    Auch das habe ich gerade ausprobiert. Das Ergebnis ist ebenfalls "0".
    Kann es sein, das die Daten nicht automatisch eingebunden werden, sondern erst irgendwie initialisiert werden müssen ?
    Im Assemblerlisting (AVR Studio) wird der Platz für die Daten zwar freigehalten, es sind aber alle "0" ?

Seite 1 von 3 123 LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •