How to Interface Simple I/O to the FlexBus

[Bob1]

Hi,   I am using an MCF54415 processor running on a Netburner MOD54415 module and need some help interfacing with the FlexBus. I have an application where I need to add general-purpose I/O. Two 74LVC573s and two 74LVC574s would do the job. I was able to use two 74LVC574s in a previous project as a 16-bit output port with only the CS1 signal connected to the pin-11 CLK line. Still, now I also need an input port so I should employ the R/W signal, but I’m not sure how or if I need to include other external signals to use with logic circuitry. Is there an application note that covers this example, or can someone please help with this seemingly simple problem?

[Hui_Ma]

Hi,

From MCF54415 Flexbus signals direction, the FB_R/W signal is output.

There need to add another pin as input function to realise that logic circuit.

Thanks for the attention.

Have a great day,

Mike

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[Bob1]

Thanks for the reply. I think you are right. I probably need to use the R/W, OE, and the CS with some glue logic. 

[TomE]

I'm pretty sure there's a far simpler way to do this.

Pioneered by cheap hobbyists going back 40 or more years, and even implemented (I think I'm right) in the original Macintosh.

It didn't bother implementing separate Read and Write Strobes for some of its I/O. It just used one of the address lines as the Read/Write signal, and read from an address where that address was high, and wrote to addresses where it was low.

You can do that with this chip. Allocate one address range (mapped to one Chip Select pin from the FlexBUS) as the "Read Addresses" and another address range and matching Chip Select as the "Write Addresses".

Then you can treat the "Read CS" as a "Read Strobe" and connect it directly to the output-enable pin on your input register chip. Likewise the "Write CS" chip connects to the Clock or Latch pin on the output register chip. THAT'S IT. No need for read/write signals or external logic decoding Read/Write into strobe and enable signals for your latches. You can have the chip-select pin decoding do all that work for you.

You'll have to check the timing of the generated Chip Select signals to make sure they can be programmed to "obey all the hardware rules" and match the required FlexBus timing.

The diagrams in the manual "20.4.6.1 Basic Read Bus Cycle" and "20.4.6.2 Basic Write Bus Cycle" look promising, but you may have to look at the detailed timing diagrams in the Data Sheet to be sure. Also check "20.4.6.4.2 Address Setup and Hold" and following for the timing variations available.

You can connect up to 4 8-bit latches across the 32-bit data bus using the same chip-select signals. If you're only connecting one or two, connect them to the UPPER lanes of the bus first. The upper bits are "byte address zero". You can program the port as an 8-bit or 16-bit one and read that. If you connect to "D0-D7" you'll have to program the port as 32-bits in order to read that byte as the lower-byte of a 32-bit read or as "byte 3" of a byte-read on a 32-bit port. That doesn't matter as you can code around any mistakes like this. It just makes it easier to get it "right" the first time. This is one place where you run into "little endian" versus "big endian" matters.

Tom

[Bob1]

Mr. Evans,

That is very clever! I understand how it works and would not have thought of using address lines in that way.

However, I must take all precautions to decode the port addresses as close as possible so that if the software runs off into the weeds, the probability of accidentally writing a port is as low as possible.

I should have mentioned the nature of the application involves preventing train derailments.

Thank you for the idea. I will file that one you away for future reference.

Bob

[TomE · Accepted solution]

I didn't mean to use an address line as a control signal. I was providing that as an example of how thinking slightly outside of a "standard design" can pay dividends.

But using logic (or PALs) to decode bus signals to drive peripherals was last needed in the 1980's. The earliest microcontrollers made that sort of design obsolete by providing the right signals that memory chips used. Or that external registers or shift registers can use.

And in this case, the Chip Select pins on the CPU can (probably, check the detailed timing) be programmed to provide the strobe signals required to read or write the external registers. Without any extra logic at all.

> However, I must take all precautions to decode the port addresses as close as

> possible so that if the software runs off into the weeds, the probability of

> accidentally writing a port is as low as possible.

It doesn't matter if you're decoding a megabyte range or a single byte range, if it goes wrong the CPU may still hit those addresses. A "runaway" that cycles through the whole of memory (like a "stack runaway") is pretty common. If a train derails then "I only decoded one address" isn't going to cut it as a design choice.

I would suggest that you need a design where it takes a number of different operations before one of those ports can be written to. If there's a safety standard involved, it may require external hardware interlocks to guarantee this, if not a system with "multiple redundant voting". But if you only need two operations that are very unlikely to be triggered by a "runaway program", then connecting a chip select directly to the register clock pin makes that very easy.

You simply don't enable the chip-select decoder until you want to write to the register, and then you disable the decoder afterwards. So the "write to the port" sequence is "Write CSMRn with an appropriate mask with the V bit set; write to the port; zero CSMRn". So the port isn't even in the memory map for 99.999% of the time. You could even program the chip-select pin as a GPIO (in PAR_CS) and an Input (PPDR_x) (with the data register set to the inactive value in PODR_x), so you would then have a three-stage lock, requiring the pin to be changed from GPIO to Chip Select before the other two steps. Then you'd have code around the function that performs that sequence to check other software "lock" conditions to try and stop a "wild jump" into that function triggering the sequence.

Neither the 573 or 574 have reset pins. There's a bit of work allowing for safe power on and reset as well. They (or downstream circuitry) can't be enabled until they've had the "inactive" values loaded into them.

There's also the risk that those external registers could be corrupted by external interference flipping the registers. Especially if this is anywhere near locomotive electrical power. That stuff is nasty.

Tom

[Bob1]

Mr. Evans,

Your suggestion of using external hardware interlocks is spot-on. We manage this by writing code sequences into logic circuitry.

The idea of not enabling the chip-select pin is interesting and may provide a “belt-and-suspenders” approach to use in addition to existing precautions.

Reset on power-up for output latches is indeed critical.

Electrical noise mitigation is a constant issue. We take electromagnetic compatibility into consideration from the beginning of each project. [I’ve spent time acquiring an EMC engineering certification for this reason.]

I can tell this is not your first rodeo. Thank you for your time. I sincerely appreciate your help.

Bob