 | | Re: NXT Firmware source code
|
|
(...) Flash memories all have a limited number of write cycles before they become unreliable. Usually, the on-chip write controller will "load-balance" the writes so that different memory locations all get used the same number of times, (...) (17 years ago, 12-Dec-06, to lugnet.robotics.nxt)
|
| |
| | Re: NXT Firmware source code
|
|
(...) If this limitation had applied to the rcx, I'd have suggested this. Because you can control the outputs and read the inputs direct from a pc you could run an emulation of the rcx firmware running your program on the pc. The rcx would then (...) (17 years ago, 15-Dec-06, to lugnet.robotics.nxt)
|
| |
| | Re: NXT Firmware source code
|
|
(...) Now that's a cool idea. I've been messing around with remote-controlling the NXT via Bluetooth from a PC application, and it seems pretty solid. You'd definitely have some timing issues running a remote emulation like you describe, but this (...) (17 years ago, 15-Dec-06, to lugnet.robotics.nxt)
|
| |
| | Re: NXT Firmware source code
|
|
"Steve Lane yahoo.co.uk>" <stevenrobertlane@<n...pamplease> wrote in message news:JABnK0.15z@lugnet.com... (...) Fortunately the most common failure mode is a reduction in the "longevity" of storage. Out of box, the Atmel ARM flash is specified to (...) (17 years ago, 18-Dec-06, to lugnet.robotics.nxt)
|
| |
| | Re: NXT Firmware source code
|
|
(...) Not to put too fine a point on it, but the 100 cycle limit is only on the lock bits, I think. This is specified at the extreme limits of voltage and temperature. At normal room conditions, actual NXTs were reflashed (which cycles the lock (...) (17 years ago, 19-Dec-06, to lugnet.robotics.nxt)
|
