Forums

Abhishek Trivedi

Its TACCR0 is set to 12000 for 12MHZ clock

This gives an interrupt every millisecond. I don't know the code, but likely, the ISR is counting the milliseconds and start a transmission if it counted to 1000.

If you change the count to 6, you'll get an interrupt every 0.5µs or every 6 MCLK cycles. Which is faster than the MSP can enter and exit an ISR, let alone execute some code inside the ISR.

You should instead change TACCR0 to 6000, getting an interrupt every 500µs, and then remove the counter from the ISR, to send something on every ISR call, not every 1000th.

However, sending a 16 bit value every 0.5ms, means 4000 bytes per second. So you'll neet at least a baudrate of 57600. With 9600, you are limited to 960 bytes per second, which limits you to one value every 2.1ms. Which fits the observation of 270 values (=540 bytes) per second due to the missing interrupts caused by the insanely (and unnecessary) high interrupt rate

Hello Michael,

      Thanks for the reply. I am really sorry, I made a mistake the clock is 12 KHz not 12 MHz. Now should there be any problem of high interrupt rate?

Abhishek Trivedi

I made a mistake the clock is 12 KHz not 12 MHz. Now should there be any problem of high interrupt rate?

Well, if your MCLK is also 12kHz only, the the problem scales to the same amount. 6 clock cycles per interrupt only. Where do you get these 12kHz from? What is your MCLK? What is the clock source for the UART?

The 12 KHz is my ACLK which is the internal oscillator clock known as VLOCLK. The clock source for my UART is SMCLK which is ~1.1MHz.

I think i got the output as i need. At 9600 we have a limitation of sending 960 bytes per second and I am sending a buffer of 10 bytes(for numbers), so I am limited to 96 numbers per second, so when I set the interrupt rate <= 96(by changing TACCR0) , I get the continuos numbers but when I set it >96, I loose numbers in between. So, i think this whole problem is due to baud rate limitation.

And you are most welcome to tell me if I am wrong in any way. 

And can you suggest me any other similar develoment kit with a higher baud rate?

Thanks.

Abhishek Trivedi

The 12 KHz is my ACLK which is the internal oscillator clock known as VLOCLK.

So it's rather a 4-20kHz clock that is likely to be somewhere in the 12kHz range :)

Abhishek Trivedi

The clock source for my UART is SMCLK which is ~1.1MHz.

The '~' is a problem. UARTs are not very forgiving about ~ baudrates. YOu should rathe ruse teh calibrated 1MHz DCO settings (if available) or calibrate your MSP somehow.

Other than that, yes, if you're sending 10 bytes per package, you're limited to 96 interrupts per second. And that you're losing numbers indicates that you're starting to overwrite packets already in the queue, instead of simply slowing down the pace (losing interrupts), which would be the other option.

Abhishek Trivedi

And can you suggest me any other similar develoment kit with a higher baud rate?

The backchannel UART is limited to 9600Bd because it uses bit-banging of unused I/O ports of the TUSB chip that connects the FET with the PC.
The MSP itself can go as high as 1MBd, bu tthat won't be forwarded to the PC tough the standard connection.

The the 4x/2x combo experimenter board has a dedicated RS232 connector supporting all baudrates (you'll need a real COM port or an USB/serial converter to connect to the PC) and the experimenter board for the MSPs with USB controller offers a virtual serial port that is stuffed directly by the MSPs USB controller (but requires much more code to handle).

However, you can connect even teh LaunchPad to the PC with any baudrate by using a separate USB/serial converter. Eithe rone that has an RS232 signal level (the standard type). Then you'll have to disconnect the RX and TX signals from teh FET part of the LaunchPad (pulling the two jumpers) and connect them to a MAX3232 chip or similar. Or you get an USB converter that offers direct TTL signal output. In this case the MAX3232 isn't necessary and RX and TX can be connected directly.

Thanks for your help Michael, I really appreciate it.

Now, I am directly converting numbers from int to char and I am directly transmitting the numbers(not converting to ASCII), So each number takes only two bytes. So, basically with the limitation of 960 bytes, I can send 480 bytes per second. But this is all based on calculation. Is there any way to know how many numbers I receive in each second programmatically? Because right now till whatever number I send, I will eventually receive it but i dont knw whether I will receive it in one second or not?

Can you help me out with this?

Thanks.

Abhishek Trivedi

Is there any way to know how many numbers I receive in each second programmatically?

Well, you need to write your own PC frontend software that eeps track of how many number received in how much time.

Or you start capturing and stop capturign fro a certain period of time and thencount how many numbers arrived in that delay (easier to do, but less precise, of course).

For an MCU, time is relative. If the MCU has no access to a timebase that matches our human 'normal time flow', it cannot tell.

Well, another way would be keepign track of the tiem internally (with a precision crystal as time source). Then count ho wmany values sent and how much tiem passed, itnernally. YOu then have to communicate the result somehow.

I guess, doing it externally on the PC side is the easier way :)