Closed GoogleCodeExporter closed 8 years ago
[deleted comment]
[deleted comment]
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
** 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
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
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
Original comment by gru...@gmail.com
on 21 Dec 2010 at 8:33
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
Original issue reported on code.google.com by
gru...@gmail.com
on 15 Nov 2010 at 11:10