Daten übertragen von Tiny13 nach Tiny2313

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    Aufgrund technischer Veränderungen ist der Mailverkehr innerhalb des Forums (Private Nachrichten) nur noch eingeschränkt möglich. Die Einschränkung ist notwendig, um zusätzliche Betriebskosten für das Forum zu vermeiden. Näheres zu den Hintergründen im Thread "Aktuelles zum Forum".Wir bitten um Verständnis.

    Hinweis kann nach Kenntnisnahme deaktiviert werden!

    • @elektron
      Baudrate glaube ich nicht wirklich dran,
      9,6 MHz und baud 4800 , ist der Fehler unter 0.2%
      8MHz und baud 4800 , liegt der Fehler auch bei ca. 0,2%
      Um den Fehler über 2% zu bringen, muss die Frequenz aber
      schon ziemlich daneben liegen.
      Meine erfahrung sagt, wenn die Baudraten ziemlich daneben liegen
      empfüängt man meist nur Hyroglyphen. Ist aber hier nicht so.
      Ich kann mich natürlich auch irren. Sollte es dennoch so sein,
      kommt ein "..tschuldigung..", 'ne Schippe Asche aufs Haupt,
      dann muss aber alles wiede vergessen sein.

      @tschoeatsch
      ich werde mich mal in die PRINTBIN geschichte einlesen und probieren.
      Ob von Erfolg gekrönt , oder nicht, ich lass es dich wissen.

      Also weiter probieren.

      Detlef

      was mir gerade auffällt, die Überschrift ist falsch.
      Es müsste Tiny 2313 heissen, hat sich aber noch keiner dran gestört.
      Leichtsinn ist kein Mut, Vorsicht keine Feigheit.

    • tschoeatsch schrieb:

      Diese ganze Umwandlerei hat man bei verwenden von printbin und inputbin nicht. Wurde ja auch schon von @djmsc vorgeschlagen.
      Exakt!
      'print' wandelt in ascii um und hängt noch ein <cr> dran.
      Will man wie hier einen Messwert übertragen bietet sich 'printbin' an. Da die serielle Übertragung bytorientiert arbeitet einfach die Messwert-Wortvariable mit 2 Overlay-Byte unterlegen und diese dann senden. Die Empfangsseite kann diese dann umgekehrt wieder zusammensetzen.

    • oscar schrieb:

      tschoeatsch schrieb:

      Diese ganze Umwandlerei hat man bei verwenden von printbin und inputbin nicht. Wurde ja auch schon von @djmsc vorgeschlagen.
      Exakt!'print' wandelt in ascii um und hängt noch ein <cr> dran.
      Will man wie hier einen Messwert übertragen bietet sich 'printbin' an. Da die serielle Übertragung bytorientiert arbeitet einfach die Messwert-Wortvariable mit 2 Overlay-Byte unterlegen und diese dann senden. Die Empfangsseite kann diese dann umgekehrt wieder zusammensetzen.
      Das ist nach dem Lesen der zugehörigen Hilfe nicht nötig. Man kan auch word senden und in ein word empfangen. Es müssen nur geschickterweise die Sendevariable gleiches Format wie die Empfangsvariabe haben.
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------

    • Hallo,
      gleiche Variablentypen hatte ich ja am Anfang auch so, das Terminal hat auch brav gelesen
      und angezeigt. Der TinY 2313 hat aber gesagt, Variable ist "0".
      Vielleicht ist Print und Input doch die falsche Wahl.
      Ich werde wohl, so ich morgen die Zeit finde das alles mit
      Printbin und inputbin durchspielen.
      Schau' ' mer mal.

      Detlef
      Leichtsinn ist kein Mut, Vorsicht keine Feigheit.

    • Hallo,
      Also, es kommt ja offensichtlich auf der Empfangsseite ein Cr an, denn sonst würde Input hängen bleiben. Ich habe nie verstanden, was Input oder Print ohne #x eigentlich tut. Daher mal mit #1 oder so probieren und den Com-Port intialisieren (steht in deinem Eingangs-Post nicht dabei). Wer weiss, auf was Dein Input sonst lauscht.

      Dekaman schrieb:

      alles mit
      Printbin und inputbin durchspielen
      Vorsicht.
      Es war bis vor nicht allzulanger Zeit so, dass Inputbin Probleme bereitete (ich weiss nicht, ob das behoben wurde). Offensichtlich war ich auf der ganzen Welt der Einzige, der das mal ernsthaft benutzen wollte, denn in keinem der Forum gab es Kommentare zu den folgenden Problemen:
      Und zwar, wenn man die Übertragungs-Synchronisation mittels Input #(!),a macht, wobei in einer Schleife auf ein bestimmtes Zeichen gewartet wird, und anschliessend Inputbin #(!) aufrief, dann stand in dem empfangegen Block zuvorderst immer noch das von Input# gelesene Zeichen drin, und die folgenden 5 Bytes waren irgendwas konstantes von Irgendwoher, also sechs Bytes unbrauchbar, was man berücksichtigen musste.
      Weiterhin, wenn man Inputbin # dann zweimal hintereinander aufrief (weil Inputbin nur 64k? empfangen konnte - das ist inzwischen vergrößert worden, siehe "Enhancements" im bei MCS) - dann war der zweite Teil gleich dem ersten! Im alten Forum kam ich zu dem Schluss, dass Inputbin kaputt sei.
      Ich hab's noch nicht wieder probiert....wahrscheinlich ist's repariert... :aber zunächst mal Vorsicht walten lassen. Mich hat das eine Woche vertane Zeit gekostet, bis ich die Systematik mit allen Kräften (Logikanalysator) herausfand und dann auf die Übertragung ganz verzichten konnte und musste, weil der Xmega alles alleine konnte. (Die Übertragung mit Print und Input hätte zu lange gedauert).

      Wenn die Baudrate stimmt was ich als noch nicht "bewiesen" sehe weil die Empfangsseite ja nicht funktioniert, dann muss die Kommunikation klappen. Geht immer. (Und schön TX und RX kreuzen, und GND-Verbindung nicht vergessen.)

      Zusammenfassung:
      Den Com-Port initilisieren und Input # benutzen.
      Für das bisschen Daten brauchst Du nicht Inputbin.
      Gruß, elektron

    • elektron schrieb:

      Für das bisschen Daten brauchst Du nicht Inputbin.
      Jetzt mal vorausgesetzt, das inputbin geht, warum wäre input besser? Die Daten sind words, da ist es doch praktisch, mit printbin und inputbin zu hantieren, weil ich nach dem Hilfetext meine empfangenen Daten gleich in einem word drin habe.
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------

    • tschoeatsch schrieb:

      Die Daten sind words, da ist es doch praktisch, mit printbin und inputbin zu hantieren, weil ich nach dem Hilfetext meine empfangenen Daten gleich in einem word drin habe
      Was da praktisch(er) sein soll, erschliesst sich mir nicht.

      Hilfe zu Input:
      "It will receive 2 bytes for a WORD/INTEGER"
      Also geht das doch wunderschön mit Print und Input.
      Inputbin:
      "Read binary data from the serial port"

    • Die Befehle INPUT und INPUTBIN verwende ich überhaupt nicht, sondern benutze den Receive Complete Interrupt.
      Die Nachteile von INPUT und INPUTBIN:
      Der Befehl INPUT wartet auf eine Zeichenfolge von der UART und schreibt diese ineine Variable und zwar wartet der µC so lange auf die Zeichenfolge bis CARRIAGE RETURN (CR) erkannt wurde. Das Programm bleibt also stehen, bis CR über die UART kommt.
      Bei INPUTBIN wartet Bascom auf Binärdaten. Es wartet also nicht auf Text,wie es INPUT macht, sondern auf reine Daten. INPUTBIN stoppt das Programm so lange,bis die entsprechende Variable befüllt wurde.
      Der µC hat ja sonst nichts Anderes zu tun als zu warten bis endlich mal Daten über die UART kommen. a_218_eb6e2334

    • Print und input sind perfekt aufeinander abgestimmt.
      Die Hilfe erklärt sehr schön, was input alles annimmt. Und mit Print sendet man das entsprechende. Bytes, integer, strings etc, nur muss es halt bytezahlmässig zueinander passen.
      For I=1 to 1000:Print #1,chr$(13); I:next
      .............................input #1,J......
      Hab wie gesagt nie Probleme gehabt, wenn alles andere passt (s.obigen Post.).

      Edit:
      Man kann das Wartezeichen für Input mit config Input modifizieren.
      Tut man es nicht, wartet Input auf Cr. Print #1,a sendet aber defaultmäßi CrLF nach dem a, so dass man so Printen muss:
      Print #1,a;chr$(13); Dann passt es zu Input #1,a, wenn die a's gleich dimensioniert sind.

      Also ;chr$(13); anhägen.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von elektron ()

    • Lassen wir das Warten mal außer Acht. Wenn ich mit print ein word sende, dann empfange ich mit input nur was vernünftiges, wenn ich einen string damit befülle, den ich dann mit val zu einem word konvertiere. Sende ich das word mit printbin, klappt es mit input (in ein word), wenn ich ein 'cr' hinterher schicke, oder ich nehme inputbin (in ein word). Nachdem printbin keine Ascii sendet, muss man nicht wandeln. Ist das so richtig?
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------

    • elektron schrieb:

      Print und input sind perfekt aufeinander abgestimmt.
      Die Hilfe erklärt sehr schön, was input alles annimmt. Und mit Print sendet man das entsprechende. Bytes, integer, strings etc, nur muss es halt bytezahlmässig zueinander passen.
      For I=1 to 1000:Print #1, I:next
      .............................input #1,J......
      Hab wie gesagt nie Probleme gehabt, wenn alles andere passt (s.obigen Post.).
      Wie passt das mit dem Hilfetext zusammen??
      PRINT will automatic convert numeric variables into the string representation.
      This means that when you have a byte variable named B with the value of 123, the numeric variable is converted into a string "123" and then printed.
      In this case, print will print 3 characters or bytes. When you want to print the byte you can use the chr() function : print chr(b);
      This will send just one byte to the UART.
      Wenn du j als word dimmst, kann j 2 bytes aufnehmen, dann ginge deine Schleife bis 99. Und führende Nullen werden doch nicht gesendet, also passt das bei 0..9 auch nicht. (alles aus meiner Sicht, wie schon paarmal erwähnt, keine Erfahrung, aber es interessiert mich)
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------

    • elektron schrieb:

      Das Warten sollte man nicht ausser Acht lassen.
      Input wartet auf das Abschlusszeichen (Cr). Wenn "12CR" ankommt, und die Inputvariable ist als Word definiert, dann ist wird die Word-Variable =12 dezimal, aber zwei bytes.
      Siehe auch meinen korrigierten Beitrag #32.
      Wie ist der Zeichenfolge auf die 2 bytes verteilt? Print sendet Ascii-zeichen, also steht nach input im msb von Variable a ein chr(1) drin und im lsb chr(2).
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------

    • Hallo,
      ich habe wieder etwas rum experimentiert.
      Jetzt bin ich soweit, das das Display die ankommenden
      Daten anzeigt.
      @tschoeatsch
      Ich habe den Transfer mit PRINTBIN und INPUTBIN versucht,
      leider negativ. Frag mich aber bitte nicht warum. Ich habe mich dann
      doch wieder für PRINT und INPUT entschieden.
      Die ADC Werte(WORD) habe ich in STRING umgewandelt und mit PRINT
      gesendet. AM 2313 habe ich mit INPUT die in einem STRING abgelegt.
      Da aber als erstes Zeichen immer diese Hyroglyphe war , habe ich den
      String mit RIGHT einen zweiten String gefüllt, der die drei letzten Zeichen
      enthält, und diese zur Anzeige gebracht. Funktioniert prima, bis auf...

      @elektron
      am Terminal saubere Zahlen. Am Display manchmal auch kleine Buchstaben
      mit dabei (beide Anzeigen gleichzeitig).
      Jetzt Asche auf mein Haupt. Ich vermute, die Frequenz des 2313 ist doch nicht
      so optimal, so das die Synchronisation doch nicht wirklich stimmt. Ich denke ,
      daher auch die falsch interpretierten Zeichen.

      Ich will der Sache aber jetzt nicht weiter auf den Grund gehen. Ich weis jetzt,
      das ein Tiny13 auch mit dem Rest der Welt kommunizieren kann.
      Die ganze Sache war eh nur eine Machbarkeitsstudie. Wenn ich wirklich mal
      die Werte auslesen muss, geht's auch über MAX und COM auf ein Terminal.

      Schade , das ich nicht mehr Erkenntnisse gesammelt habe, aber es gibt auch
      noch ein Leben ausserhalb des Kolophoniumnebels.

      Detlef
      Leichtsinn ist kein Mut, Vorsicht keine Feigheit.