serieller TX mit delay in Software (AVR, UART)

[floh boing (Gast)]

Für's schnelle Debuggen ohne Debugger.
Der Vorteil: braucht keinen Timer oder Interrupts.
Der Nachteil: hat keinen Timer.

Kann man das noch schicker schreiben, so dass die Wartezeit samt 
Schleifendurchlauf und Vergleich näher an der tatsächlichen Bitzeit dran 
ist (so dass 1/BAUDRATE-CONST genutzt werden kann)?
CONST könnte noch mit F_CPU angepasst werden.

Ich hatte zuvor Schieben mit variablem i drin (d&(1<<i)), so sind's 
schonmal 32 Byte weniger (neues Timing noch nicht getestet, Takt 1MHz):

    uint16_t d = 0b1000000000 | (c<<1);  // stop, data LSB first, start
    for(uint8_t i=0; i<10; i++){
        if( d & 1 )
            PORT |= (1<<PIN);
        else
            PORT &= ~(1<<PIN);
        d>>=1;
        _delay_us(70/*104*/);
    }

[floh boing (Gast)]

PS: GCC mit -Os

[Falk B. (falk)]

Herzlichen Glückwunsch zur Wiederentdeckung des Soft-UARTs!

[floh boing (Gast)]

Falk B. schrieb:
> Herzlichen Glückwunsch

Danke. Kannst du auch was Sinnvolles beitragen, wie z.B. einen Link oder 
gar eine Verbesserung des Codes?

[Stefan F. (Gast)]

floh boing schrieb:
> Kannst du auch was Sinnvolles beitragen,

Ich verstehe auch nicht, was du uns mit diesem Thread großartiges 
mitteilen willst. Da ist seit Erfindung der Mikroprozessoren nichts 
neues oder interessantes dran.

Du solltest Interrupts sperren, die versauen dir sonst das Timing.

[A. S. (Gast)]

Hallo,

ganz solide. Die 70µs sind gewürfelt?

Du könntest das genauso auch mit dem d laufen lassen und auf i 
verzichten, zumindest wenn c uint8 ist. Ist aber kaum besser.

uint16_t d = 0b1000000000 | (c<<1);  // stop, data LSB first, start

    while(d) {
        if(d&1) {PORT |=  (1<<PIN);}
        else    {PORT &= ~(1<<PIN);}
        d>>=1;
        _delay_us(70);
    }

[wendelsberg (Gast)]

Stefan ⛄ F. schrieb:
> Du solltest Interrupts sperren, die versauen dir sonst das Timing.

Zum Debuggen? Unzweckmaessig.

wendelsberg

[Axel S. (a-za-z0-9)]

wendelsberg schrieb:
> Stefan ⛄ F. schrieb:
>> Du solltest Interrupts sperren, die versauen dir sonst das Timing.
>
> Zum Debuggen? Unzweckmaessig.

Und? Was nützt eine nicht funktionierende Debugausgabe?

[Falk B. (falk)]

Axel S. schrieb:
> Und? Was nützt eine nicht funktionierende Debugausgabe?

Die kann man dann Debuggen ;-)

[Stefan F. (Gast)]

Textausgaben untersuchen ist auch eine Variante des Debugging. Lange 
Zeit ging es gar nicht anders. Ich kam in meiner Jugendzeit noch 
zwangsweise zu diesem unerquicklichen Genuss.

Eproms mit Kippschaltern zu programmieren ist auch aus der Mode gekommen 
:-)

Kennt ihr noch die Computerzeitschriften mit Spielen zum Abschreiben? 
Also wo man seitenweise Hex-Zahlen abtippen musste.

Wenn das Programmieren heute noch so mühsam wäre, würden alle nur noch 
vor dem Fernseher sitzen. Den Stress tut sich heute niemand mehr an.

[Peter D. (peda)]

Hier meine Version:

void sputchar(unsigned char c)
{
  c = ~c;                                       // complement to send 0 = stop bit(s)
  STXD_oe = 1;                                  // output
  STXD = MARK;                                  // start bit
  for (uint8_t i = 9 + STOP_BITS; i; i--)       // start + data + stop bits
  {
    _delay_us(1e6 / BAUD);                      // bit duration
    if (c & 1)
      STXD = MARK;
    else
      STXD = !MARK;                             // = Space
    c >>= 1;                                    // next bits or stop bit(s)
  }
}

[floh boing (Gast)]

Stefan ⛄ F. schrieb:
> Du solltest Interrupts sperren, die versauen dir sonst das Timing.

Guter Hinweis.

A. S. schrieb:
> ganz solide. Die 70µs sind gewürfelt?
>
> Du könntest das genauso auch mit dem d laufen lassen und auf i
> verzichten, zumindest wenn c uint8 ist. Ist aber kaum besser.

Ja, ausprobiert. Darin steckt aber auch die Abweichung des internen RCs 
bei meinem AVR.
Danke für's Feedback.

Peter D. schrieb:
> Hier meine Version:

Danke Peter, die hatte ich gestern in 
Beitrag "Re: ATtiny44 -Software Uart - nur senden" ff. gefunden, und 
wollte gerade den Link posten.
Im Beitrag von Schorsch werden auch die offenbar 9 Takte für Schleife 
und Ausgabe berücksichtigt.

Falk B. schrieb:
>
.
Das habe ich mir gedacht.


Thema erledigt. Danke!

[Martin (Gast)]

Wer Interrupts nicht sperren möchte nimmt:

ATOMIC_BLOCK(ATOMIC_RESTORESTATE)
{

    ...

}

[Georg (Gast)]

Martin schrieb:
> Wer Interrupts nicht sperren möchte nimmt:

Da darin ein Delay steckt sind die Nebenwirkungen ev. drastisch, da dann 
der Interrupt nicht mehr annähernd Real Time ist, jedenfalls manchmal - 
das ganze ist eben ein Weg aus der Computersteinzeit. Zuletzt habe ich 
das gesehen bei ZX80 und C64.

Georg

[Stefan F. (Gast)]

Bei einem Steuergerät in einem Verteilzentrum hatten die das mal clever 
mit der Power-LED kombiniert (war offenbar anfangs nicht eingeplant 
gewesen).

Man konnte ein USB-UART Adapterkabel anstelle der Power-LED anstecken. 
Dieses hatte einen Taster, der die beiden Pins miteinander verband. 
Dadurch konnte man Debug Ausgaben auf eben diesem LED-Pin aktivieren.

Mein Motorrad hat etwas ähnliches. Da baumelt aus dem Steuergerät ein 
kleiner zweipoliger Stecker, an den man ein Diagnosegerät anschließen 
kann. Wer dieses Gerät nicht hat, kann dort einfach eine Drahtbrücke 
einsetzen. Dann gibt das Gerät hilfreiche Morsecodes auf der gelben 
Kontroll-Leuchte aus. Und diese Codes sind in der Betriebsanleitung alle 
dokumentiert (was leider nicht mehr selbstverständlich ist).

Klar hat so eine Soft-UART Seiteneffekte. Sie kann trotzdem in 
bestimmten Anwendungsfällen äußerst nützlich sein.

[Peter D. (peda)]

Je nach Anwendung kann man 2 Varianten vorsehen:
- kurze Interrupthandler, geringe Baudrate
- Byte senden atomar gekapselt, hohe Baudrate

[floh boing (Gast)]

Peters Algorithmus hat mindestens zwei Vorteile:

- es gibt keine (überflüssige) Wartezeit am Ende
- es muss nur ein Byte geschoben werden, denn das Stopbit gibt es 
"kostenlos" beim Schieben (durch die Invertierung)

[A. S. (Gast)]

floh boing schrieb:
> Peters Algorithmus hat mindestens zwei Vorteile:
>
> - es gibt keine (überflüssige) Wartezeit am Ende
> - es muss nur ein Byte geschoben werden, denn das Stopbit gibt es
> "kostenlos" beim Schieben (durch die Invertierung)

a) die Wartezeit am Ende ist nicht überflüssig. Das weiß Peter auch. 
Darum versteckt er das im Schleifenzähler. Rechne mal nach.

b) Dafür braucht er einen Schleifenzähler.

(c) Es gibt 2 verschiedene Stellen, in denen die Leitung gesetzt wird.

Peters Code ist (wieder mal) sehr pfiffig und kaum zu toppen. Bei der 
Aufgabe sind die Möglichkeiten aber auch überschaubar ... und sinnlos. 
Das Problem bleibt das Delay: Damit ist kein Interrupt erlaubt und und 
Rechenzeit spielt keine Rolle.

[floh boing (Gast)]

Stimmt!