UART setup for 801C188EB/80186

Comments won't change how the code runs, but it might help people read it.

I'm not looking at my 80C186 data sheet -- does the UART have a dedicated pin, or does it share a GPIO pin? If it's shared, do you have to do something to switch it over? Did you?

Have you tried connecting a scope to see what is happening and where, so many different possible points of failure from cabling to software.

As from memory 80188 werer normally just a processor we have no idea what UART you are using. 80188 was just an 8 bit external data bus version of 80186

Personally I did not realise many folks still making 80188 from about 30 years ago.

Although I don't know the 80x188 in detail the following line looks strange to me.

I think you mean "status & 0x8" if you want to test if the bit is set. Normally the status register for a UART has several bits for each status like receiver ready, transmitter ready, parity error ...

This can't be the code that you're running, because what you have here won't compile.

But have you considered the infinite loop in serial_puts? You need to put the status read inside of the "while" loop, or it'll either always drop through or it'll always get stuck there.

If you have any blinky lights, or any spare GPIO that you can monitor with an oscilloscope or meter, use them in lieu of "printf" as a debugging tool. Start by using them to see how far you're getting in your main loop, then how you're doing inside of any troublesome functions, etc.

Besides that, the status register is only read once and the status variable is not updated in the while loop. If the status register is not

Sorry for not adding comments. serialinit()

//FF66 is transmit buffer register

UART Is a dedicated PIN for this port. SO I have not done anything other than this. Another concern which i think might be hampering this is the watchdog timer. Its set to go off after an interval, I am not sure how to toggle it to make sure my while loop runs.

--------------------------------------- Posted through

many different possible points of failure from cabling to software.

continuous high pulse after i turned it on. I am guessing the watch dog timer might be creating the issues.

Yes this is a modification to on old boot code. Thats the reson this processor is in use. I know pin 9 is the watchdog input. When I need to toggle it, do i need to reconfigure it as this is a GPIO? What would be the procedure to toggle it?

-srao

Add-ons

Font

--------------------------------------- Posted through

Yes, I understand. I am wondering now, if its required to check if the transmit buffer is empty? TXE is one of the bit which denoted the buffer is empty(set to 1 if empty) Out of the several bits.. is there a way i can check only this bit?

--------------------------------------- Posted through

Haven't been programming long?

Do a logical OR -- if the one bit is bit 3, then

((status ^ 0x08) != 0)

will return true if the status bit is set, and false if not.

buffer

Thanks TIM. Yes, been a while. N I accept this last part was a unnecessary question. Do u know how to go about the watchdog timer. I need to keep it kicking. The pin of the processor which takes the input is P1.5 (GCS5) I can see there ate two registers associated with it. GCS5ST, GCS5SP for start and stop registers. i didnt get an idea what they mean.? thoughts?

--------------------------------------- Posted through

You mean _bitwise_and_

((status & 0x08) != 0)

Good lord yes! What was I thinking?

Study that data sheet, 'cause I don't know either!

If it's like the watchdog timers I'm used to, you need to reset it in software before it times out, or it'll reset the processor. The idea is that if your program hangs the watchdog resets it.

You really ought to implement a task loop instead of blocking on status flags.

I looked for a web reference and didn't find it. The basics are that everything that needs to get serviced has a state associated with it, and a function. Your main program is a loop that just calls all of the functions in turn (there are other ways to do this -- this is the simplest).

Each function looks at its state, looks at whatever hardware it is servicing, then does whatever it needs to do based on those two things, possibly writing to hardware and/or changing its state in the process. Functions _never, ever_ waste time -- so no "while (status)" loops are allowed. Instead, you'd have something like "if I have stuff to transmit, and the transmitter is ready, write a byte to the transmitter and update my 'stuff to transmit' pointer".

Task loops are what you do instead of implementing RTOSs, when the problem is small enough.

The terms I'm used to for this is "event loop" or "state machine".

Yes, I understand. I will look into it, and modify the program according to your suggestions. I used a while loops just to make sure, i could see something on the scope. Figured the watchdog timer stuff. Like you said, they do reset if the program hangs, so I am planning to keep toggling watchdog and not allow it to kick.

--------------------------------------- Posted through

buffer

Did something like this:-

while(1) {

for (N loops) //togggle watchdog { //port1 clear bits Set bit on watchdog PIN outport(0x00xx,a); }

for (N loops) { //port1 clear bits //Clear bit on watchdog PIN outport(0x00xx,a); }

--------------------------------------- Posted through

not sure if I am doing something wrong here. the above code does not toggle the Port pin. is there a better way to solve this?

--------------------------------------- Posted through

Where do you change the value written to the port? You don't even show where you set the value of 'a' initially.

The OP _really_ needs to show us _actual_ code not the above pseudo code.

Also, the above sequence "feels" really wrong to me. Why is the port pin being set N times and then cleared N times ?

With a watchdog you are supposed to send a specific sequence _once_ every time you decide to report that you are still alive and not stuck.

Simon.