program needs updating, how

[talktwo]

I have an old program that needs to be updated, but I need to know what it is doing in the first place. Bought book The C programming language by Kernighan & Ritchie, but still need help. Here is the program:
#include<dos.h>
#include<stdio.h>

#define IER 1
#define MCR 4
#define DTR 1
#define RTS 2
#define LSR 5
#define RCVRDY 1
#define RX 0

#define OVRERR 2
#define PRTYERR 4
#define FRMERR 8

int portbase = 0x2f8

main()
{

FILE *handle;
register unsigned long i, j = OL;
/* I do not understand the j = OL */
register int c = 0, inpstat;
register int a[340];

outportb(portbase + IER, 0};
outportb(portbase + MCR, DTR | RTS;
/* I need help on both the above lines examples? */

handle = fopen(&quot;SAMPLE.DAT&quot;,&quot;w&quot;

for(i=OL;i<17*7500;i++)
(
if(j >= 340) break;

instat = inportb(portbase + LSR);
if(inpstat & RCVRDY)
/*The bitwise & is confusing, help */
{
c = inportb(portbase + RX);

if(inpstat & (OVRERR | PRTYERR | FRMERR))
/*This line with & and | looses me totally */
{
printf(&quot;\b&quot;
c = -1;
}

}
else
{
c = -1;
}

if( c != -1)
{
a[j] = c;
j++;
}
}
for(i=OL;i<j;i++)
/* What is the i=OL and does it have a value? */
{
fputc(a, handle);
}
fclose(handle);
}

The data comes into this program on com2 9600 baud, even parity, 7 data bits, 2 stop bits, if you could give an example of what is happening, I would greatly appreciate.
A stream of data from breakout (black box) looks like this
(02)* 0025 0000(0D)(00)
Thanks!

 

[SamBones]

I'll try to answer the individual questions.

First, there seems to be a lot of typos in the code. There are missing parens and other odd things that look like just typos.

The OL, should actually be a zero and a lower case &quot;L&quot;. It should be [tt]0l[/tt]. This is the value zero, but as a long int, not a short int.

The bitwise & and | are because the program is setting and testing bit positions. The & is to test if a bit is set.

For example, OVRERR, PRTYERR, and FRMERR are set to 2, 4, and 8 respectively. This corresponds to 00000010, 00000100, and 00001000 (shortened to one byte so I don't have to type so much. So, to test if [tt]inpstat[/tt] has the OVRERR bit set, you would code...
[tt]
if ( inpstat & OVRERR )
[/tt]
Just remember that in an if statement, zero equals false and anything non-zero is true. So, if that bit is set in inpstat, then the result of the bitwise and is non-zero and the if condition it TRUE. This is how you test a single bit without regard to any other bits.

Now the bitwise or, is for turning on bits. That is, the construct of [tt](OVRERR | PRTYERR | FRMERR)[/tt] results in 00001110. So, doing the bitwise and with this and inpstat is testing to see if any one of these three bits is set. If it is, the if is TRUE.

The line [tt]outportb(portbase + MCR, DTR | RTS);[/tt] is to output something to an i/o port (serial port?). What is being output is a byte with the value 3 (or 00000011 which is (DTR|RTS)). DTR is Data Terminal Ready and RTS is Request To Send. This sets some signals on the serial port to let whatever's connected to it know that we're ready to communicate.

Hope this helps.

 

[lionelhill]

just a tiny comment: if you were wondering why your code burst into italics, it's because you had an array subscript &quot;i&quot; in square brackets. Unfortunately the TGML mark-up language this message forum uses interprets that as &quot;italic&quot;, and the same thing with a back-slash as &quot;italic off&quot;. If you're posting code with subscript i, consider un-ticking the process tgml box...
(took me ages to realise that one, till some nice person told me)

 

[talktwo]

Thank you so much for your good answers. I spent some time trying to follow this program, still having problems as I cannot follow how the input gets to the output. The input is continous from serial port in this format.
1 2 3 4 5 6 7 8 9 10 11 12131415 16 17 18
S S S S M weight L M WEIGHT L C C
T T T T S VALUE S S VALUE S A H
A A A A D D D D R E
R T T T R C
T U U U I K
A S
O W W W G U
F O O O E M
R R R
T D D D R
E E
X A B C T
T U
R
N

Status word ABC are not transmitted in continuous mode only weight data. If a flow chart on the code is possible, would appreciate it otherwise will need to find a c programmer to help as this is hard. Thanks in advance

 

[SamBones]

Well, in short it appears to be reading characters from a serial port, into the array a[], to a maximum of 340 characters, then it writes it to a file called SAMPLE.DAT.

What kind of device is connected to the serial port?

 

[talktwo]

A model 8142 toledo scales is hooked to computer through com2 port rs232 cable. This program reads the weight from the scales and writes into the SAMPLE.DAT file, then another program written in Foxpro takes the raw data from SAMPLE.DAT and uses it. The original c program & foxpro program was written by the same person, who left, whereabouts unknown. Our new foxpro programmer tried to collect the raw data from scales using foxpro, did not work. Cannot upgrade unless we know how to read c program. The info above was straight on my screen, not now. #10 is LSD #11 MSD #16 LSD #17 carriage return #18 checksum The weight values are in 6-9 and 12-15 Thanks for help!!

 

[palbano]

First some background.

Several years ago i wrote ActiveX controls for toledo scales (don't know the model). The ActiveX controls where used in MS Access and VB applications to read weights from the scales. No intermediate files were involved.

Now i re-read all your posts and do not see where you explain what has changed resulting in the need to upgrade any of your existing code ( C or Foxpro ).

-pete

 

[talktwo]

We have another location that has a toledo model 8806 scales and when we try to sample the data, the SAMPLE.DAT Data flow writes [] 000042LG (first one is square then space) 19 times and takes too much time. We want to be able to change the c program to fit the i/o data so our foxpro program can read it. If we have our program above documented where someone can change it, then we can adjust to read whatever scales we put in. We did get all the original foxpro documentation and code, but did not realize this c was between. Important piece!

gc

 

[palbano]

The two outportb calls probably write a single byte to the two ports the first one writes a byte value zero to port 0x2f8 + 1

The second writes a byte value of 3 to port 0x2f8 + 4

This probably initializes the scale and tells it to begin sending output.

I’m not sure but “OL” probably is a character error that should be Zero instead of an uppercase ‘o’ which just makes it Zero cast to a “long” type.

Then there is a loop of 17*7500 hopefully this value came from the teledo documentation otherwise it is specific to the developers environment at the time and could now be completely bogus.

Then the loop appears to have a second break condition which is when 340 bytes have been read and stored in the array “a” which is of course written to the output file

Now here is the psuedo code

Read a byte from 0x2f8 + 5
IF it has the least significant bit set
Read a byte from 0x2f8
IF these bits ( 00001110 ) are NOT set
Set the j element of array ‘a’ to the byte read and…
Encrement j
ENDIF
ENDIF

my experience with scales is that each one can use a completely different method of sending output. It is possible that this code my not work at all for different model scales. You must read the scales documentation to determine how to control the scale and interpret it's output.

Hope that helps
-pete

 

[lionelhill]

You are trying to use a serial port in a dos environment. This is really not trivial but there is masses of information on the web, pages and pages.

IER is the interrupt enable register,
MCR the modem control register etc. etc.
DTR data transfer register
LSR line status register.
The bitwise and is simply that the port control hardware will return a set bit if there is a byte of data waiting for collection. The AND is to mask off the other bits when testing whether an input is waiting for you.

All these various registers need to be handled correctly if you are to get data from your scales.

The (slightly) good news is that your application is not interrupt driven, so it simply seems to look at the port continuously, easier to handle. But interrupt driven servicing of the port is more reliable, because it has virtually no buffer space, so if your computer is off doing something else (fiddling about with its disk drives or whatever), then it will miss data.

Really, I have greatest sympathy with you on this one. I can't offer any practical help because my own attempt to talk to a microtitre plate reader in DOS via a serial port ended in admission I hadn't the time to plough through any more of this and it was time to move windows-wards. The frustration was that following the web-searched instructions didn't always yield the result I expected. I have suspicions not all computers behave the way they should according to literature (even in the web-searching there was much muttering of how different chipsets behave differently).


Good luck.