<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""></div>Yes, the SN74LV1T34 we are trying is around that (5ns). 3.3v->1.8v seems to have the worst propagation delay.<div class=""><br class=""></div><div class="">At 40MHz, the !CS signal must be established within 25ns, so we’ll be delayed about 1/5 of that cycle. I think that should be ok.</div><div class=""><br class=""></div><div class="">The lines we have are:</div><div class=""><ul class="MailOutline"><li class="">FL_CS1: 1.8v CS line to internal flash (never used)</li><li class="">FL_CS2: 3.3v CS line to external flash (level converted to 1.8v)</li><li class="">FL_SCK: 1.8v clock to internal and external flash</li><li class="">GPIO16 / SRAM_CS: 1.8v CS to SPI RAM</li><li class="">GPIO17 / SRAM_CLK: 1.8v clock to SPI RAM</li><li class="">FL_SDI: 1.8v shared SPI bus</li><li class="">FL_SDO: 1.8v shared SPI bus</li><li class="">FL_WP: 1.8v shared SPI bus</li><li class="">FL_HOLD: 1.8v shared SPI bus</li></ul></div><div class=""><br class=""></div><div class="">Notice that the CLK is different for flash vs SPI RAM access.</div><div class=""><br class=""></div><div class=""><div class="">My concern is the ‘out’ transition from us to some other device (say SPI RAM) - we could still have CS active for the first 1/5 of that cycle. Not sure how much delay there is when switching between different SPI devices, but I suspect it will not be quick (us rather than ns). In any case, the flash spi clock should not even be running when SPI RAM is being accessed (flash and ram are on two different clocks). Advise from China was that it would be ok. I’ll have a look at it on the oscilloscope when I get it.</div></div><div class=""><br class=""></div><div class="">The issue is that we can’t really see any other way of doing it. I guess we’ll find out in the next couple of days.</div><div class=""><br class=""></div><div class="">Regards, Mark.</div><div class=""><div><br class=""></div><div><blockquote type="cite" class=""><div class="">On 19 Jan 2018, at 10:47 AM, Stephen Casner <<a href="mailto:casner@acm.org" class="">casner@acm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On Wed, 17 Jan 2018, Mark Webb-Johnson wrote:<br class=""><br class=""><blockquote type="cite" class="">The only solution we can see is to continue to use GPIO22 for FL_CS2<br class="">external flash, but use a level converter 3.3V -> 1.8V. We only need<br class="">uni-directional, but it must operate fast enough not to interfere<br class="">with a 40MHz SPI bus. Maybe a resistor voltage divider would be too<br class="">slow / interfere too much, so safer to use a simple single channel<br class="">uni-directional 3.3V->1.8V logic level shifter chip.<br class=""></blockquote><br class="">Just out of curiousity I looked in DigiKey to see what SMD<br class="">unidirectional level translators were available. They all seem to<br class="">have typical propagation delays in the neighborhood of 5ns. Since the<br class="">cycle time for 40MHz is 25ns, it seems like that delay would be a<br class="">problem.<br class=""><br class=""> -- Steve<br class="">_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.teslaclub.hk" class="">OvmsDev@lists.teslaclub.hk</a><br class="">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev<br class=""></div></div></blockquote></div><br class=""></div></body></html>