View previous topic :: View next topic |
Author |
Message |
Adrian Bennett
Joined: 08 Dec 2008 Posts: 3
|
Posted: Tue Dec 16, 2008 7:20 pm Post subject: How can the USB port be accessed to send and recieve data. |
|
|
I would like to be able to send and recieve blocks of data through the USB port. Is there a windows API call I could make from FTN95 to accomplish this? FTN95 has commands for the serial port or the printer. Now the USB port is very prevalent and much more useful. I would like to be able to use the USB port from the FORTRAN code. Is there maybe some lines of assembly that could be included in my code for this? Any information would be very appreciated. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Tue Dec 16, 2008 9:23 pm Post subject: |
|
|
You can access files on a USB memory device just like any other files.
You will need to know the drive letter that the device is mapped to, otherwise just use a standard Fortran OPEN statement as usual. |
|
Back to top |
|
|
Adrian Bennett
Joined: 08 Dec 2008 Posts: 3
|
Posted: Wed Dec 17, 2008 7:13 pm Post subject: Not to memory device. |
|
|
Hello Paul,
Thanks for the reply. This in the end may be the best way to send the data, but I am not sure. I am interested in sending data to and from a Xilinx FPGA device from a FTN95 program. I want to design some highly paralled computations into the FPGA then make function calls from FTN95 through an interface module(FTN95 module) to this device. I would like to make a library that I can use which gives the user access to the computational abilities of the programmed FPGA. I do not know if this info would change your answer, or if you have any suggestions that would bring me closer to doing this? Thanks.
Adrian Bennett |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Wed Dec 17, 2008 11:09 pm Post subject: |
|
|
The FTN95 library includes some undocumented routines that allow memory to be shared between processes using what are called memory mapped files.
These might be useful in this context and other users may also be interested. I will aim to put together an outline for the Knowledge Base as soon as I can. |
|
Back to top |
|
|
Adrian Bennett
Joined: 08 Dec 2008 Posts: 3
|
Posted: Wed Dec 17, 2008 11:28 pm Post subject: Thanks. |
|
|
Hello Paul,
Thank you for your response. I look forward to reading your post in the Knowlege Base section whenever it becomes available. I am sure this will be very useful.
God bless you,
Adrian Bennett |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Thu Dec 18, 2008 7:28 pm Post subject: |
|
|
I am putting my sample code here rather than in the Knowledge Base for the time being because there is an error in one of the standard header files. This will be corrected for the next release. Because of this, I have had to declare my own CREATE_SHARED_MEMORY@ in order to correct the existing declaration of CREATE_INTERPROCESS_SHAERMEM@ which is both miss-spelt and has the wrong return type.
I have written one application (see the code below) and the idea is that you run two instances of the application. The first instance sends the message "Hello there!" to the second instance. The message is passed across by using shared memory together with a semaphore for synchronisation purposes. Here is the code...
Code: | include <windows.ins>
integer ptr,r
integer(2) c
integer,parameter::buffsize = 1024
character(*),parameter::semaphore = "MySemaphore"
character msg*80
C_EXTERNAL CREATE_SHARED_MEMORY@ '__create_interprocess_shared_memory' (STRING,VAL):INTEGER
ptr = CREATE_SHARED_MEMORY@("MyMemory",buffsize)
if(ptr == 0) stop "Failed to create shared memory"
r = TIMED_WAIT_ON_SEMAPHORE@(semaphore, 1000) !Wait for at most one second
if(r == 0) then !We must be in the the first instance
call SIGNAL_SEMAPHORE@(semaphore) !Signal for timed wait in second instance
print*, "First instance"
print*, "Press any key to send message"
call get_key@(c)
call CopyMessage(CCORE1(ptr), buffsize, "Hello there!")
call SIGNAL_SEMAPHORE@(semaphore) !Signal for infinite wait in second instance
print*, "Read the message in a second instance then press any key to terminate"
call get_key@(c)
else
print*, "Second instance"
print*, "Waiting for message..."
call WAIT_ON_SEMAPHORE@(semaphore)
r = buffsize
call ReadMessage(msg, CCORE1(ptr), r)
print*, msg(1:r)
print*, "Press any key to terminate"
call get_key@(c)
endif
call UNMAP_FILE@(ptr)
end
subroutine CopyMessage(dest, size, src)
integer size
character dest(size)
character(len=*) src
do i = 1, len_trim(src)
dest(i) = src(i:i)
dest(i+1) = '~' !Add end marker.
if(i+1 == size) exit
enddo
end
subroutine ReadMessage(dest, src, size)
integer size,k
character(*) dest
character src(size)
do i = 1, size
if(src(i) == '~') exit !Detect end marker
dest(i:i) = src(i)
k = i
if(i == size) exit
enddo
size = k
end |
|
|
Back to top |
|
|
Andrew
Joined: 09 Sep 2004 Posts: 232 Location: Frankfurt, Germany
|
Posted: Mon Dec 22, 2008 4:15 pm Post subject: |
|
|
It all depends on how your USB device functions as to how you will communicate with it. Usually vendors will provide a driver for the device that will abstract the actual details of interacting with it to an API of some sort. Mass storage devices, for example, will use a driver that will enable a USB device to function as a disk drive as far as the rest of the system goes.
If the USB device does some form of specialised task then it is probable that the vendor has details of how to communicate with it. If they do not then you may have to write a driver, which could be very involved. Coincidently, I have just had to write a USB driver for a device that had no driver for an esoteric OS, which has been rather painful. The first thing I would do is check with the vendor to see how they recommend communicating with the device and perhaps I could give more advice knowing that. |
|
Back to top |
|
|
|