Hello, Guest the thread was viewed2.9k times and contains 19 replies

last post from syshack at the

i2c Schnittstelle Byteweise befehl übertragen

  • Hallo zusammen


    Wäre schön wenn mir einer weiterhelfen könnte


    Ich baue eine i2c schnittstelle am c64-userport


    Der Aufbau


    c64-ttwandler-i2cModul


    Testweise sende ich jetzt Text vom pc zu c64 und in die andere Richtung


    Das i2c modul funktioniert am pc mit der dafür vorgesehenen Software. Nicht aber mit einem anderen Terminalprogramm. Angeschlossen am pc über comport.


    Mit dem c64 empfange ich keine Antwort vom i2c Modul.


    Das i2c Modul habe ich auf die Bautrate des c64 eingestellt auch alle anderen Einstellungen müssten in Ordnung sein.


    Da ich mit diesen Einstellung Daten mit dem PC austauschen kann und das i2c modul am PC ebenfalls funktioniert wird der fehler wohl in der Übermittlung der Befehle liegen und oder im einlesen der antworten.


    Wie kann ich mit dem c64 folgendes machen..



    sendbyte 18 #befehl
    sendbyte(0) #frame
    sendbyte(4) # ende


    read byte 1
    read byte 2


    für eure Hilfe wäre ich echt dankbar


  • Hallo,


    leider war bei deinem Text keine URL dabei, so dass ich nicht weiß, mit welchen Geräten du arbeitest. ?( Dass I2C ein Master-Slave-Bus ist (d.h. im Fall, dass beide von dir verwendeten Geräte eigentlich Master sind, nun eines als Slave agieren muss) ist dir klar? Außerdem gibt es bei I2C keine Baudrate, höchstens eine maximale Baudrate, die von der verwendeten Hardware und der Art der Programmierung abhängt. Wegen des bei I2C verwendeten Handshakes sollte das aber kein Problem sein, außer die Software ist nicht systemkonform programmiert.


    Ciao, Michael

  • Hallo,


    leider war bei deinem Text keine URL dabei, so dass ich nicht weiß, mit welchen Geräten du arbeitest. ?( Dass I2C ein Master-Slave-Bus ist (d.h. im Fall, dass beide von dir verwendeten Geräte eigentlich Master sind, nun eines als Slave agieren muss) ist dir klar? Außerdem gibt es bei I2C keine Baudrate, höchstens eine maximale Baudrate, die von der verwendeten Hardware und der Art der Programmierung abhängt. Wegen des bei I2C verwendeten Handshakes sollte das aber kein Problem sein, außer die Software ist nicht systemkonform programmiert.


    Ciao, Michael

    Hallo Michael


    hier der link zum modem und dieses modem häng an einem TTL wandler.
    ich kann dem ding aber keine befehle übermitteln.
    der wandler funktioniert in der verbindung c64 zum pc
    und das modem am pc
    überall die gleichen einstellungen
    also funktioniert das modem auch am c64
    nur weiß ich nicht, wie ich die befehle übermittel und die antworten lese
    über
    open 2,2,0, chr$(6)+chr$(0)
    print# 2, befehl
    get# 2, A$. print A$;: goto get


    geht es nicht, so kann ich mich nur mit dem pc unterhalten
    http://www.horter.de/shop/inde…fuer_din_schiene4686.html


    gruß
    ingo

  • wenn das ding wirklich an der rs232 am userport hängt, würde ich empfehlen zu testzwecken irgendein terminal programm zu benutzen (CCGMS, handyterm, novaterm...)


    ansonsten erinner ich mich dunkel das man die signalleitungen am userport invertieren muss um richtiges rs232 zu bekommen

  • wenn das ding wirklich an der rs232 am userport hängt, würde ich empfehlen zu testzwecken irgendein terminal programm zu benutzen (CCGMS, handyterm, novaterm...)


    ansonsten erinner ich mich dunkel das man die signalleitungen am userport invertieren muss um richtiges rs232 zu bekommen


    Das Modem kann ich am pc nur über die dazugehörigen Terminalprogramme ansprechen. Mit einem Terminalprogramm term irgendwass bekomme ich keine brauchbaren Antworten. Der Grund ist das ich das modem falsch anspreche.


    Im quellcode der Programme die für das Teil sind geht das mit den Befehlen


    sendbyte ()


    den hab ich aber auf dem c64 nicht


    ich muss also für einen Befehl 3 byte Byteweise übertragen damit das Modul mich versteht und ebenso 1 oder 2 byte je nach befehl byteweise einlesen


    sowas wie


    read byte()


    Ich glaube nicht das es an der RS232 Schnittstelle liegt. Das hab ich ja getestet in dem ich den c64 am PC angeschlossen habe und da kann ich lustig ASCII Code hin und her senden aber eben keine "bytewerte"


    Oder hab ich da einen Denkfehler


    :(

  • Ich war erst auf dem völlig falschen Dampfer (dachte, Du wolltest am Userport des C64 das I2C-Protokoll implementieren), aber jetzt denke ich das Problem verstanden zu haben. Korrigier mich, falls diese Beschreibung nicht stimmt: ;)
    1. Du willst irgend etwas per I2C ansprechen.
    2. Du hast einen I2C-Controller, der über eine RS232-Schnittstelle gesteuert werden kann.
    3. Wird dieser Controller mit der seriellen Schnittstelle eines PC verbunden, so kann man ihn mit den PC-Programmen des Controllers erfolgreich ansteuern.
    4. Mit normalen PC-Terminalprogrammen klappt es jedoch nicht (weshalb? was passiert? welche Fehlermeldung?)
    5. Statt mit dem PC willst Du aber lieber mit dem C64 auf besagten Controller zugreifen.
    6. Du hast bereits einen Pegelwandler am Userport, damit der C64 eine standardkonforme RS232-Schnittstelle erhält.
    7. Um sicherzustellen, dass die RS232 des C64 grundsätzlich funktioniert, hast Du die beiden RS232 von C64 und PC testweise direkt verbunden und kannst auch erfolgreich Daten austauschen.


    Zuerst einmal solltest Du herausfinden, warum genau Du den I2C-Controller nicht auch von einem normalen PC-Terminalprogramm ansprechen kannst. Solange das nicht funktioniert, ist es meines Erachtens nicht sinnvoll, den C64 als zusätzliche Hürde dazuzunehmen.


    Davon abgesehen kann es auch noch mit der RS232 des C64 ein Problem geben, nämlich falls die Pegel nicht stimmen: Laut Standard benutzt RS232 Pegel von +/- 12 Volt; einige Schnittstellen erzeugen jedoch stattdessen nur +0/+5 Volt. Falls nun der C64 falsche Pegel ausgeben sollte, wäre es möglich, dass der PC diese akzeptiert, der I2C-Controller jedoch nicht.


    Ach ja, und dieser Thread scheint nicht in die Rubrik "andere Commodore" zu gehören. Hallo Mod, bitte verschieben. ;)


  • Du bekommst einen Orden
    genau so ist es
    ich verstehe auch nicht warum ich das Modem über ein normales Terminal programm nicht ansprechen kann
    wie gesagt es stimmt etwas mit dem format der befehlsübergabe nicht
    das Modem versteht wahrscheinlich keine ascii zeichen den übertragung der daten muss als byte übertragen werden also etwas was nicht ascci ist. ich hab im forum ein code gesehen der grafik daten byte weise überträgt. ich habs nur nicht ganz verstanden... ich denke: wenn ich in einen speicherbereich die nötigen werte poke und diese dann an das modem übertrage könnte es gehn. Ich hab in dem beispiel aber auch gesehen das ein "hire" aufgebaut wir der zu hälfte gefüllt wird??????? keine Ahnung :(
    Ich hab einfach ein problem mit der übertragung. wenn das modem einen befehl dez 18 pls dez0 pls dez 4 erwarten wie bekomme ich die daten dahin. Im normalen Terminalprogramm werden Asscii werte übertrage das versteht der c64 sie können sogar als steuerzeichen interpretiert werden also bei wert sowieso ändert sich am c64 die zeichenfarbe usw. das ist für das modem nicht zu gebrauchen. Dann hab ich versucht mit dem terminalprogramm hex werte zu übertragen mit $10 oder x010 usw geht alles nicht. das modem spricht nur auf die übermittlung der befehle aus den programmen an die auf der website sind. bitte schau dir das mal an. Dein hinweis den c64 nicht als zusätzliche hürde ein zubauen sehe ich auch so den wenn ich weiß wie ich von einem normalen terminalprogramm die befehle übermittle bekommme ich das auch mit dem c64 hin!! was nu ;)
    was die pegel angeht ich hab hinter der uart emulierten userpor einen ttl wandler mit einem max232 und eigen kondensatoren, der die pegel von 5v/0v auf -15/+15 volt umwandeln sollte......
    bitte schau dir das nochmal an :thumbsup:

  • ASCII-Zeichen sind auch nur Bytewerte, so hat z.B. das Zeichen 'A' den Wert 0x41 (dezimal 65). Wenn Du z.B. im Terminalprogramm die Zeichenfolge "$10 x010" eingetippt hast, wurden diese Bytes gesendet:
    0x24 (Dollarzeichen), 0x31 ('1'), 0x30 ('0'), 0x20 (Leerzeichen), 0x78 ('x'), 0x30, 0x31, 0x30.


    Das Problem ist, dass die ASCII-Zeichen erst ab dem Leerzeichen (0x20 = 32) druckbar sind; die Werte von 0 bis 31 sind Steuercodes: 9 ist z.B. TAB, 10 ist Line Feed, 13 ist Carriage Return. Werte wie 3 oder 6 kann man also in einem Terminalprogramm nur schlecht eingeben. Am C64 ist das aber trivial, einfach die CHR$()-Funktion benutzen:

    Code
    1. print chr$(6);:rem gib Zeichen mit Wert 6 aus

    Das Semikolon am Ende ist wichtig - wenn es fehlt, gibt der PRINT-Befehl noch ein Return (Wert 13) aus, und das willst Du ja nicht.
    Für den umgekehrten Weg brauchst Du die ASC-Funktion:

    Code
    1. get a$:rem lese Zeichen
    2. c = 0:if a$<>"" then c=asc(a$):rem wandle Zeichen in Zahlenwert
  • ASCII-Zeichen sind auch nur Bytewerte, so hat z.B. das Zeichen 'A' den Wert 0x41 (dezimal 65). Wenn Du z.B. im Terminalprogramm die Zeichenfolge "$10 x010" eingetippt hast, wurden diese Bytes gesendet:
    0x24 (Dollarzeichen), 0x31 ('1'), 0x30 ('0'), 0x20 (Leerzeichen), 0x78 ('x'), 0x30, 0x31, 0x30.


    Das Problem ist, dass die ASCII-Zeichen erst ab dem Leerzeichen (0x20 = 32) druckbar sind; die Werte von 0 bis 31 sind Steuercodes: 9 ist z.B. TAB, 10 ist Line Feed, 13 ist Carriage Return. Werte wie 3 oder 6 kann man also in einem Terminalprogramm nur schlecht eingeben. Am C64 ist das aber trivial, einfach die CHR$()-Funktion benutzen:

    Code
    1. print chr$(6);:rem gib Zeichen mit Wert 6 aus

    Das Semikolon am Ende ist wichtig - wenn es fehlt, gibt der PRINT-Befehl noch ein Return (Wert 13) aus, und das willst Du ja nicht.
    Für den umgekehrten Weg brauchst Du die ASC-Funktion:

    Code
    1. get a$:rem lese Zeichen
    2. c = 0:if a$<>"" then c=asc(a$):rem wandle Zeichen in Zahlenwert


    danke ;) ich werd jetzt erstmal testen bitte bleib am ball.

  • I2c geht aber auch direkt mit dem C64 und zwar mit dem Kassetten-Port und etwas Hühnerfutter! :) In dem Buch "Hardwarebastelleien mit dem C64" gab es mal eine i2c Schaltung für ein RTC.
    Das Interface hatte ich vor einiger Zeit mal nachgebaut und ein paar Displays damit angesteuert:


    hier


    Also nur für den Fall, der RS232-Umsetzer will nicht... :)


    VG


  • Super danke


    ich hab diese Infos auch gefunden, leider ist das Buch nicht mehr zubekommen und wenn dann gebraucht für 98 Euronen.


    Die Frage die ich nicht klären konnte ist wie der cassetten port genau angesprochen wird.


    Ich hab zwar ein paar Pokes gefunden zum beispiel zu schalten des Datasettenmotors usw.


    Die datenübertragung kann ich doch nicht mit save oder load machen oder.? Ich hab mir überlegt dass man evt über die Kernelroutinen geht. Ich hab da ne tabelle in der steht wie man diese aufruft und welche register usw. mit was geladen werden müssen.


    Allerdings stell ich mir vor, das man dann in den datasetten puffer in dem die Daten vorgehalten werden nur die ensprechenden werte laden muss um sie dann über den port zu senden. da fehlen mir aber noch die genauen adressen.


    Des weiteren muss doch wahrscheinlich die Spannung des für den Motor vorgesehenen Stroms auf 5v anpassen oder?


    Also lauter Fragen...


    Da ich mit dem USERport schon ein wenig Erfahrung habe dachte ich... kein Problem HAHA


    Ich muss aber dazu sagen, dass ich mit dem c64 aufgewachsen bin so wie wahrscheinlich die meisten hier und dann habe ich mich entschlossen mich wieder damit zu beschäftigen. Back to the routs so zusagen..


    Ich muss mich erst wieder einarbeiten. deshalb bitte nicht zuviel vorausetzen ich bin für jeden tipp dankbar

  • Zitat von »MOS6510«
    In dem Buch "Hardwarebastelleien mit dem C64" gab es mal eine i2c Schaltung für ein RTC.

    ich hab diese Infos auch gefunden, leider ist das Buch nicht mehr zubekommen und wenn dann gebraucht für 98 Euronen.

    Hallo Ingo, schön dass du den Weg hier her gefunden hast, eine PDF-Version des Buches findest du übrigens in der ersten Wolke.

  • ja, den Schaltplan hätte ich auch separat da. Über Kernel-Routinen kann man das natürlich nicht ansprechen. Da muss man in Assembler etwas selbst machen.
    Die Motorleitung wird als Datenleitung missbraucht...Es ist aber nicht schwer. Ist ja nur etwas "Bitwackeln" Die Codestellen hätte ich sogar auch da…aber wenn's das Buch in der Wolke gibt… :)

  • gibt's eigentlich ein commodore-buch, das du nicht hast kiri ? ;) bist ja unser reinster Literatur guru

    Auch auf die Gefahr hin dich zu enttäuschen, ich habe es nicht hochgeladen, das Buch lag bereits in der Wolke.
    Ich könnte höchstens noch das D64-Image zum Buch beisteuern, das habe ich auf den ersten Blick nicht in der Wolke gefunden.

  • ja, den Schaltplan hätte ich auch separat da. Über Kernel-Routinen kann man das natürlich nicht ansprechen. Da muss man in Assembler etwas selbst machen.
    Die Motorleitung wird als Datenleitung missbraucht...Es ist aber nicht schwer. Ist ja nur etwas "Bitwackeln" Die Codestellen hätte ich sogar auch da…aber wenn's das Buch in der Wolke gibt… :)


    hallo


    ist es unverschämt, wenn ich dich bitte mir die Sachen zu geben? :P


    Ich hab gestern noch was ausprobiert und denke das es doch an dem ttlwandler liegt.


    Denn, zumindestens müsste ich vom modul eine fehlermeldung bekommen.


    Dank an alle!