EmbeddedRelated.com
Forums
Memfault Beyond the Launch

UART setup for 801C188EB/80186

Started by srao October 14, 2015
>On Thu, 15 Oct 2015 15:48:07 -0500, srao wrote: > >> 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? > >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. > >-- > >Tim Wescott >Wescott Design Services >http://www.wescottdesign.com
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 http://www.EmbeddedRelated.com
Tim Wescott wrote:

> On Thu, 15 Oct 2015 15:48:07 -0500, srao wrote: > >> 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? > > 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.
You mean _bitwise_and_ ((status & 0x08) != 0) -- Reinhardt
On Fri, 16 Oct 2015 07:21:25 +0800, Reinhardt Behm wrote:

> Tim Wescott wrote: > >> On Thu, 15 Oct 2015 15:48:07 -0500, srao wrote: >> >>> 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? >> >> 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. > > You mean _bitwise_and_ > > ((status & 0x08) != 0)
Good lord yes! What was I thinking? -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
On Thu, 15 Oct 2015 17:08:11 -0500, srao wrote:

>>On Thu, 15 Oct 2015 15:48:07 -0500, srao wrote: >> >>> 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? >> >>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. >> >>-- >> >>Tim Wescott Wescott Design Services http://www.wescottdesign.com > > 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?
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. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Tim Wescott <seemywebsite@myfooter.really> writes:
> 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 terms I'm used to for this is "event loop" or "state machine".
>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. > >-- > >Tim Wescott >Wescott Design Services >http://www.wescottdesign.com
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 http://www.EmbeddedRelated.com
>On Thu, 15 Oct 2015 15:48:07 -0500, srao wrote: > >> 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? > >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. > >-- > >Tim Wescott >Wescott Design Services >http://www.wescottdesign.com
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 http://www.EmbeddedRelated.com
>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); > } >---------------------------------------
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 http://www.EmbeddedRelated.com
On 10/16/2015 7:33 PM, srao wrote:
>> 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); >> } >> --------------------------------------- > 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?
Where do you change the value written to the port? You don't even show where you set the value of 'a' initially. -- Rick
On 2015-10-17, rickman <gnuarm@gmail.com> wrote:
> On 10/16/2015 7:33 PM, srao wrote: >>> 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); >>> } >>> --------------------------------------- >> 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? > > 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. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world

Memfault Beyond the Launch