Does anybody have a schematic for the 'Philips Standard I2C Parallel Port Adapter' I have searched the web and found only commercial units. There are parallel port to I2C schematics but I have no way to know if they are the same or similar. Thanks Added after 4 hours 53 minutes: I came across this later on. Mcdsp Emerald Pack Torrent Macbook.

Can anyone decipher The schematic is almost the same as the Schematic provided by Philips. As a matter of fact it is the same.A little addition has been made. However it is 100% compatible with the philips driver schematic.

This was done so you can use it both with tools like TV400 from Philips and with my driver.

ORIGINAL: luk2011 It's safe to programming 24CXX with SOIC TEST CLIPS ( 8 PIN ) without to desolder the SMD Eeprom from the board? Hi Luk2011, What kind of concerns do you have? In my opinion, I think in situ programming is a great way to go.

Two wire bus initially was used by Philips and become a standard among chip vendors. I2C bus consists of two lines called Serial Data. Programming AVR I2C interface. Standard EEPROM ICs Interfacing SLx 24Cxx I 2. C-bus becomes a standard bus system which. 1 control module with EEPROM routines and 1 demo program. Philips Semiconductors The I2C-bus and how to use it (including specifications) 1995 update. Up to 100 kbit/s in the standard mode or up to 400 kbit/s in the.

If you have a PIC on the board or any other master I2C controller, you might have to place it in a reset state so that you avoid multi-master I2C communications (to make things easier) since your external I2C EEPROM programmer will also be a master on the bus. Maybe you already have the details figured out -- I just thought I'd mention that.

From what you said so far, I don't see anything wrong with your approach as long as you always practice safe HEX and verify the contents after programming (you could even implement a CRC signature on the EEPROM contents if you wanted extra assurance of proper programming, versus a simple checksum). Some people might use pogo pins that mate with some designated PCB pads or use a programming header instead, but your SOIC clip approach seems doable as long as you don't mind the human intervention involved. Actually, I'm assuming that this will be a human operation -- perhaps I'm wrong and it would be automated instead. You mentioned a desoldering approach: I think you could be introducing more risk if you use your alternate method of desoldering the EEPROM.

I'm assuming you would also re-solder this component to the board after programming it out of the circuit -- with this method I see more chances of heat damage, bent pins, and exposure to ESD. You also asked this same question about Microwire EEPROMs. I think in situ programming is valid there as well as long as you iron out all the details about who's controlling the programming transactions (on-board versus external contention). I don't have the details about your board, but perhaps you could have the on-board microcontroller/microprocessor (if there is one) program the EEPROM through some simple communication interface commands? In other words, say you already have an RS-232 serial link on this board. You could implement EEPROM read and write routines controlled by commands you send over the link so that you can download and verify a HEX file and have the on-board processor program the EEPROM.

Decibel Mac Keygen App. This could be automated and would eliminate human 'touch time' if so desired. Just throwing out some ideas here. Best regards, Ken Pergola.

ORIGINAL: luk2011 MY question is. I can do this with PonyProg or other software 100% SAFE without to remove the SMD Eeprom, and RISK FREE ( without any RISK )? Hi Luk2011, I have never used PonyProg, but have you developed a proof-of-concept prototype and actually tried this yourself? A huge part of engineering is about risk management and risk mitigation -- I don't think anything is 100% risk-free.

The onus is really upon you to minimize any risk involved as much as possible. There's also non-engineering risk involved also, correct? What about the legal liability of modifying a car's electronics (especially if it is not yours)? What are you actually trying to do here inside the car dashboard? If it is modifying odometers, is this a legal application for doing such?

Will you be subject to a lawsuit if something goes wrong? I already gave you some ideas to minimize risk so I really don't have much further to add to this thread, but even a CRC signature will not provide 100% risk-free assurance. You might have to write some code and invest some engineering resources to get this extra assurance that you are looking for. In addition, I gave you some warnings and some advice about EEPROM access contention in terms of internal versus external access: is the car's computer accessing the EEPROM while you are trying to program it externally? Framingham Risk Score Calculator Pdf To Excel. This is potentially very significant and something that has to be determined and/or addressed for all types of EEPROM bus topologies (I2C/SPI/Microwire).