I am not sure how to proceed if I want to try do something to work with the IO bus with chips or other electronics that have a different format. Could you give me some ideas about what to search for or look after in order to do so? Using a much faster CPU (on the other end) will not manage to deal with the signalling so that a program can manage the expansion slot in real-time?
Your question is somewhat vague. So I’m not actually completely sure what you are actually asking. But I’ll try to provide an answer.
Chips do come in a variety of formats if you will divided into 2 basic types. Parallel and serial. For the purposes of the expansion bus we are discussing here, it is only directly compatible with parallel type interfaces.
Within the parallel type chips there is typically a data bus and sometimes might be an address or register select as we as a Chip Select or Enable and depending on the chip there may be an Output Enable and Write Enable or a multiplexed R/W line. For chips that require separate OE and WE lines you will need to provide the circuitry to split the CPU R/W line into the required OE and WE signals.
As to asking if a much faster CPU can be used I have in other articles tried to explain in layman’s terms why this is an issue. It can be mitigated once you understand what the issue is but it’s not as simple as just connecting the buses together.
To grasp this you need to think in terms of timing and for my example I’ll use an 8 MHz 6502 and we’ll have a 48 MHz AVR chip. And for simplicity sake we will assume only a single register which can be read and written.
How would you interface it? Well for starters you would need to assign 8 of the IO pins as the data bus. Next the CS line coming from the X16 needs to be set up as an external interrupt on the AVR. Since we have only a single register you will not need any address lines. And we can use the X16 R/W line to tell the AVR whether we are reading or writing. So you need 10 total IO pins on the AVR.
The X16 can now either read or write to the single register we are presenting. So to understand the timing that will be taking place and we have to allow a margin at the edges because the clocks are not synchronous. You need a margin in the design anyway but more if you cannot guarantee synchronization.
So what happens in timing terms when you attempt to write the register. Well we are going to do some quick math to determine what our access windows are. For a 6502 at 8 MHz you take 1000 ns (nanoseconds) and dude it by 8 to get the size of our cycles in nanoseconds. In this case it’s 125 ns. However the 6502 performs accesses in half cycles rather than full cycles so we need to divide that figure in half. Which gives us 62.5 nanoseconds for the access. Next we need to solve for the AVR at 48 MHz. Same equation 1000ns/48mhz gives us about 20 nanoseconds per cycle.
So let’s go step by step with what will happen starting with the start of the access window (when the CS line is triggered). This will invoke an interrupt on the AVR. The AVR will need to complete its current instruction so more or less your first 20ns of your 62ns window is taken up. Next the AVR is going to check to see if this is a read or a write access and branch accordingly. This takes a full cycle. So now you are into 40ns into the access. Next the AVR needs to store the value on the data bus which is going to use a single cycle. You are now at 60ns into the cycle and the X16 has successfully written to the register. But there is a caveat. This is assuming the clock edges are closely aligned. In reality they could be up to 20ns off in which case you could add nearly 20ns before the CS/IRQ is registered. This would throw all the actions that follow by the same amount. Since the data on the bus is only guaranteed to be valid for 10ns after the end of the cycle you will in this example possibly work, but it wouldn’t be guaranteed 100% of the time. So this is clear during this action the AVR only has time to execute 2 or three instructions before the access window ends and the data that is written is no longer guaranteed to be valid.
So what if the x16 needs to read. Well in terms of steps the AVR needs to get into it IRQ, branch based on the R/W state, and provide the requested data in less than 62ns. But it gets tougher here. The data needs to be valid and stable for at least 10ns before the end of the access window. In this scenario it is just possible if the clocks are correctly lined up but otherwise is a timing violation and will not work correctly.
So how do we mitigate this?
You need either a faster AVR and by that I mean much faster. Probably in the 60-200 MHz range. What about PIC, ARM, or Propeller? Well the same things apply to each of those. Each architecture will have its own limitations and some may be better suited but it’s still going to be a matter of how many steps can be completed during that access window.
Another way of mitigating it is by introducing waitstates. This would be added circuitry though in some cases it could be implemented by the AVR of equivalent. Basically the the CS line is asserted the x16s RDY line needs to be pulled low and held low as long as required. The issue with this is the X16 wasn’t exactly designed with waitstate in mind. In theory it would probably work fine but as of this writing it hasn’t been tested. If this waitstate was implemented in logic it could be done with a counter and a flip flop. If it was done by the AVR you could use one of its IO lines connected to RDY to perform the same task. You would just pull that line low first thing in the AVR and then switch the line back to high when the code is completed. This would have the benefit of allow as much access time as needed. But it has the effective drawback of slowing down the X16 cpu though in most cases it would probably only be a single cycle of delay.
As an important not I am making some assumptions about the AVR and that other micros will be similar. I am assuming that the IRQ only takes a single cycle and that you can execute a branch instruction based on the value of an IO pin and that all these instructions only take 1 cycle to complete. If any of these take longer then you definitely have to invoke waitstates.
By contrast most of these same tasks can easily be done by a sufficiently fast CPLD or FPGA which is why they a better suited to use on the system bus than a microcontroller. Microcontrollers are better off interfacing to the user port where the timing is much more forgiving.
Sent from my iPhone using Tapatalk