next topic »

[on:]

I have a serlcd from sparkfun.  I need to send data that ends up like this (ie degrees, mins, secs):
359d 34m 23s
Which is more 'effecient':
A.  concatenate a string programmatically ie: string = degvar + "d" +minvar + "m" + secvar + "s". (also need to include leading zeros) And then print that string to the LCD.
OR
B.  print each variable at the correct location on the LCD:
print (at location 0) degvar
print (at location 6) minvar
print (at location 10) secvar

The timing is critical because the LCD is reporting the movement of a stepper motor which at its fastest rate only has 10ms between each step - so I don't want the stepper to be interrupted by the reports to the lcd.  

I should add perhaps that I presume I would transmit to the lcd at 9600 baud and would only be sending values every 100ms or so (ie not every step but every 10 steps or so).

Many thanks in advance.

Ben

PS I recognise that I could test this out experimentally but wondered if there was an obvious answer...

[Reply #1 on:]

There is some overhead (i.e. time) involved in the function call to print data to the LCD, but that is trivial in comparison to the time it takes to print one character.

On the other hand, there is overhead involved in constructing a single string to print.

I doubt that you would be able to measure the difference in times required to create and send one string vs. sending multiple strings.

[Reply #2 on:]

If you know how to exploit it,  there's a significant advantage to printing in small chunks.

The serial transmitter has two registers:  an active shift register where the current byte is being processed,  and a buffer where the next byte is held until the shift register is finished.

Unlike systems with more RAM to spare,  the Arduino runtime doesn't allocate a software transmit buffer,  so those two bytes are all you get.

So,  when you write more than two bytes to the serial port,  the hardware immediately transfers the first byte from the buffer register to the shift register,  stores the second byte in its buffer,  and sets a "buffer full" flag in one of its status registers.  The Serial.write() routine sees that flag,  and spins in a loop until it's cleared.  That means that,  when you write n bytes,  you spend n-2 character transmit times just waiting,  and nothing useful gets done unless it's in the handler for an interrupt that fires while you're spinning.

Given what you've said about the design of your application,  where you're updating the LCD about every tenth update of the stepper position,  I'd make a sort of state machine for driving the display,  and do a small fragment of the display operation on each motor move cycle:

Cycle 0:  send the "clear screen" (or "cursor home") to the LCD.

Cycle 1: print degvar.

Cycle 2: print "d ".

Cycle 3: print minvar.

Cycle 4: print "m ".

Cycle 5: print secvar.

Cycle 6: print "s".

With 10mS per cycle,  every preceding write will have finished,  so you should only see a wait when you're printing variables with 3-digit values (and maybe on the clear/home escape sequence).  You could do a little more tweaking,  but that's probably beyond the point of diminishing returns.

Ran