(Ridiculous webmail client can't quote your message.) There can be different external tools for different purposes. Deciding to implement one particular type isn't a decision not to do something else. There are many useful things a tool with an RS-232 to SPI microprocessor in it could do. It's probably the most versatile tool we could devise, depending on what hooks are provided in the ASIC for it to exploit. Again, the objective is to aggressively minimize what has to be added to the ASIC, and throw all the complexity on the tool. The simple DIPswitch-and-shift-register tool serves a different purpose. Digi-Key prices for DIPswitches are quite low, less even than header pins. That's why I shifted from suggesting jumper plugs to DIP switches; that, and there are no loose pieces to fall into inaccessible places. The chip count isn't really a cost consideration; shift register chips are extremely cheap, and if DIP IC packages are used, they lay out very nicely alongside the DIP switches -- track routing would be very easy, and so would soldering. It could be easily assembled with home-user tools. The DDC tool is one I hadn't thought of, but it also sounds very useful for some situations. It probably needs more brainstorming, to decide, among other things, whether it should be configured entirely through text commands on its RS-232 interface, or whether it should also have a small bank of DIP switches. Depends on whether there is a fairly limited set of DDC values, I suppose. I'm not going to take too strong a position on which microcontroller is most convenient for RS-232 to SPI designs; I've done it with both 6805 and PIC architectures. Whoever decides to write the firmware should probably have the most say. Regarding SPI clock rate: it shouldn't be a problem, as long as the tool's microcontroller has an SPI port implemented in hardware, with the shift register driven directly by the incoming SCLK when operating in slave mode. That way, it can keep up with anything up to 33 Mhz or so regardless of CPU clock rate, which is all SPI is really supposed to handle. That should be among the selection criteria. If we don't find anything suitable, we can always hang an external shift register on it for buffering, but I don't think that will be necessary. Obviously, that's not a problem for a tool that uses actual shift registers; just use 74HC devices or better.
-------------- Original message ---------------------- From: Peter TB Brett <[EMAIL PROTECTED]> > _______________________________________________ > Open-graphics mailing list > [email protected] > http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
--- Begin Message -----NextPart_Webmail_9m3u9jl4l_22845_1156799268_1 Content-Type: multipart/signed; boundary="nextPart2028402.kSImvQMz1b"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart2028402.kSImvQMz1b Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 28 August 2006 01:40, Jack Carroll wrote: > On Sat, Aug 26, 2006 at 02:53:57AM +0100, Peter TB Brett wrote: > > Having said that, chaining onto the end of the SPI bus is the most > > reasonable solution I've heard so far. I'd suggest a PIC + serial port > > as the tidiest solution, requiring the following components: > > That's one of the higher-capability tools you could hang on the SPI > bus. I suggested a 68HC908AB32, but there are PICs that would work too. > Depending on the raw hooks in the ASIC, you could use that to set the > boot-time video mode, simulate an off-board EEPROM that substitutes itself > for the on-board EEPROM, write a real off-board EEPROM, write to the > on-board EEPROM, or if the on-chip logic to support it is affordable, > provide an TRV10 debugger interface through its RS-232 port. That was the general idea. I'd go for a PIC -- the 16F87 is one that suppo= rts=20 both RS232 & SPI directly, for example. The advantage is, it's cheap and=20 requires very few external components. > An SPI tool that sets the video mode on power-up and does nothing > else could be a lot simpler. All it needs is about 120 DIP switches and a > shift register chain to read them in. Yeah, I saw this discussion, but as I mentioned I was thinking of a tool th= at=20 would be more useful for programming/test/repair purposes at the factory or= =20 vendor. Also, the PIC-based cable could well be smaller and easier to use. The kind of usage I envisaged for the PIC-based cable was as follows. Usin= g=20 your old video card, you boot up and use a nice command-line/curses-based/G= UI=20 wizard to program the cable with the desired settings. You then turn off=20 your computer, replace your video card and plug in the cable, and boot up=20 again. This makes the process a little more fool-proof and probably quicke= r=20 than messing about with hundreds of fiddly little DIP-switches, IMHO. Pricing for USB version (UK prices, based on Farnell/Digikey): =2D PIC16F87 =A32.50-ish =2D FT232 =A32.26 (strangely, MAX233 serial line drivers seem to be extraordinarily highly priced at =A35+) =2D USB A R/A connector =A30.30 =2D Some 5-core cable =A30.25 per metre approx. =2D Some discrete resistors/capacitors =2D A connector to plug onto the card =2D A PCB It'll also need some diodes, since it's going to be USB-powered during setu= p=20 and card-powered during reading. DIL switches seem to be cheapest at about =A31+ for 4, making the switch-ba= sed=20 tool at least =A330 for switches alone. Then you've got the facts that (a)= =20 it'll take a bunch more chips for the shift register, and (b) you'll need a= =20 much larger PCB. Peter =2D-=20 =46isher Society publicity officer http://tinyurl.com/o39w2 CUSBC novices, match and league secretary http://tinyurl.com/mwrc9 Quake II build tools maintainer http://tinyurl.com/fkldd v2sw6YShw7$ln5pr6ck3ma8u6/8Lw3+2m0l7Ci6e4+8t4Eb8Aen5+6g6Pa2Xs5MSr5p4 hackerkey.com --nextPart2028402.kSImvQMz1b Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBE8q9+Z7Gbq7g7vpoRAn3WAJ95kuPbQuxfUbD2W/PMgKvHZ6GP8QCfUxEh 9D1cmFvmr6b01MxDT2TRV1I= =uMZ4 -----END PGP SIGNATURE----- --nextPart2028402.kSImvQMz1b-- --NextPart_Webmail_9m3u9jl4l_22845_1156799268_1--
--- End Message ---
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
