How did someone get 48MHz I/O speed, I have only ever been able to reach 24MHz and that was with direct registry access.
LPC_GPIO0->FIOCLR = 0x07800000;
LPC_GPIO0->FIOSET = 0x07800000;
In addition is there any further developments/benchmarking been done on mbed I/O speed. I haven't done much with the mbed recently as I just felt it could achieve the speeds I wanted.
I have started to look at the mbed again in the hope it has grown an would be able to acheive what I want.
If i can get the speed required (<40nS if possible) the I would probably use the lpc1768 on a pcb.
I want to be able to have an external SRAM interface to a 4Mbit SRAM with a 16bit data bus.
I would also want a data bus connecting another controller possible a second lpc1768.
The idea being that I have an LPC1768 reading inputs from a controller.
This LPC1768 reads the input and outputs a 8/16/32bit command to the second LPC1768.
The second LPC1768 reads the instruction from the first LPC1768 and performs data manipulation on image data stored in external SRAM according to the code is recieves from the first LPC1768.
So within the second LPC1768 it may have a lookup table that says if i recieve instruction 0x00780000 then move image starting at 100,100 with a width of 100 and height of 100 to have a starting point of 300,300.
This means that the second lpc1768 reads and writes data from the SRAM to alter the position of the image as the specified location.
Then using a bus exchanger the SRAM is then flipped to the FPGA which is acting as a VGA controller in this system.
The display resolution I am going to use is 640 x 360 which is 16:9 aspect ratio. This is because 640 x 360 fits into 4Mbit SRAM when 640 x 480 at 16bpp doesn't.
The pixel clock of 640 x 480 at 60Hz is 25.175MHz hence the want for an I/O speed of <40nS so I could completley change the frame of an image at 60 frames/sec.
I understand I wont reach that level due to the calculations/lookups the second LPC1768 will need to do, however I would like to get as close as possible.
I would be will to settle for a level of 30 frames/sec, but need to aim high first to give myself room to come down.
I would be designing a PCB that would contain 2 LPC1768's and 1 small FPGA probably from Xilinx in QFP form.
I want to use 2 LPC1768's because I think manipulating the data in external SRAM will be enough work for it to do and I think that if i tried to get it to read controller buttons an calculate where things moved on a screen I would loose too much performance in the way of frame rates, given I believe it will struggle as it is.
The point is to make a basic games console, probably on the level of the SNES (Hopefully Better)
So....After that long essay of trying to explain what I am trying to achieve.
I would like to know if what I want to achieve with the I/O is possible or should I just look at another device and if so some suggestions of microcontrollers with fast I/O would be very helpful.
On a final note, I would like to avoid BGA's and QFN's as I intend to solder this myself, and although I have the means to get a bga down, I would rather not have to as it becomes very expensive if it goes wrong.
Thanks in advance guys, hope someone can help
Brief decription of how one operation might work.
player presses right on controller pad.
mbed1 reads controller pad inputs
mbed1 detects right button pressed
mbed1 knows a right button press means move sprite 10 pixels right
mbed1 determines current sprite location is 100,100
mbed1 knows sprite is 100,100 big
mbed1 sends code to mbed2 (0x00780000)
this means move image starting at location 100,100
to location 110,100
with a width/height of 100,100
fill location left empty by move with background texture
fill 100,100 to 109,200 with background texture
mbed2 recieves code
mbed2 looks up what code means
mbed2 carrys out sram read and writes to move image
mbed2 controls the buffer enchanged device to flip the SRAM memory so it will be used by the FPGA
fpga continuously reads from the sram ram it is using and using logic within it outputs a VGA video signal
I thought I might see what a quick first step might look like. Remember, I'm flying blind so please be gentle! So, the idea is to...
1) change the pins around so at least the bus is on the same port, and redo the wiring - check it all works
2) try a fast version of the write to the port, but nothing else - see if that works
3) Well, if you've got this far, things are looking good - time to continue optimising.
So, here are the details:
1) involves moving to P0.0-P0.11, and for simplicity moving the other pins off port 0, which i think is basically:
Note, p30 is bit 0, and p27 bit 7. So with that change, and after rewiring all those wires, you should be able to run again and it still work. If not, rinse, repeat.
2) involves writing directly to the port. So, something like:
And then see if that works.
Note, it only changes two of the functions, and is just a raw write to the port with no mask, so not quite how you'd actually do it and and doesn't do anything for the other pins or input/output, but i'd hope it'd be enough to measure a difference to show it working. The idea being if it doesn't work, not much has changed so the bug should be easier to track down. And if/when it does, then it is time to do it properly, and for the other pins etc. i.e. 3)