Announcement

Collapse
No announcement yet.

Using REP INSW

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Using REP INSW

    I have the following code written in C:

    void Insw(unsigned int port, unsigned int *buf, int count)
    {
    _ES = FP_SEG(buf); /* Segment of buf */
    _DI = FP_OFF(buf); /* Offset of buf */
    _CX = count; /* Number to read */
    _DX = port; /* Port */
    asm REP INSW;
    }

    I want to implement a similar function in PowerBasic (for Windows Version 7)
    where the buffer can be located anywhere in memory. The purpose is for our
    ADC board in which we have a very large FIFO that I want to read out into a
    user specified memory buffer (perhaps up to 16Kwords at a time).

    Do you have any example code or suggest how this could be done in PowerBasic.

    Thanks!
    Mike Ihm

    ------------------
    Apex Embedded Systems
    www.apexembedded.net
    Apex Embedded Systems
    www.apexembedded.net

  • #2
    For direct access, the FIFO buffer needs to be mapped in the programs memory space.
    (If the board is designed for Windows use, it probably has an API interface with it...)
    If not, and you want to access the board directly, you'll need a driver like NTPio.
    (from www.lvr.com )


    ------------------
    Regards,
    Peter
    Regards,
    Peter

    Comment


    • #3
      Mike,
      use the assembler within PB something like this:
      Code:
      'PBWIN7.02 program
      #REGISTER NONE
      FUNCTION PBMAIN() AS LONG
      
      DIM buf%(16000)  'create 16,000 word data buffer in memory
      ioport%=2345     'the I/O port to use
      cnt& =123        'the number of words to get
      
      b&=VARPTR(buf%(0)) 'get address of 1st item of buffer
      
      !pushad          'save all registers
      
      !mov edi,b&      'buffer offset to edi
                       'ES is already set to the same as DS by default
      !mov ecx,cnt&    'get the count
      !mov dx,ioport%  'get the i/o port
      !rep insw        'get the data from i/o port to memory
      
      !popad           'restore all registers
      
      END FUNCTION
      Paul.

      ------------------

      Comment


      • #4
        VERY OLD Post, but in the case Paul is watching and worth resurrecting....I work with Serial Ports all the time, and this is the 1st lead I have to possibly looking into the "Inner-Workings" of a Serial Port if anyone can help???

        I think www.lvr.com is the place to look, but as I am looking more at the "How does the engine work??" than I am at "How do I change the Oil???" I was hoping someone might have a nugget to chew on and can help me locate just where the buffers are so I can look at them????
        Engineer's Motto: If it aint broke take it apart and fix it

        "If at 1st you don't succeed... call it version 1.0"

        "Half of Programming is coding"....."The other 90% is DEBUGGING"

        "Document my code????" .... "WHYYY??? do you think they call it CODE? "

        Comment


        • #5
          Cliff,
          this thread isn't really about serial ports, it's about reading blocks of data from I/O ports. What's on the I/O port isn't clear.

          If you want to know the insides of the serial port then read the data sheet for the 16550 UART chip that used to control it:
          http://www.national.com/ds/PC/PC16550D.pdf
          Searching for 16550 UART will get you lots more information.

          If you're not electronically minded then just skip the electrical specs and read what the registers do.

          These days the chip doesn't really exist as a seperate entity in the PC, it's usually one small part of a larger chip but the function from the point of view of the pins and the registers is the same.

          If you program in DOS or Win98 then you can access the port registers directly but Later versions of Windows won't let you.

          Paul.

          Comment


          • #6
            Thank YOU Paul!!!!!... (it just might be my lead into underlying info)

            Specs can be confusing...but code posts of some else's "Understanding" of said posts can be worse...

            I know full well it might be something that I rip my hair out over, but have to do it, and I am VERY thankful for people like you that can point me the right direction (even if its a "Well...its not the way I think, but if it helps then..." sort of thing :coffee4
            Engineer's Motto: If it aint broke take it apart and fix it

            "If at 1st you don't succeed... call it version 1.0"

            "Half of Programming is coding"....."The other 90% is DEBUGGING"

            "Document my code????" .... "WHYYY??? do you think they call it CODE? "

            Comment

            Working...
            X