Soft UART sendet, empfängt aber nicht

[MagicWSmoke]

Getestet habe ich verschiedene Ports (auch PD3 mit INT1), in zig Kombinationen mit Buffer und ohne .....

Die Idee hinter ext. Int1 ist, dass man den Softuart-Empfang dort reinpackt um eine unmittelbare Reaktion auf eingehende Daten zu bekommen.
Eine leere Int1-ISR nutzt Dir nix. Nicht vergessen zum Abschluss der ISR das INTF1 zu löschen, ist in diesem Fall notwendig.
Nachteile einer solchen Konstruktion: Blockierung anderer ISR's während des Empfangs und andere ISR's können den Empfang behindern.

@PicNick

 .......dein code etc
   ' ---------- bis hierhin funktioniert alles ------------------------
 DIM instring as string * 8
 DIM Inchar(8) as byte at instring overlay
 DIM inidx as byte

  inidx = 0
  do 
          incr inidx
          X = Inkey(#2)
          inchar(inidx) = X
   while  X > 0                        

   Print "<";Instring;">Len:";inidx

Das wird so nix, denn da müsste der PC dann senden, wenn der µC genau diese Stelle des Codes ausführt. Da wäre ein Waitkey() angebracht. Das hätte allerdings den Nachteil, dass der Code hängen bleibt, wenn nix von der Seriellen reinkommt.
Man könnte sich für Inkey() selber etwas stricken, so in etwa:

Dim Time_Out As Word
  Time_Out = 10000
    While PinB.4 = 1 And Time_Out > 0
      Decr Time_Out
    Wend
  X = Inkey(#2)
' ...

[PicNick]

Du hast recht, wer nix weiss, soll nix reden.
Ich weiss nämlich nicht, was Bascom bei Soft-Uart "Inkey()" genau generiert.

[MagicWSmoke]

Du hast recht, wer nix weiss, soll nix reden.

Na, ich denke, Du weist schon, speziell bei Inkey() mag das jetzt nicht der Fall sein.

Ich weiss nämlich nicht, was Bascom bei Soft-Uart "Inkey()" genau generiert.

Muss zugeben, das wusste ich auch nicht genau, nur ergab sich aus der Hilfe:

If there is no character waiting, a zero will be returned.

dass Inkey() nicht-blockierend wirkt und lustig weitermacht, wenn nichts ansteht. Ob etwas ansteht, kann bei Soft-UART sowieso nur aktiv per Polling festgestellt werden (außer man verwendet Intx).

Daraus ergab sich, dass es im Pogrammablauf sehr unwahrscheinlich ist, dass das einzelne Inkey() gerade da kommt, wenn das Startbit vom PC kommt. Es gibt ein Beispiel dazu, "open.bas" im Samples-Ordner, da wird Inkey() in 'ner Do/Loop gepollt.

Aber um auch sagen zu können, was Inkey() tatsächlich macht, hab' ich's mir angesehen.
Wenn der Pin auf High liegt, liefert es eine 0 zurück, wenn er auf Low liegt, wird die Soft-UART Empfangsroutine ausgeführt.

Bei Deinem Code ist die Schleifenabbruchbedingung x = 0. Aus dem Gesagten ergibt sich, dass dies sehr wahrscheinlich gleich beim ersten Durchlauf zutrifft, die Schleife also sofort verlassen wird.

Waitkey() hingegen würde darauf warten, dass der Pegel Low geht, blockiert aber wenn nix über die Serielle kommt den weiteren Ablauf, deswegen mein Vorschlag mit dem Timeout.

[PicNick]

Das Bascom-Help hat mich über die Eigenheiten bzw. Unterschiede bei HW- und Softuart nicht befriedigt.
Bevor ich aber da mangels bessern Wissens nochmal "Lull" und "lall" erzähle, werd ich mir die diversen Soft-Uart Routinen disassemblieren und melde mich dann auf der Kampfstatt wieder *g*

[MagicWSmoke]

...werd ich mir die diversen Soft-Uart Routinen disassemblieren und melde mich dann auf der Kampfstatt wieder *g*

Alles klar.

[PicNick]

So, im Nachhinein betrachtet ohnehin klar:
Man muss/darf (wenn man INKEY() verwenden will) natürlich nur das speichern, was NICHT 0 ist. Als Endeerkennung einer Nachricht ist "0" wenig geeignet.
Wenn man z.b <CR> als Nachricht-Ende nimmt ( was Bascom-PRINT freiwillig tut, wenn man ihn nicht hindert), müsste die Receive-Schleife lauten:

    DO  
        inchar= inkey(#2)
        if inchar > 0
              incr myidx
              myarr(myidx) = inchar
        end if
    LOOP until  inchar = 27  

    myarr(myidx) = 0    ' ev. ein String-ende aus dem <CR> machen

unter der Annahme, dass das Speichern nicht zu langsam ist. Müsst man ausrechnen, bis zu welcher baudrate es reicht.
Sonst ist wohl eher "INPUT #" oder GET # geeignet


Wen es interessiert, so sieht INKEY() von innen aus:

open comb.4:9600,8,n,1 

L_0x00DE:   ' delay 1/2 bit --------------------------
 PUSH r24
 PUSH r25
 LDI r24,0x08
 LDI r25,0x00
L_0x00E6:
 SBIW r24,0x0001
 BRNE L_0x00E6
 POP r25
 POP r24
 RET

' inkey (#1)  ---------------------------------
L_0x00F0:
 SBIS 0x0016,4      ' check PortB.4
 RJMP L_0x00F8      ' start
 CLR r24            ' return 0
 RET
L_0x00F8:
 LDI r18,0x09       ' counter = 9 (8 + 1 )
L_0x00FA:           ' loop until PortB.4 = 0
 SBIC 0x0016,4      ' 
 RJMP L_0x00FA  
 RCALL L_0x00DE     ' delay 1/2 bit
L_0x0100:
 RCALL L_0x00DE     ' delay 1/2 bit
 RCALL L_0x00DE     ' delay 1/2 bit
CLC                ' clear carry
 SBIC 0x0016,4      ' PortB.4 = ?
 SEC                ' = 1---> set Carry
 DEC r18            ' decr counter
 BREQ L_0x0114      ' counter= 0 --> exit
 ROR r24            ' shift carry into r24:r25
 ROR r25
 RJMP L_0x0100      ' next bit
L_0x0114:
 RET                ' R24 = inbyte  (that's it)

Der Unterschied von Waitkey ist minimal

' waitkey (#1)  ---------------------------------
L_0x00F0:
 SBIS 0x0016,4 ' wait PortB.4 = 0
 RJMP L_0x00F6 ' start 
 RJMP L_0x00F0 ' cont'd wait    Das ist der einzige Unterschied 

[MagicWSmoke]

unter der Annahme, dass das Speichern nicht zu langsam ist. Müsst man ausrechnen, bis zu welcher baudrate es reicht.

9600 Baud = 9600 Bit/Sek, bei 16 MHz sind dann 1667 Takte pro Bit, da kann er viel speichern. Auch bei 76800 Baud, welche bei 16 MHz nur 0.2% Fehler hätten, wären's noch 208 Takte, sollte auch noch locker reichen. Voraussetzung ist, dass keine Interrupts unterbrechen.

' inkey (#1)  ---------------------------------
L_0x00F0:
 SBIS 0x0016,4      ' check PortB.4
 RJMP L_0x00F8
 CLR r24            ' return 0
 RET

Der Unterschied von Waitkey ist minimal

' waitkey (#1)  ---------------------------------
L_0x00F0:
 SBIS 0x0016,4 ' wait PortB.4 = 0
 RJMP L_0x00F6 ' start 
 RJMP L_0x00F0 ' cont'd wait

Das ist der einzige Unterschied

Aber der Entscheidende.