Bulk storage for more models and telemtry data logging

[GoogleCodeExporter]

Please describe the feature you would like added
Add a USB Flash or SDCARD based bulk storage device to allow storing of more 
models and recording of telemetry data.

Original issue reported on code.google.com by gru...@gmail.com on 15 Nov 2010 at 11:10

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

It would be easiest and probably best to implement the extra model storage 
aspect of this feature by simply allowing the saving and loading of all model 
data from/to the existing EEPROM. This allows the transmitter to operate 
normally without any sdcard or usb-stick present.

Original comment by gru...@gmail.com on 15 Nov 2010 at 11:41

[GoogleCodeExporter]

** This feature would obviously require less than trivial, additional hardware 
modification **

Suggest a device such as: http://www.4dsystems.com.au/prod.php?id=22]
or "VDrive2" here: 
http://www.ftdichip.com/Products/Modules/ApplicationModules.htm

USB Flash drives are more universally accessible by users of most any computer 
type -- but often larger and more clumsy in that they tend to 'stick out' of 
the device they're connected to.

Implementation thoughts
=======================

High speed and reliable two-way serial communications is required to drive such 
a device. 

The ATmega64A has two USARTa. USART0 is currently configured for use with 
telemetry data. The THH and AIL switched are re-assigned to ports PC6 and PC7. 

Option 1 (Preferred option)
--------

The pins for USART1 (not currently in use) -- ports PD2 and PD3 -- are assigned 
to ElevatorTrimUp and ElevTrimDown respectively. There are too remaining spare 
ports (not including the reserved LCD back-light driver on PB7), namely PC0 and 
PG2. These could take on the elevator trim switch function to free up USART1. 

Option 2
--------
Move telemetry to USART1, freeing up USART0 for the data storage device. I see 
no real benefit in doing this at this time. But a reason to consider it may 
emerge.

Option 3
--------

Another option is to implement an interrupt-timer-driven, software serial 
receiver on port PG2 for 9600 baud telemetry reception, thus freeing up USART0 
for data storage. Preliminary investigation suggests this is feasible, given 
the amount of CPU load it would add, etc. (Asynchronous baud-rate accuracy only 
needs to remain inside about 10% per bit in practice, if the start bit is 
carefully monitored.)

Original comment by gru...@gmail.com on 15 Nov 2010 at 11:42

[GoogleCodeExporter]

The labels ElevTrimUp and ElevTrimDown assumes operating stick mode 1. More 
accurately then, ...

ATmega64A pins ...
PD2 = USART1_RXD = INP_D_TRM_LV_UP  (Left trim up switch)
PD3 = USART1_TXD = INP_D_TRM_LV_DWN (Right trim down switch)

Original comment by gru...@gmail.com on 16 Nov 2010 at 2:18

[GoogleCodeExporter]

I've now completed re-wiring my unit to change the trim switches to PC0/PG2, 
written the code to accommodate that and it's all A-OK.

The storage devices also really need to be used with RTS/CTS hardware 
handshaking. But we're all out of spare ports now. Or maybe not ...

I see that LCDCS1 is implemented on a port pin (PC1). This is good! In theory 
it means I can multiplex all of the current LCD outputs using an additional 
latch chip.

I haven't checked the LCD driver manual to be absolutely certain yet, but I'm 
pretty sure that with LCDCS1 not asserted, the LCD driver will ignore 
everything that happens on all its other pins. So I can use that condition as a 
chip-select for a latch chip, and then use, say, PC2 (also LCDRES, but its 
ignored by the LCD at this point) to clock in the values of a number other 
LCD-multiplex ports I connect to the latch. This could work for input too, by 
employing tri-state buffer.

I know that's all getting a bit "serious" and there may be a simpler way to get 
the job done. But it's good to know that, if it comes down to it, it will be 
possible.

Now ... after all that comes to fruition,... seems to me it might be time to 
design my own complete replacement PCB for this thing! :-D Stay tuned. 

Original comment by gru...@gmail.com on 16 Nov 2010 at 5:13

• Changed state: Started

[GoogleCodeExporter]

Original comment by gru...@gmail.com on 21 Dec 2010 at 8:33

[GoogleCodeExporter]

This issue has been replaced by the introduction of an SD/MMC interface in the 
V3 (obsoleted before production even happened!) and V4 custom circuit boards. 

Original comment by gru...@gmail.com on 3 Aug 2011 at 10:34

• Changed state: Duplicate