Hi Guys,
I just got UART transmit working with dsPIC and looking to get receive working.
Could anyone tell me why dsPIC UART sample code/libraries from Microchip have an interrupt for UART serial transmit?
Is it only because of the bottleneck if data rate could flow faster than the UART FIFO buffer could be emptied?
So you’d be wanting to load the next bytes as fast as possible?
Cheers, Art.

 

I tend to use interrupt on receive, the libraries samples I have downloaded use either interrupt or non.
Max.

 

Using an interrupt for transmit has the primary benefit of not requiring a process to wait while a spot becomes available in the FIFO. If the FIFO is full when you need a spot, then you can leave the character in memory, enable the interrupt, and go on to do something else. When the interrupt is serviced it goes to the place where you left the character, picks it up and adds it to the FIFO. When there are no more characters waiting to go into the FIFO the interrupt is disabled.

 

Thanks, I figured as much later. For some reason had it in my head the interrupt would
trigger when you sent the byte rather than when the UART actually send the byte.

 

Thanks, I figured as much later. For some reason had it in my head the interrupt would
trigger when you sent the byte rather than when the UART actually send the byte.

That is correct. The interrupt is triggered when the UART is finished shifting all the bits, including the STOP bit, out of the transmit shift register, and loads a new data byte from the FIFO into the transmit shift register, which frees up a slot at the other end of the FIFO for the processor to load a new byte which will then be transmitted at a later time depending on the depth of the FIFO.

 

You do have to be careful because some transmitters have more than one interrupt.
Transmit Shift Register Empty is the one that means the end of transmission.
Transmit Data Register Empty fires when the Transmit Shift Register is loaded, in processors with a FIFO or alternatively with a single register aka a 1 byte FIFO

 

Thanks
It appears I lose the first byte of transmission from the dsPic, only once at power up.
My 16F877A with UART doesn’t do that. The first thing it says is “Hi” and I see that on a terminal.

I have Tx/Rx working basically in practical application,
but haven’t looked at any UART error checking yet, which I will eventually clean it up.
The device it connects to is a slower pic micro, so comms can’t run away at the moment.

 

When you say that you lose the first byte. It could be either the dsPIC never sending the first byte or the slower PIC micro never receiving the first byte. I suggest a variable delay before sending the first byte to make certain the slower device is ready to receive in time for the arrival of that first byte.

 

No that’s tested with an old-school serial console.
I’m talking only about first byte after power, not the first byte of every string.
Perhaps I need to check the state of the UART tx pin before serial kicks in.

The astronomy algorithms at least work as they do on a bigger platform.
The top line is Moonrise/set times, and the bottom is Sunrise/set times for the day.
They happen to be pretty close to each other today, but it is correct for Eastern Australia.
I’ve yet to implement Moon percentage illumination, but do have the algorithm in C.

The dsPic gets time & calendar information from the clock.
Lucky I wrote serial terminal support so I could add the dsPic right onto it
It has been given a fixed geographic location for the astronomy algos, now I really need a GPS module.