|
Make sure IPv6 didn't get installed somehow... Aside from that power down the box and reseat the card perhaps even try a different slot for it.
I've seen similar problems that had no plausible explanation and moving stuff around fixed things up. You could start doing things like "ping -t www.google.com" and record how often the connection is dropping. If it's on 20 seconds and every 20 seconds then you have some clues. If it's very random with no visible pattern then no joy there.
One thing you might attempt is getting a small portable router and just plug it into the router and see if it will hold a connection. If that works you know it isn't on the server. Somehow you need to isolate the problem to one of the 3 main areas (Switch, Cables, Server). If you can remove two of the variables then boring into the one remaining becomes easier.
I can definitely agree with pbraun that when you see that notice it often does mean a poor or faulty connection somewhere. How to determine where/if is a PITA but...
Without more information I'm not sure what else to tell you. You could get a KNOPPIX bootable CD/DVD and boot into it and see if KNOPPIX or a similar product (BartPE) can get and hold a network connection. This would tell you if it's software or hardware and booting KNOPPIX/BartPE is much easier than reloading the OS.
- Rex
|
|
|
|
|
|
Yeah, going off what you are saying I bet SP4 fixes the problem. I'd be very surprised if it didn't.
|
|
|
|
|
I darn well hope so. It's 50% downloaded now 
modified 18-Jul-18 11:59am.
|
|
|
|
|
Argh. Just installed SP4 - you guessed it, no change.... 
This really sucks. I don't think there's a newer driver to be found as the hardware is really old.
NT4 worked - maybe I'll have to go back to using that, but unfortunately that's quite a bit less usable in this situation...
modified 18-Jul-18 11:59am.
|
|
|
|
|
Who's the card manufacturer? I'm not buying that you cannot run Windows 2000 on it. It's the release right after NT 4.0 so it works somehow.
Try deleting the card from the device manager (uninstall it) reboot and let Windows auto-detect a new updated driver for it.
|
|
|
|
|
code-frog wrote: Try deleting the card from the device manager (uninstall it) reboot and let Windows auto-detect a new updated driver for it.
Had already tried that, for the formality I tried again; no go 
I am considering trying XP for interest sake, though probably the supplied driver is the same... Don't really know what else to do as NT4 isn't really an option (possibly at a push) but as you say, I agree, I also refuse to believe it won't work.
It's a Compaq Netelligent 10/100TX PCI Embedded UTP controller (one of those with AUI port).
modified 18-Jul-18 11:59am.
|
|
|
|
|
If that's a bundled server that came from Compaq then if you went to the Compaq site (now hp.com) you would find the right drivers just by typing in the name of the server in the Software Download section. If you can't then I'm betting if you Google "Compaq Netelligent 10/100 PCI UTP Windows 2000" you'd get good hits.
|
|
|
|
|
I had indeed already looked at hp.com (and google) (same link as you gave). The driver they had corresponded (nearly - build incremented from 18 to 22) with the one I got off the SmartStart cd for servers which is the newest version applicable to the 1200 series.
Version 5.0.1.22C now installed. No difference.
modified 18-Jul-18 11:59am.
|
|
|
|
|
|
I've seen this plenty of times and field service often told me this was happening.
This issue is not a software problem, it is a hardware problem. The trouble is that the wires are not maintaining a connection to your card. How to diagnose is to grab the cable physically and wiggle it into a position where it remains connected. The solutions are to get a cable that fits properly and stays connected, or to replace the network cable or network card.
Phil
|
|
|
|
|
Sounds plausible, except before the format today the same server worked perfectly (this morning still) with the same network cable etc. The server also hasn't moved since the format. The only change is the OS.
Have in the mean time tried a different (known working) cable with no effect unfortunately.
modified 18-Jul-18 11:59am.
|
|
|
|
|
Was the driver reverted to a previous version that had problems? Is there an update for the driver that you should install?
Phil
|
|
|
|
|
Both the standard Windows 2000 driver and the updated drivers off the Compaq SmartStart disc have the same problem.
As a side note, I've reformatted the computer a second time and installed Win2k again in case that would help a phantom error, but this also hasn't helped...
Thanks anyway for the suggestions so far. Is there anything you can think of that I may have missed?
modified 18-Jul-18 11:59am.
|
|
|
|
|
The latest Service Pack for Windows 2000...?
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
Unfortunately that didn't help. Thanks anyway 
modified 18-Jul-18 11:59am.
|
|
|
|
|
Network cards have been known to go bad on occasion. It doesn't matter if they were previously running well.
Would it be possible to replace the card with an identical one? Have you tried using a different port on the switch or router?
Isolating the problem is always the hardest part of trouble shooting.
Phil
|
|
|
|
|
Unfortunately the card is on-board, and I don't have a spare PCI card lying around. If not solved soon I might indeed look into just swapping the card.
The router seems to be in perfect order as my other PC can talk to it on that port/cable.
modified 18-Jul-18 11:59am.
|
|
|
|
|
Not the network card.
Works perfectly like it used to under Knoppix, with the same cables/port/physical config.
Argh. Back to the drawing board 
modified 18-Jul-18 11:59am.
|
|
|
|
|
Most likely autosensing of connection speed and duplexing has stopped working. I find that this feature flat out does not work properly, regularly going into autosense when not necessary, and quite frequently never actually completing the autodetect process.
Go into the device's settings in Device Manager and, on the Advanced tab, force the speed to 100Mbps and Full duplexing. Do this for all devices on your network that will allow this.
|
|
|
|
|
I also thought of that indeed, unfortunately it didn't help.
Now I'm battling another connection problem on a different computer... Looking similar... I wonder if the switch isn't somehow involved
Thing is though, if I connect the two unfriendly pc's with a cross-over cable the problems persist over reboots...
modified 18-Jul-18 11:59am.
|
|
|
|
|
Remove the one computer (not the server, the other one) from the network entirely. Reboot the router/switch and server then see how things go. You have to break this into the affected area and you do that by isolating away hardware. Get your variables down as small as you can, get that other machine off the network post-haste and then see how you are doing.
|
|
|
|
|
The basic objective of the project is to capture the image data from a camera sensor chip & sent to a microcontroller (after all the pixels in a single frame has been captured). It is then stored in a flash memory for display. The image data is stored in the form of a bitmap image. It is then later displayed on the computer screen.
The microcontroller selected for the project is ATMEL’s AT89C51ED2. The package used is VQFP64. AT89C51ED2 is a high performance CMOS flash version of 8051. It has 256Bytes of internal RAM, a 9-source 4-level interrupt controller and three timers/counters. It also has 2048 Bytes of EEPROM. It has a programmable counter array, an XRAM of 1792Bytes, a hardware watchdog timer, SPI interface, keyboard, a capability of multiprocessor communication(EUART), a speed improvement system(X2 Mode). It contains 64KByte flash memory block for code & data. This flash memory can be programmed either in parallel mode or serial mode with ISP capability or with software.
The sensor used to capture image data from external environment is MICRON’s 1/2-Inch Mega pixel CMOS Digital Image Sensor named MT9M001C12STM (Monochrome). The package used is 48-Pin CLCC. The Micron® Imaging MT9M001 is an SXGA-format with a 1/2-inch CMOS active-pixel digital image sensor. It has an active imaging pixel array of 1,280H x 1,024V (1,310,720 active pixels). So, it has a total of 1,374,976 pixels (incl. dark pixels i.e. 1,312H x 1,048V). It incorporates sophisticated camera functions on-chip such as windowing, column and row skip mode, and snapshot mode. It is programmable through a simple two-wire serial interface. It also has a programmable frame rate of 30 fps (progressive scan). It also has Electronic rolling shutter. The sensor can be operated in its default mode or programmed by the user for frame size, exposure, gain setting, and other parameters. The default mode outputs an SXGA-size image at 30 frames per second (fps). An on-chip analog-to-digital converter (ADC) provides 10Bits per pixel. FRAME_VALID and LINE_VALID signals are output on dedicated pins, along with a pixel clock that is synchronous with valid data.
The image is stored in the bitmap format. The resolution can be changed using the header in the image. Finally, a C program is written that can display the required frame as the output.
But we have some errors in the code the following are the codes:
1.THE ASSEMBLY LANGUAGE CODES
The first code that was developed was aimed to verify the validity of the PCB design. This program had a subroutine which would start the timer on the 4 pin of the sensor connector. The code was as follows:
PROGRAM 1:
ORG 0000H
LCALL START_T2CLK
START_T2CLK:
MOV 20H, 0C9H
SETB 01H ; PROGRAM T2 AS CLK OUTPUT MODE
MOV 0C9H, 20H
MOV 20H, 0C8H
CLR 01H ; SETTING T2 IN TIMER MODE
MOV 0C8H, 20H
MOV 0CBH, #0FFH ; LOADING RELOAD VALUE INTO
MOV 0CAH, #0FBH ; RCAPH2 & RCAPL2 REGISTERS
MOV 0CDH, #0FFH ; LOADING RELOAD VALUE INTO
MOV 0CCH, #0FBH ; TH2 & TL2 REGISTERS
MOV 20H, 0C8H
JB 02H, OVR_T2CLK
SETB 02H ; STARTING TIMER2
OVR_T2CLK:
MOV 0C8H, 20H
RET
In this program, the reload value is loaded into the RCAPH2 & RCAPL2 registers, having the address 0CBH and 0CAH. They are the timer/counter2 reload/capture high and low byte registers respectively. Similarly, the value is loaded into the TH2 and TL2 registers. After dumping this program into the microcontroller, the output waveform can be verified on the 4th pin. It should show an almost perfect square wave of 1MHz frequency. Once this waveform is observed on the screen of the CRO, it can be confirmed that the sensor has been connected correctly.
Once the validity has been verified, the data from the sensor must be acquired. The program given below acquires the data from the sensor.
PROGRAM 2:
ORG 0000H
LCALL START_T2CLK ; CALLING THE TIMER SUBROUTINE
MOV R7, #0FFH
MOV DPTR, #2000H ; LOADING THE MEMORY ADDRESS
INC 0A2H ; TO ACTIVATE THE SECOND DPTR
MOV DPTR, #0F500H
CLR 0B4H
WAIT_DATAVALID:
JNB 91H, WAIT_DATAVALID
MOVX A,@DPTR ; LOADING THE SENSOR DATA INTO ACC
INC 0A2H
MOVX @DPTR, A
INC DPTR
INC 0A2H
DJNZ R7, WAIT_DATAVALID
STOP : SJMP STOP
; ROUTINE TO PROGRAM TIMER2 AS CLOCK-OUT MODE
; CLK FREQUENCY = KHz
START_T2CLK:
MOV 20H, 0C9H
SETB 01H ; PROGRAM T2 AS CLK OUTPUT MODE
MOV 0C9H, 20H
MOV 20H, 0C8H
CLR 01H ; SETTING T2 IN TIMER MODE
MOV 0C8H, 20H
MOV 0CBH, #0FFH ; LOADING RELOAD VALUE INTO
MOV 0CAH, #0FBH ; RCAPH2 & RCAPL2 REGISTERS
MOV 0CDH, #0FFH ; LOADING RELOAD VALUE INTO
MOV 0CCH, #0FBH ; TH2 & TL2 REGISTERS
MOV 20H, 0C8H
JB 02H, OVR_T2CLK
SETB 02H ; STARTING TIMER2
OVR_T2CLK:
MOV 0C8H, 20H
RET
In this program, we are using the concept of Dual Pointers. In one of the pointer we are loading the external data memory address from where we are going to dump our program. By incrementing the AUXR register, we are selecting the second DPTR. Into this, we are sending the address of the decoder to the microcontroller. Then we check for the valid data. The data is not valid until the data_valid line is high. As the R7 register has 256 in it, it will confirm that data_valid become high at least once before 256 loops. Data acquisition can be verified on the pins of the sensor jumper and also on the data pins of the buffer 74HC373.
Theoretical calculations to read and store one pixel in XRAM:
JNB 91H, WAIT_DATAVALID – 2 machine cycle
MOVX A,@DPTR – 2 machine cycle
INC 0A2H – 1 machine cycle
MOVX @DPTR, A – 2 machine cycle
INC DPTR – 1 machine cycle
INC 0A2H – 1 machine cycle
DJNZ R7, WAIT_DATAVALID – 2 machine cycle
Total number of machine instructions for that routine = 11
Total time = 11x 12 (since 1 machine cycle = 6 clock periods)
Frequency of the microcontroller = 40MHz
Time to read & store 1 pixel is 132/40MHz = 3.3µsec (~4µsec)
The next program to be developed was to check the number of pixels that are being captured from the sensor, by the microcontroller.
PROGRAM 3:
ORG 0000H
LCALL START_T2CLK
MOV R7, #0FFH
MOV DPTR, #2000H
INC 0A2H
MOV DPTR, #0F500H
CLR 0B4H
TEST:
JNB 0B5H, DEBUG
WAIT_DATAVALID:
JNB 91H, WAIT_DATAVALID
MOVX A,@DPTR
INC 0A2H
MOVX @DPTR, A
INC DPTR
INC 0A2H
DJNZ R7, WAIT_DATAVALID
DEBUG:
CJNE R7, #0FH, AHEAD
STOP: SJMP STOP
AHEAD:
MOV A, R7
CLR C
SUBB A, #0FH
JC AHEAD1
CLR 0B2H
RET
AHEAD1:
CLR 0B3H
JMP STOP
; ROUTINE TO PROGRAM TIMER2 AS CLOCK-OUT MODE
; CLK FREQUENCY = KHz
START_T2CLK:
MOV 20H, 0C9H
SETB 01H ; PROGRAM T2 AS CLK OUTPUT MODE
MOV 0C9H, 20H
MOV 20H, 0C8H
CLR 01H ; SETTING T2 IN TIMER MODE
MOV 0C8H, 20H
MOV 0CBH, #0FFH ; LOADING RELOAD VALUE INTO
MOV 0CAH, #0FBH ; RCAPH2 & RCAPL2 REGISTERS
MOV 0CDH, #0FFH ; LOADING RELOAD VALUE INTO
MOV 0CCH, #0FBH ; TH2 & TL2 REGISTERS
MOV 20H, 0C8H
JB 02H, OVR_T2CLK
SETB 02H ; STARTING TIMER2
OVR_T2CLK:
MOV 0C8H, 20H
RET
This routine counts the number of pixels that are being read. The logic is that register R7 is given a value of 256. Whenever the data_valid becomes high then the execution comes out of the wait_datavalid. At that time the value of the R7 will definitely not be 256. It is then compared with different values (stored in Accumulator) to conclude the number of pixels. In this routine, we use the free port pins as debug points. Two such free pins are 0B2 and 0B3, i.e. 2nd and 3rd (beginning from 0) pins of port 3. In this program, we have written the loop such that: the value of the R7 register is stored in the Accumulator after coming out of the wait_datavalid. A hexadecimal value of 0FH is subtracted from it. If carry is generated, then P3.3 is cleared else P3.2 is cleared. This is cleared because if the pins of the ports are not connected then they are in logic “high” state. So, after dumping the program in to the microcontroller, we must check the port pins externally to know the value of the R7. After actually checking the debug points, we derived that the number of pixels read is 256.
Next, we developed a code to verify the total number of pixels (rows x columns). It is similar to the above program, except that the line _valid is also brought into the picture. Its value is high during the line of validated pixels data.
PROGRAM 4:
ORG 0000H
LCALL START_T2CLK
MOV R7, #0FFH
MOV R4, #0FFH
MOV DPTR, #2000H
INC 0A2H
MOV DPTR, #0F500H
CLR 0B4H
WAIT_DATAVALID:
JNB 91H, WAIT_DATAVALID
MOVX A,@DPTR
INC 0A2H
MOVX @DPTR, A
INC DPTR
INC 0A2H
DJNZ R7, WAIT_DATAVALID
WAIT_LNVALID:
JNB 0B5H, WAIT_LNVALID
MOV R7, #0FFH
DJNZ R4, WAIT_DATAVALID
CJNE R4, #00H, AHEAD
STOP: SJMP STOP
AHEAD: MOV A, R4
CLR C
SUBB A, #00H
JC AHEAD1
CLR 0B2H
RET
AHEAD1:
CLR 0B3H
JMP STOP
; ROUTINE TO PROGRAM TIMER2 AS CLOCK-OUT MODE
; CLK FREQUENCY = KHz
START_T2CLK:
MOV 20H, 0C9H
SETB 01H ; PROGRAM T2 AS CLK OUTPUT MODE
MOV 0C9H, 20H
MOV 20H, 0C8H
CLR 01H ; SETTING T2 IN TIMER MODE
MOV 0C8H, 20H
MOV 0CBH, #0FFH ; LOADING RELOAD VALUE INTO
MOV 0CAH, #0FBH ; RCAPH2 & RCAPL2 REGISTERS
MOV 0CDH, #0FFH ; LOADING RELOAD VALUE INTO
MOV 0CCH, #0FBH ; TH2 & TL2 REGISTERS
MOV 20H, 0C8H
JB 02H, OVR_T2CLK
SETB 02H ; STARTING TIMER2
OVR_T2CLK:
MOV 0C8H, 20H
RET
Note: The data validity has also been confirmed, (with the CMOS sensor connected) on a CRO monitor, with the probe at the data pins of the CMOS sensor and also at the buffer pins. The waveform obtained for the data with the sensor exposed is exactly opposite to the data obtained with the sensor covered.
Once the number of pixels has been found, the next stage is to store the sensor data somewhere, so that later it can be transmitted. The most suitable option was to use the FLASH memory of the microcontroller. Its capacity is 64Kbytes.
PROGRAM 5:
ORG 0000H
LCALL START_T2CLK
MOV R7, #0FFH
MOV R4, #0FFH
MOV DPTR, #1000H
INC 0A2H
MOV DPTR, #0F500H
CLR 0B4H
WAIT_DATAVALID:
JNB 91H, WAIT_DATAVALID
LCALL WRITE_FLASH
INC 0A2H
INC DPTR
DJNZ R7, WAIT_DATAVALID
STOP : SJMP STOP
; ROUTINE TO PROGRAM TIMER2 AS CLOCK-OUT MODE
; CLK FREQUENCY = KHz
START_T2CLK:
MOV 20H, 0C9H
SETB 01H ; PROGRAM T2 AS CLK OUTPUT MODE
MOV 0C9H, 20H
MOV 20H, 0C8H
CLR 01H ; SETTING T2 IN TIMER MODE
MOV 0C8H, 20H
MOV 0CBH, #0FFH ; LOADING RELOAD VALUE INTO
MOV 0CAH, #0FBH ; RCAPH2 & RCAPL2 REGISTERS
MOV 0CDH, #0FFH ; LOADING RELOAD VALUE INTO
MOV 0CCH, #0FBH ; TH2 & TL2 REGISTERS
MOV 20H, 0C8H
JB 02H, OVR_T2CLK
SETB 02H ; STARTING TIMER2
OVR_T2CLK:
MOV 0C8H, 20H
RET
WRITE_FLASH: ; SUB ROUTINE TO WRITE DATA INTO FLASH
PUSH 01H
MOV R2, #02H
MOV 20H, 0A2H
SETB 05H
MOV 0A2H, 20H
LCALL 0FFF0H
MOV 20H, 0A2H
CLR 05H
MOV 0A2H, 20H
POP 01H
RET
The program reads the data from the sensor and writes it into flash. Here again we used the concept of DUAL DPTR. One of the DPTR has the flash address while the other has the sensors address. The problem faced here was that, the microcontroller receives one row of pixel data in 1ms. The flash sub routine takes about 1.3ms to write one pixel into the flash. As the result the number of pixels written into the flash is very few. Thus the final frame obtained would not be recognizable. So, the need for a faster storage memory was apparent. The next option for writing the data from the sensor is into XRAM. Its capacity was 768 Bytes (default). It was programmed to 1792 Bytes using the AUXR register. To write the data into the XRAM, the XRAM bit in the AUXR register must be cleared. The program is as follows:
PROGRAM 6:
ORG 0000H
LCALL START_T2CLK
MOV 20H, 11H
MOV 8EH, 20H
MOV R7, #0FFH
MOV R4, #07H
MOV DPTR, #0300H
INC 0A2H
MOV DPTR, #0F500H
CLR 0B4H
WAIT_DATAVALID:
JNB 91H, WAIT_DATAVALID
INC DPTR
MOVX A,@DPTR
INC 0A2H
MOVX @DPTR, A
INC DPTR
DJNZ R7, WAIT_DATAVALID
STOP : SJMP STOP
; ROUTINE TO PROGRAM TIMER2 AS CLOCK-OUT MODE
; CLK FREQUENCY = KHz
START_T2CLK:
MOV 20H, 0C9H
SETB 01H ; PROGRAM T2 AS CLK OUTPUT MODE
MOV 0C9H, 20H
MOV 20H, 0C8H
CLR 01H ; SETTING T2 IN TIMER MODE
MOV 0C8H, 20H
MOV 0CBH, #0FFH ; LOADING RELOAD VALUE INTO
MOV 0CAH, #0FBH ; RCAPH2 & RCAPL2 REGISTERS
MOV 0CDH, #0FFH ; LOADING RELOAD VALUE INTO
MOV 0CCH, #0FBH ; TH2 & TL2 REGISTERS
MOV 20H, 0C8H
JB 02H, OVR_T2CLK
SETB 02H ; STARTING TIMER2
OVR_T2CLK:
MOV 0C8H, 20H
RET
The 8EH register is the auxiliary register. It is not bit addressable. So, the alternative is to use a bit addressable register. To check if the data is being written into the XRAM, we can verify by copying it from the XRAM to the flash. Into the XRAM, only 7 rows of 256 pixels each can be written. Loop must be written to read the whole frame.
DISTUISHING THE XRAM FROM THE FLASH:
There are two blocks of internal memory XRAM and flash. And accessing these memories should be done by using DPTR but how could the controller know whether, it is the XRAM or the flash that is being accessed. Depending on the instructions, the microcontroller will know whether it is XRAM or flash. For example, if we want to write a data to XRAM then this can be done by using MOVX instruction and whatever address is there in DPTR at that instant that address will be taken. Bytes greater than 1792 can’t be accessed in XRAM. And for writing data into flash a routine has to be called. While doing so, whatever address is there in the DPTR when the being called, the data will be written to that address.
One last program was developed to verify the functioning of the XRAM. A general data apart from that of the sensor was stored in the accumulator and the address of the XRAM was given. The data was written into the XRAM. This was verified by transmitting the data from the XRAM to the PC via serial communication.
PROGRAM 7:
ORG 0000H
MOV R7, #0FFH
MOV R4, #07H
MOV DPTR, #1000H
NOP
NOP
NOP
NOP
NOP
MAIN:
MOV 81H, #50H
LCALL TXT_INI
LCALL INIT
LCALL DELAY
MOV DPTR, #1000H
AGA:
LCALL TX_DATA
SJMP AGA
LCALL DELAY
LCALL DIGIT_14
LCALL COUNT
LCALL DELAY
MOV DPTR, #BYTE_7
MOV R2, #7
LCALL TX_DATA
STAY: SJMP STAY
; TXT INITIALIZATION
TXT_INI:
CLR 0AFH
CLR 8EH
CLR 8CH
CLR 0A9H
MOV 98H, #52H ; REN = 1 TI =1, MODE 2
MOV 89H, #20H ; TIMER 1 AUTO RELOAD
MOV 8DH, #0F5H ; 9600 BAUD WITH 20MHz.CRYSTAL
SETB 8EH ; START TIMER 1
RET
INIT: MOV DPTR, #BYTE_7
MOV R2, #7
RET
DELAY: MOV R4, #0FFH
DELAY2: MOV R5, #0FH
DELAY1: DJNZ R5, DELAY1
DJNZ R4, DELAY2
RET
DIGIT_14:
MOV A, #0
MOVC A,@A+DPTR
CLR 99H
MOV 99H, A
HERE: JNB 99H, HERE
INC DPTR
LCALL DELAY
DJNZ R2, DIGIT_14
RET
COUNT:
CLR 99H
JNB 99H, COUNT
MOV A, 99H
MOV R3, A
CLR 99H
MOV DPTR, #BUFFER
RET
TX_DATA: MOV A, #76H
CLR 99H
MOV 99H, A
WAIT_TDATA: JNB 99H, WAIT_TDATA
INC DPTR
LCALL DELAY
RET
BUFFER: DS 255
BYTE_7: DB 11H,22H,33H,44H,55H,63H,00H
; ROUTINE TO PROGRAM TIMER2 AS CLOCK-OUT MODE
; CLK FREQUENCY = KHz
START_T2CLK:
MOV 20H, 0C9H
SETB 01H ; PROGRAM T2 AS CLK OUTPUT MODE
MOV 0C9H, 20H
MOV 20H, 0C8H
CLR 01H ; SETTING T2 IN TIMER MODE
MOV 0C8H, 20H
MOV 0CBH, #0FFH ; LOADING RELOAD VALUE INTO
MOV 0CAH, #0FBH ; RCAPH2 & RCAPL2 REGISTERS
MOV 0CDH, #0FFH ; LOADING RELOAD VALUE INTO
MOV 0CCH, #0FBH ; TH2 & TL2 REGISTERS
MOV 20H, 0C8H
JB 02H, OVR_T2CLK
SETB 02H ; STARTING TIMER2
OVR_T2CLK:
MOV 0C8H, 20H
RET
After the data has been written into a memory, the next step is to check for the transmission, communication of the data from the microcontroller to the PC. To do that a code was developed:
PROGRAM 8:
ORG 0000H
LCALL SET_BAUDRATE
MOV A, 11H
TX_DATA:
CLR 99H
MOV 99H, A
TRANSMIT_DATA:
JNB 99H, TRANSMIT_DATA
CLR 0B3H
STOP: SJMP STOP
SET_BAUDRATE: ; 9600 BAUD RATE ON 20MHz
MOV 20H, 9BH ; READING BAUDRATE CTRL REG (9BH)
SETB 02H ; SETTING INTERNAL BAUDRATE GENERATOR
SETB 03H ; FOR TX & RX
SETB 01H ; SETTING SPEED BAUDRATE GENERATOR
MOV 9BH, 20H
MOV R0, 9AH
MOV R0, #07EH ; LOADING 220 IN BUADRATE RELOAD REGISTER
MOV 9AH, R0
MOV 20H, 87H
CLR 07H
MOV 87H, 20H
MOV 20H, 9BH
SETB 04H ; SETTING BAUDRATE RUN CTRL BIT
MOV 9BH, 20H
RET
In this routine we are setting the baud rate for the transmission of data from the PC to the microcontroller. It is done by selecting the baud rate as earlier discussed, via internal baud rate generator. The formula used is:
By using this formula, we tried to do the communication from the microcontroller to the PC. When the microcontroller transmits the data to the PC, the PC must be able to capture it. For this, we developed a code in “C” language. This program uses predefined functions as BIOSCOM used for serial communication.
/*program to accept the data transmitted by the microcontroller via serial communication*/
#include <bios.h>
#include <time.h>
#include <math.h>
#include <conio.h>
#include <stdlib.h>
#include <stdio.h>
#include <dos.h>
#include <string.h>
#define COM1 0
#define COM1_ADD 0x3F8
#define COM2 1
#define COM2_ADD 0x2F8
#define THRE 0x2000
#define DATA_READY 0x100
#define SETTINGS (0x0C0 | 0x00| 0x00 | 0x03)
/* 9600 BAUD RATE, NO PARITY, 1 STOP BIT, 8 DATA BITS*/
int status, i, j, COM_ADD, COM;
unsigned char c;
unsigned char in_data()
{
unsigned char ch;
int a;
FILE *fpr;
fpr=fopen("c:\\out.txt","w");
for(;;)
{
status=bioscom(3,0,COM);
if (status&DATA_READY)
{
ch=inportb(COM_ADD);
printf("%X ", ch);
a=(int)ch;
// printf("%d ",a);
fprintf(fpr,"%X ",a);
}
}
fclose(fpr);
return ch;
}
void main()
{
int i, a, temp[10]={23,435,67,2,14,55,778,67,673,92};
clrscr();
COM=COM1;
COM_ADD=COM1_ADD;
bioscom(0, SETTINGS, COM); // Initializing the port
out_data(170);
delay(1);
out_data(85);
delay(1);
for(i=0;;i++)
a=(int)in_data();
getch();
} //End Main
THE PREDEFINED FUNCTION: BIOSCOM
The predefined function used in the above program is BIOSCOM. It enables serial communication via RS232. Its declaration can be done in two ways as follows:
Int bioscom (int cmd, char abyte, int port);
Unsigned _bios_serialcom (int cmd, int port, char abyte);
In the above syntax, Abyte is the “OR” combination of bits that specifies COM port settings (ignored if cmd = 2 or 3). Cmd specifies the I/O operation to perform. Port identifies the I/O port; 0 = COM1, 1 = COM2, etc. For all values of cmd, both functions return a 16-bit integer. The upper 8 bits of the return value are status bits.
1. If one or more status bits is set to 1, an error has occurred.
2. If no status bits are set to 1, the byte was received without error.
The lower 8 bits of the return value depend on the value of cmd specified:
If the value of cmd is 0 then the bioscom function sets the communications parameters to the value in abyte. If the value of cmd is 1 then the bioscom function sends the character in abyte out over the communications line. If the value of cmd is 2 then the bioscom function receives a character from the communications line. If the value of cmd is 3 then the bioscom function returns current status of the communications port.
When cmd = 2 or 3 (_COM_RECEIVE or _COM_STATUS), the abyte argument is ignored. When cmd = 0 (_COM_INIT), abyte is an OR combination of the following bits (one from each group).
The 16 bits are designated parameters as given below:
0 bit indicates Received line signal detect
1 bit indicates Ring indicator
2 bit indicates Data set ready
3 bit indicates Clear to send
4 bit indicates Change in receive line signal detector
5 bit indicates Trailing edge ring detector
6 bit indicates Change in data set ready
7 bit indicates Change in clear to send
8 bit indicates Data ready
9 bit indicates Overrun error
10 bit indicates Parity error
11 bit indicates Framing error
12 bit indicates Break detect
13 bit indicates Transmit holding register empty
14 bit indicates Transmit shift register empty
15 bit indicates Time out (set to 1 if abyte value could not be sent)
Based on the bits that are set, the error can be analyzed.
The “C” program and the “set_baud rate assembly” should be run simultaneously. The data being sent from the microcontroller is supposed to send to the PC. Here, we encountered a problem because the baud rate of the internal baud rate generator of the microcontroller has fixed values of 4800, 7200 and 9600. When these values are substituted into the baud rate formula, fractions are being obtained for the BRL values. Thus, the synchronization was not exact and the data was not received properly. So, the next alternative was to use the Timer 2 in mode 1(Auto Reload Mode). The routine which was developed to serve the purpose was:
PROGRAM 9:
ORG 0000H
NOP
NOP
NOP
NOP
NOP
MAIN:
MOV 81H, #50H
LCALL TXT_INI
LCALL INIT
LCALL DELAY
MOV DPTR, #0000H
AGA:
LCALL TX_DATA
INC DPTR
SJMP AGA
LCALL DELAY
LCALL DIGIT_14
LCALL COUNT
LCALL DELAY
MOV DPTR, #BYTE_7
MOV R2, #7
LCALL TX_DATA
STAY: SJMP STAY
TXT_INI:
CLR 0AFH
CLR 8EH
CLR 8CH
CLR 0A9H
MOV 98H, #52H ; REN = 1 TI =1, MODE 2
MOV 89H, #20H ; TIMER 1 AUTO RELOAD
MOV 8DH, #0F5H ; 9600 BAUD WITH 20MHz.CRYSTAL
SETB 8EH ; START TIMER 1
RET
INIT: MOV DPTR, #BYTE_7
MOV R2, #7
RET
DELAY: MOV R4, #0FFH
DELAY2: MOV R5, #0FH
DELAY1: DJNZ R5, DELAY1
DJNZ R4, DELAY2
RET
DIGIT_14:
MOV A, #0
MOVC A,@A+DPTR
CLR 99H
MOV 99H, A
HERE: JNB 99H, HERE
INC DPTR
LCALL DELAY
DJNZ R2, DIGIT_14
RET
COUNT:
CLR 99H
JNB 99H, COUNT
MOV A, 99H
MOV R3, A
CLR 99H
MOV DPTR, #BUFFER
RET
RX_DATA: CLR 98H
JNB 98H, RX_DATA
MOV A, 99H
MOVX @DPTR, A
INC DPTR
CLR 98H
DJNZ R3, RX_DATA
RET
TX_DATA: MOV A,@DPTR
; MOVC A,@A+DPTR
CLR 99H
MOV 99H, A
WAIT_TDATA: JNB 99H, WAIT_TDATA
; INC DPTR
LCALL DELAY
; DJNZ R2, TX_DATA
RET
BUFFER: DS 255
BYTE_7: DB 11H,22H,33H,44H,55H,63H,00H
When this program was run simultaneously with the “C” program then the data was successfully transmitted and also written in a file. Now, the next task was to develop a “C” program which can convert a given text file into bitmap format i.e. “1s” and “0s”. “0s” represent black while “1s” represents white.
/*program to convert the given input into bitmap format by calculating the dynamic threshold*/
#include <stdio.h>
#include <conio.h>
#include <math.h>
void main()
{
int i, j, data, min=256, max=0, threshold, image[128][160], l, k ,a;
unsigned header[62] = {66,77, 62,10,0,0, 0,0,0,0, 62,0,0,0, 40,0,0,0, 160,0,0,0, 128,0,0,0, 1,0, 1,0, 0,0,0,0, 0,10,0,0, 196,14,0,0, 196,14,0,0, 0,0,0,0, 0,0,0,0, 0,0,0,0,255,255,255,0};
FILE *fpr, *fpw;
clrscr();
fpr=fopen("d:\\image.txt","r");
for(i=0;i<20480;i++)
{
fscanf(fpr, "%d ", &data);
if(data<min) min="data;
" if(data="">max) max=data;
}
threshold=(max+min)/2;
threshold=0x1F;
fseek(fpr,0,0);
for(i=0;i<128;i++)
{
for(j=0;j<160;j++)
{
fscanf(fpr,"%d ", &data);
if(data<threshold)
image[i][159-j]="0;
" else
="" }
="" fclose(fpr);
="" creating="" bmp="" file
="" fpw="fopen("d:\\ckt.bmp","wb");
" for(i="0;i<62;i++)" adding="" header
="" fputc((char)header[i],fpw);
="">=0;i--)
for(j=0;j<160;l++)
{
for(k=7,a=0;k>=0;k--,j++)
a+=image[i][j]*(int)pow(2.0,(double)k);
fputc((char)a,fpw);
}
fclose(fpw);
}
The output of this program is the monochrome, bitmap version of the input data. The threshold is defined as a mid value between the max and min.
ANALYSIS:
Here are some of the points that had come across during the project. Here are some of the points of analysis:
1. Though the number of pixels that can be scanned over a row are 1024 due to slow speed of reading and writing data the number of pixels are reduced to 256.
2. As the time taken to write one pixel into flash is more than 1ms the obtained data can be written to XRAM which takes relatively less time.
3. The decoder logic can be checked by checking the camera control bit of decoder which produces a pulse.
4. To ensure serial communication, one can check over the TXD pins of microcontroller, TXD of MAX232, RS232 cable and serial port of PC.
5. To check the proper working of sensor one can observe following points
a) Data pins of sensor can be checked.
b) Line valid has to be checked (it need to be 1ms).
c) Pixel clock can be checked (which is of frequency 1MHZ)
d) Datavalid bit can be checked for a pulse which is given to port of microcontroller
6. The baud rate has to be set up in “C” program in order to receive the data.
7. If the data is not received properly in the “C” program, one could check out for errors by checking the status register
8. One could check the validity of bitmap format by giving the known inputs in the form of a file.
9. To check for the data written in XRAM, one can copy the data from XRAM into Flash and read it using FLIP
software.
FUTURE SCOPE OF WORK:
1. The amount of horizontal blanking and vertical blanking is programmable through Reg0x05 and Reg0x06, respectively.
2. The aspect ratio of the CMOS sensor of 5:4. If it is to be displayed on TV monitor the aspect ratio is to be 4:3.
3. In case of the microcontroller, there ports that are left free. One of them can be connected to a printer or any other external devices. So that, simultaneously the picture can be obtained on the monitor as well as on another peripheral device.
4. So far, we have only been able to store the pixels from the sensor to the XRAM. Transmission of the data from the XRAM to the PC should be carried out.
5. Only 1792bytes has been written into the XRAM. Code has to be developed so that all the pixel data can be captured.
6. The sensor has been used with the default settings. The sensor settings can be modified by developing the serial port interfacing with the PC.
Please help me in this aspect and help me in getting the output.
manohar
|
|
|
|
|
 My brain cramped up after reading half the post. You might not get any replies to this simply because of how long this question is!
On the plus side, from what I've read, the description is thorough...Government Documentation thorough...
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
I used to work at Micron and we wrote tons of automation software out there. You need to work with the component vendors on this problem. They have API's written specifically for interfacing with their stuff in most cases and that should save you a lot of work. Work with their support people and have them look over what you are doing and your code and they can validate/invalidate your approach. This type of question is totally impossible to get an answer to here. We don't have any of the test equipment, manuals or other specs that are an absolute must for this type of work (okay maybe not a must but they really help, and we don't have them).
You'd be much better off to work with the component vendors support directly.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
