Guys,
Damn, how come anything I say always ends up in these insanely lengthy
discussions? :)
Although I can see why there would be a problem with "smart" devices
like PLDs et al, why dont we hide such smartness in firmware that is
executed by the processor of the programmer?
What I would like to see is a device that can be talked to using one
of (serial|parallel|usb) methods (so pretty much any platform of any
age can talk to it), and which can be told what to do using a sort-of
standardized (ASCII-based) language:
>> RESET
>> DEVICE SELECT 27C512
>> DOWNLOAD
Start sending data please, end with . on single line.
[some recognized data format flies by]
.
>> OK, Motorola HEX format detected, 440KB received.
>> UPLOAD
Programming 27C512 ... 100%
>>
We separate the various parts of the problem. We no longer
care about HOW to talk to it. You choose. We also no longer
care HOW the data is formatted. Send it, and the firmware
will bitch at you if you're sending an MPEG movie :)
The real trick would be the logic behind the UPLOAD command,
which of course is the part where the stuff we sent to it will
be sent to the device- EPROM, EEPROM, whatever. Based on the
selected device type, this will use one of its algorithms to
write to it.
Although not perfect, wouldn't this solve most of the probs
with platform dependentness and so on? Yes, for the smart
device you still need to use the vendor's preparation tools
to generate the bits that have to be stuffed into the dev,
but at elast once that is done, you can use this thingie to
actually do that.
Anyone here with decent microcontroller experience ? :)
--
Fred N. van Kempen, DEC (Digital Equipment Corporation) Collector/Archivist
Visit the VAXlab Project at http://VAXlab.pdp11.nl/
Visit the Archives at http://www.pdp11.nl/
Email: waltje_at_pdp11.nl BUSSUM, THE NETHERLANDS / Mountain View, CA, USA
Received on Mon Mar 22 2004 - 09:43:36 GMT