Toby: To program the ATTiny84/85 initially we require a 3 pin SPI interface (which the prop can already do, just need to send the appropriate commands) and the reset pin to the ATTiny.
Two of these pins will already be connected for the I2C interface, so only 2 more prop pins need to be temporarily connected to initially program the bootloader into the ATTiny. Once the bootloader is done, subsequent programming can be done via the 2pin I2C interface/bootloader. Most likely we could use the PropPlug Tx & Rx pins for these extra 2 programming pins.
SO, the prop can program the ATtiny without any special programming device :smilewinkgrin: Just a bit of code and the SPI object. neat hey!
The only consideration is to verify any other I2C device (such as the EEPROM) will not interfere when the SPI protocol is used instead of I2C. These are all solvable.
That was one of my worries, the possibilities of a series of the SPIs ones and noughts being spotted as a valid command by other bus attachments.
I remember saying, a long time ago, that I was supprised to see no useage of the Prop in things like programmer interfacing anywhere. I had to take some flack back then but here we are, talking about it again. The Prop seems to be deemed "too good for anything so lowly" but I count the ability to do something easilly over the $ cost/1000 pieces. Obviously if the project is to be a comercial venture ...
The only consideration is to verify any other I2C device (such as the EEPROM) will not interfere when the SPI protocol is used instead of I2C.
As long as you don't change SDA during programming while SCL is high, you should have no problems; and that should be an easy condition to maintain for SPI communication. Otherwise, the I2C devices will recognize start conditions and may respond.
Phil, what part of SPI signalling would help maintain the right conditions? I don't remember all the details just now.
I've been programming the '85 "in-circuit" connected to Propeller/EEPROM using STK200 and AVR Studio with no problems - I do have some 470 ohm resistors between the STK200 SPI pins and the Propeller I2C pins. My original guess is that the resistor on the SDA/DI pin probably keeps any ACK from the EEPROM from clobbering the program ... Phil's comments indicate a game changer.
In the I2C bus's idle state, both SCL and SDA are high. When you begin an SPI sequence, bring SCL (SCLK) low first, then SDA (MOSI). Thereafter, always change MOSI with SCLK low, then toggle SCL to clock the data. At the end of the sequence, you will have to raise MOSI, then SCLK to return the bus to its I2C idle state. If this causes an extra bit to transfer, you can use this for the last bit and raise MOSI last if the last bit is a 0. Doing so will cause a stop state on the I2C bus, but that will be harmless.
In the I2C bus's idle state, both SCL and SDA are high. When you begin an SPI sequence, bring SCL (SCLK) low first, then SDA (MOSI). Thereafter, always change MOSI with SCLK low, then toggle SCL to clock the data. At the end of the sequence, you will have to raise MOSI, then SCLK to return the bus to its I2C idle state. If this causes an extra bit to transfer, you can use this for the last bit and raise MOSI last if the last bit is a 0. Doing so will cause a stop state on the I2C bus, but that will be harmless.
IIRC correctly (dont have the schematics with me) I use -WE & -OE shared with SCL & SDA (not sure which way around) for SRAM on the TriBlade. I checked the details of the I2C interface while designing it and was certain there would be no interference.
In fact, the SD is a SPI interface. So this could share SPI devices, but will require separate -CS pins. Don't forget Phils trick of using an XOR/Inverter to get HS & VS from 1 pin. This is useful for getting two -CS from a single pin with 4 resistors and an inverter.
My new pcbs will place the SD on pins on P24-27. Not to standard I know, but I want/require that P0-7, P8-15 & P16-23 be 8pin expansion ports with the SD card (microSD) on the baseboard.
That's what I'm thinking. Two of the SD pins could be on the I2C pins.
With the more flexible pin assignment SD drivers, that would allow grouping on pins 26,27,28,29 for example. This would allow headache free sharing of the I2C bus assuming Phil's analysis is complete.
jazzed: On the RamBlade I share the SCL & SDA with the data bus of the SRAM. So, in order to ensure that the EEPROM does not wrongly intercept data, I hold either SCL or SDA (no schematic here) when the SRAM is being used by using a gate. Of course this is another chip - cheap but another chip. I mention this because it may help you with your design.
From what I recall, as long as either the SDA or the SCL stays constant, the other line can toggle with almost no chance of the device seeing a 'real message'.
In an effort to get as many free pins as possible, I pushed the VGA (4 pins ) up onto 24-27 and had the SD card on 20-23. The idea was to allow the SD to be either on a small daughter board, next to the Prop, or up on the top memory board when things got sorted out.
The SD card worked ok even with the short IDE cable etc until the SD code got speeded up, so the track lenths etc will have to be kept down.
Comments
-Phil
Two of these pins will already be connected for the I2C interface, so only 2 more prop pins need to be temporarily connected to initially program the bootloader into the ATTiny. Once the bootloader is done, subsequent programming can be done via the 2pin I2C interface/bootloader. Most likely we could use the PropPlug Tx & Rx pins for these extra 2 programming pins.
SO, the prop can program the ATtiny without any special programming device :smilewinkgrin: Just a bit of code and the SPI object. neat hey!
The only consideration is to verify any other I2C device (such as the EEPROM) will not interfere when the SPI protocol is used instead of I2C. These are all solvable.
I remember saying, a long time ago, that I was supprised to see no useage of the Prop in things like programmer interfacing anywhere. I had to take some flack back then but here we are, talking about it again. The Prop seems to be deemed "too good for anything so lowly" but I count the ability to do something easilly over the $ cost/1000 pieces. Obviously if the project is to be a comercial venture ...
-Phil
I've been programming the '85 "in-circuit" connected to Propeller/EEPROM using STK200 and AVR Studio with no problems - I do have some 470 ohm resistors between the STK200 SPI pins and the Propeller I2C pins. My original guess is that the resistor on the SDA/DI pin probably keeps any ACK from the EEPROM from clobbering the program ... Phil's comments indicate a game changer.
-Phil
This is a very comforting description. It really makes me wonder
why we're not using I2C and SPI pins like this normally.
If this is deemed universally reliable, it can save 2 more Propeller pins !
In fact, the SD is a SPI interface. So this could share SPI devices, but will require separate -CS pins. Don't forget Phils trick of using an XOR/Inverter to get HS & VS from 1 pin. This is useful for getting two -CS from a single pin with 4 resistors and an inverter.
My new pcbs will place the SD on pins on P24-27. Not to standard I know, but I want/require that P0-7, P8-15 & P16-23 be 8pin expansion ports with the SD card (microSD) on the baseboard.
That's what I'm thinking. Two of the SD pins could be on the I2C pins.
With the more flexible pin assignment SD drivers, that would allow grouping on pins 26,27,28,29 for example. This would allow headache free sharing of the I2C bus assuming Phil's analysis is complete.
From what I recall, as long as either the SDA or the SCL stays constant, the other line can toggle with almost no chance of the device seeing a 'real message'.
The SD card worked ok even with the short IDE cable etc until the SD code got speeded up, so the track lenths etc will have to be kept down.