??? 09/09/08 18:52 Read: times |
#158137 - Simplicity versus overengineering Responding to: ???'s previous message |
If the programming adapter drives the signals directly, but your extra devices are connected to the SPI signals behind a suitable series resistor, it will not matter of these devices tries to put out any data. The series resistor will limit their drive capability enough that the programming adapter can do its work unhindered.
I have a number of products using this concept, and it is inexpensive and works very well. The factory may connect a USB-to-SPI converter and then download new firmware into a powered board. The only thing to think about is that if the other devices have their slave-select input activated and are not held in a reset state, they will also hear the communication between ISP adapter and the device being updated. This is normally not a problem, and is solved if the ISP adapter affects the reset of the other SPI devices or can force their slave-select lines to inactive state. And for most SPI devices, it doesn't matter if they hear any unknown noise as long as they don't have non-volatile memory that may get programmed by mistake. Having jumpers or DIP switches will add two extra steps in the programming. You must remember to put them in the ISP state before starting, and you must remember to restore them to the operating state after. Strap fields may in some situations be affected by vibration, resulting in intermittent communication problems. And DIP-switches adds to the component costs. But strap fields and DIP-switches requires extra documentation. |
Topic | Author | Date |
89S51/52/8252 ISP (ISP lines connected to MCP3201) | 01/01/70 00:00 | |
Series resistors. | 01/01/70 00:00 | |
Hhm, I dont think this is a good idea... | 01/01/70 00:00 | |
Re: Hhm, I dont think this is a good idea... | 01/01/70 00:00 | |
Simplicity versus overengineering | 01/01/70 00:00 | |
Re: Simplicity versus overengineering | 01/01/70 00:00 | |
Modified my earlier post...![]() | 01/01/70 00:00 | |
assuming... | 01/01/70 00:00 |