Hello E2E,
If change the device from TL16C752B to TL16C752D, do we necessary to modify for driver S/W?
Regards,
ACGUY
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Hello ACGUY,
Ideally the two devices should be compatible however I have seen cases where there has been some trouble. Currently what I have seen is setting FCR before sending a series of Serial data through TX helps to stop any backwards compatibility issues. I would suggest modifying the code to have FCR set (enable FIFO) before any serial data needs to be sent (it seems receiving is okay).
Thanks,
-Bobby
Hey ACGUY,
I am assuming your transmission request reception routine involves looking at the MSR first to look for a change in state of either DSR or CTS. If the logic is correct then you would initiate the routine.
In your step 2 and 3, you disable the IER for the THR flag and then reinitiate it. Is there any reason why you disable it first? Presumably the THR flag should be disabled before the transmission request to avoid turning on the interrupt routine prior.
After step 3 is complete, INT should flag itself because the THR is empty. The interrupt routine then starts and you send a byte into THR. After this though, the device will send the data through serial but the INT will trigger again because THR is empty again. At this point your code would likely loop itself because it wil try to service the interrupt. You would need to include a step 3 to your interrupt routine to disable THR in IER to avoid the loop.
This is what I believe will happen, I can try to set this kind of code up tomorrow on my board and verify this is what happens.
Thanks,
-Bobby
Hey ACGUY,
I can check for you what happens if you disable THRE in IER and then enable it (see if this will immediately generate an INT) but can you tell me which device you are asking about? B version or D version?
My guess is when you enable THRE at IER the INT pin should trigger, you will generate an interrupt but your code will get you stuck in a loop where you won't stop sending data because after each byte sent through TX, the THRE will be empty again and the INT will trigger. <-- if this is what you ARE trying to do then this routine should work. I can verify this for you if you let me know which version of the device you are asking about.
Thanks,
-Bobby
Hey ACGUY,
I was able to finish my testing today.
Here is the code I ran:
Main code:
Display after running code:
As you can see, your interrupt servicing routine will always see LSR=0x60 and as a result the INT will always re trigger itself. It gets stuck in a constant loop of repeating the service routine. This is what I guessed would happen in my earlier post.
To fix this I had to add an extra set of code, I ended up disabling the THR int inside of IER after sending the byte of data into THR inside of the service routine.
When I reran the same main code, I was able to send data only once and the INT stopped triggering:
-Bobby