In my application I need to known when the last bit is shifted out of the serial channel shift register. The NET+50 doc states to use the TXBC (tx buffer closed) condition for this, but this bit never seems to get set in Serial Channel Status Register A. I use the serial channel in UART mode, without DMA. Anybody any idea?.
Have this problem also … the following is from Netsilicon (Sept. 2002) … “… in unpublished errata (was discovered recently) that TXBC is broken. The TXBC field in the Serial Channel Status Register A. Unfortunately, this field is not working and it is not documented. TXBC is broken for serial UART mode . However, the work-a-round is to use TXEMPTY and TXHALF (FIFO half full). An example is in our SPI driver in NET+OS 4.0 in the SPI driver file netos_spi.c.”
But this workaround is really slow. The Patch uses a tx_thread_sleep() to wait for completion. And this might be a hole tick (default for the tick is 10ms). So we have to wait until the TXBC-bit gets fixed.
I can’t add more to it rather summarizing it. The TXBC field in the Serial Channel Status Register A, unfortunately is not working. TXBC is not functional on the 40 - for UART/SPI/HDLC modes. Also it is not functional for serial UART mode on the 50 as well. However, the work-a-round is to use TXEMPTY and TXHALF (fifo half full). This is because Net+Arm does not set TXBC (Transmit Buffer Closed Interrupt Pending). At this point, you can get interrupt before XMT buffer is closed. You need to wait until FIFO is empty. The Net+Arm 40 chips sets TXEMPTY (Transmit FIFO Empty) bit correctly, so you wait for 5 bytes max where as for Net+Arm 50 you must wait for 9 bytes max since 1 byte is added for the shift buffer
I seem to have the same problem in the NS7520 (HDLC mode). Does anyone know if it is fixed in the NS7520 or should I go for the workaround? Is the problem there also if I go for a DMA solution instead of an interrupt driven implementation?
So, what is the correct fonction to avoid the famous tx_thread_sleep(20ms) ? We need to be quick (access to a real time clock, with 10ms resolution)
That would hold the same therefore follow the workaround described above.