PDA

View Full Version : Moving from Tight Loop to State Machine


Pacetech
08-04-04, 10:29 PM
Ok, I have my application working well in a tight loop using CAN and serial - whole application is 1300 lines of code.

I am now ready to turn it into a state machine so that I can try to do more. I basically have one Isopod on the CAN Bus receiving values and storing them in an array. In that same loop, it is spitting formatted commands out the serial port using the data in the array. The serial port is set at 38400 Baud.

The loop is taking about 16ms to run.

I was wondering if it is possible to overflow the serial buffer? I have a 32 byte transmit buffer. If I hammer it with a bunch of bytes and start to overflow it, will it delay until the buffer is not full?

Another way to ask the question, is my serial transmit wasting processor time? I'm not looking to transmit faster, but if I can regain any wasted clock cycles by going to a state machine, then I'll make the effort.

nmitech
08-05-04, 02:03 PM
Yes, the IsoPod will delay until the buffer is not full. It will not
allow the buffer to overflow. So if you're going to be sending long strings of data, you should make the buffer as big as the longest string.

If the loop generating serial data runs every 16 msec, and you are operating at 38400 baud (approximately 4 characters per msec), a buffer size of 64 characters should be adequate.

Pacetech
08-05-04, 06:03 PM
Originally posted by nmitech
Yes, the IsoPod will delay until the buffer is not full. It will not
allow the buffer to overflow. So if you're going to be sending long strings of data, you should make the buffer as big as the longest string.

If the loop generating serial data runs every 16 msec, and you are operating at 38400 baud (approximately 4 characters per msec), a buffer size of 64 characters should be adequate.

Well, I made my first state machine and it works great. And I gained back all that extra processing power, I don't even notice any difference in working with the CPU while the machine is running.