[Comms] Seriele poort; vage tekens

[Zynth]

Ik zit met een nogal vreemd probleem.
Ik moet via een UART, seriele poort dus, mijn telefoon aansturen.
Mijn telefoon is een Siemens M35i.

De datasheet van siemens is heel simpel;
stuur een commando, bijvoorbeeld AT+CGNI, afgesloten door
een \r (carriage return), en de telefoon antwoord.
Leuk bedacht, maar het werkt niet zomaar.
Als ik mijn telefoon aan de seriele poort hang en er met
SimpleTerm Gold (seriele poort tooltje) die string heenros
(op de goede bitrate he 38400) dan antwoord de telefoon niet.
Hij heeft dus blijkbaar iets niet goed ontvangen.
Met een nulmodem kabel naar een andere pc ook met simpleterm
kom ik erachter dat de string zeer netjes wordt verstuurd...

OK dacht ik; ik schrijf zelf ff een delphi applicatietje die met een component
datzelfde commando naar de seriele poort stuur.
Toen ging het ineens wel goed!!
Maar, door nu weer met een nulmodem kabel en een linux programmaatje
naar de output van mijn delphiproggie te kijken, zag ik dat mijn programma
daar het volgende van maakt:
een "a\r" versturen levert aan de andere kant van de kabel de volgende ascii-waardes op: 6, 102, -128.
Hoe kan dat???
en vraag 2; waarom reageerd mijn telefoon wel op zulke blaat (waarvan ik er maar niet kan achterkomen waar het allemaal voor staat)
en reageerd hij niet op letterlijk de goede string sturen?...

PS. om het verhaal nog raarder te maken;
ik heb een jaar geleden ofzo een C proggie gemaakt waarmee ik mijn telefoon een
nummer kon laten bellen; dat ging toen blijkbaar wel goed.
Maar hoe ik dat toen deed; geen idee!
Het enige was ik nog weet is dat ik wel gewoon een array met "ATD0611111111"
heb verstuurd...

[ Voor 4% gewijzigd door Zynth op 22-04-2004 16:26 ]

[curry684]

Nullmodem moet aan allebei de kanten dezelfde settings hebben: ziet eruit alsof je nu aan de Linuxkant bijv. 7 bits no parity leest en vanuit Windows 8 bits met parity stuurt oid.

[farlane]

Volgens mij heb je last van framing errors. Denk dat je je parity verkeerd hebt staan, of het aantal startbits/databits/stopbits.

* farlane langzaam zijn

[ Voor 8% gewijzigd door farlane op 22-04-2004 16:25 ]

[Zynth]

in mijn programmaatje verstuur ik als het goed is met 8 bits, 1 stopbit en non-parity.
In mijn C progamma lees ik dat uit met:

code:

  tcgetattr(fd, &options); //Get current port settings
  cfsetispeed(&options, B38400); //Set input speed
  cfsetospeed(&options, B38400); //Set output speed
  options.c_cflag &= ~PARENB; //Clear the parity bit
  options.c_cflag &= ~CSTOPB; //Clear the stop bit
  options.c_cflag &= ~CSIZE; //Clear the character size
  options.c_cflag |= CS8; //Set charater size to 8 bits
  options.c_cflag &= ~CRTSCTS; //Clear the flow control bits
  options.c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG); //Raw input mode
  options.c_cflag |= (CLOCAL | CREAD);
  tcsetattr(fd, TCSANOW, &options);

Dat zou volgens mij goed moeten zijn.
In mijn programma met de instellingen klooien levert niet echt wat op.
Ik blijf negatieve waarden ontvangen.

Als iemand mijn delphi programma of c programma wil hebben, zeg het dan maar.
Dan zet ik hem ff op de webserver.

[farlane]

Zynth schreef iets:

Volgens mij vergeet je nog een aantal dingen, mn ISTRIP te clearen.

Zie http://www.die.net/doc/linux/man/man3/tcsetattr.3.html

en ook

http://www.easysw.com/~mike/serial/serial.html#3_1_1

[ Voor 14% gewijzigd door farlane op 23-04-2004 16:59 ]