FT201X (3.4MBd i2c slave) with Prop?
jmg
Posts: 15,183
As a mental exercise, the new FT201X looks interesting for minimal, but high performance, systems.
Advantages :
A high speed serial channel (3.4MBd) to the PC now exists, for Debug/logging/report info.
No auto-baud footwork needed, and tolerant of frequency agile systems.
Assuming 3.4MBd, a 512 byte debug snapshot can dump to the PC in ~ 1.35ms, a whole GOG image in ~5.4ms
Data is annoyingly sparse on FT201X, but I think the three blocks [PC.FT201X.Prop] could play together, with a little care.
FTDI claims to have
["Royalty free VIRTUAL COM PORT (VCP) DRIVERS "]
so that suggests you can config handshake lines, and send data, just as in their more common COMxx devices.
Connections are
SCL - from Prop to FT201X & EEPROM
SDA - from Prop to FT201X & EEPROM
RST - Handshake line Control from FT201X to Prop, PC controlled.
A0 - FT201X Control - Mux and EEPROM Adr0, pulldown so boots from EPROM, hi boots from FT201X
These are the questions and issues I can see :
Note, this FT201X is an i2c SLAVE, with the address set in MTP config, so if we set the Address to EEPROM, and Ping the Prop reset...
Q: Will it boot properly from waiting data ? { Fill the FT201X before releasing RESET }
One issue I can see, is read-underflow; it is not clear what happens over the bus, if the PC does not refill the 512 byte buffer soon enough.
(ie does the FT201X cease ACK, or repeat the last byte, or repeat 00 or ? )
If this is an issue, 512 bytes is enough to send a smarter stub.
The ideal is to quick-boot from the PC and also PGM the local i2c memory, and load from that.
I can see that the EEPROM can have an address pin flipped to move out of the way for load from FT201X, and that can then share the i2c bus for PGM, but when this pin is pulled LOW for EEPROM boot test, (PC control ?, no-PC floats to EEPROM on ) somehow we need to disable the FT201X, as it still has the Boot i2c Address ?
If there is no easy SW way to disable FT201X, then a P-FET series switch in FT201X-SCL should work
Once booted, both the EEPROM and FT201X are on the i2c bus, and can be R/W.
If you have extra data in the EEPROM, it needs a debug switch to shift the address for Debug mode.
PC sourced code gets any Data from EEPROM moved address, whilst EEPROM pgmd/fetched code gets data from default base.
EEPROM Pgm/verify would need a small Prop module that reads blocks from FT201X, and writes to EEPROM (Adr Moved)
An updated boot ROM, could simplify some of this a little, but I can see no brick walls here ?
Advantages :
A high speed serial channel (3.4MBd) to the PC now exists, for Debug/logging/report info.
No auto-baud footwork needed, and tolerant of frequency agile systems.
Assuming 3.4MBd, a 512 byte debug snapshot can dump to the PC in ~ 1.35ms, a whole GOG image in ~5.4ms
Data is annoyingly sparse on FT201X, but I think the three blocks [PC.FT201X.Prop] could play together, with a little care.
FTDI claims to have
["Royalty free VIRTUAL COM PORT (VCP) DRIVERS "]
so that suggests you can config handshake lines, and send data, just as in their more common COMxx devices.
Connections are
SCL - from Prop to FT201X & EEPROM
SDA - from Prop to FT201X & EEPROM
RST - Handshake line Control from FT201X to Prop, PC controlled.
A0 - FT201X Control - Mux and EEPROM Adr0, pulldown so boots from EPROM, hi boots from FT201X
These are the questions and issues I can see :
Note, this FT201X is an i2c SLAVE, with the address set in MTP config, so if we set the Address to EEPROM, and Ping the Prop reset...
Q: Will it boot properly from waiting data ? { Fill the FT201X before releasing RESET }
One issue I can see, is read-underflow; it is not clear what happens over the bus, if the PC does not refill the 512 byte buffer soon enough.
(ie does the FT201X cease ACK, or repeat the last byte, or repeat 00 or ? )
If this is an issue, 512 bytes is enough to send a smarter stub.
The ideal is to quick-boot from the PC and also PGM the local i2c memory, and load from that.
I can see that the EEPROM can have an address pin flipped to move out of the way for load from FT201X, and that can then share the i2c bus for PGM, but when this pin is pulled LOW for EEPROM boot test, (PC control ?, no-PC floats to EEPROM on ) somehow we need to disable the FT201X, as it still has the Boot i2c Address ?
If there is no easy SW way to disable FT201X, then a P-FET series switch in FT201X-SCL should work
Once booted, both the EEPROM and FT201X are on the i2c bus, and can be R/W.
If you have extra data in the EEPROM, it needs a debug switch to shift the address for Debug mode.
PC sourced code gets any Data from EEPROM moved address, whilst EEPROM pgmd/fetched code gets data from default base.
EEPROM Pgm/verify would need a small Prop module that reads blocks from FT201X, and writes to EEPROM (Adr Moved)
An updated boot ROM, could simplify some of this a little, but I can see no brick walls here ?
Comments
I don't think it will be possible to get the FT201X to "look" like an eeprom. You're probably going to still need an eeprom for boot purposes
All these new x-chips are available on small dip 0.3" breakout boards, so there's nothing stopping us from using a breadboard, and diving into the software and trying.