RS232 comport: ny rad? putChar('\n');

[stekern]

Ett tips är att definiera radslut i C som "char lf[3];" och sedan använda "strcpy(lf,"\r\n");".

Om jag ska vara ärlig så ser jag inte fördelen med detta, men det är möjligt att nåt har förbigått mig.
Så utveckla gärna.

[blueint]

Ett alternativ är "char *eol;" samt "eol = "\r\n";" eller "eol = "\n";" osv beroende på vad inställningarna kräver. När man sedan ska skriva ut något så använder man "printf("Hej!%s\n",eol);" så att man slipper fundera över vilken eol dialekt som används.

[sodjan]

> Om jag ska vara ärlig så ser jag inte fördelen med detta,

Nej, inte jag heller riktigt.

Om man ska definiera ett eget radslutstecken så ska man väl
inte ta omvägen över \r\n utan stoppa in de numeriska värdena
som man vill ha direkt. Alltså något i stil med :

strcpy(lf,"\x0A\x0D" (eller om det blir i den andra ordningen...)

Om man ända förlitar sig på \r\n så kan man lika väl köra med det
direkt utan att ta omvägen över en egen variabel "lf"...

[jesse]

Ofta sker ju kommunikationen åt båda hållen, så jag tänkte helt enkelt kolla av vad den andra sidan skickar som "radslut". Just nu har jag en buffer som växer tills jag får in 0x0d (eller buffer overflow) - då signalerar den att en rad kommit in. Skulle en 0x0a slinka in nånstans så ignoreras denna. Jag kunde kanske lite mer aktivt leta efter 0x0a vid radslut - och beroende på om jag får in det eller inte så skickar jag ett likadant radslut tillbaks. Borde ju passa terminalen i den andra änden - "som man ropar får man svar".

[stekern]

De flesta "köpe"-seriella kommunikationsmoduler jag har påträffat (diverse RS-485 <-> AD-omvandlare, magnetometer, reläer osv)
har tolkat CR som linjeskiljare vid inkommande kommmunikation. Vad de skickat har vart lite olika.
En del har skickat CR-LF, en del bara CR, en del har det gått att ställa in det på.

[sodjan]

En annan vanlig metod är att skicka LF *först* i en ny rad/record/post.
På så sätt så scrollar inte en vanlig terminal "i onödan", d.v.s att den
sist sända raden ligger kvar på *sista* raden och det blir inte heller
ett problem att skriva på den sista positionen på den sista raden.
Terminalen scrollar bara upp när det faktiskt kommer en ny rad
att skriva ut.

[jesse]

Konstigt att det heter CR-LF då , om man ska skicka dom i omvänd ordning - LF-CR

[sodjan]

> ...om man ska skicka dom i omvänd ordning - LF-CR

Vem har sagt det ? LF kommer (fortfarande) efter CR.
Alltså CRLF.

[jesper]

sodjan har ju redan i sitt första inlägg förklarat hur det är.
Historiskt sett:
CR = cursorn/skrivhuvudet åt vänster.
LF = ny rad.

Att det sen egentligen inte behövs eller ser lite annorlunda ut idag är en annan sak. Tidigare användes ofta CR ensamt, för att uppdatera en rad t.ex. för att visa hur många % som fortskridit i något. Det syns även idag med många kommandoradsprogram.

För det "vanliga" radbytet, är det "Normala" förfarandet är att skicka en CR/LF sekvens (och i denna ordning).
Att olika system tolkar detta olika är sorgligt, men så är det. Det är ingen ide att försöka lösa detta problem.
Det är bara att skaffa ett ordentligt terminal program som klara båda varianterna.
Eller fixa o trixa i koden för att kunna skriva ut båda varianterna.

[sodjan]

Japp, det är inte alltid lätt att förklara visa saker för point-n-click-generationen...

> det "Normala" förfarandet är att skicka en CR/LF sekvens (och i denna ordning).

Exakt. Jesse läste mitt inlägg lite slarvigt. Det man ibland gör, är att fördröja
LF i CRLF sekvensen fram till att det faktiskt finns en ny rad att skriva ut !
Först *då* skickar men LF. På detta sätt kan man t.ex alltid visa 24 rader
på en 24 raders terminal, om man alltid skickade LF *direkt efter* CR så
skulle den sista raden alltid vara blank och man kan bara visa 23 rader...

[jesse]

Nej, jag hör inte till point-and-click-generationen. Jag växte upp med ABC80 (och den hade just 24 rader x 40 tecken) för att sedan pyssla med UNIX på universitetet. Men Det var ju när Microsoft gjorde intåg på marknaden som allt blev förvirrat (jag vägrade PC under 12 års tid).

Jag missuppfattade helt enkelt Sodjans inlägg, men fattar det nu. Bra poäng.

[stekern]

Japp, det är inte alltid lätt att förklara visa saker för point-n-click-generationen...

OT, men point-n-click-generationen brukade vi kalla folk som var lite till åren när jag var liten
Dvs, gamlingar som inte kunde använda en dator utan att klicka sig runt.

[sodjan]

Vill bara avrunda denna intressanta terminal-diskussion med en bild av den
terminal som startade det hela, VT100 från Digital Equipment Corp (DEC).
*Alla* emulator idag brukar ha VT100 som default emulering.
Jag har kört *mycket* programmering via sådana dära...



För den som är intresserad av terminaler, emulatorer eller olika ANSI/VT standards
kan gärna besöka http://vt100.net/.

[jesse]

[blueint]

Det som gör VT100 riktigt trevligt.. Valid ANSI Mode Control Sequences

Kanske något matnyttigt för diskussionen?
"The reset state causes the interpretation of the line feed (LF), defined in ANSI Standard X3.4-1977, to imply only vertical movement of the active position and causes the RETURN key (CR) to send the single code CR."