There are quite a few TFt screen threads just below your own.

Maybe this will be of interest - http://arduino.cc/forum/index.php/topic,125034.0.html

1) Always keep your sponge wet
2) Always keep your tip clean
3) Don't use the absolute point of the tip, it's not the hottest part. Use the side.
4) Make sure you have a good enough iron that is getting sufficiently hot. Too cold and you'll struggle, especially with lead free solder.
5) Use additional flux, if required, to help the solder flow. Of course, you need the iron tip to be hot enough for the solder to melt properly.

I'm sure there will be some more experienced solderers that can offer other advice.

http://www.elcojacobs.com/using-shiftpwm-to-control-rgb-leds-with-arduino/

Alongside the schematics towards the bottom of the page.

It will depend somewhat on the input voltage as some power will be wasted as heat in the linear voltage regulator.

From measurements just taken

Totally standard UNO R3 SMD, feeding into the DC power jack

54.7mA @ 9v
48.2mA @ 7.5v

Have a look at the ShiftPWM library as there are some instructions there for how to add push-pull line driver to ensure you can drive long signal wires to shift registers adequately.

It might help you.

So, is it a single point on the front, or is it two; I.e two wheels?

If it's two wheels the surely you could have a left to right incline, so trying to level the rear would result in a chassis twist.

If you actually need to ensure that ride height is equal from to back then two tilt sensors front to back should allow you to do this I'd have though. Rear 1 needs to level with front 1 and rear 2 with front 2.

Front 1 to front 2 could be different altitudes and rear 1 to rear 2.

If you need equal ride height over a particular surface then maybe downwards facing ultrasound distance sensors would work, one on each adjustabme corner? You'd be trying to get them all to read the same as a point of reference. Let's say you had sensors on the front wheels then you could actually have a button for left and right to select the reference and then auto-height the other three from that reference.

I think if you did a diagram showing your 'platform', it's support points and examples of different wrong and right orientations the we could all get a better idea of what you're trying to achieve.

I'm going to use a surface mount resistor but I'll have a 2 pin jumper in parallel. The jumper can be off by default, leaving the resistor in circuit. This will make sure there is always a resistor in series with the LED, regardless of the module design.

If the backlight is dim then the backpack resistor can be shorted wit the jumper. OR, even if there is a resistor on the LCD module, the jumper can stay off to have a dimmer backlight using less current. The user just has an additional option.

What If you has a software buffer, 8 bits for each LCD that held the last state it was set to.

In each constructor you have a total_lcds and this_lcd item so that each constructor know how many lcds (buffers 1 to x) there are and what it's own position is. When you write to this LCD, say lcd3, you update buffer 3 and just take the contents of all other buffers and do the full x bit shift out with the buffer data in the correct order, before latching for transfer to outputs.

I guess that there is a sequence of events that occurs, so all other LCD buffers would basically need to  obtain data that doesn't alter their respective LCD state, such as setting the RW line to read, or not setting Enable like, for example, while the sequence is carried out with buffer(x) data being shifted to the 'active' LCD.

I'm just think in general terms as a question as to whether the methodology sounds like something achievable.

Being able to get a 2 wire implementation, with daisy chained displays, that is faster than I2C with the same wiring benefits, would be quite an achievement.

After getting the *new* LiquidCrystal library owing with my I2C expanders I had a quick try of MENWIZ examples last night.

It looks very good and I'll try some altering of menu code in a short while.

Incidentally I'm testing with a 16x2 and it seems fine on two line displays.

One question though:-

The way I would want to use this is as a settings menu that only appears when entered on startup. It will set parameters for a game.

I can see that I'd do this by setting a variable for menu=1 and enter a while loop with the me u worker process running. When I exit the menu then I'll set menu=0 and drop into my main loop.

It looks like there is no lcd.begin() in the main sketch, but rather controlled in the library. This seems to assume that the menu has exclusive use of the LCD.

I will use the LCD for other things too, with the menu only used when required. At start I will have a splash screen, then an optional key combination to enter setup menu. This will be followed by screens showing the current game settings, before a countdown time to start the game, at which point the display will then be a scoreboard display.

Settings will only be able to be hanged at startup, analogous to entering PC BIOS settings.

Can I do this with MENWIZ? Since the LCd is initialized with the menu, it seems that if I don't enter the menu I wouldn't need to do so. But, if I do go into the menu then I might end up with trying to initialize the same lcd object twice.

If the LCD uses SPI too then both devices will share the MOSI, MISO and SCK pins but then have a SS pin each. Hardware SS is usually pin 10, so that is probably your pin 54 equivalent on Mega.

SD Card tends to be pin 4 for SS.

Note that you can often configure the SS pins in the libraries though, so you could check if they state D10 and D4 and leave them as is. You'd just need to get the 3 SPI pins to the correct Mega ones then.

Great idea on adding the pads but providing a thin trace. I may go for the option of adding a 68R on one side of the board and a trace on the other to short it out. If it gets used with a module with no onboard resistor then the trace can be cut to bring the resistance into circuit.

Or, even a 2 pin shorting jumper next to the resistor with jumper in the off position by default.

I quite like that idea actually as, on a module with a 100R already present, the jumper off would make backlight dimmer to save a little power. It gives additional options which is the kind of flexibility the board has.

At the moment I have it so it can have upto 2 x 8574 to provide both LCD and Keypad support. Addresses are set by jumpers. It can be used as LCD or Keypad or Both, depending on which components and headers are installed. Backlight can be set by a jumper as I2C or direct pin. Contrast can be set by a jumper as onboard trimmer or direct pin. The 6 pin I2C/Backlight Option/Contrast Option header can be set at either end of the PCB or both for an I2C pass through to another device. All on a 50mm x 23mm board, so only a few mm large than some of the LCD backpacks available.

Thanks for the idea Don and Larry. :-)

I'm about to send of a design for some nice flexible I2C backpack PCB's and just need to clear up issue over the backlight connections.

I've found and seen lots of conflicting information on this.

1) A post on here saying there are two 15mA LED's fed via a 10R, with Vcc intended at 3.3 v to provide 30mA total power.
2) Some SPI/I2C schematics showing a 68R in the LED feed circuit, controlled in various ways from PNP/NPN transistors or a P-Fet.

I can't find anything definitive in any datasheets on these generic modules, with respect to the backlight LED info.

On the modules I have, there is a 100R. The VD across the LED when lit is 3.0V. This all ties nicely with a measurement of 21.85mA total consumption of the LCD module @ 5V. The LED being (5-3)/100 = 20mA.

So, this suggests no external reistor is needed.

The mjkdz I2C modules I have use a PNP transistor and have no LED resistor.

Just after opinions before I send the Gerbers off for a batch. At the moment I have no backlight resistor on the design, after removing it.

The SDCard will use SPI, usually pins 11,12,13 and 4 on Uno.

On the Mega2560 SPI is no longer on those pins, but on 50 somthing (Might be 50,51,52), so the shield won't connect the correct pins through.

Mega compatible SPI shield, such as Ethernet, make use of the 6 Pin ISP header as that also has the SPI pins present so is a common SPI pining across both Arduino's.

If you want to use your device then you'll need to connect the relevant device pins to the correct alternatives on the Mega2560.

If speed is of the essence then it might be worth using I2C via the New LiquidCrystal Library, as that is faster than other libraries and will mean the interrupt routine exiting faster.

I'll certainly play with the SR modes as well.

Noted on the number of pins required for multiple LCD's via SR.

Could you not cascade by connecting Q7S of one into DS of the next, with Latch and Clock shared.  If you kept track of whih LCD was to be updated the could you not shift in the required number of bits, with unchanged LCD(s) having the SR bit set to state that would cause no change?

Would that not effectively allow you to daisy chain more and more displays for no extra pins? It might have a speed effect if you had many many displays, but how many would seriously affect update speed by causing so many bits to be shifted in?

I'm not conversant with the low level driving of the LCD's, but it just occurs to me that you might control LCD3, for example, by only changing bits 8-15. With bits 0-7 and 16-31 in a 'neutral' state then LCD's 1, 2 & 3 wouldn't be driven by their SR.

When we you want to drive one display you have to do a full write across all SR but the bits for the others are just set to cause no change?