Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
can anyone who is using the EMIF, provide a measurement of the control signal timings? I want to create a external chip select decoder logic. It's for teaching purpose, that's why I think feeding the address pins back and create internal decoder logic is a waste of pins, even if the PSoC architecture is really suited for that (okay, that's something I've to think about - the students can create the decoder logic by themselve, which would also be a good teaching approach...).
Anyway, I really want to know the exact timing behaviour because each diagram of datasheet, user manual and EMIF component datasheet shows a different(!) behaviour. Comparing them didn't give useful results IMHO rather than maximizing the confusion... from this point of view it doesn't matter if the decoder logic is internal or external, the confusion still exists...
Maybe I can build up a small project with a -059 kit even without memory to check the timings myself prior to make first real hardware, but it would be nice if someone could at least support.
I've seen one approach here in the forum, where an address line is feed back into the PSoC and fed into an multiplexer, which controls the #CE signal. According to the timing diagram of the EMIF component datasheet, this wouldn't work IMHO, because a) address is shown stable after #CE goes low and might therefore cause a glitch on the multiplexed #CE signal and b) since the #CE and #OE/#WE active duration is the same, which leads to the assumption(!) that both signals go low at the same time - therefore I see a risk that the #CE glitch will address the wrong device.