UART_TX_COMPLETE is not quite done: RS-485

A catchall for PSoC Mixed-Signal Array (microcontroller) discussions not captured by the other forums.

Moderator: ericb

UART_TX_COMPLETE is not quite done: RS-485

Postby DavidCary on Tue Sep 12, 2006 7:42 am

Is there any way for the PSoC to drive the "driver output enable" pin correctly?

I want to turn off the driver *after* the last byte of the message was transmitted.

I wish the UART TX had a "transmitting" output that I could wire up to the "driver output enable" pin of a standard RS-485 transciever.

Since it doesn't, I tried
* set up the "TXComplete" interrupt, then in the interrupt set the "driver output enable pin" low.
* spin-loop wait (in software) until the UART_TX_COMPLETE flag goes high, then I set the "output enable pin" low.

But I seem to be turning off the "driver output enable" pin *before* (or perhaps in the middle of) the last byte of the message.

What am I doing wrong?
Or is this really a bug in the UART module or the CY8C29466 silicon?

(Forgive me for re-posting a question I already asked at
viewtopic.php?t=1798
)

Code: Select all
/*
MAIN.C
BY ANGEL CARRILLO AND DAVID CARY.

Bug demonstration:
the "enable" output gets turned off too soon --
I can see on the o'scope that about 7 or 8 (?) bits
get shifted out *after* the "enable" pin goes high.
(If I take out the "!", I see 12 or so bits shifted out after
the "enable" pin goes high).

Since the hardware between the PSoC and the PC does not transmit anything
when the "enable" pin is lo,
the PC (as I can see on Hyperterminal) never recieves that last byte.

Expected output:

]][[Hi.

]][[Hi.

]][[Hi.

]][[Hi.

Actual output:

][[Hi.

][[Hi.

][[Hi.

] [[Hi.

][[Hi.

(odd that *occasionally* I get a space charater, rather than the final right bracket I was expecting).

If I manually disconnect the "enable" wire from the PSOC and connect it to +5V instead,
I see exactly the output I expected in Hyperterminal.
But that is not a good long-term solution,
because (over this half-duplex channel)
I need the hardware enable pin to go low when I am listening for a message.

   2006-09-11: created simplified bug report.
    2006-06-09: Started.
*/

#include <m8c.h>        // part specific constants and macros
#include "PSoCAPI.h"    // PSoC API definitions for all User Modules
#include "psocgpioint.h"
#include "iso646.h"


/*
RS485_enable_Data_ADDR
RS485_enable_MASK
etc. from
from psocgpioint.h
*/
void enable_TX(void){
   RS485_enable_Data_ADDR = RS485_enable_Data_ADDR bitor RS485_enable_MASK;
}
void disable_TX(void){
   RS485_enable_Data_ADDR = RS485_enable_Data_ADDR bitand ~RS485_enable_MASK;
}

void PutString( char * message ){
   int i=0;
   BYTE status = 0;
   enable_TX();
   UART_1_CPutString( "[[" );
   UART_1_PutString(message);
   UART_1_CPutString( "]]" );
   do{
      status = UART_1_bReadTxStatus();
   }while( !(UART_TX_COMPLETE bitand status) );
   // }while( !(UART_TX_BUFFER_EMPTY bitand status) );
   
   disable_TX();
}


void set_up_serial(void){

    UART_1_CmdReset();  // Initialize receiver/cmd buffer 
   // "UART_EnableInt() ... should be called prior to calling Start()." -- UART datasheet.
    UART_1_EnableInt();            // enable UART interrupts (in particular, transmit_interrupt()).
   Timer16_1_Start(); // Turn on baud rate generator (this input must be 8 times the desired baud rate)
    UART_1_Start(UART_PARITY_NONE);         // Enable UART
   UART_1_CmdReset(); // Initialize receiver/cmd buffer
    M8C_EnableGInt ;                      // Turn on interrupts 
}

char greeting[20] = "Hi.\r\n";

void main(void){ 
   int i = 0;
    set_up_serial();

    // main loop:
    while(1) { 
      RES_WDT = 0xAA; // feed watchdog timer
      PutString(greeting);
      for( i=0; i< 100; i++){
      };
   };
}
Attachments
UART_bug_report.zip
a project that demonstrates the bug
(57.46 KiB) Downloaded 201 times
DavidCary
Cheese Wheel
Cheese Wheel
 
Posts: 73
Joined: Sat Jun 17, 2006 8:51 pm
Location: TULSA OK

Postby antedeluvian on Tue Sep 12, 2006 10:54 am

What am I doing wrong?
Or is this really a bug in the UART module or the CY8C29466 silicon?


You are not doing anything wrong. It is the implementation of the UART. The flag goes active when there are a few bits still inside the hardware although the detection logic sees that the actual Tx register is empty. It is also possible that the logic generates the flag without considering the stop bit, so when you change the state of the RS485 buffer the default of the line is seen as a zero and the recieving hardware sees an error.

The only way that I have found is to build in a slight delay once the transmission is complete. My software contains a "tick" timer that decrements several software counters so that I can have many timers within the software based on a single hardware resource. As a result the transmit turnaround delay is only a mild annoyance costing me a memory byte.

This UART implementation is not unique to the PSoC so I would hardly call it a bug, but you are right: it would be nice if the TxEmpty meant that everything had completely cleared the chip right up to the pin.

-Aubrey
antedeluvian
The Big Cheese
The Big Cheese
 
Posts: 248
Joined: Mon Dec 22, 2003 12:03 pm
Location: Toronto, Canada

Postby jiml on Tue Sep 12, 2006 12:15 pm

Aubrey is right....I ran into the same problem and it was discussed a while back in this forum. Regrettably you do have to delay after sending the last char. even when you poll the transmit status bits. Having it all happen in hardware would be nice.

I can think of a couple approachs that MIGHT work.

Method 1 - Set up a PWM with the clock input routed to the tx clock from the transmitter. Reset the PWM as each byte is loaded into the transmit buffer.

Method 2 - Use the OneShot UM (possibly modified for retrigger if it doesn't already support it). Route the TxData stream to the OneShot input and the TxClock to the OneShot UM clock. Since the oneshot is retriggerable (according to the datasheet diagrams?!), the oneshot output should go low and stay low on the first startbit and stay low until 8 clocks after the last zero bit in the output stream


If you try either let me know how it works....or doesn't!

jiml
jiml
The Big Cheese
The Big Cheese
 
Posts: 440
Joined: Tue Sep 27, 2005 2:35 pm

Postby antedeluvian on Tue Sep 12, 2006 12:34 pm

jiml wrote:Method 2 - Use the OneShot UM (possibly modified for retrigger if it doesn't already support it). Route the TxData stream to the OneShot input and the TxClock to the OneShot UM clock. Since the oneshot is retriggerable (according to the datasheet diagrams?!), the oneshot output should go low and stay low on the first startbit and stay low until 8 clocks after the last zero bit in the output stream


This approach certainly works with external hardware. As you mention the down side is that it can have a considerable delay for the monostable to time out, especially at low baud rates.

Another approach that could work, and will depend on unseen interactions within the PSoC as well as possibly how the receiver handles errors is as follows:

Add an extra (dummy) byte to the end of the transmission. I would suggest 0xff, but the start bit if it gets through will still cause an error. Instead of interrupting on the TX register empty, interrupt on the Holding Buffer empty flag. When the dummy byte has left the holding register, change the direction of the RS485. It is possible that when the holding buffer goes empty that the byte before last (the actual last byte) has shifted out.

Perhaps you would have to check both flags.

If you get any of these approaches to work it would be worth an App Note...

I do hope you have a storage scope as it will make your job much easier in trying to understand the events.

-Aubrey
antedeluvian
The Big Cheese
The Big Cheese
 
Posts: 248
Joined: Mon Dec 22, 2003 12:03 pm
Location: Toronto, Canada

Postby jiml on Tue Sep 12, 2006 1:19 pm

Good points. One thing of note though is that unlike the external hardware approach where the oneshot has no way of "knowing" the baud rate, the pSoc OneShot UM is clocked directly from the TXClock output of the transmitter so the delay is no more than 1 character time ...assuming you setup the one shot correctly!

Hmm...I may have to actually try this in my spare time ...

jiml
jiml
The Big Cheese
The Big Cheese
 
Posts: 440
Joined: Tue Sep 27, 2005 2:35 pm

Code to monitor UART TX Complete

Postby Mr_E on Tue Sep 12, 2006 1:34 pm

We have also struggled with this, finally came up with this solution (works well):

Code: Select all
   if( CbOutPtr < CbOutLen )   //if we haven't sent all the bytes (ie for len=6: 0-5 < 6)
   {
      if(bUART_1_ReadTxStatus() & UART_TX_BUFFER_EMPTY)//make sure UART has room before stuffing another byte
      {
         UART_1_SendData(Cb.out[CbOutPtr]);
         CbOutPtr++;
      }
   }
   else               //we sent all the bytes, wait for TX buffer to empty and UART to finish transmitting
   {                  //we do this because we turn off the TX line, and don't want to do it mid-byte
      if( !(bUART_1_ReadTxStatus() & UART_TX_BUFFER_EMPTY) )
         return;         //wait for UART buffer to empty
         
      wait = 75;                  //max time = 71 cycles if this is all we do, so 75 should work on all processors
      while( !(bUART_1_ReadTxStatus() & UART_TX_COMPLETE) & (wait>0) )//wait for UART to transmit last byte
         wait--;                  //without timeout every once in a while the display would lock up here forever
      
      port1dr &= ~0x08;            //  disable 485 transmit
      PRT1DR = port1dr;
      CbOutLen = 0;               //clear xmit request so we don't send same data again
   }
User avatar
Mr_E
The Big Cheese
The Big Cheese
 
Posts: 297
Joined: Wed Aug 11, 2004 7:08 am
Location: Oklahoma, USA

Postby jiml on Tue Sep 12, 2006 2:54 pm

Thats a lot like the solution that Graaja recommended when I posted about the issue (maybe you also contributed this previously). It does work but seems painful compared to having a UART with status bits that work right.

jiml
jiml
The Big Cheese
The Big Cheese
 
Posts: 440
Joined: Tue Sep 27, 2005 2:35 pm

Postby werner on Tue Sep 12, 2006 4:27 pm

antedeluvian wrote:This UART implementation is not unique to the PSoC so I would hardly call it a bug,


TRM 2.01 (yeah, I should finally print 2.10 :-) says about TX Complete
(in the DCBxxCR0 register definition):

"1 Indicates that a byte is shifted out and all the associated framing bits
are generated."

In the "Transmitter Timing" section, the figure "Status Timing for the
Transmitter" also shows TX COMPLETE go high after the stop bit is
sent.

So, if this really doesn't work (I haven't tried it), this would sound like
a silicon or documentation bug, or a problem in the library functions
or their use.

Since the TRM seems to be fairly insistent on this, I'd be a bit
surprised if documentation and silicon would really disagree.

A simple test would be to set up the transmitter, send a byte, then
poll TX Complete, and change another pin when it goes 1. Then watch
both pins on a scope.

If this looks good, repeat using the TX Complete interrupt.

The TRM says that TX COMPLETE is cleared only when reading CR0.
So the sequence should be roughly like this:

- write the last byte into the TX buffer
- wait for TX Reg Empty to go high again
- read CR0 (not sure if this is needed if we've already read CR0
while waiting for TX Reg Empty)
- poll for TX COMPLETE

If the library implements interrupt-driven buffered transmission,
one would also have to synchronize with that.

- Werner
werner
The Big Cheese
The Big Cheese
 
Posts: 246
Joined: Fri Jan 20, 2006 10:20 am
Location: Buenos Aires, Argentina

Postby graaja on Tue Sep 12, 2006 11:50 pm

Why dont you check the value in DxBxFN register? Check if the "interrupt type" bit is properly set. It is possible that there is a bug with the user module and the interrupt type bit is not being set to TxComplete.
User avatar
graaja
PSoC Master
PSoC Master
 
Posts: 3084
Joined: Thu Dec 18, 2003 4:35 pm
Location: India

Postby jomalogil on Wed Sep 13, 2006 2:33 am

Hi,
I've next code in my ISR subroutine and it's running ok
ISR reception is configurated as TX_COMPLETE.
Code: Select all
void Int_Serie_Out_UART1(void)
{
  UART_1_bReadTxStatus();          // leemos el reistro para borrar la interrupcion
  if(ucPntOutIn==ucPntOutOut)
     { FlagTxd=FALSE;
      aucShadowPorts[PORT_CTRL_485] &= ~aucMascaraBits0_7[BIT_CTRL_485];
      PRT0DR=aucShadowPorts[PORT_CTRL_485];       
      }
  else
      { UART_1_SendData(aucOut[ucPntOutOut]);
        ucPntOutOut ++;
        if(ucPntOutOut==COLA_OUT_SIO)
            { ucPntOutOut=0;
          }
       }
  return;
}
Gil
Saludos-Best regards
jomalogil
Cheese Wheel
Cheese Wheel
 
Posts: 140
Joined: Thu Nov 24, 2005 6:36 am
Location: Madrid - Spain

Postby jiml on Wed Sep 13, 2006 4:37 am

See this link to some prior discussion on the same issue.....

http://www.psocdeveloper.com/forums/viewtopic.php?t=1731&highlight=uart

I am not sure that Aubrey's comment about...

This UART implementation is not unique to the PSoC so I would hardly call it a bug,


makes for a very convincing argument. Just because a characteristic is common doesn't mean its correct. Heart disease is common but its still a disease. I agree that this combination of status bits is very common however the timing of when the bits get set is variable. Some uarts set the "transmit shift register empty" bit 1/2 way through the last bit of the last byte. Some will not set the transmit shift register empty bit if the transmit holding register already has another byte queued. Some don't set the transmit shift register empty until the very last bit of the last byte has shifted out. I have worked with some UARTs that have the same status bits but the timing of when they get set is different and one is able to un-ambiguously determine when the last bit of the last byte is fully transmitted without resorting to software delays. Sometimes this condition is flaged with an additional bit which indicates "transmitter underrun" and one can use the underrun condition to decide when to turn of the RS485 transmit.


jiml
jiml
The Big Cheese
The Big Cheese
 
Posts: 440
Joined: Tue Sep 27, 2005 2:35 pm

Postby antedeluvian on Wed Sep 13, 2006 5:40 am

jiml wrote: Just because a characteristic is common doesn't mean its correct.

I don't want to get involved in semantics. I think we all agree that we would like the flag to go true when the data has left the chip. If calling it a "bug" gets Cypress to update the UM, then I am all in favour of the insect classification.

-Aubrey

Added after 15 minutes:
P.S. I still don't think it is a bug. I think it is a shortcoming. If I were a betting man, I would put $1 to say that that is the way the PSoC module is, and you the User Module can't be changed to improve the performance.
antedeluvian
The Big Cheese
The Big Cheese
 
Posts: 248
Joined: Mon Dec 22, 2003 12:03 pm
Location: Toronto, Canada

Postby werner on Wed Sep 13, 2006 6:58 am

jiml wrote:See this link to some prior discussion on the same issue.....

http://www.psocdeveloper.com/forums/viewtopic.php?t=1731&highlight=uart


Thanks. Now I know why I had that strange feeling of deja vu :-)

There's indeed at least one race condition in my code, e.g.,
the cached status can give us a false "go ahead" if the previous
send completes entirely before we do anything else. (E.g.,
because a long-running interrupt kept us busy.)

Searching for a solution ...

- Werner
werner
The Big Cheese
The Big Cheese
 
Posts: 246
Joined: Fri Jan 20, 2006 10:20 am
Location: Buenos Aires, Argentina

Postby werner on Wed Sep 13, 2006 8:11 am

werner wrote:Searching for a solution ...


If the going gets tough, the tough use Promela :-)

Here's a partial solution:
http://www.psocdeveloper.com/forums/viewtopic.php?p=11225#11225

Its correctness is based on two assumptions:

- my model is right (wouldn't take this for granted with my flu)

- TX_COMPLETE gets set only if there isn't a new byte waiting in the
TX Buffer (the TRM isn't clear on this - needs verification on real
hardware)

I don't quite like disabling interrupts, but I haven't found any better
solution so far.

- Werner
werner
The Big Cheese
The Big Cheese
 
Posts: 246
Joined: Fri Jan 20, 2006 10:20 am
Location: Buenos Aires, Argentina

Postby werner on Wed Sep 13, 2006 11:15 am

werner wrote:- TX_COMPLETE gets set only if there isn't a new byte waiting in the
TX Buffer (the TRM isn't clear on this - needs verification on real
hardware)


No such luck :-(

I've tested it, and TX_Complete gets set for the first time exactly
when the stop bit of the first byte has ended, even if there's
another byte waiting in the TX buffer at that time.

Example program (for m8cas):
http://www.almesberger.net/misc/uart.asm

And this is what it looks like:
Image

Two 0x55 bytes are sent back to back. CH1 rises on TX_RegEmpty,
after enqueuing the second byte, and falls again on the first
TX_Complete.

This confirms what the TRM says: TX_RegEmpy is set on the start bit
and TX_Complete is set after the stop bit.

- Werner
werner
The Big Cheese
The Big Cheese
 
Posts: 246
Joined: Fri Jan 20, 2006 10:20 am
Location: Buenos Aires, Argentina

TX enable how I did it

Postby blinari on Thu Sep 14, 2006 5:03 pm

This is how I did it.

Now be for I start my TX I

Code: Select all
   TX8_1_SetTxIntMode(TX8_1_INT_MODE_TX_REG_EMPTY);   
   
   TX8_1_EnableInt();
   TX8_1_Start(0);
   CommCount=0;
   TX8_1_SendData(TXBuffer[0]);
   RDI1LT0 = 0xFF;      //This is TX Eneable pin //RDI1LT0




inside of my isr looks something like this:


Code: Select all
void TX8_C_ISR()
{
while((TX8_1_bReadTxStatus()&TX8_1_TX_COMPLETE))
      {}
      TXindex++;

      if(TXindex<=TXBUFLen)      //The first Bytes was sent from main
      {
         TX8_bReadTxStatus();

         if(TXindex>=TXBUFLen-1)
               TX8_SetTxIntMode(TX8_INT_MODE_TX_COMPLETE);// was 1
         if(TXindex<TXBUFLen)
            TX8_SendData(TXBuffer[TXindex]);

         TX8_bReadTxStatus();

      }
// You what to know when the TX is done not when the buffer is empty
so that is why you trigger off of TX8_1_INT_MODE_TX_COMPLETE
      }
      else
      {  //Last time though
         StopTX();  //this is where you need to toggle your pin
      }

      CommCount=0;
}


This is how I turn it off.

Code: Select all
void   StopTX(void)
{   
   if(TRXStat==2)
   {   
      TX8_1_Stop();
      RDI1LT0 = 0x00;      //This is TX Eneable pin //RDI1LT0
      
      TX_Flag_Done=0;
   
   }
}
Last edited by blinari on Thu Sep 28, 2006 8:31 am, edited 1 time in total.
User avatar
blinari
Cheese Wheel
Cheese Wheel
 
Posts: 73
Joined: Tue Feb 28, 2006 3:59 pm
Location: Wa

Re: TX enable how I did it

Postby werner on Thu Sep 14, 2006 6:54 pm

blinari wrote:This is how I did it.


Hmm, the code looks a bit confusing. Is the algorithm something like
this ?

- send the first byte
- on each TX_REG_EMPTY, enqueue one more byte
- if there are no more bytes to send, switch to interrupt on TX_COMPLETE
- when the TX_COMPLETE arrives, turn the transmitter off

?

If yes, then this should work, but only if your worst-case interrupt
latency is less than the time it takes to send one byte.

Otherwise, you may hit the following scenario:

- sending of the last byte begins, TX_REG_EMPTY interrupt is raised
- time passes without handling the interrupt (interrupts off, other
interrupt being processed)
- sending of the last byte ends, TX_COMPLETE is set
- now you finally handle the interrupt, and switch to waiting for
TX_COMPLETE
- the interrupt never arrives

Nasty, huh ?

Of course, it's reasonable to assume that interrupt latency will be short,
but there are corner cases (sloppy programming, running the UART very
fast, or, I think, Flash programming), where this may not be true.

One way to work around this would be to also start a timer (however
this is implemented) when switching to TX_COMPLETE, which will force
the shutdown if waiting longer than one byte transmission time
(including framing bits).

- Werner
werner
The Big Cheese
The Big Cheese
 
Posts: 246
Joined: Fri Jan 20, 2006 10:20 am
Location: Buenos Aires, Argentina

Postby blinari on Fri Sep 15, 2006 8:18 am

You are exactly right. That is what I did. CommCount is a timer 1msec counter that if it gets too long then it just turns off the TX. :)
User avatar
blinari
Cheese Wheel
Cheese Wheel
 
Posts: 73
Joined: Tue Feb 28, 2006 3:59 pm
Location: Wa

Postby DavidCary on Wed Sep 27, 2006 6:46 pm

I see I misinterpreted the datasheet.

Silly me, I thought the "TX_Complete" flag had something to do with when the complete transmission was completely completed :-).

Immediately after a typical PutString(),
there are 2 bytes in the buffer -- one being shifted out bit-by-bit in the "Tx shift register", and another in the "Tx buffer".

I had hoped that the TX_Complete flag would be set only after the last bit of the *last* byte -- when both the "Tx shift register" and the "Tx buffer" were empty, and it is time to disable my RS-485 transmitter.

From Werner's excellent o'scope image, I see that
the TX_Complete flag is actually set after the stop bit of the *next-to-last* byte -- even though there's another byte in the "TX buffer" that will immediately be moved into the "TX shift register".

If I look closely at the "TX Timing Diagram" in the UART data sheet, I see that it does accurately describe what Werner shows actually happens:

When the stop bit of the *next-to-last* byte is done, then the TX_Complete flag and TX_buffer_empty flag are simultaneously set, and the TX output simultaneously goes low (the beginning of the start bit of the last byte).

Unfortunately, that is not what I wanted to happen.

Proposed work-arounds so far:

* a short do-nothing delay loop delaying 2 character-times after PutString() returns (or delaying until TX_buffer_empty, then delaying 1 character-time), then turn off transmitter. (This is what I'm doing now. It seems to work adequately, but it is such a fragile hack). Surely there is a better way.

* The code blinari posted seems to be reasonable, but since TX_Complete and TX_buffer_empty are set *simultaneously*,
wouldn't it be simpler and work exactly the same to stuff in the first *2* bytes whenever we want to start a new packet, and keep the transmitter *always* in
Code: Select all
TX8_1_SetTxIntMode(TX8_1_INT_MODE_TX_COMPLETE);

mode?
Would that end up exactly the same as what jomalogil suggested?
(Would that help with the potential glitch werner pointed out?)

* Add a character to the end of PutString() that will be ignored by the reciever -- perhaps 0xFF, but certainly something *different* from the "start of packet" byte. Then after PutString returns, delay until TX_buffer_empty, then turn off transmitter. (Is there some way we can wire the TX_buffer_empty bit directly to the output pin that goes to the transmitter enable?) (as suggested by antedeluvian)

* set up a one-shot, clocked directly from "TX Clock Out" or the baud rate (times 8) generator, wired to enable the transmitter whenever TX Out is Low, and keep it enabled until TX goes Hi at least 2 bit times (or 8 bit times?). See AN2249 ? As suggested by jiml.

* Is there some way to *change* the user module to give use the signal we want? (In place of the IMHO useless "TX Clock Out"). Then I could wire that signal to the appropriate output pin, and it would Just Work.
DavidCary
Cheese Wheel
Cheese Wheel
 
Posts: 73
Joined: Sat Jun 17, 2006 8:51 pm
Location: TULSA OK

Postby werner on Wed Sep 27, 2006 7:21 pm

DavidCary wrote:I see that
the TX_Complete flag is actually set after the stop bit of the *next-to-last* byte


In fact, it's set (unless already set) after every byte. Only in my
example, that would be the second-to-last byte. (And of course,
it would be set again after the last byte, which my test wasn't set
up to show.)

* a short do-nothing delay loop delaying 2 character-times after PutString() returns (or delaying until TX_buffer_empty, then delaying 1 character-time), then turn off transmitter. (This is what I'm doing now. It seems to work adequately, but it is such a fragile hack). Surely there is a better way.


It depends on what PutString does. If PutString doesn't do any additional
buffering, and your timer is reliable, that solution should be fine.

keep the transmitter *always* in
Code: Select all
TX8_1_SetTxIntMode(TX8_1_INT_MODE_TX_COMPLETE);

mode?
Would that end up exactly the same as what jomalogil suggested?


That should work perfectly fine, yes. The problem with this approach
is that the there will be a delay between adjacent bytes, namely the
UART setup time of 1-2 bit times, plus any latency we have in responding
to TX_COMPLETE rising.

If your application doesn't require full-speed back-to-back transmission,
this should be the most convenient approach, though.

* Add a character to the end of PutString() that will be ignored by the reciever -- perhaps 0xFF, but certainly something *different* from the "start of packet" byte. Then after PutString returns, delay until TX_buffer_empty, then turn off transmitter.


This sounds very hackish. Also, what happens when you turn on the
UART again ? Suppose you do this immediately after shutting down.
Could you now be transmitting the first new byte inside the time frame
of the "idle" byte ?

* Is there some way to *change* the user module to give use the signal we want? (In place of the IMHO useless "TX Clock Out").


The UM only seems to do what the hardware supports. Alas, there isn't a
mode to get a "nicer" TX_COMPLETE. Well, there are still a few unused
code points for digital block functionality, so at least in theory, Cypress
could add this. Not sure if it would be worth the trouble, though. The
work-arounds aren't all that nasty.

- Werner
werner
The Big Cheese
The Big Cheese
 
Posts: 246
Joined: Fri Jan 20, 2006 10:20 am
Location: Buenos Aires, Argentina

Next

Return to PSoC1 General

Who is online

Users browsing this forum: Bing [Bot] and 0 guests

cron