1. Have a master "ebi" device, then individual devices that hang off it specifying the addresses, etc, or2. Have up to 4 individual "ebi" devices which specify the addresses, and you attach devices to them.

In the former you configure the whole bus and it's the device's responsibility to carve it up. In the latter you carve the bus up and then attach devices to the carved up chunks.

I'm not sure which would be the best way to go. Thoughts?

Hi, by the way - been a while

_________________Why not visit my shop? http://majenko.co.uk/catalogUniversal IDE: http://uecide.org"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".

The EBI is the External Bus Interface - basically an 8086-like system bus. There's 4 dedicated CS pins for 4 address blocks (you can of course subdivide it manually if you like). So there's basically 4 devices, and you get to specify where within the EBI memory block those 4 devices are mapped, and how big a memory area they consume within that block.

So it's basically a question of do I define the bus and embed the device configurations inside the target device drivers, or define the devices and pass those to the target device drivers...

Or there is a third option - I could define just one device that covers the whole EBI memory block and divide it up manually...

_________________Why not visit my shop? http://majenko.co.uk/catalogUniversal IDE: http://uecide.org"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".

Maybe I will go for the third option actually - keep it all in software. Just define one single CS block that covers the whole memory area and allow as many devices within it as you like. Makes it more flexible. Then it's down to the device driver itself to define the memory area it's working with. It'd make the control of the EBI module somewhat simpler - just turn it on and leave it.

_________________Why not visit my shop? http://majenko.co.uk/catalogUniversal IDE: http://uecide.org"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".

1. We are in the forum "Board index » LiteBSD - Unix for microcontrollers with MMU » Kernel and Drivers"2. The MX doesn't have EBI

_________________Why not visit my shop? http://majenko.co.uk/catalogUniversal IDE: http://uecide.org"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".

I finally got around to reading about EBI on the PIC. Seems to me it might be pretty useful for i/o types of things. Along the lines of what I was talking about earlier. I want a fast way that the PIC can read a memory location and tell whether the peripheral has its flag set, has new data, etc.

It is not clear to me how fast EBI really is and also it seems like a HUGE waste of pins on the PIC.

That said some sort of 8 bit address, 8 bit data might make some sense but also appears to be reverting the the many parallel wires of the 8088 era? I am not sure what advantage this really gives to a product?

For me the idea of plugging in some custom gizmo and having it appear in the PIC memory and also on the web 'automatically' in some simple way would be pretty useful when doing custom stuff.

Then I could add 'drivers' to post process this raw data into other perhaps more useful forms. Raw temp. becomes degrees F comes to mind.

Some PICs are pretty cheap so maybe they could be used for a cheap 'foundation module'? It would be especially nice if they could be soft programmed and reprogrammed when attached. That seems pretty far from possible at this point?

The main use I would get out of the EBI is connecting a TFT screen with a 16-bit parallel (8086) interface. Connecting a big chunk of RAM would also be nice.

The advantage of the EBI over, say, SQI (which gives similar memory mapping functionality) is that of speed. SQI gives a 4x speed improvement over SPI (but only half duplex, but that's fine), and EBI gives a 4x speed improvement over SQI.

The slew rate on the IO pins of the PIC32MZ limits them to about 50MHz (ish) operation, which is the limit the SQI interface can run at, and I guess the EBI will be about the same.

The memory mapping side of things, of course, also means that code can be executed out of external RAM or ROM (though of course not as fast as internal memory, but faster than SQI).

At present I'm using the PMP for high speed TFT screen access, but I'd like to switch to using the EBI (which uses the same pins) at some point to see if it gives me faster and more fluid access (reading data with the PMP is a bit of a pain, it's always one transaction out - you read the byte you got during the previous transaction, not the one from the current transaction).

_________________Why not visit my shop? http://majenko.co.uk/catalogUniversal IDE: http://uecide.org"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".

There's no point in mining bitcoins any more. The electricity costs more than the value of the coins.

What to do with a laptop with a broken screen? Plug a monitor into it and install Linux.

_________________Why not visit my shop? http://majenko.co.uk/catalogUniversal IDE: http://uecide.org"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum