This tutorial shows how to build a DSS service from scratch, which enables FT hardware to be driven by MRDS. Originally I had set out to create such an activity for my own use. But the process turned out to be pretty straightforward and I learned a lot while doing it, so instead of just publishing the end result I decided to make a little tutorial out of it.
It is important to understand that MRDS can only control an FT brick by teleoperation, meaning that MRDS runs on your PC and sends commands to the brick over the wire. The "wire" is a USB cable, or in the case of the FT-32 brick may also be Bluetooth. MRDS runs on a .NET CLR, which does not run on the FT brick.
There are two ways to drive a microcontroller from the PC. One method is to download and run a monitor program on the brick which listens for commands and sends sensor data back to the PC. The LEGO activities which come with MRDS use this approach. Sending commands directly to the brick is a very common thing to want to do, so in many cases the microcontroller firmware will support a "direct" mode.
We're in luck because both the FT-16 and FT-32 controllers both support a direct command mode. In addition, fischer provides interface DLLs to drive them, along with documentation and sample code. In other words, most of the heavy lifting has already been done by the manufacturer.
The FT-16 is driven by ftLib.dll and the FT-32 is driven by ftMscLib.dll. The DLLs themselves are unmanaged code. The APIs are somewhat different between the two.
The FT-16 is controlled by directly setting and reading registers in a "transfer area", which is a block of memory that is updated at regular intervals. This synchronization between the brick and the PC is performed by a monitor loop running on the brick, which is started/stopped by API calls. (This type of programming interface will be familiar to anyone who has programmed a Commodore VIC-20 or 64.)
The FT-32 is a little bit simpler to set up and use, the brick is controlled mostly through API calls. The FT-32 has a similar architecture and also uses a monitor loop, but the transfer area is wrapped in API calls, so there is seldom need to access it directly.
The sections can be followed independently of each other, they are almost identical - but not quite.
The samples are not production quality code.
Driving the ROBO Interface (FT-16) Brick With MRDS
Driving the ROBO TX (FT-32) Brick With MRDS
Note: both of these samples ran on a 32-bit PC running Windows XP. I also tried them on a 64-bit PC running Windows 7 and they didn't work, this is a pending work item.