Find the answer to your Linux question:
Results 1 to 2 of 2
I am interfacing to an FPGA using buffered address/data lines on a Digi cc9p9215 embedded module running on Linux/C. When I mmap (using CS2 at address 0x60000000) I find that ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    May 2011
    Posts
    14

    Linux on NS9215 ARM Processor / Interfacing Buffered Address/Data


    I am interfacing to an FPGA using buffered address/data lines on a Digi cc9p9215 embedded module running on Linux/C. When I mmap (using CS2 at address 0x60000000) I find that data lines D0 thru D7 are actually "multiplexed" onto data lines D8 thru D15. Buffered data lines D0 thru D7 appear to do nothing? Anyone else come across this quirk? I am told this is because of the endianness? Looking on an oscilloscope at the BD8 output, if I write (from my program) 0x0100 I can see the BD8 data line pulse high for the second half of the write cycle, if I write 0x0101 I can see BD8 pulse high for double the width, starting at the first half of the write cycle, but BD0 stays low? If I just write 0x0001, BD8 Pulses high for the first half of the write cycle. Any thoughts please......

  2. #2
    Just Joined!
    Join Date
    May 2011
    Posts
    14
    RESOLVED: My bad! I didn't realize that on the ARM 9 architecture the external address lines are used for a data "channel". For 32 bit reads/writes D0 thru D7 are ignored and 4 8 bit bytes are transferred on D8 thru D15 using A0 and A1 to define the "position" of the bytes. If A2 thru A15 are mapped to A0 thru A13 they act as "normal" address lines. If only interested in transferring 1 8 bit byte (as I am) you can write the same data to the FPGA 4 times (actually is 4 chip select cycles) and just choose which byte to read into the FPGA (we chose to clock when A1 is high). When reading there is only one chip select cycle and the bytes are again clocked by A0/A1. In this case we read all 4 bytes into a long integer, the two least significant bytes of which are undefined as again we are clocking data out of the FPGA on address 1. If anyone is interested I have written a more detailed document, with timing diagrams.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •