Function inp / outp

[Michael Post]

Hello members,

i have a (time-(?))-problem with the serial-communication with an ms-
dos 6.2 and the rs232-interface with an rs485-adapter behind the
interface.

I program in C. As compiler, i am using Open Watcom to build a DOS 16-
bit executable.

When i send the telegram to the device, the device answers very fast
(<1 millisecond).
After complete sending, i set the rts to 0x0 and wait for the answer,
but i got no answer, or i am to slow.
Somewhere is the error.

Maybe someone has some ideas or can give me some tips for better
coding?

Thanks for your help.

Here is my complete code:

#include <stdio.h>
//#include <stdlib.h>
#include <string.h>
#include <conio.h>
#include <dos.h>
#include <time.h>

/*
* Define some program keys
*/

// Exit-States
#define EXIT_SUCCESS 1
#define EXIT_UNSUCCESS 0

/**
* Define some information which should be outsourced to a config file
*/

// Sum of devices at COM1
#define SUM_DEVICES_COM1 1

/**
* Constants for serial port
*/

// Return values / Error codes
#define SERIAL_OK 1
#define SERIAL_E_COMPORT_NOT_DEFINED -1
#define SERIAL_E_WRONG_COMPT -2
#define SERIAL_E_WRONG_COMORT -3

// Serial mode for register 3
#define SERIAL_MODE_5BIT 0x00 // Bit
0-1: 00
#define SERIAL_MODE_6BIT 0x01 // Bit
0-1: 01
#define SERIAL_MODE_7BIT 0x02 // Bit
0-1: 10
#define SERIAL_MODE_8BIT 0x03 // Bit
0-1: 11
#define SERIAL_MODE_1STOPBIT 0x00 // Bit 2: 0
#define SERIAL_MODE_2STOPBIT 0x04 // Bit 2: 1
#define SERIAL_MODE_PARITY_NON 0x00 // Bit 3-5: 000
#define SERIAL_MODE_PARITY_ODD 0x08 // Bit 3-5: 001
#define SERIAL_MODE_PARITY_EVEN 0x18 // Bit 3-5: 011
#define SERIAL_MODE_PARITY_MARK 0x28 // Bit 3-5: 101
#define SERIAL_MODE_PARITY_SPACE 0x38 // Bit 3-5: 111
#define SERIAL_MODE_BREAK_CONTROL 0x40 // Bit 6: 0 or
1 Break control;
sends the receiver a break condition
#define SERIAL_MODE_ENABLE_DLR 0x80 // Bit 7: 0 or
1 DLR access
enable; if set, registers 0 and 1 become one big word register (the
DLR)

/**
* Function-Prototypes
*/

int serialInterfaceConnect(int nComPort, const int nBaud, const int
nMode);
void serialInterfaceSetBaudrate(int nComPort, const int nBaud);
char serialInterfaceGetRegister(int nComPort, int nRegister);
void serialInterfaceSendData(int nComPort, char *cString, int nLen);
int serialInterfaceConnect(int nComPort, const int nBaud, const int
nMode);
int serialInterfaceGetPort(int nComPort);
void serialInterfaceSendTelegram(int nCom, char cCommand, int
nSensor);
char vaseGenerateChecksum(const char *cTelegram);

/**
* Functions / Routines
*/
int main(){

int i=1;
int c1=0,c2=0;
int input;
int ii=0, rts_delay=20000;

/* Connect to COM2 */
if(serialInterfaceConnect(serialInterfaceGetPort(2), 1200,
SERIAL_MODE_7BIT | SERIAL_MODE_2STOPBIT | SERIAL_MODE_PARITY_EVEN)){
printf("Connected to COM2.\n");
saveToLog(DEBUG, "Connect to COM2.");

/* Connect to COM1 */
if(serialInterfaceConnect(serialInterfaceGetPort(1),
19200,
SERIAL_MODE_7BIT | SERIAL_MODE_2STOPBIT | SERIAL_MODE_PARITY_EVEN)){
printf("Connected to COM1.\n");
saveToLog(DEBUG, "Connect to COM1.");

/**
* Initialise all devices
*/
printf("*** Initialise devices ***\n");
for(i=1;i<=SUM_DEVICES_COM1; i++){
// for every device at com1

// Initialise sensor
printf("Activate sensor %d.\n",i);
saveToLog(INFO, "Activate sensor " +
i);

serialInterfaceSendTelegram(serialInterfaceGetPort(1), 'T', i);

// Receive result
c1 = 0;
c1 = inp(serialInterfaceGetPort(1) +
5);
// If so, then get Char
while(c1 & 1){
c2 =
inp(serialInterfaceGetPort(1) + 0);
printf("IN %c
\n",c2); // Print Char to Screen
c1 =
inp(serialInterfaceGetPort(1) + 5);
}// end while

// wait 500 milliseconds
delay(500);

// Get Version
printf("Get Version from sensor %d.
\n", i);
saveToLog(INFO, "Get Version from
sensor.");
saveToLog(INFO, i);


serialInterfaceSendTelegram(serialInterfaceGetPort(1), 'V', i);

// Receive result
c1 = 0;
c1 = inp(serialInterfaceGetPort(1) +
5);
// If so, then get Char
while(c1 & 1){
c2 =
inp(serialInterfaceGetPort(1) + 0);
printf("IN %c
\n",c2); // Print Char to Screen
c1 =
inp(serialInterfaceGetPort(1) + 5);
}// end while
}// end initialise for every device
}
else {
printf("Error: Could not connect to COM1.\n");
saveToLog(ERROR, "Could not connect to
COM1.");
return EXIT_UNSUCCESS;
}
}
else {
printf("Error: Could not connect to COM2.\n");
saveToLog(ERROR, "Could not connect to COM2.");
return EXIT_UNSUCCESS;
}

return EXIT_SUCCESS;

}// end function main

int serialInterfaceConnect(int nCom, const int nBaud, const int nMode)
{
/*
* This function connect to an specified serial-port
*/
int nTmp = 0;

outp(nCom + 1, 0); // Turn off interrupts
outp(nCom + 3, 0x80); // SET DLAB ON
serialInterfaceSetBaudrate(nCom, nBaud); // Set
baud rate

nTmp = nMode & 0x03;
if(nTmp == SERIAL_MODE_5BIT)
saveToLog(DEBUG, " SERIAL_MODE_5BIT");
if(nTmp == SERIAL_MODE_6BIT)
saveToLog(DEBUG, " SERIAL_MODE_6BIT");
if(nTmp == SERIAL_MODE_7BIT)
saveToLog(DEBUG, " SERIAL_MODE_7BIT");
if(nTmp == SERIAL_MODE_8BIT)
saveToLog(DEBUG, " SERIAL_MODE_8BIT");

nTmp = nMode & 0x04;
if(nTmp == SERIAL_MODE_1STOPBIT)
saveToLog(DEBUG, " SERIAL_MODE_1STOPBIT");
if(nTmp == SERIAL_MODE_2STOPBIT)
saveToLog(DEBUG, " SERIAL_MODE_2STOPBIT");

nTmp = nMode & 0x38;
if(nTmp == SERIAL_MODE_PARITY_NON)
saveToLog(DEBUG, " SERIAL_MODE_PARITY_NON");
if(nTmp == SERIAL_MODE_PARITY_ODD)
saveToLog(DEBUG, " SERIAL_MODE_PARITY_ODD");
if(nTmp == SERIAL_MODE_PARITY_EVEN)
saveToLog(DEBUG, " SERIAL_MODE_PARITY_EVEN");
if(nTmp == SERIAL_MODE_PARITY_MARK)
saveToLog(DEBUG, " SERIAL_MODE_PARITY_MARK");
if(nTmp == SERIAL_MODE_PARITY_SPACE)
saveToLog(DEBUG, " SERIAL_MODE_PARITY_SPACE");

nTmp = nMode & SERIAL_MODE_BREAK_CONTROL;
if(nTmp == SERIAL_MODE_BREAK_CONTROL)
saveToLog(DEBUG, " SERIAL_MODE_BREAK_CONTROL");
nTmp = nMode & SERIAL_MODE_ENABLE_DLR;
if(nTmp == SERIAL_MODE_ENABLE_DLR)
saveToLog(DEBUG, " SERIAL_MODE_ENABLE_DLR");

outp(nCom + 3, nMode);
outp(nCom + 2, 0xC7); // FIFO Control Register
saveToLog(DEBUG, "Turn off RTS.");
outp(nCom + 4, 0x0); // Turn off DTR, RTS, and OUT2

return SERIAL_OK;

}

void serialInterfaceSetBaudrate(int nCom, const int nBaud){
int nDivisor = 115200 / nBaud; // 0x1c200 / nBaud

// nDivisor defaults:
// ------------------
// 0x03 = 38,400 BPS
// 0x01 = 115,200 BPS
// 0x02 = 57,600 BPS
// 0x06 = 19,200 BPS
// 0x0C = 9,600 BPS
// 0x18 = 4,800 BPS
// 0x30 = 2,400 BPS
// 0x60 = 1,200 BPS

outp(nCom + 0, nDivisor); // Set Baud rate - Divisor
Latch Low Byte
outp(nCom + 1, 0x00); // Set Baud rate - Divisor
Latch High Byte

}

void serialInterfaceSendData(int nCom, char *cString, int nLen){
int i=0;
for(; i<nLen; i++){
outp(nCom + 0, cString);
}// end for

}

int serialInterfaceGetPort(int nComPort){
/**
* This functions get the adress for the port
*/
int nPort = 0;

switch(nComPort){
case 1:
nPort = 0x3F8;
break;
case 2:
nPort = 0x2F8;
break;
case 3:
nPort = 0x3E8;
break;
case 4:
nPort = 0x2E8;
break;
default:
return SERIAL_E_COMPORT_NOT_DEFINED;
}

printf("Return for %d comPort %d.\n", nComPort, nPort);

return nPort;

}

void serialInterfaceSendTelegram(int nCom, char cCommand, int nSensor)
{
/*
* This function sends a defined telegram over register 4
* to the sensor
*/

char cBuf[10];
char cChecksum;
char cTelegram[5];
int nLen;
int i = 0;

int c1, c2;

printf("Send Telegram for %d.\n", nCom);

// Build telegram data
cTelegram[0] = 'b';
cTelegram[1] = cCommand;
cTelegram[2] = nSensor + 48; // + '0'
cTelegram[3] = '\r';
cTelegram[4] = 0x0;

// Generate checksum
cChecksum = baseGenerateChecksum((char*) &cTelegram[0]);

// Data to send
strcpy(cBuf, cTelegram);
nLen = strlen(cTelegram);

cBuf[4] = cChecksum;
nLen++;
cBuf[5] = 0x0;
nLen++;

/*
* Send telegram to COM
*/
printf("Send telegram manually to OUT: %s\n", cBuf);
// printf("Telegram is %d characters long.\n",nLen);

// Open RTS
outp(nCom + 4, 0x0B); // Turn on RTS

for(i=0;i<nLen;i++){
// Send data
printf("Data %c\n.", cBuf);
outp(nCom + 0, cBuf);
}

// Close RTS
outp(nCom + 4, 0x0); // Turn off RTS

} // end function

char baseGenerateChecksum(const char *cTelegram){
int nChecksum = 0;
unsigned int i=0;

for(; i<strlen(cTelegram); i++) {
nChecksum = nChecksum ^ cTelegram; // Jedes Zeichen
mit XOR
verknüpfen
}

// Letztes Zeichen muss ein \r (ASCII 13) sein.
if(cTelegram[strlen(cTelegram) - 1] != '\r')
nChecksum = nChecksum ^ '\r';

nChecksum = nChecksum ^ 0xFF; // invertieren
nChecksum = nChecksum & 0x7F; // auf 7 Bit beschneiden
return (char) nChecksum;

 

[Michael Post]

Hello members,

......


is outp and inp the fastest way to communicate with the interface, or
other functions are faster?

Thanks for your help.

Michael

 

[kingfox]

.....

is outp and inp the fastest way to communicate with the interface, or
other functions are faster?

Thanks for your help.

Michael

I think the inp() and outp() function is the fastest way to access the
interface in C language. Else you can use assembly language to access
the interface. Sorry for can't give you more help because I forgot the
detail about the UART interface. But I think a program written by C
can send data through COMM port in PC at a rate more than 921600bps.
So, I think may be you should check whether the receiver return the
answer signal. May be you need a oscilloscope or a logic analyser to
help you debug this program.

 

[Walter Roberson]

i have a (time-(?))-problem with the serial-communication with an ms-
dos 6.2 and the rs232-interface with an rs485-adapter behind the
interface.

The standard C language only includes an fopen() function; if fopen()
is not sufficient to open the device conditioned to the right
communication parameters, then you will need to call upon system-
specific libraries that are beyond the scope of C.

To phrase this another way: what you have asked for cannot be done
in standard C, and you need to ask in a newsgroup specific to
your OS.

 

[Kenny McCormack]

The standard C language only includes an fopen() function; if fopen()
is not sufficient to open the device conditioned to the right
communication parameters, then you will need to call upon system-
specific libraries that are beyond the scope of C.

To phrase this another way: what you have asked for cannot be done
in standard C, and you need to ask in a newsgroup specific to
your OS.

To phrase this yet another way:

Nobody here gives a shit about you or your problems.

You may find some or all of the following links helpful in understanding
why this is so:

http://en.wikipedia.org/wiki/Aspergers
http://en.wikipedia.org/wiki/Clique
http://en.wikipedia.org/wiki/C_programming_language

 

[Carramba]

Kenny McCormack skrev:

To phrase this yet another way:

Nobody here gives a shit about you or your problems.

You made my day! haha haven't laughed that hard for some time...
Your evil-mindedness is funny ... but I still can't remember when I
started to appreciate good malice .. must since I started to read
comp.lang.c ...
and yes, I get it.. nobody gives a shit about it either...

 

[Christopher Benson-Manica]

Kenny McCormack skrev:

*Please* ignore Mr. McCormack. He is neither pleasant nor helpful.

 

[Kenny McCormack]

*Please* ignore Mr. McCormack. He is neither pleasant nor helpful.

Got ya on the run, don't I?

 

[Michael Post]

Hello,

thanks all for your very explained versions of answers.
Thanks espacially to Kingfox for his answer.

The rest of answers are very shitty. This group is called comp.lang.c
and noch comp.lang.ansi-c

I have a problem with c ... ok, seems like not being in the ansi-
standard, but i hoped for a qualified answer here at this mailinglist
and not this shit.

When someone does not want to answer me then he should not do it, but
not answer with this non-productive text, because i search for a
qualified answer for my question and no answer like " youre shit and
we don´t want to answer it, cause it is no ansi".

Now i spurn this list and will not ask anymore any questions or other
phrases.

This is my meening.

Thanks for your genial welcome.

Michael

 

[Michael Post]

Hello Walter,

.....

And Thanks for your answer, Walter.

Michael

 

[Dave Vandervies]

The rest of answers are very shitty. This group is called comp.lang.c
and noch comp.lang.ansi-c

I have a problem with c ... ok, seems like not being in the ansi-
standard, but i hoped for a qualified answer here at this mailinglist
and not this shit.

This newsgroup is also not called comp.lang.c.my-compiler. Perhaps if
you wanted help with something specific to your compiler, you should
have asked somewhere where your compiler is on-topic.


*plonk*


dave

 

[Andy]

Hello members,

i have a (time-(?))-problem with the serial-communication with an ms-
dos 6.2 and the rs232-interface with an rs485-adapter behind the
interface.

I program in C. As compiler, i am using Open Watcom to build a DOS 16-
bit executable.

When i send the telegram to the device, the device answers very fast
(<1 millisecond).
After complete sending, i set the rts to 0x0 and wait for the answer,
but i got no answer, or i am to slow.
Somewhere is the error.

Maybe someone has some ideas or can give me some tips for better
coding?

Make the serial receive routine interrupt driven.

 

[Peter Nilsson]

...This group is called comp.lang.c and noch comp.lang.ansi-c

Your lack of usenet etiquette is your problem to fix, not ours.

I have a problem with c ...

No, you have a problem with life and your sense of importance
in it.

 

[Kenny McCormack]

Your lack of usenet etiquette is your problem to fix, not ours.


No, you have a problem with life and your sense of importance
in it.

This being a sterling example of the kind, helpful, wonderful people
that clc is (allegedly) filled with.

 

[Old Wolf]

The rest of answers are very shitty. This group is called comp.lang.c
and noch comp.lang.ansi-c

What is 'noch' ?

Now i spurn this list and will not ask anymore any questions or other
phrases.

Oh noes!

 

[Michael Post]

Hallo Old Wolf,

What is 'noch' ?

Sorry. This is german. ;-) Translate it with nor.

Oh noes!

I am not interested in discussing about what it ansi and what not.
So for a beginner it is not so clear, what is ansi and what not.
And then the beginner turn to this mailinglist and got - till 3
messages of 14 - online messages in kind of " this is no ansi, this
are compiler specific (why?)" and so on.
That´s not really enjoyable.

Why i turn to a mailinglist when i get this messages?

Thanks for your help and sympathy.

Michael

 

[Richard Heathfield]

Michael Post said:

I am not interested in discussing about what it ansi and what not.

Then what are you doing here?

So for a beginner it is not so clear, what is ansi and what not.

That's one of the things this newsgroup can help with.

And then the beginner turn to this mailinglist

This is a newsgroup, not a mailinglist.

and got - till 3
messages of 14 - online messages in kind of " this is no ansi, this
are compiler specific (why?)" and so on.

Usenet is asynchronous. It is likely that most of those replies were
composed by people who had not yet seen the replies posted by other
people.

That´s not really enjoyable.

And that is our problem how, exactly?

Why i turn to a mailinglist when i get this messages?

I don't know why you would turn to a mailinglist, but if you're asking
"what is the point of comp.lang.c?", the answer is that it's a
newsgroup for discussing the C language, and there are quite a few C
experts posting here. If you want to discuss C, this is a fabulous
place to do it, although you might find it difficult to get people to
treat you seriously after your insulting behaviour in this thread.

But if you want to talk about MS-DOS, this is not the place. There are
other newsgroups for that - such as comp.os.msdos.programmer, for
example.

 

[Kenny McCormack]

I don't know why you would turn to a mailinglist, but if you're asking
"what is the point of comp.lang.c?", the answer is that it's a
newsgroup for discussing the C language, and there are quite a few C
experts posting here. If you want to discuss C, this is a fabulous
place to do it, although you might find it difficult to get people to
treat you seriously after your insulting behaviour in this thread.

And there you have it, gentlemen. What more evidence do you need?

 

[Walter Roberson]

I am not interested in discussing about what it ansi and what not.
So for a beginner it is not so clear, what is ansi and what not.
And then the beginner turn to this mailinglist and got - till 3
messages of 14 - online messages in kind of " this is no ansi, this
are compiler specific (why?)" and so on.
That=B4s not really enjoyable.

It turns out that (for good reasons) this is not the right newsgroup to
address your questions. That being the case, we had the choice of
either replying -saying- that it wasn't the right place, or of not
answering at all. Replying with the information you were hoping for was
not an option here because we don't know that information. If we had
not replied at all, then you would have been left waiting, not knowing
whether you were not going to get a reply because it was the wrong
place, or if you just had not received a reply yet because the person
with the answer just hadn't happened to read your question yet. (Some
of the regulars here only read the newsgroup every three to five
weeks.) Rather than leave you wondering, we replied as soon as
practical with a "We don't know; ask Fred over in Accounting" response,
freeing you up to persue the question elsewhere.

Taking into account that we don't know the answer here, how could we
have served you better? Should we have just left you wondering if you
were going to get an answer or not? I think you will agree that if we
didn't know the answer, that it was not reasonable to -expect- that we
would go off and research the answer and present it to you.


As for why this is not the right newsgroup to address your question:

Your question was not actually a question about C: instead, it was a
question about operating system interfaces. You planned to use C to
access those operating system interfaces, but those operating system
interfaces are available to any of a number of programming languages,
such as Fortran or Basic or Assembly. We cannot know everything about
every operating system interface or hardware interface that *could* be
accessed by a C program: as there are very few systems and libraries
that C -cannot- be used with, and very few programs that -cannot- be
written in C, that would make us responsible for knowing everything
about every kind of programming on practically every kind of computer.
The effect would be to expect us to know the answer to nearly any
question that could reasonably be asked in any comp.* newsgroup --
because, after all, whatever it was -could- have been implemented in C.

This may sound like an exaggeration, but people really do come by
comp.lang.c and expect us to be able to answer detailed questions
about networking, databases, encryption, compression, scientific
computing, artificial intelligence, security, C++, assembly on
microcontrollers, graphics, memory management techniques,
real-time programming, unix, general algorithms, complexity
analysis, and numerous other topics. If it has to do with programming,
someone will come by and ask about it sooner or later, whether there
is a C connection or not

 

[Default User]

Hello,

thanks all for your very explained versions of answers.
Thanks espacially to Kingfox for his answer.

The rest of answers are very shitty. This group is called comp.lang.c
and noch comp.lang.ansi-c

*plonk*




Brian