Timeline for MSP430F5529 UART: UCTXIFG Doesn't Set Again After Initiating Transmit
Current License: CC BY-SA 4.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 1, 2018 at 10:40 | vote | accept | DerStrom8 | ||
| Oct 31, 2018 at 15:58 | history | edited | DerStrom8 | CC BY-SA 4.0 |
added 33 characters in body
|
| Oct 31, 2018 at 15:44 | history | edited | DerStrom8 | CC BY-SA 4.0 |
added 2127 characters in body
|
| Oct 31, 2018 at 15:36 | comment | added | DerStrom8 | No low power modes are used at this time. I am fairly confident the USCI module clocks are set correctly because I was able to establish communication at an earlier stage in this project. I will update my question to include the initialization though. | |
| Oct 31, 2018 at 15:33 | comment | added | CL. | Do the USCI modules actually get a working clock? How are UCSSEL and the clock module configured? Any LPM? | |
| Oct 31, 2018 at 15:26 | answer | added | CL. | timeline score: 1 | |
| Oct 31, 2018 at 15:26 | comment | added | jonk | That forces me to restart the system when I have another byte to transmit the first time. Keep in mind that all drivers are pairs of actual driver code: a high side routine used by the main code and a low side routine which operates the interrupt events and drains the buffer. That's for transmit. For receive, there will be ANOTHER pair of such routines. So for full-duplex, there are FOUR routines, two high-side and two low-side, each with buffers isolating them. Special handling takes care of the case where re-priming is needed. | |
| Oct 31, 2018 at 15:23 | comment | added | jonk | What I'm worried about is that you need to be sure you make certain that you don't lose an interrupt here. I normally arrange my serial port drivers in a fashion that covers my long experiences with a wide variety of peripheral behaviors. I always make sure that I handle the special-cases. So within the interrupt code if I load TXBUF then I immediately check to see if TXBUF is made re-available right away. If so, I load a 2nd byte (assuming there is one in the outgoing buffer.) If I can't do that, then the buffer is empty and I've sent out the last byte and the whole system is shut down. | |
| Oct 31, 2018 at 15:10 | history | edited | DerStrom8 | CC BY-SA 4.0 |
added 609 characters in body
|
| Oct 31, 2018 at 15:06 | comment | added | DerStrom8 | The enabling and disabling of global interrupts was something I added later for testing, and you're right, it doesn't appear to make any difference. I currently have them commented out. Regarding the possibility of a double-buffer system, I'm not entirely sure. I believe the datasheet and family guide for this device mention the value in TXBUF gets moved to a shift register, at which point TXIFG goes high again indicating it's ready for more data. | |
| Oct 31, 2018 at 15:00 | comment | added | jonk | A third thought comes to mind, though. I believe (I would need to go look) that this is a double-buffered situation. When you first load the transmitter buffer, if the second "in-progress shift register" is NOT busy at the time then the transmit buffer will be instantly moved into that in-progress shift register. I think this transfer is what signals an interrupt. If you are inside the interrupt code when this happens, it's possible that things have already gone back to a quiescent state and you won't get an interrupt. This is something I'd have to go research, though. Your job, I think. | |
| Oct 31, 2018 at 14:57 | comment | added | jonk | Not an answer, just some thoughts crossing my mind. (1) The global interrupts are cleared once the status byte is pushed during the interrupt event, so I've no idea why example code includes a call to disable the interrupts within the interrupt vector code. Makes no sense. (2) Using someone else's code that you don't agree with, independently, is fraught with possible errors. I would choose NOT to take the convenient/easy path but would instead work out my own idea. At least I'd know WHY I wrote what I wrote, then. | |
| Oct 31, 2018 at 14:46 | history | asked | DerStrom8 | CC BY-SA 4.0 |