Probleem bij apparaat aansturing volgens RS232

[Hu9o]

Hallo mede tweakers,


Ik ben bezig met het ontwikkelen van een aanstuurmodule voor een apparaat.
Hiervoor heb ik documentatie (Duits) waarin staat welke string er verzonen moet worden om een bepaalde actie uit te laten voeren.

Het probleem is dat iedere regel eindigd met een "CS".
Ik heb al geprobeerd om een \n of \r te proberen, maar het werkt niet. Weet iemand wat die "CS" inhoud?

[CyberSnooP]

Hu9o schreef op 26 May 2003 @ 12:58:
Weet iemand wat die "CS" inhoud?

Bij mijn weten is CS een signaal lijn (pin) van de serieële poort. Die zul je dus blijkbaar (even kort) moeten activeren zodat het ontvangende apparaat weet dat hij zijn buffer kan gaan uitlezen.

Hoe je die signaal lijn precies activeert hangt af van OS en programmeertaal

[Hu9o]

Ok bedankt.

OS is Win NT, dat zal wel mogeljk zijn. Maar de programeertaal is HP VEE (Visual Engineering Enviorment) en daar zal het een veel groter probleem mee zijn. Denk namelijk dat je vanuit die omgeving niet direct toegang kan krijgen tot de afzonderlijke pinnen. Misschien met een ActiveX component

[pkouwer]

NT heeft sowieso problemen met het aansturen van poorten, direct

[DRAFTER86]

Ik stuur een lcd aan via de lpt en daar staat CS voor chip select, daar kun je mee aangeven of de daaropvolgende data een commando of een parameter is.

[farlane]

Duitsers zijn vaak sterren in het verzinnen van protocollen maar CS is geen RS232 pin iig.

Kun je een stukje posten zodat we kunnen zien in welk zinsverband het staat ?

[ Voor 24% gewijzigd door farlane op 26-05-2003 23:07 ]

[Verwijderd]

cs is een index register op je processor dacht ik

[Hu9o]

Apparaat aanzetten

Positie	0	1	2	3	4
teken	A	T	Z	NoB=5	CS

Apparaat uitzetten

Positie	0	1	2	3	4
teken	A	T	Q	NoB=5	CS

NoB=Number of Bytes

Een string moet opgebouwd zijn uit, zoals hierboven beschreven.
Alleen hoe de CS verzonden moet worden is me nog een vraag.
Als het zo is dat het een teken is om aan te geven dat de buffer uitgelezen kan worden, welk teken mag dit wezen dan?

[EXX]

Lijkt op een variant op de AT modem command set. Aangezien de lengte-indicator NoB 5 is, moet CS een bepaalde bytewaarde zijn. Ik zou zeggen: er zijn 256 mogelijkheden, poberen maar!

[Verwijderd]

CS is waarschijnlijk de checksum. Er zal wel beschreven staan hoe die berekent moet worden.
Er zijn verschillende manieren hoe die gebruikt kan zijn. Tel alle karakters (behalve de CS) bij elkaar op. Voor aanzetten is het resultaat 124 hex en voor uitzetten 11B hex.
Aangezien je waarschijnlijk maar een byte kunt sturen, kun je resp 24h en 1Bh proberen. Als dat niet werkt, kun je proberen de waarden te inverteren (XOR met FFh) of om ze af te trekken van 100h en het resultaat van die bewerking te gebruiken.

[Hu9o]

Checksum zou idd ook nog wel een goeie kunnen zijn. Maar die berekening die jij noemt, is dat een standaard berekening of bedenkt iedere fabrikant z'n eigen checksum berekening:?

Heb al contact met de leverancier opgenomen, maar die wisten het zelf ook niet... Dus die vraag gingen hun weer aan de fabriekant stellen. Kortom dat zal nog wel een tijdje duren...

[Reptile209]

Over welk LCD hebben we het eigenlijk? Wie weet heeft iemand 'm liggen...

[Hu9o]

We hebben het niet over een LCD. Het gaat hier om een gaspomp met 2 verwarmingselementen. Kleine kans dat iemand dit ding heeft liggen

[farlane]

Hu9o schreef op 27 May 2003 @ 10:20:
Checksum zou idd ook nog wel een goeie kunnen zijn. Maar die berekening die jij noemt, is dat een standaard berekening of bedenkt iedere fabrikant z'n eigen checksum berekening:?

Heb al contact met de leverancier opgenomen, maar die wisten het zelf ook niet... Dus die vraag gingen hun weer aan de fabriekant stellen. Kortom dat zal nog wel een tijdje duren...

Er zijn standaard checksum routines ( CRC8 , CRC16 etc ), maar als het een duits apparaat is worden die vast niet gebruikt.
Ze zijn vaak nogal blij met het OR/XOR'en van de bytes:

Bijvoorbeeld de checksum van het Siemens 3964R protocol

C++:

static byte calc_lrc(byte *data, sword size)
{   
    byte result;

    result = 0;
    while(size--)  result ^= *data++;
    return(result);
}

[Verwijderd]

Hu9o schreef op 27 mei 2003 @ 10:20:
Checksum zou idd ook nog wel een goeie kunnen zijn. Maar die berekening die jij noemt, is dat een standaard berekening of bedenkt iedere fabrikant z'n eigen checksum berekening:?

Nee, daarom ook de verschillende opties. En er kunnen er meer zijn. En sommige fabrikanten voegen nog een kleine offset toe

farlane schreef op 27 May 2003 @ 11:23:
[...]

Er zijn standaard checksum routines ( CRC8 , CRC16 etc ), maar als het een duits apparaat is worden die vast niet gebruikt.
Ze zijn vaak nogal blij met het OR/XOR'en van de bytes:

Checksum is NIET hetzelfde als een CRC. Een checksum is een simpele optelling, een CRC is dat zeker niet.

[farlane]

Verwijderd schreef op 27 May 2003 @ 16:53:
Checksum is NIET hetzelfde als een CRC. Een checksum is een simpele optelling, een CRC is dat zeker niet.

Het is idd niet hetzelfde, maar ze worden beide gebruikt om fouten in een bericht te detecteren. Ze hebben dus wel eenzelfde functie

[Verwijderd]

Punt was dat jij CRC aanhaalde als voorbeeld van een checksum routine. De functie is inderdaad min of meer hetzelfde.
Een CRC heeft echter wat voordelen:
* het verwisselen van twee bytes zal zeker een verschillend resultaat opleveren (bij een checksum dus niet)
* het omvallen van eenzelfde bit in twee verschillende bytes zal ook een verschillend resultaat geven (en bij een checksum niet)
* een CRC kan (meen ik) tot op zekere hoogte gebruikt worden om fouten te corrigeren

[ Voor 4% gewijzigd door Verwijderd op 28-05-2003 09:53 ]

[Hu9o]

Ik heb net een berichtje gekregen van de fabriek in Duitsland, hierin stond het volgende:

code:

"CS" bedeutet "Checksumme". Sie ist das letzte Byte ener Sendesequenz.
 Alle Bytes, auber CS (VCR), werdern met XOR verknüppft.

Dit betekent, zoals al eerder geopperd werd, dat het een Checksum betreft. Deze moet dus berekend worden doormiddel van een XOR.

Ik weet wel wat de XOR functie inhoud:

code:

X Y XOR 
0 0 0 
0 1 1 
1 0 1 
1 1 0

Maar deze kan steeds twee parameters vergelijken, hoe moeten de checksum nou bepaald worden? Want er ziten in totaal iets van 40 bits in de string waaruit de checksum bepaald meot worden.


edit:
mr Google zei:
letter1
letter2
XOR
letter3
XOR
letter4
CS

[ Voor 8% gewijzigd door Hu9o op 28-05-2003 11:28 ]

[Verwijderd]

De code die farlane hierboven gaf, doet dit voor je. Je pakt een byte en XOR'ed dat met het volgende byte. Het gaat (dus) om een byte-wise XOR.

[Hu9o]

Ik heb ondertussen een meeltje van de fabrikant gekregen!

Hierin staat het volgende voorbeeld ( Wat dit nou met XOR te maken heeft???)

code:

ATZ5
CS = (~(Byte1 + Byte2 + Byte3 + Byte4))+1
CS = (~(0x41+0x54+0x5A+0x05))+1
CS = (~(0xF4)))+1
CS = (0x0B)+1
CS = 0x0C

Dit voorbeeld is nog wel te volgen. Maar wat opvalt hierin zijn twee dingen:
- Voor cijfers wordt niet de ASCII code van het cijfer gebruikt, maar de rechtstreeks het hex getal.
- Er staat het ~-teken in. Het voorbeeld was een C voorbeeld stond in de meel.

Vraag: Wat betekend het ~ -teken * Hu9o bitwise invert

Waarschijnlijk is het iets als:
while CS > FF do CS - FF
(maar dat werkt niet bij andere commandos)

Iemand die hier antwoord op heeft?

edit: typo

[ Voor 8% gewijzigd door Hu9o op 03-06-2003 15:04 ]

[EXX]

Ja, ze gebruiken voor het cijfer de hexwaarde 5, want dat is het in wezen ook: number of bytes vd message; 0x05 dus (en niet het ASCII character 5)

Men doet dus:

code:

for t:= 1 to (number_of_bytes - 1) do
  begin
    cs := cs + byte[t];
  end;
invert(cs)
cs := cs + 1;

ik vermoed dat als je alle bytes inclusief de CS bij elkaar telt, er nul uit moet komen (als byte).

edit:

bij het voorbeeld klopt dat in elk geval

[ Voor 10% gewijzigd door EXX op 03-06-2003 15:23 ]

[Reptile209]

Hu9o schreef op 03 June 2003 @ 14:20:
- Er staat het ~-teken in. Het voorbeeld was een C voorbeeld stond in de meel.

Vraag: Wat betekend het ~ -teken * Hu9o bitwise invert

Die tilde moet een logische NOT zijn, dus praktisch in bijv. Pascal/Delphi:

Delphi:

CS := $F4;           // Rest v/d berekening ff overgeslagen
CS := not(CS)+1;
CS := CS and $FF;  // om de eventuele hogere bytes af te kappen

[EXX]

Reptile209 schreef op 03 June 2003 @ 15:27:
[...]

Die tilde moet een logische NOT zijn, dus praktisch in bijv. Pascal/Delphi:

code:

CS := $F4;           // Rest v/d berekening ff overgeslagen
CS := not(CS)+1;
CS := CS and $FF;  // om de eventuele hogere bytes af te kappen

Nope, een NOT in pascal geeft true of false en geen waarde (tenminste dat zou niet moeten).

Wat ze hier doen is niets anders dan het twee-complement van de som van de bytes, wat in Assembly ook wel NEGATE wordt genoemd:

NEG 0x00 -> 0x00
NEG 0xff -> 0x01

Volgens mij zit ik met mijn oorsponkelijke vermoeden juist: samen met de CS moet alles bij elkaar opgeteld nul opleveren (zonder carry).

byte1+byt2+byte3+byte4 = 0xf4
0xF4 + CS = 0x100.

Conder acht te slaan op de carry (dus puur byte als datatype gebruiken) is het resultaat dus 0x00.

[Hu9o]

Ok bedankt!

En dat optellen klop idd voor ieder commando.